Очередной айтишный пост, ибо как я сейчас активно разрабатываю новый продукт. Мысли, соответственно, крутятся именно вокруг девелопмента :)
Как я уже говорил, свои 10,000 часов программистом я уже отработал. В реальности эта цифра ближе уже к 20,000 часов: было время, когда я кодил по 10-12 часов ежедневно по нескольку месяцев.
Так вот, дам полезный совет тем, у кого эта цифра значительно меньше: вместо создания библиотек расширяйте язык. Благо .NET дает для этого отличный функционал в виде Extention Methods.
Разница в том, что при написании библиотек на выходе получается цельный черный ящик, из которого используется хорошо если половина функционала. Чем больше времени прошло с момента написания библиотеки, тем меньше функционала используется и тем меньше ты помнишь, как оно там внутри устроено и работает.
Особенно это касается багов: если в первые недели после написания либы ты легко и непринужденно их правишь, то через полгода ты вынужден будешь разбираться в своем коде, как в чужом — проверено не раз.
В отличие от «библиотечного» подхода расширение языка дробит изначально цельную библиотеку на отдельные простые функции, которые ты можешь удалять и добавлять по желанию. Миграция этих функций в другие проекты — обычная копипаста, без необходимости перекомпиливать проекты при изменении функционала.
Представим себе сферического коня в вакууме: нам понадобилась шифрация, допустим.
В случае с «библиотечным» подходом мы создаем новый класс с нужным нам функционалом и либо создаем под него новую библиотеку, либо добавляем в уже существующую. Сама шифрация при этом будет выглядеть как подключение библиотеки, создание экземпляра класса и вызов метода этого класса. Дешифрация — тот же процесс.
В случае с расширением языка у меня есть просто большой класс Extentions, в котором находятся описания Extention Methods. Я просто добавляю туда две функции Encrypt(this byte[], string password) и Decrypt(this byte[], string password). При этом в любом месте своего проекта я могу написать data.Encrypt(«password») или data.Decrypt(«password») без создания классов и подключения библиотек.
Более того, я не должен заботиться даже о том, что data может быть null — он передается моей функции в виде параметра, который можно всегда проверить. Если эти же функции нужны в другом проекте, я просто копипастой переношу именно их, можно даже среду разработки не открывать. Достаточно обычного менеджера файлов с функцией просмотра.
В итоге вместо тонны классов, их экземпляров и вызовов функций получается компактный и понятный код, в котором баги сведены к минимуму: каждый из Extention Methods достаточно просто и незатейлив.
По мере расширения языка ты все больше приближаешься к программированию в терминах предметной области, все меньше обращая внимание на второстепенные технические детали.
В общем, рекомендую :)
во кстате, а ты тестами покрываешь модули? )
Пробовал, но отказался.
Дело в том, что разработка новых продуктов ближе к Research, нежели к Development, поэтому из-за постоянного изменения кода тесты «плывут». Получается, что ты ведешь два одинаковых по размеру и сложности взаимосвязанных проекта — основной проект + тест-проект.
Вместо этого я стараюсь разбивать все на мелкие простые блоки, чтобы визуально можно было ошибки ловить. Ну и везде встраиваю нормальное отслеживание и логгирование ошибок, чтобы можно было постфактум ловить то, что произошло.
Ну и при моем размере клиентской базы любые баги всплывают и фиксятся моментально :)
ну вот я так и не нашел варианта использования тестов при активном прототипировании ))
в два раза больше кода писать.. но — технический долг таки накапливается ((
Хоть какие-то тесты лучше, чем совсем никаких. При рефакторинге кода (а он обязательно случится в любом проекте), единственную гарантию работоспособности модулей дают только юнит-тесты. Но к тестам нужно подходить без фанатизма. ))
>>Ну и при моем размере клиентской базы любые баги всплывают и фиксятся моментально :)
Так у клиентов вырабатывается впечатление о продукте, как о сыром и ненадежном.
Тут есть ньюанс: 80-90% обнаруженных клиентами «багов» не имеют никакого отношения к системам автоматизированного тестирования. Чаще всего это неправильные тексты, названия, данные, модели поведения, сложные сетевые ошибки.
То есть в бизнес-логике (там, где можно автоматизировать) баги реально бывают очень редко, поскольку их с большой вероятностью видно еще во время разработки.
Вот честно: за последние 3 года работы со своими продуктами я еще не вспомню случая, когда я получал сообщения о каком-то конкретном баге больше, чем от пары человек. Если же это тот самый уникальный случай, когда баг проявляется у нескольких человек, чаще всего это сложновоспроизводимая особенность их систем, вроде корпоративных файрволлов.
Причем и «багом»-то это является с натяжкой: допустим, некоторые библиотеки чувствительны к локальному времени. А файрволл меняет время пакетов на лету с какого-то хрена. Ну устроен он так. И баг у клиента выглядит как отсутствие связи, причем все остальные программы у него работают нормально. И как его прикажете тестировать? :)
А ощущение «сырого» и «ненадежного» продукта складывается в первую очередь из интерфейсов и удобства использования. Опять же к автоматизированному тестированию имеет малое отношение.
Мое мнение, что юнит-тесты очень даже нужны. Но не везде, а там, где стоимость ошибки реально высока: те же финансовые системы, работа с ценными пользовательскими данными. В остальных случаях спасают немедленный фикс обнаруженных багов и ежедневные бекапы.
Вот только проблема в том, что люди почти не сообщают разработчикам о багах. Если один написал в тех. поддержку об этом, значит 10 поморщились и не написали. Впрочем, это у массовых программных продуктов, в случае ваших продуктов (баз), возможно, другая специфика.
Тут уже вопрос размера клиентской базы. Когда у тебя тысячи человек, ты нет-нет да и получишь сообщение о редком баге.
1. Юнит-тесты не нужны до тех пор, пока разработчиков в проекте чуть больше 0. Как только разработчиков станет больше, то контролировать качество выдаваемого кода можно только при помощи юнит-тестов или массированной атаки тестеров на кишащий багами проект. Но инженеры по тестированию хотят спать и есть, а юнит тесты готовы проверить качество проекта в любой момент за наикратчайший срок.
2. Юнит тесты позволяют делать массированный рефакторинг модуля, не беспокоясь о том, что функциональность не поломается. А если поломается, то будет обнаружно сразу же.
3. Юнит тесты можно рассматривать как документацию к коду. По простым тестам можно легко понять как должен работать код.
Рекомендую. проверено на себе не раз. (с)
:)
Спасибо, учту рекомендацию.
Просто действительно сейчас «чуть больше нуля девелоперов», поэтому вопросы проверки чужого кода не сильно актуальны :)
По опыту действительно скажу, что тестирование очень даже нужно, сами программисты код тестировать просто ненавидят. Да и мне кажется, что юнит-тестирование сможет приучить «слабого» девелопера к некоторой дисциплине, что полезно само по себе :)
Так что я отнюдь не агрессивный противник юнит-тестов, просто в своей практике пользы от них не вижу :)