Просветите про роль требований в проектировании, плиз - Управление проектами

А>Я заранее прошу прощения за такую непонятливость, но я не понимаю как вы употребляете некоторые слова. UI это явление. Дизайн UI (в данном случае) это процесс. Приоритет чего бы то ни было — атрибут процесса. Поэтому, "UI — ... приоритет" для меня бессмыслица. Я не мог такого сказать. Я мог сказать (и на самом деле сказал), что "дизайн UI имеет приоритет".

Не придирайтесь пожалуйста к словам. Само собой не имелся в виду не просмотр UI или использование UI, а именно дизайн. При том что дизайн — это по русски тоже сущность

. Так что — разработка дизайна.

А>Далее, основным приоритет быть никак не может. Приоритет — сравнительная характеристика. Изначально приоритет мог быть только бОльшим. Так и говорили: А имеет приоритет перед Б. Или, Б имеет приоритет перед А. В компьютерном языке, однако, приоритет стал использоваться как синоним порядка следования, и он может быть как бОльшим, так и мЕньшим, а также наибольшим или наименьшим, в крайнем случае — выраженным численно.

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

А>Таким образом, мой тезис — "дизайн UI должен иметь приоритет перед архитектурным проектированием". Это не придирки. Половина глупых споров могла бы никогда не возникнуть, если бы люди точно писали и точно читали.

Именно так он всеми и был понят. А значит всё-таки придирки и демагогия.

А>Примем, что приоритет это порядок следования (как нормальные компьютерщики). Может ли быть приоритет функцией требований? Я считаю, нет.

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

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

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

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

Дружно планируем совместное распитие напитков? Или какие активности мы будем включать в этот процесс?

А> Теперь, ваш тезис. Пусть приоритет дизайна зависит от требований (функционально или не функционально — неважно). Из этого следует что результат дизайна предполагается ненулевым, иначе какой смысл давать дизайну приоритет? Так? А раз так, значит, дизайнерам есть что сказать о продукте. Значит, UI какой-никакой есть.

У Google есть UI. Никто не спорит.

А> Ну, а дальше все просто: вы о чем думаете, о пользователе или о технологиях? Вот и приоритеты такие же. Я всегда думаю о пользователе. Допустим, стоит задача сделать продукт для... недалеких чайников. Это один случай. Или для умных инженеров, которые хотят, чтобы было эффективно работать, пусть даже ценой того, что сложно разобраться. Это другой случай. Возможно, архитектура для этих двух случаев будет разная. Поэтому, design comes first. Очевидно, что сторонники противоположного подхода — техноцентристы, которые думают сначала о том, MS SQL или Oracle, а уже потом про тех, кто будет оплачивать процесс создания.

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

VGn>>Для меня UI — всего лишь один из внешних аспектов системы, которые собственно и определяют пользовательский (клиентский) функционал.

А>Аспект — это взгляд [откуда-то]. Примерно, то же, что и точка зрения. UI не может быть точкой зрения и я опять полностью потерял нить рассуждений. Допустим, мы смотрим на систему, и на все закрываем глаза, кроме UI. Видим только его. Как это может что-то определять?

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

А>Я согласен с одним: что UI, не будучи аспектом, а будучи свойством системы, определяет пользовательский функционал.

Свойство — тоже спорный термин.
Свойства: синий, зелёный, мокрый, мягкий.
"
— Ваша система какая?
— UI
— О как интересно!
"

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

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

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

Это всего лишь ваш взгляд (аспект

).

А>Что жизнь неоднократно и доказала. UNIX, говорят, архитектурно превосходил винду, как бог черепаху. Но унихисты всегда давали приоритет архитектуре, а БГ говорил — если что-то как следует не работает, пусть оно хотя бы хорошо выглядит. Чем закончилось, знаете?

Знаю. Многолетним превосходством UNIX на серверных системах. Не замерли бы в развитии, вообще задавили бы нафиг. На суперкомпутерах до сих пор винды в аутсайдерах. Потому как там UI приоритет имеет хорошо если сто двадцатый.

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

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

А>>Не-не-не, теперь все, ждем другого собеседника.
VGn> Да ради бога. Всем привет.
VGn> Лично я вижу здесь просто логическую ошибку:
VGn>

VGn> Функция от требований — UI. Функция от всех аспектов UI — архитектура

