Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Интересно, что вы спорите с совершенно другой позицией, чем озвучиваемая вашим оппонентом... Т.е. при критике его позиции у вас идет речь о полном vs. итерационное проектирование/разработка, в то время, как ИТ и Влад озвучивали позицию отсутствия выделенного этапа проектирования до кодирования, а eao197 настаивал на его полезности (по крайней мере, для себя). Наличие выделенного этапа проектирования вполне возможно на каждой итерации. Более того, это вполне согласуется с рекомендациями всевозможных RUP, XP etc.
Тут проблема в том что мы используем разные средства разработки. Вы с Евгением пишете на С++, а я, ИТ, Влад, Синклер пишем на C# с ReSharper'ом. Так вот когда пишешь на С++ то писать и изменять когд намного сложнее чем делать тоже самое на C# с ReSharper'ом. Вот по этому вам нужна выделеная стадия проектирования, а нам нет. Мы можем проектировать прямо в коде ибо можем очень легко изменять этот код.

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

S>А что ты начинаешь делать при проектировании? пишешь текст? Ну так я просто набиваю // и тайпаю. Возникла какая-то сущность типа LogRecord? Ок, пишем:
S>

S>internal struct LogRecord
S>{
S>  Guid Id;
S>    DateTime TimeStamp;
S>    |
S>}
S>

Ты ведь своей ООСУБД хотел занятся? Вот как раз попробуй подобным образом write-ahead log сделать.
У себя я начал писать код, только когда представил что у меня будут trace-файлы и snapshot-ы, и что я с ними буду делать.

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

WH>Тут проблема в том что мы используем разные средства разработки. Вы с Евгением пишете на С++, а я, ИТ, Влад, Синклер пишем на C# с ReSharper'ом. Так вот когда пишешь на С++ то писать и изменять когд намного сложнее чем делать тоже самое на C# с ReSharper'ом. Вот по этому вам нужна выделеная стадия проектирования, а нам нет. Мы можем проектировать прямо в коде ибо можем очень легко изменять этот код.

Вообще-то проектирование — это далеко не только спецификация публичных и защищенных интерфейсов типов... Проектирование начинается с use-cases, и вот в этом вопросе никакой Решарпер и никакая студия тебе не помогут. Проектирование начинается с анализа требований, уточнения их, выделения на функциональные и нефункциональные. Особенно интересны последние. Относительно них бросание в кодирование может только навредить. Почему? Потому как объем нефункциональных требований априори всегда стремится к бесконечности. Поэтому проектирование, помимо прочего, помогает ПЛАНИРОВАНИЮ проекта, тем, что более-менее детально обрисовывает функциональность всех подсистем разрабатываемой системы. Позволяет расставить приоритеты и оценить достижимость пунктов плана.


--------
Понятное дело, что заставить работать можно все, что угодно. Пинками, рефакторингом и пошаговой отладкой. Я уже как-то озвучивал наблюдение, что еще никогда не проводил столько времени в пошаговой отладке, как работая на C#. Признайтесь, вы все часто используете пошаговую отладку на дотнете... Без нее почти никак. Получается интересный момент — программист написал и не понял толком что именно он написал, раз требуется пошагово пройтись по программе. В С++ я такого не помню. Были, разумеется, заплывы с пошаговой отладкой, но явно на порядок реже. Может быть, потому что удавалось писать достаточно верифицируемый на этапе компиляции код? Или может быть потому, что вероятность получить всякие NULL/null была на порядки ниже? Ибо в С++ типы активно используются по значению/ссылке, что придает достаточно детерминированности, а разработчику — уверенности в поведении экземпляров типов.

А нетипизированные коллекции в .Net 1.1 и еще тонна нетипизированных интерфейсов и сервисов? До сих пор вздрагиваю... Нельзя было эти генерики сразу реализовать, что-ли? И кстати, дохрена сервисов так и остались нетипизированны. Вот тебе и причины необходимости плотного обкладывания юнит-тестами в сочетании с пошаговыми заплывами.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Интересно, что вы спорите с совершенно другой позицией, чем озвучиваемая вашим оппонентом... Т.е. при критике его позиции у вас идет речь о полном vs. итерационное проектирование/разработка, в то время, как ИТ и Влад озвучивали позицию отсутствия выделенного этапа проектирования до кодирования, а eao197 настаивал на его полезности (по крайней мере, для себя). Наличие выделенного этапа проектирования вполне возможно на каждой итерации. Более того, это вполне согласуется с рекомендациями всевозможных RUP, XP etc.

