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

VD>Вот такая получается фрэйдистская фигня.

Ты забываешь, Влад, что то, что тебе открылось через C# (относительно недавно), уже давно было известно и привычно в мире Java.

Ну и кроме того, если ты программируешь на C# под Windows, то это совсем не значит, что твой опыт будет полезен мне в C++ под Unix. А мне платят именно за C++.
И если я буду менять язык разработки, то ближайшим кандидатом будет не C#, а Java. Уж извини, такой се ля ви, что Java для многих вещей гораздо более привлекательна, чем C#.

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

E>Ты забываешь, Влад, что то, что тебе открылось через C# (относительно недавно), уже давно было известно и привычно в мире Java.

Я ничего не забываю. Не нужно отвлекаться.

E>Ну и кроме того, если ты программируешь на C# под Windows, то это совсем не значит, что твой опыт будет полезен мне в C++ под Unix. А мне платят именно за C++.

Тебе не платят за С++ и темболее за то что что-то под Линукс. Ты решил использовать С++ и нашел соотвествующую работу. Как в прочем и Линукс. Если ты захочешь, то завтра можешь найти себе работу на Хаскеле под Мак ОС. О том, что работа на C# под виндовс ищется за пять минут думаю и говорить не стоит.

E>И если я буду менять язык разработки, то ближайшим кандидатом будет не C#, а Java. Уж извини, такой се ля ви, что Java для многих вещей гораздо более привлекательна, чем C#.

И? Ты что-то хочешь этим сказать? Или думашь, что с тобой кто-то будет спорить? Для Явы есть IDEA и Ява в общем-то полноценное средство разработки. На ней тоже можно работать эффективно.

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

VD>Измерил объем файлов исправленных мной (между делом) в проекте Rsdn.Editor за последнюю неделю. Получилось 30 файлов общим объемом 455 килобайт.

А сколько строк было изменено?

VD>Можно махать, что называется "не глядя" 500 кил исходников и получать очень даже работающее приложение причем без юнит-тестов и даже без серьезной отладки. 99% ошибок или не делается вовсе, или устраняются на стадии компиляции.

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

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

E>>Ну и кроме того, если ты программируешь на C# под Windows, то это совсем не значит, что твой опыт будет полезен мне в C++ под Unix. А мне платят именно за C++.

VD>Тебе не платят за С++ и темболее за то что что-то под Линукс. Ты решил использовать С++ и нашел соотвествующую работу. Как в прочем и Линукс.

Я нашел себе работу, которая мне интересна и устраивает по зарплате. Причем не сразу.
И не программировал бы под Linux или любой другой Unix. Да только так получается, что большинство наших инсталляций как раз под Линуксом. Так что подобные требования диктует рынок.

VD> Если ты захочешь, то завтра можешь найти себе работу на Хаскеле под Мак ОС.

Думаю, что многие здесь заинтересовались бы такой работой. Не подскажешь координаты?

VD>И? Ты что-то хочешь этим сказать?

Я хочу сказать, что многие здесь понимают реальное положение вещей. И если задача стоит программировать на Java, то нет смысла отказываться от возможностей Eclipse, IDEA или NetBeans. А если речь идет о C++, где возможности по рефакторингу и интелисенсу не такие продвинутые, то каждый приспосабливается так, как ему удобно. Здесь не так много оголтелых фанатиков, как тебе кажется.

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

E>Самый полезный урок, который я вынес после программирования на динамических языках, это что не протестированный код будет содержать ошибки. Так оно и есть (даже для статически типизированных языков). И наличие большого числа тестов для динамических языков, как раз, дает увереность в том, что все работает так, как задумывалось. Хотя и стоит это изрядных трудов по написанию тестов. Но, думаю, оно того стоит.

Твои уроки устарели. Пора учить новые.

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

VD>Твои уроки устарели. Пора учить новые.

Ты всерьез будешь возражать против:

не протестированный код будет содержать ошибки

?

Знаешь как говорят: тесты способны показать наличие ошибок, но не их отсутствие. Даже в протестированном коде есть ошибки. А уж в непротестированном -- подавно.

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

E>Знаешь как говорят: тесты способны показать наличие ошибок, но не их отсутствие.
Имхо, этим утверждением Дейкстра пытался показать ущербность тестирования по сравнению с формальным доказательством корректности .

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

VD>Вот пример из будквально того что было только что.

А вот пример из того, что было у меня только что. Еще в прошлом году, в ноябре, я занялся внедрением в SObjectizer средств поддержки коммуникаций из ACE. И требовалось сделать это с максимальным сохранением совместимости с предудущими версиями. И при том, что существующий код транспортных агентов (отвечающих за коммуникации) так же не желательно было трогать. Сначала я разобрался с тем, что из ACE можно взять, затем, как это можно встроить, затем, что потребуется изменить. Все это было изложено на бумаге. Какая-то малая часть кода была написана. Потом работу пришлось прервать и возможность возобновить ее появилась только на этой неделе. По старым наброскам я легко восстановил весь первоначальный замысел, по коду понял, что требуется сделать. И сделал. Сегодня заработали как клиентские, так и серверные каналы. Потребовалось на это недели три в ноябре (по два часа в день) и сейчас четыре дня (по три-четыре часа в день). Может быть, это и много, но я не расчитываю заниматься его переписыванием в ближайшие полгода-год (а предыдущий вариант вообще работал с 2003 года), то это совсем не много, имхо.

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

