Изменения API
Atom Ответить
27.12.2012


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




23 Ответов
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

Фотография
Автор статей Программист Трейдер
Дата: 13.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# или пользователя?

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

Автор топика
Спасибо:

Den

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


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

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

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

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



Я тоже тратил время при переходе от версии к версии, и далеко не на каждый дот-дот перехожу, но

1. на самом деле API не просто от нечего делать меняется и изменения всегда оправданы и логичны.
2. парни практически сразу откликаются на ошибки, описанные на форуме, и быстро их устраняют!
3. дока очень даже неплохая и вкупе с примерами вполне себе дает разобраться в предмете.

библиотека бесплатна, требовать от разработчиков софтверных стандартов IBM странно было бы.

Но вот если бы разработчики при коммитах изменения API просто на форуме их озвучивали было бы здорово.
Например на странице с новостями про beta-версию просто создали бы и редактировали соответсвующий топик,
на данный момент 4.1.7.

Все равно при выкладывании версии эта информация собирается и публикуется, а так будет
сама аггрегироваться разными коммитерами в один топик по мере поступления.
Early announcement, так сказать...
Спасибо: VassilSanych Alexander

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 14.01.2013
Ответить


VassilSanych Перейти
Mikhail Sukhov Перейти
1. Чего?

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


Здесь без переводчика с русского на русский не обойтись. Я не понимаю что тут написано.

VassilSanych Перейти
Только отказаться от поддержки всех версий, кроме самой последней, а это контрпродуктивно.


Почему? Получилось очень даже продуктивно. Сразу стало больше времени на разработку, чего не было, когда приходилось поддерживать старый код.

VassilSanych Перейти

И так пользователей не то, чтобы легион.


А это плохо?Cool

VassilSanych Перейти

(Как кстати дела с тестированием?)


Тестирование на истории или тестирование ПО?
Спасибо:

VassilSanych

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


Mikhail Sukhov Перейти
Почему? Получилось очень даже продуктивно. Сразу стало больше времени на разработку, чего не было, когда приходилось поддерживать старый код.

Неисправленные ошибки, обнаруженные в старой версии, часто просто остаются незамеченными в новой. Особенно, если новой версией мало кто пользуется.
Mikhail Sukhov Перейти
А это плохо?Cool
Решать только вам. Если у вас СЛИШКОМ много пользователей/клиентов, я только рад за вас.
Mikhail Sukhov Перейти
Тестирование на истории или тестирование ПО?
Тестирование ПО

Автор топика
Спасибо:

Alexander

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


Den Перейти
Но вот если бы разработчики при коммитах изменения API просто на форуме их озвучивали было бы здорово.
Например на странице с новостями про beta-версию просто создали бы и редактировали соответсвующий топик,
на данный момент 4.1.7.

Все равно при выкладывании версии эта информация собирается и публикуется, а так будет
сама аггрегироваться разными коммитерами в один топик по мере поступления.
Early announcement, так сказать...


Хорошая идея, спасибо.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 14.01.2013
Ответить


VassilSanych Перейти

Неисправленные ошибки, обнаруженные в старой версии, часто просто остаются незамеченными в новой. Особенно, если новой версией мало кто пользуется.


Через какое-то время начнут пользоваться ей, и мы поправим ошибки. В чем проблема то? Мы ж тут, практически 24x7 доступны из-за распределенности по земному шаруLaugh

VassilSanych Перейти

Решать только вам. Если у вас СЛИШКОМ много пользователей/клиентов, я только рад за вас.


Пользователь != клиенту. Пользователи АПИ - это ко мне и еще нескольким товарищам. Клиенты (платные сервисы, в т.ч. и тех поддержка) - это к другим людям. Не все это знают, не все это понимают, но факт остается фактом. Поэтому у меня лично клиентов нет, но есть пользователи. Которых, конечно же, для меня одного слишком много. Радоваться тут особо не чему.

Mikhail Sukhov Перейти
Тестирование ПО


Собственными силами + через бета юзеров. К сожалению, бета дистрибутивы скачиваются не только бета юзерами, но всеми подряд (нет у нас закрытого раздела, и делать его так же нет ресурсов). И начинаются песнопения на форуме по поводу почему все перестало работать и как пользоваться новой версией. Скачал бета версию - следуй бета правилам. Вот и все дела.
Спасибо:

VassilSanych

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


На Codeplex кстати есть неплохой трекер, завязанный на TFS. Причём разработчики этот трекер заполнять и отслеживать могут прямо в VS.
Но почему-то сейчас разработка идёт как-то мимо него.
И там кстати можно связывать описания ошибок, исправления, версии и чекины, но этого вообще никто не делал.
Причём, по опыту, TFS - на самом деле, очень удобная система управления проектом, а не только версионное хранилище.
Там можно в пару кликов делать хорошие отчёты со списками исправлений, velocity chart и т.п.
Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 14.01.2013
Ответить


