Здравствуйте, eao197, Вы писали:
GZ>>Что-то вас господа занесло. Один апологет XP, другой водпадов.
E>Не, я не водопада апологет. А так... серии маленьких водопадиков.
Что характерно, эта метафора намного ближе к описанию итеративного процесса, чем аморфный режим "постоянного рефакторинга". Последняя метафора страдает концентрацией на коде, а не на результате. В случае же полного (хотя и короткого) цикла (проектирование — реализация — документирование — тестирование — выпуск) жизнь проекта "полнее", и всевозможные "глюки" вылавливаются в большей мере, чем в случае хронического "зависания" на стадии реализации в виде "постоянного рефакторинга". То же проектирование нужно в т.ч. и для организации тестирования и "прикормки" documentation writers.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, GlebZ, Вы писали: GZ>Здесь упоминается только то, как я работаю один.
:Жму лапу. Уровень саморефлексии на высоте.
GZ>Этап 1. Думаю. GZ>Я думаю над тем что я хочу сделать.
Я на этом этапе предпочитаю гулять где-нибуддь по парку... чтобы ногами перебирать. Чтобы окружающий мир разными сторонами поворачивался...
GZ> Во первых, нужно ли это делать. Процентов 90 именно на этом этапе и заканчивается.
!!!!!
Только у меня это два этапа. (или даже 3)
1а) Какие (и чьи) задачи задачи собираемся решать. То есть чеко определить субъект интереса (или надсистеу) и задачи этого субъекта в его собственной системе ценностей.
1б) Можно ли решить эти задачи ничего не разрабатывая (тот самый предельный случай — ни одной строчки кода).
1в) Хочу ли лично я этим заниматься и почему.
GZ> И во вторых, что это должно быть. Это не архитектура. Это действия пользователей(будем говорить сценарии).
1е) ... частично становится ясным на этапе 1б. Но дествительно требует возвращения и более детальной проаботки — отдельного этапа.
GZ> При этом я придумываю эти действия пользователей. Чаще все рождается и остается в голове, если не умещается и вещь непростая в тетрадке. (кои всегда с собой). Но я не в коем случае не думаю как я это сделаю. Не дай бог, хотя бы одним нейроном подумать об архитектуре. Тогда картина вырисовывается, и получается решение которое легко сделать. А оно ошибочное, лучше думать о действиях пользователя или системы, или утилиты. Как только подумал об архитектуре не доработав действия, то можно считать проект пропал. Это самое сложное для меня. И за этим занятием я провожу большую часть проекта.
GZ>Этап 2. Сажусь за компьютер. С первыми строчками кода, типа void main(){} в голове уже лежит архитектура. Я ее как-то уже давно не придумываю. Она сама рождается.
Вот здесь начинаются расхождения. Архитектуру я рисую. Черкаюсь.
На этом этапе я не нашел пока адекватной замены бумаге.
Но рисую вовсе не классы, а "компаненты", процессы, модули. И потоколы между ними.
То есть декомпозицию задачи на подсистемы. Стараюсь получить их "слабосвязанность".
А дальше — для каждой отдельной подсистемы уже берусь за объетное проектирование. Например — через дерево классов. И это да — если возможно, в среде разработки. С удовольствием задействую все красивости и удобства.
Но этот этап (и остальные до резултата) у меня занимает уже около четверти времени.
Re[18]: Философический вопрос про автоматический вывод типов
Здравствуйте, VladD2, Вы писали:
VD>Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.
Давай уточним постановку задачи. Если вымыться хочешь лично ты, то это одна задача. А если к тебе приходит заказчик и говорит, что он хочет вымыть 150 человек за день и заплатить за это N (естественно, N < K) рублей, то выбор ванны в качестве способа мытья может отпасть сам собой после некоторого проектирования.
VD>Позволь обратить твое внимание, на то что одним из основных посылов наших повествований как раз был посыл говорящий о том, что к сожалению на стадии проектирования (если конечно речь не идет о 225-ой итерации допроектирования в итерациооном процессе) болшая часть трудностей просто щее не известна. Полное проектирование с нуля и целиком в таких условиях скорее самхивает на профанацию.
VD>Так что рассказ о грамотном проектировании предовтвращающем большую часть проблем заранее для меня выглядит сказачно.
Я в очередной раз пытаюсь привлечь внимание к учету предметных областей, в которых идет работа. В каких-то из них стадию дотошного проектирования провести действительно нельзя. Вот сейчас я и мой коллегой пытаемся придумать удобный для операторов способ мониторинга событий в server-side приложении. Мы толком сами не знаем, что нужно сделать, так же, как этого не знают операторы. Они говорят -- хотим, что бы было удобнее, чем есть сейчас. Естественно, на вопрос "как именно?", они ничего сказать не могут. Поэтому вся работа выглядит как последовательность разрабатываемых, демострируемых и перерабатываемых прототипов. Именно прототипов, чтобы поймать и выкрилистовать идею, которой пока нет. Понятно, что в данной задаче ни о каком проектировании (с большой буквы) не идет речи. Максимум -- это попытка представить на бумаге, как будет выглядеть окно мониторинговой панели.
С другой стороны, я сейчас делаю в mxx_ru поддержку VS2005 и манифестов для exe и dll целей. Здесь понятно, что должно быть сделано. Не понятно как именно. Самый важный вопрос -- как пользователь будет описывать, какую помощь от mxx_ru он хочет получить при работе с манифестами. И здесь без проектирования, мне кажется, нет смысла начинать кодировать. Только когда станет точно ясно, что конкретно будет видеть пользователь и какие возможности будет предоставлять mxx_ru -- тогда уже не составит труда это запрограммировать просто в лоб.
И еще один пример. Добавление возможности индексации информации в ObjESSty. Вот такая простенькая формулировка. Можно просто брать и писать заглушки методов...
Очень завидую тем, кто сможет с ходу, без проектирования, путем написания и рефакторинга кода эту задачу решить. Потому что у меня не получается. Даже не нашел пока достаточного количества времени, чтобы обдумать большинство вопросов, связанных с этой темой и лежащих на поверхности.
ИМХО, индивидуальный подход нужен к каждой задаче. Но не слова вроде "сказачно" или "профанация".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, EXO, Вы писали:
EXO>Ты не прав, IMHO. Мне было очень интересно и полезно почитать некоторые из здешних сообщений. EXO>Я даже отфорвардил линк ребяам из команды, с предложением вынести эту тему на очередную "философскую пятницу" (периодическое собрание-обсуждение ситуации в отрасли... в вольном формате).
После таких слов возникает приступ графоманства и хочется написать статью 'Как я программирую на бумаге'
А IT с VladD2 и WolfHound-ом сделают симметричный ответ: 'Как мы программируем в IDE' с подзаголовком 'Бумага должна использоваться по прямому назначению в другом месте'
Не хотел никого обижать, просто пошутил.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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. Такие процессы мне очень не нравятся. Обычно это писанина компонентов которые уже есть в голове, и элементарно выводящиеся из прецедентов и предметной области.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Что характерно, эта метафора намного ближе к описанию итеративного процесса, чем аморфный режим "постоянного рефакторинга". Последняя метафора страдает концентрацией на коде, а не на результате.
Хотелось бы намекнуть, что рефакторинг — это улучшение кода не влияя на функциональность. И он мало зависит от процесса разработки. Просто в ХП она обязательная дисциплина.
ПК>В случае же полного (хотя и короткого) цикла (проектирование — реализация — документирование — тестирование — выпуск) жизнь проекта "полнее", и всевозможные "глюки" вылавливаются в большей мере, чем в случае хронического "зависания" на стадии реализации в виде "постоянного рефакторинга".
Нет. По случаям глюков могу сказать что ХП дает менее глючный код. И рефакторинг с TDD положительно влияет. Но основная проблема в несоответсвии требований пользователей и результатом. Если при тебе нет представителя клиента, у которого можно что-то спросить не отходя от кассы, получается полная фигня. Если имеются функциональные требования, то их можно утвердить у заказчика, и даже если в результате получится фигня, всегда можно сослаться на подпись.
ПК>То же проектирование нужно в т.ч. и для организации тестирования и "прикормки" documentation writers.
Для тестирования и documentation writers в основном полезны прецеденты написанные аналитиками а не архитекторами.
Здравствуйте, eao197, Вы писали:
GZ>>Что-то вас господа занесло. Один апологет XP, другой водпадов. E>Не, я не водопада апологет. А так... серии маленьких водопадиков.
Я как-то побоялся называть разработку итерационной, поскольку все процессы разработки в современном мире итерационные.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, EXO, Вы писали:
EXO>Ты не прав, IMHO. Мне было очень интересно и полезно почитать некоторые из здешних сообщений.
Ключевое слово некоторые. Но засилие откровенных понтов и бссмысленого перетирания превращают форум в пустой базар.
VD>>Такой смысл создавать письмо на 4 экрана если вся его суть заключается в мысли — "все ламеры, а я тут один на белом коне..."?
EXO>А можешь предположить, что все остальное ты просто не видишь?
А можешь предположить, что видить нечего?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Философический вопрос про автоматический вывод типов
E>После таких слов возникает приступ графоманства и хочется написать статью 'Как я программирую на бумаге' E>А IT с VladD2 и WolfHound-ом сделают симметричный ответ: 'Как мы программируем в IDE' с подзаголовком 'Бумага должна использоваться по прямому назначению в другом месте' E>Не хотел никого обижать, просто пошутил.
А в этом ничего обидного лично я не вжиу. Наоборот дельное предложение разбавленное юмором.
Вот когда общение ведтся в стиле "Хинты: тебе надо подучиться...", вот это раздражает.
Пожалуй действительно имеет смысл описать процесс разработки. Вот только пример нужен.
Хотя это нужно для вас. Как бы с бумажкой мы и сами имеем. Раньше по другому и не удавалось.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Философический вопрос про автоматический вывод типов
Здравствуйте, eao197, Вы писали:
E>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?
Строго говоря — требование к базовым интерфейсам меняться как можно реже проистекает из единственного факта — необходимости делать согласование с изменениями в использующем коде. В случае наличия рефакторинга, если конечно базовые интерфейсы не смотрят наружу проекта, проблемы согласования снимаются, следовательно снимается и вышеозначенное требование.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Навскидку несколько нетехнических причин неприятия. Первая: если в "принципы" нужно поверить, то это уже не принципы а догмы. Вторая: объяснения зачастую состоят из передёргиваний и подмены понятий, а зачастую и из бессвязно-восторженных речей. Последнее свойственно, например, твоим постингам (уж извини). Третья: нередки попытки тем или иным образом унизить э... "представителей старого мира", что естественным образом провоцирует неприятие и оратора и того, о чём он орёт.
До сюда был согласен.
ГВ> Четвёртая: подозрительная корреляция рассуждений провозвестников нового с тем, что делает 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>>
Здравствуйте, vdimas, Вы писали:
V>Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.
Это не байндинг, это особенности работы ReflectPropertyDescriptor.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, vdimas, Вы писали:
V>Вообще-то проектирование — это далеко не только спецификация публичных и защищенных интерфейсов типов... Проектирование начинается с use-cases, и вот в этом вопросе никакой Решарпер и никакая студия тебе не помогут.
use cases это здорово и круто, когда исходные требования заранее известны. А на практике это частенько не так.
V>Признайтесь, вы все часто используете пошаговую отладку на дотнете...
Признаюсь — нет. Более того, частенько у меня хватает наглости закоммитить код в репозиторий, просто убедившись что он компилируется. Обычно прокатывает . Правда есть одна область, где действительно приходится отладчиком часто пользоваться — при разработке расширения студии. Только вот проблема при этом не в дотнете, а в крайней убогости документации. Так и у тебя скорее всего — видимо задачка неприятная попалась.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, GlebZ, Вы писали:
ПК>>Что характерно, эта метафора намного ближе к описанию итеративного процесса, чем аморфный режим "постоянного рефакторинга". Последняя метафора страдает концентрацией на коде, а не на результате.
GZ>Хотелось бы намекнуть, что рефакторинг — это улучшение кода не влияя на функциональность. И он мало зависит от процесса разработки. Просто в ХП она обязательная дисциплина.
XP не отвергает выделенного этапа проектирования и планирования, и даже наоборот, в классике предполагает наличие в начале каждой итерации выделенное планирование, iteration planning meeting, и выделенный этап проектирования, основанный на использовании CRC Cards. Как мы уже разобрались выше и ранее, режим "постоянного рефакторинга" в трактовке Влада (т.е. произвольные модификации кода с помощью инструментальных средств IDE, обычно без unit tests) принципиально отличается от рефакторинга в трактовке XP, который, действительно, принципиально не изменяет функциональность.
ПК>>В случае же полного (хотя и короткого) цикла (проектирование — реализация — документирование — тестирование — выпуск) жизнь проекта "полнее", и всевозможные "глюки" вылавливаются в большей мере, чем в случае хронического "зависания" на стадии реализации в виде "постоянного рефакторинга".
GZ>Нет. По случаям глюков могу сказать что ХП дает менее глючный код. <...>
Ну началось... XP и прочие модные итерационные процессы как раз построены по схеме, упомянутой выше (полные, но короткие циклы, включающие в т.ч. (коллективное) планирование и проектирование ближайшей итерации).
P.S. Интересно, на основании чего ты воспринял метафору "серии маленьких водопадиков" как противоречащую XP и т.п.? Уж не из-за того, что встретил слово "водопадик"?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
с подзаголовком 'Бумага должна использоваться по прямому назначению в другом месте' 
Если нам не помогут, то мы тоже никого не пощадим.
