Есть ли у нас ответственность за улучшение старого кода?

Я просматривал какой-то старый код, который я написал. Это работает, но это не очень хороший код. Теперь я знаю больше, чем в то время, поэтому я мог улучшить его. Это не текущий проект, а текущий, рабочий, производственный код. Есть ли у нас ответственность вернуться и улучшить код, который мы написали в прошлом, или это правильное отношение «если он не сломан, не исправляйте его»? Моя компания спонсировала урок проверки кода несколько лет назад, и одним из главных выводов было то, что иногда это просто достаточно хорошо; двигаться дальше.

Итак, в какой-то момент вы должны просто назвать это достаточно хорошо и двигаться дальше, или вы должны попытаться подтолкнуть проекты для улучшения старого кода, когда вы думаете, что он может быть лучше?

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

Вы можете использовать «старый код» для изучения лучших практик. Если вы сделаете это, это будет неполное обучение, и вы не должны ожидать, что этот код заменит то, что в настоящее время выпущено или развернуто клиентами / заказчиками.

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

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

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

TLDR: рефакторинг по мере необходимости, обязательств нет.

Все, что вы делаете, имеет цену. У вас есть ограниченное время для программирования. Все, что вы делаете в программировании, должно быть рассмотрено против: «Какая выгода от этого?» и "Какая выгода делать что-то еще?"

Если вы не принимаете во внимание альтернативную стоимость (какова стоимость выполнения чего-то еще?), То качество бесплатное. Лучше улучшить свой код. Вы чему-нибудь научитесь. Это будет работать лучше. Это продаст больше.

На самом деле вопрос в том, что лучше всего делать со своим временем? И тогда у вас есть компромиссы.

Будет ли продавать больше программного обеспечения?

Это вызовет меньше головной боли, чтобы поддержать?

Чему ты научишься?

Станет ли это более эстетичным?

Это улучшит вашу репутацию?

Задайте эти вопросы (и любые другие относящиеся к вам) для этого и других действий в вашей очереди, и это поможет ответить, если это стоит исправить. Эти компромиссы - вот почему экономика важна для программистов. Джоэл сказал это раньше, чем я, и старый наставник сказал мне это еще до Джоэла.

Или, если вы хотите более простой ответ, просто перестаньте смотреть телевизор, пока не исправите код. :-)

Я думаю, что вы должны начать с того, чтобы задать себе вопрос, который, кажется, пропущен Чем плох код? И этим вы действительно задаете себе следующие вопросы:

• Разве код не делает то, что должен делать?
• Вызывает ли код проблемы при обслуживании программного обеспечения?
• Является ли код полностью автономным?
• Планируете ли вы обновить или заменить код в любое время в обозримом будущем?
• Есть ли обоснованное экономическое обоснование, которое вы можете предпринять для обновления кода, который вас заинтересовал?

Если есть что-то, чему я научился за эти годы, так это то, что вы не можете позволить себе угадать себя после этого. Каждый раз, когда вы решаете проблему в коде, вы узнаете что-то и, вероятно, увидите, как ваше решение - или что-то подобное - могло бы быть лучшим решением проблемы, которую вы решили по-другому несколько лет назад. Это хорошая вещь, потому что она показывает вам, что вы извлекли уроки из своего опыта. Однако реальный вопрос заключается в том, может ли написанный ранее код стать унаследованной проблемой, с которой со временем будет труднее работать.

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

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

Определенно не улучшайте это только ради улучшения этого. Как уже говорили другие (и это здравый смысл), мы все поправляемся (при некотором значении «лучше») с течением времени. При этом, пересматривая код (формально или неформально), часто освещаются эти кусочки, которые, вероятно, мы бы никогда не увидели снова.

Хотя я не считаю, что мы обязаны возвращаться и улучшать код, который не является принципиально неработоспособным, небезопасным или зависит от функций из списка устаревших / EOL, вот некоторые вещи, которые я делал в прошлом в этой ситуации :

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

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

Так что нет никакой ответственности, чтобы исправить это, но этот старый материал может быть действительно полезным И юнит-тесты и CI - твои друзья!

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

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

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

