В то время все это имело смысл, но не сейчас
Я был в рабочем блоке разработчиков. Было несколько хороших и интересных проектов. Потом еще были ужастики. Но неважно, какие чувства я испытываю к коду, у них всех есть одна общая черта — в конечном итоге все они нуждаются в рефакторинге.
Рефакторинг — один из жизненных фактов для всех разработчиков. В какой-то момент мы все с этим сталкиваемся. От этого никуда не деться, и объяснить эту концепцию высшему руководству может быть не менее сложной задачей.
Для многих людей, не являющихся техническими специалистами, программное обеспечение похоже на актив, который создан и оплачен. Для разработчика программного обеспечения это больше похоже на владение собственным домом. В какой-то момент старые трубы дадут течь, или вы вдруг поймете, что строить из асбеста — плохая идея.
Даже новые сборки имеют свои проблемы.
Ничто не идеально. Вам может понравиться цветовая схема и архитектурные планы, но для другого взгляда — это может быть просто перегрузка гедонистического максималистского кода, потакающего своим прихотям, который имел смысл только для его создателя.
Кто-то и где-то всегда будет иметь свое мнение.
Так что же можно сделать, чтобы создать хоть какой-то консенсус? Какие уроки рефакторинга я извлек, которыми можно поделиться и которые могут повлиять на будущие рефакторинги?
У меня есть три слова — три слова, которые я бы хотел, чтобы кто-нибудь сказал мне в начале моих дней разработки программного обеспечения, и то, чем я живу и умираю сейчас, работая в команде, где рефакторинг становится фактором: разработка по контракту.
Проблема с кодом и «гибкой» разработкой
Помните времена гибкой разработки?
Я помню.
Мне обещали великие дела, но они так и не осуществились. От большего количества времени, чтобы исправить ситуацию, до правильной реализации вещей.
Гибкий код со временем превратился в хрупкий код.
