Расширение языка

Очередной айтишный пост, ибо как я сейчас активно разрабатываю новый продукт. Мысли, соответственно, крутятся именно вокруг девелопмента :)

Как я уже говорил, свои 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 достаточно просто и незатейлив.

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

В общем, рекомендую :)

VN:F [1.9.20_1166]
0 голосов
9 комментариев
старее
новее большинство голосов
Межтекстовые Отзывы
Посмотреть все комментарии
авнонимус

во кстате, а ты тестами покрываешь модули? )

авнонимус

ну вот я так и не нашел варианта использования тестов при активном прототипировании ))
в два раза больше кода писать.. но — технический долг таки накапливается ((

авнонимус

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

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

Константин

Вот только проблема в том, что люди почти не сообщают разработчикам о багах. Если один написал в тех. поддержку об этом, значит 10 поморщились и не написали. Впрочем, это у массовых программных продуктов, в случае ваших продуктов (баз), возможно, другая специфика.

анонимаксимус

1. Юнит-тесты не нужны до тех пор, пока разработчиков в проекте чуть больше 0. Как только разработчиков станет больше, то контролировать качество выдаваемого кода можно только при помощи юнит-тестов или массированной атаки тестеров на кишащий багами проект. Но инженеры по тестированию хотят спать и есть, а юнит тесты готовы проверить качество проекта в любой момент за наикратчайший срок.
2. Юнит тесты позволяют делать массированный рефакторинг модуля, не беспокоясь о том, что функциональность не поломается. А если поломается, то будет обнаружно сразу же.
3. Юнит тесты можно рассматривать как документацию к коду. По простым тестам можно легко понять как должен работать код.
Рекомендую. проверено на себе не раз. (с)
:)