Pull to refresh

Comments 72

UFO just landed and posted this here
Средний срок жизни кода становится всё меньше и меньше.
И если весь код вылизывать сейчас — то вылижут окончательно его к тому моменту, когда этот код будет уже не нужен.
Есть, конечно, фундаментальные проекты (вроде nginx-а), которым текущая тенденция нипочём, но большая часть бизнес-кода живёт так.

(и я не разработчик, я вообще динозавр-админ — просто смотрю, как часто проекты схлопываются или переписываются целиком по каким-либо причинам).
Они переписываются как раз потому, что дальше уже невозможно развивать из-за технического долга и плохого кода. Слишком дорогими становятся новые фичи.
Нет, оно переписывается, потому что концепция сменилась, нагрузка сменилась, требования от менеджеров сменились настолько, что нужно писать по новой, масштаб сменился, проект передали/продали другой компании с другим стеком и так далее.

Чтобы переписывали потому что «ну реально старое барахло же, давайте перепишем, а то фичу воткнуть не получается» (а не просто немножечко раскидаем код по другим файлам), и после переписывания оно делало ровно то же — я такое один раз за 5 лет навскидку вспомнил.

Соглашусь с предыдущим человеком. Видел пару небольших проектов, которые "ну полный пи… ц" и реально проще было бы переписать уже, но нет, всё равно равно дорабатывали.
Переписывают, всё таки когда уже идейно/морально всё устарело.
Или N лет создавалось на одной технологии, а сейчас проще написать с нуля используя новый стек технологии.

Часто переписывают от того что менялась команда разработчиков. Новые (а на найме в существующий проект всегда экономят) хотят работать только с использованием «модных» технологий, или не хватает компетенции быстро продолжить вести существующий проект на текущем уровне.
Вот и получается что срок кода около 5 лет (2 смены команды).

Это тоже разновидность долга. Если не используете современные технологии, то с каждым днём вам всё труднее будет не то, что расширять команду, а даже сохранять имеющийся штат. Имеющиеся люди будут требовать всё больше денег, чтобы остаться (компенсацию за технологическое "болото", практически исключающее возможность освоения новых технологий на рабочем месте), а то и просто уходить без требований, а новые так же будут просить больше денег за "легаси" или их квалификация будет заметно ниже.


С другой стороны, переписывать весь проект с нуля — не единственный способ уменьшать такой долг. Грамотная изначальная архитектура позволит с минимальными издержками переписывать проект по частям.

Ох уж эта вера в «грамотную изначальную архитектуру». А особенно слепая вера в её необходимость и вечность. Вот только о том что при планировании системы надо предусмотреть условия и порядок её вывода из эксплуатации апологеты «грамотной архитектуры» забывают «чуть чаще чем всегда».
Вот только о том что при планировании системы надо предусмотреть условия и порядок её вывода из эксплуатации апологеты

+++++ золотые слова — я тоже про это всегда говорю, но эффективным менеджерам и грамотным архитекторам это пофиг, т.к. это событие в очень далеком будущем

Грамотная архитектура — это практически всегда возможность расширяемости там, где оно с высокой вероятностью будет нужно. Иногда это единственный пункт грамотной архитектуры, потому что ничего другого не запилено и в ближайшее время не будет.

Так переписывание продукта на новый стэк и/или новую архитектуру и есть вывод текущей системы из эксплуатации, синхронизированный с вводом новой системы. Я к тому, что система изначально может предусматривать поэтапный вывод.

Ну если уж пошел такой базар, то «грамотная изначальная архитектура» должна также предусматривать т.н. Obsolescence management — т.е. предусматривать, что компоненты системы рано или поздно устареют (т.е. не смогут использоваться по назначению) и их надо будет обновлять. Причем устареть они могут не только по причине отсутствия поддержки, но также и из-за возросших требований к ним в процессе совершенствования продукта.