1. Тут никто не спорит с некой мифической позицией. Тут скорее наблюдается сме...ки и п...ханьки по поводу чужишь слов без высказывания собственной позиции.
2. Кто говорил об отсуствии этой самой стадии проектировани? Она есть, но намного короче, так как объем планируемых действий меньше, а уровень планирования выше. И она другая. Так как процесс планирования становится короче план во многих случаях может быть просто продуман в уме. Если это не возможно, то мысли оформляются в осязаемом виде и проверяются на корректность. Ну и она растянута во времени сливаясь с процессом кодирования. Ведь как правильно заметили Вольфхаунд и ИТ простота изменения кода убирает комплекс боязни ошибки. Проще ошибиться и переделать нежели бесцельно тратить время пытясь во что бы то ни стало уберечься от ошибок проектирования.

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

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

WH>>Тут проблема в том что мы используем разные средства разработки. Вы с Евгением пишете на С++, а я, ИТ, Влад, Синклер пишем на C# с ReSharper'ом. Так вот когда пишешь на С++ то писать и изменять когд намного сложнее чем делать тоже самое на C# с ReSharper'ом. Вот по этому вам нужна выделеная стадия проектирования, а нам нет. Мы можем проектировать прямо в коде ибо можем очень легко изменять этот код.

V>Вообще-то проектирование — это далеко не только спецификация публичных и защищенных интерфейсов типов... Проектирование начинается с use-cases, и вот в этом вопросе никакой Решарпер и никакая студия тебе не помогут.

Есть такая теория по которой use-cases-диаграмы — это не более чем обман и очковтирательство.

Еще раз повторюсь, что лично у меня обычно нет проблем с продумыванием большей части функциональности. Ну, а когда они все же появляются, то нет никаких проблем прибегнуть к банальному описанию своих мыслей в виде текста и диаграм. Гарантии, что ты не ошибешся конечно все равно никакой. Но задача ведь в другом. Она в том, чтобы устаканить в голове используемые принципы и подходы. А далее все просто. Как только ты получашь работающую программу, то не составляет проблем проверить насколько ты был прав и если ты все же ошибся, то быстренько переделать.

Вот возможность быстренько ошибиться и переделать, а не трястись на священностью процесса планирования и является сутью подхода.

Для лучшего понимания приведу аналогию. Когда я наполняю ванную я могу долго и крапотливо подбирать температуру строи воды чтобы когда ванна наполнится иметь воду той температуры что нужно. Но я выбираю другой подход. Я включаю в кране ванных только горячую воду, а в кране раковины (выход которй я направляют в ванну) отворачиваю оба крана на полную катушку. Холодная вода в кране раковины течет примерно в два раза лучше чем в ванее. Получается так, что ванна наполняется очень быстро, но вода получается несколько холодноватая. После наполнения ванны я банально побую воду рукой и если она слишком холодная открываю краны с горячей водой и компенсирую температуру.

Что это дает? Ванна у мен очень большая. Наполнить ее из одного крана занимает слишком много времени. Два крана (особенно учитывая намного большую пропускную способность второго) позволяют сократить этот процесс до пары минут. Естественно, что подобрать правильное сочетание темпиратуры воды в обоих кранах при таком подходе слишком сложно. Можно конечно попытаться добиться чтобы каждый из кранов давал нужную температуру, но к сожалению это привело бы к тому, что напор воды был бы намного более слабым, так как горячая вода имеет слишком малый напор.

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

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

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

Мне влом переписывать твое письмо. Проти его и примени каждый пункт притензий к своим словам. За одно сэкономим на месте в БД и на моем времени.

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

WH>>>Тут проблема в том что мы используем разные средства разработки. Вы с Евгением пишете на С++, а я, ИТ, Влад, Синклер пишем на C# с ReSharper'ом. Так вот когда пишешь на С++ то писать и изменять когд намного сложнее чем делать тоже самое на C# с ReSharper'ом. Вот по этому вам нужна выделеная стадия проектирования, а нам нет. Мы можем проектировать прямо в коде ибо можем очень легко изменять этот код.

