Здравствуйте, Аноним, Вы писали:

А>И также определится с форматом написания кода, чтобы код был самодокумнтированым.

Вот жертва документации:



Взято отсюда

Это дурная идея смешивать код с документацией.

Здравствуйте, Аноним, Вы писали:

А>прошу сильно не пинать меня. буду очень благодарен за любую информацию

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

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

M>Здравствуйте, Аноним, Вы писали:

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

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

Глупость, ИМХО.
Во-первых, рефакторинг — это не реинжиринг, не надо путать понятия! Если меняется интерфейс класса, то это с натяжкой можно назвать рефакторингом кода.
Во-вторых, рисовать и еще рисовать. Т.к. то что можно изображить картинкой, порой можно описать только на нескольких страницах.
В-третьих, документация необходима! Главное правильно выбрать степень детализации. Составить небольшой документ с описание функционала и возможностей. И также определится с форматом написания кода, чтобы код был самодокумнтированым.

С уважением,
bw.

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

L>После чтения Лармана у меня почему-то сформировалось иное мнение.
После первого прочтения по RUP, я был вне себя от счастья. Ну что нужно разработчику, написать требования, и рисовать, рисовать, рисовать. Потом две строчки кода, тестинг на требования, и все all right. Там и думать ничего не надо. Все прописано. Но даже в первом приближении оказалось, что выполнять дословно все предписания (и даже учитывая рекомендации о приблизительности) безнадежное дело. К тому же переходы от концептуальной модели к логической, а потом и физической — сильно эвристичны. Как бы голову разработчику никто не отменял. Ну а если нужно написать программу которая выводит результат 2*2=4, то столько писанины, мама не балуйся.
Потом, прочитал про XP. Все, this is the best. Разрешено просто писать 2*2=4. Только опыт подсказывал, что не все так уж отлично. А не отлично то, что предыдущий опыт показывал степень бардака, который устанавливается в крупных группах. Когда программист не знает что делает его сосед. Поэтому, если группа большая, то распространение информации на каждого участника просто невозможна. А ведь нужно чтобы каждый участник не просто знал бизнес-процессы. Он должен знать бизнес-процессы своих соседей и мог общаться с его кодом. Ну и плюс — разработка требований. Наличие плотного общения с заказчиком, не всегда возможно. И этот заказчик, должен быть дока во всех аспектах требований. Зачастую, заказчик — это группа заинтересованных лиц от нескольких отделов предприятия. Разработка и утверждение требований — слишком важный процесс не только с точки зрения разработчика, но и с коммерческой точки зрения(потом будет сильно больно если не видно этой важности).
Поэтому, я считаю что лучшей книгой является книга Брукса. И его утверждение — серебрянной пули нет. И модель разработки (а зачастую смесь различных практик) должен выбираться конкретно под проект и комманду.

С уважением, Gleb.

Здравствуйте, Аноним, Вы писали:

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

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

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

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

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

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

GZ>Визуальные средства (типа Class или Case Diagram), нужны только для того, чтобы распространить знания о предполагаемом или готовом продукте между заинтересованными сторонами.

Да, и забыл добавить: далеко не всё в приложении есть код. Визуальных средств обычно не хватает на всё.

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

GZ>Хотя в данном случае, нужно еще объяснить что такое модульное тестирование. Так как, без этого рефакторинг невозможен(или можно сказать вреден).

Глупости вы говорите. Юнит-тестирование не панацея, хуже того, в некоторых случаях от него пользы практически нет.

решил написать программу на платформе .net, имея небольшой опыт насписания простых программ. возникли наверное дурацкие вопросы, прошу по возможности поправить мой кретинизм:
1) насколько применимы многие известные паттерны к данной платформе (во многих описаниях даны частичные реализации на языке c++)
2) какие книги есть по проектированию для платформы .net, если есть специализированные
3) поскольку программа будет состоять из одного небольшого приложения и кучи модулей — какие пожходы или статьи можно почитать?

прошу сильно не пинать меня. буду очень благодарен за любую информацию

Здравствуйте, Аноним, Вы писали:

А>1) насколько применимы многие известные паттерны к данной платформе (во многих описаниях даны частичные реализации на языке c++)

Шаблоны проектирования aka паттерны не зависят от языка (конечно, подойдет не любой язык вообще, а лишь ОО-язык). А в книгах примеры даются на С++ (кстати в GoF еще и Smalltalk есть...) потому, что данный язык наиболее часто используется для разработки сложных систем; а паттерны, собственно, и существуют для решения возникающих при этом проблем. Поскольку С# честно содрали с Java/С++, то "многие известные паттерны к данной платформе" применимы

А>3) поскольку программа будет состоять из одного небольшого приложения и кучи модулей — какие пожходы или статьи можно почитать?

Тут где-то была статья, как раз о проектировании модульного приложения, что-то типа "Практика использования паттернов"... правда, там пример на Delphi

Здравствуйте, Аноним, Вы писали:


А>прошу сильно не пинать меня. буду очень благодарен за любую информацию

Книги
http://www.rsdn.ru/res/book/oo/design_patterns.xml

Автор(ы): Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес
В предлагаемой книге описываются простые и изящные решения типичных задач,
возникающих в объектно-ориентированном проектировании. Паттерны появились
потому, что многие разработчики искали пути повышения гибкости и степени
повторного использования своих программ. Найденные решения воплощены в краткой и
легко применимой на практике форме. Авторы излагают принципы использования
паттернов проектирования и приводят их каталог. Таким образом, книга
одновременно решает две задачи. Во-первых, здесь демонстрируется роль паттернов
в создании архитектуры сложных систем. Во-вторых, применяя содержащиеся в
справочнике паттерны, проектировщик сможет с легкостью разрабатывать собственные
приложения. Издание предназначено как для профессиональных разработчиков, так и
для программистов осваивающих объектно-ориентированное проектирование.

http://www.rsdn.ru/res/book/prog/architect.xml

Автор(ы): Мартин Фаулер

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

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

M>Сначала напиши программу (хоть чучелом, хоть тушкой), а потом уже будешь думать об архитектуре. Без опыта спроектировать приложение тебе не удастся, даже если ты 20 книжек прочитаешь. Постоянный рефакторинг поможет тебе ухватить паттерны, возникающие в коде, а уж потом можно подогнать под это дело науку, GoF там, или Fowler-а.

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

Здравствуйте, Аноним, Вы писали:

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

M>>Сначала напиши программу (хоть чучелом, хоть тушкой), а потом уже будешь думать об архитектуре. Без опыта спроектировать приложение тебе не удастся, даже если ты 20 книжек прочитаешь. Постоянный рефакторинг поможет тебе ухватить паттерны, возникающие в коде, а уж потом можно подогнать под это дело науку, GoF там, или Fowler-а.

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

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

С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

А>Глупость, ИМХО.
А>Во-первых, рефакторинг — это не реинжиринг, не надо путать понятия! Если меняется интерфейс класса, то это с натяжкой можно назвать рефакторингом кода.
Рефактороинг может не только менять интерфейс класса, но и вообще удалять классы либо создавать новые. Рефакторинг — улучшение кода не изменяющее его функциональность. Хотя в данном случае, нужно еще объяснить что такое модульное тестирование. Так как, без этого рефакторинг невозможен(или можно сказать вреден).
А>Во-вторых, рисовать и еще рисовать. Т.к. то что можно изображить картинкой, порой можно описать только на нескольких страницах.
Хорошее дело рисовать. Рисовать но не перерисовывать. На рисунке могут быть только предположения об архитектуре. А там, что получится, то получится.
А>В-третьих, документация необходима! Главное правильно выбрать степень детализации. Составить небольшой документ с описание функционала и возможностей. И также определится с форматом написания кода, чтобы код был самодокумнтированым.
Нужно понимание цели. Именно для этого делается постановка. Если цель небольшая и народу в реализацию вовлечено немного, то документация может быть сделана постфактум. Это нормальная практика XP.

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

