Здравствуйте, Sinix, Вы писали:
S>Упс... по ходу иронию восприняли как наезд... Сорри. S>С другой стороны — надо ж как-то поднимать тему.
А>>>>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами. S>... А>>В физике я встречал такое обозначение: "при a >> b". Это значило, что а не просто больше, а намногобольше b. "Намного" взято в курсив как нестрогий термин.
S>Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намногобольше b"? Вы уж определитесь пожалуйста.
Слюшай, дарагой, посмотри на значок, да? Вот какой канэц у этого значка бальшой, так и прыоритет с этого канца бальшой, савсэм бальшой. Огромный прыоритет, во какой! Так понял, да?
А>>Таким образом, начинать надо со сбора требований. (Частный случай: интерфейс или архитектура являются требованиями сами по себе). Затем — разработать интерфейс, который решает ВСЕ требования. И только потом — думать об архитектуре. А уж код должен соответствовать всем документам, что были написаны в ходе первых трех этапов.
S>Откройте для себя водопадную модель уже что ли S>Ворос на засыпку. Если уж у вас гуй определяет архитектуру системы (если мы под архитектурой понимаем одно и то же) — то к чему приведёт необходимость использовать другие отчёты/список вместо грида/дублирование вызовов через меню/кнопки?
Не обязательно ГУЙ. Может и просто УЙ. Поручик, молчать: интерфейс пользователя может быть не только графическим.
S>P.S. Если вы УЖЕ решили все требования без архитектуры — зачем она вам теперь? Избавьтесь от неё
"Что это шумит? Во-до-пад!" Если интерфейс "решает" (как-то не по-русски, может стоило написать "разрешает от"?) требования (отвечает на вопрос, как ПО должно взаимодействовать с пользователем, чтобы требования были "решены", и чтобы оптимально, и универсально, и расширябельно), то архитектура "решает" интерфейс (отвечает на вопрос, как должен быть написан код, чтобы он давал такой интерфейс, и чтобы понятно, и удобно, и нетрудоемко, и, опять же, универсально и пр.).
Ответ на засыпку: после того, как стало понятно, что ПО должно давать юзеру средства для анализа (требование), дизайнер приходит к мысли о необходимости метафоры отчетов (интерфейс). Вводя такую метафору в интерфейс, он заставляет архитектора предусмотреть отчетный модуль. Кроме того, для решения текущих задач вводится набор дизайна отчетов, каждый из которых, опять же, архитектурно разрабатывается. Необходимость использовать другие отчеты (это юзверя врубились в идею отчетности и стали формулировать требования в терминах существующего интерфейса, т.н. path dependance) приведет к тому, что дизайнер проработает дизайн новых отчетов, а архитектор по каждому из них примет решение — как надо реализовывать этот вид отчета, какой библиотекой/компонентами и пр.
Список вместо грида — это как? Откуда такое странное требование? Если юзеры видели наброски интерфейса со списком и с гридом, и выбрали с гридом, то такое требование не появится. Если не видели, а дизайнер об этом не подумал, то дизайнер плохой, а что будет с архитектурой — не знаю. Возможно, придется и менять, но не думаю, что много.
Дублирование вызовов через меню/кнопки — это третий случай. Это дальнейшее развитие интерфейса, и хорошая архитектура делается с учетом возможности в будущем такого расширения. И она не меняется. Просто в OnMenu() появляется новый Case, очень грубо говоря.
Re[11]: Просветите про роль требований в проектировании, пли
Аноним, если вы сознательно троллите — так и напишите — я не буду разговаривать с вами как с адекватным человеком. Если нет — постарайтесь читать то что вам пишут, ладно?
S>>Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намногобольше b"? Вы уж определитесь пожалуйста. А>Слюшай, дарагой, посмотри на значок, да? Вот какой канэц у этого значка бальшой, так и прыоритет с этого канца бальшой, савсэм бальшой. Огромный прыоритет, во какой! Так понял, да?
Тут у нас обычное взаимонедопонимание. У меня "одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет" воспринимается как "следующее приоритетней предыдущего". А "а не просто больше, а намногобольше b" воспринимается соответственно наоборот. Замяли, ок?
А>"Что это шумит? Во-до-пад!" A> Если интерфейс "решает" (как-то не по-русски, может стоило написать "разрешает от"?) требования (отвечает на вопрос, как ПО должно взаимодействовать с пользователем, чтобы требования были "решены", и чтобы оптимально, и универсально, и расширябельно), то архитектура "решает" интерфейс (отвечает на вопрос, как должен быть написан код, чтобы он давал такой интерфейс, и чтобы понятно, и удобно, и нетрудоемко, и, опять же, универсально и пр.).
Кажется, у нас разное восприятие окружающего мира. И языки. И страны. И планеты разные наверно... Поверьте, ирония и наезд — не синонимы. В общем регайте UIDD(tm) (UI-Driven-Development) и в проповедники. Агилисты вас как своего примут.
Re[12]: Просветите про роль требований в проектировании, пли
Здравствуйте, Sinix, Вы писали:
S>Аноним, если вы сознательно троллите — так и напишите — я не буду разговаривать с вами как с адекватным человеком. Если нет — постарайтесь читать то что вам пишут, ладно?
1. Охота на троллей для меня — как охота на ведьм. Казалось бы, думаешь, что человек бесцельно жрет твое внимание — так проходи мимо, но нет, надо обязательно гавкнуть. А те, кто гавкает, обычно такого ума, что все, что не понимают, записывают в троллинг. А понимают они мало что, в силу той же причины. Вас в виду не имею, а так, объясняю свою позицию. Вы пошутили — ну, я пошутил в ответ. Но в главном — как вы это назвали, UIDD — я серьезен.
2. Можно показать на то, что я, по-вашему, невнимательно прочитал? Я перечитаю.
S>>>Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намногобольше b"? Вы уж определитесь пожалуйста. А>>Слюшай, дарагой, посмотри на значок, да? Вот какой канэц у этого значка бальшой, так и прыоритет с этого канца бальшой, савсэм бальшой. Огромный прыоритет, во какой! Так понял, да?
S>Тут у нас обычное взаимонедопонимание. У меня "одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет" воспринимается как "следующее приоритетней предыдущего". А "а не просто больше, а намногобольше b" воспринимается соответственно наоборот. Замяли, ок?
Лол. Ну да, недопонимание. Я имел в виду, что поскольку каждое следующее менее приоритетное, а двигаться надо от менее приоритетных вещей к более приоритетным, то значок еще и показывает направление движения. В общем, бывает. Проехали.
А>>"Что это шумит? Во-до-пад!" A>> Если интерфейс "решает" (как-то не по-русски, может стоило написать "разрешает от"?) требования (отвечает на вопрос, как ПО должно взаимодействовать с пользователем, чтобы требования были "решены", и чтобы оптимально, и универсально, и расширябельно), то архитектура "решает" интерфейс (отвечает на вопрос, как должен быть написан код, чтобы он давал такой интерфейс, и чтобы понятно, и удобно, и нетрудоемко, и, опять же, универсально и пр.).
S>Кажется, у нас разное восприятие окружающего мира. И языки. И страны. И планеты разные наверно... Поверьте, ирония и наезд — не синонимы. В общем регайте UIDD(tm) (UI-Driven-Development) и в проповедники. Агилисты вас как своего примут.
Зачем мне его регать, и зачем что-то проповедовать? У меня другой бизнес. Я объяснил свою позицию, почему я считаю, что UI надо заниматься до архитектуры, так? Вы вопросы задали — я ответил. Сделал все, что мог. Не могли бы теперь вы объяснить свою позицию? Согласны, не согласны, почему?
Re[13]: Просветите про роль требований в проектировании, пли
Здравствуйте, Аноним, Вы писали:
А>Лол. Ну да, недопонимание. Я имел в виду, что поскольку каждое следующее менее приоритетное, а двигаться надо от менее приоритетных вещей к более приоритетным, то значок еще и показывает направление движения. В общем, бывает. Проехали.
Тьфу ты, черт! Теперь я сам попутал. От более приоритетных вещей надо двигаться к менее приоритетным. Просто по определению. Надеюсь, теперь тема стрелок окончательно исчерпана.
Re[7]: Просветите про роль требований в проектировании, плиз
(в конце поста. У него был еще один пост на эту тему, но лень искать).
О высокой важности UI хорошо написали 37 Signals (авторы RubyOnRails) в своей книге Getting Real (в этой книге много и других очень грамотных идей).
О требованиях к архитектуре хорошо написал Ричардом П. Гэбриелом в принципах (распечатал и повесил перед глазами). Кратко: архитектура должна быть простой.
О требованиях к коду хорошо написал МкКоннел в книге Совершенный код
А>>Моя формула девелопмента: требования >> UI >> архитектура >> код. A>Согласен. Именно к этому я сейчас и прихожу.
О Вас двое
Aikin, спасибо за ссылки на пост IB и на Гэбриэла. Оказывается, я скорее сторонник MIT. За "Неправильный дизайн категорически запрещён." готов ставить памятник.
Вообще сам спор бессмысленен — всё равно что сравнивать превосходство тактики над стратегией. Попытаюсь держаться корректно, хотя когда речь идёт о несовпадении базовых принципов всё неизменно скатывается к разборкам в духе "атцтой твой Гэбриэл". Попробуем так не говорить
Может, дело именно в отношении к коду и к себе. Я ценю своё время. Я стараюсь не делать временных решений, ибо прекрасно понимаю, что их придётся исправлять либо мне, либо, что ещё хуже — другим людям, за что мне будет сильно стыдно. Я не могу себя убедить в том, что построенная на краткосрочных требованиях архитектура будет красивой и стабильной. Посему с лёгкой долей иронии отношусь к агилистам вообще и к подходу в стиле "спроектируем гуй — дальше будем думать о архитектуре и коде".
Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней.
Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё. Что называть "качественной отстоявшейся архитектурой" — другой вопрос. Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области. Более-менее объективные критерии наблюдаются только в последнем варианте, впрочем к самому DDD тоже есть куча вопросов, начиная с того что "DDD — это не методология, а скорее стиль мышления" и заканчивая любовью к орм-ам и постоянными попытками протянуть внуть доменной модели бизнес-логику.
Где-то выше я приводил примитивнейший подход к разбиению клиента на отдельные блоки. К такому в принципе низзя прийти если танцевать от требований, интерфейса, критериев надёжности системы и всего прочего. Тем не менее, он работает и решает кучу проблем из коробки — в том числе и задачу разделения представления и логики работы клиента.
Ребят, вот вы утверждаете, что приходите к архитектуре через гуй и требования. Приведите пример, что у вас получается в результате — чтобы было о чём предметно поговорить. Потому что иначе мы так и будемгнуть друг перед другом пальцы и гнать всякую пургу (я и о себе тоже, не обижайтесь ).
Re[13]: Просветите про роль требований в проектировании, пли
Мои извинения Аноним'у, слегка отвык от адекватных собеседников... ужс-ужс...
А>2. Можно показать на то, что я, по-вашему, невнимательно прочитал? Я перечитаю.
Изначально имелось ввиду моё непонимание стралочек (уже замяли ). Но можно притянуть за уши и мой коммент насчёт изоляции проблем с UI:
Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...
Просто в моём восприятии конечный продукт — очень сложная штука, и внешние интерфейсы — это нечто вроде вершины айсберга, которые не могут (да и не должны) определять логику работы. Согласитесь, при таком подходе кажется странным проектировать систему на основе требований. Ведь требования в основе своей есть описание тех самых внешних интерфейсов, и никакой значимой информации о внутренностях "идеальной системы" из них не вытрясешь.
Ну ведь глупо рассматривать горы функционала, внутренние структуры данных, составные части, ту же многозвенку и много чего ещё со стороны потребностей пользователя, точнее со стороны взаимодействия с пользователем. Оно ему вообще ведь не надо. 1с хватит. Или ацесса. Или фокспро. Или вообще экселя.
Кстати на последнем вообще крышесносящие штуки творятся — вплоть до многопользовательского составления расписаний. Из того что приходилось делать самому — сводка по штатному расписанию, построение/сортировка/фильтрация взвешенных графов по матрицам и построение дендрограмм (только не спрашивайте что это такое и как оно делается — мне до сих пор тот ужас вспоминать не хочется). Но это так, офтоп
Re[9]: Просветите про роль требований в проектировании, плиз
Здравствуйте, Sinix, Вы писали:
А>>>Моя формула девелопмента: требования >> UI >> архитектура >> код. A>>Согласен. Именно к этому я сейчас и прихожу. S>О Вас двое
Заметь я еще не преверженец этой идеи, но жизнь и опыт приводит именно к ней.
S>Aikin, спасибо за ссылки на пост IT и на Гэбриэла.
Не за что.
S>За "Неправильный дизайн категорически запрещён." готов ставить памятник.
Что есть правильный/неправильный дизайн? Продай пару пробных камней.
S>Может, дело именно в отношении к коду и к себе. Я ценю своё время. Я стараюсь не делать временных решений, ибо прекрасно понимаю, что их придётся исправлять либо мне, либо, что ещё хуже — другим людям, за что мне будет сильно стыдно.
Аналогично, коллега. Но вышеописанная цепочка ни в коем случае не провоцирует временные решения. Она просто ставит архитектуру на третье место (код (т.е. поспешные решения) имеет еще меньший приоретет).
Если перефразировать эту цепочку, то будет следующее:
1) Что должно делать приложение
2) Что пользователи будут видеть
3) Насколько сложно вносить в приложение изменения
4) Насколько сложно вносить в приложение изменения (ч2)
Ставить 3-4) выше 2), а уж тем более 1) ... (продолжишь сам).
S> Я не могу себя убедить в том, что построенная на краткосрочных требованиях архитектура будет красивой и стабильной.
Красивой -- легко (это моя цель).
Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ! Невозможно предсказать требования. Это нужно написать на стене красной краской: Невозможно предсказать требования.
Год назад я потратил дополнительное время (+30% времени таска) на реализацию очень удобной и красивой архитектуры для части системы. Вылизал ее.
Буквально через пол года заказчик упростил модель отображения этой части, отказался от ряда дополнительной информации.
Моя архитектура не подкачала -- адаптировалась под изменения, но стала слишком сложна для решаемой задачи. Стала "путаться под ногами".
3 месяца я поддерживал эту архитектуру, пока не решился и не выкосли ее нафиг, заменив на менее универсальную, но много более простую.
S>Где-то выше я приводил примитивнейший подход к разбиению клиента на отдельные блоки. К такому в принципе низзя прийти если танцевать от требований, интерфейса, критериев надёжности системы и всего прочего. Тем не менее, он работает и решает кучу проблем из коробки — в том числе и задачу разделения представления и логики работы клиента.
Хмм, есть мировые практики, опыт программистов, книжки по архитектуре... Почему мы должны нащупывать архитектуру как слепые котята? Мне нравится многослойная архитектура. Я ее и исползую.
S>Ребят, вот вы утверждаете, что приходите к архитектуре через гуй и требования. Приведите пример, что у вас получается в результате — чтобы было о чём предметно поговорить. Потому что иначе мы так и будемгнуть друг перед другом пальцы и гнать всякую пургу (я и о себе тоже, не обижайтесь ).
Я не робот чтобы работать по алгоритму "придти к архитектуре через гуй и требования". Процесс намного сложнее.
Можно сказать, что я решаю проблему комплексно (требования+UI+архитектура), что прохожу несколько циклов (требования->UI->архитектура->требования->UI->архитектура->требования->UI->архитектура->...) Но это все равно будет не всей правдой.
Правда находится в другой области: "требования приорететнее UI приорететнее архитектуры".
СУВ, Aikin
S> Посему с лёгкой долей иронии отношусь к агилистам вообще и к подходу в стиле "спроектируем гуй — дальше будем думать о архитектуре и коде".
Забудь про Aigle. Судя по всему ты не так его понял.
S>Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней.
Зачем кидаться пустыми и вкорне неверными фразами?
S>Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё. Что называть "качественной отстоявшейся архитектурой" — другой вопрос. Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области. Более-менее объективные критерии наблюдаются только в последнем варианте, впрочем к самому DDD тоже есть куча вопросов, начиная с того что "DDD — это не методология, а скорее стиль мышления" и заканчивая любовью к орм-ам и постоянными попытками протянуть внуть доменной модели бизнес-логику.
Бла-бла-бла и куча красивых лозунгов.
Re[10]: Просветите про роль требований в проектировании, пли
О — пошли аргументы Ничего, что чуть претасую порядок ответов?
S>>За "Неправильный дизайн категорически запрещён." готов ставить памятник. A>Что есть правильный/неправильный дизайн? Продай пару пробных камней.
Имелось в виду противопоставление
"Простой дизайн немного лучше, чем правильный."
-и-
"Неправильный дизайн категорически запрещён."
Из этих двух утверждений я выберу именно второе. Про пример — пару страниц выше я приводил пример разбиения программы независимо от требований. Это разбиение будет долгим и стабильным и не зависит от технологий реализации. Это "правильный" дизайн. "Неправильный" дизайн — хардкодить в контроллере структуру гуя, или держать в нём классы из конкретного фреймворка (допустим, wpf commands) или вообще не выделять логику в отдельный класс, или держать её в обработчиках событий _отдельных_ контролов (как Аноним с OnMenu предлагал). Могу ещё — один и тот же пример подсовываю не из недостатка воображения, а чтобы не плодить сущностей.
S>> Я не могу себя убедить в том, что построенная на краткосрочных требованиях архитектура будет красивой и стабильной. A>Красивой -- легко (это моя цель). A>Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ! Невозможно предсказать требования. Это нужно написать на стене красной краской: Невозможно предсказать требования.
Собсно топик и заводился ради вопроса "какого архитектура строится от требований — она ж не будет стабильной!" На шестой странице мне отвечают "Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ!". Как забавно устроены люди... (с).
A>Если перефразировать эту цепочку, то будет следующее: A>1) Что должно делать приложение A>2) Что пользователи будут видеть A>3) Насколько сложно вносить в приложение изменения A>4) Насколько сложно вносить в приложение изменения (ч2)
A>Ставить 3-4) выше 2), а уж тем более 1) ... (продолжишь сам).
Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями? И это не основание кричать про "НИ ПРИ КАКОМ ПОДХОДЕ!".
И плиз, не сводите всё к крайностям. Стабильность архитектуры определяется её возможности адаптироваться в заранее определённом диапазоне условий, а не умением работать где угодно и с кем угодно.
A>Я не робот чтобы работать по алгоритму "придти к архитектуре через гуй и требования". Процесс намного сложнее. A>Можно сказать, что я решаю проблему комплексно (требования+UI+архитектура), что прохожу несколько циклов (требования->UI->архитектура->требования->UI->архитектура->требования->UI->архитектура->...) Но это все равно будет не всей правдой.
A>Правда находится в другой области: "требования приорететнее UI приорететнее архитектуры".
И снова мы оба гнём пальцы. Сила — она в ньютонах Ну разверну я вашу цепочку как "архитектура приорететнее требований приорететнее UI". Что изменится? Хотите обсуждения — давайте конкретику.
S>>Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней. A>Зачем кидаться пустыми и вкорне неверными фразами?
А это был disclaimer
S>>Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё. Что называть "качественной отстоявшейся архитектурой" — другой вопрос. Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области. Более-менее объективные критерии наблюдаются только в последнем варианте, впрочем к самому DDD тоже есть куча вопросов, начиная с того что "DDD — это не методология, а скорее стиль мышления" и заканчивая любовью к орм-ам и постоянными попытками протянуть внуть доменной модели бизнес-логику. A>Бла-бла-бла и куча красивых лозунгов.
И снова мы гнём пальцы... Ну вот зачем вы так?
Re[11]: Просветите про роль требований в проектировании, пли
Здравствуйте, Sinix, Вы писали:
S>Собсно топик и заводился ради вопроса "какого архитектура строится от требований — она ж не будет стабильной!" На шестой странице мне отвечают "Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ!". Как забавно устроены люди... (с).
Раз это главный вопрос топика, то поднимем его наверх.
Давай сначала уточним. Какая архитектура имеется ввиду?
Есть (утрированно) высокоуровневая, среднеуровневая, средненизкоуровневая, низкоуровневая, низконизкоуровневая, ... архитектура. По убыванию "уровня": разбивка на сборки, нэймспэйсы, классы, методы.
Чем выше находится конкретный элемент, тем сложнее его изменять, но, другой стороны, он меньше подвержен влиянию изменению требований.
Так вот. Стабилизировать разбиение на сборки и неймспэйсы в большинстве случаев удается. Классы и методы -- нет.
S>Имелось в виду противопоставление S>"Простой дизайн немного лучше, чем правильный." S>-и- S>"Неправильный дизайн категорически запрещён."
В первом случае используются понятия "субъективно простой" и "субъективно правильный" дизайн. Найти (золотую) середину между ними можно.
Но в твоем утверждении используется абсолютное понятие "неправильный дизайн". Поэтому мой вопрос остается в силе
S>Из этих двух утверждений я выберу именно второе. Про пример — пару страниц выше я приводил пример разбиения программы независимо от требований. Это разбиение будет долгим и стабильным и не зависит от технологий реализации. Это "правильный" дизайн. "Неправильный" дизайн — хардкодить в контроллере структуру гуя, или держать в нём классы из конкретного фреймворка (допустим, wpf commands) или вообще не выделять логику в отдельный класс, или держать её в обработчиках событий _отдельных_ контролов (как Аноним с OnMenu предлагал). Могу ещё — один и тот же пример подсовываю не из недостатка воображения, а чтобы не плодить сущностей.
Ок, пришло требование: при закрытии окна пользователем спрашивать действительно ли он хочет это сделать. Куда будет помещена эта логика (предполагается, что дизайн уже "правильный", т.е. содержит Контроллеры и прочую атрибутику)?
S>Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями?
А от чего еще его строить. Предположения заказчика и мой собственный опыт это все что у меня есть.
S>И плиз, не сводите всё к крайностям. Стабильность архитектуры определяется её возможности адаптироваться в заранее определённом диапазоне условий, а не умением работать где угодно и с кем угодно.
Что будешь делать, когда через 2 года потребуется функционирование вне "заранее определённом диапазоне условий"? (отвечать лучше на следующий вопрос)
S>И снова мы оба гнём пальцы. Сила — она в ньютонах Ну разверну я вашу цепочку как "архитектура приорететнее требований приорететнее UI". Что изменится? Хотите обсуждения — давайте конкретику.
К вам приходит требование (сферическое в вакууме) которое требует переделки архитектуры. Ваши действия?
S>>>Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней. A>>Зачем кидаться пустыми и вкорне неверными фразами? S>А это был disclaimer
С моей стороны показалось, что это наезд Ибо все что ты перечисил мне критично.
A>>Бла-бла-бла и куча красивых лозунгов. S>И снова мы гнём пальцы... Ну вот зачем вы так?
Потому что ты написал вкорне неверно. S>>>Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё.
Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить... S>>>анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области.
формирование предметной области невозможно без анализа требований. С другой стороны, после анализа требований предметная область получится сама собой.
Забвать на архитектуру -- вообще ересь. S>>> Более-менее объективные критерии наблюдаются только в последнем варианте
Голые слова.
Re[12]: Просветите про роль требований в проектировании, пли
A>Давай сначала уточним. Какая архитектура имеется ввиду? A>Есть (утрированно) высокоуровневая, среднеуровневая, средненизкоуровневая, низкоуровневая, низконизкоуровневая, ... архитектура. По убыванию "уровня": разбивка на сборки, нэймспэйсы, классы, методы. A>Чем выше находится конкретный элемент, тем сложнее его изменять, но, другой стороны, он меньше подвержен влиянию изменению требований.
A>Так вот. Стабилизировать разбиение на сборки и неймспэйсы в большинстве случаев удается. Классы и методы -- нет.
Гммм... В моём понимании архитектура — это нечто описывающее абстрактную структуру системы. Если хотите — разделение на компоненты. Уровень компонентов и способ разбиения — это уже вопрос реализации. Другими словами архитектура отражает долгосрочные (стратегические) особенности работы.
Если вернуться к вашему вопросу то ответ будет таким: стабильными будут (точнее по возможности будут) внешние интерфейсы, способ разбиения и классы, отражающие архитектуру системы. Всякая воспомогательная шелуха и реализация актуальных требований наоборот должны быть легкозаменяемыми и не затрагивать архитектуру.
Можно даже сказать что архитектура ортогональна требованиям. Только это будет неправдой...
A>
S>>Имелось в виду противопоставление S>>"Простой дизайн немного лучше, чем правильный." S>>-и- S>>"Неправильный дизайн категорически запрещён." A>В первом случае используются понятия "субъективно простой" и "субъективно правильный" дизайн. Найти (золотую) середину между ними можно. A>Но в твоем утверждении используется абсолютное понятие "неправильный дизайн". Поэтому мой вопрос остается в силе
Я чесслово считал, что если взять "правильный" и "неправильный" в кавычки, никто не подумает что я абсолютизирую. Ошибся Не бывает абсолютно правильного и неправильного решения. Просто одно решение решает только текущую проблему, другое — текущую и ряд возможных проблем в будущем. Выбор решения — как всегда — управление рисками. Сравниваем _вероятностные_ потери от внесения изменений при "простом" решении и _текущие_ потери при "правильном" решении. Выбираем
А что, у нас уже изобрели другой метод оценки решений?
A>Ок, пришло требование: при закрытии окна пользователем спрашивать действительно ли он хочет это сделать. Куда будет помещена эта логика (предполагается, что дизайн уже "правильный", т.е. содержит Контроллеры и прочую атрибутику)?
Лехко — контроллер дёргает своё событие (скажем OnClosing), подписчики (допустим, та же форма) его обрабатывают. IoC в действии
Логика "если пользователь подтвердил — закрыть" живёт в контроллере. Способ подтверждения — дело гуя.
S>>Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями? A>А от чего еще его строить. Предположения заказчика и мой собственный опыт это все что у меня есть.
Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой).
Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс). Грубо говоря домен описывает пограничные условия, которые могут быть нарушены только при нарушении самой предметной области. Я не могу изложить всё так же ровно и гладко — почитайте "Domain-Driven-Design: Tackling the complicity in the heart of development". Только не воспринимайте всё близко к сердцу — Эванс отнюдь не идеал
Там есть пара интересных методик — от адаптации моделей при интервьюировании (слово-то какое гадкое...) до рекомендаций по использованию модели как словарика терминологии, как части документации, как сочетать DDD с методологиями и т.п. Читать стоит хотя бы для самообразования.
Модель предметной области не скажет вам ничего о конкретной деятельности заказчика. Зато она вам даст примерную модель данных (я не говорю о воспомогательных табличках). Терминология и связи между сущностями — это тоже очень много. Далее, сопоставляя требования с этой моделью вы увидите что часть идеально ложится на модель, а часть требует серьёзных переделок. Почти наверняка эти требования возникают когда заказчик хочет странного и скорее всего в первую очередь будут меняться в будущем. Ещё как вариант — эти требования не попадают в модель из-за того что вы что-то упустили при построении модели. Или заказчик (точнее, консультант) чего-то не знает в предметной области.
S>>И снова мы оба гнём пальцы. Сила — она в ньютонах Ну разверну я вашу цепочку как "архитектура приорететнее требований приорететнее UI". Что изменится? Хотите обсуждения — давайте конкретику. A>К вам приходит требование (сферическое в вакууме) которое требует переделки архитектуры. Ваши действия?
Консультация с заказчиком, уточнение требований, выделение причин (хочу потому что) и целей (хочу чтобы), пересмотр модели, оценка исправлений, повторная консультация (если требование мелкое — всё на месте), внесение изменений.
Сферическая проблема — сферичесикй ответ. Почти наверняка окажется что либо поменялась предметная область (ничего не поделаешь ) либо я неверно отразил её в модели, либо деятельность заказчика расширилась. Это объективные причины и их не проигнорируешь.
There is no silver bullet...
A>
A>>>Зачем кидаться пустыми и вкорне неверными фразами? S>>А это был disclaimer A>С моей стороны показалось, что это наезд Ибо все что ты перечисил мне критично.
Упс. Честно не хотел. Если бы можно было поправить пост — поправил бы. Можете поставить мне минус
S>>И снова мы гнём пальцы... Ну вот зачем вы так? A>Потому что ты написал вкорне неверно.
Давайте я выделю отдельные утверждения и поспорим по каждому.
...без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё.
A>Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить...
А где это не так... Или вы хотите сказать, что "возлюби ближнего" вас тоже раздражает? Я ж говорю — выбор подхода — это нечто близкое к религии. И защищается так же — священными войнами
Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области.
A>формирование предметной области невозможно без анализа требований. С другой стороны, после анализа требований предметная область получится сама собой.
Вы отделите _вашу_ предметную область — автоматизацию деятельности от предметной области деятельности _заказчика_. Я везде говорил именно о последней, наивно полагая что это очевидно. Вы ведь не будете утверждать, что в логистике или в делопроизводстве что-то изменится от желаний вашего заказчика?
A>Забвать на архитектуру -- вообще ересь.
Скажите это агилистам. Я естественно утрировал, но абсолютизация микроитераций, код как документация, верификация кода как проверка корректности проектирования, ориентация на решение текущих проблем заказчика — это не забивание на архитектуру?
Могу ещё Бека с Амблерсом поцитатить. Если выдирать с мясом — то там куча кусков где они рекомендуют не делать ничего если этого не хочет заказчик. Про их отношение к системному коду, собственным микрофреймворкам и т.п. — вообще молчу. Но agile — это хорошее забивание на архитектуру. Потому что оно как-никак работает.
Более-менее объективные критерии наблюдаются только в последнем варианте
A>Голые слова.
Гммм... для меня учёт реальных особенностей работы программы — довольно объективно. Чтобы не повторяться — уже писал про DDD выше в этом посте.
Re[13]: Просветите про роль требований в проектировании, пли
Здравствуйте, Sinix, Вы писали:
S>Гммм... В моём понимании архитектура — это нечто описывающее абстрактную структуру системы. Если хотите — разделение на компоненты. Уровень компонентов и способ разбиения — это уже вопрос реализации. Другими словами архитектура отражает долгосрочные (стратегические) особенности работы.
S>Если вернуться к вашему вопросу то ответ будет таким: стабильными будут (точнее по возможности будут) внешние интерфейсы, способ разбиения и классы, отражающие архитектуру системы. Всякая воспомогательная шелуха и реализация актуальных требований наоборот должны быть легкозаменяемыми и не затрагивать архитектуру.
У нас совершенно разные представления об архитектуре. Поэтому продолжать считаю неуместным.
Это представление, которое даёт информацию о компонентах составляющих систему, о взаимосвязях между этими компонентами и правилах регламентирующих эти взаимосвязи.
S>Сравниваем _вероятностные_ потери от внесения изменений при "простом" решении и _текущие_ потери при "правильном" решении. Выбираем
Так вот мой опыт говорит, что простое решение чаще всего предпочтительнее.
A>>Ок, пришло требование: при закрытии окна пользователем спрашивать действительно ли он хочет это сделать. Куда будет помещена эта логика (предполагается, что дизайн уже "правильный", т.е. содержит Контроллеры и прочую атрибутику)? S>Лехко — контроллер дёргает своё событие (скажем OnClosing), подписчики (допустим, та же форма) его обрабатывают. IoC в действии S>Логика "если пользователь подтвердил — закрыть" живёт в контроллере. Способ подтверждения — дело гуя.
Ну вот. Наплодили кучу сущностей вместо того, чтобы выбрать простое решение: передать всю работу во вью. Вот когда во время закрытия понадобиться что-то большее чем вопрос пользователю, тогда выступает "тяжелая артелерия".
S>Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой). S>Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс).
Это те же предположения заказчика.
S>Консультация с заказчиком, уточнение требований, выделение причин (хочу потому что) и целей (хочу чтобы), пересмотр модели, оценка исправлений, повторная консультация (если требование мелкое — всё на месте), внесение изменений.
Т.е. изменится архитектура системы. Так? Получается, что изменение требований вызвали изменение архитектуры. Значит они первичны.
A>>Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить... S>А где это не так... Или вы хотите сказать, что "возлюби ближнего" вас тоже раздражает? Я ж говорю — выбор подхода — это нечто близкое к религии. И защищается так же — священными войнами
А где я сказал ,что меня это раздражает? Некоторые мне даже нравятся (я же об этом сказал). Дело в том, что от этих очевидных вещей практического толку ноль
S>
Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области.
A>>формирование предметной области невозможно без анализа требований. С другой стороны, после анализа требований предметная область получится сама собой. S>Вы отделите _вашу_ предметную область — автоматизацию деятельности от предметной области деятельности _заказчика_. Я везде говорил именно о последней, наивно полагая что это очевидно. Вы ведь не будете утверждать, что в логистике или в делопроизводстве что-то изменится от желаний вашего заказчика?
А как ты узнаешь о предметной области? Однажды утром проснешься со всем необходимым объемом знаний?
A>>Забвать на архитектуру -- вообще ересь. S>Скажите это агилистам. Я естественно утрировал, но абсолютизация микроитераций, код как документация, верификация кода как проверка корректности проектирования, ориентация на решение текущих проблем заказчика — это не забивание на архитектуру?
Нет. В конце каждой микроэтерации запланирована фаза рефакторинга. В начале каждого изменения проводится анализ системы с точки зрения легкого добавление новой фичи. Если добавить ее сложно, то система приводится к виду, в котором ее просто добавить.
S>Могу ещё Бека с Амблерсом поцитатить. Если выдирать с мясом — то там куча кусков где они рекомендуют не делать ничего если этого не хочет заказчик. Про их отношение к системному коду, собственным микрофреймворкам и т.п. — вообще молчу. Но agile — это хорошее забивание на архитектуру. Потому что оно как-никак работает.
Было бы неплохо. Только вот боюсь, что цитата оторванная от конекста будет бесполезной (а контекстом может оказаться вся книга).
Re[14]: Просветите про роль требований в проектировании, пли
Уппс... во время правки потерялось одно слово — "Уровень компонентов и способ разбиения — это уже вопрос реализации архитектуры." Вот так точнее будет. Согласитесь, когда мы обсуждаем архитектуру мы не думаем о классах, методах и неэмспейсах а используем несколько более абстрактное понятие. Пойдёт?
Теперь особой разницы между "архитектура — это нечто описывающее абстрактную структуру системы" и "Это представление, которое даёт информацию о компонентах... взаимосвязях...правилах регламентирующих эти взаимосвязи." не наблюдается. Просто ваше определение более формально и детально.
A> S>>Сравниваем _вероятностные_ потери от внесения изменений при "простом" решении и _текущие_ потери при "правильном" решении. Выбираем A>Так вот мой опыт говорит, что простое решение чаще всего предпочтительнее.
Вот видите — у нас даже базовые подходы различаются. У вас — "опыт". У меня — явно выделенные факторы их обективная оценка и соотнесение. И кто вам сказал что "правильное" решение будет сложным?
S>>Лехко — контроллер дёргает своё событие (скажем OnClosing), подписчики (допустим, та же форма) его обрабатывают. IoC в действии S>>Логика "если пользователь подтвердил — закрыть" живёт в контроллере. Способ подтверждения — дело гуя. A>Ну вот. Наплодили кучу сущностей вместо того, чтобы выбрать простое решение: передать всю работу во вью. Вот когда во время закрытия понадобиться что-то большее чем вопрос пользователю, тогда выступает "тяжелая артелерия".
Вы передёргиваете. Добавилось одно событие. За счёт этого у нас логика по-прежнему отведена от представления. Что это даёт: снижена стоимость сопровождения UI (меньше проверок при реализации альтернативного UI/изменении старого), упрощается тестирование, возможен полный code coverage, проще разделять ответственность между разработчиками. Я в таком духе ещё долго могу
S>>Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Ещё вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой).
(добавил выделенное) S>>Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс). A>Это те же предположения заказчика.
Это разные вещи.
Вы отделите _вашу_ предметную область — автоматизацию деятельности от предметной области деятельности _заказчика_. Я везде говорил именно о последней, наивно полагая что это очевидно. Вы ведь не будете утверждать, что в логистике или в делопроизводстве что-то изменится от желаний вашего заказчика?
A>Т.е. изменится архитектура системы. Так? Получается, что изменение требований вызвали изменение архитектуры. Значит они первичны.
Уже отвечал.
Почти наверняка окажется что либо поменялась предметная область (ничего не поделаешь ) либо я неверно отразил её в модели, либо деятельность заказчика расширилась. Это объективные причины и их не проигнорируешь.
There is no silver bullet...
Причина изменения в требованиях — изменение предметной области. Точнее так: объективное изменение тербований — признак изменения в предметной области. Что приоритетней с этой точки зрения?
A> A>>>Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить... S>>А где это не так... Или вы хотите сказать, что "возлюби ближнего" вас тоже раздражает? Я ж говорю — выбор подхода — это нечто близкое к религии. И защищается так же — священными войнами A>А где я сказал ,что меня это раздражает? Некоторые мне даже нравятся (я же об этом сказал). Дело в том, что от этих очевидных вещей практического толку ноль
Это как готовить... Для меня толку от неочевидных шаманских методик в XP — ноль. Но я не называю их бесполезными, а пытаюсь разобраться почему они не работают в конкретных ситуациях и как их собирались использовать авторы.
A>А как ты узнаешь о предметной области? Однажды утром проснешься со всем необходимым объемом знаний?
Если вы не читали Эванса — есть куча неявных источников информации о предметной области. Самый простой — обсуждение требований. Цель выделение того, что Эванс называет "неявным знанием" — той информации которая кажется очевидной специалистам и последние просто её не упоминают. Он приводит пример с расписанием авиаперевозок. Из требований выходило что-то типа "исходный-конечный аэропорт + время прилёта/отлёта". Во время собеседования было совершенно случайно выяснено, что вообще-то расписание определяется планом полёта, а его лучше рассматривать как последовательность четырёхмерных точек (3 координаты + время). Дальше выясняется о связи узловых точек с навигационными маяками и заранее утверждёнными трассами. И так далее.
Вся эта информация оказалась крайне важна, но в требованиях о ней не было ни слова. Эта информация определяется не пожеланиями заказчика, а предметной областью — она объективна. Если её не учитывать её на ранних этапах — она косвенно всплывёт позже через изменения требований, например в виде проверки соблюдения полётного плана или визуализации рейсов.
Именно такие требования чаще всего и приводят к изменению архитектуры.
Сама логика DDD безумно примитивна — заказчик в идеальном случае строит свои требования в ответ на изменения в окружающей среде. Так зачем моделировать среду косвенно, через требования заказчика, если можно моделировать её прямо?
Есть ещё куча способов изучения предментной области. Самые примитивные — консультация со сторонними специалистами/самостоятельное изучение.
A>Нет. В конце каждой микроэтерации запланирована фаза рефакторинга. В начале каждого изменения проводится анализ системы с точки зрения легкого добавление новой фичи. Если добавить ее сложно, то система приводится к виду, в котором ее просто добавить.
Это делается на каждой итерации. Т.е. вместо того, чтобы сразу строить "систему приближенную к идеалу" она строится мелкими-мелкими шажочками. Архтектуры как таковой здесь нет — вместо неё происходит рефакторинг кода в ответ на изменение требований. Такой рефакторинг не отражает какой-либо конечной цели, он бессистемен. Если учесть накладные затраты на каждую итерацию то постоянное изменение архитектуры вполне может оказаться дороже — особенно для больших проектов, из-за затран на коммуникацию и теоретической возможности изменения архитектуры всей системы в любой момент.
S>>Могу ещё Бека с Амблерсом поцитатить. Если выдирать с мясом — то там куча кусков где они рекомендуют не делать ничего если этого не хочет заказчик. Про их отношение к системному коду, собственным микрофреймворкам и т.п. — вообще молчу. Но agile — это хорошее забивание на архитектуру. Потому что оно как-никак работает. A>Было бы неплохо. Только вот боюсь, что цитата оторванная от конекста будет бесполезной (а контекстом может оказаться вся книга).
Угу. Будет ниже. Попробую не выдирать из контекста.
Re[15]: Просветите про роль требований в проектировании, пли
Поехали. Кент Бек, "Экстремальное программирование" (Амблерса под рукой нет). Скан с питерского издания, перевод адекватен Extreme Programming Explained от Addison-Wesley — могу поцитатить и оттуда. Естественно книга вводная, конкретных утверждений практически нет, цепляться не за что. Посоветуете талмуд посерьёзней?
Страница 61. Глава 8 "Базовые принципы":
Бизнес должен быстро определять, каким образом система будет полезной для него, и он должен возвращать разработчикам эти сведения в течение дней или недель, но не в течение месяцев или лет.
Меня подобные утверждения очень настораживают — я вижу в них попытку переложить всю ответственность на заказчика. Если случилось что-то непредвиденное — виноват будет он.
Приемлемая простота — необходимо решать каждую проблему так, как если бы ее можно было решить самым смехотворно простым способом. Времени, которое вы экономите на решении 98% проблем, для которых это утверждение является истинным, вполне хватает, чтобы справиться с решением оставшихся 2% проблем.
...
В рамках установившихся традиций мы приучены к тщательному планированию своих действий, мы привыкли проектировать код с расчетом на его дальнейшее повторное использование. Однако в рамках ХР огромные
усилия ... прикладываются для того, чтобы сегодня программист думал о решении только сегодняшних проблем и был уверен в том, что завтра в случае необходимости имеющийся код можно будет с легкостью усовершенствовать так, как этого требует складывающаяся ситуация. Экономика разработки программ, представленная в виде набора нескольких вариантов, приветствует данный подход.
Эти 98% "решённых" проблем висят дамокловым мечом — от них не избавились, их просто "замазали" временным решением — о чём собственно и написано. Кстати я не так уж и уверен насчёт соотношения 98/2.
Особенно понравился пассаж про не надо рассчитывать на дальнейшее использование и про приветствующую это дело экономику. Так и хочется постебаться про "код на выброс" — некорректно, а хочется ведь...
Страница 66:
Путешествие налегке — вы не можете нести с собой гору багажа и при этом двигаться быстро.
...
Члены команды ХР должны стать интеллектуальными кочевниками, в любую минуту готовыми быстро упаковать свои пожитки и следовать за пастухом. Пастухом в данном случае является дизайн, который развивается в ином направлении, чем это предполагалось ранее, или заказчик, который хочет развивать проект в ином направлении, чем это предполагалось ранее, или член команды, который решил уйти из проекта, или технология, которая подчас эволюционирует с головокружительной быстротой, или изменяющийся климат, в котором функционирует бизнес.
Ребят, если это не закладывание всей архитектуры проекта на сиюминутные требования заказчика/состав разработчиков/используемые технологии — то я последний баклан и не умею читать скрижали. Какого?...
Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.
А вот вам и долгожданный отказ от архитектуры — она не необходима для "удовлетворения нужд заказчика".
Ниже, на стр 91 (Глава 11 • Как это работает? — простой дизайн):
• вы привыкаете к постоянной переработке кода, благодаря чему внесение в дизайн системы не представляет для вас сложностей;
• вы обладаете понятной всеобщей метафорой, благодаря чему вы можете быть уверенными в том, что любые изменения в дизайне будут выполняться в рамках единого пути, сходящегося в одной точке;
• вы программируете не один, а с партнером, поэтому вы можете быть уверенными в том, что вы формируете простой дизайн, а не глупый дизайн.
Это действительно всё, за счёт чего гарантируется качество дизайна?
О архитектуре упоминается аж на 145-й странице из 212 (Глава 17 • Стратегия проектирования). Порадовало:
Частично архитектура выражается в системной метафоре. Если вы обладаете хорошей метафорой, каждый член команды может сказать, каким образом система работает как единое целое.
...
Лично я предпочитаю формировать упрощенную архитектуру на основе стоящих передо мной задач, а затем при необходимости вносить в нее изменения.
На этом собсно про архитектуру всё
Порадовало как в книге мягко обошли тему про фреймворки (стр 200. Глава 26 — ХР в работе):
Можно ли использовать ХР для разработки программных инфраструктур? Одно из правил ХР гласит, что вы должны удалять из системы любую функциональность, которая в данный момент не используется, если следовать этому правилу, то вы должны удалить всю инфраструктуру.
ХР не очень хорошо приспособлена для разработки кода, использование которого планируется не сейчас, а в дальнейшем.
...
В ХР мы занимаемся разработкой конкретных приложений. Если после нескольких лет постоянных переработок дизайна начинают вырисовываться некоторые универсальные абстракции общего использования, значит, настало время подумать о том, как сделать их более широко доступными.
Появление универсальных компонентов после нескольких лет постоянных переработок дизайна??? До меня обычно доходит раньше
Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...
Удачи...
Re[16]: Просветите про роль требований в проектировании, пли
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Sinix, Вы писали:
S>>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?
S>Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению. S>Т.е. архитектура — есть функция требований. Это аксиома.
Мнээ, плюс — функция технических ограничений, которые неплохо сразу принять во внимание, и _будущих_ требований, которые предположительно может быть возникнут. "Запас прочности" надо бы заложить в архитектуру, иначе что это за архитектура?
Re[3]: Просветите про роль требований в проектировании, плиз
Здравствуйте, Gaperton!
S>>>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?
S>>Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению. S>>Т.е. архитектура — есть функция требований. Это аксиома.
G>Мнээ, плюс — функция технических ограничений, которые неплохо сразу принять во внимание, и _будущих_ требований, которые предположительно может быть возникнут. "Запас прочности" надо бы заложить в архитектуру, иначе что это за архитектура?
О, здраствуйте Давно хотел пообщаться — мало здесь товарищей, что вплотную занимаются управлением проектами, мало
Пока из общения с товарищами выходит что проектирование чисто от требований — нормальный подход. Смущает две вещи — то, что требования направлены на решение текущих задач и строить на их основе архитектуру системы — как то не того...
и то, что эти вопросы в принципе не подымаются в "тру" методологиях — такие вопросы отдаются на откуп архитекторам (если он есть) или обходятся кучей методик (не будем о DDD — про неё даже Эванс не может уверенно сказать что оно такое, куда уж простым смертным )
Это я дурак и что-то упустил или это такая модель бизнеса — "Сделаем всё за деньги. Не понравилось — платите, не можете сформулировать хотелки — платите, ошиблись — платите"? Потому что я не могу больше придумать доводов, зачем так опровергать тот факт, что архитектура не может быть построена на информации о сиюминутных целях.
Только не уходите плиз, а то сначала спорят-спорят, потом говорят что не о чем спорить и предлагают
Re[4]: Просветите про роль требований в проектировании, плиз
Здравствуйте, Sinix, Вы писали:
S>Только не уходите плиз, а то сначала спорят-спорят, потом говорят что не о чем спорить и предлагают
P.S. Спорить-то есть о чем, вот только я не вижу смысла в этом споре. Мы уж слишком с разных сторон подходим к проблеме. (перечитай два последних моих поста по теме, если будут новые мысли, то вполне может подискутировать)
Re[15]: Просветите про роль требований в проектировании, пли
Здравствуйте, Sinix, Вы писали:
S>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...
Гарантия там в том, что несмотря ни на что, проект все время будет работать. И стоимость внесения изменений будет примерно ленейна. В отличии от XP, та методология, которую ты называешь "правильной", выдаст продукт скорее всего дешевле и с более низкой итоговой ценой изменений, но в некоторых случаях проект просто не доживет до релиза (т.к. зациклится на сборе требований по причине их быстрого устаревания). Для таких случаев и придуман XP, можно ругать его безоглядное применение, можно ругать его апологетов за излишнюю религиозность, но факт есть факт, есть ниша, где XP работает лучше (заказчик и исполнитель более удовлетворены результатом проекта).
Оффтоп, наблюдение:
Если есть люди, которые реально заинтересованы в проекте и имеют достаточно полномочий, проект будет сделан по любой методологии или в ее отсутствии. Если таких людей нет или они не обладают достаточными полномочиями — никакая методология, архитектура или безупречный код проект не спасут
Автор(ы): С. Макконнелл
) либо я неверно отразил её в модели, либо деятельность заказчика расширилась. Это объективные причины и их не проигнорируешь.
