Я хочу рассказать, к чему может привести «упор на характеристики», вместо заботы о качестве кода, и почему хороший код нужен не только программистам.
Поддержка
Главный тезис, без которого текущая статья в принципе была бы бессмысленна:
То что происходит в мире программирования уже десятки лет, ради чего создаются более совершенные языки, парадигмы, подходы, ради чего выделяют различные шаблоны и заботятся о дизайне кода это, по сути, две вещи — Увеличение скорости разработки и облегчение поддержки кодовой базы(что по сути скорость разработки нового функционала).
И это вещи которые нужны бизнесу.
Можно, конечно, возразить что методологии повышающие эффективность труда программистов нужны им самим, для того чтобы продавать свой труд дороже, умея делать больше за единицу времени, но из-за того что ситуация когда у программистов заказывают сразу крупный готовый проект без необходимости дальнейшей поддержки весьма редка, и обычно функционал заказывается постепенно, при старте проекта пагубного влияния плохого дизайна вы не ощутите, это скорее инвестиция в будущее.
На эту тему есть изображение из блога Мартина Фаулера, показывающее скорость введения нового функционала в проект в зависимости от времени его существования(т.е. насколько он крупный).
Горизонтальная ось — время существования проекта, вертикальная — совокупная функциональность.
Красная линия иллюстрирует скорость развития проекта с хорошим дизайном, а синяя — проекта, который пишется без каких-либо ограничений в виде требований качеству кода.
Таким образом, если вы считаете что ваше приложение обречено на провал, и развиваться не будет, или готовится исключительно к какому-то ближайшему ивенту, вам нет смысла задумываться о дизайне системы. В противоположной ситуации хороший дизайн скорее всего будет окупаться, и окупаться многократно.
Иногда можно услышать мнение что при старте проекта можно не задумываться о качестве кода, и переписать его заново после успешной презентации клиентам/инвесторам, но в подавляющем большинстве случаев это ошибка начинающих проектов, и простейший путь нажить себе технического долга на годы вперед.
Код — не инструмент, код — итоговый продукт
Компания занимающаяся разработкой ПО не использует код как инструмент. Это основной продукт компании, именно итоговый код программы определяет её качество, скорость работы, соответствие требованиям к функциональности. Его нельзя просто так взять и полностью заменить не понеся при этом временные и материальные потери, как можно было бы сделать с Компьютером/IDE/Методологиями разработки, которые уже будут по сути являться инструментами для создания продукта.
Про «Упор на характеристики»
В статье, на которую я ссылался была озвучена следующая мысль: с заказчиком/Project Manager`ом нужно общаться на уровне состояний готовности проекта, и противопоставлением являлся следующий пример:
Представь, что дизайнер начнет рассказывать тебе об использованных им слоях в Фотошопе, о том, как много у него там объектов, какие градиенты использованы на каких кистях и какие крутые анимационные скрипты он написал. Тебя это не интересует. Тебя интересует, можно ли уже забирать картинки.
Так вот. Есть одно отличие из-за которого его нельзя просто так проецировать на ситуацию с поддержкой программного продукта — все эти слои и кисти в фотошопе становятся никому не нужны сразу же после того как результат работы(картинки), и как раз таки являются инструментом для достижения результата, а не итоговым продуктом.
Таким образом, при составлении требований к итоговым картинкам заказчик может не беспокоиться о том, что будет использовано в процессе. В случае с ПО, если заказчик(бизнес) будет требовать от приложения исключительно функциональность, он рискует получить ровно то что хотел — новую функциональность, а о том что это нужно будет поддерживать и развивать — речи не было.
К сожалению, это довольно распространённая проблема на аутсорсе, когда компания продаёт лишь время своих разработчиков, а заказчики не могут объективно оценить качество системы, и время необходимое на решение его задач. Когда стоимость изменения кода будет возрастать экспоненциально, это пойдет лишь на выгоду самой компании аутсорсеру — больше человекочасов можно монетизировать, а компания заказывающая продукт будет уже на крючке — переписывать громоздкую и неудобную систему уже поздно, так как это требует огромных вложений и остановку поставки нового функционала, что допустить нельзя.
Код — рабочее место программиста
За всё время что статья лежала в черновиках, я много думал стоит ли включать в неё этот пункт, но после небольших наблюдений за приоритетами кандидатов находящихся в поиске работы, понял что данный момент действительно важен.
Код — это то, с чем программисту придется работать ежедневно, его творческий продукт, то что он создает, но создаёт не один, а в команде, и, часто, уже не с нуля. Ему нужно принять уже существующую часть проекта, развивать его опираясь на тот функционал что написан до него. Работнику скорее всего будет неприятно работать в продукте который создается некачественно.
На первом месте, на мой взгляд, стоит команда совместно работающая над проектом. От того, как построена работа в команде, от внутренних правил и установленных внутри неё требований напрямую зависит качество получающегося продукта.
На втором месте — технологии. Бездумно выбранный либо доставшийся в наследство неудобный фреймворк, устаревшие и некачественные инструменты, библиотеки прибитые гвоздями к проекту месте со всеми их костылями и багами, с которыми приходится мириться, и отсутствия людей с достаточными компетенциями и наличием времени для устранения легаси подходов могут запросто отпугнуть возможных новых работников. Помимо причин озвученных выше, это также меньшее количество перспектив и возможностей для развития программистов, потому что вместо изучения современных и наиболее эффективных инструментов приходится разрабатывать подпорки для приспособления к текущим задачам решений доставшихся в силу исторических причин.
К чему это всё
К сожалению, требования к реальным приложениям редко могут быть сформированы на все 100%, и не требовать пересмотра во время разработки. Тем более практически невозможна ситуация, когда проект не придется подстраивать под новые требования уже после запуска. Бизнес расширяется, развивается, требует функционал о котором не было речи раньше, выходит на новые рынки.
Построить идеальную и продуманную до каждой мелочи архитектуру в таких условиях практически невозможно, да и, часто, незачем, потому что её стоимость в таком случае неоправданно высока для начальной стадии проекта.
Определённо, написание хорошего кода не должно быть головной болью тех, кто заказывает ПО у программистов, а проверить его навряд ли будет под силу тому, кто не умеет его писать.
Тем не менее компания разрабатывающая программный продукт, если желает сделать его качественно, должна понимать, что такая значимая часть продукта как его исходный код прямым образом влияет на его успех, и на такие вещи как рефакторинг исходного кода и модификация архитектуры под новые требования так же должен быть бюджет, должно выделяться время программистов. Если кого-то интересует качество продукта, конечно же.
Впрочем, IT-индустрия развивается, развиваются продукты, компании, инструменты, пользователи становятся избирательнее, возрастает конкуренция, появляется надежда что будущее все-таки за качественными продуктами.
Заключение
На самом деле тема статьи, конечно, весьма спорная.
Приведенный график не даёт ответа на вопрос, в какой же момент времени дизайн системы начинает окупаться.
Технический долг на то и долг, что позволяет получить немножко больше времени сейчас, и отдать с процентами потом, а главная его проблема исключительно проста, и сильно напоминает подобное явление в экономике — это неумение расплачиваться по долгам и невозможность точно оценить будущие доходы.
Качество кода вещь также весьма субъективная, и, к сожалению, практически неформализуемая, иначе программистов уже можно было бы начать заменять роботами.
В любом случае, самое главное — достижение грамотных компромиссов и нахождение той самой золотой середины, что позволит не утопить проект в яме технического долга в погоне за функционалом, и не уступить интересную нишу конкурентам, занимаясь дизайном системы вместо функционала.
Комментарии (21)
rzerda
19.03.2019 13:32+1Итоговый продукт — не код, а решенная проблема. Особенно отлично, когда проблема решается вообще без нового кода, например, уместным использованием sed, grep и awk.
Многие программисты же отчего-то свято веруют, что их единственная задача состоит в написании кода. Да и как бы (зачастую внешне) трепетно один программист не относился к своему коду, всё равно потом придёт другой и скажет «тут всё неправильно, надо переписывать».
EvgeniiR Автор
19.03.2019 13:45Задача программиста — формализовать задачу и все возможные варианты и исходы, и решить её за минимально возможное время оставляя точки для расширения в зависимости от предполагаемых будущих требований )
Дядя Боб в книжке «Идеальный программист» рассказывал, почему всякие популярные ошибочные предположения 20-летней давности типа избавиться от кода и предоставлять решение задачи на более высоком уровне абстракции — например в виде диаграмм понятных любому человеку(Model-driven architecture), не избавит нас от необходимости найма программистов.
«Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the
problem is code. But code is not the problem. It has never been the problem.
The problem is detail.»
Да и как бы (зачастую внешне) трепетно один программист не относился к своему коду, всё равно потом придёт другой и скажет «тут всё неправильно, надо переписывать».
Ну и, такие вещи всё же нужно чем-то обосновывать
Dgolubetd
19.03.2019 13:48Потому что это основная и первостепенная задача. Если работодателю нужно починить кран или забить пару гвоздей, то для этого не обязательно программистов нанимать.
szelga
19.03.2019 13:55+1Особенно отлично, когда проблема решается вообще без нового кода, например, уместным использованием sed, grep и awk.
думаю, в статье рассматриваются не те случаи, когда можно обойтись коротким скриптом.
Whuthering
20.03.2019 12:33когда проблема решается вообще без нового кода, например, уместным использованием sed, grep и awk.
При этом однострочник, связывающий пайпами эти sed, grep и awk с источником и получателем данных, а так же, например, сами регулярки и другие аргументы, которые передаются этим утилитам, по сути дела в итоге будут являться кодом, хоть и весьма простым.
JekaMas
19.03.2019 14:42Вы ведь недавно во всем в этом? Вариантов намного больше, чем 2: "с дизайном" и "без". Наше ремесло в оценках. Сколько будет жить продукт? Будет ли время его дорабатывать? Что для этого продукта "достаточно хорошо"? Всегда городить долг — неверно, поскольку не решит всех задач. Всегда делать идеальную расширяемую архитектуру равно неверно, поскольку тоже не решит всех задач. Наше ремесло в трезвых оценках и выборе нужных инструментах, как мне видится сейчас.
eefadeev
19.03.2019 14:49Приведенный график не даёт ответа на вопрос, в какой же момент времени дизайн системы начинает окупаться
Собственно это — самый главный вывод. Как писали, если не ошибаюсь, Том с Тимом: «Все говорят что им нужно качество. Угадайте от чего отказываются в первую очередь?»
maxzh83
19.03.2019 16:13По моему скромному опыту (почти 15 лет), хороший код бизнесу не нужен. Совсем. Бизнесу важно, чтобы в первую очередь все работало как должно, во-вторую, чтобы быстро можно было впилить очередное поведение/хотелку. Собственно, на этом все. Если все работает на костылях и программист Вася умеет строить новые костыли поверх старых, то и отлично. Иногда этот самый Вася хочет все разломать и сделать по-нормальному. Он приходит к бизнесу, спрашивает про переделки и часто получает ответ в стиле Золушки: конечно, сделай все хорошо, но вот все должно работать через неделю. Как-то так, все вышесказанное это только мой личный опыт.
EvgeniiR Автор
19.03.2019 17:58+1Мне не совсем понятна ваша терминология. Разве тот факт того что в код можно легко и быстро вносить изменения не ломая всё остальное не есть качественный код? Что тогда значит сделать «по нормальному»?
И если все же код состоит из костылей — что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код? Что будет когда Васю попросят поменять что-то спустя пол года как он сделал какую-то фичу, он так же сможет разобраться со всем что он нагородил до этого?
P.S.Если все работает на костылях и программист Вася умеет строить новые костыли поверх старых, то и отлично
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?maxzh83
19.03.2019 18:14Разве тот факт того что в код можно легко и быстро вносить изменения не ломая всё остальное не есть качественный код
У меня не было про «легко», у меня было про «быстро». Это примерно как если что-то отвалилось, то есть разные варианты починки: заменить, склеить или замотать скотчем. Бизнесу тут часто достаточно скотча. Да, в какой-то момент скотч отвалится и Вася будет придумывать что-то еще или более крепкий скотч… Еще, в какой-то момент Вася может прийти стукнуть кулаком по столу и сказать, что либо он увольняется, либо тратим время на рефакторинг. Это тоже может прокатить.
что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код?
Нет, изменения будет тяжело вносить. Но бизнес это мало заботит, к сожалению. Со временем Вася расскажет Пете про все виды костылей и все.
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?
Нет, это ужасно. Но бизнес остановится без Васи в любом случае, даже если бы он писал идеальный код, т.к. знание предметной области никто не отменял. Еще раз, я все это не оправдываю, просто к сожалению, часто такое встречал.EvgeniiR Автор
19.03.2019 18:25Да, в какой-то момент скотч отвалится и Вася будет придумывать что-то еще или более крепкий скотч…
Мне кажется далеко не каждый бизнес может смириться со стабильными сбоями в системе и давать одному Васе время их разбирать. Ну и если это обходится дешевле чем обзавестись программистами поопытнее… Видимо основной продукт бизнеса вовсе не ПО.
Со временем Вася расскажет Пете про все виды костылей и все.
Опять же, какие размеры у проекта, что чтобы его понять хватит «рассказать про виды костылей и всё»?
Нет, это ужасно. Но бизнес остановится без Васи в любом случае, даже если бы он писал идеальный код, т.к. знание предметной области никто не отменял.
Есть два отличия:
— Если Вася оставит костыли и уволится, они не будут понятны никому. Предметную область же скорее всего знает кто-то кроме Васи.
— Можно посадить Петю до того как Вася уволится, и он тоже сможет вникнуть в предметную область
я все это не оправдываю, просто к сожалению, часто такое встречал.
Ну… Если бы я этого не встречал, не появилось бы этой статьи )
Мой посыл как раз в том что так делать не нужно.
То есть… Треугольник Стоимость-Время-Качество никто не отменял, но об этом нужно задумываться, оценивать риски и находить грамотные компромиссы, а не лепить как попало пока проблемы не начнутсяmaxzh83
19.03.2019 18:49Мне кажется далеко не каждый бизнес может смириться со стабильными сбоями в системе и давать одному Васе время их разбирать.
Немножко уточню, это не сбои обычно, а хотелки. Т.е. приходит бизнес с горящими глазами и требованием сделать новый функционал, который в текущую архитектуру не укладывается совсем. Но функционал этот не просто нужен, а «нужен вчера». И остается вариант прикрутить это все синей изолентой к текущей архитектуре.
И еще, тут Вася это не обязательно один программист, это может быть команда или отдел.
оценивать риски и находить грамотные компромиссы, а не лепить как попало пока проблемы не начнутся
Это все правильно, но я не видел живого проекта, приносящего деньги, где все было сделано хорошо в этом плане. Везде присутствуют костыли, где-то меньше, где-то больше.
JekaMas
19.03.2019 21:34Мне доводилось видеть и Очень крупный бизнес. Там ровно так же, как сказал товарищ в начале ветки. Если Вася не в состоянии показать, что вот сейчас вот для этого куска или сервиса имеет смысл потратить время на долг и тогда вот какие-то конкретные, нужные бизнесу, фичи выйдут в более краткий срок, то Вася пойдет обратно к ноуту фигачить фичи и код без особой архитектуры.
EvgeniiR Автор
19.03.2019 22:57Да, не спорю, это так, и это не радует. Опять же, нет черного и белого, есть компромиссы, и проблемы возникают если приоритеты заданы не верно.
dipsy
19.03.2019 18:36+4Слона надо есть по частям, переписывать всё и сразу в рабочей системе из легаси-кода (не покрытого тестами) конечно не вариант. Нужно писать новый функционал «как положено» и заодно немножко подчищать старое, пресловутый принцип бойскаута. Вообщем всё давно придумано, главное чтобы разработчик дорос до соответствующего уровня и понимания. По своему аналогичному не менее скромному опыту, начинает приходить это как раз лет через 10, и надеюсь не закончится, всё-таки приятно каждый год понимать, что ты всё делаешь лучше, чем год назад.
bevalorous
20.03.2019 14:37Часто бизнес понятия не имеет, что «быстро» и «качественно» как-то связаны. Для него детали разработки находятся «под капотом». Адские костыли, отсутствие тестов, плохая архитектура, велосипедостроение — все это для бизнеса, как правило, не видно вовсе, пока все работает как должно и новые фичи пилятся быстро. Проблема в том, что бизнесу обычно не с чем сравнить — что означает «быстро» при разработке новых фич и «работает как надо» при сопровождении. Все, что видно бизнесу, — это как все устроено с его личным продуктом. Разве что сравнить с конкурентами, у которых почему-то новые фишки появляются быстрее, регрессии и баги — реже, а высокая нагрузка не приводит к даунтаймам. Но это обычно достаточно закрытая информация, а то, о чем бизнес знает — это как обстоят дела с его собственным продуктом (который «под капотом» кривой, косой, плохо масштабируемый и ужасный в сопровождении).
Это как если вы сдаете машину в аренду какому-то водителю, интересуясь только количеством заказов и прибылью, и однажды обнаруживаете, что автомобиль не просто почти не приносит прибыли, а с трудом ездит и убит в хлам, потому что водитель экономил на ГСМ и запчастях, ни разу не делал техобслуживания и был крайне неразборчив в выборе пассажиров и грузов. Вполне возможно, что к моменту обнаружения истинного положения дел автомобиль будет уже не в том состоянии, когда его рентабельно восстанавливать — придется покупать новый.
С плохим кодом та же самая история. Если бизнес не понимает, что от качества кода, архитектуры, культуры разработки зависит способность итогового продукта приносить деньги, то однажды бизнес обнаружит, что продукт не просто не прибылен, а что он убыточен и уже не может стать прибыльным снова — дешевле переписать его с нуля или заменить на готовое решение от третьей стороны.
r_a_g_n_a_r
20.03.2019 19:34Как-то брал для другого ресурса интервью у Staff Engineer из HBO (до этого поработавшего и в Amazon). Чувак очень старался донести мысль, что бизнесу нужен только говонкод, а в индустрии всех это устраивает. Не уверен, можно ли тут давать ссылки на сторонние ресурсы, но, кому интересно, могу кинуть в личку.
VasilyErmak
20.03.2019 19:35+1У меня было внедрение ярко показывающее отношение к этому вопросу заказчиков.
Переводил 2 с лишним года назад компанию с 1С: Предприятия 7.7 (Бухгалтерия и Торговля и Склад) всё переписано под клиента, особенно ТиС на 1С: Предприятия 8 (Бухгалтерия 3 и Управление торговлей 11). Я был третьим кто за это у них взялся и тем кто это наконец выполнил. Доработки были в основном в УТ 11 их было много и учитывая специфику клиента без них действительно нельзя было обойтись. Разговора о рефакторинге того, что было сделано до меня не было, в прочем как и времени на это.
С нового года клиент начинает работать в новых программах. К концу февраля отлаживаю работу, так что клиент решает что этот этап выполнен и надо приступать к следующему большому этапу доработок с учётом всех новых возможностей 8 версии 1С: Предприятия.
Готовлю ТЗ и первым пунктом ставлю рефакторинг того что было дописано в УТ11, прошу на это месяц с соответствующей оплатой. Объясняю, что за время запуска мне столько костылей пришлось наделать в коде моих предшественников, что дальше двигаться мне просто совесть не позволяет.
Дело даже не в том, что что-то я сделал по другому. Просто понимание специфики работы клиента до запуска реальной работы и после разные. А мои предшественники и близко к реальной работе не подошли. Плюс исправление ошибок в условиях когда для тебя главное обеспечить непрерывность работы.
В результате кроме того, что клиент не согласился на рефакторинг, у него ещё изменилось отношение к сделанному и в том числе ко мне. Они думали, что всё хорошо, а я сам говорю что не очень.
В итоге клиент нанял нового разработчика. За мной оставили поддержку сделанного.
Новые ребята рефакторинг делать не стали, но 3 месяца изучали, то что было сделано до них. Хотя я на всё просил 5 меяцев. Потом тупо перетащили все доработки в 1С:CRM. Через год клиент так и не получил того, что было в первоначальном ТЗ. Ещё через два месяца они наняли штатного программиста 1С.
Через несколько месяцев я им позвонил, узнать как дела. Мне сказали, что штатный программист пока делает ревизию (не рефакторинг) доработок.maxzh83
20.03.2019 19:53+1Поэтому опытные разработчики частенько молча закладывают рефакторинг в оценку трудоемкости и все довольны. Но это на совести разработчика остается и не с каждым заказчиком прокатывает.
d-sky
21.03.2019 10:57Я на 100% согласен с последним абзацем:
В любом случае, самое главное — достижение грамотных компромиссов и нахождение той самой золотой середины, что позволит не утопить проект в яме технического долга в погоне за функционалом, и не уступить интересную нишу конкурентам, занимаясь дизайном системы вместо функционала.
Нужно искать компромисс, хотя если рассмотреть две крайности:
- неработающий проект с идеальной архитектурой
- работающий проект с невозможностью вносить изменения
второй все же предпочтительнее.
puyol_dev2
Очень верно написано в конце про баланс. О коде забывать не стоит, но на первом месте продукт, как итоговый результат работы