С уважением, Gleb.

Здравствуйте, Аноним, Вы писали:

А>Во-первых, рефакторинг — это не реинжиринг, не надо путать понятия! Если меняется интерфейс класса, то это с натяжкой можно назвать рефакторингом кода.

Redesign — изменение уже существующего дизайна (то есть уже есть приложение)
Refactoring — изменение кода (в случае отсутствия готового приложения сюда попадает всё, что угодно)

А>Во-вторых, рисовать и еще рисовать. Т.к. то что можно изображить картинкой, порой можно описать только на нескольких страницах.

Ручка, тетрадка и вперёд. Но это только для того, чтобы выражать мысли. Система должна быть в голове. Целиком, иначе ты её просто не понимаешь.

А>В-третьих, документация необходима! Главное правильно выбрать степень детализации. Составить небольшой документ с описание функционала и возможностей. И также определится с форматом написания кода, чтобы код был самодокумнтированым.

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

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

GZ>Хотя в данном случае, нужно еще объяснить что такое модульное тестирование. Так как, без этого рефакторинг невозможен(или можно сказать вреден).
а можно поподробней зачем оно нужно?

GZ>С уважением, Gleb.

Здравствуйте, <Аноним>, Вы писали:
А>а можно поподробней зачем оно нужно?
Одна из практик XP. Сначало пишется тест — в котором есть входящие параметры, и выходные параметры (то есть что ты хочешь получить в результате) и проверка всего этого.
Потом пишется код, с макимально простым дизайном. Чтобы тест заработал.
На третьем этапе рефакторинг. Модификация кода что бы он был более гибким, расширяемым и не имел повторяющихся блоков. При любой модификации, код прогоняется через тест, чтобы точно знать не поломал ли ты что-нибудь.
За подробностями в любую книжку по XP.

С уважением, Gleb.

А>>Глупость, ИМХО.
А>>Во-первых, рефакторинг — это не реинжиринг, не надо путать понятия! Если меняется интерфейс класса, то это с натяжкой можно назвать рефакторингом кода.
GZ>Рефактороинг может не только менять интерфейс класса, но и вообще удалять классы либо создавать новые. Рефакторинг — улучшение кода не изменяющее его функциональность. Хотя в данном случае, нужно еще объяснить что такое модульное тестирование. Так как, без этого рефакторинг невозможен(или можно сказать вреден).
Так я об этом же. Только я говорю, о рефакторинге класса, а ты говоришь о рефакторинге модуля.
Т.е. для внешнего потребителя поведение не должно измениться, а меняется внутреннее содержание.
Если расссматривать класс как некий законченный продукт, то его интерфейс не должен менятся для внешнего потрибителя во время рефакторинга.

А>>Во-вторых, рисовать и еще рисовать. Т.к. то что можно изображить картинкой, порой можно описать только на нескольких страницах.
GZ>Хорошее дело рисовать. Рисовать но не перерисовывать. На рисунке могут быть только предположения об архитектуре. А там, что получится, то получится.
Рисовать, и перерисовывать столько сколько нужно!!! Более развернутый ответ в посте для Mishka.

А>>В-третьих, документация необходима! Главное правильно выбрать степень детализации. Составить небольшой документ с описание функционала и возможностей. И также определится с форматом написания кода, чтобы код был самодокумнтированым.
GZ>Нужно понимание цели. Именно для этого делается постановка. Если цель небольшая и народу в реализацию вовлечено немного, то документация может быть сделана постфактум. Это нормальная практика XP.
Интересно, а для чего документация пост-фактум? Перечитывать в старости.
Некий набор документации должне быть до начала разработки. Это набор может меняться в ходе разработки.
И конечно по окончанию разработки, нужно иметь акктуальный набор документации.
Нужно все это, чтобы провести анализ процесса и сделать работу над ошибками.

GZ>Однако должен все-таки сказать, что практики XP и в том числе рефакторинг предполагает наличие хотя-бы одного проффесионального разработчика который может оценить качество кода. Иначе от неправильного рефакторинга будет только вред.
Вопрос не по теме: сколько из практик XP внедрены у вас в конторе/проекте?

С уважением,
bw.

А>>Во-первых, рефакторинг — это не реинжиринг, не надо путать понятия! Если меняется интерфейс класса, то это с натяжкой можно назвать рефакторингом кода.

M>Redesign — изменение уже существующего дизайна (то есть уже есть приложение)
M>Refactoring — изменение кода (в случае отсутствия готового приложения сюда попадает всё, что угодно)

А>>Во-вторых, рисовать и еще рисовать. Т.к. то что можно изображить картинкой, порой можно описать только на нескольких страницах.
M>Ручка, тетрадка и вперёд. Но это только для того, чтобы выражать мысли. Система должна быть в голове. Целиком, иначе ты её просто не понимаешь.
Можно также использовать молоток, зубило и делать наскальные рисунки. Зачем использовать устаревшие технологии?
Или каждый человек от ИТ должен в совершенстве владеть навыками черчения и рисования?
Целиком в голове это конечно. Но только в силу нейрофизилогии человека все и вся он просто не состоянии обозреть и удержать в голове, в случаи даже средних проектов. Поэтому нужно создавать некие артефакты, которые помогут в работе мозга. Ни говоря уже о передаче знаний другому участнику проекта и т.п.

А>>В-третьих, документация необходима! Главное правильно выбрать степень детализации. Составить небольшой документ с описание функционала и возможностей. И также определится с форматом написания кода, чтобы код был самодокумнтированым.
M>Документация вредна для здоровья. Во-первых, она отнимает уйму времени, во-вторых писать документацию не интересно, в-третьих, она устаревает очень быстро и поддерживать её муторное занятие, в-четвёртых, читать её никто не будет, в-пятых, если кто-то читает твою документацию, то ты в этой фирме уже не работаешь, и поэтому тебе должно быть всё равно.

Во-первых, тестирование тоже отнимает уйму времени.
Во-вторых, работать тоже не интересно, ведь интерсно получать деньги.
В-третьих, она(документация) устаривает не быстрее, чем скрипты для тестирования.
В-четвертых, не судите о людях по себе. Вы != никто. Я читаю.
В-пятых, вы дорожите своей репутацией?


А>>И также определится с форматом написания кода, чтобы код был самодокумнтированым.
M>Вот жертва документации:
M>Это дурная идея смешивать код с документацией.
И вообще писать документации вредно.

Здравствуйте, <Аноним>, Вы писали:

А>Рисовать, и перерисовывать столько сколько нужно!!! Более развернутый ответ в посте для Mishka.
Сколько не рисуй, при реализации мечты остаются мечтами. А жизнь показывает другие позы для продукта. Рисовать (или что-то типа SRC — карт) следует делать только при сложных и малопонятных алгоритмах. Иначе ты будешь заниматься работой, от которой пользы ноль.

