Comments 72
И если весь код вылизывать сейчас — то вылижут окончательно его к тому моменту, когда этот код будет уже не нужен.
Есть, конечно, фундаментальные проекты (вроде nginx-а), которым текущая тенденция нипочём, но большая часть бизнес-кода живёт так.
(и я не разработчик, я вообще динозавр-админ — просто смотрю, как часто проекты схлопываются или переписываются целиком по каким-либо причинам).
Чтобы переписывали потому что «ну реально старое барахло же, давайте перепишем, а то фичу воткнуть не получается» (а не просто немножечко раскидаем код по другим файлам), и после переписывания оно делало ровно то же — я такое один раз за 5 лет навскидку вспомнил.
Соглашусь с предыдущим человеком. Видел пару небольших проектов, которые "ну полный пи… ц" и реально проще было бы переписать уже, но нет, всё равно равно дорабатывали.
Переписывают, всё таки когда уже идейно/морально всё устарело.
Или N лет создавалось на одной технологии, а сейчас проще написать с нуля используя новый стек технологии.
Вот и получается что срок кода около 5 лет (2 смены команды).
Это тоже разновидность долга. Если не используете современные технологии, то с каждым днём вам всё труднее будет не то, что расширять команду, а даже сохранять имеющийся штат. Имеющиеся люди будут требовать всё больше денег, чтобы остаться (компенсацию за технологическое "болото", практически исключающее возможность освоения новых технологий на рабочем месте), а то и просто уходить без требований, а новые так же будут просить больше денег за "легаси" или их квалификация будет заметно ниже.
С другой стороны, переписывать весь проект с нуля — не единственный способ уменьшать такой долг. Грамотная изначальная архитектура позволит с минимальными издержками переписывать проект по частям.
Вот только о том что при планировании системы надо предусмотреть условия и порядок её вывода из эксплуатации апологеты
+++++ золотые слова — я тоже про это всегда говорю, но эффективным менеджерам и грамотным архитекторам это пофиг, т.к. это событие в очень далеком будущем
Так переписывание продукта на новый стэк и/или новую архитектуру и есть вывод текущей системы из эксплуатации, синхронизированный с вводом новой системы. Я к тому, что система изначально может предусматривать поэтапный вывод.
Причем это касается не только компонентов, но и технологий и ресурсов. Бывает, что отсутствие документации + разработчик ушел = компонент вдруг устарел.
Это все должно закладываться в архитектуре вместе с методами борьбы с этой болезнью.
"зло" вам, на секундочку, зарплату платит
идеально вылизанный код никому (кроме чувства прекрасного у программистов) не нужен. нужно, чтоб работало
хуже того: идеально вылизанного кода в принципе не существует как понятия. То, что считалось верхом вылизывания и оптимизации четверть века назад сейчас воспринимается как трудноподдерживаемый набор грязных хаков, и наоборот хороший годный современный код с позиции тех времён может восприниматься как overengeniered. Что будет ещё через четверть века вам никто сейчас не скажет
Так вот, первый проект развивать дальше уже невозможно, а клиенты надо сказать, требуют современных решений. Я склонен поставить на то, что компания скоро схлопнется. Второй был успешно портирован на более современные версии программного обеспечения и фреймворков и на данный момент соответствует всем запросам потребителей.
Дело в том, что по 2 проектам делать выводы обо всех остальны — дурная идея.
На успех бизнеса влияет ещё множество факторов, которые вы не учли в этом примере. Да и компания ещё не схлопнулась всё же, по вашим же словам. Вы, кстати, поставьте, если так уверены, чтоб пустословом не прослыть.
1. Я Вам привел один из свежих примеров в моей практике, нигде в моем комментарии не было сказано, что это единственное, что я видел в своей профессиональной жизни.
2. Факторов много, но это не повод делать плохо. Это то, что я также хочу донести.
3. Да я и поставил, управляющий в курсе моего мнения.
Вдобавок, при расширении штата или изменении состава разработчиков, чистый код позволит быстрее новому человеку влиться в процесс, что, опять же, значительно лучше для бизнеса.
А что касается старого кода, на то есть код-ревью и рефакторинг, когда с течением времени необходимо изменять проблемные участки на актуальные решения.
Дак, у вас долга в проекте уже больше чем кода.
Я считаю, что нужно для себя выработать разумное подмножество того, что использовать. Тогда возможно есть шанс.
Например, смешивать в REST уровень HTTP (в данном случае транспортный) и прикладной (логику приложения) я считаю неправильным.
А тут особо не важно. Просто объявляем партнёрам, REST HTTP (крайне редкий зверь) у нас или REST over HTTP.
А вообще для того, о чем вы говорите, придумали JSON RPC
А это не ендпоинт API. Тут 404 вполне уместна.
JSON RPC — лишь один из вариантов API c HTTP в качестве транспорта. Причём его сложно назвать REST
Принято в REST HTTP (редкий зверь) и вариациях на его тему (очень часто), но в REST (или что угодно, JSON RPC, GraphQL, SOAP и т. п.) over HTTP это вовсе не обязательно.
В общем все эти статусы и прочую семантику HTTP имеет смысл активно поддерживать, только если использовать HTTP в качестве протокола прикладного уровня, когда архитектура приложения поддерживает концепцию ресурсов как основную и большинство операций над ними сводится к CRUD. Ну или вам хочется максимально использовать имеющуюся глобальную HTTP инфраструктуру
Уже проходили в других областях. С самолетами, автомобилями, сотовыми телефонами, смартфонами…
Каждый бизнесмен пытается влезть на новый и растущий рынок, не обладая достаточными знаниями. Область новая, квалифицированных технарей еще нету в нужном количестве, а квалифицированных
А качество продукта на этом этапе развития не важно никому, даже потребителю.
Что же касается самолетостроения, то недавно был показательный случаи с Боингами, если Вы помните. Он отлично вписывается в то, о чем я пытаюсь сказать. Лично я не могу себе позволить делать такие продукты.
У самолетов, автомобилей уже закат подкрадывается. Там развиваться некуда. Рынок стабилен, а производители не способны работать в таких условиях. А Боингу не хватило денег на рефакторинг.
И в случае, когда из-за качества кода, разработка под новые требования становится дорогой, страдает бизнес компании.
Может, вы и не знали, но бизнес компании в первую очередь страдает на этапе разработки нового продукта, когда денег от клиентов еще нет и продукта, который можно продавать, тоже, а зарплаты платить надо. Это огромный минус по деньгам — нужно искать инвесторов, брать кредиты и в итоге бюджет не резиновый, а за идею работают только гики.
О каком качестве продукта можно говорить на этом этапе? Конечно, если у вас денег и времени вагон, то можете попробовать. Но о первом я уже написал выше, а о втором вы узнаете от конкурентов, когда выйдете на рынок со своим качественным продуктом, но ваша ниша будет занята куда менее качественным, но зато на полгода ранее вышедшим конкурентом.
Так в этом же и состоит искусство быть хорошим программистом и прекрасным менеджером: найти тонкую грань между "очень правильно, но никогда" и "хлоп-хлоп и в продакшн".
Прочитать книжку по AGILE или любой другой аббревиатуре много ума не надо — это же нужно еще и в текущую реальность интегрировать.
Есть ещё ситуации, когда менеджмент вроде понимает, что костыли (хоть в коде, хоть в процессах) — зло, и даже обещает, что будем исправлять, но либо вообще дело до этого не доходит, или доходит формально, но ерунда какая-то получается по разным причинам
Происходит это потому, что менеджеры чаще всего ни черта не понимают в разработке.
Мне кажется, вы не правы. Происходит это все потому, что чаще всего, такой подход устраивать бизнес. То есть, бизнес устраивать то, что через 3-5 лет код нужно будет выкинуть. Потому что при разумном подходе у них будут деньги на "выкинуть".
Спасибо Коля! Таких материалов побольше, их явно не хватает. Молодец!
А почему контроллер ларавеловский на кдпв?
Там где для бизнеса выгоднее хороший код (код в сердечных стимуляторах, в ракетах), он как правило намного лучше.
Ошибки менеджеры допускают по разным причинам, у меня например все были из разработчиков. Все. 25 лет разработки и 8 фирм. Больших международных и маленьких стартапов.
Чаще всего из за недостатка опыта и неуверенности в себе.
Не обобщайте
у меня например все были из разработчиков. Все. 25 лет разработки и 8 фирм
Либо Вам чертовски повезло, либо я неудачник.
Вы уделили этому внимание, потому, что знаете «внутренность» процесса разработки. В качестве управжнения возьмите другую область. Например, железо.
Пример: мышки с usb приемником. Возражение на выбранную технологию: «Это плохое решение, приемники будут теряться. Надо использовать Bluetooth. Давайте переходить на Bluetooth».
Техническое решение: переход на Bluetooth.
Административное решение 1: продажа универсальных приемников
Административное решени 2: бесплатная отправка клиентам утерянных приемников.
Все мы знаем, что обе модели существуют сейчас и успешны.
Пока ваш комментарий оказался самым близким к моему опыту. Я могу это объяснить лишь одним: деньгами. Когда уже получил бюджет, то на продукт уже пофигу. И тут уже все зависит от философских взглядов разработчиков. А вот если деньги будут появляться только по результатам работ, то первый же заработанный доллар в один миг стирает все декларации о стремлении к лучшим практикам. "Клиент готов платить за функционал, а не код". И практика показывает что большинство менеджеров выбирает поиграть в рулетку "а вот мне повезет и без ваших лишних затрат на так называемое качество".
Но я бы не переживал, на самом деле. Ведь реально всех все устраивает. До поры до времени...
В хороших продуктах есть стратегия управления техдолгом. Разные конкретные варианты, но суть такова, что его наличие признаётся проблемой и выделяются (или планируется выделять) какие-то ресурсы на его снижение или хотя бы на поддержание на приемлемом уровне.
Разработчики — дорогой ресурс. Если проект развивается — делать идеально mvp невыгодно, куда выгоднее проверить больше гипотез.
Если mvp показал результаты — можно либо улучшать его либо сразу распространить на всех.
Куда критичнее сливание в унитаз кучи человеко-часов из-за нечеткости требований, смены ТЗ в процессе работы/перед релизом. Отсутствие макетов до начала разработки.
А критичные места если вылезут — их как раз оптимизировать больших проблем не составит, если код изначально писался более менее адекватно. Нужно просто желательно при декомпозиции/разработке их наличие явно указать, если конечно, они не внезапны.
И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
На деле ситуация выглядит абсолютно по-другому: и в России, и в Германии, и в Америке. Говорю на основании собственного опыта и наблюдений.
Какой продукт Вы сами считаете сделанным идеально или близким к идеалу?
Скорее такой ктаегорический отказ считается "списанием техдолга как безнадежного" — "нам всю жизнт с этим жить" :(. При этом замена технологии может и не приносит денег непосредственно, но они продаются на, например, рынке труда, в том числе каждый день текущей команде и рано или поздно вы, как мененджер, услышите "я ухожу/поднимите заметно зарплату, потому что мы работаем со страрьём".
Переход на новую технологию может наоборот принести убытки. Пример из головы, выбор Windows Workflow Foundation. В момент презентации технология казалась перспективной.
Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.
Как потребитель, какой продукт, или товар вы бы купили, если используемая в нем технология была другой?
Переход на новые технологии, процент ошибок, сопровождение продукта, на мой взляд, это больше про риск-менеджмент, а не следование методологиям.
Как по мне, то внедрение новых и методологий, и технологий — это инструменты риск-менеджмента по снижению разнообразных рисков. Большинству айтишников они на базовом интуитивном уровне знакомы хотя бы на уровне "сначала подождать первого сервис-пака, потом обновляться"
Имхо, тут совокупная ситуация на рынке ПО смещается в сторону «плохого кода» потому что:
а) горизонт планирования российского бизнеса мизерный. Обычно 6-12 месяцев. Все, что не окупится за это время — скорее всего не окупится никогда. Поэтому и выгода в течение 3-5 лет от хорошего кода — чаще всего призрачна для бизнеса.
б) бизнес или конечные пользователи хотят больше фич прямо сейчас. И не согласны ждать завтра с хорошей архитектурой. И согласны даже мириться с некритичными багами.
Статья ни о чем, потому что по сути переливаем из пустого в порожнее. Типичный принцип Парето — 80% задач закрываются 20% усилий и 80% дохода получается 20% функционала. А дальше… А дальше нужно просто сделать так, чтобы ты был впереди конкурентов или их попросту не было — и можно пузырь надувать дальше.
Отдельная история, как правильно заметили, это эксперименты и прототипирование. Когда не нужно делать "идеально", потому что в продакшен это никогда не пойдет, а если гипотеза подтвердится — нужно просто взять и переписать все "по науке", чтобы потом не было мучительно больно
На практике часто если гипотеза подтверждается, то появляется ещё одна, которую надо срочно подтвердить. И даже уловки типа написать прототип/MVP вообще на другой платформе могут не помочь. Посадят всю команду учить новый язык/фреймворк/экосистему, которые ты выбрал потому что хотел гарантий, что на продакшен это 100% не пойдёт
Удивляться тут нечему. На одну техническую проблему тонны языков программирования с сопутствующими фреймворками. Возможности комбинирования инструментов разработки друг с другом рождают новые профессии аля FullStack-developer конкретного стэка. С учетом того, что в IT всё новое предпочитают превращать в хайп(иначе не продвинешь), под влиянием моды довольно качественные инструменты вытесняются модными, не оставляя времени разработчикам на выработку эффективных методик работы с выбранным ранее инструментом. Разработчики со студенческой скамьи становятся похожими на Элочку Щукину, стремясь угнаться за последним словом моды которую формируют американские гиганты индустрии(Planned obsolescence in action). Проблема использования инструментов разработки не по назначению существует и она огромна.
Менеджеры никогда не будут стремиться понять эту кашу из фреймворков. Для них группа подчиненных разработчиков с определенными техническими навыками это такой же инструмент решения проблем (только человеческий) как и стек технологий для самого разработчика. Менеджеры ожидают высокой скорости отклика, производительности и прочих потенций от своих «инструментов». И большие расходы им не очень интересны.
Удивительно, что ваш продукт еще работает