R>Что, никогда не бывало такого, что первый запуск после часов кодирования — и каким-то чудом все тесты проходят и все работает корректно?

У меня это норма, и не после часов, а и иногда после дней. Иногда все 100% корректно, иногда вылавливается пара мелких багов, но в общем и целом bug rate практически не выше, как на уже релизнутом продукте — т.е. баги поступают, куда без них, но очень медленно и понемногу.

A>Ага, а еще такой момент. Прототипирование повторяет идею Test-Driven Development.
A>Т.е. выяснение, что и как делать, происходит не только (и не столько) на этапе предварительного проектирования, а прямо по ходу дела и по ходу возникновения проблем.

"Главный способ найти грабли — это наступить на них!".

Вторая известная сентенция — "не хочешь работать головой, работай руками".

A>Разумеется, когда очередное решение найдено и его архитектура выбрана и опробована "в A>бою", то это решение еще раз обдумывается, структурируется, соотносится с общей A>архитектурой системы и переносится в релиз.

Вы сами-то понимаете, что вы тратите в 2-3 раза больше человеко-часов, чем можно?

A>Код прототипа лучше распечатать

Вообще не надо код печатать, это не худлит.

A>и любоваться им издали — так не возникнет соблазна копипастнуть его

А еще можно носить бронежилет на каждый день. Из тех же соображений — чтоб жизнь малиной не казалась.

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, незнакомая или слабо знакомая разработчикам (по разным причинам, к примеру — технология только что появилась, или сама по себе достаточно нишевая, или или...). Так вот, ИМХО в таком случае написание прототипа с последующим выкидыванием бОльшей части его кода весьма даже оправдано. Т.е. за время написания прототипа разработчики ознакомятся с технологией, её достоинствами и граблями, архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией, заказчик посмотрит на прототип и сможет определиться то ли это вообще что ему нужно... Естественно, что такой подход с написанием прототипа имеет свою нишу и не подходит, к примеру, для проектов небольшого размера, или слабо оправдан если у разработчиков за плечами куча опыта по разработке подобных систем. Но тем не менее я считаю что своя ниша у него есть.

Здравствуйте, 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.

Здравствуйте, RailRoadMan, Вы писали:

RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?

По моему, в "Программисте-прагматике" для предотвращения подобной ситуации авторы советуют прототип писать не на вашем основном рабочем языке. Если пишете на C#, то сделайте прототип, для обкатки решения, на VB или Delphi.

Основной аргумент против доделок — прототип делается, чтобы быстро дойти до работоспособного варианта, а не до рабочего. Объем доработок и/или исправлений может быть сравним или превысить объем работы необходимый для полного переписывания прототипа.

Хотя, как правило, некоторые части прототипа в финальном решении используются.

ZEN>Впоследствии даже система драйверов перекочевала из Win98 в Win2000.

нет.

НТ4ую систему драйверов доработали, добавив PnP и power management, и перенесли за уши в Win98, сделав там враппер-эмулятор НТ ядра вокруг VMM под названием ntkern.

ZEN>Я, кстати, тоже в старших классах школы перестал писать черновики. Но получалось слишком кратко, порой сумбурно, тема сочинений не была раскрыта доконца

Ну так для этого есть наброски и планчики. Зачем _весь текст_ начерно писать?

L>Ну а лично я сталкивался. К примеру — есть достаточно большой проект, в котором будет использоваться технология SuperPuperMegaWidgets, незнакомая или слабо знакомая разработчикам (по разным причинам, к примеру — технология только что появилась, или сама по себе достаточно нишевая, или или...).

Вот эта ситуация как правило есть чья-то блажь кто-то начитался рекламок о технологии.

L>Так вот, ИМХО в таком случае написание прототипа с последующим выкидыванием бОльшей части его кода весьма даже оправдано. Т.е. за время написания прототипа разработчики ознакомятся с технологией, её достоинствами и граблями,

Опять изучаем грабли путем наступания на них?

Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).

Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.

L>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,

Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...

AP>По моему, в "Программисте-прагматике" для предотвращения подобной ситуации авторы советуют прототип писать не на вашем основном рабочем языке. Если пишете на C#, то сделайте прототип, для обкатки решения, на VB или Delphi.

Авторы жгут не по-детски. Иначе и не скажешь.

То есть — помимо "боевого" языка, всей командой выучить еще и "учебный"? а ведь любой язык, даже учебный — имеет свои заморочки и подводные камни.

Ну и нафига команде, которая делает продукт на Шарпе, ковыряться в нюансах Дельфей?

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).

Бу-га-га.

MSS>Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.

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

L>>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,

MSS>Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...

Это так тяжело потратить всего лиш человеко-месяц на investigation? Тяжело вам там.

ЗЫ. Такое впечатление, что ты под "написать прототит" понимаеш "написать прогу со всем функционалом десятью разными способами", а не "потратить одну сотую от общего времени разработки на исследование".

