Должен ли я вернуться и исправить работу, когда вы узнаете что-то новое/лучшее?

Ответ 1

IMO, это немного зависит от нескольких факторов:

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

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

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

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

Ответ 2

Да, если позволяет время. Обычно это не так.

Ответ 3

Если мы говорим о производственном коде, я бы сказал, сделайте изменения, если:

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

Ответ 4

Несмотря на Треугольник проекта "Время/Бюджет/Качество", вы не должны рассматривать рефакторинг своего кода, если:

• Код не работает/так работает с остальным приложением.
• Появится новое обновление функции, в котором будет использоваться ваш опытный код;)
• его не-корпоративный проект (ваш веб-блог мамы, написанный около 10 лет назад с использованием PHP и текстовых файлов;)) или проект с открытым исходным кодом - вы можете получить удовлетворение и опыт во время рефакторинга.
• Когда ваши сотрудники разозлились, когда они используют ваш код.

Вы будете лучшим программистом, когда напишете больше.

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

Однако, если я вернусь и просмотрю старый код, потому что мне нужно что-то изменить (исправить проблему, внедрить новую функцию и т.д.), и этот код заставляет меня думать (ouch, what WAS Я думаю?), то да, я меняю его, потому что он все равно работает.

Ответ 10

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

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

Тем не менее, для моего игрового проекта (читателя .NET CBR с открытым исходным кодом) я всегда рад немедленно внедрить в него новые вещи, но опять же, для чего это нужно.

Ответ 11

Я думаю об этом все время, и на этот вопрос нелегко ответить. В принципе, если код, который я хочу переписать, скорее всего, никогда не будет использоваться снова, я не делаю этого. Разве что-то я написал за пределами работы. Тогда, если бы это была достаточно крутая программа, я, скорее всего, ее переписал. Однако, если это связано с работой, я, вероятно, не сделаю этого, если только он не сможет сделать код намного сильнее.

Но я бы не стал, если вы точно не знаете, что это улучшение.

Ответ 12

Рефакторинг существующий [производственный] код, который в остальном функциональен и в целом удовлетворяет его конечных пользователей (и в меньшей степени его сопровождающим) , как правило, плохая идея. Вот почему

• Часто это не имеет экономического смысла.
• Он вводит риск (достоверность!) введения новых ошибок, которые затем потребуют исправления и которые будут нарушать конечные пользователи
• Часто наши идеи о том, как "делать что-то лучше", просто привязаны к причуде или заблуждению: сохраните новые идеи для нового кода; -)

На более философском уровне необходимо учитывать два момента:

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

Чтобы решить часть вашего вопроса:

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