GZ>>Нужно понимание цели. Именно для этого делается постановка. Если цель небольшая и народу в реализацию вовлечено немного, то документация может быть сделана постфактум. Это нормальная практика XP.
А>Интересно, а для чего документация пост-фактум? Перечитывать в старости.
А>Некий набор документации должне быть до начала разработки. Это набор может меняться в ходе разработки.
А>И конечно по окончанию разработки, нужно иметь акктуальный набор документации.
А>Нужно все это, чтобы провести анализ процесса и сделать работу над ошибками.
Ну конечно если она нужна. Если программа никому не нужна, то и документация на фиг не сдалась.
Что касается набора документации до начала кодирования, то это присуще только большим системам построенным на основе MSF или RUP, с несколькими специализированными группами и отделами (тестирования, аналитика и т.д.) и с продолжительными итерациями. В случае небольшой системы, потеря времени на подготовку документации (по структурному, логическому а потом и физическому дизайну) считаю излишней. Слишком много времени на это угрохаешь. При том, что все таки не каждый программист может нормально написать на русском языке прецедент.

GZ>>Однако должен все-таки сказать, что практики XP и в том числе рефакторинг предполагает наличие хотя-бы одного проффесионального разработчика который может оценить качество кода. Иначе от неправильного рефакторинга будет только вред.
А>Вопрос не по теме: сколько из практик XP внедрены у вас в конторе/проекте?
Группа с которой я сейчас работаю, работает над большими проектами уровня корпорации. Использование XP — в таких проектах не эффективно. Постановка практически полный RUP.

С уважением, Gleb.

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

GZ>Ну конечно если она нужна. Если программа никому не нужна, то и документация на фиг не сдалась.
GZ>Что касается набора документации до начала кодирования, то это присуще только большим системам построенным на основе MSF или RUP, с несколькими специализированными группами и отделами (тестирования, аналитика и т.д.) и с продолжительными итерациями. В случае небольшой системы, потеря времени на подготовку документации (по структурному, логическому а потом и физическому дизайну) считаю излишней. Слишком много времени на это угрохаешь.
Есть еще и ГОСТ Только это здесь не при чем.
Технология процесса одно, а построение архитектуры несколько иное.
GZ>При том, что все таки не каждый программист может нормально написать на русском языке прецедент.
Таки рисование спасеть отца русской демократии в начале его пути

А>>Вопрос не по теме: сколько из практик XP внедрены у вас в конторе/проекте?
GZ>Группа с которой я сейчас работаю, работает над большими проектами уровня корпорации. Использование XP — в таких проектах не эффективно. Постановка практически полный RUP.
Т.е. я так понимаю, что вы являетесь теоретиком XP. Хотя я думаю, что если поднапрячься, то и у вас в проекте можно выявить несколько практик XP. Извините, но я не знанок RUP.
А насколько большие проекты? И вообще рассматривалась XP в качестве определяющей технологие построения технологичекого процесса?

С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

А>Есть еще и ГОСТ Только это здесь не при чем.
А>Технология процесса одно, а построение архитектуры несколько иное.
Взимосвязанные понятия. В зависимости от технологии процесса, разные процессы построения архитектуры а в оссобенности дизайна.
GZ>>При том, что все таки не каждый программист может нормально написать на русском языке прецедент.
А>Таки рисование спасеть отца русской демократии в начале его пути
Нет. После десятого прецедента сразу же поймешь, что UML хорош в меру. Word более продуктивен.

А>>>Вопрос не по теме: сколько из практик XP внедрены у вас в конторе/проекте?
GZ>>Группа с которой я сейчас работаю, работает над большими проектами уровня корпорации. Использование XP — в таких проектах не эффективно. Постановка практически полный RUP.
А>Т.е. я так понимаю, что вы являетесь теоретиком XP.
Нет, но спасибо за такие слова. А вот Фаулер является общепризнанным теоретиком XP. Здесь. Читайте, наслаждайтесь.
А>Извините, но я не знанок RUP.
Зря. Советую ознакомится.
А>А насколько большие проекты? И вообще рассматривалась XP в качестве определяющей технологие построения технологичекого процесса?
Нет. При сложных, комплексных решениях XP не рулят. Если весьма интересно почему, почитайте Коуберна. У него более интересные идеи чем слепое следования XP.

С уважением, Gleb.
PS: просьба. Зарегистрируйтесь, пожалуйста. Я не против анонимов. Просто очень неудобно общашься сразу с несколькими анонимами. Начинаешь путаться.

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

GZ>Здравствуйте, <Аноним>, Вы писали:

А>>Рисовать, и перерисовывать столько сколько нужно!!! Более развернутый ответ в посте для Mishka.
GZ>Сколько не рисуй, при реализации мечты остаются мечтами. А жизнь показывает другие позы для продукта. Рисовать (или что-то типа SRC — карт) следует делать только при сложных и малопонятных алгоритмах. Иначе ты будешь заниматься работой, от которой пользы ноль.

Рисовать иногда не просто полезно, но и выгодно. Вообще визуально (если знаком со спецификацией языка моделирования) информация о структурных зависимостях, напрмер, отраженная в "игровом" поле формата А3 +дополненная разного рода ограничениями, пояснениями... При "рисовании" такого начинаешь лучше понимать что рисуешь.
При том современные средства прямого и обратного инжиниринга позволяют создавать и перестраивать архитектуру без особых потерь (времени в частности). Тот же "убогий", как некоторые считают, ModelMaker предоставляет средства кодогенерации, рефакторинга, реинжирининга, визульного моделирования, реализации паттернов и пр. — остается только вписать реализацию.
Визуальное моделирование — рулез!!!

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

N>Рисовать иногда не просто полезно, но и выгодно. Вообще визуально (если знаком со спецификацией языка моделирования) информация о структурных зависимостях, напрмер, отраженная в "игровом" поле формата А3 +дополненная разного рода ограничениями, пояснениями... При "рисовании" такого начинаешь лучше понимать что рисуешь.
Рисуйте на здоровье. Кто-бы возражал. Но всегда стоит помнить, что человек предпологает, а бог распологает. Не бывает того, чтобы не то что физический, логический в первой версии совпадал с тем, что получится в результате (по крайней мере у меня не было прецедентов). Для того, чтобы не погрязнуть сразу в мелочах и тем остановить проект(что является частой ошибкой, когда начинают продумывать сначало мелочи (в большистве своем неверные) а потом уже приступают ко всему проекту, если не останавливаются на предыдущем этапе) система разбивается на вполне понятные модули и этапы их выполнения. По мере реализации модулей (и влезание в их мелочи), нужная структура программы становится все более понятной. При этом и уточняются нужные модули.

N>При том современные средства прямого и обратного инжиниринга позволяют создавать и перестраивать архитектуру без особых потерь (времени в частности). Тот же "убогий", как некоторые считают, ModelMaker предоставляет средства кодогенерации, рефакторинга, реинжирининга, визульного моделирования, реализации паттернов и пр. — остается только вписать реализацию.
N>Визуальное моделирование — рулез!!!
Это потому, что вы не писали больших программ с помощью этого инструмента. Недельки через две, вы уже не будете на него обращать внимание. И структура программы значительно изменится от той которую вы предполагали. Опа, и оказалось что кодогенерация уже не нужна. Средства автоматического рефакторинга, к визуалке отношения не имеют. Средства реинжиниринга, я вообще не понимаю как такое может быть. Если у тебя проблема обнаружилась в концепции, то тут уже ничего не поможет. Только ручки, голова и итерации.

Визуальные средства (типа Class или Case Diagram), нужны только для того, чтобы распространить знания о предполагаемом или готовом продукте между заинтересованными сторонами.

С уважением, Gleb.

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

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

