Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 10
Я видел исходный код драйвера WiFi от одного крупного производителя чипов, Название не скажу, с меня взали слово не разглашать.
Там было Фсё. С большой буквы “Ф”. Своя реализация точки доступа. Написанная независимо от hostapd. Своя реализация клиента, не основанная на wpa_supplicant. Ну и разумеется, аппаратные драйвера под несколько платформ.
Я насчитал 6 реализаций одного и того же. Совпадающих почти строка в строку, с мелкими отличиями. Всё это было в одном проекте, разделённое условной компиляцией. Даже по файлам не было разделено.
Возможно, там было больше копий, но мне попались на глаза только 6.
Понять, какой экземпляр используется в какой конфигурации, было невозможно. Даже собрать это чудо было подвигом.
У компании был принцип: при появлении новой конфигурации используется та же кодовая база, но сборки под уже выпущенные конфигурации трогать нельзя. Поэтому всё просто дублировалось, и изменения шли в новую копию. Очень похожие, но немного различающиеся копии постепенно накапливались в единой кодовой базе.
По-моему, этот код был образцовым воплощением принципов, изложенных в данной статье.
Это был код, про который говорят, что он вызывает рак глаз. Когда я взялся за этот проект, мне казалось, что получить NNNN баксов за исправление небольшой ошибки - удачная сделка. Потом пожалел 10 раз, но отказаться уже было нельзя, потому, что это - вопрос чести. Ошибку, кстати, поправил - вслепую, без возможности проверить, потому, что железку соответствующую мне не дали. Но больше - ни за что, никогда.
В диаграмме вы забыли указать, в какой момент надо уволиться, и оставить вот это все в поддержку новым бедолагам.
Если что-то пошло не так — мгновенно откатываем флаг
Через пару релизов откатиться не сможет: зависимости сломаны. Потому, у нас есть правило: фичафлаги удаляем через 2 релиза. И вообще, это плохо показало себя в реальности
Версионирование явных контрактов / апи лучше, живёт дольше. Но не вечно. Если хочется археологии - ищи в гит
Технический долг не всегда нужно гасить. Иногда дешевле оставить долг, если его обслуживание дешевле, чем риски рефакторинга
Легаси не создаёт явный контракт с понятными намерениями. Даже если не менять старый код, а пытаться прибить новый код сбоку, то всё может сломаться. Но да, нужен баланс, конечно.
Легаси на критическом пути, новый код зависит от него - рефактори или оберни в явный контракт
Чтобы зафиксировать контракт легаси, нужно его понять. Чтобы понять - фактически нужно провести тот же анализ, что и для рефакторинга. А гарантировать полноту невозможно, потому что часть поведения — случайная, а потребители уже от неё зависят (закон Хайрама). Реалистичный компромисс - characterization tests (как у Физерса в "Working Effectively with Legacy Code"): не пытаешься понять намерения, а фиксируешь фактическое поведение как есть. Не идеально, но хотя бы ловит регрессии при изменениях рядом
Это здравый подход и выглядит так что за ним будущее.
Человеку тяжело искать и читать все версии фич, но последние две недели, когда я готовил новый дизайн под фича-флагом и попутно вносил новые правки, у нейронки Codex 5.4 ни разу не возникло проблем с правкой в двух версиях. Человек бы заплакал, сошел с ума, застрелился бы цианидом и потом уволился, но нейронка отпахала как боженька, даже без особых напоминаний
-- Поправила баг и в старой версии компонента, потому что он независим от дизайна.
Рефакторинг становится дешёвым, поддержка нескольких ветвей кода - не проблема, человеческий фактор чистоты кода уходит на второй план.
Кажется «чистый код» это про то, как не доводить систему до такого состояния, когда вы вынуждены поддерживать несколько систем внутри одной и высчитывать что дороже, стоимость поддержки или рефакторинга. А не про то, о чем вы написали в статье, когда уже поздно пить Борджоми.
По поводу примера со скидкой. У нас делался не только feature toggele, но и вызов обоих веток для небольшого количества клиентов и сравнение, и логирование всех расхождений
И вас нисколько не напрягает то, что в системе есть черные ящики, и ни у кого нет знаний, как они работают? Какие edge cases покрывают? И, главное, какие не покрывают? Они так же могут упасть на чём-то неожиданном, но вот убытки могут быть на порядки выше, если никто не имеет опыта работы с ними.
Knight capital потерял 5 миллиардов за 30 минут, потому что старый код никто не удалил 10 лет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Let well alone»: почему в больших проектах мы перестали удалять код