IT>>Я, с некоторых пор, первый. Сажусь и начинаю писать код

VD>Проблема в том, что все кому мы тут что-то пытаемся объяснить просто не могут поверить в описываемые прицыпы. Они привыкли, что это невозможно. Отсюда им кажется многое не вероятным.

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

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

Здесь кроме наличия самих средств ещё очень важно научится их применять. Что толку от рефакторинга, когда код уже превращён в помойку? Можно наверно самых больших мух отогнать, но дурно пахнуть всё равно будет.

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

IT>Здесь кроме наличия самих средств ещё очень важно научится их применять. Что толку от рефакторинга, когда код уже превращён в помойку? Можно наверно самых больших мух отогнать, но дурно пахнуть всё равно будет.

Речь идет о коде вообще или о чьем-то конкретном коде?

А вообще:

Чисто не там, где убирают, а там, где не мусорят.

ИМХО: кривой код никаким рефакторингом не выправишь.

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

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

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

IT>>Здесь кроме наличия самих средств ещё очень важно научится их применять. Что толку от рефакторинга, когда код уже превращён в помойку? Можно наверно самых больших мух отогнать, но дурно пахнуть всё равно будет.

E>Речь идет о коде вообще или о чьем-то конкретном коде?

Это я к тому, что рефакторинг можно использовать как во благо человечества, так и во зло.

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

IT>Я думаю, что это ещё связано и с тем, что это выглядит как будто проектирование как стадия совсем отсутствует. Но это не так. Оно точно также присутствует, только инструментами является не листок бумаги или какая-нибудь рисовалка, а сам компилятор и среда.

Чтобы не быть голословным, вот как выглядит проектирование у меня (это попытка спроектировать реализацию интерфейса timer_thread_t с помощью ACE_Thread_Timer_Queue_Adapter).

Собственно, связь между timer_thread_t и ACE_Thread_Timer... уже практически очевидна, осталось только представить, как будет выглядеть реализация ACE_Event_Handler и его обработчик handle_timeout и как timer_thread_t и Event_Handler будут синхронизировать доступ к общим данным. Это еще одна похожая страничка. И все, дальше остается только текст набрать -- все остальное уже продумано

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

VD>Проблема в том, что все кому мы тут что-то пытаемся объяснить просто не могут поверить в описываемые прицыпы. Они привыкли, что это невозможно. Отсюда им кажется многое не вероятным.

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

ЗЫ: мой выбор: постараться грамотно спроектировать + использовать по максимуму возможности среды разработки.

Привожу неболшую главу с книги "Refactoring: Improving the Design of Existing Code":

What Is Refactoring?
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

"Improving the design after it has been written." That's an odd turn of phrase. In our current understanding of software development we believe that we design and then we code. A good design comes first, and the coding comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.

Refactoring is the opposite of this practice. With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.

With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.

Это к тому, что такое рефакторинг, а вообще и тут я не со всем согласен. Например:

...we believe that we design and then we code... ...Refactoring is the opposite of this practice...

Очень важное значение имеет первоначальное проектирование, то самое design and then we code. А далее все, как тут описано.

ЗЫ: это все мое личное ИМХО

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

VD>>Проблема в том, что все кому мы тут что-то пытаемся объяснить просто не могут поверить в описываемые прицыпы. Они привыкли, что это невозможно. Отсюда им кажется многое не вероятным.

X> Лично я, тоже не могу в это поверить.

Вот, подтверждение моих слов!

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

Умным быть вообще полезно. А вообще все очень просто. На некотором уровне абстракции любую даже очень сложную систему можно довольно просто представить в уме или описать на баумжке. Далее остается разбить систему на логические части и можно приступать к ее реализации. При этом ты как бы делашь прототим системы и путем рефакторига/дороботок постепенно превращашь его в законченную систему.

Многие вещи не важные можно опускать и тольк потом дописывать/изменять получая тем самым нужные возможности.

X> А средства рефакторинга и прочие вкусности на мой взгляд к проектированию мало отношения имеют (или имеют ?). Не понимаю, что еще мне нужно кроме ручки и бумаги ?

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

X>ЗЫ: мой выбор: постараться грамотно спроектировать + использовать по максимуму возможности среды разработки.

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

Другими соловами мы проти идеи — сначало грамотно проектируем, а потом только реализуем задуманное. Мы за идею последовательного допроектирования. То есть сначала мы проектируем систему в общих чертах. Далее мы реализуем первое приближение. Осмысливаем результат. Вносим "поправку на ветер". Допроектируем/перепроектруем отдельные моменты. Дописываем/меняем код. Далее циклически повторяем шаги допроектирования и дописывания до тех пор пока результат не начинает нас удовлетворять.

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

Зато я частенько прибегаю к услугам дизайнера классов из VS 2005. Вот, например, диаграмка которую я создал разрабатывая набор стилей для Resd.Editor:

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

Здравствуйте, 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, от неё больше вреда чем пользы. Впрочем, если заказчик готов за неё платить, то почему бы и нет

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

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

Именно, что лично для меня.

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

+1

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

А вот это исключено. Проверено годами на собственном опыте.

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

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

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

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

E>А вот это исключено. Проверено годами на собственном опыте.

Это были неправильные задачи!