N>>Рисовать иногда не просто полезно, но и выгодно. Вообще визуально (если знаком со спецификацией языка моделирования) информация о структурных зависимостях, напрмер, отраженная в "игровом" поле формата А3 +дополненная разного рода ограничениями, пояснениями... При "рисовании" такого начинаешь лучше понимать что рисуешь.
GZ>Рисуйте на здоровье. Кто-бы возражал. Но всегда стоит помнить, что человек предпологает, а бог распологает. Не бывает того, чтобы не то что физический, логический в первой версии совпадал с тем, что получится в результате (по крайней мере у меня не было прецедентов). Для того, чтобы не погрязнуть сразу в мелочах и тем остановить проект(что является частой ошибкой, когда начинают продумывать сначало мелочи (в большистве своем неверные) а потом уже приступают ко всему проекту, если не останавливаются на предыдущем этапе) система разбивается на вполне понятные модули и этапы их выполнения. По мере реализации модулей (и влезание в их мелочи), нужная структура программы становится все более понятной. При этом и уточняются нужные модули.

Извините, но это уже структурное программирование, а, если я не ошибаюсь, речь о ООП. Как можно говорить о модулях в принципе? Классы, компоненты и пакеты — основные значимые структурные сущности. Как они ранжируются по модулям — на сегодня дело вкуса и языка ООП. Конечно логически можно представить модуль как некую законченную сущность — в частности как представление collaboration, но это не обязательно. Если вернуться к вопросу, то ни о каком модульном программировании и речи быть не может. В .NET все строго упаковано в классы.
Скажите, вы так вот слету берете и пишете? Я, например, так не могу. Не всегда получится архитектуру поднять из кода. Проще ее закодировать (то есть сначала представить, что и как будет). Мелочами никто и не заставляет заниматься. Рисование не вовлекает в мелочность, а располагает к всеобщему рассмотрению с возможностью заострить внимание на любой конкретной части. Не я это придумал. Физиологи так говорятъ. Таким образом мы сначала вырабатываем архитектуру в общем, учитывая требования к ее функционированию. Это, если хотите, можно увязать с ранним тестированием. Далее, определившись с общей архитектурой спускаемся ниже по степени детализации... это все не мной придумано и работает на ура. При таком подходе кстати проще вернуться на старший уровень абстракции — нужно просто посмотреть шире на "рисованые картинки". Можно менять старшие уровни организации с учетом пересмотра роли/поведения/структуры каких-то отдельных частей. При работе с чистым кодом, даже если сам его писал, не всегда увидишь, что и как переделать. Тут и начинаем масштабный рефакторинг. А все из-за неясности кодирования вслепую, глядя в отдельный модуль.

N>>При том современные средства прямого и обратного инжиниринга позволяют создавать и перестраивать архитектуру без особых потерь (времени в частности). Тот же "убогий", как некоторые считают, ModelMaker предоставляет средства кодогенерации, рефакторинга, реинжирининга, визульного моделирования, реализации паттернов и пр. — остается только вписать реализацию.
N>>Визуальное моделирование — рулез!!!
GZ>Это потому, что вы не писали больших программ с помощью этого инструмента. Недельки через две, вы уже не будете на него обращать внимание. И структура программы значительно изменится от той которую вы предполагали. Опа, и оказалось что кодогенерация уже не нужна. Средства автоматического рефакторинга, к визуалке отношения не имеют. Средства реинжиниринга, я вообще не понимаю как такое может быть. Если у тебя проблема обнаружилась в концепции, то тут уже ничего не поможет. Только ручки, голова и итерации.

Вот именно если не обращать внимания, то и начинаются проблемы с архитектурой. Простое правило: при построении архитектуры нельзя (хоть иногда и полезно) забывать о возможности реализации. Правильно выбранная модель, даже если окажется несостоятельной по какой-либо причине, всегда позволит реорганизовать себя. Что есть редизайн. Это уже сходу в редакторе кода не увидишь, не получишь.
Рефакторинг там вовсе не автоматический, а самый что ни на есть обычный: автоматика просто дает сервис, поле деятельности перед глазами, что и куда рефакторить — решай сам!
Уже пишем — пока не жалуемся.Число модули растут гораздо быстрее (и в ширину и в количестве) чем диаграмм отражающие классы их составляющие. Главное ко всему подойти с умом и не лезть граблями картошку копать. Архитектура — моделирование. Реализация — кодирование. +везде тестирование:архитектура — на соответствие требованиям, реализация — сами понимаете.

GZ>Визуальные средства (типа Class или Case Diagram), нужны только для того, чтобы распространить знания о предполагаемом или готовом продукте между заинтересованными сторонами.

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

Все это ИМХО и никто не навязывает. Просто так тоже можно и многим удобно, то есть как вариант отбрасывать не стоит.

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

M>Да, и забыл добавить: далеко не всё в приложении есть код. Визуальных средств обычно не хватает на всё.

Не нужно на все. На что не хватает? Они используются в своем ограниченном "пространстве" и справляются со своими задачами хорошо.

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

N>Извините, но это уже структурное программирование, а, если я не ошибаюсь, речь о ООП. Как можно говорить о модулях в принципе? Классы, компоненты и пакеты — основные значимые структурные сущности. Как они ранжируются по модулям — на сегодня дело вкуса и языка ООП. Конечно логически можно представить модуль как некую законченную сущность — в частности как представление collaboration, но это не обязательно. Если вернуться к вопросу, то ни о каком модульном программировании и речи быть не может. В .NET все строго упаковано в классы.
Во первых, я говорил именно о логической структуре программы. Вы же все снижаетесь на физику. По правильному — процесс разработки мало зависит от используемого языка. Во вторых — неправильный перевод термина collaboration. Package лучше.
N>Скажите, вы так вот слету берете и пишете? Я, например, так не могу.
Опыт и знания.
N>Не всегда получится архитектуру поднять из кода. Проще ее закодировать (то есть сначала представить, что и как будет). Мелочами никто и не заставляет заниматься. Рисование не вовлекает в мелочность, а располагает к всеобщему рассмотрению с возможностью заострить внимание на любой конкретной части. Не я это придумал. Физиологи так говорятъ. Таким образом мы сначала вырабатываем архитектуру в общем, учитывая требования к ее функционированию. Это, если хотите, можно увязать с ранним тестированием. Далее, определившись с общей архитектурой спускаемся ниже по степени детализации... это все не мной придумано и работает на ура. При таком подходе кстати проще вернуться на старший уровень абстракции — нужно просто посмотреть шире на "рисованые картинки". Можно менять старшие уровни организации с учетом пересмотра роли/поведения/структуры каких-то отдельных частей. При работе с чистым кодом, даже если сам его писал, не всегда увидишь, что и как переделать. Тут и начинаем масштабный рефакторинг. А все из-за неясности кодирования вслепую, глядя в отдельный модуль.
Вы описали работу жесткого процесса разработки. Для большого количества разработчиков, документирование вещь необходимая. Иначе получается бардак(я свидетель и не один раз). Я же описывал именно гибкую систему процесса разработки. Когда существует группа, в которой вся информация известна каждому члену данной группы. Также, у вас неправильное понимание о тестах. Именно в тестах содержится вся информация о модуле необходимая разработчикам. В них описание интерфейса и его работа. Также вы неправильно определили рефакторинг. Рефакторинг не предназначен для изменения функциональности и интерфейса. Это всего лишь приведение первоначального простого дизайна, на более сложный и эффективный уровень. И именно благодаря рефакторингу, все изменения в коде проходят достаточно легко. Далее. Никто и не говорил что не придется выбрасывать код. Но в силу того, что времени на постановку уходит значительно больше, и ошибка на концептуальном уровне также приводит к выбросу кода, то в XP это нормальный процесс.

