Comments 24
Не раз сталкивалась с ситуацией, когда инженеры (как опытные, так и нет), пытались переписать "легаси" код в проекте, а потом оказывалась, что, вообще говоря, все было написано по делу :)
В моей практике, модификация устоявшегося кода (написанного другими) обычно включала следующие этапы:
попытка понять насколько новый код легко интегрируется со старым (и частое разочарование ввиду невозможности это сделать легко и быстро)
неприятие существующего ("легаси") кода и желание его переписать (обычно это быстро проходит)
этап изучение существующего кода (как правило, до уровня на котором становится понятно какие есть варианты для внесения изменений)
оценка вариантов (трудоемкость, потенциальные риски)
рефакторинг старого кода ц целью уменьшения резистивности кода для внесения новой функциональности (требуется в большинстве случаев)
тестирование переработанного кода
внесение планируемых изменений
Полностью поддержу то что написано в статье.
И часто дела обстоят еще хуже. Ты непрерывно пилишь эту огромную кодовую базу на компоненты, удаляешь старый код, разбиваешь зависимости только для того чтобы стоять на месте. Это позволяет добиться только того, что сложность не сильно быстро растет. Потому что все новые фичи, исправления ошибок только наращивают и сложность, и кодовую базу.
Здесь нужно все время бежать только для того чтобы остаться на месте. Чтобы двигаться вперед нужно бежать вдвое быстрее!
А нельзя написать логику классификации юзеров один раз, чтобы «искушения» (сделать свою обработку типа пользователя) вообще не появлялось? Smells like a DRY violation. Вот что настоящий смертный грех, независимо от величины проекта.
За годы у вас появится много сценариев, на которые заранее не заложиться.
Сначала у вас только менеджеры и клиенты. Потом интеграции (разные). Где-то там же может появится "системный" пользователь для автоматизированных обработок. Потом чат-бот появится. Завтра бизнес захочет ИИ с какими-то доступами иметь.
И одной только классификацией (к чему она тут?) не обойтись в любом случае. Где-то завязки будут на неявное поведение, где-то будет строгий контракт описанный в ТЗ, где-то будет версионирование под мобильные приложения и их версии, где-то будут фичи для бизнеса которые уродские с точки зрения кода, но нужны.
Что значит «к чему она тут»? Это постановка задачи! Не возвращать сразу 403, а делать весь комплекс приседаний, ведь среди юзеров могут быть боты и кто-то там ещё. Вопрос, а почему не вынести это всё в одно место и не вызывать автоматически, чтобы при разработке нового модуля у автора просто не было возможности всё испортить? Вместо того, чтобы давать советы смотреть, как у других (по сути дела, копипастить).
А аргумент про «многие годы» и «тысячи программистов» меня не убеждает. Я видел, как это происходит. Пока проект маленький — никто не хочет закладывать правильную архитектуру, потому что и так сойдёт, для нашего маленького проекта сложная архитектура не нужна. Когда проект вырастает, никто не хочет закладывать правильную архитектуру, потому что проект уже слишком большой. Плохим танцорам всё время что-то мешает.
Плохим танцорам всё время что-то мешает.
Пока хорошие танцоры предусматривают все возможные варианты и случаи, плохие уже запилили десяток других кривых косых проектов, один из них выстрелил и принес деньги. А бизнесу глубоко фиолетово насколько в вашем коде все предусмотрено или не предусмотрено, ему нужны только деньги. В итоге плохой танцор молодец, а хороший так и сидит что-то пилит никому не нужное.
Это мы конечно не говорим про условный гугл, мы говорим про условного ИП Пупкина, у которого есть какой то бизнес, который благодаря плохим танцорам будет развиваться в какое нибудь ООО
Какая глубокая мысль: за деньги делать говно. Никто бы не догадался. Только одна проблема — автор не учит нас моральной гибкости, он учит правильно писать код.
Если код выполняет свою задачу и приносит деньги это не говно, это рабочий инструмент. А автор учит разбирать авгиевы конюшни и какие шаги по возможности следует предпринимать. Ну и вообще, при чем тут автор? Я же отвечал на ваш комментарий о том, что сразу надо делать правильно. Может и надо в идеальном мире, было бы хорошо. Да вот я живу в мире дедлайнов и всем по барабану как я напишу, им надо чтоб работало, ещё вчера.
Это хорошо, если постановку задачи кто-то готов изначально дать хорошую (или вы обладаете опытом её качественно выполнить). Но иногда таких людей на проекте нет, либо просто требования меняются по ходу жизни проекта.
Ваше утверждение звучит как "делай хорошо" и я с ним согласен, но реальность обычно чуть хуже выглядит и получается обычно "хорошо на момент реализации", а не "хорошо на всю жизнь проекта".
Ваше утверждение звучит как "делай хорошо" и я с ним согласен
Понимаете, в чём дело. Это принципиальный вопрос, и компромисса тут быть не может. Если вы соглашаетесь с этим, то соглашаетесь и с тем, что автор (его контора) совершил нарушение DRY, но оправдываете его тем, что трудно было не совершить (опыта не было, не успели за изменениями требований, решили, что и так сойдёт и т.п.)
Никто не спорит: трудно. Многие не справляются. Но они сидят на попе ровно, а не пишут статьи: «Не возвращай 403 с ходу, а посмотри (==скопипасти) код у коллег». Я всё ждал (учитывая высокий рейтинг статьи), что мне сейчас объяснят, что я понял автора неправильно. Но пока что, судя по этим ответам, получается, что всё я понял правильно.
Вы хотите хорошо и чтобы все делали хорошо.
Автор рассказывает, как будет на самом деле.
Если вы думаете, что я не видел крупных проектов, где удавалось следить за гигиеной (в том числе, не нарушать DRY), то ошибаетесь. Видел. Такое ведение дел и позволяло подстраиваться под меняющиеся требования, ничего не сломав.
Было ли этим проектам много лет?
Потому что я сталкивался пока только с 3 проектами в 10+ лет и на всех них эта проблема была в разной степени. Да, можно делать лучше, но это сложно и не всегда организационно возможно, что приводит к разным странным решениям, которые разгребают только при появлении проблем.
Тогда у меня один вопрос: с каких это пор люди, страдающие организационной немочью, начали писать статьи об «ошибках инженеров», пропагандируя пользу самоповторов? (Хочу подчеркнуть, что к переводчику у меня претензий нет: он переводит интересные статьи, иногда — [с моей точки зрения] провокационные).
Было ли этим проектам много лет?
Всякие повидал. И многолетние тоже. Однажды работал в проекте, который изначально пилили очень толковые инженеры, а потом он попал в руки карьеристов, индусов и китайцев (бестолочи всякой). Я его читал (без версионного контроля — не было его на нужную глубину), и прям видел: вот тут проходит разделение геологических слоёв. Досюда писали крутые чуваки: заложили DSL, хорошую архитектуру, боролись с самоповторами и т.д. А вот тут — пришли, извиняюсь, обезьяны и продукт ума человеческого начали заменять на хтонический ужас. А потом узнал, что у конторы в прошлом было слияние, и продукт делался изначально другой командой. Но это было видно из кода! Невооружённым взглядом!
Самое забавное, что новая команда очень гордилась своим вкладом. Особенно, почему-то, тем что объём исходников перевалил за гигабайт. Этого стыдиться надо (явно перераздутая кодебаза), а они гордились. Трудно не провести параллели с тем, как этот дядька гордо учит нарушать DRY.
Я понимаю, о чём вы. Но к сожалению, работаем не в одиночку, работаем на деньги бизнеса и в условиях конкуренции. Не всегда выходит у всех делать хорошо. И работать чаще приходится с тем что уже написано. Я лично стараюсь делать код лучше, но на каждую фичу - не хватает ни сил ни желания. Поэтому я со статьей согласен - такое бывает и надо учитывать. Хотелось бы делать лучше, но это уже как получится.
Мешает меркантильная математика. На рефакторинг большого нужно время и это время стоит денег. А кроме этого в точке есть куча задач от бизнеса, который не хочет ждать, и считает что новые ыичи принесут больше денег, т.е. это плюс, а рефакторинг только сожрет деньги - это минус. А зп у бизнесов обычно растет, если есть плюс.
Ну так, тогда так и надо писать: вы оказались в крупной говноконторе. Рефакторить вам не дадут. Проект — мрачный ужас. Нормализовать кодебазу («любая задача решается ровно один раз») вам не дадут. Но хотя бы копипасьте код у коллег, чтобы не было конфликтов, а не сочиняйте своё заново.
С такими поправками вопросов не будет. Но и пафосно поучить про «ошибки инженеров» уже не получится.
" в крупных кодовых базах есть множество закопанных мин. Например, вы можете и не знать, что в кодовой базе есть концепция "
Потому что эта концепция не описана. Не только нет документации и разработчика, который что-то помнит. Нет даже типов, нет спецификаций API, комментариев, ничего нет ибо "хорошему коду комментарии не нужны". И приходится чтобы понять лезть в код, в отладку, додумывать а что же тут должно быть.
А потом эти же люди мне говорят, что чистая архитектура и что статическая типизация слишком увеличивают трудоемкость написания.
Полностью солидарен с автором. В любых священных войнах по поводу выбора технологии или фреймворка - я на стороне консистентности, даже если выбор не мой личный фаворит. В долгосроке разобравшись с тонкими нюансами существующего решения его можно переписать на новое или использовать классический популярный фреймворк (желательно одним махом или за короткий срок, чтобы не создавать риск параллельно существующих решений). Но этим не должны заниматься люди с порога, потому что в большинстве случаев это все уйдет не дальше прототипов, которые будут бельмом выбиваться из общей канвы.
Еще понравилось это предложение
Я видел примеры успешного разбиения крупных кодовых баз, но никогда не было так, чтобы этим занималась команда, ещё не освоившая в совершенстве выпуск фич внутри этих кодовых баз.
Действительно, в команды платформы, которые делают общий код и модуляризацию нужно либо переходить из фиче-команд, либо в случае внешнего найма работа в компании должна начинаться с онбординга в фиче-команде хотя бы месяц-два. Иначе, какой бы не был крутой опыт и бэкграунд, неверных доводов о текущей ситуации не избежать.
Я обычно называю согласованность «принципом обезличенного кода» - это значит, что должно быть невозможно понять, кто из разработчиков написал код, кроме как по истории коммитов. Да, это часто бывает и копи-паста, и использование не самых удачных решений. Зато даже через два года, когда я уже забуду, что именно я писал, я смогу в этом разобраться, будучи просто погруженным в кодовую базу целиком. Это же упрощает жизнь остальным.
Ошибки инженеров в больших кодовых базах