Miscellanea II

На самом деле откровенно плохой код в production встречается не очень часто. Ну вот прям плохой-плохой, ужас-ужас. Просто потому, что оно хоть как-то, но работает, что уже критерий. Зато откровенно плохая архитектура на среднем уровне (то, что умещается в ООП-архитектуру, в разброс модулей, в общий стиль, так сказать, внутренней интеграции) в каждом втором проекте. Одноразовая. Понятная только создателю. Ушедшая от предметной области невообразимо далеко. И всё из лучших побуждений ведь. Написать очень гибко. Написать очень академически. Написать очень, очень изящно и красиво. И чтобы сущность “яблоко” выражалась через десять метаабстракций. Слишком уж крестьянски выражать яблоко яблоком. Или хотя бы фруктом. Пусть это будет SomePatternObjectDomainClass. А перевыпилить эту пакость крайне ресурсоёмко.

Парадокс языков вроде Ruby и Python в том, что на них очень легко начать и легко писать всякое, но с линейным ростом сложности сервиса сложность написания качественного кода возрастает экспоненциально. Не могу пока это как-то формализовать толком, но вот так опыт подсказывает. Ну т.е. чтобы хорошо написать большой проект на Python, вкладываться сильными ресурсами надо так же, как если бы этот проект был на Java / C++.

Сложно понять людей, которым равнодушно происходящее на самом деле. Есть какая-то конструкция языка, отражающая что-то, что человеку не нравится. Допустим, унарный инкремент. Вот фу-фу прям. В языке эту конструкцию убирают, но не убирают трансляцию / компиляцию в неё. Человеку сразу норм. Или заменяют каким-нибудь сахаром. Едва ли не макросом. И снова человеку норм. Как он при этом может не знать и не думать о том, что на самом деле он всё равно пишет тот же унарный инкремент — не понимаю.

Фигня относительно большой текучки кадров в том, что у тебя меньше шансов (на|пере)учить разработчика в стратегических вопросах. В 1817 году ты ему говоришь, что вот так делать нельзя, через пару лет при текущей динамике база лопнет, сервис ляжет, пользователи разрыдаются. Не убедил. Разработчик в 1818 году увольняется в закат. В 1819 году база лопнула, сервис лёг, пользователи рыдают. А ты сидишь дурак дураком и некому сказать “я же говорил! давай ты больше так делать не будешь”. А он уже в другом месте такую же ошибку совершает.

Допустим, ваша команда не успевает в срок. Допустим, то, что успевает, работает плохо и уныло. Что иногда делают? Ровно наперекор анекдоту (“Когда в борделе падает доход, следует менять блядей, а не передвигать кровати”) — меняют технологический стек, методологии, подход к разработке. О, давайте теперь писать функционально. И чтобы аджайл. И скрам! И уберём стулья, работать стоя прикольно и модно. Уииии! Это не спасает. Разве что вы писали сервисы на BASIC, а потом додумались до языков 2016 года. Почти всегда проблемы не в технологиях, но в людях. Эти проблемы и надо решать, а не кровати двигать. Казалось бы, общее знание, но бесконечно одно и то же. Утомляет листать десятки страниц Youtube с выдачей вида “используйте язык / технологию / утилиту XYZ и ваши рабы запрыгают быстрее”.

Добавить комментарий