Причем это касается не только компонентов, но и технологий и ресурсов. Бывает, что отсутствие документации + разработчик ушел = компонент вдруг устарел.
Это все должно закладываться в архитектуре вместе с методами борьбы с этой болезнью.
Бывает, что отсутствие документации + разработчик ушел = компонент вдруг устарел

Скорее не устарел, а стал унаследованным, эффективное его развитие невозможно

"зло" вам, на секундочку, зарплату платит
идеально вылизанный код никому (кроме чувства прекрасного у программистов) не нужен. нужно, чтоб работало


хуже того: идеально вылизанного кода в принципе не существует как понятия. То, что считалось верхом вылизывания и оптимизации четверть века назад сейчас воспринимается как трудноподдерживаемый набор грязных хаков, и наоборот хороший годный современный код с позиции тех времён может восприниматься как overengeniered. Что будет ещё через четверть века вам никто сейчас не скажет

Не готов согласиться с Вами на сто процентов. У меня была возможность сравнить два проекта стартовавших в начале двухтысячных. Оба продукта в одной отрасли, оба B2B. В одном была лапша и набор самых плохих методик, в другом возможно не идеальный, но относительно чистый код.

Так вот, первый проект развивать дальше уже невозможно, а клиенты надо сказать, требуют современных решений. Я склонен поставить на то, что компания скоро схлопнется. Второй был успешно портирован на более современные версии программного обеспечения и фреймворков и на данный момент соответствует всем запросам потребителей.

Дело в том, что по 2 проектам делать выводы обо всех остальны — дурная идея.
На успех бизнеса влияет ещё множество факторов, которые вы не учли в этом примере. Да и компания ещё не схлопнулась всё же, по вашим же словам. Вы, кстати, поставьте, если так уверены, чтоб пустословом не прослыть.

Давайте по пунктам.

1. Я Вам привел один из свежих примеров в моей практике, нигде в моем комментарии не было сказано, что это единственное, что я видел в своей профессиональной жизни.

2. Факторов много, но это не повод делать плохо. Это то, что я также хочу донести.

3. Да я и поставил, управляющий в курсе моего мнения.
Не соглашусь. Хорошо написанный код «злу» деньгу приносит за счет того, что внесение изменений в существующий код либо разработка новых частей занимает значительно меньше времени, а при говнокоде, назовем его так, это время увеличивается, вследствие чего стоимость разработки становится дорогой.
Вдобавок, при расширении штата или изменении состава разработчиков, чистый код позволит быстрее новому человеку влиться в процесс, что, опять же, значительно лучше для бизнеса.

А что касается старого кода, на то есть код-ревью и рефакторинг, когда с течением времени необходимо изменять проблемные участки на актуальные решения.
С моей точки зрения — это верный подход.
А потом приверженцы такого подхода задаются вопросом — «А почему фичи внедряются по пол года?»
Дак, у вас долга в проекте уже больше чем кода.
С другой стороны, если использовать все методики и паттерны, типа SOLID, AGILE, SCRUM и тд и тп, то время разработки быстро стремится к бесконечности. Еще не факториал, но экспонента то уж точно.
Вы считаете, что правильно — это всегда долго?
А нет такой вещи, как правильно. Есть большой набор инструментов и методик. И много энтузиастов, которые стараются использовать максимальное их число.
Я считаю, что нужно для себя выработать разумное подмножество того, что использовать. Тогда возможно есть шанс.
Если не секрет, какие методики используете Вы и команда, чтобы удерживать технический долг в пределах разумного?
почему код нужно писать так как ты сказал? То что для одного best practice для другого чушь говяжья.
Например, смешивать в REST уровень HTTP (в данном случае транспортный) и прикладной (логику приложения) я считаю неправильным.
Вы API только для внутренних потребителей разрабатываете? Если нет, то не вызывал ли Ваш подход сложностей у партнеров?