N>Вот именно если не обращать внимания, то и начинаются проблемы с архитектурой. Простое правило: при построении архитектуры нельзя (хоть иногда и полезно) забывать о возможности реализации. Правильно выбранная модель, даже если окажется несостоятельной по какой-либо причине, всегда позволит реорганизовать себя.
Вы путаете две противоположные методики. В случае гибкой методики, заинтересованных сторон не так уж много. Поэтому архитектура известна всем.
N>Что есть редизайн. Это уже сходу в редакторе кода не увидишь, не получишь.
Сначало пишешь тест, чтобы получить то что тебе нужно. Затем вносишь изменения в код. Если перед этим был процесс рефакторинга, то все проходит на ура. Ну а после изменений, снова рефакторинг.
N>Рефакторинг там вовсе не автоматический, а самый что ни на есть обычный: автоматика просто дает сервис, поле деятельности перед глазами, что и куда рефакторить — решай сам!
N>Уже пишем — пока не жалуемся.Число модули растут гораздо быстрее (и в ширину и в количестве) чем диаграмм отражающие классы их составляющие. Главное ко всему подойти с умом и не лезть граблями картошку копать. Архитектура — моделирование. Реализация — кодирование. +везде тестирование:архитектура — на соответствие требованиям, реализация — сами понимаете.
Реализация, на соответсвие требованиям Независимо от процесса производства, требования должны выполняться.

N>Изначально — да. Вообще — никто не запрещает использовать модель в отражении диаграмм переводить в шаблон кода, предъявляющий к реализации требования на соответствие заданной структуре, поведению и интерфейсу взаимодействия. Ограничения иногда оказываются слишком строгими и здесь приходишь к моменту, когда реализация требует изменений в архитектуре на каком-либо уровне. и с этим не возникает проблем. Ремоделирование -> кодирование.
Вызывают проблемы. И еще какие. Чем выше уровень изменений, тем большую проблему приходится решать. Затем и ввели итерационные процессы.

N>Все это ИМХО и никто не навязывает. Просто так тоже можно и многим удобно, то есть как вариант отбрасывать не стоит.
А я и не отбрасываю. Все что вы здесь описали, почти верно для процессов RUP и MSF. У каждой методики есть свои плюсы и минусы. Я же описал процесс XP, и показал когда это круто (когда команда небольшая, и есть возможность прямого общения с заказчиком). Советую более детально изучить процессы RUP и прочитать про процессы XP. Это две противоположности. Тогда более менее сможете квалифицированно сказать, в каком случае лучше та, или иная методика. И уже выбирать по месту, что в каком случае вам более подходит.

С уважением, Gleb.
PS:старайтесь убирать цитирования. Модераторы обижаются. Могут забанить.

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

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

GZ>Во первых, я говорил именно о логической структуре программы. Вы же все снижаетесь на физику. По правильному — процесс разработки мало зависит от используемого языка. Во вторых — неправильный перевод термина collaboration. Package лучше.
За модули извините — рефлекс сработал . Collaboration — имелось ввиду, что физически реализованный модуль можно рассматривать как способ организации отдельного collab'а. Можно брать шире до пакета...
N>>Скажите, вы так вот слету берете и пишете? Я, например, так не могу.
GZ>Опыт и знания.
А с закрытыми глазами?
GZ>Вы описали работу жесткого процесса разработки. Для большого количества разработчиков, документирование вещь необходимая. Иначе получается бардак(я свидетель и не один раз). Я же описывал именно гибкую систему процесса разработки. Когда существует группа, в которой вся информация известна каждому члену данной группы. Также, у вас неправильное понимание о тестах. Именно в тестах содержится вся информация о модуле необходимая разработчикам. В них описание интерфейса и его работа. Также вы неправильно определили рефакторинг. Рефакторинг не предназначен для изменения функциональности и интерфейса. Это всего лишь приведение первоначального простого дизайна, на более сложный и эффективный уровень. И именно благодаря рефакторингу, все изменения в коде проходят достаточно легко. Далее. Никто и не говорил что не придется выбрасывать код. Но в силу того, что времени на постановку уходит значительно больше, и ошибка на концептуальном уровне также приводит к выбросу кода, то в XP это нормальный процесс.
Ну да. Каждому свое. О тестах я знаю. И TDD понимаю. А раннее тестирование — это в том смысле, что с его помощью можно прояснить требования к архитектуре: зная вход/выход, проще понять чего нужно и проще прикинуть как это можно реализовать. Угу?
Рефакторинг при таком подходе принимает более широкие масштабы и плавно переходит в ремоделирование.

N>>Вот именно если не обращать внимания, то и начинаются проблемы с архитектурой. Простое правило: при построении архитектуры нельзя (хоть иногда и полезно) забывать о возможности реализации. Правильно выбранная модель, даже если окажется несостоятельной по какой-либо причине, всегда позволит реорганизовать себя.
GZ>Вы путаете две противоположные методики. В случае гибкой методики, заинтересованных сторон не так уж много. Поэтому архитектура известна всем.
А кто сказал, что НУЖНО придерживаться одной методики? Почему я не могу воспользоваться плюсами раннего тестирования например для определения требований, каркас модели построить (не задокументировать! — это можно рассматривать как побочный эффект) в среде моделирования, а затем по ходу разработки во взаимодействии "реализация <-> архитектура" искать баланс, применяя средства моделирования, рефакторинга и пр. ?
N>>Что есть редизайн. Это уже сходу в редакторе кода не увидишь, не получишь.
GZ>Сначало пишешь тест, чтобы получить то что тебе нужно. Затем вносишь изменения в код. Если перед этим был процесс рефакторинга, то все проходит на ура. Ну а после изменений, снова рефакторинг.
Вот с этапом "вносишь изменения в код" и "рефакторинг" можно и до того дойти в собственном радикализме, что придется модифицировать архитектуру. Типа революция снизу тут и удобны картинки.
N>>... реализация — сами понимаете.
GZ>Реализация, на соответсвие требованиям Независимо от процесса производства, требования должны выполняться.
Само собой.

эх...

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

GZ>А я и не отбрасываю. Все что вы здесь описали, почти верно для процессов RUP и MSF. У каждой методики есть свои плюсы и минусы. Я же описал процесс XP, и показал когда это круто (когда команда небольшая, и есть возможность прямого общения с заказчиком). Советую более детально изучить процессы RUP и прочитать про процессы XP. Это две противоположности.

После чтения Лармана у меня почему-то сформировалось иное мнение.

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

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

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

GZ>>Хотя в данном случае, нужно еще объяснить что такое модульное тестирование. Так как, без этого рефакторинг невозможен(или можно сказать вреден).

AVK>Глупости вы говорите. Юнит-тестирование не панацея, хуже того, в некоторых случаях от него пользы практически нет.
В отношении рефакторинга? Вы меня удивляете.

С уважением, Gleb.

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

AVK>>Глупости вы говорите. Юнит-тестирование не панацея, хуже того, в некоторых случаях от него пользы практически нет.
GZ>В отношении рефакторинга? Вы меня удивляете.

Это вы меня удивляете. Рядом сам же пишешь что there is no silver bullet и тут же заявляешь что рефакторинг без юнит-тестирования невозможен. Возможен и еще как. В нашем текущем проекте это практически непрерывный процесс, при том что юнит-тестирование к нему, несмотря на несколько попыток, так прикрутить и не удалось по ряду объективных и субъективных причин.

Здравствуйте, <Аноним>, Вы писали:

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

