Я должен возвратиться и зафиксировать работу, когда Вы изучаете что-то новое/лучше?
Полагание, что мы все постоянно учимся, мы все добрались для случайной встречи с точкой, где мы изучаем что-то просто потрясающее, которое улучшает наш код или части его значительно.
Вопрос, когда Вы узнали, что некоторая новая техника, стратегия или что бы то ни было, делает Ваш, или необходимо ли возвратиться для кодирования этого, Вы знаете работы, но могли быть настолько лучше/удобны в сопровождении/быстрее/обычно улучшенный и реализовать это новое знание?
Я понимаю понятие, "если это не, повредился, не фиксируйте его", но когда это становится проигрывающей гордостью кодом, Вы уже записали и что это говорит для рефакторинга.
16 ответов
IMO, это зависит от нескольких факторов:
Текущий проект или нет - Будет ли это возвращением в предыдущий проект, чтобы внести изменения и открыть банку с червями, чтобы сделать это? Там, где я работаю, есть наш текущий проект, и хотя я могу узнать то-то и то-то, я не собираюсь лезть в старые проекты и создавать новые проблемы, пытаясь применить что-то, что, как я думал, будет простым. Другая мысль - взять то, что есть в SourceSafe и перенести это в Subversion, что может быть полезно, чтобы иметь только одну программу для контроля версий, но, вероятно, не будет рассматриваться как разумное вложение времени, поскольку большинство разработчиков здесь привыкли использовать обе.
Возраст кода - Является ли этот код тем, над которым я работал недавно, или мне придется потратить много времени на понимание того, что я делал давным-давно? Хотя это похоже на вышеупомянутое, мой текущий рабочий проект длится с июня 2008 года, поэтому есть вещи, над которыми я работал год или более назад, и которые, возможно, не стоит возвращать и менять.
Масштаб изменений - потребуются ли на это недели или всего несколько часов? Это тоже нужно учитывать, так как небольшие изменения иногда могут привести к многочасовой работе по исправлению того и этого, которые становятся новыми ошибками из-за побочных эффектов изменения.
Это несколько вещей, которыми я бы руководствовался, а также старался помнить, что только потому, что что-то может показаться лучше, не обязательно использовать это везде. Например, пытаться использовать дрель для забивания гвоздей - не самая лучшая идея, но если вы только что научились пользоваться дрелью и хотите использовать ее везде, то могут возникнуть проблемы, когда другие инструменты, такие как молоток или гаечный ключ, могут оказаться гораздо полезнее, поэтому не забывайте, что существует подходящий инструмент для работы, который также может быть полезен.
Думаю, это зависит от того, код это для личных проектов или для работы. Если это работа, очевидно, что в конечном итоге это зависит от вашего босса. Если вы можете убедить их, что это требует , и они готовы дать вам время вдали от других проектов, чтобы сделать это, то сделайте это.
Есть ли у вас хорошее покрытие для модульного тестирования? Если вы это сделаете и уверены, что можете внести изменения, ничего не сломав, то почему бы и нет?
Я бы сделал это только в том случае, если бы был уверен, что «улучшенный» способ на самом деле лучше.
Я все время думаю об этом, и на этот вопрос нелегко ответить. По сути, если код, который я хочу переписать, скорее всего, больше никогда не будет использоваться, я не буду этого делать. Если только это не то, что я написал вне работы. Тогда, если это была достаточно крутая программа, я, скорее всего, ее перепишу. Однако, если это связано с работой, я, вероятно, не стал бы этого делать, если только это действительно не может сделать код намного сильнее.
Но я бы не стал, если вы не знаете наверняка, что это улучшение.
Мое мнение - нужно вернуться и исправить "рабочую" работу, когда кто-то платит за ее исправление.
Конечно, я упорный капиталистический консультант, и большая часть моей работы - это, по сути, заказчик, который приходит с запросом на приложение XYZ, и я создаю его для них.
Тем не менее, в моем игровом проекте (читатель .NET CBR с открытым исходным кодом) я всегда рад немедленно внедрять в него новые вещи - но опять же, это то, для чего он нужен.
Чтобы ответить на часть вашего вопроса:
Там, где я работаю, было бы неправильно редактировать то, что не сломано. В производственной среде, где люди используют ваш код весь день каждый день, вас будут упрекать за «настройку» кода, который еще не был признан сломанным. В случае (желательно) небольшого шанса, что вы допустили опечатку или случайно изменили некоторые функции, пострадает кто-то другой, пока они устраняют неполадки. Другими словами, разработка создаст проблемы для поддержки. Кроме того, мой работодатель старается избегать оплаты кому-либо за внесение изменений в то, что не сломано.
Я никогда не думаю, что переписывание кода, написанного вами в далеком прошлом, стоит усилий, если только он не сломан, потому что он часто ломается настолько фундаментально, что вы начнете с нуля. Сосредоточьте свои недавно приобретенные навыки джедая на новых задачах.
При этом, если вы проводите рефакторинг, убедитесь, что у вас есть готовые тестовые примеры, которые помогут вам отловить те регрессии, которые вы представите.
Если мы говорим о производственном коде, я бы сказал, что внесите изменения, если:
- Вы можете сэкономить время, не подвергая опасности другие проекты / выпуски расписания
- Улучшения сделают приложение более эффективным / быстрым
- Если улучшение производительности несущественно с точки зрения обычного пользователя, внесите эти изменения как часть версии с новыми функциями (не делайте выпуск только для рефакторинга, если он не является в значительной степени прозрачным для пользователей)
- Ваш код находится под контролем источника. «Если он не сломан, не чините его» применяется только тогда, когда вы не можете в мгновение ока вернуться в непрерывное состояние. Контроль версий имеет решающее значение для изменений такого рода.
- У вас есть модульные тесты для большинства компонентов, которые будут переработаны. Вы не хотите облажаться для пользователей только из-за попытки рефакторинга; лучший способ избежать этого - иметь тесты, которые проверяют идентичность поведения до и после.
Хороший вопрос, о котором я часто думаю. По мере развития программистов будет все меньше и меньше средств для обслуживания унаследованных систем, поэтому важно не позволять вашим системам становиться слишком старыми, иначе их обслуживание в будущем станет дорогостоящим.
Однако переписать всю систему - непростая задача. Годы исправления мелких ошибок здесь и там будет сложно снова начать с нуля, поэтому требуется большая осторожность.
Если вы можете сократить 1000 строк кода до 100, я бы посоветовал это сделать. Если это означает внедрение совершенно новой структуры для достижения этой цели, я бы думал иначе, пока преимущества не перевешивают недостатки.
Несмотря на треугольник времени / бюджета / качества проекта, вам не следует рассматривать рефакторинг кода, если:
- Код содержит ошибки / так себе работает с остальной частью приложения.
- Будет новое обновление функции, которое будет использовать ваш опытный код;)
- это не корпоративный проект (блог вашей матери, написанный около 10 лет назад с использованием PHP и текстовых файлов;)) или проект с открытым исходным кодом - вы можете получить удовлетворение и опыт во время рефакторинга.
- Когда ваши коллеги злятся, когда они используют ваш код.
Вы станете лучшим программистом, если напишете больше.
Лично для меня это вопрос времени. Если я узнаю что-то «новое и потрясающее», я делаю мысленную пометку, чтобы реализовать это в любом новом коде, который я напишу в будущем.
Попытка реализовать это в старом коде отнимает много времени как для изменения кода, так и для исправления любых проблем, которые могут возникнуть позже в результате внесенного мной изменения. Пытаться объяснить моему боссу, что пошло не так в этих случаях, чрезвычайно сложно, поскольку он не программист и не понимает, как мы, программисты, гордимся своим кодом.
Однако, если я все же вернусь и пересмотрю старый код, потому что мне нужно что-то изменить (исправить проблему, реализовать новую функцию и т. Д.), И этот код заставляет меня думать (ой, что БЫЛО Я думаю?) Тогда да, я меняю это, потому что я все равно над этим работаю.
Нет жесткого правила, но в целом я подошел так: Если это для личного проекта, то непременно. Если это за счет чужого доллара, то обычно вы откладываете исправление, пока клиент не захочет увеличить выгоду ремонтопригодность / производительность, которые вы будете предоставлять, или до тех пор, пока вам не придется касаться этого кода, чтобы все равно внести другие изменения. В любом случае постарайтесь убедиться, что у вас есть тестовое покрытие, которое гарантирует, что вы не нарушите какие-либо существующие функции.
В общем, нет, "если не сломано, не чини". Однако, если вы сделали существенные хаки/обходные пути, чтобы заставить что-то работать, и вы знаете, что это вызовет проблемы позже, то обычно стоит сделать рефакторинг.
Каждое решение основывается на соотношении усилий/риска и отдачи. Если вы хорошо знаете масштаб изменений и можете точно оценить стоимость исправления, то это может окупиться. Однако, если речь идет о масштабном изменении, это обычно приводит к синдрому версии 2, когда вы начинаете переписывать все заново, а там кроется проблема...
Рефакторинг существующего [производственного] кода, который в остальном функционален и в целом удовлетворяет конечных пользователей (и в меньшей степени его сопровождающих)- это, как правило, плохая идея. Вот почему
- Часто это не имеет экономического смысла.
- Это создает риск (уверенность!) появления новых ошибок, которые затем потребуют исправления и будут мешать конечным пользователям
- Часто наши идеи "делать вещи лучше" просто связаны с причудой или заблуждением: оставьте новые идеи для нового кода ;-)
На более философском уровне есть два момента, которые следует рассмотреть:
Различие между инженерией и элегантным/совершенным дизайном
. Инженерия позволяет нам справиться с несовершенством дизайна!
Поэтому, хотя полезно и часто выгодно стремиться к наиболее элегантному способу проектирования вещей и использовать инструменты, которые позволяют создавать практичные и работоспособные приложения, даже если их отдельные части могут быть менее оптимальными.относительные преимущества и недостатки творения в сравнении с эволюцией
Хотя аналогия с биологической эволюцией разрушается, поскольку эволюция программного обеспечения более направленная (т.е. в процессе эволюции вновь вводит кусочки креационизма), мы должны остерегаться того, что непрерывная эволюция программного продукта, вероятно, увеличит общую сложность этой системы.
«Новое / лучшее» не заменяет «хорошо испытано в полевых условиях». Если что-то в моем коде надежно работает годами, я не буду это трогать.
Думайте о своем коде как о подковообразных крабах - Природа изобрела «лучшие» способы делать что-то с тех пор, как они впервые появились, но они все еще существуют и набирают силу.