Что такое 'хорошо'? Какое-то время назад я писал пост, главн | Shoo and Endless Agony

Что такое "хорошо"?

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

Первое - "простое" не значит "плохое".
Это далеко не всегда костыль, говнокод и некачественная работа.
Это просто самый примитивный способ решения поставленной задачи, без усложнений, оптимизации и всяческой красоты.
При выборе алгоритма для решения задач ты всегда начинаешь с "наивного" алгоритма - самого простого и очевидного способа решить задачу.
Затем, шаг за шагом, оптимизируешь его и усложняешь исходя из потребностей и условий задачи.
Самое важное в этом процессе то, что после каждого шага у тебя остается решение, которое работает.
У тебя всегда есть возможность сравнить, чем новая версия лучше предыдущей и возможность остановиться, если дальнейшие шаги не работают.
Если ты сразу берешься за создание "идеального" алгоритма - у тебя нет ни того, ни другого.

Второе - это глобальный вопрос про то, что же такое "хорошее" решение и чем оно отличается от "плохого".
Есть люди, которым нравится думать, что программирование - это искусство.
Они хотят писать чистый, красивый и оптимизированный код, использовать интересные и элегантные решения и делать "правильно".
Потому что могут. Потому что это "правильно", красиво, классно.
Но проблема в том, что разработка ПО - не про это. Она про то, что бы используя инженерные навыки решать задачи и потребности бизнеса.
И это, на самом деле, гораздо сложнее.
Искусство существует вне ограничений.
Ты можешь двигать дедлайны, переписывать всё с нуля,
использовать какой хочешь стэк технологий, забить на документацию и писать красивый код ради красивого кода.
Инженерные задачи, в свою очередь, существуют в пространстве ограничений.
Вот тут у тебя - куча легаси в продакшене, эта задача нужна ещё вчера, а ещё тебе надо будет потом нанимать людей на поддержку всего этого, так что лучше всё таки не использовать Nim, даже если он тебе очень нравится.
Хорошим решением становится то, которое позволяет потратить меньше всего ресурсов, максимально эффективно при этом закрыв потребность бизнеса.
Писать красивый, оптимизированный и расширяемый код, когда ни одно из этих качеств не нужно - настолько же плохое решение, как и выкатывать хреново оптимизированный код, когда от него требуется производительность.

Третье - про костыли, антипаттерны и следование best practices.
Костыли, хардкод и god-object'ы не являются злом сами по себе.
Они могут генерировать риски и технический долг.
Этот код может работать менее стабильно, его может быть сложнее расширять и поддерживать.
Всё это сводится к тому, что потом тебе может понадобиться потратить больше времени на рефакторинг, разработку последующих фичей и ночные хотфиксы.
Ну, или в то, что баг в продакшене будет стоить компании кучу денег.
При этом выбор между "правильно" и "костыльно" всегда является решением о том, нужно ли тратить ресурсы на то, что бы закрыть эти риски и технический долг сейчас,
или лучше отложить это на потом.
Здесь и проявляется то, что отличает действительно хорошего специалиста.
Способность адекватно оценить последствия каждого из вариантов, донести их до команды и бизнеса и способность вместе принять взвешенное решение.
Перекос в любую сторону, будь то "всегда втыкать костыли" или "всегда писать чистый код" - одинаково вреден.

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