M>>Сначала напиши программу (хоть чучелом, хоть тушкой), а потом уже будешь думать об архитектуре. Без опыта спроектировать приложение тебе не удастся, даже если ты 20 книжек прочитаешь. Постоянный рефакторинг поможет тебе ухватить паттерны, возникающие в коде, а уж потом можно подогнать под это дело науку, GoF там, или Fowler-а.

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

Borland Together возможно?

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

MOS>Borland Together возможно?

наверное возможно, но можно хотя бы пару слов для чего он и чем отличается от продуктов rational?

А>возник еще один вопрос, при програмировани на c++ для гибкости программ часто используются интерфейсы, я знаю что на c# тоже есть интерфейсы, но вопрос в том правильно ли их использовать или есть другие спососбы создания гибких систем.
Стоит сначала прочитать какую-нибудь книжку про ООП, что бы понять для чего вообще нужны интерфейсы.
В C# далеко не уедишь без интерфейсов, и одна из причин, отсутствие множественного наследования, которое присутствует в С++

С уважением,
bw.

AVK>>>Глупости вы говорите. Юнит-тестирование не панацея, хуже того, в некоторых случаях от него пользы практически нет.
GZ>>В отношении рефакторинга? Вы меня удивляете.

AVK>Это вы меня удивляете. Рядом сам же пишешь что there is no silver bullet и тут же заявляешь что рефакторинг без юнит-тестирования невозможен. Возможен и еще как. В нашем текущем проекте это практически непрерывный процесс, при том что юнит-тестирование к нему, несмотря на несколько попыток, так прикрутить и не удалось по ряду объективных и субъективных причин.
Интересно, а что за причины объективные и субъективные?

С уважением,
bw.

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

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

L>>После чтения Лармана у меня почему-то сформировалось иное мнение.
GZ>После первого прочтения по RUP, я был вне себя от счастья. Ну что нужно разработчику, написать требования, и рисовать, рисовать, рисовать. Потом две строчки кода, тестинг на требования, и все all right. Там и думать ничего не надо. Все прописано. Но даже в первом приближении оказалось, что выполнять дословно все предписания (и даже учитывая рекомендации о приблизительности) безнадежное дело. К тому же переходы от концептуальной модели к логической, а потом и физической — сильно эвристичны. Как бы голову разработчику никто не отменял. Ну а если нужно написать программу которая выводит результат 2*2=4, то столько писанины, мама не балуйся.
Интересно было бы посмотреть набор документации, которую Вы сгенерите, чтобы выполнить проект "2х2=4".
Мне кажется, что проблемы в консерватории...

GZ>Потом, прочитал про XP. Все, this is the best. Разрешено просто писать 2*2=4. Только опыт подсказывал, что не все так уж отлично. А не отлично то, что предыдущий опыт показывал степень бардака, который устанавливается в крупных группах. Когда программист не знает что делает его сосед. Поэтому, если группа большая, то распространение информации на каждого участника просто невозможна. А ведь нужно чтобы каждый участник не просто знал бизнес-процессы. Он должен знать бизнес-процессы своих соседей и мог общаться с его кодом. Ну и плюс — разработка требований. Наличие плотного общения с заказчиком, не всегда возможно. И этот заказчик, должен быть дока во всех аспектах требований. Зачастую, заказчик — это группа заинтересованных лиц от нескольких отделов предприятия. Разработка и утверждение требований — слишком важный процесс не только с точки зрения разработчика, но и с коммерческой точки зрения(потом будет сильно больно если не видно этой важности).
Утверждение бизнес-требовании очень важная состовляющая: (a) то что написано "не вырубить топором"
(б) нельзя все удержать в голове (в) в любой момент времени можно заглянуть в документ с описанием бизнес-процесса
(г) имея список требований легче построить план проекта

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

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


С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

А>Интересно, а что за причины объективные и субъективные?

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

Здравствуйте, <Аноним>, Вы писали:

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

MOS>>Borland Together возможно?

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

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

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

N>>>Скажите, вы так вот слету берете и пишете? Я, например, так не могу.
GZ>>Опыт и знания.
N>А с закрытыми глазами?
Почему бы нет. При обладании знаниями и опытом можно с одного взгляда определить общие контуры архитектуры для данного решения. Ну а дальше определяешь итерации и подход. Ессно, если решение должно быть комплексное или сложное алгоритмически, то тут уже придется порисовать.

GZ>>Вы описали работу жесткого процесса разработки. Для большого количества разработчиков, документирование вещь необходимая. Иначе получается бардак(я свидетель и не один раз). Я же описывал именно гибкую систему процесса разработки. Когда существует группа, в которой вся информация известна каждому члену данной группы. Также, у вас неправильное понимание о тестах. Именно в тестах содержится вся информация о модуле необходимая разработчикам. В них описание интерфейса и его работа. Также вы неправильно определили рефакторинг. Рефакторинг не предназначен для изменения функциональности и интерфейса. Это всего лишь приведение первоначального простого дизайна, на более сложный и эффективный уровень. И именно благодаря рефакторингу, все изменения в коде проходят достаточно легко. Далее. Никто и не говорил что не придется выбрасывать код. Но в силу того, что времени на постановку уходит значительно больше, и ошибка на концептуальном уровне также приводит к выбросу кода, то в XP это нормальный процесс.
N>Ну да. Каждому свое. О тестах я знаю. И TDD понимаю. А раннее тестирование — это в том смысле, что с его помощью можно прояснить требования к архитектуре: зная вход/выход, проще понять чего нужно и проще прикинуть как это можно реализовать. Угу?
Вы говорите об уменьшении рисков. В данном случае имелось ввиду, что как таковая архитектурная модель только примерна. Поэтому за нее в случае XP и держаться не стоит. Что касается уменьшения рисков связанных с производительностью, то пока не построишь решение, истинного результата не получишь. Все тесты являются всего лишь эвристические предположения о производительности.
N>Рефакторинг при таком подходе принимает более широкие масштабы и плавно переходит в ремоделирование.
Рефакторинг — не затрагивает функциональность кода. Единственный смысл рефакторинга (тут мое мнение) только в том, чтобы перестроить код таким образом, чтобы он был рассыплен на кирпички с помощью которого удобно добавлять новую функциональность или редактировать существующую. Все. Больше смысла нет. Для того, чтобы рефакторинг не затрагивал функциональность, пишутся тесты. И в случае если при рефакторинге, какой-то тест не прошел, значит разработчик наколбасил. А изменение функциональности — это совершенно другая песня. Правильный рефакторинг, всего лишь способ создания кода пригодного к изменениям. Весь XP построен именно на возможности простого изменения как кода так и модели.

N>А кто сказал, что НУЖНО придерживаться одной методики? Почему я не могу воспользоваться плюсами раннего тестирования например для определения требований, каркас модели построить (не задокументировать! — это можно рассматривать как побочный эффект) в среде моделирования, а затем по ходу разработки во взаимодействии "реализация <-> архитектура" искать баланс, применяя средства моделирования, рефакторинга и пр. ?
Я только за.

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

С уважением, Gleb.

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

AVK>Это вы меня удивляете. Рядом сам же пишешь что there is no silver bullet и тут же заявляешь что рефакторинг без юнит-тестирования невозможен. Возможен и еще как.
Я не утверждал что невозможен. Любой рефакторинг должен сверяться с функциональностью. В каком виде, уже второй вопрос. Это может быть просто визуального просмотр результата. Но при этом, и наколбасить легко. Испортить как свою так и чужую функциональность. Тесты(модульные или иные) в данном случае присутствуют только для отслеживания неизменности функциональности.
AVK>В нашем текущем проекте это практически непрерывный процесс, при том что юнит-тестирование к нему, несмотря на несколько попыток, так прикрутить и не удалось по ряду объективных и субъективных причин.
Все таки я склонен думать больше о субъективных причинах. Построить плотное покрытие unit тестов, если у тебя в результате какого-то алгоритма получается бесконечное количество решений, безусловно невозможно. Это факт. Но выцепить по отдельности некоторые наиболее важные свойства результата и навесить на него unit тесты — вполне возможно. Если интересно, у меня компилятор запросов тоже имеет практически бесконечное количество решений, но unit тесты построенные по основной функциональности не раз мне спасали кучу времени.

