Когда лучше всего менять код в соответствии со стандартами? - PullRequest
2 голосов
/ 22 января 2009

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

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

1. Что следует учитывать при рассмотрении вопроса о том, лучше ли переходить на один стандарт?


(На связанной ноте)

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

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

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

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

Ответы [ 4 ]

2 голосов
/ 22 января 2009

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

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

Итак, в ответ на ваш вопрос, Я пытаюсь провести рефакторинг, когда у меня есть время для этого . Приоритет Один все еще остается для создания функционального фрагмента кода.

2 голосов
/ 17 февраля 2009

Что нужно учитывать:

  • Это работает как есть?

Как отмечает Галвегиан, это единственный критерий во многих магазинах. Тем не менее, ИМО также важна:

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

Если вы поддерживаете его, вместо этого рассмотрите:

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

Сложно догадаться, но учтите, что многие кодовые базы FAR переживают полезность, предусмотренную их первоначальными авторами. (Y2K кто-нибудь?) У меня постепенно появилось чувство, когда рефакторинг стоит, а когда нет, в основном из-за того, что он слишком часто ошибался в сторону «не» и потом сожалел об этом.

1 голос
/ 04 ноября 2009

Если у вас есть время, сейчас. Если у вас нет времени и его можно избежать, позже.

1 голос
/ 22 января 2009

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

...