VGn>Эти утверждения абсолютно верны, но ничто не указывает на то, что UI — единственный аргумент архитектуры. Необходимое не есть достаточное.

Софт с одним и тем же UI может иметь разную архитектуру. Десктопные медиаплееры имеют одни и теже кейсы, требования, и имеют разную архитектуру — достаточно взглянуть на media engine, лежащие в их основе (в open source их дохрена), и посмотреть, что общего они между собой имеют. Небо и земля — сравни например Helix DNA Client и gstreamer. При этом, плеера, построенные на них выглядят примерно одинаково и умеют примерно одно и то же.

Софты с разными use cases и соответственно UI могут быть построены на базе одной и той же архитектуры. На базе gstreamer можно делать интернет-радио, десктопный медиаплеер, стриминг-сервер, конвертер видеоформатов, программу обработки изображений, DVD-проигрыватель, и даже IP-телефон. Не все архитектуры одинаково хороши. На базе Helix DNA Client хорошо получается в основном потоковый медиаплеер. Медиадвижок MythTV вообще не пригоден к повторному использованию.

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

Вывод разумный человек из этого может сделать только один — UI вообще не является существенным фактором, влияющим на архитектуру. Даже тогда, когда все приложение из него состоит. Веб-приложения google, даже имеющие развитый GUI — такие как google documents, имеют весьма интереcную архитектуру. Отличную от MS Office. Несложно понять, почему — а гуй у них близкий), и от zoho office (тоже интернет-офис, но в основе совершенно другие базовые технологии).

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

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

VGn>Именно так он всеми и был понят. А значит всё-таки придирки и демагогия.

Вот, видишь какая содержательная беседа получается?

А ведь я знал, что меня пытаются втянуть в сессию группового словесного онанизма под эгидой пионерской организации, и именно поэтому отказался. Смотри, до чего вы уже договорились:

А>>Что жизнь неоднократно и доказала. UNIX, говорят, архитектурно превосходил винду, как бог черепаху. Но унихисты всегда давали приоритет архитектуре, а БГ говорил — если что-то как следует не работает, пусть оно хотя бы хорошо выглядит. Чем закончилось, знаете?

VGn>Знаю. Многолетним превосходством UNIX на серверных системах. Не замерли бы в развитии, вообще задавили бы нафиг. На суперкомпутерах до сих пор винды в аутсайдерах. Потому как там UI приоритет имеет хорошо если сто двадцатый.

Превосходство Венды обусловлено в первую очередь бизнес-моделью Microsoft, и ее связями с OEMами, что давало в тот момент сильное преимущество. Причины в бизнесе, а не в "ориентации на UI" или архитектуре.

И второе, вот уж где UI совсем не имеет никакого отношения к архитектуре, так это в ОС.

Windows 95 и XP имеют практически одинаковый UI и look-and-feel, и совершенно разную архитектуру. Более того, есть window managers по Linux, которые дают практически тот же look-and-feel, как и винда.

Solaris, Linux, и MacOS имеют разную архитектуру, однако реализуют один и тот же POSIX. Выводы?

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

Я пас, извините. Отвечать получается долго и бесполезно.

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

NGG>>Если смотреть на ПО совсем цинично, то можно выделить две задачи, которые оно решает:
NGG>>1) представление данных и поддержка операций над ними;
NGG>>2) отображение данных пользователю и предоставление доступа к операциями над ними.

VGn>Это не задачи. Это всего лишь взгляд на реализацию. Не более.

Игра в слова?

Нет, это взгляд не на реализацию, а на ПО как таковое. Возможно вас смутило сочетания слов "задачи" и "решает".

Смысл моих слов прост до безумия:
1) ПО служит для манипулирования данными
2) ПО может иметь "морду лица", через которую пользователь получает доступ к этим данным и может как-то ими манипулировать.

VGn>>Это не задачи. Это всего лишь взгляд на реализацию. Не более.

А>Игра в слова?

А>Нет, это взгляд не на реализацию, а на ПО как таковое. Возможно вас смутило сочетания слов "задачи" и "решает".

Нет. Меня "смутило" слово "данные".
У пользователя обычно нет данных. Соответственно нет и операций над данными.
Ему это всё вообще не интересно.
Нет у него таких задач, и соответственно решать их ему не нужно.