А объективная причина (которая зачастую является субьективной) отрицания модульного тестирования, по моему только одна. Деньги платят за функциональность, а не за качество кода.

С уважением, Gleb.

Здравствуйте, <Аноним>, Вы писали:

А>Интересно было бы посмотреть набор документации, которую Вы сгенерите, чтобы выполнить проект "2х2=4".
А>Мне кажется, что проблемы в консерватории...
Для показа проблемы, нужно просто явно довести ее до маразма

А>Утверждение бизнес-требовании очень важная состовляющая:
А>(a) то что написано "не вырубить топором"
А>(б) нельзя все удержать в голове
А>(в) в любой момент времени можно заглянуть в документ с описанием бизнес-процесса
А>(г) имея список требований легче построить план проекта
Все абсолютно верно. Требования — документ прибитый подписями со всех заинтересованных сторон. А теперь поговорим об отрицательных сторонах. Проблема одна и большая. Заказчика уволить нельзя.
В результате получается по твоему пункту (a) 3 типа изменения требований:
1. Заказчик требует внести изменения. Ему трясут трясут бумажками и ставят на место. Клиент недоволен.
2. Фирма ложится под заказчика. Разработчики потеют и сроки летят. Разработчики недовольны. Самое криминальное, поскольку есть вероятность вообще не получить готового продукта.
3. Фирма видит невозможность реализации требования. Самое меньшее из зол. Обычно это проходит без маразма, поскольку причина объективна. А в продукте заинтересованы обе стороны.

А>Должен быть порядок в проекте, тогда и не будет проблем с координацией в нутри него. Это задача проект-менеджера и ведщего(их) разработчика(ов).
Ты видел 100% RUP в действии? Я видел только адаптации применительно к проектам. Точно так же и MSF (хотя он немного и полегче полного RUP).

С уважением, Gleb.

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

GZ>Все таки я склонен думать больше о субъективных причинах. Построить плотное покрытие unit тестов, если у тебя в результате какого-то алгоритма получается бесконечное количество решений, безусловно невозможно. Это факт. Но выцепить по отдельности некоторые наиболее важные свойства результата и навесить на него unit тесты — вполне возможно.

Но может быть очень дорого. Слишком дорого.

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

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

GZ>А объективная причина (которая зачастую является субьективной) отрицания модульного тестирования, по моему только одна. Деньги платят за функциональность, а не за качество кода.

У нас не все так просто.

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

AVK>Здравствуйте, <Аноним>, Вы писали:

А>>Интересно, а что за причины объективные и субъективные?

AVK>Насчет субъективных я умолчу, а объективные очень простые — объем работ по созданию тестов в некоторых случаях, покрывающих код на ощутимую величину очень велик.
Таки это ведь тестирование — плата за уверенность в качестве продукте.
Конечно, очень трудно в один прекрасный момент понять, что хорошо бы иметь unit-тесты, но уже написаны километры кода. Сам сейчас разруливаю такую ситуацию...

AVK>К таким случаям относятся например кодогенераторы.
Это хороший аспект. Взаимосвязь кодогенератора и XP. А каким пользуется? Насколько сильно завязаны разработчики на такие средства?
AVK>Кроме того плохо поддаются тестированию куски кода, завязанные на окружение.
Какие проблемы могут быть?

В вашем проекте участвуют тестировщики? И как выглядит процесс тестирования?

С уважением,
bw.

А>>Интересно было бы посмотреть набор документации, которую Вы сгенерите, чтобы выполнить проект "2х2=4".
А>>Мне кажется, что проблемы в консерватории...
GZ>Для показа проблемы, нужно просто явно довести ее до маразма
Проблемы нужно решать, а не вырождать их до маразма

GZ>Все абсолютно верно. Требования — документ прибитый подписями со всех заинтересованных сторон. А теперь поговорим об отрицательных сторонах. Проблема одна и большая. Заказчика уволить нельзя.
GZ>В результате получается по твоему пункту (a) 3 типа изменения требований:
GZ>1. Заказчик требует внести изменения. Ему трясут трясут бумажками и ставят на место. Клиент недоволен.
А с чего я вдруг буду против, если фирма платит? Если проект "пишется" больше, чем полгода, то вероятность таких изменений очень велика.

GZ>2. Фирма ложится под заказчика. Разработчики потеют и сроки летят. Разработчики недовольны. Самое криминальное, поскольку есть вероятность вообще не получить готового продукта.
Не надо никуда ложится. Надо конструктивно сотрудничать.
Что за детский сад "Разработчики недовольны"?!

GZ>3. Фирма видит невозможность реализации требования. Самое меньшее из зол. Обычно это проходит без маразма, поскольку причина объективна. А в продукте заинтересованы обе стороны.
Очень странно. Как это фирма видит невозможность реализации требования? А куда она раньше смотрела, перед тем как подписаться под проектом?

А>>Должен быть порядок в проекте, тогда и не будет проблем с координацией в нутри него. Это задача проект-менеджера и ведщего(их) разработчика(ов).
GZ>Ты видел 100% RUP в действии? Я видел только адаптации применительно к проектам. Точно так же и MSF (хотя он немного и полегче полного RUP).
Нет, не видел. Но я также не видел, чтобы кто-то соблюдал правила дорожного движения на 100%. Но это не значит, не надо стремится не нарушать ПДД. Мысль, надеюсь, понятна?!

С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

AVK>>Насчет субъективных я умолчу, а объективные очень простые — объем работ по созданию тестов в некоторых случаях, покрывающих код на ощутимую величину очень велик.
А>Таки это ведь тестирование — плата за уверенность в качестве продукте.

Вопрос в размере этой платы.

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

У нас как раз попытки сделать юнит-тесты были когда кода было еще немного.

AVK>>К таким случаям относятся например кодогенераторы.
А>Это хороший аспект. Взаимосвязь кодогенератора и XP. А каким пользуется? Насколько сильно завязаны разработчики на такие средства?

Не понял вопроса.

AVK>>Кроме того плохо поддаются тестированию куски кода, завязанные на окружение.
А>Какие проблемы могут быть?

Проблемы воссоздания окружения в тестовой среде.

А>В вашем проекте участвуют тестировщики?

Да.

А>И как выглядит процесс тестирования?

Как обычно.

Здравствуйте, <Аноним>, Вы писали:

GZ>>Для показа проблемы, нужно просто явно довести ее до маразма
А>Проблемы нужно решать, а не вырождать их до маразма
Не путайте локализацию и решением.

А>А с чего я вдруг буду против, если фирма платит? Если проект "пишется" больше, чем полгода, то вероятность таких изменений очень велика.
А>Не надо никуда ложится. Надо конструктивно сотрудничать.
А>Что за детский сад "Разработчики недовольны"?!
С того, что за разработку платит именно фирма разработчиков, а не заказчик. Заказчик платит за готовый продукт сданный в срок. А зарплату платит непосредственный начальник.

А>Очень странно. Как это фирма видит невозможность реализации требования?
Вы никогда не попадали на нерешаемые проблемы? Или ошибки в требованиях? Смею вас уверить, это обычное дело.
А>А куда она раньше смотрела, перед тем как подписаться под проектом?
И куда смотрит Путин?

