Отказ от устаревшей функциональности.
Представьте себе, что вы разрабатываете некую довольно сложную библиотеку (приложение, программно-аппаратный комплекс и т.д.), которой пользуется большое количество людей во множестве проектов по всему миру. Со времени её выхода в свет было выпущено несколько версий, каждая из которых была обратно совместима в предыдущими. Тем самым разработчики, использующие вашу библиотеку, могли без лишней спешки переходить на новые версии библиотеки.
Со временем обеспечение обратной совместимости со всеми вариантами интерфейса и вариациями поведения разных версий стало отнимать всё больше времени, оставляя всё меньше возможностей для добавления новой функциональности. В один прекрасный день вы решили, что к следующему выпуску библиотеки, её архитектура будет кардинально переработана, неиспользуемые рудименты удалены, код почищен и т.д. и т.п. При этом в жертву придется принести совместимость, так как полная имитация предыдущих версий интерфейса отнимет слишком много времени и сведет на нет преимущества новой архитектуры. Впрочем, в жертву будут принесена только наиболее редко используемая функциональность, так что 95% пользователей даже не заметят разницы.
Хороший план? Отличный. Проблема только в том, как определить ту самую редко используемую часть кода. Бывает и так, что та самая «ненужная» функциональность известна. В таком случае проблема состоит в том, чтобы доказать что она действительно не используется.
Существует множество способов решения этой проблемы. Можно просто принять волевое решение отказаться от спорной функциональности. Можно привлечь к обсуждению лучших экспертов и положиться на их чутьё. Однако лучше всего – собрать правдивую статистику с участием реальных приложений и принять решение на основе этих данных. Это не всегда просто, так как любая имитация сценариев использования приложений всегда немного отличается от реальности.
Допустим, вы все же решили пойти по этому тернистому пути. С какими проблемами придется столкнуться?
- Как получить наиболее близкую к реальности статистику?
Фактически, есть только два варианта:
- собрать статистику, прогнав более или менее синтетические тесты, либо…
- выпустить специальную версию библиотеки, собирающую нужные данные в «боевых» условиях.
Достоверность результатов при первом подходе будет тем выше, чем больше сторонних приложений, использующих вашу библиотеку, будет задействовано. В идеальном случае, тест должен имитировать работу пользователей с участием этих приложений. К сожалению, даже в этом случае достоверность результатов всегда будет под вопросом.
Второй вариант позволяет получить максимально достоверные данные, однако и проблем с его реализацией в разы больше. Во-первых, только часть ваших пользователей дадут согласие на сбор этой статистики. У остальных найдется множество резонов отказаться от такого «бонуса». Во-вторых, с момента принятия решения о сборе статистики до получения результатов проходит много времени. Вам придется выпустить специализированную версию библиотеки и распространить её среди пользователей или встроить нужный код в следующий плановый релиз и дождаться, пока новая версия распространиться среди пользователей. В любом случае это с легкостью может растянуться на пару лет ожидания. В-третьих, существует чисто техническая проблема организовать нужную инфраструктуру: сервера которые будут принимать отчеты, мощности для обработки и хранения отчетов, круглосуточную поддержку.
- В каком виде собирать статистику?
Как правило, данные о событиях, которые нас интересуют, пишутся в какой-либо журнал. Это может быть и текстовый лог файл, и стандартный Event Log, и база данных, и специализированный журнал, завязанный на сервис автоматической отсылки отчетов. Выбор конкретного способа хранения данных зависит главным образом от того, как эти данные будут собираться со всех компьютеров, участвующих в тестировании, для последующего анализа. Формат и характер данных, само собой, то же влияют на этот выбор.
- Насколько подробной должна быть собираемая информация?
К сожалению, ответ в стиле «чем подробнее – тем лучше» здесь не годиться. Подробности зачастую выливаются в гигабайты данных помноженных на сотни машин, что, в общем-то, не облегчает ни пересылку, ни обработку. В этом случае работает эмпирическое правило – данных должно быть ровно столько, чтобы ответить на поставленный вопрос плюс ещё чуть-чуть. Это «ещё чуть-чуть» поможет, при случае, ответить на дополнительные вопросы, которые возникнут уже после того, как статистика будет собрана.
- Как пересылать собранные данные для анализа?
Здесь будет работать любой способ, полностью исключающий участие человека. Стоит только положиться на пользователя, чтобы, к примеру, послать письмо с подготовленным отчетом, - данные будет потеряны, отчет прислан слишком поздно и т.д. и т.п. Единственное что стоит разрешить пользователям – решать, согласны ли они на сбор статистики или нет.
- Как анализировать собранные данные?
Perl, SQL и т.д. Всё что душе угодно, на самом деле. Замечу, что средства изначально направленные на анализ данных (SQL) позволяют получать гораздо более точные результаты, по сравнению с самописными анализаторами. С другой стороны тот же Perl – отличный инструмент для обработки данных перед внесением их в базу данных.
Прочитав всё это, вы, вероятно, зададитесь вопросом: «А стоит ли овчинка выделки»? К сожалению, на него нет однозначного ответа. Всё зависит от множества факторов: количества и характера пользователей вашей библиотеки, её архитектуры, частоты выхода новых версий, ваших знаний о том, как именно используется библиотека и т.д. и т.п. В любом случае, после проведения подобных мероприятий существенно улучшатся ваши знания о привычках ваших пользователей. 
А разве нельзя переделать программу/комплекс, но сделать это аккуратней. Произвести тщательное проектирование миграции со старой версии, например? Думаю, что множество проблем снимается тщательностью и продуманностью процесса перехода, а не “скорее надо на рынок выпустить!”.
А боле-менее глобальная переработка необходима постоянно, иначе на старых костылях можно долго ковылять…
Форточки и так славятся костылизмом…
Через два года нам новую “радость” представят в видено “новой” ОС с новыми костылями. Новая версия DRM с новыми требованиями к ресурсам… И т.д. и т.п.
Суть от этого не меняется уже лет …цать.
Вот я посетил http://ru.ecomstation.ru/ecoshop/ecoshop.php?sel=os и обновил свою версию eComStation до более новой. И там костылей куда как меньше, но больше расширений.
Чего и мс желаю.
Каким образом? Я знаю единственный способ - спроектировать систему так, что бы её архитектура смогла вместить все будущие добавления и исправления. Иными словами нужно уметь предсказывать будущее.
Нахождение неиспользуемой рудиментарной функциональности - вполне себе часть тщательного проектирования миграции со старой версии.
Ну и как новая версия? Отличается от предыдущей принципиальной новизной?
Хм… Надо уметь согласовать предсказание и указать направление. Как в процессорах: сколько раз какую-то технологию уже начали в процессорах внедрять еще поколение назад, но она была заблокированной, а потом, когда всё было отлажено, разблокировали и… опа!
Совершенно согласен. Но, наверное, не миграции, а подготовки новой версии. Это - подготовительный этап, на который будет опираться миграция. Ведь миграция - процесс перехода с одной версии к другой (у заказчика/покупателя), а не процесс создания новой версии.
А почему она должна отличаться именно _принципиальной новизной_?
Лично мне до это самой новизны совершенно всё равно: по мне она и раньше она вполне отвечала моим требованиям. И новинки не в их принципиальности, а в доработке/исправлению существующего и упрощение чего-то, например, настройки системы: обновление REXX-скриптов и т.д.
Из принципиально нового (для меня): наличие загрузочной IFS на JFS, обновление ACPI и доступ к новым и разрабатываемым компонентам подготавливаемой к выпуску 2.0 (и сама она, когда выйдет). А! Там еще OpenOffice отдельно будет. Теперь не только у меня на работе, но и дома я под OOo буду работать.
А зачем обязательно _принципиально новое_? Стремление к рюшечкам мне совершенно не свойственно, а вот доп. удобство старого и проверенного - самое то.
Зная то, ЧТО собой обычно представляют эти нововведения (и по работе и в иных случаях личного опыта), могу сказать, что нове рюшечки в 90% приводят к проблемам. А если нововведения принципиальны, то проблемность достигает 99,9%.
Как с Вистой: принес мне директор купленный за неделю до этого ноут Asus G2P в ВистаХомПремиум и тремя фразами:
1. Почему Виста на этом новом крутом ноуте работает куда как медленней, чем ХП на старой Тошибе?
2. Что в ней ТАКОГО полезного, кроме красивостей?
3. Снеси ка ты её нафиг и поставь мне ХП.
Я своими словами передал, ибо дословно не помню, но суть передал однозначно точно.
Принес я ноут к себе, включил, посмотрел на аэро (так что он называется?). Подошел начальник, поковырялся и запустил на выключение. Система задумалась на 15 минут (думал, что это так и должно быть, ибо писали, что у некоторых до 1 часа перезагрузки бывают) и… благополучно вывалилась в BSOD (я был уверен, что его сделали красным). Красота! Но фоткать не успели - ноут пошел в перезагрузку. Но сообщение о нештатной перезагрузке сохранили - могу прислать.
В итоге - Виста (лицензионная), была благополучно снесена и там водрузилась ХР.
Прикольно, но перед установкой инсталлятор ХР выдал при выборе раздела для установки, то загрузочный раздел висты это “OS/2 boot manager”.
В тех же процессорах существуют и обратные примеры, когда существующую функциональность убрали из последующих версий процессоров. Примеры - защищённый режим 286 или некоторые арифметические инструкции присутсвующие в наборе IA-32, но отсутствующие в наборе инструкций amd64. Каждое такое изменение ломало программы, использовавшие эту функциональность. Чтобы количество поломок было минимальным разработчикам процессоров пришлось потрудиться, собирая данные о том, кем и как используется удаляемая функциональность.
Потому что вы упорно требуете принципиальной новизны от Vista, приводя в пример OS/2 AKA eComStation. Вот мне и интересно, где же там принципиальная новизна.
Защищенный режим в 286 убрали из-за того, что всё остальное для поддержки этого режима было как раз недоработано. А вот уже в 386 реализацию довели до ума и отполировали в 486.
Ну а IA32 и AMD64 это как-никак совершенно разные разработчики.
Я про такие опросы не слышал, хотя со многими разработчиками общаюсь. Но обычно в процессорах функциональностью и фиксами ошибок управляют в микрокоде, который в БИОСах хранится.
Нет. Вы не правы. Требую принципиальной новизны от Висты, т.к. её пропагандирует реклама мс. Разве не так? Между тем в нет не осталось ничего из того, что планировалось ранее - ни WinFS ни многого другого.
А привожу OS/2 aka eCS в пример по надежности, удобству и приятному лицу к пользователям. Ибо при всех рюшечках висты реальное удобство в свете DRM, активации, WGA и прочих “удобств” - только в рюшечках, но не в реальном практическом пользовании системы.
Да, внутри переделано что-то. Но реальных эффектов от этого - НОЛЬ. Кроме аномально возвышенных требований к железу за ни за что.
В рамках данной дискуссии совершенно неважно почему его убрали. Важно что фича была, ею пользовались, а потом её убрали. Это ещё раз показывает что спроектировать все правильно заранее нельзя. Внешние условия меняются. Соответственно решать проблему нахождения неиспользуемой функциональности так или иначе приходится.
Понятия не имею. Мне так же не понятно, как можно требовать чего-либо, опираясь лишь на собственную интерпретацию такой неконкретной вещи, как реклама. Вас реклама стиральных порошков не цепляет, часом?
И чем же Вам не понравился мой предыдущий пост, что его стоило удалить?
Не знаю. Я его не удалял. Возможно спам фильтр постарался.
PS: О чём пост-то был?
У меня с утра 6 и, соотв., 7 пост не были видны. Если это не ваша вина, приношу извинения.
Бывает.
Тем не менее все ваши посты модерируются, уж извините. Так что с момента нажатия на “Submit Comment” и до появления комментария на сайте может пройти какое-то время. Если учесть что между нами разница часов 11, то задержка может быть ещё больше.
Я от этого не отказывался.
А писал о том, что при серьезной переработке программы большее внимание должно уделяться не “чистке” от ненужного, а процессу перехода. Тогда и “костыли” можно будет изничтожить.
Лично мне представляется процесс перехода на переработанную версию в два этапа:
1. переработка, без тотальной чистки, и с важнейшим вниманием на миграцию;
2. переработка (подправка), с тотальной чисткой, и с вниманием на саму переработку.
Конечно, всё просто так не делается и процесс перехода очень сложен, но очень важно иметь правильные цели и лучше разбить на этапы - меньше ошибок.
Вообще-то, помнится, Интел засудили, когда у них реклама не сошлась с тем, что было в действительность (про беспроводную работу ноутбуков в горах было дело). Ведь это обман и мошенничество! Правда это было не в России, а где-то в Европе.
Так вы утверждаете, что Виста, это совершенно ничего нового (серьезного)? Так… небольшие переделки?
Кстати, был очень удивлен, прочитав http://www.bezpeka.com/ru/news/2007/06/04/6024.html. Неужели и виста только 64 битная 64 камня держит? Помнится, что OS/2 даже в своем 32 битном варианте 64 процессора держит, причем давно.
Согласен. Хорошо когда это ещё и к тому же возможно на практике.
Это вы утверждаете. Я-то как раз ничего по этому поводу не говорил.
Именно так.
Ничего в ней нет.
Кроме новый требований к “железу”. Нет, я не против вкладов разработчиков и вас в том числе, но рукойводство 
рукойводит криво. И чем дальше, тем больше впечатлене, что главное в работе мс - регресс. Причем чем дальше, тем сильнее… Маразм крепчает…
Жесть… Судя по http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx архитектура win не позволяет ей поддерживать бОльшую память. Если, конечно, это не сделано специально.
Даже за вычетом памяти для работы устройств её больше, чем показывает система. На трех серверах проверил - на всех трех - по разному. Вот же… Хотя, конечно, и сервера разные.
Да и не всегда 4Гб видит система.
Не думаю, что это архитектурное ограничение. Максимум 64GB памяти - это как раз ограничение процессора (36 бит шина). Потом появился AMD c лимитом 1TB (40 бит), но лимит увеличили только до 128GB, так как стали доступны 64-х битные версии системы.
Ограничение на 64 процессора это кстати тоже всего лишь ограничение реализации, так как используется 64-х разрядная маска. А так ядро системы никаких особенных предположений о максимальном количестве процессоров не делает.
Честно говоря, думал, что шина данных у iP 32 битная, а оказалось, что 32 для прямой адресации и дополнительно 4 для страничной. А в AMD и 8 для страничной.
Но если всё равно 4Гб (2^32) для прямой адресации, то непонятно, почему на IBM eServer 346 c 4 Гб W2k3 R2 EE показывает 3,37… Для устройств столько (630 Мб), не нужно - ведь на другом (IBM eServer 346 с 2,5 Гб) всё показывается полностью.
http://support.microsoft.com/kb/929605
Спасибо за ссылку, но это о сВисте, а я смотрел на W2k3 R2 EE.
Похоже, что поиском только я один умею пользоваться. IBM eServer 346 использует Intel E7520 чипсет. HP упонимает о аналогичной проблеме с материнскими платами на этом чипсете: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=PSD_EL041214_CW01 и даёт ссылку на сайт Intel: http://support.intel.com/support/motherboards/server/sb/CS-010458.htm.
Только лечение… Хм… Надо UpdateExpress новый слить…
P.S. Наш разговор уже ушел далеко за пределы темы.