Было в прошлом веке такое течение "искусство для искусства". Ваш подход чем-то его напоминает имхо.

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

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

S>Мне не нравится односторонний подход — либо представление данных (расскажите, как вы его понимаете — а то будем спорить впустую), либо UI. Во-первых жисть куда сложнее, во-вторых /*дело ленина*/ любая система живёт и развивается, приоритеты регулярно тасуются.

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

S>И получается, что сейчас труёвее "подход Sinix'a" или "подход Aikin'а/Анонима", поэтому сегодня танцуем от UI, а завтра от предметной области...

Ну, а куда деваться, если "жисть куда сложнее" любых теорий? :) Танцуем.

S>Коротко: Архитектура штука неповоротливая, но без неё тяжко.

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

Если есть архитектура, а вокруг одни обезъянки, продукт это не спасёт.

S>Точно так же не согласен с утверждением, что ООП рулит для отображения модели предметной области. Сорри за тыканье носом в историю, ... конкретнейший недостаток, когда нам нужно несколько представлений одних и тех же данных. DTO не от хорошей жизни появились.

Фраза "несколько представлений одних и тех же данных" требует уточнений, желательно с наглядными примерами, а то не стыковка понятий может возникнуть :)

DTO. Почему же не от хорошей... Хочешь типизацию (хорошую жизнь) и не хочешь тащить лишние данные (должна быть причина почему) — создай новый тип или "скакай" в мир без типизация, передавай нужные данные в массивах/коллекциях/{вставить нужное} и вынимай на другой стороне, доставая интерпретацию для этих данных из шляпы, как фокусник. Что удивительного?

S>Коротко: ООП эффективен для реализации поведения, а не для работы с представлением однородных данных. Я могу долго на эту тему распинаться, есть желание — продолжим.

Если просто "распинаться", то не стоит. Если есть что интересное сказать — то пожалуйста :)

S>Далее. Второй подход — типичная иллюстрация глобального "Code&fix". Кстати, вы привели замечательнейший пример рассуждений — не считая изначальной предпосылки, каждый шаг абсолютно логичен. В результате получается вывод, что на архитектуру проще забить, чем сделать её тру — она постоянно переделывается. Это дело неизбежно заканчивается горой костылей, поскольку каждый костыль куда быстрее и дешевле мегафреймворка. А в сумме?

А что в сумме? Даже интересно стало.

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

S>Тут мне конечно возразят, что микроитерации с рефакторингом спасут /*суверенную демократию*/ тру-команду. Расскажите мне, в чём смысл регулярнейше редизайнить горы кода без конечной цели, только ради того что чтобы сделать _текущий_ код как можно проще (мы всё ещё говорим о KISS?).

Sorry, на что именно так возразят? :)

Если уж речь зашла об айгл, то, насколько я понимаю, горы кода никто "не редизайнит без конечной цели". 1) Кода не гора — а только тот, что был написан, чтобы реализовать определённое требование, 2) цель — трезво посмотреть на то, что получилось, убрать дублирование и прочие запашки и привести код в соответствие с текущим видением архитектуры.
Это выглядит лучше, чем классический подход: "раз требование реализованно, значит код хорош — плюнули и забыли". Сомневаюсь, что кто-то будет рефакторить только из любви к этому искусству.

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

Представление — само по себе много кода. Могут требоваться не стандартные компоненты, состояния компонентов могут не тривиально зависеть друг от друга и т.д. В итоге вокруг представления создаётся набор "классов поддрежки" образующих модель этого представления и связующую логику (и где-то сбоку кастомные компоненты), в предыдущем сообщение я именно это называл "моделью UI". Она изолированна от "данных" и "логики" в той же степени, в какой изолированно "представление".

Мой тезис был: При изменении "требований к UI" может существенно меняться "модель UI" (но не модель предметной области, к которой приложил руку архитектор).

Теперь смотрим, что я писал:
NGGU>Поэтому тяжёлая артиллерия оказывается бесполезной, если UI состоит не из "типовых" форм. Точнее говоря, не бесполезной, а требующей большего вложения времени и/или средств, чем вариант, когда реализуется самое простое решение из возможных.

