Проектирование и рефакторинг
От: IT Россия linq2db.com
Дата: 11.02.06 23:42
Оценка: 170 (14) +5
#Имя: FAQ.philosophy.refactoring
Здравствуйте, 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, от неё больше вреда чем пользы. Впрочем, если заказчик готов за неё платить, то почему бы и нет
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 12:30
Оценка: 7 (2) +7
Здравствуйте, VladD2, Вы писали:

E>>По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.


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


Скорость моей разработки определяется не скоростью набора кода в редакторе, а скоростью продумывания и проектирования. Чем лучше решение продумано, тем меньше оно тебует кода и времени на отладку.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 14.02.06 09:43
Оценка: 63 (4) +3 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ты не подумай, я не агитирую за то, чтобы отказаться от библиотек. Ни в коем случае. Меня интересуют только те сложности, которые находятся "в промежутке" между готовыми библиотеками и целевым продуктом.


Есть такое. Поверь, сложностей хватает. Ведь все эти шаблоны и пр. вещи в С++ — они же не концептуально-другого плана (типа как С++ отличается от Пролога), они лишь элемент некоторой выразительности. Выразительность экономит нам время... Которое на С++ частенько приходится терять на всевозможные остальные мелочи. На мой взгляд то на то и выходит... поэтому я более склоннен делить задачи сейчас по нишам (технологическим).

ГВ>"Хрен здесь думать, это же не шахматы!". Ну ёжкин хвост, прям как дети!


А вот тут ты не прав. Да я ТЕ ЖЕ САМЫЕ ЗАДАЧИ И НА БЕЙСИКЕ сделаю. После того, я как ОСОЗНАЛ как именно надо решать задачу, я решу ее на большинстве современных популярных императивных языков. Т.е. я выразительность весьма цинично рассматриваю лишь как фактор, экономящий время. А на последних замерах времени учитывается, разумеется, суммарный результат.

Сразу после начала знакомства с дотнет (3 года назад) меня удерживало примерно то же, что и в Java — я не знал еще о ср-вах адекватного взаимодействия с имеющимися технологиями. В Java действительно, удобного способа нет, но вот в дотнет — проще простого. Это тоже один из немаловажных моментов... Ибо на С++ действительно можно все, что угодно, и начинает казаться, что на инструментах вроде дотнета подобной "бинарной" свободы нет... Да есть она и точно такая же...

ГВ>Да, конфетка-то в виде тонн халявы есть, но цена её — ухудшение стиля проектирования и реализации, переориентация с "сделать и забыть" на "сделать и переделать".


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

Гена, средний уровень программистов постоянно и сремительно падает. Но не надо мне приводить этот уровень в пример. Большая часть этого уровня вообще способна существовать как программисты только на технологиях типа дотнета или VB. Это не значит, что у дотнета ограниченный потенциал, это лишь значит, что очень большую часть его функциональности (примерно 20-30%) могут легко освоить и даже с некоторой пользой для общества эксплуатировать даже новички.

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

ГВ>Так, например, исключение МН вроде бы, значит не много, но на самом деле оказывает сильнейшее влияние на подход к проектированию.


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

ГВ>"решарпер читает мои мысли!", это, как ты понимаешь, признак не высоты полёта решарпера, а кое-чего обратного.


Да нет. Просто в отсутствии include и макросов С# получился весьмадетерминированным языком и решарпер предлагает только то, что не будет являться ошибкой в данном месте. Иногда таких вариантов всего единицы, вероятность регулярного попадания решарпером в "нужный вариант" постоянно высока, особенно если взять крейсерскую скорость — 1 автокомплит в секунду .

ГВ>А с учётом сомнительных нововведений в C# положение будет усугубляться. Либо... либо C# превратится в подобие C++.


Нет, в подобие С++ он не превратиться. Заимствование идет на уровне концепций, но реализация будет носить специфичный, разумеется, оттенок. К тому же, мне глубоко пофиг насчет будущих тонкостей синтаксиса в новых языках. Это смешной объем информации для освоения. Гораздо важнее другие осязаемые моменты, типа: лаконичности, мощной кодогенерации и статической типизации. В Nemerle это уже отчасти можно пощупать.


ГВ>Ну и сразу возникает вопрос: а на хрена крюки выписывать? Апелляции к наличию большой библиотеки сразу отметаются по факту того, что для C++ этих библиотек хоть бульдозером греби.


Да гребли мы их неоднократно. У С++ных библиотек сложная судьба. У всех. Даже у STL. И эти библиотеки зачастую не переваривают друг друга, или требуют длительных уговоров для совместной работы. Ты же не от хорошей жизни свою библиотечку писал? А там же, в принципе, роперы над основными примитивами...

ГВ>Притом любую из них при желании можно выкинуть.


Д не так это просто. У С++ нет объединяющего центра в техническом плане. Либы взаимонезаменяемы. Если что-то где-то не пошло, то пишешь сам. И так всю жизнь. Я один лишь могу отметить плюс (по своим личным наблюдениям) — иногда подобная работа приносит удовольствие... Да, вместо того, чтобы тупо кодить функциональные требования, гораздо интересней разрабатывать фреймворки. Использование ТОЛЬКО ЛИШЬ С++ гарантирует такой вид занятости пожизненно.

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


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

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


Но и не трудодни, Гена... А готовые рабочие решения.
Я ведь не призываю бросить С++. Сам для души вожусь с математикой, обработкой сигналов и системными вещами... На С++ разумеется. И на основном месте тоже опять плотно за него сел

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

-------------
Хочу добавить еще одно свое наблюдение. Действительно, шумиху раздули очень сильную вокруг дотнета. Разумеется, на кое-кого подобная "ненавязчивая" реклама возымела резко-отрицательное действие, мешающее трезво смотреть на вещи. В общем, ты понял
Re[16]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.02.06 05:02
Оценка: 17 (2) +1 -3 :))
Здравствуйте, 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-библиотек. Я же не библиотеки собираюсь продавать, верно?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Мое проектирование и рефакторинг
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.02.06 12:17
Оценка: :))) :))) :))
Здравствуйте, Sinclair, Вы писали:

GZ>>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.

S>Двойняшки?

Не. Две женщины позвонили
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.06 08:48
Оценка: 44 (4) +1 -1 :)
Здравствуйте, VladD2, Вы писали:

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


Навскидку несколько нетехнических причин неприятия. Первая: если в "принципы" нужно поверить, то это уже не принципы а догмы. Вторая: объяснения зачастую состоят из передёргиваний и подмены понятий, а зачастую и из бессвязно-восторженных речей. Последнее свойственно, например, твоим постингам (уж извини). Третья: нередки попытки тем или иным образом унизить э... "представителей старого мира", что естественным образом провоцирует неприятие и оратора и того, о чём он орёт. Четвёртая: подозрительная корреляция рассуждений провозвестников нового с тем, что делает MS. Проследить это можно на примере шаблонов (Кто тут пел, что это нафиг не нужно и приведение от базового Object — рулез форева?). Интересно, если MS всё-таки вставит в C# x.0 множественное наследование, как изменятся куплеты в этой песне?

Вот это — действительно проблемы. Правда, в основном, для .Net-community. Из серии "нахрена нам враги, когда у нас есть такие друзья?". Хм. Кажется, когда-то я уже что-то подобное говорил.

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

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


Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения. Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать? Почему после попробования должна быть непременно одна и та же реакция? Там на мозг как-то влияют? Я вот попробовал — не торкнуло. Потенциал .Net — да, отлично понимаю. Будет ли он реализован в полной мере? Не уверен. Однако вижу, что C# медленно, но верно превращается в свалку идей, подходов и прочего, в точно соответствии с принципом "огонь и движение". То есть, налицо "раскрутка" в лучших традициях шоу-бизнеса. Прости, но я не отношусь к любителям современной попсы. Наверное, у меня полно э... "внутренних страхов" и моя э... "подсознательно понимает, что не прав". Можно, кстати, наплести и ещё чего-нибудь квазипсихоаналитического. Как я погляжу, тут мастеров по этой части пруд пруди.

VD>Так что похоже все эти попытки бесполезны. Вот Паша у нас до сих пор придумывает себе аутотренинг на тему "почему мне не нравится C#". Это все потому, что он подсознательно понимает, что не прав, но боится себе в этом признаться. Вот и ищет оправдания чтобы бороться со своими внутренними страхами. Вот Вольфхаунд попробовл новый путь и уже от него что-то не слышно огульного отрицаиня. Так что тут важен личный опыт. Без него они останутся теми самыми программистами на Абапе которые смотрят на мир с более низкоуровневой позиции и просто не в силах оценить смысл более высокоуровневых технологий.


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


Точно, фигня. А ещё — передёргивание и некорректный переход на личности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 09.02.06 15:23
Оценка: 4 (1) +6
Здравствуйте, eao197, Вы писали:

E>А почему учет неучтенных факторов должен обязательно требовать рефакторинга? Рефакторинг, если я не путаю, это изменение внутренностей кода, без изменения его функциональности. Здесь же речь идет об изменении функциональности. Далеко не факт, что это изменение потребует рефакторинга. Так же не факт, что подобные изменения не будут выявлены при предварительном проектировании.


Если при изменении, добавлении неучтённой функциональности просто добавлять её в код без рефакторинга, то через пару итераций у тебя будет не код, а помойка.

E>Более того, если ты будешь делать рефакторинг не думая, то есть очень большая вероятность, что ты будешь делать его неоднократно.


Именно неоднократно и со 100% вероятностью.

E>Вместо того, чтобы подумать и изменить только то, что действительно нужно.


А я и буду менять только то, что нужно. Впрочем, возможно у нас разное понимание 'нужно'.

В подходе "всё досканально продумать и реализовать" я уже давно разочаровался. Плохо он работает из-за того, что всё досканально продумать практически никогда не получается. Особенно в исследовательских проектах или проектах с неясными начальными требованиями. В таких проектах много приходится менять уже по ходу дела, и рефакторинг является незаменимой вещью и основным инструментом подхода, где мы не пытаемся минимизировать последующие изменения, а автоматизируем их, делаем этот процесс простым. Но, без поддержки IDE это не работает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 14:40
Оценка: +4 -2 :)
Здравствуйте, eao197, Вы писали:

E>Я проектирую в уме. Результаты пытаюсь выразить на бумаге
Автор: eao197
Дата: 20.05.05
. Если не получается, то повторяю процесс до тех пор, пока не получится. И только после этого берусь программировать. Поверишь ты мне или нет, но набор кода в gvim занимает совсем не большой процент времени.


А у меня планирование занимает минуты, от силы часы. А вот реализация почему-то дни. Причем заранее извесно, что после того, как реализация хоть как-то заработает, то после анализа (а то и в процессе разработки) будут выявлены неучтенные предпосылки которые приведут к изменению плана, а стало быть и кода.

Так мы плавно подходим к теме рефакторинга. Я опять же делаю его в мощьной IDE, а ты в снова в своем уме и Нотпэде.

Эффективность такой экстенсиной разработки стримительно стремится к нулю. Не прийми это на свой счет, но ты даже не осознашь насколько не эффективно ты трудишся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.02.06 08:39
Оценка: :))) :))) :)
Здравствуйте, EXO, Вы писали:

EXO>Ты не прав, IMHO. Мне было очень интересно и полезно почитать некоторые из здешних сообщений.

EXO>Я даже отфорвардил линк ребяам из команды, с предложением вынести эту тему на очередную "философскую пятницу" (периодическое собрание-обсуждение ситуации в отрасли... в вольном формате).

После таких слов возникает приступ графоманства и хочется написать статью 'Как я программирую на бумаге'
А IT с VladD2 и WolfHound-ом сделают симметричный ответ: 'Как мы программируем в IDE' с подзаголовком 'Бумага должна использоваться по прямому назначению в другом месте'
Не хотел никого обижать, просто пошутил.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 14.02.06 03:51
Оценка: 26 (4) +1 -1
Здравствуйте, 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>Но это невозможно так как многие его тонкости становятся известны только когда ты реально с ними сталкнешся.


Вот все, что ты здесь говоришь, весьма похоже на обсуждение каких-то экспериментальных работ. Представь, что с технологией УЖЕ знакомы. Представь, что непонятные моменты УЖЕ были отмакетированы и выработаны подходы к решению неких типовых технических задач. Это ничуть не уменьшает потребности в проектировании, а по тебе выходит, что и проектировать тогда ничего не остается.
Re[8]: Проектирование и рефакторинг
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 14:18
Оценка: :))) :)))
Здравствуйте, eao197, Вы писали:

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


Вот-вот. Я классы в дизайнере проектрую, а ты в Нотпэде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 14.02.06 18:11
Оценка: 31 (3) +2
Что-то вас господа занесло. Один апологет XP, другой водпадов.

Напишу о том как я проетирую в случае, если это не групповая разработка в которой нужно писать кучу, иногда не нужной, документации. Здесь упоминается только то, как я работаю один.

Этап 1. Думаю.
Я думаю над тем что я хочу сделать. Во первых, нужно ли это делать. Процентов 90 именно на этом этапе и заканчивается. И во вторых, что это должно быть. Это не архитектура. Это действия пользователей(будем говорить сценарии). При этом я придумываю эти действия пользователей. Чаще все рождается и остается в голове, если не умещается и вещь непростая в тетрадке. (кои всегда с собой). Но я не в коем случае не думаю как я это сделаю. Не дай бог, хотя бы одним нейроном подумать об архитектуре. Тогда картина вырисовывается, и получается решение которое легко сделать. А оно ошибочное, лучше думать о действиях пользователя или системы, или утилиты. Как только подумал об архитектуре не доработав действия, то можно считать проект пропал. Это самое сложное для меня. И за этим занятием я провожу большую часть проекта.

Этап 2. Сажусь за компьютер. С первыми строчками кода, типа void main(){} в голове уже лежит архитектура. Я ее как-то уже давно не придумываю. Она сама рождается. Я примерно представляю как это строить. И начинаю писать. Сначало пишу процедуру. Потом пишу для нее тест. Поскольку процедура обычно получается большой и здоровой, а по пацански сходу я красиво писать не умею, разбиваю ее на различные процедуры и объекты(то бишь рефакторинг). Потом следующую процедуру. Потом для нее тесты. Потом чувствую что эти две процедуры можно будет совместить в одну, но в два вызова с разными параметрами. Сново рефакторинг. Третья процедура уже будет построена на предыдущих. И т.д. Рефакторинг у меня идет все время. Пока пишу код.

Этап 3. Документирование. Нет ничего хуже чем понимать как все это работает через код. Ну фигово разбираться в классах и бегать по всяческим Class View да мотать колесика у мышки в поиске что тут имелось ввиду. Сам такое делал неоднократно, поэтому злорадно пытаюсь не делать документации. Пускай знают почем килограмм байтов. Но если тебя взяли за грудки и сказали что лишат премии, то пишешь некоторую концепцию. Этого и еще желательно тестов, вполне достаточно чтобы разобраться что там и как работает. Остальное все фигня, и лично мне мало помогало.