VassilSanych Перейти
На Codeplex кстати есть неплохой трекер, завязанный на TFS. Причём разработчики этот трекер заполнять и отслеживать могут прямо в VS.
Но почему-то сейчас разработка идёт как-то мимо него.


Потому что у нас есть свой трекер, тоже на TFS, но в закрытом разделе.

VassilSanych Перейти

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


Делается регулярно.

VassilSanych Перейти

Причём, по опыту, TFS - на самом деле, очень удобная система управления проектом, а не только версионное хранилище.
Там можно в пару кликов делать хорошие отчёты со списками исправлений, velocity chart и т.п.


Именно поэтому и пользуемся.
Спасибо:

VassilSanych

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


Mikhail Sukhov Перейти
Потому что у нас есть свой трекер, тоже на TFS, но в закрытом разделе.

Было бы удобно, если бы пользователи могли сами добавлять ошибки в трекер и отслеживать их статус, не задавая лишних вопросов на форуме, как, например, здесь Resharper Tracker (там, правда, другой трекер)
Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 14.01.2013
Ответить


VassilSanych Перейти
Mikhail Sukhov Перейти
Потому что у нас есть свой трекер, тоже на TFS, но в закрытом разделе.

Было бы удобно, если бы пользователи могли сами добавлять ошибки в трекер и отслеживать их статус, не задавая лишних вопросов на форуме, как, например, здесь Resharper Tracker (там, правда, jira)


Юзер не знает (не захочет узнавать) есть ли уже подобная ошибка в системе. Нужна модерация такого трекера, иначе будет неудобно разработчикам. Сплошь минусы. Поэтому у нас лучше решение - форум.
Спасибо:

VassilSanych

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


Mikhail Sukhov Перейти
Юзер не знает (не захочет узнавать) есть ли уже подобная ошибка в системе. Нужна модерация такого трекера, иначе будет неудобно разработчикам. Сплошь минусы. Поэтому у нас лучше решение - форум.

Юзер создаёт неназначенные ошибки. Разработчик, как правило, создаёт ошибку, сразу записывая её на себя, или просто назначает на себя какую-то из неназначенных. TFS позволяет видеть список тех ошибок, которые касаются только вас лично, или список всех ошибок, назначенных на разработчиков. Ничего не нужно модерировать, когда можно просто игнорировать. Можно изредка пробегать по полному списку, проставляя реджекты или беря в разработу ошибки, а всё остальное время видеть только то, над чем работаешь.

Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 14.01.2013
Ответить


VassilSanych Перейти
Ничего не нужно модерировать, когда можно просто игнорировать.


Это и есть модерация. Потому что ошибку нужно прочитать, найти (кстати, поисковик у трекеров всегда ущербнее форумного, как и редактор, так что еще минусы), и выбросить ее (иначе свалка проигнорированных сообщений будет расти и расти, затрудняя поиск и анализ).

Опять сплошные минусы? Вы попробуйте сами какой-нибудь проект создать и повести. Сразу поймете минусы и плюсы подходов. А так вы рассуждаете пока абстрактно. Берете первый попавшийся продукт (Решарпер), и сравниваете с нашим. А у них совсем другой бизнес, и процессу по другому построены. Нельзя колесо от Белаза к Жугули прикручивать, хоть оно надежнее и прочнее. Просто потому что разные машинки и для разного предназначены.

VassilSanych Перейти

Можно изредка пробегать по полному списку, проставляя реджекты или беря в разработу ошибки, а всё остальное время видеть только то, над чем работаешь.


Можно изредка пробегать по форуму?
Спасибо:

ra81

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


Вообще я конечно понимаю разработчиков. Дел дофига, рук всего две а голова вообще одна, но все же. Постоянные, я бы сказал, серьезные изменения в API приводят к тому что постоянно надо переписывать все что уже написано. Это нервы, отлов багов итд. Приходится думать о собственном штате программистов :). Это просто раздражает. Если написано уже много, то сильно раздражает и первое что приходит в голову - юзать API по минимуму, только как базовую обвязку к трейдеру.

Передаю, так сказать, общественное мнение а не свое личное. Сам сижу на старом ибо переписывать влом. Баги все выловил мне достаточно.
Спасибо:

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

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


ra81 Перейти
рук всего две а голова вообще одна

Это предположение имело бы право на существование, если бы команда стокшарп не отфутболивала бы предложения в помощи

Спасибо:


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

loading
clippy