Итак, имеем альтернативы:
1) Каждая форма пишется будто с нуля с применением техники гавнокода (за пределы представления гавнокод не пускаем, конечно же). Получается дрянь, но достаточно быстро и работает. Т.к. отдельные формы чаще всего хорошо изолированы друг от друга, гавнокод не расползается в ширь и может быть легко выброшен и переписан.

2) Тоже самое, но стараемся гавнокода избегать и повозможности использовать существующий код. Без планового контроля грозит возникновением нескольких "кривых" недофреймворков для деланья одного и того же в рамках одного проекта и, возможно, появлением прикольных иерахий наследования.

3) Задумываемся о прекрасном и создаём мегафреймворк/инструментарий/докумнтацию, на основе которых определённый класс UI сторится достаточно быстро... Всё хорошо, но где найти того, кто сможет объять не объятное, чтобы потом не было мучительно больно от попыток реализовать уй не попадающий в класс поддреживаемых фреймвёрком уёв. Тем не менее тоже не плохой подход, если большинство морд однотипные.

"Бесполезность" возникает, если
— в команде нет человека съевшего не одну собаку на разработке аналогичных фреймворков
— если проекту уже не один год и нет явных причин почему это нужно делать (причину желательно в денежном эквиваленте)

S>Коротко: заменяем мантру "вы не следуете всем методикам XP" на "вы не разделяете логику и представление" — новая религия готова:)

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

Дня NotGonnaGetUs!

Тут не примиришь — это старый-старый холивар, что тянется ещё с вермён "cafedral vs bazaar" и "MIT vs Worse is Better". Всё давно уже сказано, одним товарищам нравится надёжность и они готовы платить за это соблюдением требований и ответственностью, другие тащатся от "путешествуй налегке". Каждому своё

Топик и так раздулся, буду краток

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

Такое элементарно организуется силами субд — в базе полные данные (соответствующим системам — доступ только через воспомогательные вьюхи/хранимки), а вот чтобы реализовать подобное, если у нас "СУБД как хранилище" и данными заведует аппсервер, придётся попотеть. Если от аппсервера не требуется изображать из себя СУБД в плане разруливания разрешений, транзакций, odbc и т.п. — тогда проще сразу повеситься.

2. "Это дело неизбежно заканчивается горой костылей, поскольку каждый отдельный костыль куда быстрее и дешевле мегафреймворка. А в сумме?" — куда-то потерялось слово "отдельный". Сорри

Дальше у нас обычнейший спор на тему "делать сразу и качественно" vs "нифига! надо будет — пофиксим, не надо — сэкономим бабки заказчика". Имхо, обсуждать бессмысленно. С замечаниями насчёт рефакторинга и отдельных методик из XP согласен — именно так оно и должно работать при устоявшейся архитектуре. Только в agile нет устоявшейся архитектуры, равно как и устоявшегося мнения по этому поводу. Если Амберс выступает за умеренный рефакторинг к месту, то у Бека постоянно натыкался на принцип "если что-то не нужно сейчас — выбрасываем". Постоянная подгонка архитектуры/дизайна под текущее состояние проекта больше навредит и проекту и архитектуре. Не согласны?

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

3. У нас явно различные понятия о представлении в UI. Или скорее, разные подходы к

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

У вас в представлении свалены в кучу функционал контроллера (хранение состояния/разруливание зависимостей между контроллерами) и функционал UI-фреймворка (биндинг к свойствам контроллера и нетривиальные контролы). Между тем контроллеру должно быть глубоко параллельно на модель UI. Контроллер — обычный класс со своими свойствами/методами/событиями и то как UI будет к ним обращаться — проблема UI, не контроллера. Причём никакого особенного фреймворка не требуется, большинство проблем прекрасно решается средствами из коробки.

"Нетиповые" формы прекраснейше генерятся дизайнером, биндинг к данным — тоже проблем дизайнера. Оставшийся код — связывание UI и контроллера — пишется ручками в code behavior и обычно выглядит как

private void OnActionButtonClick(object sender, EventArgs e)
{
  ProgramName.SpecificController.Action();
}

Свойство Enabled у кнопки забиндено на свойство контроллера CanExecuteAction. Никакой магии, мегафреймворка и гавнокода

Единственное капитальное вложение — отучивание кодеров писать логику в code behavior формы. Выгоды перечислять?

Дня!

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