V>>Вообще-то проектирование — это далеко не только спецификация публичных и защищенных интерфейсов типов... Проектирование начинается с use-cases, и вот в этом вопросе никакой Решарпер и никакая студия тебе не помогут.

VD>Есть такая теория по которой use-cases-диаграмы — это не более чем обман и очковтирательство.



Use-cases — это необязательно UML диаграммы. Это именно то, что означает дословный перевод. Спецификации "внешних" требований через сценарии использования.

VD>Еще раз повторюсь, что лично у меня обычно нет проблем с продумыванием большей части функциональности.

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

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

А твое "продумывание", это из разряда — вот если я вот здесь в коде это и это поменяю/добавлю/переделаю (нужное подчеркнуть) то получу такую-то и такую-то возможности... А каков приоритет получаемых новых возможностей? На самом деле никого подробности кода зачастую не интересуют. Надо отталкиваться от обратного: "Требуется такая-то функциональность... для ее реализации требуется то-то и то-то, последнее в свою очередь потянуло за собой пятое и десятое, при определенных обстоятельствах возможно пятнадцатое... И вот наконец на 20-м моменте ты полностью представил себе, что именно надо делать, сколько примерно трудоемкости/времени займет, как пересекается с уже решенными задачами или еще не решенными и т.д."


VD>Как только ты получашь работающую программу, то не составляет проблем проверить насколько ты был прав и если ты все же ошибся, то быстренько переделать.

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

Да рефакторинг мы делаем часто... но рефакторинг — это "косметический" уход за телом, не более того.


VD>Вот возможность быстренько ошибиться и переделать, а не трястись на священностью процесса планирования и является сутью подхода.

Хинт. Макетирование тоже может являться частью проектирования... Да именно.
Когда:
1. Необходимо досконально разобраться с предполагаемыми к использованию технологиями, дабы иметь возможность оценивать трудоемкость на выбранном на предыдущей итерации пути.
2. Заказчик плохо представляет себе use-cases.

И это еще не все. Итеративный процесс проектирования предполагает возвраты и уточнение результатов предыдущих итераций.

VD>Точно так же я могу спроектировать систему намного (я бы даже сказал радикально) быстрее если не буду "дышать" над каждым пунктом и если опущу тонкости до того момента когда они действительно потребуют проработки.

Хинт. Никто над каждым пунктом и не дышит в течении процесса проектирования. Есть требования. Есть некий текущий уровень проектирования со своими задачами соответствующего уровня. На некоторых уровнях, разумеется, мазки очень крупны. Будет большой ошибкой пытаться на этих уровнях объять какие-то подробности имплементации каких-то подсистем. Вернее, зачастую приводит к ошибкам.

VD>В итоге ошибаюсь я конечно чаще, но добираюсь до финиша первым, так как иду на полных парах и коректируюсь только когда это не обходимо.

Такие вещи ты мог бы познать только в сравнении и только на приличных проектах, доведенных до конца. Никакие быстрые промежуточные результаты никого всерьез не интересуют.

VD>"Стандартный" же способ проектирования предлагает сразу спланировать маршрут без ошибко.

Чушь. Стандартный способ определяет методологию, обладающую полнотой и гарантирующую полное выполнение всех требований. Пытаясь выделить наиболее важную черту, я бы сказал, что "стандартный" итеративный процесс разработки призван наиболее точно выявлять цели и задачи каждого уровня абстракции. Причем гарантирует, что ты ничего важного не упустишь. Поверь, мелкие детали имплементации никого толком не волнуют. У многих задач есть очень большое кол-во решений, т.е.ты не прав, считая что обычно проектируют "сразу правильный маршрут". Нифига, проектируют системы абстракций. причем таким образом, что неверный маршрут в какой-то из них не должен губительно сказаться на остальном проекте. Дай бог, чтобы количество уровней абстракций хотя бы правильное выбрать на первой итерации. На каждом уровне и в каждой отдельной подсистеме может быть свое мини-проектирование и даже использование антогоничных подходов. Например, в GUI мне импонирует XP.

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

последний пункт на самом деле выполняется постоянно, и между итераций и во время итераций, т.е. проектировщик/проектироващики должен осознавать, во что именно выливаются их задумки.

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

