Изменения API

Изменения API
Atom
12/27/2012
VassilSanych


Вообще изменения существующего API в серьёзных проектах не приветствуются. Но если они жизненно необходимы, то это делается так:

  • устаревший метод/класс помечается атрибутом Obsolete ([System.Obsolete("use class B")]). При билде в Visual Studio это будет видно в warnings.
  • содержимое устаревшего метода заменяется рабочей обёрткой над новым функционалом
  • при выпуске мажорной версии (например 1.7 -> 2.0) устаревший код окончательно выбрасывается с указанием в описании релиза. Вот как-то так.


1 2 3  >
Mikhail Sukhov

Avatar
Date: 12/27/2012
Reply


Спасибо, добавил в избранное. Как наймем штат программистов эдак из 5-6 человек, обязательно будем пользоваться этими рекомендациями. Надеюсь, пока не сильно доставляет неудобства, что переделки идут без поддержания обратной совместимости?

Thanks:

VassilSanych

Avatar
Date: 12/27/2012
Reply


Mikhail Sukhov: Спасибо, добавил в избранное. Как наймем штат программистов эдак из 5-6 человек, обязательно будем пользоваться этими рекомендациями. Надеюсь, пока не сильно доставляет неудобства, что переделки идут без поддержания обратной совместимости? Если б не доставляло неудобства, я бы это не писал. Не сильно. Терпимо. Но всегда хочется лучшего.

Thanks:

Геннадий Ванин (Gennady Vanin)

Avatar
Date: 1/10/2013
Reply


Mikhail Sukhov: Терпимо Подскажите, как лучше терпеть?

Из документации как-то не очень видно, что в какой версии как использовать

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

Thanks:

VassilSanych

Avatar
Date: 1/10/2013
Reply


Геннадий Ванин (Gennady Vanin): Подскажите, как лучше терпеть? Из документации как-то не очень видно, что в какой версии как использовать

Вам уже объяснили. Расшифровываю: странно требовать от поделки соответствия профессиональным стандартам. Исследуйте. Делитесь находками на форумах. Как все.

Thanks:

Moadip

Avatar
Date: 1/10/2013
Reply


Геннадий Ванин (Gennady Vanin): Но это мало помогает, если нужные методы или классы там не применяются или же произошли изменения названий на новые, которые неизвестны и непонятно, как и откуда узнавать Самая свежая и актуальная справка по API это ObjectBrowser в VS.

Thanks:

VassilSanych

Avatar
Date: 1/10/2013
Reply


Moadip: Самая свежая и актуальная справка по API это ObjectBrowser в VS. Зависимости и последовательность вызовов лучше видно Reflector'ом.

Thanks:

Mikhail Sukhov

Avatar
Date: 1/14/2013
Reply


VassilSanych:

Геннадий Ванин (Gennady Vanin): Подскажите, как лучше терпеть? Из документации как-то не очень видно, что в какой версии как использовать

Вам уже объяснили.

У вас вопрос был касательно ночных сборок. С ними даже в планах нет написания изменений. У ГВ я так понимаю проблема с переходом от версии к версии. Это все в топиках вида S# 4.1 бета.

Thanks:

VassilSanych

Avatar
Date: 1/14/2013
Reply


Mikhail Sukhov: У вас вопрос был касательно ночных сборок. С ними даже в планах нет написания изменений. У ГВ я так понимаю проблема с переходом от версии к версии. Это все в топиках вида S# 4.1 бета. Не совсем так. Я писал, что в профессиональных проектах поддержку старого API убирают в мажорных (главных) версиях. А это бывает, как правило, не чаще, чем раз в год или раз в два года. ГВ, конечно, немного резок. Но в одном он прав: проблемы с реагированием на фидбэк, документацией, версиями, изменениями - это на самом деле не столько проблемы пользователей, сколько ваши проблемы.

  • отсутствие строгой версионности приводит к проблемам поиска ошибок. Особенно если пользователь не склонен обновлять версии (см. далее)
  • неадекватность документации ведёт к бОльшему количеству вопросов. Часто одних и тех же.
  • неустойчивость API приводит к тому, что пользователи не склонны обновлять версию. Никто не хочет ломать то, что худо-бедно, но работает.

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

Thanks: Геннадий Ванин (Gennady Vanin)

Mikhail Sukhov

Avatar
Date: 1/14/2013
Reply


VassilSanych: Не совсем так. Я писал, что в профессиональных проектах поддержку старого API убирают в мажорных (главных) версиях. А это бывает, как правило, не чаще, чем раз в год или раз в два года.

А у нас не так разве?

VassilSanych:

  • отсутствие строгой версионности приводит к проблемам поиска ошибок. Особенно если пользователь не склонен обновлять версии (см. далее)
  • неадекватность документации ведёт к бОльшему количеству вопросов. Часто одних и тех же.
  • неустойчивость API приводит к тому, что пользователи не склонны обновлять версию. Никто не хочет ломать то, что худо-бедно, но работает.
  1. Чего?
  2. Документация адекватна хотя бы потому, что с ее помощью много пользователей научились пользоваться S#. Да, на 100% вопросов она не отвечает, да и не должна.
  3. Вот тут я не понял, описана проблема S# или пользователя?
Thanks:

VassilSanych

Avatar
Date: 1/14/2013
Reply


Mikhail Sukhov:

  1. Чего?
  • ошибка такая-то
  • в какой версии?
  • 4.1.7
  • номер чекина на codeplex?
  • а хрен его знает. Забыл.

Mikhail Sukhov: 3. Вот тут я не понял, описана проблема S# или пользователя? Как я написал, это всё по большей части проблемы разработчиков. Хотя они почему-то думают, что это проблемы пользователей. Пользователю конечно тоже не очень приятно. А разработчик имеет дело с фидбэком ошибок из зоопарка версий и ничего не может с этим сделать. Только отказаться от поддержки всех версий, кроме самой последней (по принципу - ничего не вижу, ничего не слышу, ничего никому не скажу), а это контрпродуктивно. И так пользователей не то, чтобы легион. (Как кстати дела с тестированием?)

Thanks:
1 2 3  >

Attach files by dragging & dropping, , or pasting from the clipboard.

loading
clippy