Насчет итераций. Нету у меня их. Потому как каждая процедура есть итерация.
Re[9]: Проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 14:26
Оценка: 13 (2) +3
Здравствуйте, VladD2, Вы писали:

VD>Вот-вот. Я классы в дизайнере проектрую, а ты в Нотпэде.


Смешно. И грусно.

Я проектирую в уме. Результаты пытаюсь выразить на бумаге
Автор: eao197
Дата: 20.05.05
. Если не получается, то повторяю процесс до тех пор, пока не получится. И только после этого берусь программировать. Поверишь ты мне или нет, но набор кода в gvim занимает совсем не большой процент времени.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Проектирование и рефакторинг
От: IT Россия linq2db.com
Дата: 09.02.06 14:21
Оценка: +4 -1
Здравствуйте, eao197, Вы писали:

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


Это справедливо только для утилит командной строки. Продумать большую систему в голове без прототипирования, без проб и ошибок и последующего рефакторинга практически невозможно. А здесь скорость набора кода в редакторе играет не самую последнюю роль.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Философический вопрос про автоматический вывод типов
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 05:15
Оценка: 23 (3) +1
Чуток дополню.

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

V>

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

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


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


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

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

Если же начинать с "продумывания функциональности"... да, порой к "финишу" можно попасть быстрее. И, к сожалению, нынче стало модно этим увлекаться. Резултат грустный — стремительно сокращается "время самостоятельной жизни" продуктов. Если продукт был построен на принципиальной "доработке напильником" под итоговые требования, то почти наверняка придется снова браться за напильник при каждом их изменений. Просто потому, что "большая внешняя система" не рассматривалась и сообветсвенно любые процессы в ней выльются в "неожиданные изменения требований" к разрабатываемой подсистеме. В результате стоит разработчикам "забыть" свой продукт на пару месяцев, как он начинает стремительно устаревать.
Последнее время стало опять же модно, списывать все на "ускорение темпа жизни". На мой взгляд, по крайней мере на половину, это отговорки разработчиков, которые либо ленятся (либо разучились) системно и концептуально мыслить. Ускорение "темпа времени" реально есть, но вовсе не такое уж большое. В качестве примера могу сказать, что у меня есть один старый продукт (SCADA-система), насчитывающий примерно 120тыс. строк кода на C, С++ который продается уже 11 лет, после того, как я поставил в нем последнюю точку. Да, сейчас он уже морально устаел и года 4 назад его стоило бы заменить. Но даже с учетом этого получается 7 лет нормальной жизни продукта без "дозатачивания". Таким образом, даже если "традиционное проектирование" обходится дороже (что не всегда), это вполне окупается временем жизни подуктов.
Re[17]: Философический вопрос про автоматический вывод типов
От: Дарней Россия  
Дата: 23.02.06 08:33
Оценка: 18 (1) +2 -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ещё раз: проектирование как раз и предполагает, что большая часть трудностей будет выловлена на его этапе.


Цель грамотного проектирования — создать архитектуру, которая позволит легко (относительно) исправить любые вероятные проблемы, которые могут появиться в дальнейшем. Под проблемами я здесь понимаю непонимание требований к системе (со стороны программистов иил самого заказчика), изменение требований к системе (по объективным причинам, или просто по капризу заказчика), несовершенство используемых средств, лицензионные проблемы и т.п.
Проектирование, которое решает все проблемы до их появления — это из области фантастики. Любые реальные проблемы, которые возникают во время развития проекта, предсказать просто невозможно. Потому что техника гадания на кофейной гуще еще очень далека от промышленного применения
Максимум, что можно сделать — это составить список вероятных проблем, и подготовить почву для их решения, когда какие-то из них станут реальностью. Это и есть сверхзадача грамотного проектирования. Мастерство же архитектора состоит в основном в умении грамотно расставить приоритеты грядущих проблем, и в умении спроектировать систему в соответствии с этими приоритетами.
То же самое касается и вопроса скорости будущего продукта. Грамотный архитектор должен всегда закладывать возможность увеличить скорость работы — с помощью кэширования, распределения нагрузки, переписывания некоторых модулей на язык более низкого уровня (именно так, этот пункт — на последнем месте). НО! Если архитектор на этапе проектирования говорит "мы будем использовать здесь X, чтобы увеличить скорость" — за шиворот его, и отправлять гальюны чистить. Зубной щеткой. Потому что правильное высказывание должно звучать так: "Мы сделаем Y, чтобы иметь возможность увеличить скорость потом, если это понадобится"

ЗЫ желающие расставить минусы — в очередь!
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[17]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 17:11
Оценка: +4
Здравствуйте, VladD2, Вы писали:

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


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

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

?

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 13.02.06 15:37
Оценка: +4
Здравствуйте, eao197, Вы писали:

E>И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная.


Код — это как раз самая точная и достоверная информация. Когда уже не помогают хелпы, то остаётся только код. Да простит меня Бил Гейтс, но чтобы разобраться как работает баиндинг в WinForms, мне пришлось декомпильнуть фреймворк. Это уже после изучения всех MSDN'ов и прочих гуглей. Есть такая WinForms библиотека Syncfusion с, мягко выражаясь, несколько противоречивым интерефейсом. Документация к ней есть, но понять главную идея и охватить широту мысли разработчиков можно только изучая исходный код. Если при этом этот исходный код можно подключить к текущему проекту, то во многих случаях проход по коду отладчиком даёт полное представление о происходящем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 17.02.06 08:04
Оценка: 50 (3)
Здравствуйте, IT, Вы писали:

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


GZ>>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.


IT>Мои поздравления! Мальчик, девочка?

Девочка 3700x51
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 13.02.06 13:17
Оценка: 22 (2) -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения. Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать?


Потому что нет новых принципов. Есть менее выразительный язык. Разумеется, требуется уговаривать переходить с более выразительного языка на менее выразительный. Что именно предлагается попробовать? ХАЛЯВУ!!! Горы, целые кладези бесплатной функциональности. Это действительно зачастую торкает и сильно. Факт: распределение усилий программиста м/у низкоуровневыми и высокоуровневыми задачами стало другим.

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

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


ГВ>Почему после попробования должна быть непременно одна и та же реакция?


Это зависит от степени потребности в халяве.

ГВ>Там на мозг как-то влияют? Я вот попробовал — не торкнуло.


Значит, твои задачи не были реализованы на 90% в нем.

Я как-то рассуждал о надежности в ответ тебе: http://www.rsdn.ru/Forum/Message.aspx?mid=1609434&amp;only=1
Автор: vdimas
Дата: 24.01.06


ГВ>Потенциал .Net — да, отлично понимаю. Будет ли он реализован в полной мере? Не уверен. Однако вижу, что C# медленно, но верно превращается в свалку идей, подходов и прочего,


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

Просто перенеси сейчас эти принципы на 1-го разработчика и ты получишь примерный сценарий работы большинства дотнетчиков. Люди пишут сразу же алгоритмы самого высокого уровня именно такими, какими хотели бы их видеть. Плагин Решарпер тут же создает заглушки на несуществующие методы. Ты как бы общаешься с самим собой, выдавая себе задание на разработку более низкоуровневых компонент. (Эти задания потом выискиваются глобальным поиском по "NotImplementedException"). Такой сценарий сам по себе является тянет на один из способов проектирования.

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


ГВ>Прости, но я не отношусь к любителям современной попсы. Наверное, у меня полно э... "внутренних страхов" и моя э... "подсознательно понимает, что не прав".


С одной стороны могу опять напомнить про надежность (обсуждал по ссылке выше). С другой стороны... читай мысли вслух ниже

VD>>Так что похоже все эти попытки бесполезны. Вот Паша у нас до сих пор придумывает себе аутотренинг на тему "почему мне не нравится C#".


ГВ>Точно, фигня.


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

Возможно, С++/CLI способен временно послужить в качестве компроммисса, пока для дотнета не создадут достаточно выразительного языка (языков). Мне вот Nemerle показался интересным направлением. Действительно, что-то от философии макросов Lisp-а в нем есть, т.е. имеется полный контроль над кодогенерацией. Но в отличие от Лиспа — все это в сочетании с типизированным языком. Правда, к сожалению, сам код этих макросов еще не столь декларативен, как хотелось бы (так же как и в Лиспе, кстати), но это вопрос времени, вернее — наработок готовых библиотек этих макросов, в т.ч. и обслуживающих задачи программирования макросов. Нечто типа шаблонов С++ вполне можно будет написать.


----------------
Для себя я свою позицию уже давно определил: тонны отлаженной (то бишь — высоконадежной) функциональности — это всегда гут. Бедноватый язык (поначалу действительно трудно было с этим кастратом, порой до психа... потом привык) воспринимается как плата за халяву. С другой стороны, тешу себя мыслью, что развитие самих языков идет весьма шустро. Действительно, C#2.0, например, на порядок удобнее, чем предыдущая версия. Да и всякие Nemerle и прочие функциональные языки на подходе... И все это в сочетании с действительно гладкой стыковкой в рамках фреймворка... Ведь и у тебя и у меня достаточно опыта по стыковке разных по парадигмам языков и технологий в одном проекте... В общем, это всегда были уникальные решения "по месту"... Сейчас, очевидно, все не так.

Есть много вещей, которых не хватает в современных языках для .Net. Например, они недодумали о совместимости делегатов и пользовательских функциональных объектов в современных компиляторах. Самое прикольное, что эту совместимость можно запросто реализовать, но пока только через ручную байткодогенерацию.
Re[17]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 14.02.06 05:12
Оценка: 22 (1) +2
Здравствуйте, EXO, Вы писали:

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


На одном из моих недавних проектов у меня на кодирование и отладку уходило 15 минут в день. Остальное время я проводил в беседах с друзьями, за чтением RSDN и прочих дозоров. А народ в это время бегал запаренный два месяца перед релизом, размахивая бумажками и диаграммами. У меня же баг-теккинг был чист как слеза. Причём здесь скорость написания кода? А при том, что я свои косяки не загонял подальше в угол и не прикрывал их бумажками и диаграммами, а лечил сразу на месте и не доводил код до неконтролируемой помоечной консистенции.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.06 06:23
Оценка: 10 (3)
Здравствуйте, IT

Данное сообщение не является попыткой покритиковать или опровергнуть что-нибудь в рассказе IT. Как я понимаю, Игорь просто поделился своим опытом. У меня же есть мой опыт, исходя из которого я смотрю на некоторые вещи чуть иначе. Так же я думаю, что мы с IT занимаемся разными задачами, что дает возможность нам использовать разные подходы к разработке.
Этот пост в некоторой степени является ответом и на сообщение VladGalkin
Автор: VladGalkin
Дата: 12.02.06
, о хороших результатах инкрементальной разработки и дискредитировавшей себя модели Waterfall.

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

Степень точности зависит от уровня абстракции. На каком-то уровне нужно точно понять, что необходимо разработать инструмент SObjectizer (или ACE, или Spring, или BLToolkit, конкретное имя ничего не значит). Здесь мы можем более-менее расплывчато представлять себе конкретные возможности нового инструмента, но зато точно должны знать, чем этот инструмент отличается от конкурентов и зачем он нужем нам (либо потенциальным покупателям).

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

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

По моему мнению, здесь нет никакой модели Waterfall. На каждом уровне абстракции я нахожусь ровно столько, сколько нужно чтобы понять, что я точно представляю себе работу этого уровня. И что это знание позволяет мне двигаться дальше. Не на всех уровнях возможно написание кода, но если где-то возможно и это имеет смысл, то я пишу код. Но я предпочитаю пользоваться при проектировании именно бумагой, потому что:
* лично меня отвлекает большое количество мелких деталей общения к компьютером (хотя бы необходимость периодически сохранять изменения в документе);
* на компьютере для меня «хуже обзор», т.к. даже на мониторе с большим разрешением я вижу гораздо меньше деталей, чем на двух сложенных рядом листах формата A4;
* в большинстве случаев процесс поиска точного представления напоминает блуждание в тумане, когда перебираются десятки вариантов. Многие варианты отвергаются и затем принимаются к расмотрению по несколько раз, многократно перекраиваются и возвращаются затем к первоначальному варианту. Лично мне не хочется проделывать лишнюю работу и проделывать все это мышкой в Visio, поскольку на бумаге все это для меня гораздо проще.
Кстати, приведенный мной черновой вариант
Автор: eao197
Дата: 10.02.06
решения с timer_thread_t оказался не правильным. И я выбросил его не написав ни одной лишней строчки кода. У меня не возникло соблазна взять какую-то часть написанного кода для нового решения (не знаю как у кого, но у меня такой соблазн всегда был слишком велик).

И еще один важный момент по поводу проектирования. Неявно подразумевается, что проект все равно будет неоднократно пересматриваться, требования к нему будут изменяться и все равно его придется перекраивать и переделывать. В некоторых предметных областях только так и можно, но не везде. При разработке программного инструментария ситуация несколько иная. Если я разрабатываю объектную СУБД, то глупо, имхо, расчитывать на то, что требования к ней будут меняться раз в месяц. Нет, я сразу должен буду получить приемлимый результат. Более того, должен быть выбран такой API для СУБД, который бы позволил выпустить несколько версий СУБД не нарушая совместимости клиентских приложений. А в разработке СУБД есть области, в которых лично я не представляю себе написания кода без точного понимания того, как он будет работать. Например, механизм записи транзакционных изменений посредством write-ahead log. До написания кода я уже должен четко знать, какая метаинформация информация должна быть в log-е, как по этой информации определять актуальность log-а, как по log-у восстанавливать БД после сбоя, можно ли использовать log для организации on-line репликации и пр. Конечно, точный состав и форма представления метаинформации будет меняться по ходу реализации. Сама реализация может быть итерационной, где некоторые части метаинформации будут игнорироваться на разных итерациях. Еще более вероятно, что перед разработкой будет создано и выброшено несколько прототипов. Но суть в том, что лично я не представляю, как придти к механизму write-ahead log-а начав с программирования подсистемы write-ahead log-а.

И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная. Например, если речь идет о вспомогательных библиотеках. Я думаю, что для программиста, использующего ACE, не так уж много пользы даст код метода ACE_Event_Handler::handle_input или ACE_Reactor::run_reactor_event_loop. А в некоторых случаях кода используемой библиотеки нет вовсе. На первое место в таких условях выходит документация, написанная в комментариях к методам и классам. Но чтобы ее написать, довольно часто нужно представлять себе всю картину в целом. Картину, которая открывается мне после предварительного проектирования на бумаге. Поэтому, когда я приступаю к программированию, я приступаю и к документированию. При этом написание doxygen комментариев к коду является, наверное, более трудоемкой и длительной операций, чем кодирование. Зато на выходе получается еще и довольно объемный и актуальный Reference Manual. Конечно, не иногда он не нужен. Но, поскольку я всегда старался заниматься разработкой инструментария, то практически постоянно мне приходилось делать еще и документацию. И предварительное проектирование на бумаге существенно облегчало этот процесс.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 13.02.06 16:33
Оценка: 1 (1) +2
Здравствуйте, WolfHound, Вы писали:

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


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


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