А>Нет, не видел. Но я также не видел, чтобы кто-то соблюдал правила дорожного движения на 100%. Но это не значит, не надо стремится не нарушать ПДД. Мысль, надеюсь, понятна?!
Аналогия неуместна. Я видел людей которые соблюдали правила дорожного движения на 100%. Соблюдение 100% RUP ведет к умиранию проекта. И в процессе производства программных продуктов нет правил дорожного движения. Скорее это похоже на установку светофоров и рисование полос. Для каждого участка, подход индивидуальный. И ГИБДД часто ставят светофор пока дюжину народу не передавят.

С уважением, Gleb.

А>>А с чего я вдруг буду против, если фирма платит? Если проект "пишется" больше, чем полгода, то вероятность таких изменений очень велика.
А>>Не надо никуда ложится. Надо конструктивно сотрудничать.
А>>Что за детский сад "Разработчики недовольны"?!
GZ>С того, что за разработку платит именно фирма разработчиков, а не заказчик. Заказчик платит за готовый продукт сданный в срок. А зарплату платит непосредственный начальник.
Вот это для меня новость! Впервые слышу о такой модели взаимодействия.
До этого, я был уверен, что или коробка или заказная разработка.
В-первом случаи, требования — это внутреннее видение проблемы, а у потенциальных клиентов обычно пожелания.
Во-втором случае, каждое требование имеет некую стоимость, соответственно изменении требования влечет за собой изменение стоимости.

А>>Очень странно. Как это фирма видит невозможность реализации требования?
GZ>Вы никогда не попадали на нерешаемые проблемы? Или ошибки в требованиях? Смею вас уверить, это обычное дело.
Нет безвыходных ситуаций, даже если вас съели, у вас есть два выход (С) Народная мудрость
А>>А куда она раньше смотрела, перед тем как подписаться под проектом?
GZ>И куда смотрит Путин?
Казалось при чем тут Путин?!

А>>Нет, не видел. Но я также не видел, чтобы кто-то соблюдал правила дорожного движения на 100%. Но это не значит, не надо стремится не нарушать ПДД. Мысль, надеюсь, понятна?!
GZ>Аналогия неуместна. Я видел людей которые соблюдали правила дорожного движения на 100%. Соблюдение 100% RUP ведет к умиранию проекта. И в процессе производства программных продуктов нет правил дорожного движения. Скорее это похоже на установку светофоров и рисование полос. Для каждого участка, подход индивидуальный. И ГИБДД часто ставят светофор пока дюжину народу не передавят.
Не вздумайте говорит, что знаете тех, кто соблюдает ПДД на все 100%. Таких людей нет в природе. А люди, которые делают такие заявление, могут привлечь внимание со стороны психиатров. Серьезно!


C уважением,
bw.

А>>Это хороший аспект. Взаимосвязь кодогенератора и XP. А каким пользуется? Насколько сильно завязаны разработчики на такие средства?
AVK>Не понял вопроса.
Как интенсивно используются кодогенераторы в процессе разработки? Или Вы привели данный случай в качестве примера?

AVK>>>Кроме того плохо поддаются тестированию куски кода, завязанные на окружение.
А>>Какие проблемы могут быть?
AVK>Проблемы воссоздания окружения в тестовой среде.
Я понимаю. Какие проблемы?

А>>И как выглядит процесс тестирования?
AVK>Как обычно.
Все равно, что на вопрос "как выглядит процесс разработки?", ответить "как обычно".

С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

А>>>Это хороший аспект. Взаимосвязь кодогенератора и XP. А каким пользуется? Насколько сильно завязаны разработчики на такие средства?
AVK>>Не понял вопроса.
А>Как интенсивно используются кодогенераторы в процессе разработки? Или Вы привели данный случай в качестве примера?

Привел в качестве примера.

AVK>>Проблемы воссоздания окружения в тестовой среде.
А>Я понимаю. Какие проблемы?

Трудоемкость.

А>>>И как выглядит процесс тестирования?
AVK>>Как обычно.
А>Все равно, что на вопрос "как выглядит процесс разработки?", ответить "как обычно".

Ну а что я тебе еще могу сказать? Я разработчик, а не тестировщик.

Здравствуйте, <Аноним>, Вы писали:

GZ>>С того, что за разработку платит именно фирма разработчиков, а не заказчик. Заказчик платит за готовый продукт сданный в срок. А зарплату платит непосредственный начальник.
А>Во-втором случае, каждое требование имеет некую стоимость, соответственно изменении требования влечет за собой изменение стоимости.
Сравниваем сказанное, и начинаем долго нудно думать.

GZ>>И куда смотрит Путин?
А>Казалось при чем тут Путин?!
А потому-что он наш президент.
Если интересно, это была шутка.

С уважением, Gleb.

AVK>>>Проблемы воссоздания окружения в тестовой среде.
А>>Я понимаю. Какие проблемы?
AVK>Трудоемкость.
Не труднее, чем писать unit-тесты при использовании WinSockets

А>>>>И как выглядит процесс тестирования?
AVK>>>Как обычно.
А>>Все равно, что на вопрос "как выглядит процесс разработки?", ответить "как обычно".
AVK>Ну а что я тебе еще могу сказать? Я разработчик, а не тестировщик.
Так может стоит привлекать тестировщиков на ранних этапах разработки, чтобы они оказывали методологическую помощь при написании unit-тестов?!

С уважением,
bw.

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

M>Здравствуйте, Аноним, Вы писали:
А>>И также определится с форматом написания кода, чтобы код был самодокумнтированым.
M>Вот жертва документации:
M>Это дурная идея смешивать код с документацией.
Нет. Во-первых, Intellisence (или как там). Во-вторых — чисто эстетически, код с комментариями не вызывает чувство отчаяния. В конце концов, любой код рано или поздно будет читать тот, кто об этом коде ничего не знает, и скорее всего, времени на вникание в детали будет в обрез. Наличие подсказки на каждый метод сэкономит много десятков секунд, и тысячи нервных клеток. Кроме того, наличие даже самых примитивных комментариев (хотя бы ///) заставляет ещё раз задуматься (автора), что же всё-таки делает этот код.
Не бывает самодокументироемого кода. Есть понятный, и непонятный. А комментарии никогда не бывают лишними — в этом меня убеждает, например, сегодняшний ревью собственного кода.

Здравствуйте, <Аноним>, Вы писали:

AVK>>Трудоемкость.
А>Не труднее, чем писать unit-тесты при использовании WinSockets

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

AVK>>Ну а что я тебе еще могу сказать? Я разработчик, а не тестировщик.
А>Так может стоит привлекать тестировщиков на ранних этапах разработки, чтобы они оказывали методологическую помощь при написании unit-тестов?!

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

А>И вообще писать документации вредно.
Как ни странно, да.
Её вредно писать в том случае, когда она маскирует непонятность кода. В таком случае лучше сделать код понятным. А вот описание сложной логики взаимодействия сущностей модели — это уже (в терминах XP) метафора. Ну так она и есть внешняя (по отношению к коду) документация, вопрос лишь в балансе между размером этой документации и необходимостью в ней. Часто бывает достаточно обозначить ключевые моменты. Широкое же документирование всего и вся нужно лишь в том случае, если коммуникация перестаёт работать, а это случается в очень больших командах. И тут, как мне кажется, лучше систему разбивать на достаточно независимые модули и писать их маленькими командами. Тогда документирование нужно будет только в местах стыковки этих модулей, но не для всей системы целиком.