Значение культуры
разработки для заказчика
и программиста

24 июля 2019

Волкова Ангелина,
PR-менеджер Intaro
Качество конечного продукта, будь то написанная на коленке программа или интернет-магазин с многомиллионным оборотом, зависит от качества кода.
Если на проекте архитектурные решения оставляют желать лучшего, реализовать любую доработку в будущем будет долго и дорого, а также велик риск неожиданных поломок.
О значении культуры разработки для программистов и проекта в целом, ее формировании и поддержании в компании поговорим подробнее.
Некачественно выполненный код сложно поддерживать. Логика плохого кода понятна только его разработчику, а значит, чтобы внести малейшие изменения в проект, нужно постараться. Значительная часть времени программистов уходит не на разработку фич, а на исправление старых багов.
Чем так плох «плохой код»?
Для разработчика
Рефакторинг (или переработка структуры) плохого кода трудоемкий и рискованный процесс. Когда не понятно, на чем держится эта конструкция, велика вероятность сломать всё при малейшем прикосновении.
Демотивация. Работать с плохим кодом тяжело и неприятно, у хорошего программиста быстро наступает выгорание и компания рискует потерять ценный кадр.
Для заказчика и проекта в целом
На старте проекта качество кода может не отражаться на работе, но при росте нагрузки некорректная структура и неэффективно реализованный функционал могут существенно влиять на производительность кода, а значит на скорость и качество работы сайта.
К нам на поддержку пришел чужой проект с большим количеством плохого кода, с целью срочно сделать хайлоад оптимизацию сайта за неделю перед «Черной пятницей». Команда заказчика осознала, что сайт не выдержит высокой нагрузки и упадет в самый неподходящий момент.

Авральный режим и крайне не очевидная логика архитектуры кода привели к тому, что изменения в несвязанных частях проекта уничтожили все свойства товаров в каталоге. На восстановление ушло несколько драгоценных часов.
В процессе масштабирование проекта все изменения, которые нужно внести, будут требовать больше рабочих часов программиста, а значит и денег.
Во время проведения рефакторинга на одном из наших проектов удаление всего одной строчки устаревшего кода привело к приросту 70% производительности.
На первый взгляд элементарные задачи выливаются в огромные трудозатраты. Код обмена на одном из проектов был настолько запутанным и не оптимальным, что каждая доработка вызывала кучу ошибок и новых проблем (в одном месте правишь, в другом ломается). Трудозатраты оказывались в несколько раз больше ожидаемых. Одну из задач оценивали в 8 часов, а затратили 100.
Конечно, не получится сформировать культуру по щелчку пальцев. Это ежедневная работа по установлению стандартов, контролю, обучению и наставничеству. Даже уже сложившуюся культуру разработки можно легко разрушить неправильно выстроенной мотивацией, попустительством и постоянными горящими задачами, которые нужно «сделать вчера и не важно как».
Как сформировать культуру разработки?
Это не значит, что правильную архитектуру нужно ставить превыше всего. Если реально срочный и важный функционал выйдет с опозданием, то даже идеальный код не спасет ситуацию. Поэтому на практике иногда приходится сделать «по-быстрому», но обязательно выделить время на переработку решения, чтобы в дальнейшем без проблем вносить новые фичи.
Каждый новый разработчик изучает действующие регламенты и тренируется на тестовых проектах. А его боевые задачи контролирует старший коллега. Они общаются и обсуждают все архитектурные решения.
А как у нас?
Значимое место в команде имеет менеджер проекта. Он отстаивает важность каждого этапа разработки перед заказчиком и предоставляет программистам адекватные сроки на выполнение задач.
На действующих проектах за качеством кода следит ответственный тимлид. И если код написан неоптимально, он безжалостно отправляется на переработку. При этом на наиболее сложных проектах проводится полноценное code-review, где тимлид вместе с автором разбирают код строчка за строчкой и доводят его до необходимого уровня.
По завершении проекта команда разработки готовит всю необходимую техническую документацию по проекту, чтобы любому новому специалисту было сразу понятно, что к чему.
Когда команда получает на поддержку чужой проект с кодом не лучшего качества, важно еще «на берегу» обсудить с заказчиком значение постепенного рефакторинга кода. Хоть с точки зрения пользователя программа не меняется, рефакторинг позволит удешевить разработку и поддержку проекта в будущем.
Код в наследство
Переписывать всё с нуля - это трудозатратно, дорого и может повлечь много непредвиденных проблем. А постепенные правки — то, что надо. И чем дольше команда работает на проекте, тем меньше остается плохого кода.
Читать также
Подпишитесь на рассылку
Мы будем присылать лучшие статьи и кейсы
о ecommerce не чаще 2 раз в месяц.
Нажимая на кнопку, Вы соглашаетесь с политикой обработки данных