А нетипизированные коллекции в .Net 1.1 и еще тонна нетипизированных интерфейсов и сервисов? До сих пор вздрагиваю... Нельзя было эти генерики сразу реализовать, что-ли? И кстати, дохрена сервисов так и остались нетипизированны. Вот тебе и причины необходимости плотного обкладывания юнит-тестами в сочетании с пошаговыми заплывами.
Re[15]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.06 20:42
Оценка: 1 (1) +2
Здравствуйте, vdimas, Вы писали:

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


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


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


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

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

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

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

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

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

Точно так же я могу спроектировать систему намного (я бы даже сказал радикально) быстрее если не буду "дышать" над каждым пунктом и если опущу тонкости до того момента когда они действительно потребуют проработки. А быстрая и безболезненная модификация кода позволяют устранить появлющиеся в следствии этого перекосы. В итоге ошибаюсь я конечно чаще, но добираюсь до финиша первым, так как иду на полных парах и коректируюсь только когда это не обходимо. "Стандартный" же способ проектирования предлагает сразу спланировать маршрут без ошибко. Но это невозможно так как многие его тонкости становятся известны только когда ты реально с ними сталкнешся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 19:45
Оценка: 1 (1) +1 :)
Здравствуйте, Геннадий Васильев, Вы много писали писали...

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

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

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

В общем, видимо надо сносить такие "филосовские" темы во флэйм. Конструктива в них — 0.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 16.02.06 15:56
Оценка: 1 (1) +2
Здравствуйте, VladD2, Вы писали:

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


Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".

Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.

Гена утрирует, но что-то в этом есть. Действительно, на многих "популярных" задачах достаточно ныне нажать кнопку "пуск" и все работает само в этом дотнете. Единственно что потребуется изучать — это расположение самой этой кнопки.

Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
Проектирование и рефакторинг
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 12:23
Оценка: +1 -1 :)
Здравствуйте, eao197, Вы писали:

E>По мне, так если язык действительно хороший (теплый взгляд в сторону C++ и Ruby), так на нем даже в Notepade (не говоря уже про vim и emacs) программировать можно.


А по-мне так если ты программирушь в нотпэде и тебя удовлетворяет скорость, то скорее всего скорость твоей разработки неприемлемо низка.
... << RSDN@Home 1.2.0 alpha rev. 637>>

12.02.06 08:08: Ветка выделена из темы Философический вопрос про автоматический вывод типов.
Автор: c-smile
Дата: 05.02.06
— Odi$$ey
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 09.02.06 16:19
Оценка: +3
Здравствуйте, eao197, Вы писали:

E>Тем не менее, есть и другие системы (черные ящики, которые с пользователем не работают, а выполняю свою задачу). Из того, что лично я делал, вот пример
Автор: eao197
Дата: 24.01.05
. И я не представляю, как подобные вещи можно делать без предварительного тчательного продумывания.


Без разницы. Для тебя инструментом продумывания является бумажка, для меня код. Вот и всё. Только я результат уже вижу, а ты о нём только догадываешься.

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


Тогда тем более о чём мы спорим.

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


Это тоже всё без разницы. Я занимался и гуями, и серверами, и базами данными, разными вебами, включая rsdn'ами, компиляторами, визуальными редакторами ресурсов, библиотеками и прочими BLToolkit'ами. Большой разницы в подходах к проектированию не заметил.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Философический вопрос про автоматический вывод типов
От: Павел Кузнецов  
Дата: 14.02.06 05:59
Оценка: +2 -1
Здравствуйте, WolfHound, Вы писали:

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


Выделенная стадия проектирования нужна не столько для того, чтобы избежать лишних модификаций кода, сколько для того, чтобы уменьшить общее количество циклов модификация-тестирование-анализ сбоев-модификация-{...}, в которых стоимость внесения модификаций традиционно играет далеко не первую роль.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[7]: Мое проектирование и рефакторинг
От: IT Россия linq2db.com
Дата: 17.02.06 03:30
Оценка: +3
Здравствуйте, GlebZ, Вы писали:

GZ>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.


Мои поздравления! Мальчик, девочка?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Мое проектирование и рефакторинг
От: EXO Россия http://www.az.inural.ru
Дата: 15.02.06 07:41
Оценка: 48 (2)
Здравствуйте, GlebZ, Вы писали:
GZ>Здесь упоминается только то, как я работаю один.

:Жму лапу. Уровень саморефлексии на высоте.

GZ>Этап 1. Думаю.

GZ>Я думаю над тем что я хочу сделать.

Я на этом этапе предпочитаю гулять где-нибуддь по парку... чтобы ногами перебирать. Чтобы окружающий мир разными сторонами поворачивался...

GZ> Во первых, нужно ли это делать. Процентов 90 именно на этом этапе и заканчивается.



!!!!!
Только у меня это два этапа. (или даже 3)
1а) Какие (и чьи) задачи задачи собираемся решать. То есть чеко определить субъект интереса (или надсистеу) и задачи этого субъекта в его собственной системе ценностей.
1б) Можно ли решить эти задачи ничего не разрабатывая (тот самый предельный случай — ни одной строчки кода).
1в) Хочу ли лично я этим заниматься и почему.

GZ> И во вторых, что это должно быть. Это не архитектура. Это действия пользователей(будем говорить сценарии).


1е) ... частично становится ясным на этапе 1б. Но дествительно требует возвращения и более детальной проаботки — отдельного этапа.

GZ> При этом я придумываю эти действия пользователей. Чаще все рождается и остается в голове, если не умещается и вещь непростая в тетрадке. (кои всегда с собой). Но я не в коем случае не думаю как я это сделаю. Не дай бог, хотя бы одним нейроном подумать об архитектуре. Тогда картина вырисовывается, и получается решение которое легко сделать. А оно ошибочное, лучше думать о действиях пользователя или системы, или утилиты. Как только подумал об архитектуре не доработав действия, то можно считать проект пропал. Это самое сложное для меня. И за этим занятием я провожу большую часть проекта.


Посмотри вот это (может не самые удачные ссылки, но что уж нагуглилось):
http://www.journal.gennadij.pavlenko.name/node/2344
http://www.brainstorming.ru/article/diltsstr.htm


GZ>Этап 2. Сажусь за компьютер. С первыми строчками кода, типа void main(){} в голове уже лежит архитектура. Я ее как-то уже давно не придумываю. Она сама рождается.


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

А дальше — для каждой отдельной подсистемы уже берусь за объетное проектирование. Например — через дерево классов. И это да — если возможно, в среде разработки. С удовольствием задействую все красивости и удобства.
Но этот этап (и остальные до резултата) у меня занимает уже около четверти времени.
Re[15]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.06 15:55
Оценка: 15 (2)
Здравствуйте, 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 будут синхронизировать доступ к общим данным. Это еще одна похожая страничка. И все, дальше остается только текст набрать -- все остальное уже продумано


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 16:50
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

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


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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.02.06 16:06
Оценка: 1 (1) +1
Здравствуйте, xbit, Вы писали:

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


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


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

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


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

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

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


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

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


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

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

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

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

Такие диаграмы визиализируют сущьности и позволяют упростить размышления о дизайне частей приложения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 17.02.06 02:51
Оценка: 1 (1) :)
Здравствуйте, VladD2, Вы писали:

VD>Если твоя задача выделиться, то у нас разные задачи. Моя задача быть более продуктивным и сделать более продуктивными остальных.


А чем еще, по-твоему, можно выделиться? Именно быть более продуктивным в какой-то области.

VD>Отсюда если для повышения продуктивности нужно перестроиться, то значит нужно перестраиваться.


Пока еще есть рынок С++ приложений и С++ рабочих мест, речь все еще может вестись о повышении продуктивности на нем.


VD>Как человек общавшийся с ЧПУ скажу тебе, что влючить кнопку недостаточно. Еще нужно ввести программу и обслуживать станок (менять фрезы, вносить поправки и т.п.). Думаю в твоем гипотетическом эксповаторе тоже будет что-то подобное. Так что место где можно отличиться будет.


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


VD>Мечат о зеленой факсовой кнопке решающей все задачи так и останется мечтой. Я в этом уверн. Так что не убдем обсуждать эту утопию.


Да ну почему же? Ты просто привык к тоннам халявного функционала и наверно, не представляешь, как мог обходиться раньше без него. И это действительно — ожившая утопия. Неплохие либы, розничной стоимостью как минимум в многие тысячи баксов, достаются совершенно бесплатно. Ты бы хоть поинтересовался стоимостью либ под те же С++ или Дельфи или что угодно. Там вшивая библиотека контролов от $500. Сначала Sun удивил мир своей бесплатностью, затем ему вторит MS, вернее, даже переплюнул. И ты пытаешься сказать, что утопий не бывает, хе-хе...

V>>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.


VD>Именно. Причем искать то в общем-то нечего. Все под ногами.


Например? Покажи мне ИНТЕРЕСНЫЕ задачи под дотнет, за которые платят нормальные деньги. Твое "под ногами" — чистой воды утопия и есть. Сейчас деньги платят за... кодирование бизнес-приложений. Можно называть это все громко, типа "бла-бла-разработка N-уровневой распределенной системы", суть не меняется: формочки, отчеты, SQL и некая прослойка м/у ними (громко называющаяся сервером этого бизнес-приложения) которая уже давно не является интересной задачей.
Re[16]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 17:07
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

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


Твои уроки устарели. Пора учить новые.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.06 09:00
Оценка: :))
Здравствуйте, eao197, Вы писали:

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

E>

E>Все мы жертвы цепи нелепых случайностей.

E>((С) К.Вонегут).

И заказчики у тебя неправильные! Они несут неправильный мёд. Так что, ты его не пей, козлёночком станешь. Давай, бросай всё и вливайся в ряды миллионов. Ты понял, нет? Миллионы тебя ждут. Мил-ли-о-ны!А ты, понимаешь, расчирикался! Ты ещё не понял, как надо компиляторы писать? Эх, и поимела же тебя матрица! По самое фрейдистское начало.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.06 09:05
Оценка: :))
Здравствуйте, VladD2, Вы писали:

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


VD>Тебе не платят за С++ и темболее за то что что-то под Линукс.


Влад, это было сильно! Я в восторге. Можно на бис?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.06 10:11
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

E>Гена, что-то ты злой сегодня.


Да нет, Женя, это я ещё не злой. Это, в общем, шуточный пост был.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Философический вопрос про автоматический вывод типов
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.06 13:27
Оценка: +2
Здравствуйте, IT, Вы писали:

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


E>>О каких системах ты говоришь?


IT>Кто-то мне тут недавно приводил в качестве примеров Вижуал Студии, MS Офисы и прочие IE, Мазилы и Оперы Но я бы оценил это проще — если система предполагает затрат хотя бы в несколько человеко-месяцев, то продумать и удеражать её такую продуманную в голове крайне сложно. Да и не нужно. Очень часто всё это умножается ещё на неясные по началу функциональные требования.

Кстати, тут по-моему начинают вмешиваться какие-то квантовые силы. В том смысле, что некоторые требования принципиально появляются только для уже готовой реализации. И основная проблема — в том, чтобы изготовить прототип настолько быстро, чтобы в случае проявления новых требований все еще можно было его исправить до релиза. А если попытаться все нафиг заспецифицировать перед разработкой, то на проектирование уйдет в 3-5 раз больше времени, чем на кодинг, и на исправление этого напроектированного времени уже точно не останется.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Философический вопрос про автоматический вывод типов
От: Павел Кузнецов  
Дата: 13.02.06 14:11
Оценка: +1 -1
Sinclair,

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


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


Интересно, что вы спорите с совершенно другой позицией, чем озвучиваемая вашим оппонентом... Т.е. при критике его позиции у вас идет речь о полном vs. итерационное проектирование/разработка, в то время, как ИТ и Влад озвучивали позицию отсутствия выделенного этапа проектирования до кодирования, а eao197 настаивал на его полезности (по крайней мере, для себя). Наличие выделенного этапа проектирования вполне возможно на каждой итерации. Более того, это вполне согласуется с рекомендациями всевозможных RUP, XP etc.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[13]: Философический вопрос про автоматический вывод типов
От: WolfHound  
Дата: 13.02.06 16:07
Оценка: +1 :)
Здравствуйте, Павел Кузнецов, Вы писали:

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

Тут проблема в том что мы используем разные средства разработки. Вы с Евгением пишете на С++, а я, ИТ, Влад, Синклер пишем на C# с ReSharper'ом. Так вот когда пишешь на С++ то писать и изменять когд намного сложнее чем делать тоже самое на C# с ReSharper'ом. Вот по этому вам нужна выделеная стадия проектирования, а нам нет. Мы можем проектировать прямо в коде ибо можем очень легко изменять этот код.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Философический вопрос про автоматический вывод типов
От: Шахтер Интернет  
Дата: 14.02.06 08:08
Оценка: -2
Здравствуйте, vdimas, Вы писали:

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


Я не знаю как "они", я как в С++ пошаговую отладку использую эпизодически, так и в тех нескольких задачках на С# которые я написал я её не использовал. По моему, это от языка не зависит. Больше от подходов к работе и от опыта.
Хотя С# действительно провоцирует на грязную работу. Ну так не поддавайся на провокации.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[19]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 15:43
Оценка: -2
Здравствуйте, vdimas, Вы писали:

V>2. А прибедняться зачем? Я лишь придерживаюсь общего тона нашей беседы:


Ничего ты не придерживашся. Ты понтушь и хамишь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Мое проектирование и рефакторинг
От: IT Россия linq2db.com
Дата: 15.02.06 02:34
Оценка: +2
Здравствуйте, GlebZ, Вы писали:

GZ>Этап 2. Сажусь за компьютер.


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

Что это даёт? Во-первых, к повторно используемому коду должны предъявляться повышенные требования. А значит требуется больше времени над ним подумать. То, что этот код где-то ещё несколько раз пригодится именно в таком виде — не факт. По-этому, кроме потери времени можно ещё и понаделать кучу одноразовых-повторно-используемых методов и классов. В результате мы имеем как выигрышь по времени, так и достаточно продуманную и полезную повторно-используемую часть подсистемы.

При чём тут рефакторинг и почему я так раньше не делал? Потому что это было долго и чревато багами, т.е. было неэффективно. Лугче было сразу продумывать и писать повторно-испольуемые вещи.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Философический вопрос про автоматический вывод типов
От: EXO Россия http://www.az.inural.ru
Дата: 15.02.06 05:47
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


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

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


А можешь предположить, что все остальное ты просто не видишь?
Re[3]: Мое проектирование и рефакторинг
От: Павел Кузнецов  
Дата: 15.02.06 05:51
Оценка: +2
Здравствуйте, eao197, Вы писали:

GZ>>Что-то вас господа занесло. Один апологет XP, другой водпадов.


E>Не, я не водопада апологет. А так... серии маленьких водопадиков.


