Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, iZEN, Вы писали: iZEN>>OLE == OLE 1. (К примеру, Java 1 тоже в природе не существовало, была просто Java и Java2. Здесь также.) VD>В твоей терминологии. В общепринятой подобный термин не используется. По сути OLE и OLE 2 настолько разные вещи, что понятие "версия" к ним не применимо.
Да ну! Почитай известных авторов, которые писали про ActiveX в то время и убедись в своей безграмотности.
VD>>>Тот факт, что VBX был заменен на OLE Controls после выхода OLE 2 и COM ничего ровным счетом не говорит. iZEN>>Почему? Наоборот! Технология OLE ознаменовала новую модульность, не привязанную к конкретному языку программирования (в данном случае к VB). VD>Ну, и что? Это как-то доказывает связь между VBX и OLE (OLE 1 в твоей классификации)?
Опять ты за своё? Что тебе не даёт спокойно вести беседу?
iZEN>> OLE стала унифицированной моделью для программирования бинарно-переносимых Win32-приложений и протоколов обмена данными в межпроцессном взаимодействии (с объявлением ActiveX и COM). VD>Нда. Очередной поток сознания. Еща раз. Последний. VD>1. OLE не имеет никакого отношения к OLE 2. И OLE и OLE 2 существуют как в 32-битной, так и в 16-битной версии.
Ещё раз: OLE2 это дальнейшее развитие OLE(1), никак иначе.
VD>2. VBX не имеет никакого отношения ни к OLE, ни к OLE 2.
Угу, компоненты OCX (ои же VBX) можно было писать только на VisualC++, но не в VB. Поэтому, наверное, VBX не имеют никакого отношения к OLE x. Рассмешил.
VBX был прототипом для OLE всех версий. VD>3. OLE Controls + балшит == ActiveX. VD>4. COM — это компонентная технология независимая от "битности" процессора на которой основаны OLE 2, ActiveX и многое другое.
А я что, против?
VD>>>Короче, очердной раз говоришь о том, что сам плохо знаешь. Зайди на http://en.wikipedia.org/wiki/ и подставь по очереди все перечисленные тобой базворды. Потом открой http://en.wikipedia.org/wiki/Object_Linking_and_Embedding и почитай реальную историю. iZEN>>Чё такое "базворды"? VD>Волшебные слова вроде ActiveX которыми маркетологи пудрят мозг окружающим.
Не, "баззворды" это что-то для меня недосягаемое, загадочное. Выражайся, пожалуйста, по-русски.
iZEN>>Кстати, я уже использовал Wiki для сопоставления дат выхода операционных систем. Этого оказалось достаточно, чтобы утверждать, что Windows 9x была прототипом для Windows NT. VD>У тебя огромные проблемы с логикой. Если пользоваться твоей "логикой", то так как, скажем, ты младше меня, то я послужил прототипом для тебя.
(Переход на личности проигнорирован. В следующий раз будут разбирательства с модератором конференции.)
iZEN>>Обо всём. В Windows NT 3.51 бы GUI от Windows 3.1x, что совсем не мешало ей быть настоящей 32-битной системой, в отличие от Win3x. VD>Ну, и что? В прочем, не "GUI от Windows 3.1x", а аналогичный. Код там совершенно разный. Да и функциональность отличалась в некоторых случаях. Да и вообще, почему "3.1x"? У 3.0 интерфейс был такой же. Да и 2.0 мало чем отличалась.
Вот ты опять переходишь не в ту степь. Я говорил о конкретном прототипировании и конкретном опробовании так называемых "новых технологий" на людях. И эти "новые технологии" опробовались отнюдь не в Windows NT, но, возможно, рождались там.
iZEN>>В то же время, Win3.1x начала перенимать некоторые 32-битные черты с выходом набора библиотек Win32S, правда, не становясь от этого многозадачной. VD>Что? Ужас какой! То есть если я поставлю на 64-битную ОСь WMWare и запущу из под нее DOS, то мая 64-битная ОСь начнет перенимать черты DOS-а? Круто!
Набор Win32S был прототипом для Win32 API, который родился в WindowsNT, но стал широко доступным для пользователей и разработчиков ещё в Windows 3.1x исходя из требований рынка к унификации API двух ветвей операционных систем. Прототип, как известно, не может полностью заменить оригинал, это просто "затычка" с видимыми эффектами как у оригинала.
iZEN>>Ещё, Windows NT 3.51 не поддерживала длинных имён файлов! VD>Ты уже совсем бредишь. В самой первой версии NT поддерживался NTFS в котором длинна путей практически не ограничивалась.
Я говорю о фактах. Независимо от того, поддерживала или нет длинные имена файлов NTFS, у WindowsNT 3.51 не было средств с ними работать!
iZEN>> Она их резала до 8 символов. Поддержка длинных имён файлов появилась сначала в Windows 95, а потом перешла в Windows NT4. VD>Может быть ты о FAT-32?
Нет, я о WindowsNT 3.51.
iZEN>>Windows 95 имела в реестре дополнительную ветвь AppPath для приложений, инсталляторы которых писали туда строку, содержащую пути к библиотекам DLL и модулям OCX, которые были нужны этим приложениям (строка добавлялась в переменную окружения %PATH% приложения). Эта опция появилась спустя год в реестре Windows NT4.
VD>Нда. Продолжается феерверк невежества. Для OCX ака ActiveX никакие пути не нужны, так как они регистрируются в реестре по ГУИДу в определенных ветках. А AppPath — это какая-то мелочевка.
Это не мелочёвка! Dll- и OCX-файлы при инсталляции в систему должны иметь соответствующий инструмент регистрации regsvr.exe/Regsvr32.exe. Но многие программы не используют регистрацию компонентов, а используют динамичскую линковку библиотек во время запуска и работы, то есть им по барабану, есть ли в реестре запись GUID'ов нужных им библиотек или нет — они находят библиотеки в своём подкаталоге (или из путей, прописанных в переменной AppPath) и подгружают их в свой процесс. Исходя из доктрины полного перехода на Win32 API, кроме как использование дополнительного ключа в реестре невозможно было обеспечить быстрый поиск таких компонентов, а регистрация GUID'ов — второй, не самый лучший способ.
VD>И вообще, кто спорит, что в 95-ых был опробирован десктоп который в дальнешем был использован NT4 и выше. Но это никак не говорит о том, что 95-ые были прототипом для NT. NT появилась значительно раньше и прожила значительно дольше. И все это потому, что она специально проектировалась для своих целей. 95-ые же были проектом переходного периода. В его задачи входили: VD>1. Обеспечение совместимости с 16-битным миром. VD>2. Раобра на слабом железе. VD>3. Перевести пользователей на 32-битный софт (Офис и т.п.). VD>Вот их она выполнила и благополучно умерла. VD>Совместимость с линейкой NT обеспечивается за счет стандартизации Win32 API. Win32 API разрабатывался как универсальный API, а не API для конкретной ОС. Он реализован в NT, 9x и мобильных ОС.
При этом Win32 API обкатывался на "прототипах" Windows 3.1x (Win32S), Windows 9x/ME. Чего ж тут спорить?
iZEN>>Но простые пользователи с этим столкнулись ранее — ещё в Windows 98. Может WDM пришли из Cairo (Windows NT5), мы-то видим обратное: WDM испытывалась на пользователях раньше выхода Windows 2000.
VD>Cairo — это никогда не выходившая версия ОС. WDM, как тебе уже неоднократно сказали — это немного доработанный стандарт драйверов NT. В общем, учи историю. Мне уже надоело одно и то же по сто раз повторять.
Cairo была доступна для разработчиков-бета тестеров. У меня валяется диск с Cairo.
iZEN>>Прочитал:
The Microsoft Windows Driver Model defined a unified driver model for the Windows 98 and Windows 2000 lines by standardizing requirements and reducing the amount of code that needed to be written.
iZEN>>По-моему, исчерпывающая информация. VD>Ага и из нее следует, что 9х прототип для NT.
Точно так.
iZEN>>Да, я тут с FreeBSD балуюсь, VD>Тогда зачем пытаться блестать эрудицией в других областях?
Интересно же. Ведь собеседник должен по идее оказаться более сведующим в области спора. Жаль, что этого не происходит.
iZEN>> у которой Microsoft позаимствовала стэк TCP/IP... VD>Да ну? Ты и тут все знаешь? VD>А как можно объяснить тот факт, что у МС стэк TCP/IP был реализован еще для Windows for Workgroups 3.11 появившеся в 1993-ем, в то время как в 1993-ем Фришку только начали разрабатывать? Да и вообще, интересно, как же в МС умудрились повзавимствовать 16-битный код из 32-битной ОС?
Да ты что! Таких элементарных вещей не знаешь!
Стэк TCP/IP разработан в рамках проекта BSD в сентябре 1983 года. Разработка FreeBSD началась в 1993 году, в качестве отправной точки были взяты исходные тексты 386BSD. Однако, из соображений законности использования исходных кодов 386BSD, команда разработчиков FreeBSD переработала большую часть системы ко времени выпуска FreeBSD 2.0 в январе 1995 г., используя 4.4BSD-Lite. (с) ru.wikipedia.org
Чем являлась FreeBSD и чем просто-BSD показывает диаграмма:
В момент начала разработки Windows 3.1 (1991 год, выпуск 1992 год) поддержку TCP/IP обеспечивала сторонняя библиотека Winsock, базировавшаяся на "Berkeley sockets".
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).
Бу-га-га.
MSS>Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.
Я таких граблей, на которые натыкался, но которые можно было бы обнаружить "глазами" не припомню вообще.
L>>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,
MSS>Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...
Это так тяжело потратить всего лиш человеко-месяц на investigation? Тяжело вам там.
ЗЫ. Такое впечатление, что ты под "написать прототит" понимаеш "написать прогу со всем функционалом десятью разными способами", а не "потратить одну сотую от общего времени разработки на исследование".
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, iZEN, Вы писали:
VD>Ты меня извини, но твоя некомпетентность в данном вопросе превышае разумные пределы. Читать ту же Вики с целью ее искоренения ты явно не намерен.
VD>В таких условиях говорить с тобой о чем-то просто бессмысленно. Нельзя апеллировать к бурной фантазии .
Друзья, без обид... Но после прочтения вашего короткого но бурного диалога, возникло ощущение, что один из вас является прототипом другого...
Здравствуйте, iZEN, Вы писали:
ZEN>Алан Купер советует выбрасывать прототип без сожаления.
Аналогично Фредерик Брукс еще с 1975 года. В его МЧ-М есть целая глава с названием "Планируйте на выброс". Цитата из начала:
Глава 11. Планируйте на выброс
В этом мире нет ничего постояннее непостоянства.
СВИФТ
Разумно взять метод и испытать его. При неудаче честно признайтесь в этом и попробуйте другой метод. Но главное, делайте что-нибудь.
ФРАНКЛИН Д. РУЗВЕЛЬТ
Опытные заводы и масштабирование
Инженеры-химики давно поняли, что процесс, успешно осуществляемый в лаборатории, нельзя одним махом перенести в заводские условия. Необходим промежуточный шаг, создание опытного завода, чтобы получить опыт наращивания количеств веществ и функционирования в незащищенных средах. К примеру, лабораторный процесс опреснения воды следует проверить на опытном заводе мощностью 50 тысяч литров в день, прежде чем использовать в городской системе водоснабжения мощностью 10 млн. литров в день.
Разработчики программных систем тоже получили этот урок, но, похоже, до сих пор его не усвоили. В одном проекте за другим разрабатывают ряд алгоритмов и затем начинают создавать поставляемое клиенту программное обеспечение по графику, требующему поставки первой же сборки.
В большинстве проектов первой построенной системой с трудом можно пользоваться. Она может быть слишком медленной, слишком большой, неудобной в использовании, а то и все вместе. Не остается другой альтернативы, кроме как, поумнев, начать сначала и построить перепроектированную программу, в которой эти проблемы решены. Браковка и перепроектирование могут делаться для всей системы сразу или по частям. Но весь опыт разработки больших систем показывает, что будет сделано.2 В тех случаях, когда используются новые системные концепции и новые технологии, приходится создавать систему на выброс, поскольку даже самое лучшее планирование не столь всеведуще, чтобы попасть в цель с первого раза.
Поэтому проблема не в том, создавать или нет опытную систему, которую придется выбросить. Вы все равно это сделаете. Вопрос единственно в том, планировать ли заранее разработку системы на выброс или обещать клиентам поставку системы, которую придется выбросить. Если смотреть под этим углом, ответ становится намного проще. Поставка хлама клиенту позволяет выиграть время, но происходит это ценой мучений пользователя, отвлечений разработчиков во время перепроектирования и дурной репутации продукта, которую даже самой удачно перепроектированной программе будет трудно победить.
Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.
...
К этой теме также примыкает другая глава, под названием "Эффект второй системы".
ZEN>Как делалась Windows 95 и как делалась Windows NT? Что в итоге получилось всем ясно.
Вот, цитата из главы резюмирующей все утверждения книги, написанная спустя 20 лет после издания:
Глава 5. Эффект второй системы
5.1 Связь, установленная на ранних этапах и продолжающаяся непрерывно, может дать архитектору верную оценку стоимости, а разработчику — уверенность в проекте, не снимая при этом четкого разграничения сфер ответственности.
5.2 Как архитектору успешно влиять на реализацию:
— Помнить, что ответственность за творчество, проявляемое при реализации, несет строитель, поэтому архитектор только предлагает.
— Всегда быть готовым предложить некоторый способ реализации своих замыслов и быть готовым согласиться с любым другим способом, который не хуже.
— Выдвигая такие предложения, действовать тихо и частным образом.
-Не рассчитывать на признательность за предложенные усовершенствования.
-Выслушивать предложения разработчиков по усовершенствованию архитектуры.
5.3 Из всех проектируемых систем наибольшую опасность представляет вторая по счету; обычно ее приходится перепроектировать заново. 5.4 OS/360 является ярким примером эффекта второй системы. (Похоже, что Windows NT — это пример для 1990 года.)
5.5 Достойной внимания практикой является предварительное назначение функциям величин в байтах и микросекундах.
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
MSS>Все остальное можно сразу начисто писать.
Классическая война "остроконечников" с "тупоконечниками".
По моему опыту, создание прототипа очень помогает в случае работы с "проектами со сложностью вширь". Есть такие специальные проекты, в которых водится много страшных слов типа Business Logic, GUI, взаимодействий компонентов, клиентских требований и т.д — например, системы учета и контроля. Тут прототиапы очень сильно рулят. Собственно, as for me, самой главной целью прототипа является упорядочивание хаоса в мозгах заказчиков и разработчиков.
В случае "проектов со сложностью вглубь" идея прототипирования никуда не годится. В эту группу проектов относятся драйвера, сетевые системы, системы безопасности, DRM всякие и т.д. "Маленькие тесты" в таких проектах естественным образом получатся в результате каждого research'а по конкретной задаче.
З.Ы. Вот не знаю, как обстоит ситуация в геймдеве, не привлекался
Здравствуйте, Maxim S. Shatskih, Вы писали:
ZEN>>Да, я тут с FreeBSD балуюсь, у которой Microsoft позаимствовала стэк TCP/IP...
MSS>Это просто ложь ненавистников Микрософта, причем всем известная.
А вот это тогда как понимать:
/* WINSOCK.H--definitions to be used with the WINSOCK.DLL
* Copyright (c) Microsoft Corporation. All rights reserved.
*
* This header file corresponds to version 1.1 of the Windows Sockets specification.
*
* This file includes parts which are Copyright (c) 1982-1986 Regents
* of the University of California. All rights reserved. The
* Berkeley Software License Agreement specifies the terms and
* conditions for redistribution.
*
*/
...
/*
* Basic system type definitions, taken from the BSD file sys/types.h.
*/
...
/*
* Structure used in select() call, taken from the BSD file sys/time.h.
*/
...
?
P.S.
Конечно, не из FreeBSD, скорее из какой-то более ранней BSD.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Поддержка со стороны среды нужна только новичкам в данной технологии. Продвинутым — не нужна.
Каждый имеет право на свою точку зрения. Лично я выигрываю не от красивости представления, а скорее от подсветки синтаксиса, automplete и refactoring. Даже отлично зная какие-то вещи, всегда выгоднее затратить пару нажатий на кнопки, чем десяток. При прочих равных условиях это — вполне себе аргумент.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>это полу-баги типа "не обрабатывает вот такой вот corner case", или "мы хотим более детальный вывод в лог", или "локализуйте нам лог на японский"
странно, я почему то считал, что это зовется фичреквест...
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано. RRM>- Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше. RRM>- Переиспользовать часть, часть сделать заново
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Ой, старая мозоль
Мне нравится такая методика.
В начале разработки системы выясняются задачи, которые будет решать оная. Т.е. берем юзкейсы (если есть) или просто список функциональных требований, и
стряпаем ГУИ, который и будет отражением этих самых требований.
Короче, первый прототип.
Его можно показывать заказчикам и потенциальным пользователям, чтобы они потрогали его руками. Не представляете, сколько замечаний, поправок и пояснений
получите по поводу функциональных требований! Это здорово, т.к. позволяет заметно снизить риск появления существенных изменений требований в более поздних фазах разработки, когда они будут стоить очень дорого.
Далее.
Изучая и развлекаясь с прототипом №1, анализируем нефункциональные требования. Например, понимаем, что в комбобокс со справочником будет грузиться аж 10000 элементов, и пользователь Вас потом найдет и застрелит Значит, нужно далеть "ленивую" загрузку или просто по частям. Или приложению понадобятся обновления. Или нужно продумать сценарии синхронизации клиентского и серверного кэшей.
Короче, пытаемся просчитать, КАК система будет делать желаемое.
И делаем прототип №2 (а так же №3, №4, и сколько не лень), главное, чтобы в нем не было каши из разных непересекающихся задач.
А теперь рассмотрим, как быть с релизом
Собственно, прототипы и основной проект должны развиваться почти параллельно (основной, понятно, отставать).
Т.е. благодаря прототипу решили проблему, все проверили и резко уменьшили риск, связанный с последующими изменениями — а теперь переносим решение в основной проект. Не "copy&paste" (не вздумайте, а то в релиз попадет мусор и неряшливый код из тестов), а по-новой, вооруженные новым опытом.
В общем, разработка получается хорошо контролируемой, хотя, в первой половине занимает больше времени (до 30%, наверное). Зато, перевалив за середину, проект идет к завершению быстрее за счет гораздо меньшего количества правок, гораздо более ясного кода и случайных ошибок, вызванных поиском причин других ошибок
Теперь о проблемах.
Проблемы будут с малограмотным начальством, которое может увериться, что прототип (даже ГУИ, как не смешно) — это почти готовый продукт. Соответственно, нужно постоянно держать обратную связь с начальством/заказчиком, демонстрирую при помощи прототипов решение конкретных, отдельных проблем и не более того. Ну и ликбез, само собой.
Все в детстве писали сочинения/изложения? Так вот прототип — это черновик.
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
Собственно вопрос — что дальше? что делать с этим прототипом?
— С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано.
— Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше.
— Переиспользовать часть, часть сделать заново
Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
Совсем не обязательно. Это гигантский расход ресурсов.
Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
Все остальное можно сразу начисто писать.
RRM>Собственно вопрос — что дальше? что делать с этим прототипом?
Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Я не считаю, что есть универсальный путь, мне интересно у кого, что было. Как положительный опят так и отрицательный
Всяко бывало. От полного копирования прототипа в рабочий проект без изменений до полного переписывания.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, RailRoadMan, Вы писали:
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано.
Все просто! Когда возможно причесать и привести в нормальный вид, то так и надо делать, а если не получается, то писать заново.
Лично я сейчас пишу заново, т.к. прототип написал на динамически типизированном языке.
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Тут все зависит от случая, я думаю нельзя какой-то единственно верный путь найти. Вообщем здравый смысл рулит
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, iZEN, Вы писали:
ZEN>>Как делалась Windows 95 и как делалась Windows NT? Что в итоге получилось всем ясно.
Кё>Вообще-то NT 3.1 вышла раньше чем Windows 95
Вообще-то, я о том, что Windows 95 унаследовала кучу 16-битного кода от своей предшественницы и плохо масштабировалась. Была ненадёжной.
Windows NT писалась с нуля. Из "прототипа" Windows 95 брались лучшие, обкатанные идеи и переносились в Windows NT. Windows 95 продолжала оставаться прикладным (но не системным!) полигоном для NT-линейки вплоть до объявления о слиянии линеек в одну на основе ядра NT.
L>Арабская мудрость гласит: "Чтобы сделать что-то хорошо, нужно сделать это как минимум дважды". Так вот писАть "сразу и навсегда" это имхо из разряда "in the perferct world" — было бы замечательно, и менеджеры были бы довольны — сильно упростилось бы у них планирование проектов — но в большинстве случаев у реальных разработчиков не получается.
А может, стоит зарплаты поднять и кадровую политику пересмотреть?
P.S. Я занимался программированием в нескольких командах, каждая из которых сделала по достаточно сложному продукту. Так вот, Я НИ РАЗУ не видел, чтобы при написании кода хотя бы в одной из этих команд — а они сильно разные — использовался бы подход с "черновиком". Это для меня вообще новое слово в программировании
ZEN>Windows NT писалась с нуля. Из "прототипа" Windows 95 брались лучшие, обкатанные идеи и переносились в Windows NT. Windows 95 продолжала оставаться прикладным (но не системным!) полигоном для NT-линейки вплоть до объявления о слиянии линеек в одну на основе ядра NT.
Windows 95 НЕ разрабатывалась с целью создания прототипа для Windows NT, это совершенно очевидно.
Целью ее разработки было — получить полноценно многозадачную и почти полноценно 32битную ОС _с меньшими требованиями к памяти, чем НТ_.
Когда требования к памяти у НТ перестали быть напряжными — линейка Win9x стала умирать. WinMe был просто провальный продукт.
И исторически сначала сделали НТ, а уже потом — Win32 над старым VMM и 16битными GDI и USER, что и есть Win95. Т.е. поток идей шел из НТ в 95, а не наоборот.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>P.S. Я занимался программированием в нескольких командах, каждая из которых сделала по достаточно сложному продукту. Так вот, Я НИ РАЗУ не видел, чтобы при написании кода хотя бы в одной из этих команд — а они сильно разные — использовался бы подход с "черновиком". Это для меня вообще новое слово в программировании
Может "черновичники" просто не знают что такое пересмотр кода (refactoring)?
Конечно, иногда большой массив кода проще выкинуть и переписать, но, насколько понял, сейчас идет речь про маленькие компоненты.
MSS>P.S. Я занимался программированием в нескольких командах, каждая из которых сделала по достаточно сложному продукту. Так вот, Я НИ РАЗУ не видел, чтобы при написании кода хотя бы в одной из этих команд — а они сильно разные — использовался бы подход с "черновиком". Это для меня вообще новое слово в программировании
Ну а лично я сталкивался. К примеру — есть достаточно большой проект, в котором будет использоваться технология SuperPuperMegaWidgets, незнакомая или слабо знакомая разработчикам (по разным причинам, к примеру — технология только что появилась, или сама по себе достаточно нишевая, или или...). Так вот, ИМХО в таком случае написание прототипа с последующим выкидыванием бОльшей части его кода весьма даже оправдано. Т.е. за время написания прототипа разработчики ознакомятся с технологией, её достоинствами и граблями, архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией, заказчик посмотрит на прототип и сможет определиться то ли это вообще что ему нужно... Естественно, что такой подход с написанием прототипа имеет свою нишу и не подходит, к примеру, для проектов небольшого размера, или слабо оправдан если у разработчиков за плечами куча опыта по разработке подобных систем. Но тем не менее я считаю что своя ниша у него есть.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
По моему, в "Программисте-прагматике" для предотвращения подобной ситуации авторы советуют прототип писать не на вашем основном рабочем языке. Если пишете на C#, то сделайте прототип, для обкатки решения, на VB или Delphi.
Основной аргумент против доделок — прототип делается, чтобы быстро дойти до работоспособного варианта, а не до рабочего. Объем доработок и/или исправлений может быть сравним или превысить объем работы необходимый для полного переписывания прототипа.
Хотя, как правило, некоторые части прототипа в финальном решении используются.
L>>Ну а лично я сталкивался. К примеру — есть достаточно большой проект, в котором будет использоваться технология SuperPuperMegaWidgets, незнакомая или слабо знакомая разработчикам (по разным причинам, к примеру — технология только что появилась, или сама по себе достаточно нишевая, или или...). MSS>Вот эта ситуация как правило есть чья-то блажь кто-то начитался рекламок о технологии.
Хм. Реклама рекламой, но работать с технологией рано или поздно надо начинать.
L>>Так вот, ИМХО в таком случае написание прототипа с последующим выкидыванием бОльшей части его кода весьма даже оправдано. Т.е. за время написания прототипа разработчики ознакомятся с технологией, её достоинствами и граблями, MSS>Опять изучаем грабли путем наступания на них?
К сожалению, я не знаю другого эффективного пути обучения.
MSS>Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).
Этого конечно никто не отменял. Но по-настоящему технологию узнаешь только потрогав её руками. Документация-примеры — это всегда только начало, процентов 30 пути.
MSS>Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.
In the perferct world
L>>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией, MSS>Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...
Во-1 — я назвал несколько причин, а не только для того чтобы менеджер что-то понял. А во-2 — если на кону стоят человеко-годы, то можно рискнуть человеко-месяцем (в крайнем случае прототип отправляется в топку вместе с технологией).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).
ANS>Бу-га-га.
MSS>>Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.
ANS>Я таких граблей, на которые натыкался, но которые можно было бы обнаружить "глазами" не припомню вообще.
L>>>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,
MSS>>Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...
ANS>Это так тяжело потратить всего лиш человеко-месяц на investigation? Тяжело вам там.
ANS>ЗЫ. Такое впечатление, что ты под "написать прототит" понимаеш "написать прогу со всем функционалом десятью разными способами", а не "потратить одну сотую от общего времени разработки на исследование".
Согласен. Аффтар, похоже, только со студенческой скамьи слез В бой рвется, шашкой махать
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, Maxim S. Shatskih, Вы писали:
AP>>По моему, в "Программисте-прагматике" для предотвращения подобной ситуации авторы советуют прототип писать не на вашем основном рабочем языке. Если пишете на C#, то сделайте прототип, для обкатки решения, на VB или Delphi.
MSS>Авторы жгут не по-детски. Иначе и не скажешь.
MSS>То есть — помимо "боевого" языка, всей командой выучить еще и "учебный"? а ведь любой язык, даже учебный — имеет свои заморочки и подводные камни.
На самом деле я совершенно исказил цитату, или всё-таки это была другая книга
Вот что пишут в Pragmatic programmer
Since a prototype should gloss over details, and focus in on specific aspects of the system being considered, you may
want to implement prototypes using a very high-level language—higher than the rest of the project (maybe a language
such as Perl, Python, or Tcl). A high-level scripting language lets you defer many details (including specifying data
types) and still produce a functional (albeit incomplete or slow) piece of code.[6] If you need to prototype user
interfaces, investigate tools such as Tcl/Tk, Visual Basic, Powerbuilder, or Delphi.
Автору топика рекомендую поискать эту книгу (Pragmatic Programmer) — позиция авторов по поводу прототипирования аргументирована и адекватна.
Раздел Prototypes and Post-it Notes
How Not to Use Prototypes
Before you embark on any code-based prototyping, make sure that everyone understands that you are writing
disposable code. Prototypes can be deceptively attractive to people who don't know that they are just prototypes.
You must make it very clear that this code is disposable, incomplete, and unable to be completed.
It's easy to become misled by the apparent completeness of a demonstrated prototype, and project sponsors or
management may insist on deploying the prototype (or its progeny) if you don't set the right expectations. Remind
them that you can build a great prototype of a new car out of balsa wood and duct tape, but you wouldn't try to drive
it in rush-hour traffic!
If you feel there is a strong possibility in your environment or culture that the purpose of prototype code may be
misinterpreted, you may be better off with the tracer bullet approach. You'll end up with a solid framework on which
to base future development.
When used properly, a prototype can save you huge amounts of time, money, pain, and suffering by identifying and
correcting potential problem spots early in the development cycle—the time when fixing mistakes is both cheap and
easy.
L>>Хм. Реклама рекламой, но работать с технологией рано или поздно надо начинать. MSS>Зачем надо? кому надо? в чем смысл слова "надо"? с целями деятельности определиться надо.
Ну, это несложно. Цель деятельности программерской конторы — разработка ПО за деньги. Зачастую новые проекты требуют использования новых (не обязательно новых в плане возраста) технологий, с которыми никто в команде (в конторе) ещё не работал.
L>>К сожалению, я не знаю другого эффективного пути обучения. MSS>А я знаю. Книжки, документация, примерчики. Этих трех вещей хватает, чтобы просто сесть и пойти вперед в разработке. Без прототипов и черновиков. MSS>90. Документация-примеры-общение на профильных форумах = 90%.
Э... Не все технологии одинаково хорошо документированны. Есть такие по которым и книжек днём с огнём не сыщешь, и примеры покрывают 10% юзкейсов, и документация оставляет желать лучшего. Предлагаешь отказаться от проекта пока технология не вызреет настолько что появятся все составляющие успеха? Предполагаю что иногда так и делают, но не все и не всегда.
L>>In the perferct world MSS>В реальной практике всех моих 15 лет профессиональной деятельности. Никто — повторяю, никто — не писал черновики на выброс, чтобы освоиться с технологией.
Ну а я в реальной практике за 12 лет профессиональной деятельности раза 2 или 3 сталкивался лично, и ещё несколько раз слышал про подобное от коллег. Бывают, бывают ситуации когда это оправдано. Пойми, мил человек — я не к тому что ты что-то неправильно делал или что-то неправильно понимаешь. Просто индустрия IT нынче разрослась ну шибко широко, и то что в одном её краю кажется идиотизмом и расходом средств впустую — в другом вполне себе оправданная практика.
Здравствуйте, iZEN, Вы писали:
ZEN>Интерфейс пользователя WinNT4 (win32.sys и comctl.dll) оттачивался на Win95 и только после этого в 1996 году была выпущена WinNT4 с интерфейсом "как у Win95".
Сам то понял что сказал?
ZEN>OLE/OLE32 и ActiveX первоначально обкатывались в Win3x/Win95 и только потом переносились в NT-линейку.
OLE — это вообще прошлый век существоваший только в 16-битном мире (как набор сообщений Виндовс).
OLE32 никогда не было в природе. Было OLE 2. Так вот OLE 2 — это набор СOM-интерфейсов независимый от платформы. А COM как раз и разрабатывался для него. И специальной поддержки COM в ОС не требуется. Вот DCOM-это другое дело. Причем в Win16 его вообще не было. А в 95-ых он ставился отдельно. И только в НТ он поставлялся и поставяется в составе ОС.
ZEN>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
Каких еще драйверов? Причем тут драйверы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, iZEN, Вы писали:
ZEN>>Интерфейс пользователя WinNT4 (win32.sys и comctl.dll) оттачивался на Win95 и только после этого в 1996 году была выпущена WinNT4 с интерфейсом "как у Win95".
VD>Сам то понял что сказал?
Угу. Explorer оттачивался в Win9x, а только потом переносился в NTx.
iZEN>>OLE/OLE32 и ActiveX первоначально обкатывались в Win3x/Win95 и только потом переносились в NT-линейку.
VD>OLE — это вообще прошлый век существоваший только в 16-битном мире (как набор сообщений Виндовс). VD>OLE32 никогда не было в природе. Было OLE 2. Так вот OLE 2 — это набор СOM-интерфейсов независимый от платформы. А COM как раз и разрабатывался для него. И специальной поддержки COM в ОС не требуется. Вот DCOM-это другое дело. Причем в Win16 его вообще не было. А в 95-ых он ставился отдельно. И только в НТ он поставлялся и поставяется в составе ОС.
OLE, оно же OLE16, оно же VB OCX. Модули для программирования приложений в VisualBasic, писались на MS VisualC++ начиная с Windows3.1.
OLE2, оно же OLE32, позднее переименовано в ActiveX и COM (Component Object Model). Под эту модель затачивался реестр 32-битных версий Windows.
Windows 95 вышла в августе 1995 года. Windows NT4 вышла в июле 1996 года. Прототипирование и обкатка технологий прослеживается как нигде, особенно в прикладных вещах.
iZEN>>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
VD>Каких еще драйверов? Причем тут драйверы?
Windows Driver Model — *.WDM
Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
(Ты ж вроде на Windows и должен помнить историю. )
Здравствуйте, Maxim S. Shatskih, Вы писали: MSS>90. Документация-примеры-общение на профильных форумах = 90%.
Ну это если брать технологии 90х годов, то да. Уже и профильные форумы под завязку набиты; и документация есть, и статьи/примеры и т.п.
А с чем-то более-менее новым... Вот сейчас, к примеру, развивается WPF и Silverlight. Я бы лично не рискнул сразу рисовать ТЗ на Silverlight и бросаться реализовывать финальную версию. Потому что на данном этапе я затрудняюсь не только стоимость, но и вообще реализуемость какого-либо проекта оценить.
Много лет назад была у меня задача: разработать свой Mail-клиент. Под винду. Я, будучи наслышан о MAPI, почитал поподробнее документацию, убедился что таки да — всё ровно для меня, все тонкости взаимодействия с POP3/SMTP уже реализованы, осталось только UI написать. Оценил задачу, начал колбасить.
И только тогда, когда приложение было на 90% готово, оказалось, что в очередной версии микрософт молча убрала программную отправку почты. Т.е. метод есть, возвращает S_OK, но ничего не происходит. Пришлось за выходные полностью переписать всё что касалось отправки и получения почты. Только запуск интерактивного аутлука выполняет собственно отправку.
Вот тебе и 10%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ZEN>>POP3/SMTP, вообще-то, примитивные и простые протоколы обмена информацией, основанные служебных "командах" в формате ASCII. S>И какое отношение это имеет к теме разговора? S>А насчет POP3/SMTP я в курсе. Так, в качестве упражнения на дом: сколько RFC необходимо изучить, чтобы принять (или отправить) русскоязычное письмо с аттачментом?
Ориентировочно 2 десятка (это если не реализовывать самому SSL-enabled протоколы). Но дело даже не в RFC, а в том чтобы сделать парсинг Mime контента письма так же, как это делает Outlook. А там ньюансов — на человекогод (hint — далеко не все письма удовлетворяют RFC, но показывать их всё равно нужно).
Да, кстати — году эдак в 2004-м MS открыла интерфейсы для парсина mime-content <--> MAPI object. Правда, ЕМНИП, только для Outlook 2003 и старше.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>OLE 2.0 и COM появились в 16 битах как охапка redistributable DLLs (COMPOBJ и прочие) в 1993 году.
MSS>Офис того года выпуска, как и CorelDraw, пользовался этой технологией.
Ну, и чем это противоречит моим словам? Он с тем же успехом появился и для NT который появился в том же 1993-ем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>OLE, оно же OLE16, оно же VB OCX. Модули для программирования приложений в VisualBasic, писались на MS VisualC++ начиная с Windows3.1.
ZEN>OLE2, оно же OLE32, позднее переименовано в ActiveX и COM (Component Object Model). Под эту модель затачивался реестр 32-битных версий Windows.
OLE 2 было в двух версиях 16 и 32 бита. OLE 1 вообще в природе не существовало. Было просто OLE. VBX никакого отношения к OLE не имел. Тот факт, что VBX был заменен на OLE Controls после выхода OLE 2 и COM ничего ровным счетом не говорит.
Короче, очердной раз говоришь о том, что сам плохо знаешь. Зайди на http://en.wikipedia.org/wiki/ и подставь по очереди все перечисленные тобой базворды. Потом открой http://en.wikipedia.org/wiki/Object_Linking_and_Embedding и почитай реальную историю.
ZEN>Windows 95 вышла в августе 1995 года. ZEN> Windows NT4 вышла в июле 1996 года. Прототипирование и обкатка технологий прослеживается как нигде, особенно в прикладных вещах.
Ну, и что? А 3.51 вышла приблизительно с 95-ыми и для нее был доступен десктоп аля 95-ые. Я себе скачивал и ставил.
О чем вообще по-твоему говорит тот факт, что в 95-ых прикрутили какой-то там новый ГУЙ?
iZEN>>>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
VD>>Каких еще драйверов? Причем тут драйверы?
ZEN>Windows Driver Model — *.WDM ZEN>Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
Ага. Тебе тут уже ответили рядом. Если не веришь сходи опять же в Вики http://en.wikipedia.org/wiki/Windows_Driver_Model и почитай, про то откуда взялся WDM.
ZEN>(Ты ж вроде на Windows и должен помнить историю. )
Ага. В отличии от тебя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>OLE == OLE 1. (К примеру, Java 1 тоже в природе не существовало, была просто Java и Java2. Здесь также.)
В твоей терминологии. В общепринятой подобный термин не используется. По сути OLE и OLE 2 настолько разные вещи, что понятие "версия" к ним не применимо.
VD>>Тот факт, что VBX был заменен на OLE Controls после выхода OLE 2 и COM ничего ровным счетом не говорит.
ZEN>Почему? Наоборот! Технология OLE ознаменовала новую модульность, не привязанную к конкретному языку программирования (в данном случае к VB).
Ну, и что? Это как-то доказывает связь между VBX и OLE (OLE 1 в твоей классификации)?
ZEN> OLE стала унифицированной моделью для программирования бинарно-переносимых Win32-приложений и протоколов обмена данными в межпроцессном взаимодействии (с объявлением ActiveX и COM).
Нда. Очередной поток сознания. Еща раз. Последний.
1. OLE не имеет никакого отношения к OLE 2. И OLE и OLE 2 существуют как в 32-битной, так и в 16-битной версии.
2. VBX не имеет никакого отношения ни к OLE, ни к OLE 2.
3. OLE Controls + балшит == ActiveX.
4. COM — это компонентная технология независимая от "битности" процессора на которой основаны OLE 2, ActiveX и многое другое.
VD>>Короче, очердной раз говоришь о том, что сам плохо знаешь. Зайди на http://en.wikipedia.org/wiki/ и подставь по очереди все перечисленные тобой базворды. Потом открой http://en.wikipedia.org/wiki/Object_Linking_and_Embedding и почитай реальную историю.
ZEN>Чё такое "базворды"?
Волшебные слова вроде ActiveX которыми маркетологи пудрят мозг окружающим.
ZEN>Кстати, я уже использовал Wiki для сопоставления дат выхода операционных систем. Этого оказалось достаточно, чтобы утверждать, что Windows 9x была прототипом для Windows NT.
У тебя огромные проблемы с логикой. Если пользоваться твоей "логикой", то так как, скажем, ты младше меня, то я послужил прототипом для тебя.
ZEN>Обо всём. В Windows NT 3.51 бы GUI от Windows 3.1x, что совсем не мешало ей быть настоящей 32-битной системой, в отличие от Win3x.
Ну, и что? В прочем, не "GUI от Windows 3.1x", а аналогичный. Код там совершенно разный. Да и функциональность отличалась в некоторых случаях. Да и вообще, почему "3.1x"? У 3.0 интерфейс был такой же. Да и 2.0 мало чем отличалась.
ZEN>В то же время, Win3.1x начала перенимать некоторые 32-битные черты с выходом набора библиотек Win32S, правда, не становясь от этого многозадачной.
Что? Ужас какой! То есть если я поставлю на 64-битную ОСь WMWare и запущу из под нее DOS, то мая 64-битная ОСь начнет перенимать черты DOS-а? Круто!
ZEN>Ещё, Windows NT 3.51 не поддерживала длинных имён файлов!
Ты уже совсем бредишь. В самой первой версии NT поддерживался NTFS в котором длинна путей практически не ограничивалась.
ZEN> Она их резала до 8 символов. Поддержка длинных имён файлов появилась сначала в Windows 95, а потом перешла в Windows NT4.
Может быть ты о FAT-32?
ZEN>Windows 95 имела в реестре дополнительную ветвь AppPath для приложений, инсталляторы которых писали туда строку, содержащую пути к библиотекам DLL и модулям OCX, которые были нужны этим приложениям (строка добавлялась в переменную окружения %PATH% приложения). Эта опция появилась спустя год в реестре Windows NT4.
Нда. Продолжается феерверк невежества. Для OCX ака ActiveX никакие пути не нужны, так как они регистрируются в реестре по ГУИДу в определенных ветках. А AppPath — это какая-то мелочевка.
И вообще, кто спорит, что в 95-ых был опробирован десктоп который в дальнешем был использован NT4 и выше. Но это никак не говорит о том, что 95-ые были прототипом для NT. NT появилась значительно раньше и прожила значительно дольше. И все это потому, что она специально проектировалась для своих целей. 95-ые же были проектом переходного периода. В его задачи входили:
1. Обеспечение совместимости с 16-битным миром.
2. Раобра на слабом железе.
3. Перевести пользователей на 32-битный софт (Офис и т.п.).
Вот их она выполнила и благополучно умерла.
Совместимость с линейкой NT обеспечивается за счет стандартизации Win32 API. Win32 API разрабатывался как универсальный API, а не API для конкретной ОС. Он реализован в NT, 9x и мобильных ОС.
ZEN>Но простые пользователи с этим столкнулись ранее — ещё в Windows 98. Может WDM пришли из Cairo (Windows NT5), мы-то видим обратное: WDM испытывалась на пользователях раньше выхода Windows 2000.
Cairo — это никогда не выходившая версия ОС. WDM, как тебе уже неоднократно сказали — это немного доработанный стандарт драйверов NT. В общем, учи историю. Мне уже надоело одно и то же по сто раз повторять.
ZEN>Прочитал:
The Microsoft Windows Driver Model defined a unified driver model for the Windows 98 and Windows 2000 lines by standardizing requirements and reducing the amount of code that needed to be written.
ZEN>По-моему, исчерпывающая информация.
Ага и из нее следует, что 9х прототип для NT.
ZEN>Да, я тут с FreeBSD балуюсь,
Тогда зачем пытаться блестать эрудицией в других областях?
ZEN> у которой Microsoft позаимствовала стэк TCP/IP...
Да ну? Ты и тут все знаешь?
А как можно объяснить тот факт, что у МС стэк TCP/IP был реализован еще для Windows for Workgroups 3.11 появившеся в 1993-ем, в то время как в 1993-ем Фришку только начали разрабатывать? Да и вообще, интересно, как же в МС умудрились повзавимствовать 16-битный код из 32-битной ОС?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
D>Feasibility study — стандартная вещь. Выбрать одну из нескольких подходящих технологий, проверить практическое быстродействие, оценить поддержку со стороны IDE и т.д.
Поддержка со стороны среды нужна только новичкам в данной технологии. Продвинутым — не нужна.
Например, редактор свойств и методов ATL OA объектов, который был еще в MSVC 5 вроде как. Мы через полгода бросили им пользоваться и стали писать IDL файлы руками с подробными комментариями (самодокументация).
Дело в том, что эта поддержка нужна только для того, чтобы скрыть от ламера детали IDL файла. От не-ламера их можно и не скрывать.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Еще раз повторю: написание больших черновиков, чтобы поощущать технологию и посмотреть, что получится — сочли бы бредом все мои бывшие и нынешние работодатели.
ANS>>А что они оценили бы?
MSS>Написание сразу начисто. Чтобы, если заработает — сразу делать продукт минимальными усилиями.
В выделенном ты противоречишь своему же высказыванию в верху.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Спильный Андрей, Вы писали:
СА>>вы точно уверены, что "winsock придуман в Berkley"?
AVK>В Беркли, естественно не конкретно WinSock придумали
уже легче...
а то предыдущий пост воспринимался как "динозавры произошли от украинцев"
AVK>, а sockets API. А winsock это его вариант, реализованный в Windows. AVK>http://en.wikipedia.org/wiki/Berkeley_sockets
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Действительно никакой, подтверждаю. И даже не коллега. Это вообще-то довольно распространенное обращение, к реальной дружбе отношения не имеющее. Оно служит для добавления в текст некоторого оттенка доброжелательности по отношению к собеседникам.
Интересный такой оттеночек. Бросаешь грязи и для предания оттенка добавляшь "дружище!" .
VD>>Но обижаться действительно просто не на кого.
KV>А (если не секрет), на чем основано это суждение?
На разных факторах. Например, на твоих сообщениях... Ну, вот еще на основании того может ли человек себе такое позволить или нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Действительно никакой, подтверждаю. И даже не коллега. Это вообще-то довольно распространенное обращение, к реальной дружбе отношения не имеющее. Оно служит для добавления в текст некоторого оттенка доброжелательности по отношению к собеседникам.
VD>Интересный такой оттеночек. Бросаешь грязи и для предания оттенка добавляшь "дружище!" .
О какой грязи речь? Если по существу вопроса — то прав ты, а не iZEN. Если по тому, как ты свою правоту ему доказывал — это было резко, с пренебрежением и переходом на личности. Также как и с его стороны, в общем-то. И шутя насчет прототипов, я подразумевал именно манеру общения, а не познания в истории разработки windows либо что-то еще.
VD>>>Но обижаться действительно просто не на кого.
KV>>А (если не секрет), на чем основано это суждение?
VD>На разных факторах. Например, на твоих сообщениях...
Т.е. читая мои сообщения, ты во мне не увидел профессионала либо личность, либо и то и другое, я правильно понимаю?
VD>Ну, вот еще на основании того может ли человек себе такое позволить или нет.
Влад, если я тебя как-то задел этой шуткой — искренне и здесь же приношу свои извинения, т.к. это не было целью того сообщения. Это я себе тоже могу позволить
Я бы не сказал что все так однозначно. Если попытаться выразить коротко: можно не выбрасывать, но быть готовым переписать с нуля.
Когда имеет смысл выбрасывать: когда ясно что это не будет работать достаточно скоро, настолько скоро что лучше сразу сделать "по-нормальному". Если такого понимания нет, наверное лучше оставить.
Был один пример, когда сделали работающий прототип и пустили его в production. Спустя некоторое время говорили что да, сделано криво. Но с другой стороны: решение _работает_, и в тот момент когда его запускали в production не было понимания того что скоро это просто заткнется с точки зрения масштабируемости, производительности etc. Поэтому я бы не сказал что все так однозначно.
С другой стороны, в некотором классе продуктов (в нашей области такое часто бывает), разница между прототипом и финальным вариантом не проходит так четко как при прототипировании каких-то чисто технологических решений. Например, там где критерием "работоспособности" прототипа является не техническая характеристика типа сколько сообщений обрабатывается в секунду, а то насколько удобна и полезна какая-то высокоуровневая функциональность, влияющая при этом на пол-системы, то даже часть уже выпущенного продукта может так и оставаться "прототипом", потому что acceptance test для нее — реальное использование.
Но при всем при этом я бы сказал что часто трудозатраты на переписывание немного переоценивают: прототип создавать гораздо сложнее, потому что в процессе создания пробуются куча разных подходов, что-то отвергается etc. Если же переписать это целиком с нуля — это может быть в 5-10 раз меньше. Единственная опасность — когда прототип абсолютно нерабочий — на нем не отловлена еще куча проблем, которые существуют (видно что работает он так себе). В этом случае переписывание с доведением до ума может быть и дольше чем создание самого прототипа.
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано. RRM>- Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше. RRM>- Переиспользовать часть, часть сделать заново
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
Алан Купер советует выбрасывать прототип без сожаления.
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Как делалась Windows 95 и как делалась Windows NT? Что в итоге получилось всем ясно.
Здравствуйте, iZEN, Вы писали:
ZEN>Алан Купер советует выбрасывать прототип без сожаления.
Выбрасывать совсем? Или что-то можно взять? Отдельные классы например. Все переписывать — ну глупо как-то одно и тоже два раза писать, особенно есл одно и тоже получится (это я утрирую конечно).
Насколько целесообразно переиспользовать дизайн, иерархию классов например?
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, iZEN, Вы писали:
ZEN>>Алан Купер советует выбрасывать прототип без сожаления.
RRM>Выбрасывать совсем? Или что-то можно взять? Отдельные классы например. Все переписывать — ну глупо как-то одно и тоже два раза писать, особенно есл одно и тоже получится (это я утрирую конечно).
RRM>Насколько целесообразно переиспользовать дизайн, иерархию классов например?
Так вот во многом ради выяснения дизайна, архитектуры, и создаются прототипы. Главное, сам код не переносить.
Код в прототипах получается неряшливый, "временный".
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, AndrewVK, Вы писали:
RRM>>Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
AVK>А с чего ты решил, что есть универсальный образ действий?
Я не считаю, что есть универсальный путь, мне интересно у кого, что было. Как положительный опят так и отрицательный
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
Угу. Это и называется прототипирование. Но вы же не включаете Unit-тесты в конечный продукт? Или включаете?
MSS>Все остальное можно сразу начисто писать.
Писать можно, но такая фигня получается.
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом?
Выбрасывать. Или к делу подшивать.
MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
Не получится.
RRM>>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его.
Этакий интерактивный Unit-тест на людях.
MSS>И правильно начальство захочет.
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
MSS>Все остальное можно сразу начисто писать.
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом?
MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
RRM>>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его.
MSS>И правильно начальство захочет.
Ага, а еще такой момент. Прототипирование повторяет идею Test-Driven Development.
Т.е. выяснение, что и как делать, происходит не только (и не столько) на этапе предварительного проектирования, а прямо по ходу дела и по ходу возникновения проблем. Разумеется, когда очередное решение найдено и его архитектура выбрана и опробована "в бою", то это решение еще раз обдумывается, структурируется, соотносится с общей архитектурой системы и переносится в релиз. Заметьте, решение, а не код Код прототипа лучше распечатать и любоваться им издали — так не возникнет соблазна копипастнуть его
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, iZEN, Вы писали:
MSS>>Все остальное можно сразу начисто писать. ZEN>Писать можно, но такая фигня получается.
Что, никогда не бывало такого, что первый запуск после часов кодирования — и каким-то чудом все тесты проходят и все работает корректно?
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
Воспрос о случаях, когда обязательно. Или лучше когда имеет смысл.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
А если на маленьком юнит-тесте просто не получится попробовать решение. Т.е. нужно сделать достаточну большую систему и только потом станет ясно, что получилось. Кроме того маленький юнит-тест может быть вполне удачным, но не покажет проблем, ктр появятся в реальной большой системе
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом?
MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
Тогда это уже не прототип, а версия v0.1
Кроме того начисто писать прототип -> тратить гораздо больше времени -> результат от прототипа получен позже -> позже может выяснится, что использованный дизайн неудачен, а это вполне возможно, ради проверки прототип затевали
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом? MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
Арабская мудрость гласит: "Чтобы сделать что-то хорошо, нужно сделать это как минимум дважды". Так вот писАть "сразу и навсегда" это имхо из разряда "in the perferct world" — было бы замечательно, и менеджеры были бы довольны — сильно упростилось бы у них планирование проектов — но в большинстве случаев у реальных разработчиков не получается.
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано. RRM>- Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше. RRM>- Переиспользовать часть, часть сделать заново
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
теория говорит — реюзать полученые в ходе прототипирования знания, а не код. на практике практически всегда реюзал и код. и думаю это была ощибка, его стоило переписывать. "доделывать" прототип будет ошибкой.
R>Что, никогда не бывало такого, что первый запуск после часов кодирования — и каким-то чудом все тесты проходят и все работает корректно?
У меня это норма, и не после часов, а и иногда после дней. Иногда все 100% корректно, иногда вылавливается пара мелких багов, но в общем и целом bug rate практически не выше, как на уже релизнутом продукте — т.е. баги поступают, куда без них, но очень медленно и понемногу.
A>Ага, а еще такой момент. Прототипирование повторяет идею Test-Driven Development. A>Т.е. выяснение, что и как делать, происходит не только (и не столько) на этапе предварительного проектирования, а прямо по ходу дела и по ходу возникновения проблем.
"Главный способ найти грабли — это наступить на них!".
Вторая известная сентенция — "не хочешь работать головой, работай руками".
A>Разумеется, когда очередное решение найдено и его архитектура выбрана и опробована "в A>бою", то это решение еще раз обдумывается, структурируется, соотносится с общей A>архитектурой системы и переносится в релиз.
Вы сами-то понимаете, что вы тратите в 2-3 раза больше человеко-часов, чем можно?
A>Код прототипа лучше распечатать
Вообще не надо код печатать, это не худлит.
A>и любоваться им издали — так не возникнет соблазна копипастнуть его
А еще можно носить бронежилет на каждый день. Из тех же соображений — чтоб жизнь малиной не казалась.
Здравствуйте, Maxim S. Shatskih, Вы писали:
iZEN>>Писать можно, но такая фигня получается.
MSS>У меня все хорошо получается. Я бросил пользоваться черновиками (в т.ч. при написании сочинений, о котором тут говорили) еще в старших классах школы.
Я, кстати, тоже в старших классах школы перестал писать черновики. Но получалось слишком кратко, порой сумбурно, тема сочинений не была раскрыта доконца, чем очень премного огорчил учительницу русского языка и литературы. С пятёрок скатился на четвёрки. Стал писать реже — просто со временем надоело выдавать посредственный продукт, стыдно было.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>И исторически сначала сделали НТ, а уже потом — Win32 над старым VMM и 16битными GDI и USER, что и есть Win95. Т.е. поток идей шел из НТ в 95, а не наоборот.
Не соглашусь.
Я говорил о прикладном полигоне.
Интерфейс пользователя WinNT4 (win32.sys и comctl.dll) оттачивался на Win95 и только после этого в 1996 году была выпущена WinNT4 с интерфейсом "как у Win95".
OLE/OLE32 и ActiveX первоначально обкатывались в Win3x/Win95 и только потом переносились в NT-линейку.
Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
Здравствуйте, iZEN, Вы писали:
ZEN>Вообще-то, я о том, что Windows 95 унаследовала кучу 16-битного кода от своей предшественницы и плохо масштабировалась. Была ненадёжной.
ZEN>Windows NT писалась с нуля. Из "прототипа" Windows 95 брались лучшие, обкатанные идеи и переносились в Windows NT. Windows 95 продолжала оставаться прикладным (но не системным!) полигоном для NT-линейки вплоть до объявления о слиянии линеек в одну на основе ядра NT.
Вообще-то Windows 95 не только не была прототпом для Windows NT, но и не могла им быть хотя бы потому, что Windows NT вылла на несколько лет раньше.
Общее у Windows NT и Windows 95 только Win32 API.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ZEN>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
нет.
НТ4ую систему драйверов доработали, добавив PnP и power management, и перенесли за уши в Win98, сделав там враппер-эмулятор НТ ядра вокруг VMM под названием ntkern.
ZEN>Я, кстати, тоже в старших классах школы перестал писать черновики. Но получалось слишком кратко, порой сумбурно, тема сочинений не была раскрыта доконца
Ну так для этого есть наброски и планчики. Зачем _весь текст_ начерно писать?
L>Ну а лично я сталкивался. К примеру — есть достаточно большой проект, в котором будет использоваться технология SuperPuperMegaWidgets, незнакомая или слабо знакомая разработчикам (по разным причинам, к примеру — технология только что появилась, или сама по себе достаточно нишевая, или или...).
Вот эта ситуация как правило есть чья-то блажь кто-то начитался рекламок о технологии.
L>Так вот, ИМХО в таком случае написание прототипа с последующим выкидыванием бОльшей части его кода весьма даже оправдано. Т.е. за время написания прототипа разработчики ознакомятся с технологией, её достоинствами и граблями,
Опять изучаем грабли путем наступания на них?
Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).
Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.
L>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,
Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...
AP>По моему, в "Программисте-прагматике" для предотвращения подобной ситуации авторы советуют прототип писать не на вашем основном рабочем языке. Если пишете на C#, то сделайте прототип, для обкатки решения, на VB или Delphi.
Авторы жгут не по-детски. Иначе и не скажешь.
То есть — помимо "боевого" языка, всей командой выучить еще и "учебный"? а ведь любой язык, даже учебный — имеет свои заморочки и подводные камни.
Ну и нафига команде, которая делает продукт на Шарпе, ковыряться в нюансах Дельфей?
Здравствуйте, Maxim S. Shatskih, Вы писали:
A>>Ага, а еще такой момент. Прототипирование повторяет идею Test-Driven Development. A>>Т.е. выяснение, что и как делать, происходит не только (и не столько) на этапе предварительного проектирования, а прямо по ходу дела и по ходу возникновения проблем.
MSS>"Главный способ найти грабли — это наступить на них!".
MSS>Вторая известная сентенция — "не хочешь работать головой, работай руками".
A>>Разумеется, когда очередное решение найдено и его архитектура выбрана и опробована "в A>бою", то это решение еще раз обдумывается, структурируется, соотносится с общей A>архитектурой системы и переносится в релиз.
MSS>Вы сами-то понимаете, что вы тратите в 2-3 раза больше человеко-часов, чем можно?
A>>Код прототипа лучше распечатать
MSS>Вообще не надо код печатать, это не худлит.
A>>и любоваться им издали — так не возникнет соблазна копипастнуть его
MSS>А еще можно носить бронежилет на каждый день. Из тех же соображений — чтоб жизнь малиной не казалась.
Ирония неуместна
Времени на прототип и на релиз вместе тратится больше процентов на 20. Ведь это естественно — почти все время было потрачено на отладку прототипа, а релиз получается сам собой Зато потерянное время компенсируется качеством, что, согласитесь, важнее: из всех фаз жизненного цикла проекта дороже всего обходится сопровождение и исправление застарелых багов.
Зачем код печатать? Ну, просто психология с физиологией. С экрана читать труднее, а бумага "все стерпит" Такая же ситуация с электронными книгами — читать с экрана очень неудобно, глаза устают.
Потом, желание подстраховаться и сделать проект как можно более контролируемым — это ведь с опытом приходит. Ведь, когда над проектом работает хотя бы человек 5-6, он постепенно обрастает "макаронами" и излишней сложностью.
Так что не горячитесь С прототипами работать любят многие, и достоинств у них больше, чем недостатков.
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
A>Согласен. Аффтар, похоже, только со студенческой скамьи слез В бой рвется, шашкой махать
Кто-то грабли сразу видит и на автопилоте обходит, кто-то по ним ходит, и видит их только лобной костью.
Еще раз повторю: написание больших черновиков, чтобы поощущать технологию и посмотреть, что получится — сочли бы бредом все мои бывшие и нынешние работодатели.
L>Хм. Реклама рекламой, но работать с технологией рано или поздно надо начинать.
Зачем надо? кому надо? в чем смысл слова "надо"? с целями деятельности определиться надо.
MSS>>Опять изучаем грабли путем наступания на них? L>К сожалению, я не знаю другого эффективного пути обучения.
А я знаю. Книжки, документация, примерчики. Этих трех вещей хватает, чтобы просто сесть и пойти вперед в разработке. Без прототипов и черновиков.
L>Этого конечно никто не отменял. Но по-настоящему технологию узнаешь только потрогав её руками. Документация-примеры — это всегда только начало, процентов 30 пути.
90. Документация-примеры-общение на профильных форумах = 90%.
Остальные 10 доберешь в процессе реальной работы. Может и лид подсказать. Я без старших товарищей справлялся.
L>In the perferct world
В реальной практике всех моих 15 лет профессиональной деятельности. Никто — повторяю, никто — не писал черновики на выброс, чтобы освоиться с технологией.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Целью ее разработки было — получить полноценно многозадачную и почти полноценно 32битную ОС _с меньшими требованиями к памяти, чем НТ_.
+ требования почти полной совместимости с Win16 и DOS. NT этого там и не смогла обеспечить. Как раз 16-битный код в 95-ых для этого и использовался. По тем же причинам там были дыры в защите памяти.
MSS>Когда требования к памяти у НТ перестали быть напряжными — линейка Win9x стала умирать. WinMe был просто провальный продукт.
И когда потребность в 16-битных приложения стала отпадать (выпустили их 32-битные аналоги).
Вот сейчас скажем Вынь64 есть и отлично работает. На столах в большинстве своем 64-разрядные машины. Но большинство людей используют 32-битные ОС только в связи с тем, что основная масса софта 32-битная.
MSS>И исторически сначала сделали НТ, а уже потом — Win32 над старым VMM и 16битными GDI и USER, что и есть Win95. Т.е. поток идей шел из НТ в 95, а не наоборот.
На самом деле не совсем так. NT разрабатывалась (в самом начале) как замена OS/2 2.х и изначально ее API был развитем API Презентэшон менеджера из полуоси. Но в это время у МС выгорел проект с Windows 3.х. Она набрала нехилую популярность и было решено переоринтировать НТ на API Windows 3.х. Так как оно было 16-битным было решено создать 32-битное API максимально совместимое с 16-битным, для облегчения миграци программ написанных под Вынь 3.х.
Так был разработан Win32 API. Причем сразу этот API подразумевал разный уровень поддержки. Скачала свет увидел Win32S — это обертка для 16-битного API. Он ставился на Вынь 3.1 и позволял запускать 32-битные приложения из под нее. Но все вызовы в Вынь32Эс конвертировались в 16-битные, а многоие и вовсе не были реализованы (били только заглушки ничего не делающие). В НТ Win32 API был реализоан полноценно. В 95-ых он был реализован, но с некоторыми ограничениями и позже чем в НТ или Вынь32Эс.
Так что таки, да, Вынь 95 была после НТ, но таки, Win32 API был специально разработан как замена 16-битному и не только для НТ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
L>Э... Не все технологии одинаково хорошо документированны. Есть такие по которым и книжек днём с огнём не сыщешь, и примеры покрывают 10% юзкейсов, и документация оставляет желать лучшего. Предлагаешь отказаться от проекта пока технология не вызреет настолько что появятся все составляющие успеха? Предполагаю что иногда так и делают, но не все и не всегда.
Бывает. Согласен. Но как из этого следует написание _черновика_ на весь проект? ну, написали исследовательский код. Ну, он заработал. И что — теперь его в помойку, и заново переписывать?
Надо сразу чисто писать, даже исследовательский код, если есть шансы, что он заработает.
Предложение писать прототип UI на Пауэрбилдере — это достаточное ИМХО основание не покупать книгу.
Видите ли, у ПауэрБилдера (оставим в покое вопрос качества этого тула) свой достаточно развитый набор готовых UI элементов, в этом вопросе он примерно соответствует Access. И желаю счастья потом отписывать на Си++ точно такие же.
MSS>Бывает. Согласен. Но как из этого следует написание _черновика_ на весь проект? ну, написали исследовательский код. Ну, он заработал. И что — теперь его в помойку, и заново переписывать?
Как правило — да, лучше в помойку. Прототип же не обязательно по размеру кода сопоставим с оригиналом Это ж только концепция, функционала в нём — дай Бог если 25% от всего проекта, о производительности и масштабируемости вообще обычно не думают, так что кода там процентов 10% от основного проекта.
Кстати, как пример — я бы привёл примеры кода из MSDN (не все, но подавляющее большинство). Как правило, они кусками копипейстятся в прототип, но из продакшн кода я их стараюсь всеми силами выковыривать, оставляя ту же логику работы но переписывая всё втрое короче и понятнее.
MSS>Надо сразу чисто писать, даже исследовательский код, если есть шансы, что он заработает.
Э... Опять же — я согласен что НЕПЛОХО БЫ было уметь так писать. Но зачастую, не обладая чётким пониманием технологии написать сразу чисто просто не под силу даже очень опытному разработчику.
Давайте я лучше приведу конкретный пример: был проект, нужно было захватывать видео со встроенной камеры в мобильном девайсе на базе WinMobile. С мобильными девайсами был небольшой опыт работы, с DirectShow (а он там как и всё остальное на Win Mobile — слегка специфичный) — не было вообще. В результате — написали прототип (с жутким качеством кода, поскольку код на 75% состоял из кусков накопипейстеных из китайских форумов и прочих весьма сомнительных мест). А потом, когда примерно поняли что и как нужно делать — переписали всё заново. Зато прототип смогли быстро показать заказчику, который увидел какого качества видео можно ожидать .
MSS>Видите ли, у ПауэрБилдера (оставим в покое вопрос качества этого тула) свой достаточно развитый набор готовых UI элементов, в этом вопросе он примерно соответствует Access. И желаю счастья потом отписывать на Си++ точно такие же.
А не обязательно точно так же. Нужно просто похоже. Никто не требует от прототипа 100% соответствия релизной версии.
Хотя честно говоря сама идея писАть прототип на другом языке мне не кажется слишком удачной. Overkill, IMHO.
L>Давайте я лучше приведу конкретный пример: был проект, нужно было захватывать видео со встроенной камеры в мобильном девайсе на базе WinMobile. С мобильными девайсами был небольшой опыт работы, с DirectShow (а он там как и всё остальное на Win Mobile — слегка специфичный) — не было вообще. В результате — написали прототип (с жутким качеством кода, поскольку код на 75% состоял из кусков накопипейстеных из китайских форумов и прочих весьма сомнительных мест).
Вам повезло, что это вообще заработало даже как демка. Не повезло бы, возникли бы какие баги неприятные — все равно пришлось бы для их исправления изучать DirectShow, в т.ч. специфичный для CE.
ZEN>Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
Не заменила, а расширила. WDM — это НТ4 модель драйверов с добавленными PnP & Power.
Здравствуйте, Sinclair, Вы писали:
S>Много лет назад была у меня задача: разработать свой Mail-клиент. Под винду. Я, будучи наслышан о MAPI, почитал поподробнее документацию, убедился что таки да — всё ровно для меня, все тонкости взаимодействия с POP3/SMTP уже реализованы, осталось только UI написать. Оценил задачу, начал колбасить. S>И только тогда, когда приложение было на 90% готово, оказалось, что в очередной версии микрософт молча убрала программную отправку почты. Т.е. метод есть, возвращает S_OK, но ничего не происходит. Пришлось за выходные полностью переписать всё что касалось отправки и получения почты. Только запуск интерактивного аутлука выполняет собственно отправку. S>Вот тебе и 10%.
POP3/SMTP, вообще-то, примитивные и простые протоколы обмена информацией, основанные служебных "командах" в формате ASCII.
Здравствуйте, iZEN, Вы писали:
ZEN>POP3/SMTP, вообще-то, примитивные и простые протоколы обмена информацией, основанные служебных "командах" в формате ASCII.
И какое отношение это имеет к теме разговора?
А насчет POP3/SMTP я в курсе. Так, в качестве упражнения на дом: сколько RFC необходимо изучить, чтобы принять (или отправить) русскоязычное письмо с аттачментом?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
MSS>Вам повезло, что это вообще заработало даже как демка. Не повезло бы, возникли бы какие баги неприятные — все равно пришлось бы для их исправления изучать DirectShow, в т.ч. специфичный для CE.
Дело в том что "изучать DirectShow специфичный для CE" возможности нет. Нет документации. Вся что есть от МС — по PC-шному DirectShow. Понять что работает а что не работает (и главное — как сделать чтобы работало) в CE-шном можно только методом "втыка и вытыка".
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Еще раз повторю: написание больших черновиков, чтобы поощущать технологию и посмотреть, что получится — сочли бы бредом все мои бывшие и нынешние работодатели.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>P.S. Я занимался программированием в нескольких командах, каждая из которых сделала по достаточно сложному продукту. Так вот, Я НИ РАЗУ не видел, чтобы при написании кода хотя бы в одной из этих команд — а они сильно разные — использовался бы подход с "черновиком". Это для меня вообще новое слово в программировании
Feasibility study — стандартная вещь. Выбрать одну из нескольких подходящих технологий, проверить практическое быстродействие, оценить поддержку со стороны IDE и т.д. Другое дело, что масштаб умеренный, без дублирования.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, iZEN, Вы писали:
iZEN>>OLE, оно же OLE16, оно же VB OCX. Модули для программирования приложений в VisualBasic, писались на MS VisualC++ начиная с Windows3.1.
iZEN>>OLE2, оно же OLE32, позднее переименовано в ActiveX и COM (Component Object Model). Под эту модель затачивался реестр 32-битных версий Windows.
VD>OLE 2 было в двух версиях 16 и 32 бита. OLE 1 вообще в природе не существовало. Было просто OLE. VBX никакого отношения к OLE не имел.
OLE == OLE 1. (К примеру, Java 1 тоже в природе не существовало, была просто Java и Java2. Здесь также.)
VD>Тот факт, что VBX был заменен на OLE Controls после выхода OLE 2 и COM ничего ровным счетом не говорит.
Почему? Наоборот! Технология OLE ознаменовала новую модульность, не привязанную к конкретному языку программирования (в данном случае к VB). OLE стала унифицированной моделью для программирования бинарно-переносимых Win32-приложений и протоколов обмена данными в межпроцессном взаимодействии (с объявлением ActiveX и COM).
VD>Короче, очердной раз говоришь о том, что сам плохо знаешь. Зайди на http://en.wikipedia.org/wiki/ и подставь по очереди все перечисленные тобой базворды. Потом открой http://en.wikipedia.org/wiki/Object_Linking_and_Embedding и почитай реальную историю.
Чё такое "базворды"?
Кстати, я уже использовал Wiki для сопоставления дат выхода операционных систем. Этого оказалось достаточно, чтобы утверждать, что Windows 9x была прототипом для Windows NT.
iZEN>>Windows 95 вышла в августе 1995 года. iZEN>> Windows NT4 вышла в июле 1996 года. Прототипирование и обкатка технологий прослеживается как нигде, особенно в прикладных вещах.
VD>Ну, и что? А 3.51 вышла приблизительно с 95-ыми и для нее был доступен десктоп аля 95-ые. Я себе скачивал и ставил.
Для NT4 тоже был доступен десктоп IE4. Я себе ставил, но это работало так криво, что пришлось переустанавливать WinNT. Потом появилась Win2000 с уже интегрированным десктопом IE4 (как в Windows 98/ME), который не глючил.
VD>О чем вообще по-твоему говорит тот факт, что в 95-ых прикрутили какой-то там новый ГУЙ?
Обо всём. В Windows NT 3.51 бы GUI от Windows 3.1x, что совсем не мешало ей быть настоящей 32-битной системой, в отличие от Win3x.
В то же время, Win3.1x начала перенимать некоторые 32-битные черты с выходом набора библиотек Win32S, правда, не становясь от этого многозадачной.
Ещё, Windows NT 3.51 не поддерживала длинных имён файлов! Она их резала до 8 символов. Поддержка длинных имён файлов появилась сначала в Windows 95, а потом перешла в Windows NT4.
Windows 95 имела в реестре дополнительную ветвь AppPath для приложений, инсталляторы которых писали туда строку, содержащую пути к библиотекам DLL и модулям OCX, которые были нужны этим приложениям (строка добавлялась в переменную окружения %PATH% приложения). Эта опция появилась спустя год в реестре Windows NT4.
iZEN>>>>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.
VD>>>Каких еще драйверов? Причем тут драйверы?
iZEN>>Windows Driver Model — *.WDM iZEN>>Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
Но простые пользователи с этим столкнулись ранее — ещё в Windows 98. Может WDM пришли из Cairo (Windows NT5), мы-то видим обратное: WDM испытывалась на пользователях раньше выхода Windows 2000.
VD>Ага. Тебе тут уже ответили рядом. Если не веришь сходи опять же в Вики http://en.wikipedia.org/wiki/Windows_Driver_Model и почитай, про то откуда взялся WDM.
Прочитал:
The Microsoft Windows Driver Model defined a unified driver model for the Windows 98 and Windows 2000 lines by standardizing requirements and reducing the amount of code that needed to be written.
По-моему, исчерпывающая информация.
iZEN>>(Ты ж вроде на Windows и должен помнить историю. )
VD>Ага. В отличии от тебя.
Да, я тут с FreeBSD балуюсь, у которой Microsoft позаимствовала стэк TCP/IP...
MSS>>OLE 2.0 и COM появились в 16 битах как охапка redistributable DLLs (COMPOBJ и прочие) в 1993 году.
MSS>>Офис того года выпуска, как и CorelDraw, пользовался этой технологией.
VD>Ну, и чем это противоречит моим словам? Он с тем же успехом появился и для NT который появился в том же 1993-ем.
Ничем. Я увеличиваю степень знания картины, а не с тобой воюю
ZEN>Ещё, Windows NT 3.51 не поддерживала длинных имён файлов! Она их резала до 8 символов. Поддержка длинных имён файлов появилась сначала в Windows 95, а потом перешла в Windows NT4.
Просто чушь.
На NTFS такие имена файлов поддерживались с самого начала, с NT 3.1
На FAT они стали поддерживаться в NT 3.5 в 94 году, так называемый "чикагский FAT", он появился и использовался еще до Win95 именно в NT 3.5.
ZEN>Windows 95 имела в реестре дополнительную ветвь AppPath для приложений, инсталляторы которых писали туда строку, содержащую пути к библиотекам DLL и модулям OCX, которые были нужны этим приложениям (строка добавлялась в переменную окружения %PATH% приложения). Эта опция появилась спустя год в реестре Windows NT4.
OCXы, как и все COM объекты, грузятся по абсолютным путям, указанным в InprocServer32, и потому им плевать на %PATH%.
iZEN>>>Впервые появилась в Windows 98 (июнь, 1998), прошла в Windows ME (сентябрь, 2000), заменила систему управления драйверами в NT-линейке с выходом Windows 2000 (февраль, 2000).
Угу, и разработана на основе НТ4ой driver model, куда добавили PnP & Power.
ZEN>Но простые пользователи с этим столкнулись ранее — ещё в Windows 98. Может WDM пришли из Cairo (Windows NT5), мы-то видим обратное: WDM испытывалась на пользователях раньше выхода Windows 2000.
Угу, но сделана она именно на основе НТшного стиля, а не VMMного. Ее испытывали на _враппере_ ntkern.vxd, который эмулил часть НТшного ядра над VMM.
Некоторые подсистемы в ядре — например, почти вся поддержка USB — существовали только в WDMной версии, причем USB стек из w2k без сервис-паков совпадает с Win98 SE. Я пробовал просто бинари из w2k ставить в Win98 и оно работало. Именно для этого WDM и делали.
Win98 вышла раньше, чем w2k, потому пробовали на ней. Раньше даже не из-за WDM, а из-за активной директории и прочих w2kшных прелестей.
ZEN>Да, я тут с FreeBSD балуюсь, у которой Microsoft позаимствовала стэк TCP/IP...
Это просто ложь ненавистников Микрософта, причем всем известная.
VD>А как можно объяснить тот факт, что у МС стэк TCP/IP был реализован еще для Windows for Workgroups 3.11 появившеся в 1993-ем, в то время как в 1993-ем Фришку только начали разрабатывать? Да и вообще, интересно, как же в МС умудрились повзавимствовать 16-битный код из 32-битной ОС?
Код там 32битный, как и весь VMM, но заимствования действительно не было, этот код зародился в MS LAN Manager for OS/2 1.x
MSS>>Еще раз повторю: написание больших черновиков, чтобы поощущать технологию и посмотреть, что получится — сочли бы бредом все мои бывшие и нынешние работодатели.
ANS>А что они оценили бы?
Написание сразу начисто. Чтобы, если заработает — сразу делать продукт минимальными усилиями.
S>А насчет POP3/SMTP я в курсе. Так, в качестве упражнения на дом: сколько RFC необходимо изучить, чтобы принять (или отправить) русскоязычное письмо с аттачментом?
Я за пару месяцев сделал в 99ом году систему вебовской почты, с русскими аттачами, c MIME и с uuencode.
Для базы данных был MSSQLServer или Jet или Oracle, веб-интерфейс был функциональный, но без наворочанного "дизайна".
POP3 и SMTP — это как раз были пустяки, не пустяки был MIME.
Здравствуйте, Maxim S. Shatskih, Вы писали:
S>>А насчет POP3/SMTP я в курсе. Так, в качестве упражнения на дом: сколько RFC необходимо изучить, чтобы принять (или отправить) русскоязычное письмо с аттачментом?
MSS>Я за пару месяцев сделал в 99ом году систему вебовской почты, с русскими аттачами, c MIME и с uuencode.
Ну, поддержку аттачей, в том числе и русских, и uuencode, и base64, и корректную работу с временными зонами, мне удалось сделать примерно за пару недель. Ну, точнее, основа была сделана за трое суток, остальное время чинил баги. MSS>Для базы данных был MSSQLServer или Jet или Oracle, веб-интерфейс был функциональный, но без наворочанного "дизайна". MSS>POP3 и SMTP — это как раз были пустяки, не пустяки был MIME.
Это да. Полноценная поддержка всего — это не пустяк. К тому же веб-почта вообще в разработке значительно сложнее, чем десктопный клиент, которого писал я.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Сергей, Вы писали:
С>>P.S. С>>Конечно, не из FreeBSD, скорее из какой-то более ранней BSD.
AVK>Ты не путай TCP/IP стек и API к нему — winsock, которое было придумано в Berkley.
o_O
вы точно уверены, что "winsock придуман в Berkley"?
ZEN>>>Да, я тут с FreeBSD балуюсь, у которой Microsoft позаимствовала стэк TCP/IP...
MSS>>Это просто ложь ненавистников Микрософта, причем всем известная.
С>А вот это тогда как понимать:
Socket API взят BSDшный — точнее, уже на тот момент общеUNIXный.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Друзья, без обид... Но после прочтения вашего короткого но бурного диалога, возникло ощущение, что один из вас является прототипом другого...
VD>Какой ты мне друг?
Действительно никакой, подтверждаю. И даже не коллега. Это вообще-то довольно распространенное обращение, к реальной дружбе отношения не имеющее. Оно служит для добавления в текст некоторого оттенка доброжелательности по отношению к собеседникам.
VD>Но обижаться действительно просто не на кого.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>У меня это норма, и не после часов, а и иногда после дней. Иногда все 100% корректно, иногда вылавливается пара мелких багов, но в общем и целом bug rate практически не выше, как на уже релизнутом продукте — т.е. баги поступают, куда без них, но очень медленно и понемногу.
Долго думал, но не верится что-то...
Какое количество багов у вас приходится на 100 строк кода и сколько строк за день вы пишете (на каком языке и насколько формализовано задание)?
FDS>Какое количество багов у вас приходится на 100 строк кода и сколько строк за день вы пишете (на каком языке и насколько формализовано задание)?
Максимально, в режиме "написать с нуля крупную компоненту с полностью понятными мне требованиями", в великолепном настроении итд — бывали случаи и по 2000 строк в день (включая комментарии, коих у меня немало), но вот это уже потолок, за которым часто следует день полной неработы башки.
Язык как правило Си. В коде, которым я занимаюсь последние 3 года, всего 2 файлика на Си++, где надо звать сложную COMовскую подсистему от MS. Ах, еще дебаг аллокатор есть на Си++ для юнит-тестов, зовется из Си
Задание никогда не формализовано, мне это не нужно. Но мне всегда понятны все требования к вновь разрабатываемой компоненте.
Обычно на 1500-2000 строк потом 2-3 бага находятся при первоначальном тестировании мною же, потом 2-3 бага при "плотном".
После написания с нуля крупного куска кода обязательно делаю передышку и потом код вычитываю. После небольших патчей обязательно вычитываю в режиме сравнения на source control.
Все остальное, что нужно сделать с этой компонентой — это полу-баги типа "не обрабатывает вот такой вот corner case", или "мы хотим более детальный вывод в лог", или "локализуйте нам лог на японский" (код написан за 2 дня и отлажен на примере русского , после чего переводчик перевел пару сотен английских сообщений на японский и прислал мне обратно файл со stringtable resource).
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Максимально, в режиме "написать с нуля крупную компоненту с полностью понятными мне требованиями", в великолепном настроении итд — бывали случаи и по 2000 строк в день (включая комментарии, коих у меня немало), но вот это уже потолок, за которым часто следует день полной неработы башки.
Меня интересует средняя производительность
MSS>Обычно на 1500-2000 строк потом 2-3 бага находятся при первоначальном тестировании мною же, потом 2-3 бага при "плотном".
Т.е. вы утверждаете, что не используя никакой формальной методики вы получаете за несколько дней работы (включая отдых, анализ кода, но не включая написание тестов), например, 1000 строк кода примерно с 6 дефектами? При этом нет какого-либо заранее согласованного алгоритма работы программы и во время кодирования эти алгоритмы и разрабатываются...
При этом я считаю дефектом, в частности, некорректную обработку исключений и неправильного ввода данных (по крайней мере, должна быть какая-то проверка, что ввод правилен) и вообще любой недостаток программы, выявленный после её компиляции, в том числе на тестах. Естественно, нереализованная функциональность, которая и не планировалась к реализации, не в счёт — это не дефект, это Change Requirements
Какой критерий покрытия вы используете для тестирования?
Вообще говоря, при хорошей скорости программирования (если не выше), получается слишком мало багов (у меня 2,3 — 8 дефектов на 100 (сто) строк кода в зависимости от языка и способа программирования). Если речь не идёт о простейших компонентах, то совершенно непонятно, как такое достигается. Было бы интересно подробнее понять как вы пишете код или взглянуть на него самого, если есть такая возможность.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>О какой грязи речь? Если по существу вопроса — то прав ты, а не iZEN. Если по тому, как ты свою правоту ему доказывал — это было резко, с пренебрежением и переходом на личности. Также как и с его стороны, в общем-то. И шутя насчет прототипов, я подразумевал именно манеру общения, а не познания в истории разработки windows либо что-то еще.
Может ты что-то и подразумевал, но это осталось у тебя в мозгах. А на поверку получилось, то что получилось. Надеюсь я понятно выражаюсь?
Что касается резкости, то согласен. В конце я был резок. Но ёрш тваю меть (с) я перед этим несколько сообщений кидал ссылки (долго роясь в гугле чтобы их найти) и объяснял вполне доходчивым и мягким языком. Но упертость оказалась потрясающая. Даже, казалось бы, прозрачное описание подвергалось реинтерпретации в совершенно причудливой форме.
KV>Т.е. читая мои сообщения, ты во мне не увидел профессионала либо личность, либо и то и другое, я правильно понимаю?
Я не увидел сообщений по делу (форумы то для программистов). Ну, может я не все видел. Юмор оценил.
KV>Влад, если я тебя как-то задел этой шуткой — искренне и здесь же приношу свои извинения, т.к. это не было целью того сообщения. Это я себе тоже могу позволить
Я воспринял эти слова как оценку моих слов в техническом плане. Я конечно могу что-то забыть, но все же с виндой я с тех пор когда она еще была 3.0 и всю историю НТ и 9х я прошел на собственной шкуре. И когда мне намекают, что я несу точно такую же чушь как мой оппонент, то я действительно обижаюсь (уж извиняюсь за очередную грубость).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Хм это конечно интересное историческое дерево, но его как-то не видно на форумах (я не заметил), да и история ОС не офтопом будет разве что в философии или вообще о жизни. Ладно, проехали. Я действительно был несколько обижен, и сотоветственно груб. Приношу свои извенения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>О какой грязи речь? Если по существу вопроса — то прав ты, а не iZEN. Если по тому, как ты свою правоту ему доказывал — это было резко, с пренебрежением и переходом на личности. Также как и с его стороны, в общем-то. И шутя насчет прототипов, я подразумевал именно манеру общения, а не познания в истории разработки windows либо что-то еще.
VD>Может ты что-то и подразумевал, но это осталось у тебя в мозгах. А на поверку получилось, то что получилось. Надеюсь я понятно выражаюсь?
VD>Что касается резкости, то согласен. В конце я был резок. Но ёрш тваю меть (с) я перед этим несколько сообщений кидал ссылки (долго роясь в гугле чтобы их найти) и объяснял вполне доходчивым и мягким языком. Но упертость оказалась потрясающая. Даже, казалось бы, прозрачное описание подвергалось реинтерпретации в совершенно причудливой форме.
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно RRM>Собственно вопрос — что дальше? что делать с этим прототипом?
Надо смотреть индивидуально. Но вообще по моему лучше писать заново, и в случае целесообразности портировать некоторые куски кода в рабочую версию. Обычно после написания прототипа возникает куча новых идей, взгляд на ряд вещей существенно меняется и желание дорабатывать прототип пропадает само собой. Обычно портируется только самый тупой код, который скрывается за каким-нибудь фасадом с пометкой "переписать когда нибудь" .
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Это уже отдельный вопрос. Самое ужасное, если вы перестарались и прототип работает . Тогда начальство может встать в позу "типа рабочая система, нафига переписывать". Причём даже после согласия на переписывание может переодически тыкать на каждый баг/недоработку, что мол вот была рабочая система, вы зачем то настояли на переделки и теперь у вас куча ошибок.
C>теория говорит — реюзать полученые в ходе прототипирования знания, а не код. на практике практически всегда реюзал и код. и думаю это была ощибка, его стоило переписывать. "доделывать" прототип будет ошибкой.
Это старая теория. Потом придумали рефакторинг и эволюционное прототипирование. Всё течёт, всё изменяется.
Но бывают случаи, когда прототип настолько абстрактен или нетехнологичен, что его проще выбросить.
Иногда прототипируют на бумаге. Такой прототип сложно использовать в продукте
AP>Основной аргумент против доделок — прототип делается, чтобы быстро дойти до работоспособного варианта, а не до рабочего. Объем доработок и/или исправлений может быть сравним или превысить объем работы необходимый для полного переписывания прототипа.
Это тоже устарело. Не пишите на таком языке, на котором страшно делать прототип. Ибо мазохизм.
Здравствуйте, VGn, Вы писали:
C>>теория говорит — реюзать полученые в ходе прототипирования знания, а не код. на практике практически всегда реюзал и код. и думаю это была ощибка, его стоило переписывать. "доделывать" прототип будет ошибкой.
VGn>Это старая теория. Потом придумали рефакторинг и эволюционное прототипирование. Всё течёт, всё изменяется.
Нет ничего лучше хорошей выдержаной теории
Так что ничуть ни устарело.
Прототип лучше писать на легком гибком языке (например python, schema или haskell) и нисколько ни думая о реюзе. Рефакторинг кстати придумали не для этого.
VGn>Но бывают случаи, когда прототип настолько абстрактен или нетехнологичен, что его проще выбросить. VGn>Иногда прототипируют на бумаге. Такой прототип сложно использовать в продукте
Здравствуйте, iZEN, Вы писали:
ZEN>Тем не менее, я настаиваю на своей точке зрения.
Успеха тебе в этом нелёгком деле.
Каждый имеет право на заблуждение
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Рассмешил.
