Эстетика в разработке, или Как качество кода влияет на успех бизнес-проекта
Статья будет полезна владельцам продуктов, заказчикам, так и начинающим менеджерам, руководителям команд, которые хотят улучшить процессы на проекте, повысить эффективность своей команды или просто познакомиться с инструментами разработки. Эта информация поможет пролить свет на некоторые вопросы, например, как ускорить онбординг новых специалистов…
Код должен решать задачу.
Оптимальным способом с минимальными издержками.
Не должен он быть эстетичным. Не должен быть красивым. Не должен радовать глаз разработчика.
Задачу он, блэт, поставленную должен решать.
Красивый и «эстетичный» код не гарантирует и даже не коррелирует с качеством.
Чистота кода может снижать издержки (стоимость поддержки и сложность онбординга), и то не всегда.
Но в огромном количестве случаев для бизнеса нести эти издержки выгоднее, чем «делать красиво».
В среднем, лучше потратить условные человекочасы на написание тестов, чем на холивары про нейминг переменных.
И то есть целый пласт исключений, когда и на тесты лучше забить.
Пойдите скажите бухгалтеру, что упорядочивание документов по папочкам - это лишние издержки. Надо зарплаты считать здесь и сейчас.
Или офис-менеджеру, который фрукты и молоко в офис делает, скажите, что не надо вот это вот молоко на одну полочку, бананы на другую. Свалил в кучу на складе и не трать время.
Вот с кодом та же фигня. Он красивый и глаз радуется не потому, что он в форме сисек, а потому что видишь, что с его поддержкой не возникнет проблем.
И доводить узкие места до нормального состояния гораздо проще в нормальном коде.
И самое главное, что для квалифицированного разраба писать красивый код - не такие уж издержки. В основном соблюдение всего-то пяти принципов делает жизнь гораздо проще. Ну создал я пусть даже 5 дополнительных классов для разделения логики - 2 минуты издержек. Они окупятся на 2-3 задаче по изменению этого функционала.
Правда есть два момента.
1. Далеко не всегда мы пишем с нуля, иногда приходим в функционирующий слипшийся спагетти-монолит. Тут конечно надо придерживаться золотой середины и не рефакторить весь проект в рамках первой же задачи.
2. Среди разрабов много таких, кто понятия не имеет, какой код - «красивый», но упорно его делает. Конечно, это потеря времени. Потом приходит другой и переделывает. Это проблема.
В общем, красивый код - важно даже не в долгосрочной, а в очень даже краткосрочной перспективе именно потому, что ресурсов на его поддержку (а 80% времени мы поддерживаем и развиваем) тратится гораздо меньше.
а потом оказывается как у тинька "клиенты необоснованно обогатились на обмене валют"