Что характерно, эта метафора намного ближе к описанию итеративного процесса, чем аморфный режим "постоянного рефакторинга". Последняя метафора страдает концентрацией на коде, а не на результате. В случае же полного (хотя и короткого) цикла (проектирование — реализация — документирование — тестирование — выпуск) жизнь проекта "полнее", и всевозможные "глюки" вылавливаются в большей мере, чем в случае хронического "зависания" на стадии реализации в виде "постоянного рефакторинга". То же проектирование нужно в т.ч. и для организации тестирования и "прикормки" documentation writers.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[18]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.02.06 08:16
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.


Давай уточним постановку задачи. Если вымыться хочешь лично ты, то это одна задача. А если к тебе приходит заказчик и говорит, что он хочет вымыть 150 человек за день и заплатить за это N (естественно, N < K) рублей, то выбор ванны в качестве способа мытья может отпасть сам собой после некоторого проектирования.



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


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


Я в очередной раз пытаюсь привлечь внимание к учету предметных областей, в которых идет работа. В каких-то из них стадию дотошного проектирования провести действительно нельзя. Вот сейчас я и мой коллегой пытаемся придумать удобный для операторов способ мониторинга событий в server-side приложении. Мы толком сами не знаем, что нужно сделать, так же, как этого не знают операторы. Они говорят -- хотим, что бы было удобнее, чем есть сейчас. Естественно, на вопрос "как именно?", они ничего сказать не могут. Поэтому вся работа выглядит как последовательность разрабатываемых, демострируемых и перерабатываемых прототипов. Именно прототипов, чтобы поймать и выкрилистовать идею, которой пока нет. Понятно, что в данной задаче ни о каком проектировании (с большой буквы) не идет речи. Максимум -- это попытка представить на бумаге, как будет выглядеть окно мониторинговой панели.

С другой стороны, я сейчас делаю в mxx_ru поддержку VS2005 и манифестов для exe и dll целей. Здесь понятно, что должно быть сделано. Не понятно как именно. Самый важный вопрос -- как пользователь будет описывать, какую помощь от mxx_ru он хочет получить при работе с манифестами. И здесь без проектирования, мне кажется, нет смысла начинать кодировать. Только когда станет точно ясно, что конкретно будет видеть пользователь и какие возможности будет предоставлять mxx_ru -- тогда уже не составит труда это запрограммировать просто в лоб.

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



ИМХО, индивидуальный подход нужен к каждой задаче. Но не слова вроде "сказачно" или "профанация".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 21:03
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?


Строго говоря — требование к базовым интерфейсам меняться как можно реже проистекает из единственного факта — необходимости делать согласование с изменениями в использующем коде. В случае наличия рефакторинга, если конечно базовые интерфейсы не смотрят наружу проекта, проблемы согласования снимаются, следовательно снимается и вышеозначенное требование.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[15]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 21:19
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Навскидку несколько нетехнических причин неприятия. Первая: если в "принципы" нужно поверить, то это уже не принципы а догмы. Вторая: объяснения зачастую состоят из передёргиваний и подмены понятий, а зачастую и из бессвязно-восторженных речей. Последнее свойственно, например, твоим постингам (уж извини). Третья: нередки попытки тем или иным образом унизить э... "представителей старого мира", что естественным образом провоцирует неприятие и оратора и того, о чём он орёт.


До сюда был согласен.

ГВ> Четвёртая: подозрительная корреляция рассуждений провозвестников нового с тем, что делает MS. Проследить это можно на примере шаблонов (Кто тут пел, что это нафиг не нужно и приведение от базового Object — рулез форева?).


Влад? Не припоминаю.

ГВ>Интересно, если MS всё-таки вставит в C# x.0 множественное наследование, как изменятся куплеты в этой песне?


Не вставит.

ГВ>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения.


Черта с два. Я сам начинал всерьез программировать как раз когда на просторах необъятной стали популярны объектные TP 5.5 и TC 2. И тогда неприятие ООП было таким мощным, что сегодняшние войны против .NET ни в какое сравнение не идут. Запомнил я это хорошо потому что тогда сам испытал самую мощную ломку сознания за свою жизнь в попытке освоить ООП (а говорят — наоборот, мозги костенеют с возрастом).

ГВ> Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать?


Потому что иначе рискуешь попасть в плен к собственным предрассудкам. Не про тебя, но здесь, проглядывая оценки, можно выделить отчетливую группу товарищей, устойчиво ставящих плюсы при восхвалениях С++, и минусы при восхвалениях дотнета, вне зависимости от того, насколько прав тот, кому оценки ставят. Как впрочем, наверное есть группа и с антогонистичным поведением. Вот это оно — они уже не способны оценивать языки объективно.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[20]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 16.02.06 21:55
Оценка: +1 :)
Здравствуйте, Anton Batenev, Вы писали:

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


Научи
Re[12]: Философический вопрос про автоматический вывод типов
От: VladGalkin Украина  
Дата: 12.02.06 11:09
Оценка: 28 (1)
Здравствуйте, eao197, Вы писали:

E>Все время не нужно. Только на момент проектирования. А это не так уж и сложно. Особенно, если нарезать систему на слои и не смешивать их без лишней надобности.

BDUF очень часто приводит "плохо пахнущему" дизайну. Современные процессы разработки ПО, а особенно гибкие итеративны и инкременты: проектирование выполняется на каждой итерации, все время. Модель Waterfall дискредетировала себя.

E>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?

Вспоминается врезка от Рона Джеффриза 263 странице в книге Фаулера, о рефакторинге "Введение Null Object" в проекте C3 там этих рефакторингов немало, выполнялись они часто, да и сам C3 немаленький проект.
... << RSDN@Home 1.1.4 stable rev. 510>>
ДЭ!
Re[21]: Философический вопрос про автоматический вывод типов
От: Шахтер Интернет  
Дата: 14.02.06 07:36
Оценка: 24 (1)
Здравствуйте, eao197, Вы писали:

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


E>>>Строки отлаженного кода штука дорогая.

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

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


Это слова Давида Гильберта.
Он сказал как-то примерно так: ты по настоящему понимаешь предмет если можешь выйти на улицу и объяснить его первому встречному.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[19]: Философический вопрос про автоматический вывод типов
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.06 14:59
Оценка: 22 (1)
Здравствуйте, eao197, Вы писали:

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


S>>Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая.


E>Строки отлаженного кода штука дорогая.

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

E>Я просто рассказал, как я работаю. И к этому механизму я пришел не сразу, а за 15 лет, которые занимаюсь программированием. Если кому-то не нравится -- это его дело. Если кто-то не верит, то может посмотреть на RuCodeGen, Mxx_ru, ObjESSty, SObjectizer
Автор: Евгений Охотников
Дата: 30.12.05
. Это все проекты, которые развивались практически в свободное от основной работы время. Для меня это служит доказательством эффективности моего подхода (примененного ко мне).


E>Если кто-то использует другие способы работы, то мне интересно про них узнавать и брать что-то на вооружение. Но я не собирась на навязывать свое мнение, ни реагировать на навязывание мне чужого мнения.

Ну, я надеюсь, что ни о каком навязывании речи не идет.
Я вообще всю жизнь хотел как можно больше проектировать. Но меня постоянно сдерживала тщетность моих усилий — бумагу в SVN не положишь, и в какой-то момент все равно надо набить этот код руками. Пробовал UML, но постоянно бесило отсутствие round-trip и поддержки полной модели языка. В какой-то момент я пришел к проектированию в коде, и использованию плагина в Розе для визуализации — благо Delphi позволял довольно шустро педалить интерфейсы (студия в те времена в качестве автокомплита предлагала вообще все, что ей известно, включая макросы. Се ля ви — плюсы язык такой, никогда заранее не знаешь, что удастся привести к чему ).
Неприятность была в том, что вносить изменения в коде было дорого — банальная опечатка в имени класса могла жить до конца проекта, т.к. не доходили руки сделать полную замену.
Я уже не говорю о смене типа свойства или раскидывании класса на два.

Теперь вроде как есть кульный кульман. Все как встарь, только в углу кнопка "построить здание по этому чертежу"
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 23.02.06 01:04
Оценка: 18 (1)
Здравствуйте, AndrewVK, Вы писали:

AVK>use cases это здорово и круто, когда исходные требования заранее известны. А на практике это частенько не так.


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

V>>Признайтесь, вы все часто используете пошаговую отладку на дотнете...


AVK>Правда есть одна область, где действительно приходится отладчиком часто пользоваться — при разработке расширения студии. Только вот проблема при этом не в дотнете, а в крайней убогости документации.


В принципе, по большинству прикладных классов документация не ахти. Не так уж много публичных классов имеют развернутую доку, с опсианием целей и задач этого класса, его взаимодействия с другими и т.д. Но это никак не мешает пользоваться остальными, где такой доки нет. Потому что есть внятные именования типов и методов. А для студии да, IServiceProvider и подобные ему — как голый QueryInterface в COM, аналог черной дыры в космосе.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Мое проектирование и рефакторинг
От: Павел Кузнецов  
Дата: 16.02.06 00:02
Оценка: 2 (1)
Здравствуйте, GlebZ, Вы писали:

ПК>>Что характерно, эта метафора намного ближе к описанию итеративного процесса, чем аморфный режим "постоянного рефакторинга". Последняя метафора страдает концентрацией на коде, а не на результате.


GZ>Хотелось бы намекнуть, что рефакторинг — это улучшение кода не влияя на функциональность. И он мало зависит от процесса разработки. Просто в ХП она обязательная дисциплина.


XP не отвергает выделенного этапа проектирования и планирования, и даже наоборот, в классике предполагает наличие в начале каждой итерации выделенное планирование, iteration planning meeting, и выделенный этап проектирования, основанный на использовании CRC Cards. Как мы уже разобрались выше и ранее, режим "постоянного рефакторинга" в трактовке Влада (т.е. произвольные модификации кода с помощью инструментальных средств IDE, обычно без unit tests) принципиально отличается от рефакторинга в трактовке XP, который, действительно, принципиально не изменяет функциональность.

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


GZ>Нет. По случаям глюков могу сказать что ХП дает менее глючный код. <...>


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

P.S. Интересно, на основании чего ты воспринял метафору "серии маленьких водопадиков" как противоречащую XP и т.п.? Уж не из-за того, что встретил слово "водопадик"?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[15]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 16:27
Оценка: 1 (1)
Здравствуйте, IT, Вы писали:

IT>Тогда тем более о чём мы спорим.





А разве мы спорим? Я думал мы просто впечатлениями о собственном стиле работы обменивамся.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 09.02.06 14:59
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>О каких системах ты говоришь?


Кто-то мне тут недавно приводил в качестве примеров Вижуал Студии, MS Офисы и прочие IE, Мазилы и Оперы Но я бы оценил это проще — если система предполагает затрат хотя бы в несколько человеко-месяцев, то продумать и удеражать её такую продуманную в голове крайне сложно. Да и не нужно. Очень часто всё это умножается ещё на неясные по началу функциональные требования.

Одним из реально работающих механизмов, позволяющих бороться со сложностью, является рефакторинг, который при больших объёмах кода немыслим без поддержки IDE.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 16:35
Оценка: :)
Здравствуйте, IT, Вы писали:

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


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

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

Так что похоже все эти попытки бесполезны. Вот Паша у нас до сих пор придумывает себе аутотренинг на тему "почему мне не нравится C#". Это все потому, что он подсознательно понимает, что не прав, но боится себе в этом признаться. Вот и ищет оправдания чтобы бороться со своими внутренними страхами. Вот Вольфхаунд попробовл новый путь и уже от него что-то не слышно огульного отрицаиня. Так что тут важен личный опыт. Без него они останутся теми самыми программистами на Абапе которые смотрят на мир с более низкоуровневой позиции и просто не в силах оценить смысл более высокоуровневых технологий.

Вот такая получается фрэйдистская фигня.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 10.02.06 02:33
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


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

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


Здесь кроме наличия самих средств ещё очень важно научится их применять. Что толку от рефакторинга, когда код уже превращён в помойку? Можно наверно самых больших мух отогнать, но дурно пахнуть всё равно будет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.02.06 10:15
Оценка: -1
Здравствуйте, IT, Вы писали:

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


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

А вообще:

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 10.02.06 13:17
Оценка: +1
Здравствуйте, eao197, Вы писали:

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


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


Это я к тому, что рефакторинг можно использовать как во благо человечества, так и во зло.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.02.06 07:52
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


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


Это были неправильные задачи!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Философический вопрос про автоматический вывод типов
От: Андрей Коростелев Голландия http://www.korostelev.net/
Дата: 12.02.06 10:56
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А у меня планирование занимает минуты, от силы часы. А вот реализация почему-то дни. Причем заранее извесно, что после того, как реализация хоть как-то заработает, то после анализа (а то и в процессе разработки) будут выявлены неучтенные предпосылки которые приведут к изменению плана, а стало быть и кода.


VD>Так мы плавно подходим к теме рефакторинга. Я опять же делаю его в мощьной IDE, а ты в снова в своем уме и Нотпэде.


То, что защищает Влад в лице ReSharper-а является в большей части удобным средством рефакторинга, когда решение о проведении того или иного типа рафакторинга уже принято разработчиком. Да, он умеет принимать кое-какие решения за разработчика (как то Extract method), они все основаны на статическом анализе кода.

Однако повод к проведению рефакторинга появляется в большей степени через опыт использования системы. Это уже ни что иное как Test-First Design, то есть динамический подход, когда дизайн эволюционирует через постоянное тестирование.
-- Андрей
Re[20]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.06 15:24
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

E>>Строки отлаженного кода штука дорогая.

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

Один умный человек когда-то на лекции сказал: "Ты знаешь что-то сам только когда можешь объяснить это другому". Имхо, ты понимаешь что-то только тогда, когда можешь внятно это описать. Мое рисование на бумаге как раз является критерием проверки понимания. А кристализация идеи до такой степени, чтобы быть внятно записанной, имхо, включает в себя и процесс отладки идеи. Отладки, которой может никогда не произойти, если я раньше времени отвлекусь от продумывания и брушусь за реализацию.

Приведенный мной пример с timer_thread_t как раз стал яркой тому иллюстрацией. На тот момент мне представлялось, что я четко представляю себе, как будет работать не только timer_thread_t, но и необходимый ему ACE_Event_Handler. И если бы я взялся за программирование, то написал бы код, заставил бы его работать, прикрутил бы к нему тесты. Проблема была бы в том, что в очень эпизодических ситуациях (когда вызов destroy_all_agent_msg() совпал бы с определенным моментом времени при обработке периодического сообщения этого агента) происходила бы порча памяти. Я сильно сомневаюсь, что такую ошибку удалось бы отловить в автономных тестах. И в реальном использовании она бы возникала очень нестабильно. Зато при проектировании, когда кода не было написано вообще, эта ошибка стала очевидной как только я взялся расписывать обработчик handle_timeout. Иначе как отладкой идей на бумаге я назвать это не берусь.

