Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят
Один раз я написал статью о том, как увлечение новым языком программирования спасло меня от выгорания. Её прочитало много людей, и меня позвали работать в стартап. Предложение было заманчивым, ребята звали меня делать реальные вещи, а не абстрактное дерьмо. Я согласился.
478478 показов
63K63K открытий
GoF мне кажется это худшее что случилось в индустрии. Много раз сталкивался с ситуацией когда разработчик получает задачу, решение которой довольно простое, но из-за количества абстракций, фабрик, 10 абстрактных классов, 12 интерфейсов, 5 уровней наследования сложность решения становится колоссальной и сам разработчик не может реализовать это все без багов, что требует дополнительных затрат на юнит-тестирование всего этого зоопарка абстракций, и вся эта куча, предназначенная казалось бы для решения задачи управления сложностью эту сложность и создает.
Почему то для многих хорошая архитектура начинает измеряться количеством абстракций, но это не так. Изначальная задача по поддержанию сложности кода на приемлемом уровне не означает что вам нужно абстрагировать все, и найти в книжке паттерн, который можно натянуть на ваш юзкейс, потому что каждая абстракция имеет цену, в том числе цену поддержки, а задача крутого программиста минимизировать цену разработки и я говорю не о деньгах, хотя очевидно что это коррелирует с бизнес-затратами. И зачастую, особенно если речь идет о хай-левел задаче, ад-хок решение конкретного случая дешевле во всех отношениях чем придумывание генерализации для частного случая в том числе и с точки зрения поддержки.
Есть шуточный пример на гите Hello World Enterprise Edition, который конечно утрирован, но не сильно далек от правды, когда работаешь с GoF адептами на проектах.
Я много лет проектирую фреймворки разной степени величины и с моей точки зрения хороший фреймворк это не тот, который решил все возможные дженерик задачи абстрактно, а наименее интрузивный, с наименьшей стоимостью абстракций, тот который можно выкинуть за день работы и прицепить другое решение и наличие всего этого зоопарка из GoF как правило усложняет, а не облегчает этот процесс. Самая дешевая и удобная абстракция это функция, и если есть возможность использовать функцию и это решает проблему не нужно городить ООП ад. Даже прежде чем создавать класс вместо функции стоит несколько раз подумать. Ну а если руки полезли создавать фабрику вместо вызова конструктора то нужно иметь очень веское обоснование для этого.
А мне вот не кажется, что зоопарки абстракций — это прям худшее. Если человек без надобности пишет паттерн на паттерне, то это как правило от того, что у него есть сильная внутренняя потребность в гармонии и красоте, к которой он неумело тянется. Такому человеку можно показать Путь, и есть хороший шанс, что он поймет. А вот научить писать хороший код человека, который сразу начал гавнокодить, у меня еще не получилось ни разу.