А тут особо не важно. Просто объявляем партнёрам, REST HTTP (крайне редкий зверь) у нас или REST over HTTP.

гораздо проще когда сервис выдает 404 только если вы промахнулись с URL а не когда он не нашел в базе сущность с нужными полями
А habr.com/ru/post/49515666 должен выдавать 404? А ведь тут просто не нашли в базе сущность с нужными полями… при использовании АПИ отсутствие сущности гораздо более вероятная ситуация, чем «опечатка» в URI
А вообще для того, о чем вы говорите, придумали JSON RPC

А это не ендпоинт API. Тут 404 вполне уместна.


JSON RPC — лишь один из вариантов API c HTTP в качестве транспорта. Причём его сложно назвать REST

Я и не говорю, что JSON RPC это REST. Прям совсем не Representational State Transfer, а очень даже Remote Procedure Call. Просто в REST принято общение через методы и статусы HTTP. Вероятно для ошибки в URI можно использовать 400, а для отсутствующего «состояния» — 404. Или как ВАМ больше нравится. В этом плане REST прям совсем гибкий и не стандартизированный. И в этом его плюс и минус. JSON RPC пожестче. А хотите совсем жесткого регламента — используйте WSDL + SOAP

Принято в REST HTTP (редкий зверь) и вариациях на его тему (очень часто), но в REST (или что угодно, JSON RPC, GraphQL, SOAP и т. п.) over HTTP это вовсе не обязательно.


В общем все эти статусы и прочую семантику HTTP имеет смысл активно поддерживать, только если использовать HTTP в качестве протокола прикладного уровня, когда архитектура приложения поддерживает концепцию ресурсов как основную и большинство операций над ними сводится к CRUD. Ну или вам хочется максимально использовать имеющуюся глобальную HTTP инфраструктуру

Не стоит напрягаться, так и должно быть.
Уже проходили в других областях. С самолетами, автомобилями, сотовыми телефонами, смартфонами…
Каждый бизнесмен пытается влезть на новый и растущий рынок, не обладая достаточными знаниями. Область новая, квалифицированных технарей еще нету в нужном количестве, а квалифицированных менеджеров управленцев всегда дефицит был. Вот и нанимают кого смогут, пока ресурсы позволяют.

А качество продукта на этом этапе развития не важно никому, даже потребителю.
На мой взгляд потребителю важно, чтобы качество продукта соответствовало его минимальным требованиям, которые со временем ужесточаются под действием конкуренции. И в случае, когда из-за качества кода, разработка под новые требования становится дорогой, страдает бизнес компании.

Что же касается самолетостроения, то недавно был показательный случаи с Боингами, если Вы помните. Он отлично вписывается в то, о чем я пытаюсь сказать. Лично я не могу себе позволить делать такие продукты.
Потребителю качество становится важно со временем. Но не на старте технологии, когда требования еще не сформированы. Компании, которые это не предусмотрели изначально, сталкиваются с трудностями вплоть до полной замены своего продукта.

У самолетов, автомобилей уже закат подкрадывается. Там развиваться некуда. Рынок стабилен, а производители не способны работать в таких условиях. А Боингу не хватило денег на рефакторинг.
И в случае, когда из-за качества кода, разработка под новые требования становится дорогой, страдает бизнес компании.

Может, вы и не знали, но бизнес компании в первую очередь страдает на этапе разработки нового продукта, когда денег от клиентов еще нет и продукта, который можно продавать, тоже, а зарплаты платить надо. Это огромный минус по деньгам — нужно искать инвесторов, брать кредиты и в итоге бюджет не резиновый, а за идею работают только гики.
О каком качестве продукта можно говорить на этом этапе? Конечно, если у вас денег и времени вагон, то можете попробовать. Но о первом я уже написал выше, а о втором вы узнаете от конкурентов, когда выйдете на рынок со своим качественным продуктом, но ваша ниша будет занята куда менее качественным, но зато на полгода ранее вышедшим конкурентом.