Может быть кто-то и может при программировании помнить детали проекта, но это не я.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.06 21:28
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

Мне влом переписывать твое письмо. Проти его и примени каждый пункт притензий к своим словам. За одно сэкономим на месте в БД и на моем времени.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Философический вопрос про автоматический вывод типов
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 04:46
Оценка: :)
Здравствуйте, eao197, Вы писали:
E>Таких примеров можно сотнями приводить. Например, если бы с ACE не шло несколько мегабайт тестов и примеров, то от их Reference Manual толку вообще было бы ~0%.
E>Но меня плохие примеры не интересуют, мне хочется делать хорошие примеры. Чтобы на мои проекты и мою документацию народ не плевался.
Это что-то из области фантастики. Разве что ты будешь сопровождать каждый метод блок-схемами.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.02.06 05:31
Оценка: -1
Здравствуйте, VladD2, Вы писали:

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


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

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


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

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

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


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

Так что, ты уж поверь, очень давно и очень хорошо известна цена "быстрого программирования" и "проектирования в коде".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 09:37
Оценка: :)
Здравствуйте, vdimas, Вы писали:

Вести разговор с людьми пытающимися сорвать аплодисменты на экстравагантности хамства мне интереса не представляет.

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

Если хочешь обсудить мои слова, то исходи из предпосылок, что твое мнение не имеет никакого преимущества перед чужим. Я с удовольствием послушаю конструктивную критику своих слов и отвечу на нее. Но я не желаю выступать в роли оправдывающегося. В конце концов я, и что характерно, многие не последние люди на RSDN-е использую этот подход уже не мало времени и для себя определился в его высокой эффективности. Доказывать это тем, кто всеми силами противится принятию новых идей дело не благодарное. Жить они смогут и при самых экстенсивных подходах к разработке. Так что счастливо оставаться при своем мнении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 15.02.06 02:45
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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


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

Кстати, следующей вещью повышающей скорость разработки скорее всего станут системы, позволяющие расширять компиляторы, что совместно с декларативностью даст возможность повторно использовать очень сложные паттерны.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Мое проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.02.06 05:30
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Что-то вас господа занесло. Один апологет XP, другой водпадов.


Не, я не водопада апологет. А так... серии маленьких водопадиков.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 22:19
Оценка: :)
Здравствуйте, vdimas, Вы писали:

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


use cases это здорово и круто, когда исходные требования заранее известны. А на практике это частенько не так.

V>Признайтесь, вы все часто используете пошаговую отладку на дотнете...


Признаюсь — нет. Более того, частенько у меня хватает наглости закоммитить код в репозиторий, просто убедившись что он компилируется. Обычно прокатывает . Правда есть одна область, где действительно приходится отладчиком часто пользоваться — при разработке расширения студии. Только вот проблема при этом не в дотнете, а в крайней убогости документации. Так и у тебя скорее всего — видимо задачка неприятная попалась.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[17]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.02.06 04:47
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Споришь ты с Владом, так что не отвлекайся

ВВ>Ибо общественность в лице меня требует продолжения.

Вот такого?
Автор: eao197
Дата: 15.02.06


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Философический вопрос про автоматический вывод типов
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.02.06 08:43
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.


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


Это мне напоминает истории про физиков и математиков. Типа, как погасить горящий газ — повернуть ручку плиты. Как погазить газ, если он не горит — зажигаем газ, и сводим эту задачу к предыдущей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[19]: Философический вопрос про автоматический вывод типов
От: WolfHound  
Дата: 16.02.06 17:19
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.

И это хорошо. Зачем заниматься всякими примитивными нюансавми если можно занятся настоящим делом?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 16.02.06 22:16
Оценка: :)
Здравствуйте, Павел Кузнецов, Вы писали:

GZ>>Хотелось бы намекнуть, что рефакторинг — это улучшение кода не влияя на функциональность. И он мало зависит от процесса разработки. Просто в ХП она обязательная дисциплина.


ПК>XP не отвергает выделенного этапа проектирования и планирования, и даже наоборот, в классике предполагает наличие в начале каждой итерации выделенное планирование, iteration planning meeting, и выделенный этап проектирования, основанный на использовании CRC Cards.

Проектирование и планирование совершенно различается у жестких и мягких процессов программирования(я имею ввиду RUP и XP). В XP нет ничего постоянного. Ни в планировании, ни тем более в архитектуре. Даже те же CRC карты — это всего лишь некоторые намерения которые вполне могут измениться.
ПК>Как мы уже разобрались выше и ранее, режим "постоянного рефакторинга" в трактовке Влада (т.е. произвольные модификации кода с помощью инструментальных средств IDE, обычно без unit tests) принципиально отличается от рефакторинга в трактовке XP, который, действительно, принципиально не изменяет функциональность.
Он собственно сильно отличается и от моего рефакторинга. В отличие от принятых норм в XP, я не выделяю для него время в виде итераций. Он делается постоянно в каждой процедуре, и тесты я делаю после того как написал первую версию того или иного блока.

GZ>>Нет. По случаям глюков могу сказать что ХП дает менее глючный код. <...>

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

ПК>P.S. Интересно, на основании чего ты воспринял метафору "серии маленьких водопадиков" как противоречащую XP и т.п.? Уж не из-за того, что встретил слово "водопадик"?

Ключевым словом здесь было дизайн кода.

PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Мое проектирование и рефакторинг
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.06 12:12
Оценка: :)
Здравствуйте, GlebZ, Вы писали:
GZ>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.
Двойняшки?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.02.06 12:23
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Влад? Не припоминаю.

ГВ>Сейчас некогда копаться, поищу как-нибудь на досуге. Может быть, и ошибаюсь.

В следующий раз прежде чем делать заявления вроде этого поищи сразу. Глядишь и заявлять не станешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Философический вопрос про автоматический вывод типов
От: EXO Россия http://www.az.inural.ru
Дата: 26.02.06 04:21
Оценка: :)
Здравствуйте, vdimas, Вы писали:
V>Для этого сейчас и отделяют аналитиков от проектировщиков, чтобы путаницы не было
V>Если четких требований нет, то их необходимо изобрести, предложить... Причем конечный набор этих требований должен диктоваться лишь полезностью для заказчика (или нишевого пользователя), а не выводиться из экспериментов программиста как результат рефакторинга кода. Последнее работает только для каких-нибудь вещей, типа неординарных/исследовательских проектов, чаще всего из области разработки инструментария (то бишь системного софта/библиотек).

Можно я эту цитату на стенку повешу?
( Для напоминания кое-кому из коллег... )
Re[9]: Проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 14:30
Оценка:
Здравствуйте, IT, Вы писали:

IT>Это справедливо только для утилит командной строки.


Хорошие утилиты командной строки дорогого стоят. И сделать их не проще, чем написать какое-нибудь GUI приложение.

IT> Продумать большую систему в голове без прототипирования, без проб и ошибок и последующего рефакторинга практически невозможно. А здесь скорость набора кода в редакторе играет не самую последнюю роль.


О каких системах ты говоришь?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 14:40
Оценка:
Здравствуйте, eao197, Вы писали:

E>Хорошие утилиты командной строки дорогого стоят. И сделать их не проще, чем написать какое-нибудь GUI приложение.


Значит и такие утилиты невозожно полностью заранее продумать и расписать на бумаге.

IT>> Продумать большую систему в голове без прототипирования, без проб и ошибок и последующего рефакторинга практически невозможно. А здесь скорость набора кода в редакторе играет не самую последнюю роль.


E>О каких системах ты говоришь?


О лбых сложнее тех что примитивны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 14:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А у меня планирование занимает минуты, от силы часы. А вот реализация почему-то дни. Причем заранее извесно, что после того, как реализация хоть как-то заработает, то после анализа (а то и в процессе разработки) будут выявлены неучтенные предпосылки которые приведут к изменению плана, а стало быть и кода.


VD>Так мы плавно подходим к теме рефакторинга. Я опять же делаю его в мощьной IDE, а ты в снова в своем уме и Нотпэде.


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

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

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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 15:12
Оценка:
Здравствуйте, IT, Вы писали:

IT>Кто-то мне тут недавно приводил в качестве примеров Вижуал Студии, MS Офисы и прочие IE, Мазилы и Оперы



Здесь не берусь судит, каждый из этих проектов больше всего, в чем мне доводилось участвовать. Я о том, чтобы такой объем кода затем собирался в один дистрибутив и работал затем как одно целое.

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


Все время не нужно. Только на момент проектирования. А это не так уж и сложно. Особенно, если нарезать систему на слои и не смешивать их без лишней надобности.

IT>Очень часто всё это умножается ещё на неясные по началу функциональные требования.


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

IT>Одним из реально работающих механизмов, позволяющих бороться со сложностью, является рефакторинг, который при больших объёмах кода немыслим без поддержки IDE.


Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 15:53
Оценка:
Здравствуйте, IT, Вы писали:

E>>Более того, если ты будешь делать рефакторинг не думая, то есть очень большая вероятность, что ты будешь делать его неоднократно.


IT>Именно неоднократно и со 100% вероятностью.


E>>Вместо того, чтобы подумать и изменить только то, что действительно нужно.


IT>А я и буду менять только то, что нужно. Впрочем, возможно у нас разное понимание 'нужно'.


Я не зря у тебя спращивал, о каких системах идет речь. Если дело касается каких-то GUI вещей, да еще разрабатываемых под конкретного заказчика со своими прибабахами, то здесь я с тобой соглашусь на 100%. Хотя у меня был опыт разработки специализированного векторного редактора, там так же пришлось сначала много чего спроектировать, прежде чем приступить к кодированию (например, как при выделении нескольких объектов в одну группу сделать диалог изменения свойств, который бы позволил изменять только те свойства, которые есть у всех объектов в группе).

Тем не менее, есть и другие системы (черные ящики, которые с пользователем не работают, а выполняю свою задачу). Из того, что лично я делал, вот пример
Автор: eao197
Дата: 24.01.05
. И я не представляю, как подобные вещи можно делать без предварительного тчательного продумывания.

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


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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 09.02.06 16:03
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>Все время не нужно. Только на момент проектирования. А это не так уж и сложно. Особенно, если нарезать систему на слои и не смешивать их без лишней надобности.


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

IT>>Очень часто всё это умножается ещё на неясные по началу функциональные требования.


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


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

E>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?


Откуда я знаю? Надо хотя бы взглянуть на эти 200к строк
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 16:13
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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

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


Может и я к тому же приду
Кстати, недавно писал на RubyOnRails, мне показалось, что там по другому вообще нельзя (по крайней мере, если не знаешь этот RoR в мельчайших деталях).

E>>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?


IT>Откуда я знаю? Надо хотя бы взглянуть на эти 200к строк


Дык в том-то и дело, что 200k никогда и не требуется изменять. Обычно дело 1k-2k ограничивается. А на таких объемах можно и ручками обойтись (особенно, если вот так
Автор: eao197
Дата: 25.01.06
). Нужно только понять, какую именно тысячу строк выбросить


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 16:14
Оценка:
Здравствуйте, eao197, Вы писали:

E>А почему учет неучтенных факторов должен обязательно требовать рефакторинга? Рефакторинг, если я не путаю, это изменение внутренностей кода, без изменения его функциональности. Здесь же речь идет об изменении функциональности.


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

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

В RE (Rsdn.Editor) реализована работа со шрифтами. Вроде бы как все пашет, но есть проблема. Шрифт задается дотнетным объектом Font который не позволяет задать отдельные атрибуты шрифта. К тому же трудно организовать масштабирование шрифта (то есть сделать конечно можно, то при этом будет не очень красивое решение).

Заранее продумать такие мелкие подробности было конечно можно, но наличие столь мелких деталей резко усложняет сам план. По этому сначало все было реализовано в лоб, на базе дотнетных шрифтов, а потом был произведен рефакторинг/модификация кода цель которой замена System.Drawing.Font на более сложное решение, а именно на набор классов позволяющих задать срифт частично, комбинировать настройки шрифта и в итоге поулчить некую сущьность которую я назвал ZoomedFont которая прозрачно используется для конечных рассчетов и вывода на экран.

Изменения затронилу большую часть проекта.
http://rsdn.ru/projects/VcsStatus.aspx?project=Rsdn.Editor (версия 46-52)
Если бы я производил рефакторинг вручную и темболее если бы я писал на скриптовом языке, то столь масштабный рефакторин был бы или вообще не возможен, или крайне затруден. Наличие кучи юнит-тестов здесь во-первых скорее помешало бы, так как их сами пришлось бы переписывать, а во-вторых было бы довольно бессмысленно, так как речь идет о динамике ГУИ и тесты сделать крайне не просто.

Так вот наличие средств рефакторинка и строгая статическая типизация позволила мне произвести масштабное изменение проекта с минимумом отладки. Фактически она не заняла и 10 минут. Я просто поправил опечатки и изменил, то что забыл изменить.

Что же мне позволило это сделать? Две вещи. Автоматизированный рефакторинг, и дизайнер классов. Без них бы я просто не решился на столь масштабные изменения или делал бы их очень долго.

E> Далеко не факт, что это изменение потребует рефакторинга. Так же не факт, что подобные изменения не будут выявлены при предварительном проектировании.


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

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


Никто не говорит о том, что не надо думать. Я веду речь о том, что объем информации которую мне нужно держать в голове и которую нужно отслеживать значительно меньше за счет применения средств автоматизации.

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


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

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


Гм. Работодатель зависит от результатов твоего труда. Так что если он очено долго не будет это осозновать, то рискует вылететь в трубу. Хотя конечно если этого не происходит, то на эффектиность разработки можно наплевать... до поры... до времени...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 16:40
Оценка:
Здравствуйте, eao197, Вы писали:

E>Дык в том-то и дело, что 200k никогда и не требуется изменять. Обычно дело 1k-2k ограничивается. А на таких объемах можно и ручками обойтись (особенно, если вот так
Автор: eao197
Дата: 25.01.06
). Нужно только понять, какую именно тысячу строк выбросить


Измерил объем файлов исправленных мной (между делом) в проекте Rsdn.Editor за последнюю неделю. Получилось 30 файлов общим объемом 455 килобайт. Вот их список:
\Rsdn.Editor.Test\MainForm.cs
\Rsdn.Editor.Test\MainForm.Designer.cs
\Rsdn.Editor\Formatter\breakline.cs
\Rsdn.Editor\Formatter\DefaultStyler\RsdnStyler.cs
\Rsdn.Editor\ObjectModel\Edit.cs
\Rsdn.Editor\ObjectModel\Row\Row.cs
\Rsdn.Editor\ObjectModel\Styles\CombinedStyle.cs
\Rsdn.Editor\ObjectModel\Styles\CompleteStyle.cs
\Rsdn.Editor\ObjectModel\Styles\SimpleStyle.cs
\Rsdn.Editor\ObjectModel\Styles\Style.cs
\Rsdn.Editor\ObjectModel\Styles\StyledRange.cs
\Rsdn.Editor\ObjectModel\View\IView.cs
\Rsdn.Editor\ObjectModel\View\iviewowner.cs
\Rsdn.Editor\ObjectModel\View\PaintInfo.cs
\Rsdn.Editor\ObjectModel\View\view.displayrowscalculations.cs
\Rsdn.Editor\ObjectModel\View\View.Paint.cs
\Rsdn.Editor\ObjectModel\View\view.properties.cs
\Rsdn.Editor\ObjectModel\View\View.State.cs
\Rsdn.Editor\ObjectModel\View\View.Translate.cs
\Rsdn.Editor\Utils\RsdnGraphics\DoubleBuffering.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\CompleteFont.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontEx.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontExComparer.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontExField.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\FontHelper.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\IFont.cs
\Rsdn.Editor\Utils\RsdnGraphics\FontEx\ZoomedFont.cs
\Rsdn.Editor\Utils\RsdnGraphics\RsdnGraphics.cs
\Rsdn.Editor\Utils\utils.cs

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

