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

X> Лично я, тоже не могу в это поверить. Как можно сесть и сразу начать писать (как IT например) какой нибудь крупный (или средний) проект. Может объясните мне глупому ? Наверное для этого надо быть очень очень умным и иметь огромный опыт или наоборот быть идиотом

На самом деле, это просто. Очень умным быть не обязательно, главное не быть полным идиотом.

eao197 пропагандирует во всех отношениях правильный и устоявшийся стиль мышления — подумай, нарисуй на бумажке, потом закодируй. Современные супер-дюпер архитекторы заменятю бумажку какой-нибудь рисовалкой типа Visio. Но eao197 с бумажкой в этом смысле не очень сильно отстал, не исключено, что для него этот способ гораздо более эффективнее

Проектирование как отдельная стадия очень даже имеет смысл, действительно имеет и действительно смысл, тогда, когда речь идёт о передаче знаний от одного человека другому. Но судя по постам eao197 этот кто-то другой — он сам. Он просто хочет передать свои же знания самому же себе во времени. Т.е. когда-то он потратил 10 минут на идею, затем 2 часа на воплощение этой идеи на бумаге, что через 2 месяца безусловно гарантировало ему сохранение 10-ти минут на воспроизведение этой самой идеи в течении 20 минутного разглядывания бумажек 2-х месячной давности.

Всё нормально. Только если он сразу начал бы писать код, то не исключено, что задача была бы решена ещё 2 месяца назад. Либо была бы решена на 90%.

---

У меня складывается стойкое впечатление, что вы думаете, что если я или Влад начинаем сразу писать код, то этап проектирования как таковой ислючается. Но это не так. Возьмём, например, дизайн базы данных. Можно взять Визио, нарисовать в нём таблички, затем перенести их в SQL Server. Затем внести какие-то изменения в диаграммы, перенести эти изменения в SQL Server. И так до посинения.

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

К тому же я могу взять встроенный в SQL Server диаграммер. Он не такой навороченный, но в отличии от Визио позволяет не делать одно и то же дважды и мгновенно отражает любые изменения в структуре БД. Т.е. я получаю тот же результат что и с Визио, но гораздо быстрее.

То же самое и с кодом. Я начинаю одновременно проектировать систему и писать код, пробовать в живую, ошибаться, переписывать. Бывают, конечно, случаи, когда открываешь лаптоп, задумываешься что и как делать, смотришь 40 минут в окно, закрываешь лаптоп и откладываешь свою писанину до завтра. Идея ещё не сварилась, она пока не готова. Не готова для воплощения ни в коде, ни на бумаге.

Вопрос — что же изменилось, почему те кто ещё вчера агитировал за обязательное проектирование, сегодня утверждают, что во многих случаях его как стадию проекта можно опустить и сразу начинать писать код?

Чтобы ответить на этот вопрос, нам нужно понять что даёт нам проектирование на бумаге или в Визио. Одной из целей проектирования явлюется минимизация затрат на кодирование, а именно затрат на переделку уже готовых вещей, в случае, если изменился дизайн системы. Такие изменения, как правило, самые болезненные и вносят в систему наибольшее количество проблем. Поэтому, мы сначала всё досконально продумываем на бумаге и только потом переносим это в код.

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

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

Теперь ответ на вопрос что изменилось. Изменились средства разработки. С решарпером или с 2005-й студией, я больше не боюсь глубоких переделок кода. Это стало вполне обычным делом. Если я вижу кривизну дизайна или его несоответствие новым требованиям, я не задумываясь переделываю всё что меня не устраивает. Средства рефакторинга позволяют это делать очень быстро. Например, переименование метода или изменение порядка его параметров с изменением всех ссылок на него делается в течении нескольких секунд. Попробуй это корректно сделать поиском/заменой. Генерация заглушек методов позволяет создавать их прямо из мест использования. А это значит, что я могу не отвлекаться от текущей задачи, что позволяет мне сохранить минуту-две. Скорость набора кода обеспечивает автокомплит. Интеллисенс позволяет держать в голове только ссылки на информацию, но не весь MSDN.

Таким образом, первое из перечисленных выше преимуществ проектирования становится не актуальным.

Остаётся документирование. Точнее не оно само, а возможность с помощью него быстрого воспроизведения информации. Средства современных IDE по организации проектов и навигации по коду сводят и это преимущество проектирования практически в ноль. Разбиение задачи на проекты, а проекты на фолдеры делает навигацию по классам в Solution Explorer не сложнее чем перебор бумажек с диаграммами на столе. Поиск ссылок на класс или метод — это одна секунда. За кнопку F12 разработчикам студии надо вообще поставить 5 с плюсом. Закладки, аутлайнинг и partial классы позволяют больше не беспокоится о размере классов и устраняют проблемы навигации по ним. Раньше я старался держать как можно больше файлов открытими, чтобы иметь возможность вернуться в место где я был до этого. Сейчас после написания очередного функционала я делаю Close All Documents, так как много открытых документов — это всё же не очень удобно, а найти нужное для меня место в проекте с современным возможностями IDE — задача элементарная. Наличие отработанных соглашений усиливает эффект от всего перечисленного и позволяет нормально ориентироваться не только в своём коде, но и в коде своих коллег.

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

Что же у нас осталось положительного от проектирования на бумаге в сравнении с проектированием прямо в коде? А ничего не осталось. Учитывая то, что проектная документация имеет тенденцию довольно быстро устаревать и требует серьёзных усилий по поддержке её в актуальном состоянии, то получается, что сегодня, при поддержке современных IDE, от неё больше вреда чем пользы. Впрочем, если заказчик готов за неё платить, то почему бы и нет

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

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