Комментарии 37
Пассаж про лес достоин оваций!
Читаешь пассаж про лес и понимаешь, что остальное можно смело не читать. Мало того, что совет сделать всё заново как правило безумен, так ещё в этом пассаже написано, что переписывание проекта наново каким-то образом даёт возможность попробовать новые идеи не переписывая половину кодовой базы.
Совет сделать всё заново не всегда безумен — зависит от ситуации. В ряде ситуаций, если этого не сделать, действительно можно погрязнуть в техническом долге и не иметь возможности двигаться вперёд.
Если у вас есть что-то хорошо работающее и не требующее существенных изменений или новых функций — всё относительно хорошо, но если в какой-то момент вы упираетесь в ограничения изначальной архитектуры — всё, вы попали. Простой пример — это IPv4 — вроде как всё ок и отлично работает уже не один десяток лет, но...
Требования постоянно меняются, код в ответ обрастает костылями, т.к. разработан под старые требования.
В какой-то момент код превращается в сложноподдерживаемый кусок ужаса.
Когда появляется возможность, нужно выделить ресурсы и провести полный рефакторинг либо всей архитектуры, либо какой-то отдельной подсистемы.
По ситуации конечно же — зависит от того, насколько все плохо на проекте.
Основная цель всего этого действа — уменьшение сложности.
Убираешь старый ужасный код, который не был предназначен под новые требования, и, с учетом опыта, пишешь новый код, адаптированный конкретно под новые требования.
Получается даже экономия — костыли исчезли, сложность упала, новые изменения делать уже проще.
Потом, через какое-то время цикл повторяется. Потому что код постоянно меняется, живет, обрастает костылями, и периодически должен сбрасывать ставшее лишним, мертвым, неудобным.
Но обычно, по опыту, рефакторинг делают для чего-то мелкого, но критичного. Полный рефакторинг никто не делает, проекты время от времени просто переносят на новую кодовую базу, которую пишут с нуля.
Возможно так выходит дешевле.
Возможно не хотят тратить деньги на поддержку старого, предпочитая вкладывать только в новое.
Возможно выгоднее откладывать потихоньку бюджет на полный перенос, вместо постоянных затрат на рефакторинг.
Возможно тут проявляются фундаментальные недостатки архитектуры. Похоже это единственный более-менее адекватный вариант.
Если сама основа архитектуры сделана неудобно — перестроить все действительно выйдет в несколько раз дороже, чем сделать с нуля, уже с учетом прошлых ошибок и новых требований к системе.
Время от времени так все равно придется делать, если проект будет долго жить, т.к. сразу адекватную архитектуру заложить просто нереально, с учетом постоянно меняющихся требований.
Универсальных и удобных архитектур нет, всегда чем-то приходится жервовать.
Проблема в том, что требования как правило существуют только в коллективном бессознательном команды, занимающейся разработкой продукта. Документация зачастую неполна, какие-то правки вносились в код, чтобы закрыть проблемы, возникающие только у конкретного пользователя, а что-то по документации должно отсутствовать, но его не убрали, потому что на самом деле оно всё ещё нужно.
По хорошему нужно собирать требования заново, а потом заново разрабатывать продукт, но сколько на это нужно денег и времени заранее сказать невозможно. А ведь в это же время придётся ещё и развивать и поддерживать ту версию, которая считается устаревшей и которую хотели сжечь.
Наверное такое имеет смысл делать, если хочется перевести проект с Кобола на, допустим, Джаву, для того, чтобы проект впринципе можно было развивать дальше. Но если код можно рефакторить, а не переписывать, то сделать так дешевле, быстрее и безопаснее.
если происходит хрень с компиляцией или отображением + изначально было выбрано не самое лучшее решение — бывает.
у меня есть софт, который я продаю. маленький софт для маленьких компаний. клиентов от 200 до 300. месячная подписка.
изначально софт писался для себя на питоне (анализ данных + ручки).
первая версия софта — питон без гуи (тупо терминал). однако продавалось
вторая версия — гуи на питоне.
третья — гуи на электроне — с подгрузкой питоновского скомпилированного файлика.
последняя версия пока — большинство вещей переделано на js для визуальности. питоновский файлик еще жив, служит теперь больше для защиты кода, которого жалко, что сопрут. примерно 80% кода с изначального проекта так или иначе переписано.
стоит ли все стирать и массово переписывать — ну врядли.
стоит ли со временем переписывать, оптимизировать — ну да.
совет, конечно, слишком радикальный.
Да, да. И так каждый новый раз! А через полгода — что за дерьмо мы написали....
Больше похоже на гуманитария мечтателя когда такое пишут…
Я уверен, что многие вещи стоит сейчас делать на основе не голого kubernetes, а на основе knative, который работает в kubernetes.
Пользователь knative оперирует небольшим количеством сущностей, имеет большое количество "плюшек".
А "сложности" kubernetes решает уже тот, кто развернул knative. Впрочем, это ведь уже несложно, когда ты успешно развернул knative :)
Насчет сжигания леса, я бы добавил что частота переделки с нуля зависит от инновационности проекта.
Глыбко, йобко, феерично
10 идей, о которых стоит знать всем программистам
Ваша компания — это не Google
Занавес
Боже, судя по комментам — мы обречены.
Никто не собирается следовать советам — простым и правильным в большинстве случаев. Каждый суслик в поле агроном.
И самое страшное — это происходит сплошь и рядом, не только в программировании. Уроки истории никому не интересны. Похоже третья мировая не избежна.
Эта идея заставляет менеджеров нервничать. Она портит настроение владельцам продукта. Она злит программистов. Но «возрождение из пепла» — это совершенно необходимо. Время от времени начинать всё сначала — это хорошо.
Интересно, хоть одна комерческая компания так делала, после 2-20 человеко-лет разработки?
Другое дело что это просто список очевидных вещей. Но если вам вдруг так не кажется, и при этом вы считаете себя разработчиком (возможно крутым), добро пожаловать вон из профессии
Пакетоманьяки. Ради какого-то дополнения строки слева или использования конкурентных фьючерсов/промисов готовы ставить 11-строчные библиотеки на каждый чих, вместо написания алгоритма просто у себя в отдельном файле. Если так хочется готовый код, то возьми и скопируй его себе без зависимости. Но городить милионные зависимости просто потому что «так правильно бэст практис чувак» — это есть безумие.
> 7. Не нужно писать абстракции до тех пор, пока в этом не возникнет реальная необходимость
Да за неиспользования DRY, GRASP, GoF и прочего иногда вас готовы сжечь уже прямо на собеседовании.
если видишь два похожих класса или функции, и при этом они достаточно просты, то подумай о том почему они похожи,
если их похожесть это просто случайность, то лучше оставить все как есть, и не создавать никаких доп. абстракций. Если же они похожи потому что это реально связанные вещи в предметной области, то лучше сделать абстракцию.
Со сложными функциями конечно по другому, сложность всегда хочется где-то спрятать,
Многие могут сказать «мы всё это и так знали», но «суть не в том, что мы знаем, а в том, чем мы пользуемся».
Спасибо за статью! :-)
Нужно сделать что-то простое, но гениальное
архитектурный ребут?
10 идей, о которых стоит знать всем программистам