Можешь не верить в это, но это факт подтвержденный нашим SVN-ом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 16:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.02.06 16:48
Оценка:
Здравствуйте, eao197, Вы писали:

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


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

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


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

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


И? Ты что-то хочешь этим сказать? Или думашь, что с тобой кто-то будет спорить? Для Явы есть IDEA и Ява в общем-то полноценное средство разработки. На ней тоже можно работать эффективно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 17:01
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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

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


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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Философический вопрос про автоматический вывод типов
От: Programmierer AG  
Дата: 09.02.06 17:15
Оценка:
Здравствуйте, eao197, Вы писали:

E>Знаешь как говорят: тесты способны показать наличие ошибок, но не их отсутствие.

Имхо, этим утверждением Дейкстра пытался показать ущербность тестирования по сравнению с формальным доказательством корректности .
Re[13]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.02.06 17:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Философический вопрос про автоматический вывод типов
От: WolfHound  
Дата: 10.02.06 12:19
Оценка:
Здравствуйте, eao197, Вы писали:

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

Кривой код и код не подходящий под уточненные или изменившияся требование это далеко не одно и тоже. А требования порой меняются так что нужно поменять очень много кода для того чтобы потом можно было систему поддерживать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Философический вопрос про автоматический вывод типов
От: xbit Россия  
Дата: 11.02.06 00:44
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

ЗЫ: мой выбор: постараться грамотно спроектировать + использовать по максимуму возможности среды разработки.
Нас не догонят!
Re[15]: Философический вопрос про автоматический вывод типов
От: xbit Россия  
Дата: 11.02.06 01:15
Оценка:
Привожу неболшую главу с книги "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. А далее все, как тут описано.

ЗЫ: это все мое личное ИМХО
Нас не догонят!
Re[16]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.02.06 06:51
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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


+1

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Проектирование и рефакторинг
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.02.06 07:26
Оценка:
Здравствуйте, eao197, Вы писали:

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

А также скоростью отладки, скоростью понимания чужого кода с помощью быстрого позиционирования на нужных переменных и методах и тд.
Несомненно нотепад в этом рулит. Когда после хорошего приходшь к аналогу нотепада, возникает быстрое отсутствие слюны и неизбежный переход в твой стан.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.02.06 08:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Все мы жертвы цепи нелепых случайностей.

((С) К.Вонегут).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.02.06 09:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И заказчики у тебя неправильные! Они несут неправильный мёд. Так что, ты его не пей, козлёночком станешь. Давай, бросай всё и вливайся в ряды миллионов. Ты понял, нет? Миллионы тебя ждут. Мил-ли-о-ны!А ты, понимаешь, расчирикался! Ты ещё не понял, как надо компиляторы писать? Эх, и поимела же тебя матрица! По самое фрейдистское начало.




Гена, что-то ты злой сегодня.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Проектирование и рефакторинг
От: VladGalkin Украина  
Дата: 12.02.06 10:03
Оценка:
Здравствуйте, eao197, Вы писали:

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

Отсюда парадокс: идеальное решение не требует кода и времени на отладку, то есть его нет.
... << RSDN@Home 1.1.4 stable rev. 510>>
ДЭ!
Re[17]: Философический вопрос про автоматический вывод типов
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.02.06 14:34
Оценка:
Здравствуйте, eao197, Вы писали:
E>Кстати, приведенный мной черновой вариант
Автор: eao197
Дата: 10.02.06
решения с timer_thread_t оказался не правильным. И я выбросил его не написав ни одной лишней строчки кода. У меня не возникло соблазна взять какую-то часть написанного кода для нового решения (не знаю как у кого, но у меня такой соблазн всегда был слишком велик).

Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая. И вот ты получил лист A4, и сэкономил несколько строк кода.
Я пока еще не достиг нужного уровня просветления, но довольно давно предпочитаю проектировать в терминах кода. Раньше мне это было не очень удобно, потому что я писал на дельфи, а там еще и изменения в интерфейсе не очень хорошо отображались в имплементейшн. Не говоря уже о внешних ссылках.
Сейчас в студии я пишу код не задумываясь. При этом получается у меня быстрее, чем на бумажке:
— когда я описываю интерфейс или делегат, мне вообще не нужно делать лишних нажатий. За меня почти все дописывает автокомплит.
— когдя я меняю сигнатуру, у меня под рукой рефакторинг, который мгновенно согласованно меняет весь солюшн.
Поэтому мне не страшно сделать ошибку. Я не пользуюсь решарпером, т.к. он еще недостаточно стабилен. Но даже встроенный рефакторинг VS2005 позволяет мне думать кодом.
При этом самое милое — в том, что когда я хочу нарисовать картинку, дизайнер диаграмм делает это гораздо быстрее и аккуратнее, чем карандаш и бумага. И, в отличие от бумаги, эти картинки не теряются под столом, а идут в SVN. И они бесплатно сохраняют актуальность, если я что-то поменял в коде!
Я выбрасываю довольно много кода. Зачастую придуманные мной интерфейсы/классы не переживают очередного витка рефакторинга. Но я отношусь к ним так же, как к бумажкам на столе — периодически выкидываю их из SVN.
Получается, что мне проектировать в студии дешевле, чем на бумаге!

E>И еще один важный момент по поводу проектирования. Неявно подразумевается, что проект все равно будет неоднократно пересматриваться, требования к нему будут изменяться и все равно его придется перекраивать и переделывать. В некоторых предметных областях только так и можно, но не везде. При разработке программного инструментария ситуация несколько иная. Если я разрабатываю объектную СУБД, то глупо, имхо, расчитывать на то, что требования к ней будут меняться раз в месяц. Нет, я сразу должен буду получить приемлимый результат. Более того, должен быть выбран такой API для СУБД, который бы позволил выпустить несколько версий СУБД не нарушая совместимости клиентских приложений.

API — пожалуйста. А внутреннее устройство можно пересматривать как угодно. Более того, обычно этого не делают не потому, что не надо, а потому, что очень дорого.
E>А в разработке СУБД есть области, в которых лично я не представляю себе написания кода без точного понимания того, как он будет работать. Например, механизм записи транзакционных изменений посредством write-ahead log. До написания кода я уже должен четко знать, какая метаинформация информация должна быть в log-е, как по этой информации определять актуальность log-а, как по log-у восстанавливать БД после сбоя, можно ли использовать log для организации on-line репликации и пр. Конечно, точный состав и форма представления метаинформации будет меняться по ходу реализации. Сама реализация может быть итерационной, где некоторые части метаинформации будут игнорироваться на разных итерациях. Еще более вероятно, что перед разработкой будет создано и выброшено несколько прототипов. Но суть в том, что лично я не представляю, как придти к механизму write-ahead log-а начав с программирования подсистемы write-ahead log-а.
А что ты начинаешь делать при проектировании? пишешь текст? Ну так я просто набиваю // и тайпаю. Возникла какая-то сущность типа LogRecord? Ок, пишем:
internal struct LogRecord
{
  Guid Id;
    DateTime TimeStamp;
    |
}

E>И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная. Например, если речь идет о вспомогательных библиотеках. Я думаю, что для программиста, использующего ACE, не так уж много пользы даст код метода ACE_Event_Handler::handle_input или ACE_Reactor::run_reactor_event_loop. А в некоторых случаях кода используемой библиотеки нет вовсе. На первое место в таких условях выходит документация, написанная в комментариях к методам и классам. Но чтобы ее написать, довольно часто нужно представлять себе всю картину в целом. Картину, которая открывается мне после предварительного проектирования на бумаге.
Гм. К моменту, когда у тебя завершено проектирование на бумаге с текстами, у Влада и IT уже готов набор заглушков на все методы этой библиотеки. Все мало-мальски существенные мысли записаны не карандашом, а в блоках ///. Поэтому в конце достаточно просто просмотреть эту документацию на предмет корректности, понятности и полноты.
E>Поэтому, когда я приступаю к программированию, я приступаю и к документированию. При этом написание doxygen комментариев к коду является, наверное, более трудоемкой и длительной операций, чем кодирование. Зато на выходе получается еще и довольно объемный и актуальный Reference Manual. Конечно, не иногда он не нужен. Но, поскольку я всегда старался заниматься разработкой инструментария, то практически постоянно мне приходилось делать еще и документацию. И предварительное проектирование на бумаге существенно облегчало этот процесс.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.06 14:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая.


Строки отлаженного кода штука дорогая.



Вообще, я никому не навязываю свой способ работы. Не доказываю, что чей-то способ работы ущербен.

Я просто рассказал, как я работаю. И к этому механизму я пришел не сразу, а за 15 лет, которые занимаюсь программированием. Если кому-то не нравится -- это его дело. Если кто-то не верит, то может посмотреть на RuCodeGen, Mxx_ru, ObjESSty, SObjectizer
Автор: Евгений Охотников
Дата: 30.12.05
. Это все проекты, которые развивались практически в свободное от основной работы время. Для меня это служит доказательством эффективности моего подхода (примененного ко мне).

Если кто-то использует другие способы работы, то мне интересно про них узнавать и брать что-то на вооружение. Но я не собирась на навязывать свое мнение, ни реагировать на навязывание мне чужого мнения.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Философический вопрос про автоматический вывод типов
От: EXO Россия http://www.az.inural.ru
Дата: 13.02.06 15:01
Оценка:
О!

Но это вовсе не к вопросам среды разработки.
Просто минимализм "красивостей" приучил тебя думать над программой. В первую, вторую и третью очередь... а кодировать — кодировать потом.

Вообще, все эти разговоры о скорости написания кода мне достаточно смешны. Просто лично у меня на кодирование и отладку (!) в общей сложности уходило (раньше — пока занимался именно програмингом) примерно полтора часа в день. Все остальное — проектирование и выстраивание концептуальной модели. И если бы я даже сэкономил что-то из этих полутора часов, это была бы не сильно существенная экономия.
Пожалуй мне была бы полезнее (в плане итоговой эффективности) какая-нибудь хорошая среда написания use case, чем навернутая среда разработки с авторефакторингами. А еще лучше — интеграцю idef с теми же use case и ментальными картами. Но такой пока не нашел (по "рейшеновские" продукты можно не говорить — достали).
Re[18]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.06 15:50
Оценка:
Здравствуйте, IT, Вы писали:

IT>Код — это как раз самая точная и достоверная информация. Когда уже не помогают хелпы, то остаётся только код. Да простит меня Бил Гейтс, но чтобы разобраться как работает баиндинг в WinForms, мне пришлось декомпильнуть фреймворк. Это уже после изучения всех MSDN'ов и прочих гуглей. Есть такая WinForms библиотека Syncfusion с, мягко выражаясь, несколько противоречивым интерефейсом. Документация к ней есть, но понять главную идея и охватить широту мысли разработчиков можно только изучая исходный код. Если при этом этот исходный код можно подключить к текущему проекту, то во многих случаях проход по коду отладчиком даёт полное представление о происходящем.


Таких примеров можно сотнями приводить. Например, если бы с ACE не шло несколько мегабайт тестов и примеров, то от их Reference Manual толку вообще было бы ~0%.
Но меня плохие примеры не интересуют, мне хочется делать хорошие примеры. Чтобы на мои проекты и мою документацию народ не плевался.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.02.06 16:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.02.06 20:42
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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


1. Тут никто не спорит с некой мифической позицией. Тут скорее наблюдается сме...ки и п...ханьки по поводу чужишь слов без высказывания собственной позиции.
2. Кто говорил об отсуствии этой самой стадии проектировани? Она есть, но намного короче, так как объем планируемых действий меньше, а уровень планирования выше. И она другая. Так как процесс планирования становится короче план во многих случаях может быть просто продуман в уме. Если это не возможно, то мысли оформляются в осязаемом виде и проверяются на корректность. Ну и она растянута во времени сливаясь с процессом кодирования. Ведь как правильно заметили Вольфхаунд и ИТ простота изменения кода убирает комплекс боязни ошибки. Проще ошибиться и переделать нежели бесцельно тратить время пытясь во что бы то ни стало уберечься от ошибок проектирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Проектирование и рефакторинг
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 05:25
Оценка:
Здравствуйте, VladGalkin, Вы писали:
E>>Скорость моей разработки определяется не скоростью набора кода в редакторе, а скоростью продумывания и проектирования. Чем лучше решение продумано, тем меньше оно тебует кода и времени на отладку.
VG>Отсюда парадокс: идеальное решение не требует кода и времени на отладку, то есть его нет.

Кстати, не такой уж и парадокс. Есть примеры.
Хотя бы вот в этой книжке:
http://www.alpina.ru/book/36/
а вот в этой статье некоторые выдержки из кникги
http://www.osp.ru/cio/2004/06/022.htm
Re[14]: Философический вопрос про автоматический вывод типов
От: Павел Кузнецов  
Дата: 14.02.06 07:04
Оценка:
VladD2,

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


Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше" и "уровень планирования выше"? (Чтобы сократить количество оборотов в хождении кругами, можем заранее считать, что в обоих рассматриваемых случаях процесс разработки итерационный.)
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[16]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 14.02.06 08:33
Оценка:
Здравствуйте, Шахтер, Вы писали:

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

Ш>Хотя С# действительно провоцирует на грязную работу. Ну так не поддавайся на провокации.

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

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

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

Ситуацию осложняют постоянные пробросы исключений в TCP-канале. Суть в чем: есть такая опция — break on exception. Очень удобно — поставил опцию и получил break в месте выброса exception. Так вот, внутренности TCP-канала постоянно пробрасывают и глотают в нутри себя исключения... Типа, логика там на них, что ли... В общем, этим полезным способом вылавливать ошибки не получается (канал фонит исключениями примерно каждые 10 сек). И как альтернатива — глубокие пошаговые погружения в подробности ремотинга и всего этого нетипизированного мусора, на котором он построен.
Re[17]: Философический вопрос про автоматический вывод типов
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 09:02
Оценка:
Здравствуйте, vdimas, Вы писали:

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


