В разработке программного обеспечения есть старая поговорка. Я слышал это много раз в своей карьере…

Если он не сломан, не чините его.

У вас могут возникнуть проблемы с оптимизацией старого кода.

Но вы также должны очищать старый код, когда можете!

Как вы решаете — оставить или исправить?

Мой код просто работает

Сейчас на Reddit гуляет забавная гифка.

Это подчеркивает тот факт, что мы часто знаем, что наш код не соответствует предметной области!

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

Даже когда вы пишете код, это может показаться не лучшим решением.

Что делать?

Взвешивание ваших вариантов

Будь то код, который вы только что написали, или старый код, который нуждается в рефакторинге — как вы решаете, что с этим делать?

• С одной стороны, код работает! Программное обеспечение Agile говорит, что достаточно хорошо . Вы должны тратить свое время на деятельность, приносящую больше пользы.
• С другой стороны, оставлять беспорядочный, запутанный или плохо спроектированный код кому-то еще не так уж и приятно! Кроме того, когда базовый код хорошо разработан, будущие изменения и расширения намного проще.

Разработка программного обеспечения всегда связана с компромиссами. Вы будете постоянно осуждать. Следует ли проводить рефакторинг — один из таких вызовов.

Не так просто, как кажется

Вы часто обнаружите, что базовый код сложен по определенной причине.

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

Как правило, простая очистка фундаментального фрагмента кода распутывается. Требуются дни или недели усилий, чтобы следить за всеми частями.

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

Я бы сказал, всегда предполагайте, что это займет в два раза больше времени, чем вы думаете.

Затем вы должны спросить: «Стоит ли оно того?»

Вопросы для рассмотрения

Вот некоторые вещи, о которых следует подумать, прежде чем приступать к серьезному рефакторингу:

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

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

Итак, подумайте дважды и приступайте к рефакторингу с ясным сознанием. Ваша команда будет вам благодарна.

Ежедневный список

Я помогаю разработчикам программного обеспечения целенаправленно строить значимую карьеру.

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

Моя цель — помочь вам работать над программным обеспечением, которое делает мир лучше.

2000 других разработчиков программного обеспечения получают мою ежедневную публикацию прямо в свои почтовые ящики.

Присоединяйтесь к ежедневному списку и получите мгновенный доступ к моему лучшему контенту!

—

Присоединяйтесь к Medium за 5 долларов — получите доступ ко всему Medium + поддержите меня и других!