Так в этом же и состоит искусство быть хорошим программистом и прекрасным менеджером: найти тонкую грань между "очень правильно, но никогда" и "хлоп-хлоп и в продакшн".


Прочитать книжку по AGILE или любой другой аббревиатуре много ума не надо — это же нужно еще и в текущую реальность интегрировать.

UFO just landed and posted this here
То, что Вы делаете называется прототипированием. Прототип и не должен быть идеальным, это противоречит его назначению. Тут, с моей точки зрения все окей. Другое дело, что его в продакшн тащить нельзя.

Это больше похоже на MVP, если планируется на реальных пользователях тестировать, а не инвесторам или фокус-группе показать.

Есть ещё ситуации, когда менеджмент вроде понимает, что костыли (хоть в коде, хоть в процессах) — зло, и даже обещает, что будем исправлять, но либо вообще дело до этого не доходит, или доходит формально, но ерунда какая-то получается по разным причинам

Конечно бывает, но это не повод не работать над качеством. Лучше понемного, но постоянно, чем много, но никогда.

Когда долг наращивается быстрее чем погашается, то какое-то время можно протянуть на вере в "скоро будет", какое-то рефакторить и т. п… в личное время или затягивая задачи, а потом уже руки опускаются…

Происходит это потому, что менеджеры чаще всего ни черта не понимают в разработке.

Мне кажется, вы не правы. Происходит это все потому, что чаще всего, такой подход устраивать бизнес. То есть, бизнес устраивать то, что через 3-5 лет код нужно будет выкинуть. Потому что при разумном подходе у них будут деньги на "выкинуть".

Я считаю, что при разумном подходе, эти деньги «на выкинуть» можно использовать намного выгоднее.

Это очень философский вопрос. Вам нужно быть на 100% уверенным в своем продукте, что бы строить такие долгосрочные перспективы. Это далеко не всегда возможно.

полностью согласен.

Спасибо Коля! Таких материалов побольше, их явно не хватает. Молодец!

А почему контроллер ларавеловский на кдпв?

Код плохой, потому что это выгоднее чаще всего для бизнеса, чем хороший код (но писать больше времени, нанимать более дорогих разработчиков).

Там где для бизнеса выгоднее хороший код (код в сердечных стимуляторах, в ракетах), он как правило намного лучше.

Ошибки менеджеры допускают по разным причинам, у меня например все были из разработчиков. Все. 25 лет разработки и 8 фирм. Больших международных и маленьких стартапов.
Чаще всего из за недостатка опыта и неуверенности в себе.

Не обобщайте
Код плохой, потому что это выгоднее чаще всего для бизнеса, чем хороший код — это частый, но недальновидный подход.

у меня например все были из разработчиков. Все. 25 лет разработки и 8 фирм
Либо Вам чертовски повезло, либо я неудачник.
Код это биты и байты. Для клиента надо, чтобы продукт решал проблему. Как это сделано внутри для него неважно. Это имеет значение только с точки зрения экономики производства.
Вы уделили этому внимание, потому, что знаете «внутренность» процесса разработки. В качестве управжнения возьмите другую область. Например, железо.

Пример: мышки с usb приемником. Возражение на выбранную технологию: «Это плохое решение, приемники будут теряться. Надо использовать Bluetooth. Давайте переходить на Bluetooth».

Техническое решение: переход на Bluetooth.
Административное решение 1: продажа универсальных приемников
Административное решени 2: бесплатная отправка клиентам утерянных приемников.

Все мы знаем, что обе модели существуют сейчас и успешны.
По моему опыту (почти 15 лет), если проект круто спроектирован, идеально написан и покрыт тестами, то он мертвый и никому не нужен. Как правило, это проекты написанные ради освоения бюджета, успешно сданные и положенные в стол. А живые проекты, которыми пользуются, они внутри далеко не идеальны (это мягко говоря), по крайней мере по моему опыту. Возможно, у кого-то есть другие примеры, буду рад почитать.