L>>Ну а лично я сталкивался. К примеру — есть достаточно большой проект, в котором будет использоваться технология SuperPuperMegaWidgets, незнакомая или слабо знакомая разработчикам (по разным причинам, к примеру — технология только что появилась, или сама по себе достаточно нишевая, или или...).
MSS>Вот эта ситуация как правило есть чья-то блажь кто-то начитался рекламок о технологии.
Хм. Реклама рекламой, но работать с технологией рано или поздно надо начинать.

L>>Так вот, ИМХО в таком случае написание прототипа с последующим выкидыванием бОльшей части его кода весьма даже оправдано. Т.е. за время написания прототипа разработчики ознакомятся с технологией, её достоинствами и граблями,
MSS>Опять изучаем грабли путем наступания на них?
К сожалению, я не знаю другого эффективного пути обучения.

MSS>Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).
Этого конечно никто не отменял. Но по-настоящему технологию узнаешь только потрогав её руками. Документация-примеры — это всегда только начало, процентов 30 пути.

MSS>Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.
In the perferct world

L>>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,
MSS>Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...
Во-1 — я назвал несколько причин, а не только для того чтобы менеджер что-то понял. А во-2 — если на кону стоят человеко-годы, то можно рискнуть человеко-месяцем (в крайнем случае прототип отправляется в топку вместе с технологией).

Здравствуйте, Maxim S. Shatskih, Вы писали:

A>>Ага, а еще такой момент. Прототипирование повторяет идею Test-Driven Development.
A>>Т.е. выяснение, что и как делать, происходит не только (и не столько) на этапе предварительного проектирования, а прямо по ходу дела и по ходу возникновения проблем.

MSS>"Главный способ найти грабли — это наступить на них!".

MSS>Вторая известная сентенция — "не хочешь работать головой, работай руками".

A>>Разумеется, когда очередное решение найдено и его архитектура выбрана и опробована "в A>бою", то это решение еще раз обдумывается, структурируется, соотносится с общей A>архитектурой системы и переносится в релиз.

MSS>Вы сами-то понимаете, что вы тратите в 2-3 раза больше человеко-часов, чем можно?

A>>Код прототипа лучше распечатать

MSS>Вообще не надо код печатать, это не худлит.

A>>и любоваться им издали — так не возникнет соблазна копипастнуть его

MSS>А еще можно носить бронежилет на каждый день. Из тех же соображений — чтоб жизнь малиной не казалась.

Ирония неуместна
Времени на прототип и на релиз вместе тратится больше процентов на 20. Ведь это естественно — почти все время было потрачено на отладку прототипа, а релиз получается сам собой Зато потерянное время компенсируется качеством, что, согласитесь, важнее: из всех фаз жизненного цикла проекта дороже всего обходится сопровождение и исправление застарелых багов.

Зачем код печатать? Ну, просто психология с физиологией. С экрана читать труднее, а бумага "все стерпит" Такая же ситуация с электронными книгами — читать с экрана очень неудобно, глаза устают.

Потом, желание подстраховаться и сделать проект как можно более контролируемым — это ведь с опытом приходит. Ведь, когда над проектом работает хотя бы человек 5-6, он постепенно обрастает "макаронами" и излишней сложностью.
Так что не горячитесь С прототипами работать любят многие, и достоинств у них больше, чем недостатков.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>Нужно почитать тексты о технологии. Документацию на нее. Примерчики (упаси господь из них копи-пейстить, но почитать надо).

ANS>Бу-га-га.

MSS>>Грабли обнаруживаются осмотром местности, глазами, а не болевой чувствительностью лба.

ANS>Я таких граблей, на которые натыкался, но которые можно было бы обнаружить "глазами" не припомню вообще.

L>>>архитектор скорректирует архитектуру с учётом этих граблей, менеджер увидит насколько вообще оправдано связываться с этой технологией,

MSS>>Афигеть! потратили эдак человеко-месяц, чтобы менеджер что-то понял. Кудряво живете. Такой распыл человекоресурса...

ANS>Это так тяжело потратить всего лиш человеко-месяц на investigation? Тяжело вам там.

ANS>ЗЫ. Такое впечатление, что ты под "написать прототит" понимаеш "написать прогу со всем функционалом десятью разными способами", а не "потратить одну сотую от общего времени разработки на исследование".


Согласен. Аффтар, похоже, только со студенческой скамьи слез В бой рвется, шашкой махать

Здравствуйте, akarinsky, Вы писали:

A>Согласен. Аффтар, похоже, только со студенческой скамьи слез В бой рвется, шашкой махать

A>Согласен. Аффтар, похоже, только со студенческой скамьи слез В бой рвется, шашкой махать

Кто-то грабли сразу видит и на автопилоте обходит, кто-то по ним ходит, и видит их только лобной костью.

Еще раз повторю: написание больших черновиков, чтобы поощущать технологию и посмотреть, что получится — сочли бы бредом все мои бывшие и нынешние работодатели.