Интересно. По идее, автостоп на брошенных исключениях работает только для режима Just My Code, а в нем тебе кишочки канала не должны быть видны. А если и видны, достаточно пойти в диалог Exceptions и отключить лишний фон.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Философический вопрос про автоматический вывод типов
От: kliff Россия http://www.esignal.ru
Дата: 14.02.06 09:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


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



Имхо, розовый слоник чересчур категоричен. Не стоит всех по себе мерить.
Re[18]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 14.02.06 10:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Подсказка: Если ты хочешь, чтобы тебя слушали оппоненты и относились к твоим словам с уважением, то не стоит вести разговор в снисходительном тоне и давать направо и налево "хинты".


1. Насколько я понял, это был хинт?
2. А прибедняться зачем? Я лишь придерживаюсь общего тона нашей беседы:

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

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

1. прИдумывание функциональности — это из области анализа, а не проектирования.
2. никто не жаловался на трудности в прОдумывании реализации

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

Никто не трясется. Просто людям любобытно хотя бы примерно понять, что именно придется делать и хотя бы примерно спланировать затраты (временные — они же финансовые в нашей отрасли)


--------
И кстати, предыдущий мой пост перед критикуемым был вполне нейтральным.

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

Угу, не слова хотелось бы обсуждать, но мысли. Бесконечно сожалею, что подобранные сторонами слова этому мешают...

VD>Я с удовольствием послушаю конструктивную критику своих слов и отвечу на нее.

Критику слов и услышал. А по смыслу, если не придираться к словам — все вполне по существу.

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

Если ты об поддержке твоей позиции IT, то я возражаю. IT очень долго собирал требования, вел обсуждения, вносил изменения в предыдущую версию. Стадия проектирования последней версии его детища ИМХО была черезчур длинной.

Хотя, если предположить, что мы все трое говорим о разных вещах... Например, IT имеет ввиду взаимоотношение конкретных классов в своем фреймворке и раскиданную м/у ними функциональность... На подобной стадии, поверь, я поступаю точно так же. Здравый смысл и решарпер в руки. До таких подробностей мало кто проектирует на бумаге сейчас.

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


К сожалению, твои идеи (вернее привычки) — не новые. Они инстинктивные и от них старательно отучают в некоторых местах. Тон в этой области задают люди, которые руководили проектами ценой в сотни человеко-лет.

------------
VD>Вести разговор с людьми пытающимися сорвать аплодисменты на экстравагантности хамства мне интереса не представляет.

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

Ладно, завязываем
Re[18]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 14.02.06 10:43
Оценка:
Здравствуйте, IT, Вы писали:

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


E>>И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная.


IT>Код — это как раз самая точная и достоверная информация. Когда уже не помогают хелпы, то остаётся только код. Да простит меня Бил Гейтс, но чтобы разобраться как работает баиндинг в WinForms, мне пришлось декомпильнуть фреймворк. Это уже после изучения всех MSDN'ов и прочих гуглей.


Да... биндинг в дотнете — это вообще пестня...
Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.

А ТРИЖДЫ запрашиваемые данные при загрузке и отображении формы??? Именно, если "ничего не делать" — трижды... Если кое-что в базовых классах делать, то можно снизить до двух раз... пестня...
Re[19]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 14.02.06 12:52
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Да... биндинг в дотнете — это вообще пестня...

V>Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.

Там ещё есть соответствующий интерфейс.

V>А ТРИЖДЫ запрашиваемые данные при загрузке и отображении формы??? Именно, если "ничего не делать" — трижды... Если кое-что в базовых классах делать, то можно снизить до двух раз... пестня...


Трижды? По-моему, там стрельба идёт как из пулемёта. А если учесть, что стандартный TypeDescriptor не отличается остротой ума и скоростью сообразительности, то картина совсем становится печальная.

Но если это всё правильно приготовить, то вполне может получиться деликатесная вещь
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 14.02.06 14:57
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше" и "уровень планирования выше"?


По сравнению с традиционным проектированием, которое не просто не гарантирует отсутствие ошибок, а делает их значительно опаснее из-за невозможности своевременного выявления.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Философический вопрос про автоматический вывод типов
От: Павел Кузнецов  
Дата: 14.02.06 15:31
Оценка:
IT,

> ПК> Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше" и "уровень планирования выше"?


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


Что такое традиционное проектирование? (Напоминаю, что мы договорились
Автор: Павел Кузнецов
Дата: 14.02.06
, что в обоих обсуждаемых случаях речь идет об итеративных процессах.)
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[17]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 15:44
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Что такое традиционное проектирование? (Напоминаю, что мы договорились
Автор: Павел Кузнецов
Дата: 14.02.06
, что в обоих обсуждаемых случаях речь идет об итеративных процессах.)


Паш, если ты с нами согласен, и придерживашся тех же подходов, то так и скажи. А то шифрушся тут.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Философический вопрос про автоматический вывод типов
От: Павел Кузнецов  
Дата: 14.02.06 15:55
Оценка:
VladD2,

> ПК> Что такое традиционное проектирование? (Напоминаю, что мы договорились
Автор: Павел Кузнецов
Дата: 14.02.06
, что в обоих обсуждаемых случаях речь идет об итеративных процессах.)


> Паш, если ты с нами согласен, и придерживашся тех же подходов, то так и скажи. А то шифрушся тут.


Я разницу своих предпочтений по сравнению с озвучиваемым тобой подходом уже давно упомянул
Автор: Павел Кузнецов
Дата: 13.02.06
. Впрочем, не обижайся, если на очередную реплику, не учитывающую предшествующие сообщения, я отвечать не стану...
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[17]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 21:49
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.

Если твое проектирование ириводит к тому, что мне прийдется мыться не в ванне, а под душем, то ну его на фиг такое проектрование.

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


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


Всей запланированой функциональности.

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


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

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


ГВ>Ещё раз: проектирование как раз и предполагает, что большая часть трудностей будет выловлена на его этапе.


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

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

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


Кстати, почему все время говорится о заказчике так как-будто все проекты на свете делаются для дяди. Причем для копризного дяди и еще к тому же слабо вменяемом?

А коробочные продукты уже не существуют? А вменяемые заказчики пологющиеся на опыт разработчиков?

ГВ> Например, нельзя заложить срок реализации 10 месяцев, а можно назвать не более, чем 5 месяцев. Хотя ясно, что при этом первоначальные 10 месяцев превратятся в ~14-15 с учётом времени, потраченного на реализацию прототипов.


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

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

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


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

В общем, нужно завязывать это соревнование. Все равно конструктива тут не будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 21:49
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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


ПК>Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше"


За счет того, что планирование производится на более абстрактном уровне. Многие детали при этом намеряно опускаются до тех пор пока они не станут очтетливо ясны в следствии уточнения других деталей.

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

ПК> и "уровень планирования выше"?


Все потому же. Проработка на начальной стадии менее глубокая, и более абстрактная. А детали уже уточняются по ходу дела, в том самом итеративном процессе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 15.02.06 02:50
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ситуацию осложняют постоянные пробросы исключений в TCP-канале.


Исключения какого типа? Если тип уникальный, то можно поставить на этот тип опцию — пропускать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Мое проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.02.06 05:29
Оценка:
Здравствуйте, IT, Вы писали:

IT>Что это даёт? Во-первых, к повторно используемому коду должны предъявляться повышенные требования. А значит требуется больше времени над ним подумать. То, что этот код где-то ещё несколько раз пригодится именно в таком виде — не факт. По-этому, кроме потери времени можно ещё и понаделать кучу одноразовых-повторно-используемых методов и классов. В результате мы имеем как выигрышь по времени, так и достаточно продуманную и полезную повторно-используемую часть подсистемы.


IT>При чём тут рефакторинг и почему я так раньше не делал? Потому что это было долго и чревато багами, т.е. было неэффективно. Лугче было сразу продумывать и писать повторно-испольуемые вещи.


Когда пишешь код на бумаге получается точно такой же эффект.

Вообще, написание кода сначала на бумаге напоминает парное программирование, только силами одного человека.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 15.02.06 08:49
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Посмотри вот это (может не самые удачные ссылки, но что уж нагуглилось):

EXO>http://www.journal.gennadij.pavlenko.name/node/2344
EXO>http://www.brainstorming.ru/article/diltsstr.htm
Удачные. Я когда-то читал об этом, но давно. А штука весьма интересная. И вообще, весьма жизненно.

EXO>Вот здесь начинаются расхождения. Архитектуру я рисую. Черкаюсь.

EXO>На этом этапе я не нашел пока адекватной замены бумаге.
EXO>Но рисую вовсе не классы, а "компаненты", процессы, модули. И потоколы между ними.
EXO>То есть декомпозицию задачи на подсистемы. Стараюсь получить их "слабосвязанность".
EXO>А дальше — для каждой отдельной подсистемы уже берусь за объетное проектирование. Например — через дерево классов. И это да — если возможно, в среде разработки. С удовольствием задействую все красивости и удобства.
EXO>Но этот этап (и остальные до резултата) у меня занимает уже около четверти времени.
Иногда приходится работать по довольно жесткому RUP с прописыванием в UML. Такие процессы мне очень не нравятся. Обычно это писанина компонентов которые уже есть в голове, и элементарно выводящиеся из прецедентов и предметной области.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 15.02.06 08:49
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Что характерно, эта метафора намного ближе к описанию итеративного процесса, чем аморфный режим "постоянного рефакторинга". Последняя метафора страдает концентрацией на коде, а не на результате.

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

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

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

ПК>То же проектирование нужно в т.ч. и для организации тестирования и "прикормки" documentation writers.

Для тестирования и documentation writers в основном полезны прецеденты написанные аналитиками а не архитекторами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 15.02.06 08:49
Оценка:
Здравствуйте, eao197, Вы писали:

GZ>>Что-то вас господа занесло. Один апологет XP, другой водпадов.

E>Не, я не водопада апологет. А так... серии маленьких водопадиков.
Я как-то побоялся называть разработку итерационной, поскольку все процессы разработки в современном мире итерационные.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 17:36
Оценка:
Здравствуйте, eao197, Вы писали:

E>Давай уточним постановку задачи.


Нет задачи. Есть решение которое применяю лично я дома когда наполняю ванну.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 17:36
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Ты не прав, IMHO. Мне было очень интересно и полезно почитать некоторые из здешних сообщений.


Ключевое слово некоторые. Но засилие откровенных понтов и бссмысленого перетирания превращают форум в пустой базар.

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


EXO>А можешь предположить, что все остальное ты просто не видишь?


А можешь предположить, что видить нечего?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 17:36
Оценка:
E>После таких слов возникает приступ графоманства и хочется написать статью 'Как я программирую на бумаге'
E>А IT с VladD2 и WolfHound-ом сделают симметричный ответ: 'Как мы программируем в IDE' с подзаголовком 'Бумага должна использоваться по прямому назначению в другом месте'
E>Не хотел никого обижать, просто пошутил.

А в этом ничего обидного лично я не вжиу. Наоборот дельное предложение разбавленное юмором.
Вот когда общение ведтся в стиле "Хинты: тебе надо подучиться...", вот это раздражает.

Пожалуй действительно имеет смысл описать процесс разработки. Вот только пример нужен.
Хотя это нужно для вас. Как бы с бумажкой мы и сами имеем. Раньше по другому и не удавалось.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Философический вопрос про автоматический вывод типов
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.02.06 17:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Нет задачи. Есть решение которое применяю лично я дома когда наполняю ванну.


Значит задача вполне точно определена: вымыться самому.
И решение вполне нормальное.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[21]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 21:58
Оценка:
Здравствуйте, eao197, Вы писали:

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


Пробовал когда нибудь переводить текст в большом объеме? Лично у меня на это уходит на порядок больше сил, нежели если нужно просто этот текст понять.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[19]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 21:58
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.


Это не байндинг, это особенности работы ReflectPropertyDescriptor.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[20]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 21:58
Оценка:
Здравствуйте, IT, Вы писали:

IT>Там ещё есть соответствующий интерфейс.


Только для списков.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[21]: Философический вопрос про автоматический вывод типов
От: IT Россия linq2db.com
Дата: 15.02.06 22:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

IT>>Там ещё есть соответствующий интерфейс.


AVK>Только для списков.


В 2.0 добавили INotifyPropertyChanged.
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 22:31
Оценка:
Здравствуйте, IT, Вы писали:

IT>В 2.0 добавили INotifyPropertyChanged.


До 2.0 руки пока не доходили. Недавно попробовал новый дизайн-тайм — понравилось. Наконец то это стало возможно использовать. В потроха не заглядывал.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[16]: Философический вопрос про автоматический вывод типов
От: Воронков Василий Россия  
Дата: 16.02.06 00:18
Оценка:
Здравствуйте, eao197, Вы писали:

E>А разве мы спорим? Я думал мы просто впечатлениями о собственном стиле работы обменивамся.


Споришь ты с Владом, так что не отвлекайся
Ибо общественность в лице меня требует продолжения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Философический вопрос про автоматический вывод типов
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.02.06 08:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения.


AVK>Черта с два. Я сам начинал всерьез программировать как раз когда на просторах необъятной стали популярны объектные TP 5.5 и TC 2. И тогда неприятие ООП было таким мощным, что сегодняшние войны против .NET ни в какое сравнение не идут. Запомнил я это хорошо потому что тогда сам испытал самую мощную ломку сознания за свою жизнь в попытке освоить ООП (а говорят — наоборот, мозги костенеют с возрастом).


Не совсем понял, если ты только начинал программировать, то откуда ломка сознания? И второе, чем ООП в интерпретации С++ отличается от Виртовской формулы " Алгоритмы+структуры данных=программы".

ГВ>> Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать?


AVK>Потому что иначе рискуешь попасть в плен к собственным предрассудкам.


Таки да.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.02.06 08:57
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Не совсем понял, если ты только начинал программировать, то откуда ломка сознания?


Читай внимательнее. Я написал всерьез программировать.

ANS> И второе, чем ООП в интерпретации С++ отличается от Виртовской формулы " Алгоритмы+структуры данных=программы".


Дизайном программ.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[15]: Философический вопрос про автоматический вывод типов
От: vitaly_spb Россия  
Дата: 16.02.06 10:46
Оценка:
IT>Я думаю, что это ещё связано и с тем, что это выглядит как будто проектирование как стадия совсем отсутствует. Но это не так. Оно точно также присутствует, только инструментами является не листок бумаги или какая-нибудь рисовалка, а сам компилятор и среда. А вот для БД ничего такого пока нет, поэтому приходится по старинке рисовать в Визио.

ИМХО PowerDesigner гораздо продвинутее Visio и подходит под "средство проектирования для БД", а не рисовалка
...Ei incumbit probatio, qui dicit, non qui negat...
Re[16]: Философический вопрос про автоматический вывод типов
От: vitaly_spb Россия  
Дата: 16.02.06 10:49
Оценка:
E>ИМХО: кривой код никаким рефакторингом не выправишь.