Пока ваш комментарий оказался самым близким к моему опыту. Я могу это объяснить лишь одним: деньгами. Когда уже получил бюджет, то на продукт уже пофигу. И тут уже все зависит от философских взглядов разработчиков. А вот если деньги будут появляться только по результатам работ, то первый же заработанный доллар в один миг стирает все декларации о стремлении к лучшим практикам. "Клиент готов платить за функционал, а не код". И практика показывает что большинство менеджеров выбирает поиграть в рулетку "а вот мне повезет и без ваших лишних затрат на так называемое качество".
Но я бы не переживал, на самом деле. Ведь реально всех все устраивает. До поры до времени...

В хороших продуктах есть стратегия управления техдолгом. Разные конкретные варианты, но суть такова, что его наличие признаётся проблемой и выделяются (или планируется выделять) какие-то ресурсы на его снижение или хотя бы на поддержание на приемлемом уровне.

Разработчики — дорогой ресурс. Если проект развивается — делать идеально mvp невыгодно, куда выгоднее проверить больше гипотез.
Если mvp показал результаты — можно либо улучшать его либо сразу распространить на всех.


Куда критичнее сливание в унитаз кучи человеко-часов из-за нечеткости требований, смены ТЗ в процессе работы/перед релизом. Отсутствие макетов до начала разработки.


А критичные места если вылезут — их как раз оптимизировать больших проблем не составит, если код изначально писался более менее адекватно. Нужно просто желательно при декомпозиции/разработке их наличие явно указать, если конечно, они не внезапны.

Похоже на выводы по одному опыту. Продукты сделаны настолько качественно, насколько это требуется. Есть ведь разница между требованиями к Notepad и RTS системам самолета или ПО для медицинских систем. Так же есть стоимость исправления ошибки. Стоимость тестирования.
И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
Это хорошо, что в Вашей профессиональной жизни Вам встречались только те, кому было не наплевать на результаты их работы. Считаю это показателем того, что Вам самому не наплевать и Вы уважаете себя и не собираетесь мириться с плохим качеством продукта и его программной базы.

На деле ситуация выглядит абсолютно по-другому: и в России, и в Германии, и в Америке. Говорю на основании собственного опыта и наблюдений.
Я все же попытаюсь переубедить. На мой взгляд отсутствие внутренней коммуникации воспринимается как «всем наплевать». Например, отказ продукт менеджера менять устаревшую технологию на новую без объяснения считается «накоплением технического долга». А на самом деле замена технологии сейчас стоит условно 1000 копеек, приносит 0 копеек (технологии никогда не продаются). При этом на 1000 копеек мы можем сделать фичу, которая принесет 5000, а убытки от старой технологии будут 2000. Мы в плюсе, заняли нишу, и есть еще средства на переписывание.
Какой продукт Вы сами считаете сделанным идеально или близким к идеалу?

