(no subject)
Jan. 26th, 2014 12:39 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
norianОбщие соображения по архитектуре софта или Пособие для Главного Плотника
собрал в кучу потыренные посты с хабра, многабукаф
Что такое архитектура, когда она нужна
Если приложение маленькое, то понятие архитектура к нему применять смысла не имеет. Скворечник можно легко делать без генерального плана. По мере роста масштаба проекта игнорировать это понятие становится все сложнее и сложнее.
Тут важно понимать, что, если вы делаете мелкую одноразовую утилиту, то самый быстрый и правильный способ — писать, как пишется, и особо не задумываться.
Байка
Как-то довольно давно я попросил коллегу написать небольшую утилиту для миграции некоторого набора данных из MySQL в Oracle с попутной небольшой коррекцией данных. Вся задача в моем понимании была строк так на 500-1000. Писали мы в те далекие времена на Delphi, при этом в отделе последние пол года царило повальное увлечение UML и RUP. Попросил в понедельник, утилита была нужна к пятнице. В четверг (тут, конечно, моя ошибка - надо было спрашивать раньше) я решил, что, прежде чем запускать на боевой базе, надо бы утилиту проверить на тестовом стенде, и попросил коллегу скинуть мне на шару exe-файл.
Выслушав ответ, с удивлением обнаружил, что утилита еще и не начинала писаться, пока только есть проект в виде десятка диаграмм в Rational Rose, и коллега готовится идти консультироваться с нашим RUP-гуру, как для единственного exe-файла должна выглядеть deployment-диаграмма.
Закончилось все довольно тривиально, хотя и не без конфликта. После 15-минутной беседы коллега сел писать утилиту, через два часа написал, отдал ее мне и ушел бурчать, что я душу полет инженерной мысли, и, если бы у него было еще два дня, то он бы сделал утилиту по все правилам, с диаграммами и архитектурой. А так данные, конечно, перелились, и утилита больше не нужна, но мы работаем не по методологии.
Само понятие SoftwareArchitecture появилось в 1968 г., кому любопытно, может почитать статью на вики. В двух словах, это генеральный план устройства вашего приложения.
Книг вообще и учебников в частности на эту тему написано множество, и я не чувствую себя достаточно крутым, чтобы написать еще один — самый лучший. Попытаюсь написать о том, о чем в книгах обычно не пишут. Основная хитрость тут в том, что на практике, в чистую, отделить собственно архитектуру от менеджмента, психологии и т. п. смежных вещей почти не реально.
Итак, альтернативное определение. Архитектура — набор решений по организации структуры, кода, команды проекта и процесса разработки (а также вообще всего, что надо, включая, например, процесс питания организмов разработчиков пиццей, если вдруг есть такая необходимость) призванных:
Сделать возможным/Ускорить/Удешевить достижение бизнес-цели.
Достичь приемлемой производительности/увеличить производительность. С производительностью не все так просто. Если система хорошо работает на хостинге стоимостью $ 3000 в месяц — это достаточная производительность или нет? Тут все зависит от того, сколько дохода приносит система. Но не только. Даже если денег много, это не повод писать кривой код.
Сделать приложение легко расширяемым на случай, если это понадобится (как показывает практика, надо это почти всегда, и почти всегда не в ту сторону, в которую ожидали изначально). Надо помнить, что, как правило, расширяемое приложение — это простое приложение.
Уменьшить количество ошибок, в частности например:
ошибок, связанных с потокобезопасностью;
работой кода только на тестовом наборе данных;
доступом разработчиков к внутренностям других модулей в обход документированных интерфейсов;
и т. п.
Вообще говоря, тут бы, конечно, вместо архитектуры придумать какой-то другой термин, но, с другой стороны, Википедия говорит, что:
Архитектура (лат. architectura — строительство, зодчество, от греч. старший, главный и греч. строитель, плотник) — одна из наиболее всеобъемлющих областей человеческой деятельности, занимающаяся организацией пространства и времени и решающая любые пространственные и временные задачи, от разработки стратегий развития агломераций до дизайна дверных ручек.
Т. е. в принципе в широком смысле слова менеджмент тоже легко попадает под понятие «архитектура».
Когда архитектура нужна
Если взять 10 программистов, знающих язык Си, 10 QA-щиков и пару-тройку менеджеров и попросить их написать, например, аналог FAR-а, поставив условие забыть о существовании термина software achitecture, то они, безусловно, FAR напишут, но, может быть, не так быстро и будет он не таким надежным, как хорошо всем известный <классический> FAR. Получится ли таким же образом написать Windows 7 (не то, чтобы я считал Windows 7 вершиной человеческой мысли, но штука безусловно большая), экстраполируя число участников, я не знаю, но думаю, что в срок человеческой жизни этот проект в любом случае не уложится.
Если взять 1000 программистов, QA и менеджеров в нужной пропорции и правильно все организовать, то Windows 7 наверняка получится. Вопрос в том, что значит организовать и что значит правильно.
Понятно, что для работы над проектом надо знать, как Windows 7 устроена, надо понять, в какой пропорции нам нужны специалисты разных видов, с чего начать и чем закончить. Ну, и не в последнюю очередь надо выбрать действительно хороших специалистов (причем не хорошие вообще, а хорошие именно для этого проекта и конкретной позиции). А после того как эти замечательные люди начнут работать, надо следить чтобы они не поубивали друг друга в споре, где должен находится крестик закрыть у окна -слева или справа. Т.е надо создать, в том числе, и культуру отношений в команде.
При этом все эти вопросы плотно связаны друг с другом. И не все можно решать по учебнику т. к. учебников много, и часто они говорят прямо противоположные вещи.
Пример, как разные, казалось бы, вещи могут быть связаны: правильная техническая архитектура проекта способствует обеспечению взаимозаменяемости разработчиков. Соображения тут довольно простые. Если каждый разработчик делает одну и ту же вещь по-своему, причем не самым очевидным образом, то после того как его переехал грузовик, разобраться в том, что он писал, практически нереально.
Байка
Группа из трех товарищей полгода делала некоторое классическое 3-звенное приложение. Поскольку все они были зрелые проверенные специалисты, а менеджер был человек вообще категорически не технический, то делалось все по принципу артели, перед началом работы поделили области и начали пилить.
Двое делали экранные формы, один - для диспетчеров, другой -для технологов, третий делал отчеты. Таблицы в БД каждый создавал для себя, благо приложение это позволяло. Приложение работало, два раза команда в полном составе выезжала к заказчику и производила релиз. Все было как всегда, по меркам той организации, пока в один прекрасный день товарищу, который делал отчеты не предложили больше денег в соседней компании. На его место взяли другого специалиста, тоже проверенного. Увы, выяснилось что каждый специалист писал в целом неплохой код, т. е. классических спагетти, когда вообще не понятно, что код делает, там не было. Но.
1. Для чего нужны таблицы и что в них хранится, догадаться можно далеко не всегда.
2. Файл отчета otchet1.aspx - один большой файл на 150 Кб, в котором захардкожена строка связи с БД, включая пароль, и оттуда же идут все обращения к БД.
Структура таблиц и имена столбцов тоже не отличались очевидностью.
Чем все закончилось? За три месяца два человека переписали отчеты заново. Можно было быстрее, но там множество данных прегенерировалось в триггерах непосредственно при вставке данных (что само по себе для отчетов решение сомнительное).
Что тут можно было сделать? Сделать можно было много что. Как минимум:
1. Назначить одного ответственного за БД, рисовать диаграммы БД.
2. Назначить ответственного за техническую архитектуру и попросить его время от времени просматривать, что и как в приложении делается.
3. Перед тем как все начать делать - сделать скелет приложения с выделенным слоем доступа к БД и стандартным способами делать наиболее часто встречающиеся вещи.
Другой вопрос, что в компании, где все это происходило, это было невозможно по двум причинам:
1. буквально все разработчики так никогда не делали и просьбу так сделать восприняли бы как личное оскорбление;
2. начальник менеджера проектов тоже про такое не слышал и любую инициативу подобного рода упразднил бы как лишнюю трату времени.
В чем тут мораль? Без архитектуры им было плохо. Но даже будь менеджер супер-крут - все равно это бы не помогло, т. к. делать проекты хорошо в той компании было решительно не принято. Скажем так, бизнес был основан не на этом.
В принципе, все, о чем я говорил выше, также ассоциируют с методологией разработки. Методология — это набор правил, которые помогают все или некоторые вышеуказанные вопросы решать более или менее однообразным образом. Как правило, это помогает. Иногда не очень, но в любом случае методология — скажем так, благоустроенная система автодорог, но ехать по ней можно в разные стороны. И не надо забывать, что редко, но бывают случаи, когда вам как раз надо заехать на середину картофельного поля, и дороги туда нет. Например RUP не вполне подходит для dedicated team проектов с недельным release cycle. А XP не вполне применима к fixed price проектам с жестким графиком и плохими коммуникациями.
Здесь я стараюсь описать общие принципы, куда ехать надо, куда не стоит, а уж систему дорог можно выбрать, такую по которой можно доехать туда, куда вам хочется.
С чего начать проект
С чего лучше начать? В начале проекта есть несколько ключевых моментов:
Требования — что и зачем надо заказчику и как это ложится на его бизнес.
Структура и условия (включая отпущенное время) работы проектной команды — кто и как это будет делать.
Как будет делаться проект — из чего будет состоять проект, зачем нужна каждая из частей и как эти части должны быть устроены.
Ключевые технические решения и технологии — для неясного технического вопроса желательно сделать прототип или найти человека с хорошим опытом в этой технологии.
Технически подробности — как все это будет лежать в контроле версий, как будет собираться и устанавливаться.
Вначале для каждого из этих пунктов надо придумать решение. Причем решения должны идти, так сказать, от сердца. Т.е. просто прочитать, что XP технология — это здорово, и начать строго следовать ей по описанному в книге сценарию, без понимания, что это такое и как работает, скорее всего, ни к чему хорошему не приведет. У вас должно быть вполне конкретно видение, что и как вы будете делать, зачем это надо, и что будет если этого не делать. Действия без понимания, зачем это надо, есть ритуал, штука совершенно бессмысленная и даже вредная. По крайней мере, в нашем бизнесе.
Хорошо и плохо
ОК, вы знаете, что делать, есть какие-то идеи, и ваши собственные, и подсказанные коллегами, что-то вычитано в Интернете, что-то в книгах. Научить генерировать идеи либо нельзя, либо очень сложно, поэтому будем считать, что идеи у вас есть. Самое первое, что приходит в голову — надо научиться отличать плохие идеи от хороших. Какие тут могут быть критерии.
Что такое хорошо
Хорошо, это когда есть какой-то набор решений/правил (архитектура), удовлетворяющий следующим требованиям:
Документация
Набор правил хорошо документирован, ну, или, если проект короткий и небольшой, просто хорошо известен всем членам команды. Иначе говоря, архитектура должна быть в сердце каждого, или, если ее там нет, то должен быть простой путь, как ее туда поместить. Т.е. должна быть возможность новому человеку как-то войти в команду. Даже если идея полезная и простая, но нигде не записана — она очень скоро станет бесполезной.
Байка
Один из проектов я начинал делать командой из двух человек. Я и еще один очень опытный, но не очень коммуникабельный коллега. За несколько месяцев мы в несколько итераций сделали очень полезное приложение, весьма толково устроенное внутри. У нас было очень компактное ядро, обеспечивающее запуск и связывание плагинов. А весь функционал реализовывался собственно в плагинах, каждый из которых реализовывал некую изолированную функцию с четко описанным интерфейсом. Проект пошел в серию и начал очень активно развиваться.
При этом важной особенностью, определившей успех проекта была возможность, добавляя и убирая плагины, конфигурировать приложение для работы с разными БД и разными устройствами. Я из проекта ушел делать что-то другое, в проект добавили четырех человек для реализации кучи функционала, затребованного заказчиком.
Где-то через полгода за кружкой чая я поинтересовался, как идут дела. Выяснилось, что дела идут хорошо, но приложение должно работать в разных конфигурациях, и есть масса проблем с развертыванием и зависимостями между модулями для некоторых конфигураций, но их почти удалось решить, убрав плагины и ведя разработку для каждой из более десятка конфигураций в своей ветке svn.
Меня это удивило, т. к. по изначальной задумке как раз плагины эту самую проблему очень элегантно решали. Дальнейшее расследование показало, что после моего ухода из пяти человек только один знал как, оно должно работать, но у него было много своих задач, и о передаче опыта он как-то не задумался. А о том, чтобы описать, зачем тут плагины, как ими пользоваться, я как-то не подумал. Получилось так, что сразу это было не очевидно, и каждый из пришедших в проект людей понял это по-своему. В результате в проекте было четыре разных способа использования плагинов, и приложение работало, только если были включены все плагины сразу, т. к. в нем зависело все от всего.
Закончилось все не очень хорошо, проект как-то доделали, но развивать не стали.
Что надо было делать:
Мне надо было потратить несколько дней, написать какие-то документы и убедиться, что все новые члены команды пишут код в том же ключе.
Вновь пришедшим людям надо было понять, что надо активно трясти меня на предмет документации.
В принципе, знание можно было передать и на словах, но всем четверым это было сделать довольно непросто.
Простота понимания
Набор правил должен быть прост и доступен понимаю каждого члена команды. Точнее, тем членам команды, которым это необходимо для работы. Если идею объяснить тяжело, есть хороший шанс, что кто-то, покивав головой, начнет клепать код ортогонально всему, что было задумано. И хорошо, если этот код потом просто не заработает.
Байка
Рассказывал один знакомый, большой любитель хитрых решений и кодогенерации. В проекте было реализовано довольно хитрое решение, когда на специальном языке, производном от Явы, писались классы описывающие в себе сразу структуру данных, бизнес-правила и пользовательский интерфейс. Язык этот был от начала до конца придуман знакомым. Был специальный компилятор, который из одного класса на хитром языке генерировал несколько Ява-классов, и далее они уже компилировались в байт код. Все работало довольно здорово и покрывалось 99 % функционала.
Оставался 1 % довольно хитрых требований, для которых была возможность написать Java код inline, делать это было в целом не очень удобно, но, учитывая, что надо это было только в 1 % - это было ОК. Все было хорошо, если бы не одна проблема. Язык был сильно не простой. Даже несмотря на наличие документации. В итоге десяток джуниоров из всего этого поняли только, как писать inline-классы и быстренько за несколько месяцев нарисовали практически весь функционал именно таким образом. В целом несколько медленнее, чем на чистой Яве, но в пределах допустимого.
Веселье началось, когда после завершения первой итерации знакомый, получив пачку замечаний от заказчика, решил немного изменить ряд вещей в интерфейсе пользователя. В частности, надо было поменять дефолтное поведение datagrid-ов. Это делалось за несколько часов путем изменения кодогенератора и потом проверки вручную 1 % классов, содержащих исключения. Все было хорошо, но обнаружилось, что из примерно 300 классов, ответственных за функционал, на специальном языке сделано не более 10, а остальные реализованы как inline-код, и все их надо обходить и менять вручную.
Закончилось все большим количеством ругани в адрес джуниоров, архитектора и вообще всех, кто был причастен, непричастен и просто проходил мимо.
Простота в использовании
Эти решения и правила должно быть легко и просто использовать. Эмпирическая характеристика — количество мест, где надо менять код для реализации одной фичи. Если в одном классе — то хорошо, если в пяти — много хуже. Хотя иногда пять — неизбежная цифра.
Байка
В одном проекте у нас согласно требованиям заказчика была довольно хитрая 4-звенная архитектура с shrad-кластеризацией. Чтобы из клиентского приложения послать самый простой запрос, в БД разработчику надо было создать 6 классов (а иногда и больше). В целом там все было логично и красиво. Но вот беда, к моему удивления разработчики почему-то ради запроса select id,firstName,lastName from user where user = :uid очень не хотели создавать 6 классов. Поэтому код писался не очень быстро.
В результате после миграции на более старшую версию ряда библиотек я придумал решение, как можно обходится одним/двумя классами, и острота вопроса снялась. Хотя, надо признать, был момент, когда все было совсем плохо, и отдельные коллеги припоминают мне этот случай до сих пор.
Основная мораль, которую я для себя извлек: если разработчика неудобно, то проекту плохо. Надо, чтобы архитектура была комфортной и простой.
Должно работать
Набор решений должен обеспечивать приемлемые заказчиком ТТХ (Тактико-Технические Характеристики) изделия системы. Если система должна обслуживать 10.000 пользователей в сутки, то заказчику это действительно надо, и любое решение, дающее половину, не считается рабочим.
Байка
Случай из собственной практики. В 2000-2001 гг. я делал систему, собирающую данные от разного рода промышленных измерительных приборов через некую хитрую радиосеть. Опуская подробности: у заказчика стояло 7 серверов, собиравших данных от ~500 объектов, разбросанных по территории 300-400 км. С частотой примерно 10-20 раз в секунду на сервер приходили события, который он должен был передать на диспетчерские машины. Правила, что, когда и кому надо было передавать, были не вполне простыми.
Моя ошибка заключалась в том, что все события с сначала записывал в БД, а потом выбирал их из БД и отравлял дальше по сети. В принципе, решение казалось разумных во многом потому, что в компании, где я работал традиционно все делалось через БД, и решения подобного рода считались идеологически верными. Да и вообще вроде все было хорошо, БД специально предназначена для выборки и хранения данных, зачем писать свое, если уже есть готовый механизм.
На стенде все работало хорошо, но, когда поток данных вырос в 500-1000 раз, обнаружилось, что БД не справляется и, видимо, справиться не может в принципе.
За 7 суток работы в командировке, работая с 9 до 22, я переписал кусок, отвечающий за доставку данных, и еще за несколько дней отладил прямо на железе заказчика, благо это была опытная эксплуатация.
Моя ошибка была в том, что я банально не посчитал, какой будет поток данных и какова требуемая производительность. Решение с БД было красивым, простым, идеологически верным, и было одобрено старшими товарищами, но, увы, не работало под реальной нагрузкой.
Комфортный процесс разработки
Разработчикам должен обеспечиваться комфортный процесс разработки. Т.е. все должно по возможности легко и быстро собираться и деплоиться, IDE должна подсвечивать все, что можно, все должно запускаться под отладчиком, и на все можно написать юнит (и не только юнит) тест. Список в зависимости от технологии может сильно меняться.
Команда должна быть согласна с архитектурой
Команда должна быть с архитектурой более или менее согласна. Если яростного фаната Oracle заставить делать приложение на PostgeSQL и требовать от него высокой производительности — получится не очень. Если не получается, надо:
Менять команду. К примеру, незачем знатока EJB заставлять делать приложение на Spring, если рядом простаивает Spring-гуру.
Менять технологию. Иногда команду заменить или нельзя или поздно, технологию тоже можно поменять далеко не всегда, но иногда что-то подправить можно.
Вести душеспасительные беседы. Звучит как пропаганда, но иногда вполне работает. Бывает, что проблемы возникают просто от незнания и/или недопонимания.
Арсенал трюков тут бесконечен, причем и технических, и психологических. В целом это тема для отдельного разговора.
Если что-то делаешь — делай так везде
Приезжая в страну, я не спрашиваю, хорошие или плохие здесь законы. Я спрашиваю, выполняются ли они? ©. Интернет расходится в авторстве этого мудрого высказывания, лично я вычитал это у Стругацких. Но в любом случае сказано верно.
Если какое-то решение принято, оно должно быть использовано везде и всеми. Если это где-то неприменимо, должно быть четко описано, почему это неприменимо, и описаны исключения. Ни в коем случае не должно быть ситуации, когда 3 человека делают так, а 4-й -по-другому. Тут надо разбираться — либо он <художник, и он так видит>, тогда это больше к менеджменту и в сторону выхода. Либо действительно в том модуле, который он делает, по-другому нельзя. И тут уже надо думать вам.
Тут я какую-то более или менее специфичную байку припомнить не могу, как правило, практически любая <плохая> ситуация с проектом была спряжена с нарушением этого принципа. Могу вспомнить историю не вполне про архитектуру ПО, но, тем не менее, иллюстрирующую общий принцип на примере архитектуры компании.
Байка
Давно-давно я работал в компании Sterling Group (ныне не существующей). Довольно долго там работалось очень и очень хорошо. Интересные проекты, хороший коллектив. Но потом владелец компании решил, что бизнес у него не правильный и надо делать его правильным. Причем что такое правильный бизнес он решал, руководствуясь, видимо, чтением журналов и рекламных буклетов. В результате было введено множество правил, больше половины которых выполнить было просто нереально. Например, был издан указ, по которому права локального администратора должны были быть только у системных администраторов живших в Москве (я работал в воронежском филиале). На следующей день 200 разработчиков в разных городах банально не смогли, придя на работу запустить IDE, т. к. разрабатывать без прав системного админа для каких-то платформ, наверное, можно, но у нас это точно не получалось. Наиболее ушлая часть вытащила из загашников пароль локального админа, подкрутила права доступа, выкинула системных админов из списка локальных админов и продолжила работать, тихо матерясь. Остальные ждали до конца недели, пока ситуацию наконец не откатили назад на верхнем уровне.
Но это в принципе ерунда, самое интересно было, когда нам запретили пользоваться локальным почтовым сервисом (и внешними почтовыми сайтами заодно), а взамен выдали почту SAP R/3, из которой был шлюз во внешний мир. В 2003 г. пользоваться этим было чудовищно неудобно, плюс громадное количество функциональных неудобств. Например, если кто-то писал вам письмо не plain text, то прочитать его можно было, только скачав письмо как документ на локальный диск и открыв его отдельно.
Никто этой почтой реально не пользовался, все использовали Yandex или появившийся чуть позже Gmail. Это было строго запрещено под страхом увольнения и судебного преследования за нарушение корпоративной политики по информационной безопасности, но, т. к. переписываться с заказчиком все равно как-то было надо, средний менеджмент закрывал на это глаза.
К чему я это рассказываю? Закон был. Он не исполнялся. Было плохо.
Не каждая технология подходит каждому заказчику
Заказчик, если ему не все равно (а в 99 % случае не все равно), должен быть совместим с технологией.
Например, Product manager со стороны заказчика имеет огромный опыт разработки Rich Web UI на Flex — предлагать ему сделать приложение на GWT не очень здорово. Или продавцы только что продали заказчику сервер приложений за $50K — предлагать все сделать на бесплатном JBoss значит искушать судьбу.
Вообще говоря, по-честному этот пункт надо бы вставить первым, т. к. чаще всего набор технологий и основные решения диктуются заказчиком, и при всем желании много в проекте не наархитектуришь. Такую ситуацию надо четко понимать и ни в коем случае не пытаться слишком рьяно грести против течения. В результате все будут несчастливы, даже если предлагаемое вами решение лучше. Это не значит что вообще ничего на надо предлагать, просто делать это надо с большим умом в не категоричной форме А что вы думаете о технологии А? или Я тут недавно прочитал статью, и мне кажется что возможно использование технологии Б увеличит производительность в 10 раз, каково ваше мнение по этому поводу?. Но это, в общем-то, совсем другая история, и подробно про политику отношений с заказчиком я тут писать не буду.
Организационная структура имеет значение
Архитектура должна не противоречить имеющейся организационной структуре, сложившимся практикам и т. п. Например, если проект делают два разных отдела, граница между программными модулями должна пролегать по границе отделов.
Байка
Тут я могу привести случай из практики. Мы делали некоторое UI-приложение силами двух отделов. В каждом отделе был свой начальник и своя команда с неким техническим мировоззрением. Причем делать надо было UI-приложение, состоящее из какого-то количества форм. Так вот, в результате половина форм выглядела, вела себя и была внутри устроена по-одному, а другая - совсем иначе. Как-то это все в результате собрали вместе (на уровне БД все было сделано одним отделом), но просьба изменить что-либо превращалась в челночную дипломатию с бесконечными перемещениями между отделами.
Сейчас я бы, конечно, провел границу между отделами по границе слоев, например, отдал бы соседнему отделу весь backend. Нагрузка бы легла неравномерно, но хотя бы можно было понять, как оно работает, и кто за что отвечает. Это бы породило проблему размывания ответственности, т. к. за конкретную форму бы не было единственного ответственного, но в той ситуации это не было бы так страшно.
Сроки
Всегда должны учитываться сроки проекта. Иногда на реализацию совершенно замечательного фреймворка, который необыкновенно все ускорит, надо два месяца, а общий срок проекта — месяц. И наоборот, проект длительностью в год, куча стандартные стилизованных UI-компонентов, а потратить 3-4 недели на написание common UI component library никто не удосужился.
Байка
В одной компании был маленький по функционалу, средней длительности проект. По сути это было классическое 2-звенное приложение, читающее данные из БД и показывающее на экранных формах. Бизнес-требования были достаточно простыми, структура БД тоже не предвещала беды. В результате команда разработала несколько слоев метаописания данных и экранных форм. Фреймворк был действительно достаточно продвинутый и позволял на своей основе сделать каждую из 300 экранных форм. Проблема была в том, что к моменту завершения сроков проекта, помимо Фреймворка, было сделано только 5 форм. И надо было сделать еще 295. Фреймворк был настолько хорош, что каждую форму можно было сделать не более чем за 4-8 часов. Оставалось всего 150-300 человеко/дней работы.
Тут, казалось бы, идея была хороша и вполне применима. 300 форм действительно заслуживают некой универсализации, но проект имел жесткий срок, и как раз на даты разработчики посмотреть забыли.
Стандарты
Сам я уж точно — не догматичный поклонник стандартов. Если посмотреть на все мои проекты, то почти каждый содержит какое-то отступление от канона. Но стандарты важны, даже если есть другое, всем хорошее, но нестандартное решение. Как бы это не звучало цинично, надо всегда держать в голове фактор А почему у вас сделано не в соответствии с индустриальным стандартом?. Т.е. применительно к Яве, например: А почему у вас не на EJB? Ответ на этот вопрос у вас, может быть, есть, и вполне может оказаться, что на EJB будет на порядок медленнее работать и уйдет в два раза больше времени, чем так, как сделано у вас. Но поверьте, после 10 ответов на этот вопрос 11-го спросившего хочется убить. В конце концов в большинстве случаев деньги на оборудование и разработку не ваши, плюньте и сделайте на EJB (это не значит что Вам должно быть все равно, но отстаивать свою позицию надо до опредленного момента). Иначе говоря, если есть два примерно равных решения, но одно из них — стандарт а другое — нет, проще использовать стандарт, сбережете нервы.
Баек тут не будет, т. к. все они связаны со сжиганием большого количества нервной энергии и совсем не приятными воспоминаниями. Просто поверьте: если есть стандартное и нестандартное решения, и стандарт в целом годится (хотя, может быть, и не так хорош) — используйте его.
Помимо вышесказанного тут есть еще одно соображение. Если вы используете EJB, то найти специалиста очень просто — требуется вменяемый разработчик со знанием EJB, а, если вы используете свою хитрую библиотеку которая дает 50-процентный прирост скорости (и экономит $ 2500 на хостинге, например), то найти нового разработчика уже значительно сложнее, тем более что, п. 1 Документация в этом длинном списке хороших вещей вы, скорее всего, проигнорировали.
собрал в кучу потыренные посты с хабра, многабукаф
Что такое архитектура, когда она нужна
Если приложение маленькое, то понятие архитектура к нему применять смысла не имеет. Скворечник можно легко делать без генерального плана. По мере роста масштаба проекта игнорировать это понятие становится все сложнее и сложнее.
Тут важно понимать, что, если вы делаете мелкую одноразовую утилиту, то самый быстрый и правильный способ — писать, как пишется, и особо не задумываться.
Байка
Как-то довольно давно я попросил коллегу написать небольшую утилиту для миграции некоторого набора данных из MySQL в Oracle с попутной небольшой коррекцией данных. Вся задача в моем понимании была строк так на 500-1000. Писали мы в те далекие времена на Delphi, при этом в отделе последние пол года царило повальное увлечение UML и RUP. Попросил в понедельник, утилита была нужна к пятнице. В четверг (тут, конечно, моя ошибка - надо было спрашивать раньше) я решил, что, прежде чем запускать на боевой базе, надо бы утилиту проверить на тестовом стенде, и попросил коллегу скинуть мне на шару exe-файл.
Выслушав ответ, с удивлением обнаружил, что утилита еще и не начинала писаться, пока только есть проект в виде десятка диаграмм в Rational Rose, и коллега готовится идти консультироваться с нашим RUP-гуру, как для единственного exe-файла должна выглядеть deployment-диаграмма.
Закончилось все довольно тривиально, хотя и не без конфликта. После 15-минутной беседы коллега сел писать утилиту, через два часа написал, отдал ее мне и ушел бурчать, что я душу полет инженерной мысли, и, если бы у него было еще два дня, то он бы сделал утилиту по все правилам, с диаграммами и архитектурой. А так данные, конечно, перелились, и утилита больше не нужна, но мы работаем не по методологии.
Само понятие SoftwareArchitecture появилось в 1968 г., кому любопытно, может почитать статью на вики. В двух словах, это генеральный план устройства вашего приложения.
Книг вообще и учебников в частности на эту тему написано множество, и я не чувствую себя достаточно крутым, чтобы написать еще один — самый лучший. Попытаюсь написать о том, о чем в книгах обычно не пишут. Основная хитрость тут в том, что на практике, в чистую, отделить собственно архитектуру от менеджмента, психологии и т. п. смежных вещей почти не реально.
Итак, альтернативное определение. Архитектура — набор решений по организации структуры, кода, команды проекта и процесса разработки (а также вообще всего, что надо, включая, например, процесс питания организмов разработчиков пиццей, если вдруг есть такая необходимость) призванных:
Сделать возможным/Ускорить/Удешевить достижение бизнес-цели.
Достичь приемлемой производительности/увеличить производительность. С производительностью не все так просто. Если система хорошо работает на хостинге стоимостью $ 3000 в месяц — это достаточная производительность или нет? Тут все зависит от того, сколько дохода приносит система. Но не только. Даже если денег много, это не повод писать кривой код.
Сделать приложение легко расширяемым на случай, если это понадобится (как показывает практика, надо это почти всегда, и почти всегда не в ту сторону, в которую ожидали изначально). Надо помнить, что, как правило, расширяемое приложение — это простое приложение.
Уменьшить количество ошибок, в частности например:
ошибок, связанных с потокобезопасностью;
работой кода только на тестовом наборе данных;
доступом разработчиков к внутренностям других модулей в обход документированных интерфейсов;
и т. п.
Вообще говоря, тут бы, конечно, вместо архитектуры придумать какой-то другой термин, но, с другой стороны, Википедия говорит, что:
Архитектура (лат. architectura — строительство, зодчество, от греч. старший, главный и греч. строитель, плотник) — одна из наиболее всеобъемлющих областей человеческой деятельности, занимающаяся организацией пространства и времени и решающая любые пространственные и временные задачи, от разработки стратегий развития агломераций до дизайна дверных ручек.
Т. е. в принципе в широком смысле слова менеджмент тоже легко попадает под понятие «архитектура».
Когда архитектура нужна
Если взять 10 программистов, знающих язык Си, 10 QA-щиков и пару-тройку менеджеров и попросить их написать, например, аналог FAR-а, поставив условие забыть о существовании термина software achitecture, то они, безусловно, FAR напишут, но, может быть, не так быстро и будет он не таким надежным, как хорошо всем известный <классический> FAR. Получится ли таким же образом написать Windows 7 (не то, чтобы я считал Windows 7 вершиной человеческой мысли, но штука безусловно большая), экстраполируя число участников, я не знаю, но думаю, что в срок человеческой жизни этот проект в любом случае не уложится.
Если взять 1000 программистов, QA и менеджеров в нужной пропорции и правильно все организовать, то Windows 7 наверняка получится. Вопрос в том, что значит организовать и что значит правильно.
Понятно, что для работы над проектом надо знать, как Windows 7 устроена, надо понять, в какой пропорции нам нужны специалисты разных видов, с чего начать и чем закончить. Ну, и не в последнюю очередь надо выбрать действительно хороших специалистов (причем не хорошие вообще, а хорошие именно для этого проекта и конкретной позиции). А после того как эти замечательные люди начнут работать, надо следить чтобы они не поубивали друг друга в споре, где должен находится крестик закрыть у окна -слева или справа. Т.е надо создать, в том числе, и культуру отношений в команде.
При этом все эти вопросы плотно связаны друг с другом. И не все можно решать по учебнику т. к. учебников много, и часто они говорят прямо противоположные вещи.
Пример, как разные, казалось бы, вещи могут быть связаны: правильная техническая архитектура проекта способствует обеспечению взаимозаменяемости разработчиков. Соображения тут довольно простые. Если каждый разработчик делает одну и ту же вещь по-своему, причем не самым очевидным образом, то после того как его переехал грузовик, разобраться в том, что он писал, практически нереально.
Байка
Группа из трех товарищей полгода делала некоторое классическое 3-звенное приложение. Поскольку все они были зрелые проверенные специалисты, а менеджер был человек вообще категорически не технический, то делалось все по принципу артели, перед началом работы поделили области и начали пилить.
Двое делали экранные формы, один - для диспетчеров, другой -для технологов, третий делал отчеты. Таблицы в БД каждый создавал для себя, благо приложение это позволяло. Приложение работало, два раза команда в полном составе выезжала к заказчику и производила релиз. Все было как всегда, по меркам той организации, пока в один прекрасный день товарищу, который делал отчеты не предложили больше денег в соседней компании. На его место взяли другого специалиста, тоже проверенного. Увы, выяснилось что каждый специалист писал в целом неплохой код, т. е. классических спагетти, когда вообще не понятно, что код делает, там не было. Но.
1. Для чего нужны таблицы и что в них хранится, догадаться можно далеко не всегда.
2. Файл отчета otchet1.aspx - один большой файл на 150 Кб, в котором захардкожена строка связи с БД, включая пароль, и оттуда же идут все обращения к БД.
Структура таблиц и имена столбцов тоже не отличались очевидностью.
Чем все закончилось? За три месяца два человека переписали отчеты заново. Можно было быстрее, но там множество данных прегенерировалось в триггерах непосредственно при вставке данных (что само по себе для отчетов решение сомнительное).
Что тут можно было сделать? Сделать можно было много что. Как минимум:
1. Назначить одного ответственного за БД, рисовать диаграммы БД.
2. Назначить ответственного за техническую архитектуру и попросить его время от времени просматривать, что и как в приложении делается.
3. Перед тем как все начать делать - сделать скелет приложения с выделенным слоем доступа к БД и стандартным способами делать наиболее часто встречающиеся вещи.
Другой вопрос, что в компании, где все это происходило, это было невозможно по двум причинам:
1. буквально все разработчики так никогда не делали и просьбу так сделать восприняли бы как личное оскорбление;
2. начальник менеджера проектов тоже про такое не слышал и любую инициативу подобного рода упразднил бы как лишнюю трату времени.
В чем тут мораль? Без архитектуры им было плохо. Но даже будь менеджер супер-крут - все равно это бы не помогло, т. к. делать проекты хорошо в той компании было решительно не принято. Скажем так, бизнес был основан не на этом.
В принципе, все, о чем я говорил выше, также ассоциируют с методологией разработки. Методология — это набор правил, которые помогают все или некоторые вышеуказанные вопросы решать более или менее однообразным образом. Как правило, это помогает. Иногда не очень, но в любом случае методология — скажем так, благоустроенная система автодорог, но ехать по ней можно в разные стороны. И не надо забывать, что редко, но бывают случаи, когда вам как раз надо заехать на середину картофельного поля, и дороги туда нет. Например RUP не вполне подходит для dedicated team проектов с недельным release cycle. А XP не вполне применима к fixed price проектам с жестким графиком и плохими коммуникациями.
Здесь я стараюсь описать общие принципы, куда ехать надо, куда не стоит, а уж систему дорог можно выбрать, такую по которой можно доехать туда, куда вам хочется.
С чего начать проект
С чего лучше начать? В начале проекта есть несколько ключевых моментов:
Требования — что и зачем надо заказчику и как это ложится на его бизнес.
Структура и условия (включая отпущенное время) работы проектной команды — кто и как это будет делать.
Как будет делаться проект — из чего будет состоять проект, зачем нужна каждая из частей и как эти части должны быть устроены.
Ключевые технические решения и технологии — для неясного технического вопроса желательно сделать прототип или найти человека с хорошим опытом в этой технологии.
Технически подробности — как все это будет лежать в контроле версий, как будет собираться и устанавливаться.
Вначале для каждого из этих пунктов надо придумать решение. Причем решения должны идти, так сказать, от сердца. Т.е. просто прочитать, что XP технология — это здорово, и начать строго следовать ей по описанному в книге сценарию, без понимания, что это такое и как работает, скорее всего, ни к чему хорошему не приведет. У вас должно быть вполне конкретно видение, что и как вы будете делать, зачем это надо, и что будет если этого не делать. Действия без понимания, зачем это надо, есть ритуал, штука совершенно бессмысленная и даже вредная. По крайней мере, в нашем бизнесе.
Хорошо и плохо
ОК, вы знаете, что делать, есть какие-то идеи, и ваши собственные, и подсказанные коллегами, что-то вычитано в Интернете, что-то в книгах. Научить генерировать идеи либо нельзя, либо очень сложно, поэтому будем считать, что идеи у вас есть. Самое первое, что приходит в голову — надо научиться отличать плохие идеи от хороших. Какие тут могут быть критерии.
Что такое хорошо
Хорошо, это когда есть какой-то набор решений/правил (архитектура), удовлетворяющий следующим требованиям:
Документация
Набор правил хорошо документирован, ну, или, если проект короткий и небольшой, просто хорошо известен всем членам команды. Иначе говоря, архитектура должна быть в сердце каждого, или, если ее там нет, то должен быть простой путь, как ее туда поместить. Т.е. должна быть возможность новому человеку как-то войти в команду. Даже если идея полезная и простая, но нигде не записана — она очень скоро станет бесполезной.
Байка
Один из проектов я начинал делать командой из двух человек. Я и еще один очень опытный, но не очень коммуникабельный коллега. За несколько месяцев мы в несколько итераций сделали очень полезное приложение, весьма толково устроенное внутри. У нас было очень компактное ядро, обеспечивающее запуск и связывание плагинов. А весь функционал реализовывался собственно в плагинах, каждый из которых реализовывал некую изолированную функцию с четко описанным интерфейсом. Проект пошел в серию и начал очень активно развиваться.
При этом важной особенностью, определившей успех проекта была возможность, добавляя и убирая плагины, конфигурировать приложение для работы с разными БД и разными устройствами. Я из проекта ушел делать что-то другое, в проект добавили четырех человек для реализации кучи функционала, затребованного заказчиком.
Где-то через полгода за кружкой чая я поинтересовался, как идут дела. Выяснилось, что дела идут хорошо, но приложение должно работать в разных конфигурациях, и есть масса проблем с развертыванием и зависимостями между модулями для некоторых конфигураций, но их почти удалось решить, убрав плагины и ведя разработку для каждой из более десятка конфигураций в своей ветке svn.
Меня это удивило, т. к. по изначальной задумке как раз плагины эту самую проблему очень элегантно решали. Дальнейшее расследование показало, что после моего ухода из пяти человек только один знал как, оно должно работать, но у него было много своих задач, и о передаче опыта он как-то не задумался. А о том, чтобы описать, зачем тут плагины, как ими пользоваться, я как-то не подумал. Получилось так, что сразу это было не очевидно, и каждый из пришедших в проект людей понял это по-своему. В результате в проекте было четыре разных способа использования плагинов, и приложение работало, только если были включены все плагины сразу, т. к. в нем зависело все от всего.
Закончилось все не очень хорошо, проект как-то доделали, но развивать не стали.
Что надо было делать:
Мне надо было потратить несколько дней, написать какие-то документы и убедиться, что все новые члены команды пишут код в том же ключе.
Вновь пришедшим людям надо было понять, что надо активно трясти меня на предмет документации.
В принципе, знание можно было передать и на словах, но всем четверым это было сделать довольно непросто.
Простота понимания
Набор правил должен быть прост и доступен понимаю каждого члена команды. Точнее, тем членам команды, которым это необходимо для работы. Если идею объяснить тяжело, есть хороший шанс, что кто-то, покивав головой, начнет клепать код ортогонально всему, что было задумано. И хорошо, если этот код потом просто не заработает.
Байка
Рассказывал один знакомый, большой любитель хитрых решений и кодогенерации. В проекте было реализовано довольно хитрое решение, когда на специальном языке, производном от Явы, писались классы описывающие в себе сразу структуру данных, бизнес-правила и пользовательский интерфейс. Язык этот был от начала до конца придуман знакомым. Был специальный компилятор, который из одного класса на хитром языке генерировал несколько Ява-классов, и далее они уже компилировались в байт код. Все работало довольно здорово и покрывалось 99 % функционала.
Оставался 1 % довольно хитрых требований, для которых была возможность написать Java код inline, делать это было в целом не очень удобно, но, учитывая, что надо это было только в 1 % - это было ОК. Все было хорошо, если бы не одна проблема. Язык был сильно не простой. Даже несмотря на наличие документации. В итоге десяток джуниоров из всего этого поняли только, как писать inline-классы и быстренько за несколько месяцев нарисовали практически весь функционал именно таким образом. В целом несколько медленнее, чем на чистой Яве, но в пределах допустимого.
Веселье началось, когда после завершения первой итерации знакомый, получив пачку замечаний от заказчика, решил немного изменить ряд вещей в интерфейсе пользователя. В частности, надо было поменять дефолтное поведение datagrid-ов. Это делалось за несколько часов путем изменения кодогенератора и потом проверки вручную 1 % классов, содержащих исключения. Все было хорошо, но обнаружилось, что из примерно 300 классов, ответственных за функционал, на специальном языке сделано не более 10, а остальные реализованы как inline-код, и все их надо обходить и менять вручную.
Закончилось все большим количеством ругани в адрес джуниоров, архитектора и вообще всех, кто был причастен, непричастен и просто проходил мимо.
Простота в использовании
Эти решения и правила должно быть легко и просто использовать. Эмпирическая характеристика — количество мест, где надо менять код для реализации одной фичи. Если в одном классе — то хорошо, если в пяти — много хуже. Хотя иногда пять — неизбежная цифра.
Байка
В одном проекте у нас согласно требованиям заказчика была довольно хитрая 4-звенная архитектура с shrad-кластеризацией. Чтобы из клиентского приложения послать самый простой запрос, в БД разработчику надо было создать 6 классов (а иногда и больше). В целом там все было логично и красиво. Но вот беда, к моему удивления разработчики почему-то ради запроса select id,firstName,lastName from user where user = :uid очень не хотели создавать 6 классов. Поэтому код писался не очень быстро.
В результате после миграции на более старшую версию ряда библиотек я придумал решение, как можно обходится одним/двумя классами, и острота вопроса снялась. Хотя, надо признать, был момент, когда все было совсем плохо, и отдельные коллеги припоминают мне этот случай до сих пор.
Основная мораль, которую я для себя извлек: если разработчика неудобно, то проекту плохо. Надо, чтобы архитектура была комфортной и простой.
Должно работать
Набор решений должен обеспечивать приемлемые заказчиком ТТХ (Тактико-Технические Характеристики) изделия системы. Если система должна обслуживать 10.000 пользователей в сутки, то заказчику это действительно надо, и любое решение, дающее половину, не считается рабочим.
Байка
Случай из собственной практики. В 2000-2001 гг. я делал систему, собирающую данные от разного рода промышленных измерительных приборов через некую хитрую радиосеть. Опуская подробности: у заказчика стояло 7 серверов, собиравших данных от ~500 объектов, разбросанных по территории 300-400 км. С частотой примерно 10-20 раз в секунду на сервер приходили события, который он должен был передать на диспетчерские машины. Правила, что, когда и кому надо было передавать, были не вполне простыми.
Моя ошибка заключалась в том, что все события с сначала записывал в БД, а потом выбирал их из БД и отравлял дальше по сети. В принципе, решение казалось разумных во многом потому, что в компании, где я работал традиционно все делалось через БД, и решения подобного рода считались идеологически верными. Да и вообще вроде все было хорошо, БД специально предназначена для выборки и хранения данных, зачем писать свое, если уже есть готовый механизм.
На стенде все работало хорошо, но, когда поток данных вырос в 500-1000 раз, обнаружилось, что БД не справляется и, видимо, справиться не может в принципе.
За 7 суток работы в командировке, работая с 9 до 22, я переписал кусок, отвечающий за доставку данных, и еще за несколько дней отладил прямо на железе заказчика, благо это была опытная эксплуатация.
Моя ошибка была в том, что я банально не посчитал, какой будет поток данных и какова требуемая производительность. Решение с БД было красивым, простым, идеологически верным, и было одобрено старшими товарищами, но, увы, не работало под реальной нагрузкой.
Комфортный процесс разработки
Разработчикам должен обеспечиваться комфортный процесс разработки. Т.е. все должно по возможности легко и быстро собираться и деплоиться, IDE должна подсвечивать все, что можно, все должно запускаться под отладчиком, и на все можно написать юнит (и не только юнит) тест. Список в зависимости от технологии может сильно меняться.
Команда должна быть согласна с архитектурой
Команда должна быть с архитектурой более или менее согласна. Если яростного фаната Oracle заставить делать приложение на PostgeSQL и требовать от него высокой производительности — получится не очень. Если не получается, надо:
Менять команду. К примеру, незачем знатока EJB заставлять делать приложение на Spring, если рядом простаивает Spring-гуру.
Менять технологию. Иногда команду заменить или нельзя или поздно, технологию тоже можно поменять далеко не всегда, но иногда что-то подправить можно.
Вести душеспасительные беседы. Звучит как пропаганда, но иногда вполне работает. Бывает, что проблемы возникают просто от незнания и/или недопонимания.
Арсенал трюков тут бесконечен, причем и технических, и психологических. В целом это тема для отдельного разговора.
Если что-то делаешь — делай так везде
Приезжая в страну, я не спрашиваю, хорошие или плохие здесь законы. Я спрашиваю, выполняются ли они? ©. Интернет расходится в авторстве этого мудрого высказывания, лично я вычитал это у Стругацких. Но в любом случае сказано верно.
Если какое-то решение принято, оно должно быть использовано везде и всеми. Если это где-то неприменимо, должно быть четко описано, почему это неприменимо, и описаны исключения. Ни в коем случае не должно быть ситуации, когда 3 человека делают так, а 4-й -по-другому. Тут надо разбираться — либо он <художник, и он так видит>, тогда это больше к менеджменту и в сторону выхода. Либо действительно в том модуле, который он делает, по-другому нельзя. И тут уже надо думать вам.
Тут я какую-то более или менее специфичную байку припомнить не могу, как правило, практически любая <плохая> ситуация с проектом была спряжена с нарушением этого принципа. Могу вспомнить историю не вполне про архитектуру ПО, но, тем не менее, иллюстрирующую общий принцип на примере архитектуры компании.
Байка
Давно-давно я работал в компании Sterling Group (ныне не существующей). Довольно долго там работалось очень и очень хорошо. Интересные проекты, хороший коллектив. Но потом владелец компании решил, что бизнес у него не правильный и надо делать его правильным. Причем что такое правильный бизнес он решал, руководствуясь, видимо, чтением журналов и рекламных буклетов. В результате было введено множество правил, больше половины которых выполнить было просто нереально. Например, был издан указ, по которому права локального администратора должны были быть только у системных администраторов живших в Москве (я работал в воронежском филиале). На следующей день 200 разработчиков в разных городах банально не смогли, придя на работу запустить IDE, т. к. разрабатывать без прав системного админа для каких-то платформ, наверное, можно, но у нас это точно не получалось. Наиболее ушлая часть вытащила из загашников пароль локального админа, подкрутила права доступа, выкинула системных админов из списка локальных админов и продолжила работать, тихо матерясь. Остальные ждали до конца недели, пока ситуацию наконец не откатили назад на верхнем уровне.
Но это в принципе ерунда, самое интересно было, когда нам запретили пользоваться локальным почтовым сервисом (и внешними почтовыми сайтами заодно), а взамен выдали почту SAP R/3, из которой был шлюз во внешний мир. В 2003 г. пользоваться этим было чудовищно неудобно, плюс громадное количество функциональных неудобств. Например, если кто-то писал вам письмо не plain text, то прочитать его можно было, только скачав письмо как документ на локальный диск и открыв его отдельно.
Никто этой почтой реально не пользовался, все использовали Yandex или появившийся чуть позже Gmail. Это было строго запрещено под страхом увольнения и судебного преследования за нарушение корпоративной политики по информационной безопасности, но, т. к. переписываться с заказчиком все равно как-то было надо, средний менеджмент закрывал на это глаза.
К чему я это рассказываю? Закон был. Он не исполнялся. Было плохо.
Не каждая технология подходит каждому заказчику
Заказчик, если ему не все равно (а в 99 % случае не все равно), должен быть совместим с технологией.
Например, Product manager со стороны заказчика имеет огромный опыт разработки Rich Web UI на Flex — предлагать ему сделать приложение на GWT не очень здорово. Или продавцы только что продали заказчику сервер приложений за $50K — предлагать все сделать на бесплатном JBoss значит искушать судьбу.
Вообще говоря, по-честному этот пункт надо бы вставить первым, т. к. чаще всего набор технологий и основные решения диктуются заказчиком, и при всем желании много в проекте не наархитектуришь. Такую ситуацию надо четко понимать и ни в коем случае не пытаться слишком рьяно грести против течения. В результате все будут несчастливы, даже если предлагаемое вами решение лучше. Это не значит что вообще ничего на надо предлагать, просто делать это надо с большим умом в не категоричной форме А что вы думаете о технологии А? или Я тут недавно прочитал статью, и мне кажется что возможно использование технологии Б увеличит производительность в 10 раз, каково ваше мнение по этому поводу?. Но это, в общем-то, совсем другая история, и подробно про политику отношений с заказчиком я тут писать не буду.
Организационная структура имеет значение
Архитектура должна не противоречить имеющейся организационной структуре, сложившимся практикам и т. п. Например, если проект делают два разных отдела, граница между программными модулями должна пролегать по границе отделов.
Байка
Тут я могу привести случай из практики. Мы делали некоторое UI-приложение силами двух отделов. В каждом отделе был свой начальник и своя команда с неким техническим мировоззрением. Причем делать надо было UI-приложение, состоящее из какого-то количества форм. Так вот, в результате половина форм выглядела, вела себя и была внутри устроена по-одному, а другая - совсем иначе. Как-то это все в результате собрали вместе (на уровне БД все было сделано одним отделом), но просьба изменить что-либо превращалась в челночную дипломатию с бесконечными перемещениями между отделами.
Сейчас я бы, конечно, провел границу между отделами по границе слоев, например, отдал бы соседнему отделу весь backend. Нагрузка бы легла неравномерно, но хотя бы можно было понять, как оно работает, и кто за что отвечает. Это бы породило проблему размывания ответственности, т. к. за конкретную форму бы не было единственного ответственного, но в той ситуации это не было бы так страшно.
Сроки
Всегда должны учитываться сроки проекта. Иногда на реализацию совершенно замечательного фреймворка, который необыкновенно все ускорит, надо два месяца, а общий срок проекта — месяц. И наоборот, проект длительностью в год, куча стандартные стилизованных UI-компонентов, а потратить 3-4 недели на написание common UI component library никто не удосужился.
Байка
В одной компании был маленький по функционалу, средней длительности проект. По сути это было классическое 2-звенное приложение, читающее данные из БД и показывающее на экранных формах. Бизнес-требования были достаточно простыми, структура БД тоже не предвещала беды. В результате команда разработала несколько слоев метаописания данных и экранных форм. Фреймворк был действительно достаточно продвинутый и позволял на своей основе сделать каждую из 300 экранных форм. Проблема была в том, что к моменту завершения сроков проекта, помимо Фреймворка, было сделано только 5 форм. И надо было сделать еще 295. Фреймворк был настолько хорош, что каждую форму можно было сделать не более чем за 4-8 часов. Оставалось всего 150-300 человеко/дней работы.
Тут, казалось бы, идея была хороша и вполне применима. 300 форм действительно заслуживают некой универсализации, но проект имел жесткий срок, и как раз на даты разработчики посмотреть забыли.
Стандарты
Сам я уж точно — не догматичный поклонник стандартов. Если посмотреть на все мои проекты, то почти каждый содержит какое-то отступление от канона. Но стандарты важны, даже если есть другое, всем хорошее, но нестандартное решение. Как бы это не звучало цинично, надо всегда держать в голове фактор А почему у вас сделано не в соответствии с индустриальным стандартом?. Т.е. применительно к Яве, например: А почему у вас не на EJB? Ответ на этот вопрос у вас, может быть, есть, и вполне может оказаться, что на EJB будет на порядок медленнее работать и уйдет в два раза больше времени, чем так, как сделано у вас. Но поверьте, после 10 ответов на этот вопрос 11-го спросившего хочется убить. В конце концов в большинстве случаев деньги на оборудование и разработку не ваши, плюньте и сделайте на EJB (это не значит что Вам должно быть все равно, но отстаивать свою позицию надо до опредленного момента). Иначе говоря, если есть два примерно равных решения, но одно из них — стандарт а другое — нет, проще использовать стандарт, сбережете нервы.
Баек тут не будет, т. к. все они связаны со сжиганием большого количества нервной энергии и совсем не приятными воспоминаниями. Просто поверьте: если есть стандартное и нестандартное решения, и стандарт в целом годится (хотя, может быть, и не так хорош) — используйте его.
Помимо вышесказанного тут есть еще одно соображение. Если вы используете EJB, то найти специалиста очень просто — требуется вменяемый разработчик со знанием EJB, а, если вы используете свою хитрую библиотеку которая дает 50-процентный прирост скорости (и экономит $ 2500 на хостинге, например), то найти нового разработчика уже значительно сложнее, тем более что, п. 1 Документация в этом длинном списке хороших вещей вы, скорее всего, проигнорировали.