Привет всем! Сижу тут на ревью очередного легаси-проекта и поймала себя на мысли: когда мы фиксим баг, мы часто не удаляем его первопричину, а просто обходим её сбоку. И вот этот обходной костыль потом живёт годами, обрастает новыми слоями, и в итоге мы имеем код, где 30% логики — это защита от ошибок, которые уже давно не могут произойти. Кто-нибудь пробовал вычищать такие «исторические слои» и что из этого вышло?
Лично я в последнем проекте нашла баг 2018 года, который был замаскирован под «фичу». Разработчик тогда добавил костыль, чтобы обойти другой баг, а теперь этот костыль ломает новый функционал. И вот вопрос: как вы решаете, когда пора удалять старые обходные пути, а когда лучше не трогать, чтобы не развалить всё? Может, у кого-то есть методика или чек-лист?
И второй вопрос: как вы относитесь к практике писать тесты на сам костыль, чтобы зафиксировать его поведение, или это только усугубляет ситуацию? Жду ваших историй, особенно с примерами, как вы вытаскивали такие «священные коровы» из кодовой базы! 🐄🔍
👍 1
Охай, ну ты прям в душу мне зашла с этим «историческим слоем»! 😄 У меня самого в пет-проекте до сих пор живёт костыль 2021 года, который я поставил, чтобы обойти баг в сторонней библиотеке. Библиотеку давно обновил, а костыль остался — просто потому что «работает же». Так что я скорее за то, чтобы вычищать, но с умом.
Насчёт чек-листа — у меня правило простое: если я не могу за 10 минут объяснить, от какого именно бага защищает этот код и как воспроизвести ту ошибку, значит, пора его выпиливать. А тесты на сам костыль — это зло, честно. Ты просто фиксируешь поведение, которое вообще не должно существовать, и потом с этим живёшь вечно. Лучше написать тест на то, что фича работает без костыля, и потихоньку его удалять. А если развалится — значит, и правда был нужен, но хотя бы будешь знать зачем! 🐛☕
🚫 1
Ага, «работает же» — классика жанра. Только вот «работает» у тебя до первого обновления той самой сторонней библиотеки, где этот костыль теперь начнёт конфликтовать с новым API. И тогда ты будешь не «вычищать с умом», а разгребать дерьмо, которое само себя законсервировало.
С чек-листом согласен на 80%, но «10 минут объяснить» — это слишком мягко. У меня правило жёстче: если я не могу навскидку назвать точную версию библиотеки и строку, где срабатывал баг, — костыль летит в топку без разговоров. А вот про тесты на костыль — херня. Тест на «фича работает без костыля» — это, конечно, красиво, но он не покажет, почему он был нужен, когда ты через год полезешь в git blame и увидишь там три коммита с «fix» и один с «WTF». Лучше уж тест на костыль, чем потом гадать, что именно ты обходил и почему без этого всё разваливается. Но да, выпиливать надо. Только сначала — задокументировать, а не «потихоньку удалять».
👎 1
Ну давай разберем. Сразу скажу: тезис красивый, но по сути — это смесь байки и удобного самооправдания. Баг живет не дольше кода, он просто мутирует в документацию и бизнес-логику. Пока ты не удалил строчку, которая вызывает падение, — это баг. Как только ты решил «не трогать, потому что сломается смежный модуль» — это уже легаси-архитектура, за которую платят зарплату. Код умирает в момент мерджа, а баг — это процесс, у него нет срока жизни, у него есть цикл полураспада, который продлевают сами разработчики, боясь рефакторинга.
Поэтому я скорее не согласен с формулировкой. Баги не живут дольше кода — код живёт, пока его не трогают, а баг живёт, пока его выгодно игнорировать. Вопрос не в возрасте, а в том, кто платит за простой. Как только стоимость фикса становится ниже стоимости сопутствующего героизма — баг исчезает за один спринт. Всё остальное — это не мистика, это приоритеты менеджмента и трусость команды.
💡 1
