В сфере разработки программного обеспечения, нередко встречаются тезисы наподобие «Nobody cares about your code» (перевод — «Твой код никого не интересует»), «Код всего лишь инструмент» и ситуации полного непонимания со стороны бизнеса, почему это мы должны выделять время и деньги на какой-то там «рефакторинг» кода который уже работает.
Я хочу рассказать, к чему может привести «упор на характеристики», вместо заботы о качестве кода, и почему хороший код нужен не только программистам.
Поддержка
Главный тезис, без которого текущая статья в принципе была бы бессмысленна:
То что происходит в мире программирования уже десятки лет, ради чего создаются более совершенные языки, парадигмы, подходы, ради чего выделяют различные шаблоны и заботятся о дизайне кода это, по сути, две вещи — Увеличение скорости разработки и облегчение поддержки кодовой базы(что по сути скорость разработки нового функционала).
И это вещи которые нужны бизнесу.
Можно, конечно, возразить что методологии повышающие эффективность труда программистов нужны им самим, для того чтобы продавать свой труд дороже, умея делать больше за единицу времени, но из-за того что ситуация когда у программистов заказывают сразу крупный готовый проект без необходимости дальнейшей поддержки весьма редка, и обычно функционал заказывается постепенно, при старте проекта пагубного влияния плохого дизайна вы не ощутите, это скорее инвестиция в будущее.
На эту тему есть изображение из блога Мартина Фаулера, показывающее скорость введения нового функционала в проект в зависимости от времени его существования(т.е. насколько он крупный).
Горизонтальная ось — время существования проекта, вертикальная — совокупная функциональность.
Красная линия иллюстрирует скорость развития проекта с хорошим дизайном, а синяя — проекта, который пишется без каких-либо ограничений в виде требований качеству кода.
Таким образом, если вы считаете что ваше приложение обречено на провал, и развиваться не будет, или готовится исключительно к какому-то ближайшему ивенту, вам нет смысла задумываться о дизайне системы. В противоположной ситуации хороший дизайн скорее всего будет окупаться, и окупаться многократно.
Иногда можно услышать мнение что при старте проекта можно не задумываться о качестве кода, и переписать его заново после успешной презентации клиентам/инвесторам, но в подавляющем большинстве случаев это ошибка начинающих проектов, и простейший путь нажить себе технического долга на годы вперед.
Код — не инструмент, код — итоговый продукт
Компания занимающаяся разработкой ПО не использует код как инструмент. Это основной продукт компании, именно итоговый код программы определяет её качество, скорость работы, соответствие требованиям к функциональности. Его нельзя просто так взять и полностью заменить не понеся при этом временные и материальные потери, как можно было бы сделать с Компьютером/IDE/Методологиями разработки, которые уже будут по сути являться инструментами для создания продукта.
Про «Упор на характеристики»
В статье, на которую я ссылался была озвучена следующая мысль: с заказчиком/Project Manager`ом нужно общаться на уровне состояний готовности проекта, и противопоставлением являлся следующий пример:
Представь, что дизайнер начнет рассказывать тебе об использованных им слоях в Фотошопе, о том, как много у него там объектов, какие градиенты использованы на каких кистях и какие крутые анимационные скрипты он написал. Тебя это не интересует. Тебя интересует, можно ли уже забирать картинки.
Так вот. Есть одно отличие из-за которого его нельзя просто так проецировать на ситуацию с поддержкой программного продукта — все эти слои и кисти в фотошопе становятся никому не нужны сразу же после того как результат работы(картинки), и как раз таки являются инструментом для достижения результата, а не итоговым продуктом.
Таким образом, при составлении требований к итоговым картинкам заказчик может не беспокоиться о том, что будет использовано в процессе. В случае с ПО, если заказчик(бизнес) будет требовать от приложения исключительно функциональность, он рискует получить ровно то что хотел — новую функциональность, а о том что это нужно будет поддерживать и развивать — речи не было.
К сожалению, это довольно распространённая проблема на аутсорсе, когда компания продаёт лишь время своих разработчиков, а заказчики не могут объективно оценить качество системы, и время необходимое на решение его задач. Когда стоимость изменения кода будет возрастать экспоненциально, это пойдет лишь на выгоду самой компании аутсорсеру — больше человекочасов можно монетизировать, а компания заказывающая продукт будет уже на крючке — переписывать громоздкую и неудобную систему уже поздно, так как это требует огромных вложений и остановку поставки нового функционала, что допустить нельзя.
Код — рабочее место программиста
За всё время что статья лежала в черновиках, я много думал стоит ли включать в неё этот пункт, но после небольших наблюдений за приоритетами кандидатов находящихся в поиске работы, понял что данный момент действительно важен.
Код — это то, с чем программисту придется работать ежедневно, его творческий продукт, то что он создает, но создаёт не один, а в команде, и, часто, уже не с нуля. Ему нужно принять уже существующую часть проекта, развивать его опираясь на тот функционал что написан до него. Работнику скорее всего будет неприятно работать в продукте который создается некачественно.
На первом месте, на мой взгляд, стоит команда совместно работающая над проектом. От того, как построена работа в команде, от внутренних правил и установленных внутри неё требований напрямую зависит качество получающегося продукта.
На втором месте — технологии. Бездумно выбранный либо доставшийся в наследство неудобный фреймворк, устаревшие и некачественные инструменты, библиотеки прибитые гвоздями к проекту месте со всеми их костылями и багами, с которыми приходится мириться, и отсутствия людей с достаточными компетенциями и наличием времени для устранения легаси подходов могут запросто отпугнуть возможных новых работников. Помимо причин озвученных выше, это также меньшее количество перспектив и возможностей для развития программистов, потому что вместо изучения современных и наиболее эффективных инструментов приходится разрабатывать подпорки для приспособления к текущим задачам решений доставшихся в силу исторических причин.
К чему это всё
К сожалению, требования к реальным приложениям редко могут быть сформированы на все 100%, и не требовать пересмотра во время разработки. Тем более практически невозможна ситуация, когда проект не придется подстраивать под новые требования уже после запуска. Бизнес расширяется, развивается, требует функционал о котором не было речи раньше, выходит на новые рынки.
Построить идеальную и продуманную до каждой мелочи архитектуру в таких условиях практически невозможно, да и, часто, незачем, потому что её стоимость в таком случае неоправданно высока для начальной стадии проекта.
Определённо, написание хорошего кода не должно быть головной болью тех, кто заказывает ПО у программистов, а проверить его навряд ли будет под силу тому, кто не умеет его писать.
Тем не менее компания разрабатывающая программный продукт, если желает сделать его качественно, должна понимать, что такая значимая часть продукта как его исходный код прямым образом влияет на его успех, и на такие вещи как рефакторинг исходного кода и модификация архитектуры под новые требования так же должен быть бюджет, должно выделяться время программистов. Если кого-то интересует качество продукта, конечно же.
Впрочем, IT-индустрия развивается, развиваются продукты, компании, инструменты, пользователи становятся избирательнее, возрастает конкуренция, появляется надежда что будущее все-таки за качественными продуктами.
Заключение
На самом деле тема статьи, конечно, весьма спорная.
Приведенный график не даёт ответа на вопрос, в какой же момент времени дизайн системы начинает окупаться.
Технический долг на то и долг, что позволяет получить немножко больше времени сейчас, и отдать с процентами потом, а главная его проблема исключительно проста, и сильно напоминает подобное явление в экономике — это неумение расплачиваться по долгам и невозможность точно оценить будущие доходы.
Качество кода вещь также весьма субъективная, и, к сожалению, практически неформализуемая, иначе программистов уже можно было бы начать заменять роботами.
В любом случае, самое главное — достижение грамотных компромиссов и нахождение той самой золотой середины, что позволит не утопить проект в яме технического долга в погоне за функционалом, и не уступить интересную нишу конкурентам, занимаясь дизайном системы вместо функционала.
Автор: Евгений Ромашкан
