Хочу поспорить. 1 если проект больше не развивается и не расширяется, то зачем тогда его улучшать?) 2 принцип "работает - не трогай" не позволяет нормально расширяться системе( 3 если решать задачи абы как за пару часов, то через некоторое время можно получить неподдерживаемые спагетти( 4 заказчик конечно за красоту кода не платит, т.к. он не должен ничего понимать в коде. Он нанимает профессионалов, чтобы они построили ему хорошую систему.

Обычно принцип такой. Если у тебя одноразовый скрипт или ты собираешь прототип, то всеми возможными бест практисами можно пренебречь. Для всех остальных случаев тебе нужно делать так, чтобы система была расширяема и поддерживаема, что включает в себя абстрактное понятие "красивый" код

Если вы так топите за красивый код. То предоставьте свой гит на обозрение. Я бы посмотрел. Вокруг как ни посмотришь, то все прям идеал пишут и говнокодят. Как гит попросишь, то все начинают юлить. Я в вашем гите найду столько говнокода и некрасивого кода, что вы просто охренеете. Можете снять маску идеального кодера и отложить ее на другой случай. Говнокодят абсолютно все и без исключения. То, что для вас красиво, для другого — говнокод.

Причём тут мой гитхаб? Мы обсуждали какие-то базовые подходы, которые не требуют мериться гитхабами. Как ты в гитхабе увидишь кейс "проект больше не поддерживается и не расширяется"?

Для того чтобы писать расширяемый поддерживаемый код надо выполнять несколько практик - solid+тесты+рефакторинг+...

Слова должны подкрепиться делом. Если они не подтверждаются, то это фуфло, порождаемое человеком. Вы за чистоту кода, и я хочу понять, что для вас идеальный код. Может, мой в моем понимании говнокод — это на самом деле чистый код или наоборот. Я хочу увидеть в вашем понимании чистый код. Я даже не удивлен, что вы слились за гит, так как почти все сливаются, так как сут выставить на всеобщее обозрение. Если навешиваете ярлыки про чистоту кода, так нужно соответствовать. Как должно быть, это уже расписано до нас, но на практике ситуация совершенно другая. В школе все по прописям писать тренировались, а пишут аккуратно единицы, кто-то вообще разучился или 2 строчки напишет с трудом. Если доказываете, то покажите, как нужно, чтобы все глянули и убедились, что рукожопы.

Практики они абстрагированы от конкретных языков, и решений. Если непонятна суть этих абстрактных практик, то примеры кода, к сожалению, не помогут(

Про монстра Франкенштейна хорошо сказано😂

А зачем с менеджерами/бизнесом согласовывать отдельно рефакторинг? Ещё некоторые любят согласовывать написание тестов. Не надо так, это нарушение инверсии зависимостей(

Для рефакторинга есть клёвое правило бойскаута, с помощью которого код можно рефачить в процессе разработки фичи. Этот подход считается бэст практисом, который описан всякими динозаврами типа Фаулера

Потому что они трекают время и лезут в микроменеджмент в основном.

Ну трекают и трекают) закладывай в оценку по дефолту чуточку рефакторинга и будет всём щастье)

лучший код тот в котором меньше всего комментариев!

Чтобы через полгода сесть и вообще ничего не понять.

В целом да, главное чтобы легко можно было понять что происходит. Чаще, комментарии нужны к тестам, чтобы можно было проще и быстрее понять что именно проверяется и что происходит.

Как говорилось в одной притче: чужая женщина всегда слаще, так же должно быть и с кодом