Хорошие программисты и сложность
В хороших программистах, как и в бочке мёда, всегда найдется ложка дёгтя. О наболевшем и о том, почему энтузиазм не всегда полезен.
01.12.2014 | Автор: Александр Макаров
Частенько мне встречаются хорошие, на первый взгляд, программисты: они говорят правильные вещи, цитируют отцов основателей, критикуют плохие подходы. К сожалению, на практике они нередко оказываются не настолько хороши.
Чаще всего мешают им фанатичность, нетерпимость к альтернативам и полное отсутствие прагматичного подхода. От них часто можно услышать что-то вроде:
Код надо обязательно покрыть юнит-тестами на 100%. В тестах надо делать моки через мок-фреймворк.
Ни в коем случае нельзя писать связанный код.
Всегда без исключений надо следовать SOLID, DRY, GRASP и т.д.
Абсолютно все приложения надо строить по DDD.
Для доступа к данным обязательно нужен крутой ORM.
Писать документацию нет смысла, потому как она всегда отстаёт от кода. Код — лучшая документация.
Если в коде есть комментарии, код недостаточно отрефакторен. Всегда можно разделить код и назвать методы так, чтобы отразить предметную область.
Невозможно построить хорошую архитектуру без ООП.
И так далее.
Знакомо? Всё это выливается в непрактичные решения, реальной целью которых является доказать собственную правоту и крутость сделав «как учат в умных книгах». Реальность при этом частенько не учитывается.
Не следует забывать, для чего на самом деле мы пишем код. А именно:
Чтобы он работал и решал поставленные задачи.
Чтобы его могли прочитать, осознать и изменить другие программисты.
Для пункта номер два следует вносить в код как можно меньше сложности. Оправдана она только в том случае, когда другого выхода нет.
Это не означает, что не надо изучать шаблоны проектирования, читать Фаулера и т.д. Надо. Просто во всём надо знать меру и не бросаться применять прочитанное с особым энтузиазмом и уж, тем более, не стоит это делать, если вы не понимаете, для чего это и как оно упростит вам жизнь (и упростит ли вообще).
Полный текст статьи читайте на CMS Magazine