VD>Но это невозможно так как многие его тонкости становятся известны только когда ты реально с ними сталкнешся.

Вот все, что ты здесь говоришь, весьма похоже на обсуждение каких-то экспериментальных работ. Представь, что с технологией УЖЕ знакомы. Представь, что непонятные моменты УЖЕ были отмакетированы и выработаны подходы к решению неких типовых технических задач. Это ничуть не уменьшает потребности в проектировании, а по тебе выходит, что и проектировать тогда ничего не остается.

Здравствуйте, eao197, Вы писали:
E>Таких примеров можно сотнями приводить. Например, если бы с ACE не шло несколько мегабайт тестов и примеров, то от их Reference Manual толку вообще было бы ~0%.
E>Но меня плохие примеры не интересуют, мне хочется делать хорошие примеры. Чтобы на мои проекты и мою документацию народ не плевался.
Это что-то из области фантастики. Разве что ты будешь сопровождать каждый метод блок-схемами.

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

Как мне показалось, квинтэссенция здесь:

V>Да не, не фигня. Просто трудно признаться самому себе, что для себя УВАЖАЕМОГО, такой момент, как объем и качество халявы, является значимым аргументом, по сравнению с провалом выразительных ср-в инструментария, коим придется пользоваться. Это требует в какой-то мере переступить через себя.

И вот с этой квинтэссенцией я не согласен. Потому что то, что предлагается в качестве халявы плюсовики давно уже привыкли писать сами. Плохо это или хорошо — тема отдельной дискуссии. Суть в том, что нежелание отказываться от C++ связано далеко не только с наличием мегатонн халявы. Это вообще дело десятое.

Понимаешь ли, мы всегда продаём добавленную нами стоимость. То есть, нечто такое, что вышло непосредственно из-под наших рук. Следовательно, этот объём всегда должен быть большим (не в строчках кода, разумеется). Следовательно, нужен язык с мощными выразительными возможностями. В случае же C# мы хоть и получаем "тонны халявы", но теряем в инструментальной части. А тонны халявы конкурентным преимуществом не являются — они у всех автоматически есть.

Ты не подумай, я не агитирую за то, чтобы отказаться от библиотек. Ни в коем случае. Меня интересуют только те сложности, которые находятся "в промежутке" между готовыми библиотеками и целевым продуктом. Абсолютный начальный уровень библиотек совершенно не важен — хоть готовые офисы. Важен тот набор методов, которые я могу использовать для наращивания этого уровня. А тут мне предлагается м-м-м... кашеобразный бейсик-переросток в комплекте с инструментарием, который обеспечит мою непрерывную загруженность перемалыванием этой каши в строгом соответствии с принципом: "Хрен здесь думать, это же не шахматы!". Ну ёжкин хвост, прям как дети!

