Не вошла, более того, мы занимаемся еще многими вещами, которые не вошли в тезисы :) И я не упомянул их не потому, что считаю маловажными. Просто мы взяли конкретные проблемы и хотим описать подход, применяемый для их решения. Ничего больше.
P.S. "Готовый продукт", наверное не самое удачное название для последнего пункта, может именно оно вас смутило? Имелось в виду объединение дизайна и запрограммированного интерфейса.
С терминами мы определились, вернемся к вопросу: "вопросы архитектуры в принципе не обсуждаете, т.к. нет необходимости?" Если кратко: обсуждаем. Но мы ограничены используемыми языками программирования, фреймворком, операционными системами (разрабатываем только по unix-подобные ОС) и так далее со всеми вытекающими последствиями. Если бы мы одинаково хорошо владели .Net, Java, PHP, Ruby, дела бы обстояли иначе. Что касается железа и сопутствующих вопросов: мы консультируемся с людьми, которые разбираются в этом лучше нас и стараемся прислушиваться к их мнению.
Повторюсь: мы задумали написать небольшую заметку, а не книгу. Поэтому и не затрагивали "китов" гибкой разработки XP + TDD, CI, если вы это имели в виду.
У нас были проекты средней нагрузки: 40к хостов, 200к хитов. Проектов с большой нагрузкой не разрабатывали. Что в вашем понимании есть "выбор архитектуры"?
Тема проектирования не была затронута сознательно, иначе получилась бы не статья, а книга :) Естественно, мы не начинаем работу над проектом с набросков интерфейса. Но и на этапе проектирования стремимся быть гибкими и свести процесс бумагомарания к минимуму.
А почему бы сразу же не начать делать шаблоны для проекта и не заставить их работать средствами фреймворка? Времени уйдет немного больше, зато вы получите рабочую заготовку интерфейса. Хотя, все зависит от подхода, который вы используете для разработки ПО. Поэтому то что я считаю оверхедом, глядя со своей колокольни, в вашем случае может быть оправданно.
Лично я считаю, что RUP, как и любая другая "тяжелая" методология - не самый удачный выбор для небольших комманд, разрабатывающих среднего уровня сложности веб-приложения. Мы приверженцы гибкой (agile) разработки, которая позволяет нам больше делать и меньше говорить. Хотя, если речь идет об интерпрайзе, то там бюрократия - неотъемлимая часть разработки ПО и правила игры совсем другие.
"Интерфейс определяет модель" нужно воспринимать скорее как "каким образом интерфейс может определять модель" т.е. без фанатизма :)
Работа ведется сначала над интерфейсом, с активным участием заказчика в этом процессе. Изменения вносятся легко и непринужденно, так как править представление - это совсем не то же самое, что править модель. В итоге получаем модель, которая может отличаться от исходной (если бы она существовала) очень сильно, начиная от новых атрибутов у объектов и заканчивая появлением новых объектов и отношений. Конечно, мы не избавляемся от риска появления новых требований и необходимости изменения модели. Более того, мы знаем, что они будут и не боимся этого :) Но описанный выше подход позволяет существенно снизить их количество, особенно на ранней стадии разработки.
Так и хотели сделать изначально. Но процесс написания оказался более трудоемким, чем мы предполагали. Поэтому предварительно решили выяснить, есть ли у пользователей интерес к такого рода материалу.
Я тоже считаю эти правила абсурдными, но от этого они не перестают быть правилами. Думаю, не стоит скатываться в риторику, язык от этого лучше не станет.
А правила, как и все остальное, очень быстро устаревают. Поэтому многое из того, что вы учили в школе и университете может быть уже неактуальным. Например, когда я учился в школе, слова метро, кино, пальто в украинском языке не склонялись. А сейчас склоняются, и говорить, что это неправильно т.к. в мои школьные годы было по другому было бы странно :)
Я пишу "в Украине", руководствуясь справочником Розенталя и некоторыми другими. Вы пишете "на Украине" руководствуясь, насколько я понял грамотой.ру и некоторыми другими источниками. Предлагаю остановиться на том, что и тот и тот вариант правильный, пожать друг другу руку и окончить дисскусию :)
P.S. "Готовый продукт", наверное не самое удачное название для последнего пункта, может именно оно вас смутило? Имелось в виду объединение дизайна и запрограммированного интерфейса.
P.S. С программой все-равно ознакомлюсь :)
Работа ведется сначала над интерфейсом, с активным участием заказчика в этом процессе. Изменения вносятся легко и непринужденно, так как править представление - это совсем не то же самое, что править модель. В итоге получаем модель, которая может отличаться от исходной (если бы она существовала) очень сильно, начиная от новых атрибутов у объектов и заканчивая появлением новых объектов и отношений. Конечно, мы не избавляемся от риска появления новых требований и необходимости изменения модели. Более того, мы знаем, что они будут и не боимся этого :) Но описанный выше подход позволяет существенно снизить их количество, особенно на ранней стадии разработки.