Недавно мой товарищ и подписчик прислал мне видео, которое предложил обсудить в канале.
Видео само по себе уже содержит довольно много рассуждений на тему того надо или не надо говнокодить, стоит ли вылизывать код до перфекционизма и т.д. Так что тут уже особо в обсуждениях я каких-то новых революционных мыслей не внесу. Могу лишь выразить свое мнение по этому поводу и рассказать как эти идеи эволюционировали в моей работе.
На начальных этапах моей программистской карьеры меня метало из стороны в сторону. Начиналось всё с ужасного говнокода “и так сойдет, работает же”.
Под шквалом справедливой критики я начал читать книги типа “Совершенный код”, “Программист прагматик”, паттерны банды четырех и т.д. Ну и конечно десятки и сотни хабрастатей и им подобных как круто писать чистый код, как необходима гибчайшая, максимально расширяемая архитектура. Ну и начал максимально вылизывать даже самые простые случаи, пихать максимальное колличество паттернов, которые я знаю, куда надо и куда не надо.
Мне казалось, что вот сейчас стало круто и идеально (на самом деле нет). Потом, поддерживая это переусложненное творение, я понял, что красота и идеальность кода не в том, чтобы напихать туда как можно больше всего, про что ты недавно прочитал.
После этого я решил поумерить свой пыл, но продолжил разрабатывать так, что “а вот тут может понадобиться изменение логики, там расширение функционала, здесь увеличится нагрузка”. И это неплохой подход, но делал я так везде. Во всех проектах, во всех задачах. А реально стреляло это где-то в 20% случаев. Так осталось много мертворожденных потенциальных фич, на которые было потрачено довольно много времени. Мне надо было читать Дональда Кнута, который говорит “преждевременная оптимизация — корень всех зол”. Мое мнение, что потом дооптимизировать в 20% случаев – зачастую (не всегда) проще, чем поддерживать изделие, которое излишне переусложнено в 80% случаев.
Теперь я стараюсь смотреть на проект и фичу с точки зрения не только реализации, но и бизнеса, заказчика, потенциальной эволюции требований. Со временем и опытом сердечко стало лучше подсказывать, где можно быстро наговнокодить на коленке проект, который послезавтра уже выкинут, а где нужно строить хорошую архитектуру, писать тесты, думать о вариантах развития проекта, который будет расти и поддерживаться годами.
Ну и, конечно, надо рассмотреть идеальный вариант. Как известно, самый лучший код – это код, который не написан. Так что некоторые задачи иногда стоит обдумать и обсудить с заказчиком и своим здравым смыслом. Как показывает моя практика – заказчик не всегда сам знает, что именно ему нужно и как. Он просто заносит свои идеи, формулируя это как требования, а ретивый программист бежит их исполнять. Тут помогает взгляд со стороны бизнеса и умение построить диалог, в котором и программист, и заказчик смогут понять, что же на самом деле надо и какие есть варианты реализации. Кто-то может заметить, что для таких разговоров есть ПМы, аналитики, тимлиды, а не программисты. Ну…..да. Где-то есть, где-то нет. Тут речь в целом о концепции не брать сразу под козырёк и бежать исполнять любой чих.
Вывод
Говнокод писать иногда можно и даже нужно, но и злоупотреблять им не стоит. Смотрите на сам проект, на влияние заказанной фичи на бизнес, на перспективы развития. Думайте, перед тем как делать. Не занимайтесь преждевременной оптимизацией. При возможности не писать код – не пишите, не умножайте энтропию:)
