Изменения API
Atom
27.12.2012
VassilSanych


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


1 2 3  >
Mikhail Sukhov

Фотография
Дата: 27.12.2012
Ответить


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

VassilSanych

Фотография
Дата: 27.12.2012
Ответить


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

Если б не доставляло неудобства, я бы это не писал.
Не сильно. Терпимо. Но всегда хочется лучшего.

Спасибо:

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

Фотография
Дата: 10.01.2013
Ответить


VassilSanych
[quote=Mikhail Sukhov;23221]
Терпимо

Подскажите, как лучше терпеть?

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

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

VassilSanych

Фотография
Дата: 10.01.2013
Ответить


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

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


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

Спасибо:

Moadip

Фотография
Дата: 10.01.2013
Ответить


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

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

Самая свежая и актуальная справка по API это ObjectBrowser в VS.

Спасибо:

VassilSanych

Фотография
Дата: 10.01.2013
Ответить


Moadip
Самая свежая и актуальная справка по API это ObjectBrowser в VS.

Зависимости и последовательность вызовов лучше видно Reflector'ом.
Спасибо:

Mikhail Sukhov

Фотография
Дата: 14.01.2013
Ответить


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

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


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


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

VassilSanych

Фотография
Дата: 14.01.2013
Ответить


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

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

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

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

Спасибо: Геннадий Ванин (Gennady Vanin)

Mikhail Sukhov

Фотография
Дата: 14.01.2013
Ответить


VassilSanych

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


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

VassilSanych

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


1. Чего?
2. Документация адекватна хотя бы потому, что с ее помощью много пользователей научились пользоваться S#. Да, на 100% вопросов она не отвечает, да и не должна.
3. Вот тут я не понял, описана проблема S# или пользователя?
Спасибо:

VassilSanych

Фотография
Дата: 14.01.2013
Ответить


Mikhail Sukhov
1. Чего?

- ошибка такая-то
- в какой версии?
- 4.1.7
- номер чекина на codeplex?
- а хрен его знает. Забыл.
Mikhail Sukhov
3. Вот тут я не понял, описана проблема S# или пользователя?

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

Спасибо:
1 2 3  >

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy