​

Я не знаю, был ли у вас, программиста, когда-нибудь опыт сопровождения и модификации связанных функций в проекте, заваленном в «куче дерьма».

Это своего рода волшебное существование, когда класс может иметь тысячи или даже десятки тысяч строк кода, а метод также может иметь сотни или тысячи строк кода.

Тут же вам все равно придется разобраться в бизнес-логике внутри и изменить часть кода.

Иногда параметры строки метода либо имеют более 5 параметров типа, либо напрямую используют тип Map для принятия значений параметров. Вы не знаете, какие параметры будут переданы восходящим потоком, что совершенно сбивает с толку.

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

Это Рефакторинг Навык,Ранее я писал статью о Рефакторингстатьи：Код до рефакторинга и после рефакторинга кода Также было упомянуто, что этот метод может снизить вероятность возникновения ошибок в проекте.

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

Так кто-нибудь знает, как формируется этот код дерьмовой горы?

Мое личное резюме таково, что обычно есть две причины:

Сроки разработки проекта сжаты, а задачи тяжелые.

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

В этом случае уже очень хорошо иметь возможность закончить написание кода. Вы можете себе представить, каким будет код. Основная идея — сделать это как можно быстрее, и код Shishan обрел форму.

Частота текучести кадров высока, а проекты поддерживаются несколькими поколениями.

Давайте поговорим еще об одной причине формирования кода горы дерьма — высокой текучести кадров.

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