Да, конфетка-то в виде тонн халявы есть, но цена её — ухудшение стиля проектирования и реализации, переориентация с "сделать и забыть" на "сделать и переделать". Так, например, исключение МН вроде бы, значит не много, но на самом деле оказывает сильнейшее влияние на подход к проектированию. Та же ситуация и с шаблонами (естественно, я в курсе, что они уже частично появились в C# 2.0). Зато есть решарпер. А вместе с ним и разные вопли, кои прочесть можно хотя бы в этой ветке. Как там у кого-то было: "решарпер читает мои мысли!", это, как ты понимаешь, признак не высоты полёта решарпера, а кое-чего обратного. А с учётом сомнительных нововведений в C# положение будет усугубляться. Либо... либо C# превратится в подобие C++.

Ну и сразу возникает вопрос: а на хрена крюки выписывать? Апелляции к наличию большой библиотеки сразу отметаются по факту того, что для C++ этих библиотек хоть бульдозером греби. Притом любую из них при желании можно выкинуть. По сути, то же самое можно сделать и для .Net, оставив только рантайм, но снова упираемся в специфические особенности C#. Голый рационализм подсказывает, что "нас надувают", диспуты с поклонниками .Net только усиливают это впечатление, анализ приводимых ими примеров усиливает впечатление вдвойне, простое логическое размышление окончательно превращает гипотезу в утверждение: таки да, нас надувают. К тому же, ситуация с C# очень похожа на PL/1 и Ada.

V>Да и всякие Nemerle и прочие функциональные языки на подходе... И все это в сочетании с действительно гладкой стыковкой в рамках фреймворка... Ведь и у тебя и у меня достаточно опыта по стыковке разных по парадигмам языков и технологий в одном проекте... В общем, это всегда были уникальные решения "по месту"... Сейчас, очевидно, все не так.

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

V>Есть много вещей, которых не хватает в современных языках для .Net. Например, они недодумали о совместимости делегатов и пользовательских функциональных объектов в современных компиляторах. Самое прикольное, что эту совместимость можно запросто реализовать, но пока только через ручную байткодогенерацию.

Согласен, всё это можно. Беда только в том, что программист всё равно остаётся в рамках убогой выразительности C#. Кому-то это безразлично, а мне это остро не нравится. Точь-в-точь то же самое, что у меня когда-то было с Java. С проблемами single inheritance я нахлебался по уши ещё в Turbo Pascal 5.5/6.0... И плевать мне на мегатонны Java-библиотек. Я же не библиотеки собираюсь продавать, верно?

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

EXO>Вообще, все эти разговоры о скорости написания кода мне достаточно смешны. Просто лично у меня на кодирование и отладку (!) в общей сложности уходило (раньше — пока занимался именно програмингом) примерно полтора часа в день.

На одном из моих недавних проектов у меня на кодирование и отладку уходило 15 минут в день. Остальное время я проводил в беседах с друзьями, за чтением RSDN и прочих дозоров. А народ в это время бегал запаренный два месяца перед релизом, размахивая бумажками и диаграммами. У меня же баг-теккинг был чист как слеза. Причём здесь скорость написания кода? А при том, что я свои косяки не загонял подальше в угол и не прикрывал их бумажками и диаграммами, а лечил сразу на месте и не доводил код до неконтролируемой помоечной консистенции.

Чуток дополню.

Здравствуйте, vdimas, Вы писали:
VD>>Есть такая теория по которой use-cases-диаграмы — это не более чем обман и очковтирательство.

V>
V>Use-cases — это необязательно UML диаграммы. Это именно то, что означает дословный перевод. Спецификации "внешних" требований через сценарии использования.

Более того, я стараюсь избегать UML представления специально. Потому, что оно слишком формализовано. А на этом этапе строгость и формализация ЕЩЕ вредна. Рано. Здесь она будет связывать мышление, могут потеяться крайне ценные "ирациональные" идеи. "Озарения", которые возможно могли бы повернуть проект вообще дугим боком и показать в ином ракурсе.


VD>>Еще раз повторюсь, что лично у меня обычно нет проблем с продумыванием большей части функциональности.

"Продумывание функциональности" — далеко не первый этап. До нее идет "продумывание концепции". Поскольку только в этом случае проект будет "концептуально целостным".
А еще ДО того стоило бы поговорить о "миссии проекта". Ответить на вопросы:
— Частью чего бОльшего, является то, что мы собираемся делать?
— Подсистемой какой внешней системы будет нашь продукт?
— Какова его роль в этой внешней системе?

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

Если же начинать с "продумывания функциональности"... да, порой к "финишу" можно попасть быстрее. И, к сожалению, нынче стало модно этим увлекаться. Резултат грустный — стремительно сокращается "время самостоятельной жизни" продуктов. Если продукт был построен на принципиальной "доработке напильником" под итоговые требования, то почти наверняка придется снова браться за напильник при каждом их изменений. Просто потому, что "большая внешняя система" не рассматривалась и сообветсвенно любые процессы в ней выльются в "неожиданные изменения требований" к разрабатываемой подсистеме. В результате стоит разработчикам "забыть" свой продукт на пару месяцев, как он начинает стремительно устаревать.
Последнее время стало опять же модно, списывать все на "ускорение темпа жизни". На мой взгляд, по крайней мере на половину, это отговорки разработчиков, которые либо ленятся (либо разучились) системно и концептуально мыслить. Ускорение "темпа времени" реально есть, но вовсе не такое уж большое. В качестве примера могу сказать, что у меня есть один старый продукт (SCADA-система), насчитывающий примерно 120тыс. строк кода на C, С++ который продается уже 11 лет, после того, как я поставил в нем последнюю точку. Да, сейчас он уже морально устаел и года 4 назад его стоило бы заменить. Но даже с учетом этого получается 7 лет нормальной жизни продукта без "дозатачивания". Таким образом, даже если "традиционное проектирование" обходится дороже (что не всегда), это вполне окупается временем жизни подуктов.

Здравствуйте, VladGalkin, Вы писали:
E>>Скорость моей разработки определяется не скоростью набора кода в редакторе, а скоростью продумывания и проектирования. Чем лучше решение продумано, тем меньше оно тебует кода и времени на отладку.
VG>Отсюда парадокс: идеальное решение не требует кода и времени на отладку, то есть его нет.

Кстати, не такой уж и парадокс. Есть примеры.
Хотя бы вот в этой книжке:
http://www.alpina.ru/book/36/
а вот в этой статье некоторые выдержки из кникги
http://www.osp.ru/cio/2004/06/022.htm

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

VD>Так вот грубое наполнение под полным напором позволяет решить задачу быстро, но не очень точно. А возможность быстро долить нужное количество очень горячей воды и то что нужен очень небольшой ее объем позволяют решить задачу быстро и просто.

Так фокус-то в том, что при хорошем проектировании сразу многие вещи становятся ясными. И не надо наливать полную ванну воды, если вполне достаточно принять душ.

VD>Точно так же я могу спроектировать систему намного (я бы даже сказал радикально) быстрее если не буду "дышать" над каждым пунктом и если опущу тонкости до того момента когда они действительно потребуют проработки.

На самом деле, всё зависит от того, что подразумевается под "финишем". Если появление прототипа — это одно. Если же появление всей запланированой функциональности — это уже совсем другое.

То-то я смотрю, плюхи в Янусе исправляли чуть не пару лет, или сколько он там существует.

VD>А быстрая и безболезненная модификация кода позволяют устранить появлющиеся в следствии этого перекосы. В итоге ошибаюсь я конечно чаще, но добираюсь до финиша первым, так как иду на полных парах и коректируюсь только когда это не обходимо. "Стандартный" же способ проектирования предлагает сразу спланировать маршрут без ошибко. Но это невозможно так как многие его тонкости становятся известны только когда ты реально с ними сталкнешся.

Ещё раз: проектирование как раз и предполагает, что большая часть трудностей будет выловлена на его этапе. Я не раз сталкивался с тем, что правильное проектирование (это не настолько трудная задача, как может показаться на первый взгляд) даёт на выходе ну очень большую сложность проекта, которую и показывать-то страшно, а потому приходится бросаться в программирование либо заведомо недопроектировав, либо заведомо занижая сроки, либо заведомо обрезая функциональность. Причина здесь вовсе не в какой-то порочности проектирования как такового, а в наличии у заказчиков банального психологического барьера. Например, нельзя заложить срок реализации 10 месяцев, а можно назвать не более, чем 5 месяцев. Хотя ясно, что при этом первоначальные 10 месяцев превратятся в ~14-15 с учётом времени, потраченного на реализацию прототипов.

Так что, ты уж поверь, очень давно и очень хорошо известна цена "быстрого программирования" и "проектирования в коде".

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

WH> когда пишешь на С++ то писать и изменять когд намного сложнее чем делать тоже самое на C# с ReSharper'ом. Вот по этому вам нужна выделеная стадия проектирования, а нам нет. Мы можем проектировать прямо в коде ибо можем очень легко изменять этот код.

Выделенная стадия проектирования нужна не столько для того, чтобы избежать лишних модификаций кода, сколько для того, чтобы уменьшить общее количество циклов модификация-тестирование-анализ сбоев-модификация-{...}, в которых стоимость внесения модификаций традиционно играет далеко не первую роль.

VladD2,

> 2. Кто говорил об отсуствии этой самой стадии проектировани? Она есть, но намного короче, так как объем планируемых действий меньше, а уровень планирования выше.

Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше" и "уровень планирования выше"? (Чтобы сократить количество оборотов в хождении кругами, можем заранее считать, что в обоих рассматриваемых случаях процесс разработки итерационный.)

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

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

E>>>Строки отлаженного кода штука дорогая.
S>>Так никто и не предлагает отлаживать этот код. Ты же не занимаешься отладкой идей на бумаге? Вот и этот код начинает отлаживаться только в том случае, если дожил до реального использования.

E>Один умный человек когда-то на лекции сказал: "Ты знаешь что-то сам только когда можешь объяснить это другому".

Это слова Давида Гильберта.
Он сказал как-то примерно так: ты по настоящему понимаешь предмет если можешь выйти на улицу и объяснить его первому встречному.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

V>Понятное дело, что заставить работать можно все, что угодно. Пинками, рефакторингом и пошаговой отладкой. Я уже как-то озвучивал наблюдение, что еще никогда не проводил столько времени в пошаговой отладке, как работая на C#. Признайтесь, вы все часто используете пошаговую отладку на дотнете... Без нее почти никак.

Я не знаю как "они", я как в С++ пошаговую отладку использую эпизодически, так и в тех нескольких задачках на С# которые я написал я её не использовал. По моему, это от языка не зависит. Больше от подходов к работе и от опыта.
Хотя С# действительно провоцирует на грязную работу. Ну так не поддавайся на провокации.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

Ш>Я не знаю как "они", я как в С++ пошаговую отладку использую эпизодически, так и в тех нескольких задачках на С# которые я написал я её не использовал. По моему, это от языка не зависит. Больше от подходов к работе и от опыта.
Ш>Хотя С# действительно провоцирует на грязную работу. Ну так не поддавайся на провокации.

не получается... очень много системных вещей приходит через object, причем, даже в таких местах, где вообще принципиально возможен только 1 тип, например InitializeLifetimeService(). Когда первый раз с таким зверем сталкиваешься, поневоле ставишь точку останова и долго смотришь в инспекторе — что же это за зверь к нам пришел под личиной object? И таких "бузымянных", то бишь безтиповых сервисов — тонны. В первые 2 года дотнетописания как раз куча времени уходит на знакомство с ними. Разумеется, последний год, заплывы все реже, но зачастую без них никак, особенно с этими ремоутингами, синками и форматтерами каналов.

Юзаю IIOP.Net — это CORBA channel для .Net. За первые месяцы эксплуатации исправил десятки багов, как в форматтерах каналов, так и в компиляторе и общем их фреймворке... А отлаживать форматирование и прохождение ремотинг-пакетов — то еще удовольствие.

Вся система ремотинг-реализована как набор простых объектов, у которых есть св-ва типа объект, либо массивы object[]. Придти в них может все что угодно...

Ситуацию осложняют постоянные пробросы исключений в TCP-канале. Суть в чем: есть такая опция — break on exception. Очень удобно — поставил опцию и получил break в месте выброса exception. Так вот, внутренности TCP-канала постоянно пробрасывают и глотают в нутри себя исключения... Типа, логика там на них, что ли... В общем, этим полезным способом вылавливать ошибки не получается (канал фонит исключениями примерно каждые 10 сек). И как альтернатива — глубокие пошаговые погружения в подробности ремотинга и всего этого нетипизированного мусора, на котором он построен.

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

V>Ситуацию осложняют постоянные пробросы исключений в TCP-канале. Суть в чем: есть такая опция — break on exception. Очень удобно — поставил опцию и получил break в месте выброса exception. Так вот, внутренности TCP-канала постоянно пробрасывают и глотают в нутри себя исключения... Типа, логика там на них, что ли... В общем, этим полезным способом вылавливать ошибки не получается (канал фонит исключениями примерно каждые 10 сек). И как альтернатива — глубокие пошаговые погружения в подробности ремотинга и всего этого нетипизированного мусора, на котором он построен.

Интересно. По идее, автостоп на брошенных исключениях работает только для режима Just My Code, а в нем тебе кишочки канала не должны быть видны. А если и видны, достаточно пойти в диалог Exceptions и отключить лишний фон.

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

E>>И еще, я пользуюсь gvim -- это далеко не Notepad

VD>Это не имеет значения. Главное, что ты занимашся закатом солнца вручную и твоя эффективность во много раз ниже.

E>>Главное, что это не осознает мой работодатель.

VD>Гм. Работодатель зависит от результатов твоего труда. Так что если он очено долго не будет это осозновать, то рискует вылететь в трубу. Хотя конечно если этого не происходит, то на эффектиность разработки можно наплевать... до поры... до времени...


Имхо, розовый слоник чересчур категоричен. Не стоит всех по себе мерить.