Alexey Kuznetsov

+18
с 2020
0 подписчиков
27 подписок

Я переехал в другую страну по банальным бытовым причинам. Сосед сверху купил квартиру, нарушил кучу норм делая перепланировку, в том числе нормы по  шумоизоляции, нарушил функционирование общедомовых коммуникаций, затопил 3 раза меня за месяц. Я не могу добиться вообще ничего, потому что он очень важный главный гаишник, вынужден сидеть без газа в доме где нет центральной горячей воды, и с автоматом электрическим на 16а, потому что у этого мудака стоит 40 и тсж мне не разрешает поменять, чтоб верхнего уровня атомат выжил. Тсж разводит руками, милиция, суд, прокуратура просто исчезают с заявлениями в никуда. Это один из тысячи подобных моментов, которые коснулись моей жизни непосредственно. Всеми доступными инструментами я пробовал оперировать, но практически ниче не работает. Многие из моих коллег, в том числе кого я сам перевез уехали вцелом по этим же причинам. 

Я сталкивался обычно с другим. Человек, который пишет зоопарки абстракций не тянется ни к какой красоте, просто когда-то ему все сказали что есть умная книжка, которая лучше знает как сделать все. Он перестает думать и анализировать, зачем, если умные люди в книжке все придумали, он просто матчит задачу на первый попавшийся паттерн.
Люди которые пишут хороший код сейчас, когда то давно писали дерьмовый, все без исключения. И как правило каждый из них думает над задачей, не только с точки зрения моментального решения, но и с точки зрения развития кода, интеграции с остальной кодовой базой и поверьте никто из них не пытается заматчить задачу на паттерн из книжки, потому что паттерн из книжки абстрагирован от контекста. И даже казалось бы типовые задачи, которые эта книжка призвана решать, все равно в контексте реальной разработки софта имеют особенности, которых в книжке невозможно учесть.
Обучаются все как правило написав код не отвечающий каким либо требованиям, будь то поддержка или перф, и начиная решать точечно проблемы конкретно их кода. Те кто начинает кодить с этой книжки как правило зарываются в абстракциях и просто не могут решить задачу, то есть выполнить непосредственно работу. Есть неплохие книжки в которых описан общий подход к решению задач и проектированию систем и примеры из жизни с ошибками, и лучше почитать их, чем сборник абстрактных решений абстрактных задач в вакууме.

3

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

16