Гибкие методы для предотвращения удержанного от использования кода? [закрытый]

Как говорит Мэтт, атрибут Устаревший - ваш друг ... но всякий раз, когда вы его применяете, укажите подробности того, как изменить код вызова. Так у вас будет больше шансов на то, что люди действительно изменятся. Вы также можете указать, в какой версии вы предполагаете удалить метод (вероятно, в следующем крупном выпуске).

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

Since much of agile development revolves around making something work now and refactoring later if needed

That's not agile. It's cowboy coding disguised under the label of agile.

The ideal is that whatever you complete, is complete, according to whatever Definition of Done you have. Usually the DoD states something along the lines of "feature impelmented, tested and related code refactored". Of course, if you are working on a throwaway prototype, you can have a more relaxed DoD.

API modifications are a difficult beast. If they are only project-internal APIs you are modifying, the best way to go is to refactor early. If you need to change the internal API, just go ahead and change all API clients at the same time. This way the refactoring debt does not grow very large and you don't have to use deprecation.

For published APIs you probably have some source and binary compatibility guarantees you have to maintain, at least until the next major release or so. Marking the old APIs deprecated works while maintaining compatibility. As with internal APIs, you should fix your internal code as soon as possible to not use the deprecated APIs.

Ответ Мэтта - твердый совет. Я просто хотел упомянуть, что изначально вы, вероятно, захотите использовать что-то вроде:

[Obsolete("Please use ... instead ", false)]

После того, как вы перенесли код, измените false на true, и компилятор будет рассматривать все вызовы метода как ошибки.

Смотреть Джош Блоха « Как разработать хороший API и почему это важно »

Самым важным без исключения устареванием является знание того, что «если есть сомнения, оставьте это в стороне». Посмотрите видео, чтобы получить разъяснения, но это связано с необходимостью поддерживать то, что вы предоставляете навсегда. Если вы реалистично ожидаете, что этот API будет повторно использован, вы фактически закрепите свои решения на камне.

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

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

Итак, итоги: я бы не стал беспокоиться об отказе от поддержки код во время гибкой разработки. Если он какое-то время служил своей цели, вы поступаете правильно.

Для устаревания существует три основных типа API: внутренний, внешний и общедоступный.

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

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

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

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

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

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

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

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

Another approach to be popular is to have clients depend on (web) services. There are constructs out there that allow you to version your services and allow clients to perform lookups. This adds a lot more moving parts and complexity into the equation, but can be helpful if you are looking at turning over a lot of versions, and having to support multiple versions in production.

This article does a good job of explaining the problem and an approach.

The rule of thumb for API design is to focus on what it does, rather than how it does it. Once you know the end goal, figure out the absolute minimum input you need and use that. Avoid passing your own objects as parameters, pass only data.

Seperate configuration from execution. For exmaple, maybe you have an image encoder/decoder.

Instead of making a call like:

Encoder.Encode( bytes, width, height,  compression_type, compression_ratio, palette, etc etc);

Make it

Encoder.setCompressionType(compression_type);
Encoder.setCompressionType(compression_ratio);
etc,etc
Encoder.Encode(bytes, width, height);

That way adding or removing settings is much less likely to break existing implementations.