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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Haskell - рай для математика, джунгли для программиста.

Попытался на днях разобраться в Haskell. Прочёл две книги, написал немного кода по их примерам и могу сказать, что: да - язык лаконичен и математически точен.
Но для программиста, даже владеющего функциональным подходом он слишком замудрён. Чтобы сделать простые вещи приходится столько выворачивать мозги. Пока не понял систему типов.
После двух недель изучения пока не вижу способа прочесть код пары игр SDL. Вроде всё понятно, но где-то скрывается недопонимание системы типов.

Буду учить дальше.

Erlang как язык для АСКУ

Недавно искал способ сделать мои сервера АСКУ более надёжными и стабильными. Появился новый проект, который требовал создать за короткий срок сервер опроса и распределения данных. Но прошлый сервер мне на Delphi обошёлся в 1.5 года, чтобы учесть утечки памяти и стабильность при повышении нагрузки.

Для этих целей полез в интернет. И нашёл там Erlang. Многие писали, что у него синтаксис сложный, но по сравнению с недавно обнаруженным Haskell-ем или F# он, можно сказать - минималистичен.

Распределенное приложение у меня вышло в 6 строк. Короче только на рубине 5 строк. Но у рубина проблема с GIL, а тут система может поднимать 1М процессов на одной машине.

Так что потихоньку изучаю и пока радуюсь тому, что есть в базовом комплекте.