Техническое обслуживание - уравновешивание вопроса о том, когда и если вносить изменения - PullRequest
1 голос
/ 05 марта 2009

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

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

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

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

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

Проблема, с которой я сейчас сталкиваюсь, это: рекомендации по проектированию фреймворка. В рекомендациях, касающихся событий, говорится, что события должны иметь подпись с двумя аргументами: (Источник объекта, EventArgs e). Но я отсутствовал в тот день в моем курсе Framework Design;). События в моей библиотеке в настоящее время принимают только один аргумент EventArgs.

Сейчас я добавляю новые события в библиотеку. Должны ли новые события соответствовать рекомендациям по проектированию рамок? или шаблон уже установлен в библиотеке? Если я использую рекомендации по проектированию для новых событий, должен ли я изменить существующие события, чтобы они также соответствовали рекомендациям по проектированию? И если так, как сделать миграцию? Должен ли я использовать атрибут [Устаревший]? Сколько релизов?

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

Ответы [ 3 ]

1 голос
/ 05 марта 2009

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

0 голосов
/ 05 марта 2009

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

0 голосов
/ 05 марта 2009

Вам определенно придется много общаться, если вы планируете вносить серьезные изменения. Даже если вы перезапустите свои библиотеки как версию 2, вам придется сообщить своим пользователям, что в будущем версия 1 будет исправлена ​​только с ошибками, и вы перейдете к разработке версии 2, где они смогут найти все новые функции.

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

...