Это как раз единственное средство кроме переписывания. Другое дело, что рефакторинг такого кода это не процесс 5 минут.
...Ei incumbit probatio, qui dicit, non qui negat...
Re: Проектирование и рефакторинг
От: vitaly_spb Россия  
Дата: 16.02.06 11:09
Оценка:
IT>Таким образом, первое из перечисленных выше преимуществ проектирования становится не актуальным.

IT, отличный рассказ и я практически со всем согласен. С чем не согласен — проекты бывают разных масштабов и на них меняются разработчики (проект на 2-3 года скажем, люди могут уходить-приходить). Чтобы проект развивался обязательно должны быть зафиксированы структура проекта и т.п., это все забывается, не успевается передать и т.д.

Потом еще бывают ситуации с (мягко говоря) не самыми умными разработчиками, код которых приходится дорабатывать. Например, у меня была ситуация, когда я пришел в проект, половина которого была написана человеком за месяц до увольнения. Можно себе представить что там написал человек, котор. И сколько я промучался разбираясь в его коде (не было проектирования как такового по тому проекту, было только задание: сделать то-то и то-то).
...Ei incumbit probatio, qui dicit, non qui negat...
Re[19]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.02.06 11:35
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.


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


ANS>Это мне напоминает истории про физиков и математиков. Типа, как погасить горящий газ — повернуть ручку плиты. Как погазить газ, если он не горит — зажигаем газ, и сводим эту задачу к предыдущей.


А мне твои слова напоминаю влезанием в середину разговора не разобрашись. К чему ты это сказал то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Мое проектирование и рефакторинг
От: Павел Кузнецов  
Дата: 16.02.06 13:56
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ> . . . могу сказать что ХП . . .


GZ>Для тестирования и documentation writers в основном полезны прецеденты написанные аналитиками а не архитекторами.


О, кстати, а как XP и выделенные аналитики и архитекторы сочетаются между собой? По моему представлению это вещи, не вполне совместимые...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[20]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 16.02.06 16:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


V>>Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.


AVK>Это не байндинг, это особенности работы ReflectPropertyDescriptor.


Может быть, но используется именно в биндинге (и я пока не нашел, где еще).

Такие подходы — неявные шаманства по своей сути.
Re[22]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 16.02.06 16:06
Оценка:
Здравствуйте, IT, Вы писали:


IT>В 2.0 добавили INotifyPropertyChanged.


Кстати, прикольное совпадение, я тут
Автор: vdimas
Дата: 14.02.06
порассуждал для Wolfhound, как бы могли выглядеть "внешние" связи объектов и как бы работала система, построенная на этих внешних связях. Перекликается с биндингом и оповещением об изменении состояния.
Re[21]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.02.06 17:07
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Такие подходы — неявные шаманства по своей сути.


Никто тебе не мешает использовать собственную реализацию PropertyDescriptor.AddPropertyChanged.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[19]: Философический вопрос про автоматический вывод типов
От: Anton Batenev Россия https://github.com/abbat
Дата: 16.02.06 18:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".

V>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.

А ты, если хочешь и дальше носить титул специалиста, должен подняться на планку выше и включать эту самую кнопку силой мысли попивая вино на канарах. В противном случае, это будет называться "живем старым жиром".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.02.06 19:52
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".


Ну вот, Дима, наконец-то я понял главную мысль твоего ответа
Автор: vdimas
Дата: 14.02.06
. А то в ответ у меня очень объёмные какие-то рассуждения получались.

Короче говоря, здесь ты ошибаешься. Я имел ввиду не столько своё собственное "отличие от других", сколько "добавленную сложность" продукта. ИМХО, использование технологий вроде .Net/Java способствеут снижению этой самой ДС.

V>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.


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

V>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.


Так вот, ошибка как раз в том, что особенности C++ (в том числе и специфические комбинаторные приёмы) нужны не только для преодоления сугубо технических сложностей (кстати, а какие именно сложности ты имеешь ввиду как "технические"?). Да, они помогают, но не более того. Главное-то, ИМХО, другое — это возможность использовать приёмы C++ для реализации прикладной функциональности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: Философический вопрос про автоматический вывод типов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.02.06 20:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ГВ>> Четвёртая: подозрительная корреляция рассуждений провозвестников нового с тем, что делает MS. Проследить это можно на примере шаблонов (Кто тут пел, что это нафиг не нужно и приведение от базового Object — рулез форева?).


AVK>Влад? Не припоминаю.

Сейчас некогда копаться, поищу как-нибудь на досуге. Может быть, и ошибаюсь.

ГВ>>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения.

AVK>Черта с два. Я сам начинал всерьез программировать как раз когда на просторах необъятной стали популярны объектные TP 5.5 и TC 2. И тогда неприятие ООП было таким мощным, что сегодняшние войны против .NET ни в какое сравнение не идут. Запомнил я это хорошо потому что тогда сам испытал самую мощную ломку сознания за свою жизнь в попытке освоить ООП (а говорят — наоборот, мозги костенеют с возрастом).

Интересно. У меня такой ломки не было, хотя тоже, опыт структурного программирования на момент появления ОО-языков в наших пенатах уже был. С окружающими — да, были стычки. Правда уже попозже... но это уже совсем другая история.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 16.02.06 20:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


V>>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".


ГВ>Ну вот, Дима, наконец-то я понял главную мысль твоего ответа
Автор: vdimas
Дата: 14.02.06
. А то в ответ у меня очень объёмные какие-то рассуждения получались.


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


Да поняли мы это, разумеется. Вообще-то, в чем и можно было выделяться, так это в ДC
(остальные характеристики, типа "общей эрудированности" как-то не очень меня интересовали)


V>>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.


ГВ>Опять же, иллюстрация удачная, но только не к моей мысли, а к твоей. А ещё к тезису о том, что всякая сложная проблема имеет простое неправильное решение.


Я позволил себе утрирование, и оно, имхо, напрямую обращено к твоей ДС.

V>>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.


ГВ>Так вот, ошибка как раз в том, что особенности C++ (в том числе и специфические комбинаторные приёмы) нужны не только для преодоления сугубо технических сложностей (кстати, а какие именно сложности ты имеешь ввиду как "технические"?).


Кто-то кого-то тоже прочитал невнимательно... Я не сказал, что С++ для этого НУЖЕН (более того, я так не считаю), я в этих постах выше говорил о том, что на нем ПРИХОДИТСЯ это делать, из-за слабой прикладной базы.

Что такое техническая сложность на мой взгляд? Это некий эквивалент силы умственных напряжений (не путать с количеством), которое оно от меня требует. Иногда такие задачи попадались. Помнишь, я как-то говорил тебе, что обнаружил за собой, что последние лет 5-6 работаю "не думая"? Может быть, потому я так легко тратил время и на другие технологии, что банально давно не встречал "сложных" задач, для которых С++ был бы хорош.

ГВ>Да, они помогают, но не более того. Главное-то, ИМХО, другое — это возможность использовать приёмы C++ для реализации прикладной функциональности.


Отличные приемы, никто не спорит. Но я еще 2-мя постами сверху ставил на одну чашу весов выразительность С++, а на другую — отсутствие тонны мелочей, на которые ПРИХОДИТСЯ отвлекаться, работая на С++.

Мне бесконечно жаль, что на данный момент времени эти весы реально существуют. Это произошло потому что за последние буквально лет 7-10 взрывообразно возросла информационная емкость проектов, но не были сформированы языки, фреймворки и среды, отвечающие этим потребностям. Тот факт, что люди ВЫНУЖДЕНЫ использовать гораздо менее выразительные языки лишь из-за наличия платформы, показывает всю глубину (и позор, не побоюсь этого слова) этого отставания.

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

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

----------
Помнишь мой пост на sql.ru 3-х летней давности, с которого мы познакомились. Я считал, что С++ позволяет наиболее близко подходить в описании абстракций к интересующей прикладной области. Оно по прежнему так. (Например, в дотнете есть кое-какая перегрузка операторов, но невозможность перегрузить операторы: =, +=, -=, <<= и т.д. убивает добрую половину выразительных трюков, в общем, поэтому перегрузкой операторов там почти не пользуются )
Re[3]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 16.02.06 22:16
Оценка:
Здравствуйте, IT, Вы писали:

IT>Что это даёт? Во-первых, к повторно используемому коду должны предъявляться повышенные требования.

Моя проблема в том, что я предъявляю повышенные требования ко всему коду. И сразу не отходя от кассы. В результате получается что треть проекта пишется как бы с нуля, а остальная треть — это подключение и расширения классов. Никогда не поймешь, понадобится или не понадобится то или иное место во второй раз. А когда оно уже полностью подготовлено к расширению, то где-то через треть проекта начинаешь пользоваться готовыми конструкциями, которые и уже не нужно продумывать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 16.02.06 22:16
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

GZ>> . . . могу сказать что ХП . . .

GZ>>Для тестирования и documentation writers в основном полезны прецеденты написанные аналитиками а не архитекторами.
ПК>О, кстати, а как XP и выделенные аналитики и архитекторы сочетаются между собой? По моему представлению это вещи, не вполне совместимые...
Архитекторов как таковых нет. А аналитики(или представители клиента) используются в большей степени консультативно. Вобщем хаос управляемый одним человеком обязанности которого только в одном: чтобы друг другу морды не набили. Почти полное отрицания документации влияет и на documentation writers. Я очень сомневаюсь что писатели будут разбирать функциональные тесты. Что касается тестирования, то они предлагают именно автоматизированное тестирование притом сделанная клиентами. Во первых, задолбаешься с граничными условиями разбираться(что я не видел ни одной книжке по XP ). Во вторых, все равно все придется делать с аналитиками. Программисты не всегда хорошие помошники потому как для тестеров они люди заинтересованные, а для техписателей, люди не от мира сего.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Проектирование и рефакторинг
От: IT Россия linq2db.com
Дата: 17.02.06 01:50
Оценка:
Здравствуйте, vitaly_spb, Вы писали:

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


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

Всегда нужна актуальная схема базы данных (если есть БД), схема объектной модели тоже полезна. Если схема БД близка к объектной модели, то достаточно первой. Описание какой-нибудь общей концепции. Разъяснение неочевидных мест и алгоритмов. Этого в большинстве случаев более чем достаточно и чем меньше бумаги, тем легче поддерживать её в актуальном состоянии.

_>Потом еще бывают ситуации с (мягко говоря) не самыми умными разработчиками, код которых приходится дорабатывать. Например, у меня была ситуация, когда я пришел в проект, половина которого была написана человеком за месяц до увольнения. Можно себе представить что там написал человек, котор. И сколько я промучался разбираясь в его коде (не было проектирования как такового по тому проекту, было только задание: сделать то-то и то-то).


Про одноклеточных лучше никаких аргументов не приводить. Если бы он тебе оставил документация, то, поверь мне, было бы ещё хуже.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Философический вопрос про автоматический вывод типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.02.06 02:01
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".


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

V>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.


Как человек общавшийся с ЧПУ скажу тебе, что влючить кнопку недостаточно. Еще нужно ввести программу и обслуживать станок (менять фрезы, вносить поправки и т.п.). Думаю в твоем гипотетическом эксповаторе тоже будет что-то подобное. Так что место где можно отличиться будет. Надо только вовремя перестроиться. Ну, а уж захочешь ли ты перестроиться или нет — это твои проблемы.

V>Гена утрирует, но что-то в этом есть. Действительно, на многих "популярных" задачах достаточно ныне нажать кнопку "пуск" и все работает само в этом дотнете. Единственно что потребуется изучать — это расположение самой этой кнопки.


Мечат о зеленой факсовой кнопке решающей все задачи так и останется мечтой. Я в этом уверн. Так что не убдем обсуждать эту утопию.

V>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.


Именно. Причем искать то в общем-то нечего. Все под ногами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Мое проектирование и рефакторинг
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 17.02.06 08:42
Оценка:
GlebZ,

IT>>Мои поздравления! Мальчик, девочка?

GZ>Девочка 3700x51
Ничто не властно над истинными человеческими ценностями!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[9]: Мое проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.02.06 08:45
Оценка:
Здравствуйте, GlebZ, Вы писали:

IT>>Мои поздравления! Мальчик, девочка?

GZ>Девочка 3700x51

П-О-З-Д-Р-А-В-Л-Я-Ю!!!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Мое проектирование и рефакторинг
От: VladGalkin Украина  
Дата: 17.02.06 08:52
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Девочка 3700x51

Мои широкие поздравления.
... << RSDN@Home 1.1.4 stable rev. 510>>
ДЭ!
Re[8]: Мое проектирование и рефакторинг
От: GlebZ Россия  
Дата: 17.02.06 14:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

GZ>>PS. Пока писал код, позвонили, узнал что стал уже дважды отцом.
S>Двойняшки?
Типун тебе на язык. Второй.
Re[9]: Мое проектирование и рефакторинг
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.02.06 14:06
Оценка:
Здравствуйте, GlebZ, Вы писали:

S>>Двойняшки?

GZ>Типун тебе на язык.

Теперь-то чего? Или боишься, что перезвонят с уточнением?

GZ>Второй.


Молодца!!!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.02.06 07:53
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если четких требований нет, то их необходимо изобрести, предложить...


Зачем? Чтобы лишнюю работу сделать?

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


Это эксперименты не только программиста. В них заказчик тоже участвует.

V> Последнее работает только для каких-нибудь вещей, типа неординарных/исследовательских проектов, чаще всего из области разработки инструментария (то бишь системного софта/библиотек).


Последнее работает даже на самых рядовых проектах, проверено.

AVK>>Правда есть одна область, где действительно приходится отладчиком часто пользоваться — при разработке расширения студии. Только вот проблема при этом не в дотнете, а в крайней убогости документации.


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


В случае .NET документация по фреймворку на 2 головы выше. Кроме того фреймворк всегда можно декомпилировать.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[18]: Философический вопрос про автоматический вывод типов
От: EXO Россия http://www.az.inural.ru
Дата: 26.02.06 04:23
Оценка:
Здравствуйте, AndrewVK, Вы писали:
V>>Если четких требований нет, то их необходимо изобрести, предложить...
AVK>Зачем? Чтобы лишнюю работу сделать?

Потому, что иначе это будет делать каждый программист "в процссе".
В результате о концептуальной целостности проекта можно будет забыть...
Re[19]: Философический вопрос про автоматический вывод типов
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.06 09:12
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Потому, что иначе это будет делать каждый программист "в процссе".

EXO>В результате о концептуальной целостности проекта можно будет забыть...

Т.е. архитектор, после создания архитектуры на начальном этапе, от проекта самоустраняется?
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[20]: Философический вопрос про автоматический вывод типов
От: vdimas Россия  
Дата: 27.02.06 09:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


EXO>>Потому, что иначе это будет делать каждый программист "в процссе".

EXO>>В результате о концептуальной целостности проекта можно будет забыть...

AVK>Т.е. архитектор, после создания архитектуры на начальном этапе, от проекта самоустраняется?


Если нет, то бишь, если каждый программист в процессе получает вполне однозначные требования на разработку текущих участков функциональности, то... это выглядит скорее как согласие с нашей позицией
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.