среда, 17 сентября 2014 г.

Новые технологии и старые привычки

  Последнее время проповедуюю разработку на тестировании. Сначала было очень сложно, но сейчас - пишешь помаленьку и появляется чувство прогресса и видишь результат сразу.

Обратная связь как в игре - сделал что-то минута и получил ответ. И так шаг за шагом можно реализовать сложный функционал.

Но заказчикам не нравится скорость. Программирование на тестах в разработке в два раза медленее (но за счёт отладки - оно даже выгоднее, меньше на отладку времени уходит).

И приходится возвращаться к своему старому и отработанному способу. Просто пишешь и смотришь на результат, вручную отлаживаешь и тестируешь. И так шаг за шагом. Единственно, что трудно - не можешь быть уверен, что ничего не сломал. Регрессионных то тестов нет.

Да и программы получаются на выброс. Позже тестами программу покрывать сложнее чем если бы разрабатывал вокруг тестов.

Похоже, чтобы эффективно использовать эту методику нужно много своих мелких проектов поделать, чтобы конкурировать с программистами старой закалки.

Заметил, что основное время тратится на обдумывание: "Как же заставить этот мок работать так же как и компоненту этого класса?"

Google Mock, тесты и скорость разработки

  Работал над одним проектом. Наследный код надо было улучшить. И чтобы ничего не поломать писал тесты и для скорости (всё же юнит тесты должны работать быстро) - писал моки для работы.

  Пока изучал GMock, очень удивился, насколько интересный фреймворк. Но вот мышление тестами оказалось не так быстро. Понимаю, что сильно уменьшил время отладки и регрессионное тестирование показывает, где возможны проблемы.

Но это не понравилось работодателю. Ведущий программист сказал: "Пиши код, потом тесты". Это после того, как 3 года учился писать в начале тесты. Это было трудно. Смена парадигмы мышления не так прото даётся.

Начальник сказал: "Забрасывай тесты, или код никому уже не будет нужен." И это когда у него интеграция приложения занимает три недели вместо дня.

Что-же, хозяин барин. Единственное замечание и так может демотивировать.

Чувствую, что программист - всё же художник. И художника обидеть может каждый. Как это ни прискорбно.

Но, что порадовало - код получается хороший. После некоторого рефакторинга добавить было просто. Новый код тоже получился качественным.

Тесты - это очень полезная вещь.

Вот только как доказать начальнику, что он экономит на поддержке и отладке, и будущей разработке?

C++, Boost и шаблоны

     На новом рабочем месте удачно сложилось, что нужно вспомнить (и изучить новые стандарты) С++, библиотеку Boost и шаблонное программирование.

Могу сказать, что язык лишь немного улучшился с новыми стандартами. То, что я понял,- он больше стал дружеским.

Лямбды - это больше всего меня порадовало. Но также появились правосторонние ссылки, обобщённые и частичные шаблоны.

И всё бы ничего, но вкупе это приводит лишь к тому, что чувствуешь искусственность этого Boost. Да, он удобен и много чего есть. Но на изучение этого уходит много времени.

Работодатель же хочет быстрее. И работа с наследным кодом не улучшает дела. Сейчас мне понравилось в бусте то, что всё платформо-независимо.

Библиотека работы с тестами и вводом-выводом оказались весьма удобными.