G>Aikin, вот ты ставишь минус — тему-то раскрывай, а? А то хрен его поймешь, с чем именно из всего упомянутого ты не согласен. Я вот прям теряюсь в догадках. В конце концов, так не интересно. Минус — и все. У нас "обмен мнениями" — или нет?
Сил уже не было говорить одно и то же

Кроме того, я никогда не ставлю минус если отвечаю на пост. Зачем? Этот минсус уже содержится в моем ответе. Т.о. если я ставлю минус -- ответ не предполагается.

Но раз просите:

G>Меж тем, user stories сама по себе штука толковая. И думать о тестах вперед — тоже толковая. И парная работа — толковая. И ранняя обратная связь скастомером — толковая.
Абсолютно согласен.

G>А вот не делать дизайна, постоянно рефакторить, дергать кастомера чрезмерно часто, и вообще — парадоксальная стратегия "поменьше думать, и побольше прыгать" — настолько бестолковая, что сводит на дерьмо все здравое, что есть в XP.

Абсолютно согласен в общем контексте.

Но в контексте поста (в отношении к эджаилу) я хочу сказать, что
G>не делать дизайна
не предлагается

G>постоянно рефакторить
Хочу сразу отделить два вида рефакторинга: минирефакторинг в рамках TDD и рефакторинг для более удобного решения текущей задачи.
Второму не соответствует прилагательное "постоянно". По поводу первого: я до сих пор не разобрался как "правильно есть" TDD. Все время "заглядываю вперед"

Так что с этим согласен.

G>дергать кастомера чрезмерно часто
Кастомер == "представитель кастомера", это может быть и местный аналитик
Чрезмерно часто? отличный "термин", всегда можно найти то самое "чрезмерно", что взвоет даже фонарный столб

G>и вообще — парадоксальная стратегия "поменьше думать, и побольше прыгать" — настолько бестолковая, что сводит на дерьмо все здравое, что есть в XP.

"user stories сама по себе штука толковая. И думать о тестах вперед — тоже толковая. И парная работа — толковая. И ранняя обратная связь скастомером — толковая."
И это назывется "поменьше думать"?
ИМХО, предлагается поменьше думать о "будущих изменениях в требованиях" и отталкиваться от того что есть на данный момент.

Полностью осознаю, что это не более чем мое ИМХО и я сам лично могу неправильно понимать Agile, корректируя его в своем сознании.

СУВ, Aikin

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

G>Товарищ — это Аноним. Вы всего-лишь пытались выше по ветке обобщить его определение. Попытались на мой взгляд крайне неудачно. Попробуйте сформулировать Вашу мысль еще раз, так, чтобы получилась не чушь, уточнив, что вы понимаете под "внешним интерфейсом". И каким именно образом вы из него архитектуру выводить будете. На простом примере, если можно.
Мой изначальный пост был именно о юзер интерфейсе (формочках, страничках и проч). Хотя (я) не вижу противоречий при обобщении его на "внешний интерфейс". Результыты можно посмотреть здесь.
Вторая же часть обобщения UI была всего лишь шуткой. Хинт: "если заняться словоблудием".

G>Пример: интерфейс — примерно такой: www.google.com. Еще один "внешний интерфейс" — он сканирует веб через HTTP. Я никаких требований не пропустил, которые относятся к внешним интерфейсам?
В посте, который Вы проигнорировали (а я ведь именно для Вас старался) я написал:

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

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

Попытаюсь еще раз:

О первостепенной важности Требований хорошо сказал IT Re[35]: DTO внутри BusinessObject (в конце поста. У него был еще один пост на эту тему, но лень искать).
О высокой важности UI хорошо написали 37 Signals (авторы RubyOnRails) в своей книге Getting Real (в этой книге много и других очень грамотных идей).

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

СУВ, Aikin

От:	VGn	http://vassilsanych.livejournal.com
Дата:	17.03.09 15:43
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	17.03.09 17:18
Оценка:	+1

От:	Gaperton	http://gaperton.livejournal.com
Дата:	18.03.09 09:13
Оценка:	+2

	От:	Аноним
	Дата:	18.03.09 10:46
	Оценка:

	От:	Аноним
	Дата:	19.03.09 14:33
	Оценка:

От:	Aikin	kavaleu.ru
Дата:	07.04.09 09:08
Оценка:

	От:	Sinix
	Дата:	20.03.09 02:13
	Оценка: