Добавление функций в базы кода, которые остро нуждаются в рефакторинге - PullRequest
2 голосов
/ 13 июля 2010

Я занимаюсь разработкой системы, с которой немного сложно работать.Он на 99% недокументирован, не соответствует передовым методам и довольно сложен для понимания (глобальные изобилии, методы, охватывающие 50 строк, злоупотребление оценкой и т. Д.).К сожалению, я довольно новичок в кодовой базе и мне нужно добавить функциональность.

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

Спасибо!

Ответы [ 5 ]

4 голосов
/ 13 июля 2010

http://www.joelonsoftware.com/articles/fog0000000069.html

http://discuss.joelonsoftware.com/default.asp?design.4.469415.13

http://www.joelonsoftware.com/articles/fog0000000007.html

http://www.paulgraham.com/hp.html

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

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

2 голосов
/ 13 июля 2010

Я бы пошел с твоим инстинктом: пиши так, как ты умеешь.TDD, если это ваш подход;во всяком случае, постарайтесь убедиться, что ваш новый материал достаточно хорошо тестирован (и, конечно, меньше беспорядка, чем то, что есть сейчас).

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

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

1 голос
/ 13 июля 2010

Все, что вы испытываете, можно преодолеть, прочитав Работа Эффективно с устаревшим кодом .Я знаю, что вы сказали, что у вас сжатые сроки, но поспешность и неполное понимание базового кода может иметь (и, вероятно,) некоторые негативные побочные эффекты.

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

0 голосов
/ 13 июля 2010

Не беспокойтесь об этой небольшой функциональности, которую вы добавляете. Делай это быстро и грязно.

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

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

  • Среда MVC, такая как Zend Framework
  • Библиотека классов Zend Framework для часто используемых компонентов, таких как Auth / ACL / OAuth / и т. Д.
  • Уровень абстракции базы данных или ORM, такой как Doctrine или Propel
  • Всего одна библиотека JavaScript: JQuery (возможно, в сочетании с JQuery UI)
  • Системы автоматического развертывания, такие как Phing и Ant
  • Модульное тестирование для ваших классов
  • Приемочные испытания на основе вариантов использования с использованием Selenium
  • Хорошо продуманная система контроля версий и стратегия

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

0 голосов
/ 13 июля 2010

Мы находимся в той же лодке в моем деле: первая фаза пошла в направлении, которое работало, но не было идеальным.Вторая фаза изменила бизнес-модель и логику ..... эта фаза была офшорной, что само по себе не было бы проблемой, если бы компания действительно поняла структуру, на которой они решили строить.Итак, здесь мы пытаемся завершить фазу 3 (устраняя путаницу фазы 2, должным образом используя платформу, как было задумано), оплакивая необходимость работать с такой плохо написанной кодовой базой.Были серьезные проблемы - использование двух структур javascript, неуклюжего устаревшего пользовательского интерфейса, нежелательного кода и серьезного обновления инфраструктуры, что делает версию, на которой мы находимся, устаревшей и практически невозможно перенести на новую версию.

Вот что мы решили сделать ... это может быть не идеально для вашей ситуации.Во-первых, наш вице-президент по разработке продуктов занял две недели и полностью пересмотрел структуру базы данных.Он поручил нашему персоналу по программированию модифицировать существующий код по мере необходимости, чтобы приспособить правильные, эффективные структуры БД.Как только этот (болезненный) шаг был сделан, мы сделали двухнедельный перерыв, чтобы продвинуться в разработке новых функций.Затем я взял перерыв в своих обязанностях полностью реорганизовать пользовательский интерфейс, не используя одну инфраструктуру Javascript, чтобы мы работали на одной общей платформе (какая концепция, намек, ужасная оффшорная компания ...) и сделалэффективное использование современных, эффективных, текущих элементов пользовательского интерфейса.Мы будем выполнять 80% -20% задач до тех пор, пока продукт не выйдет из бета-версии - 80% будут выполнять окончательные требования, 20% будут выполнять рефакторинг кода и устранять устаревший беспорядок.Каждому сотруднику была выделена область, за которую он отвечает за «очистку» или повышение эффективности.Документирование процессов также является задачей, которая была делегирована и составляет требуемый процент рабочей недели каждого сотрудника.

Я думаю, что ключом к успеху нашего процесса является стремление к этапу 4 даже до того, как этап 3 был пройдензавершено.Новый код создается с максимальной эффективностью и взаимозаменяемостью, поэтому, если и когда мы уйдем с этой устаревшей платформы, потребуются минимальные изменения.Я экспериментирую со способом разделения наших процессов (не только кода), чтобы теоретически их можно было индивидуально перенести в новую среду, когда придет время.Наши планы на будущее составлены на бумаге, список требований разрабатывается и ведутся исследования по поиску лучших инструментов.Самое главное, что руководитель группы является сторонником правильного и эффективного выполнения дел, поэтому ничто из нынешнего или будущего не пойдет вперёд, если не сделано правильно.

Сложно объяснить руководству, что для продвижения вперед нужно идти назад.,Еще сложнее, когда все будущее вашей компании зависит от продукта, который застрял в бета-версии, как и мы.Я сравниваю это с расходами на экономичное устройство… сейчас это будет стоить дороже, но в конечном итоге это принесет огромные финансовые выгоды.Я думаю, хитрость в том, чтобы добиться успеха в этой ситуации, - найти медиану для вашего продукта, где он «достаточно хорош», чтобы оставаться в одиночестве, пока вы тратите время на то, чтобы сделать продукт великолепным.Разработка стратегии для достижения этой медианы заставит бизнес-единицу набраться терпения и в конечном итоге сделает вас героем, когда это удастся.Развейте сильный план, сообщите этот план, играйте хорошо с другими, и отрабатывайте свой хвост.Вскоре вы снова будете наслаждаться жизнью!

...