Существует большое предостережение: если, улучшая код, вы избежите появления ошибки (подумайте о больших балах Y2K здесь). Я бы определенно рассказал об этом кому-то повыше, может быть, руководителю вашего подразделения, и обсудить последствия улучшения кода.

Что касается меня, то вопрос можно перефразировать и обобщить: «Зачем кому-то тратить дополнительный ресурс (время, деньги, умственные способности и т. Д.), Если этот конкретный кусок кода работает нормально? Разве это не трата ресурсов? ?»

Каждый раз, когда я нахожу устаревший код, я думаю о нескольких вещах, которые кажутся важными.

1. Зачем я собираюсь вносить изменения?
2. Нужно ли мне поддерживать этот код? Как скоро это может произойти (ближайшее / далекое будущее)?
3. Этот код достаточно удобен для работы? (Прямо сейчас)
4. Могу ли я быть уверен, что все изменения, которые я делаю, безопасны? Различные тесты обычно помогают ответить на этот вопрос.
5. Какие последствия я могу встретить, если я сделаю ошибку (и) во время модификации кода? Можно ли быстро отменить мои изменения? Это будет пустая трата времени?
6. ...

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

PS Я заметил, что я склонен переписывать код очень часто, тогда как мой друг и товарищ по команде, как правило, не трогают его. Это потому, что мы отвечаем на указанные вопросы по-разному. И я должен сказать, что мы часто отвечаем на них неправильно, потому что мы не можем предсказать будущее.

Microsoft должна обновить окна? Все ли дистрибутивы * nix должны развиваться? Или более практичный пример: все еще водят машины 1970-х годов?

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

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

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

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

Теперь, если вы работаете и обнаруживаете, что код, с которым вам нужно взаимодействовать, не написан до уровня, на который вы в настоящее время способны писать, то разумно исправить это, если вы можете сделать это контролируемым методическим способом. Лично у меня очень минимальный опыт такого рода рефакторинга, как и у всех (почти у всех?), Я попробовал целое «давайте просто изменим все и помолимся, чтобы это сработало», и меня это достаточно сильно укусило. Я бы посоветовал изучить дискуссии Мартина Фаулера (или его книгу, или одну из многих статей ) по этому вопросу. Он, кажется, вдохновил большую часть текущей мысли о процессе.

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

Надеюсь, это поможет

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

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

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

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

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

Что еще нужно учитывать - вы намерены подтолкнуть это изменение к производству или просто к разработке? Планка для двух сценариев совершенно различна. Если это происходит только в ветке разработки и, возможно, никогда не попадет в производство, то возможность в основном означает, что вы по какой-то причине смотрите на код, и это не занимает много времени. Это может быть пересмотрено по мере необходимости, если толчок когда-либо произойдет, и пропущено, если это считается необоснованным в то время. Если, с другой стороны, сейчас он будет запущен в производство, как я уже говорил выше, вам нужно подумать, стоит ли это изменение стоимости: с точки зрения времени, потраченного на создание push-кода, и преимуществ использования нового кода.

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

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

Как говорит дядя Боб Мартин: «Всегда оставляйте лагерь чище, чем вы его нашли».

Это вопрос к руководству вашей компании.

Есть ли у вас время и ресурсы, необходимые для возврата и внесения изменений в старый код?

У вас есть время и ресурсы, чтобы провести ТЕСТ команду QA, которую вы изменили, чтобы убедиться, что она не сломана?

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

По-разному.

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

OTOH, если ваша жалоба просто отсутствие элегантности кода, то не смей ее трогать. В течение долгого времени он выполнял верное обслуживание в производстве, изменение кода только удовлетворило бы вас, но не добавило бы никакой ценности, и, как и каждое изменение, существует риск того, что вы что-то сломаете. Даже если вы этого не сделаете, ваше время ценно (буквально: вам платят за то, что вы делаете, поэтому каждая минута вашего времени стоит денег), и поскольку вы не добавляете никакой реальной стоимости, такое изменение будет чистый убыток для компании и проекта.