Скорее такой ктаегорический отказ считается "списанием техдолга как безнадежного" — "нам всю жизнт с этим жить" :(. При этом замена технологии может и не приносит денег непосредственно, но они продаются на, например, рынке труда, в том числе каждый день текущей команде и рано или поздно вы, как мененджер, услышите "я ухожу/поднимите заметно зарплату, потому что мы работаем со страрьём".

Да, с ним можно жить. Но я не считаю обновление технологии в деньгах. Это трудно предсказуемо. Я пробовал это делать, как мне кажется, в более простом случае: влиянии наличия одного продукта в портфеле на продажи другого. В итоге отказался считать такой «наведенный» доход. Только прямые цифры.

Переход на новую технологию может наоборот принести убытки. Пример из головы, выбор Windows Workflow Foundation. В момент презентации технология казалась перспективной.

Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.

Как потребитель, какой продукт, или товар вы бы купили, если используемая в нем технология была другой?
Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.

Как по мне, то внедрение новых и методологий, и технологий — это инструменты риск-менеджмента по снижению разнообразных рисков. Большинству айтишников они на базовом интуитивном уровне знакомы хотя бы на уровне "сначала подождать первого сервис-пака, потом обновляться"

Потому что бизнесу бывает даже достаточно прототипа, чтобы закрыть потребность. Вообще, проблема «хорошего кода» проистекает из попытки предвидеть требования в будущем. Если за аксиому взять, что никаких новых требований к продукту не будет — то любой работающий сейчас код хорош и нет смысла платить больше. А еще чем-то эта проблема сродни premature optimization — крайне сложно угадать узкие места, а оптимизировать все подряд — это зря тратить деньги.
Имхо, тут совокупная ситуация на рынке ПО смещается в сторону «плохого кода» потому что:
а) горизонт планирования российского бизнеса мизерный. Обычно 6-12 месяцев. Все, что не окупится за это время — скорее всего не окупится никогда. Поэтому и выгода в течение 3-5 лет от хорошего кода — чаще всего призрачна для бизнеса.
б) бизнес или конечные пользователи хотят больше фич прямо сейчас. И не согласны ждать завтра с хорошей архитектурой. И согласны даже мириться с некритичными багами.

Статья ни о чем, потому что по сути переливаем из пустого в порожнее. Типичный принцип Парето — 80% задач закрываются 20% усилий и 80% дохода получается 20% функционала. А дальше… А дальше нужно просто сделать так, чтобы ты был впереди конкурентов или их попросту не было — и можно пузырь надувать дальше.


Отдельная история, как правильно заметили, это эксперименты и прототипирование. Когда не нужно делать "идеально", потому что в продакшен это никогда не пойдет, а если гипотеза подтвердится — нужно просто взять и переписать все "по науке", чтобы потом не было мучительно больно

На практике часто если гипотеза подтверждается, то появляется ещё одна, которую надо срочно подтвердить. И даже уловки типа написать прототип/MVP вообще на другой платформе могут не помочь. Посадят всю команду учить новый язык/фреймворк/экосистему, которые ты выбрал потому что хотел гарантий, что на продакшен это 100% не пойдёт

Будут все учить Хаскель. Оно полезно, конечно, для многих, но цель "выкинуть прототип" достигнута не будет.

UFO just landed and posted this here
Автор прав хотя-бы в том, что разработчики в своем стремлении сделать внутреннее устройство продукта надёжным, стабильно сопровождаемым и предсказуемым постоянно попадают в дурацкое положение. Уже не раз делались выводы, что серебряной пули не существует.

Удивляться тут нечему. На одну техническую проблему тонны языков программирования с сопутствующими фреймворками. Возможности комбинирования инструментов разработки друг с другом рождают новые профессии аля FullStack-developer конкретного стэка. С учетом того, что в IT всё новое предпочитают превращать в хайп(иначе не продвинешь), под влиянием моды довольно качественные инструменты вытесняются модными, не оставляя времени разработчикам на выработку эффективных методик работы с выбранным ранее инструментом. Разработчики со студенческой скамьи становятся похожими на Элочку Щукину, стремясь угнаться за последним словом моды которую формируют американские гиганты индустрии(Planned obsolescence in action). Проблема использования инструментов разработки не по назначению существует и она огромна.

Менеджеры никогда не будут стремиться понять эту кашу из фреймворков. Для них группа подчиненных разработчиков с определенными техническими навыками это такой же инструмент решения проблем (только человеческий) как и стек технологий для самого разработчика. Менеджеры ожидают высокой скорости отклика, производительности и прочих потенций от своих «инструментов». И большие расходы им не очень интересны.

Ну, им надо учитывать, что без перехода на "модные" технические инструменты им надо всё больше платить человеческим ресурсам или рискуют остаться сосвем без них.

Sign up to leave a comment.

Articles