Пользователь
0,0
рейтинг
18 июля 2010 в 17:43

Разработка → Общие соображения по архитектуре ПО или Пособие для Главного Плотника (часть 1: что такое хорошо)

Краткая аннотация


В статье рассматривается некоторые практические аспекты деятельности человека, роль которого в программном проекте описывается прежде всего как архитектор/team lead/project manager. Вообще говоря, это три разные роли и три разных человека, но я ни разу не видел, чтобы архитектор и тим лид были разными людьми, и в половине проектов граница между тим лидом и менеджером проектов очень мутная. Поэтому рассказано будет про все по чуть-чуть.

О байках


Различные, в основном восточные, философские практики говорят, что, если человеку просто сказать осторожнее вытаскивай револьвер из кобуры, можешь отстрелить себе ногу, то человек может не в полной мере осознать опасность. Но если ему рассказать 33 притчи (к северо-западу от Китая за Уральским хребтом они еще называются байками) о безногих ковбоях, то, возможно, он и правда задумается о сохранности ног. Самый лучший способ тут, конечно, — собственный опыт. Но ног всего две, и, если притчи не рассказывать, то все ковбои будут одноногими (как минимум). Именно по этому я постараюсь привести как можно больше примеров.

Итак:

Что такое архитектура, когда она нужна


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

Байка

Как-то довольно давно я попросил коллегу написать небольшую утилиту для миграции некоторого набора данных из MySQL в Oracle с попутной небольшой коррекцией данных. Вся задача в моем понимании была строк так на 500-1000. Писали мы в те далекие времена на Delphi, при этом в отделе последние пол года царило повальное увлечение UML и RUP. Попросил в понедельник, утилита была нужна к пятнице. В четверг (тут, конечно, моя ошибка - надо было спрашивать раньше) я решил, что, прежде чем запускать на боевой базе, надо бы утилиту проверить на тестовом стенде, и попросил коллегу скинуть мне на шару exe-файл.

Выслушав ответ, с удивлением обнаружил, что утилита еще и не начинала писаться, пока только есть проект в виде десятка диаграмм в Rational Rose, и коллега готовится идти консультироваться с нашим RUP-гуру, как для единственного exe-файла должна выглядеть deployment-диаграмма.

Закончилось все довольно тривиально, хотя и не без конфликта. После 15-минутной беседы коллега сел писать утилиту, через два часа написал, отдал ее мне и ушел бурчать, что я душу полет инженерной мысли, и, если бы у него было еще два дня, то он бы сделал утилиту по все правилам, с диаграммами и архитектурой. А так данные, конечно, перелились, и утилита больше не нужна, но мы работаем не по методологии.


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

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

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

  1. Сделать возможным/Ускорить/Удешевить достижение бизнес-цели.
  2. Достичь приемлемой производительности/увеличить производительность. С производительностью не все так просто. Если система хорошо работает на хостинге стоимостью $ 3000 в месяц — это достаточная производительность или нет? Тут все зависит от того, сколько дохода приносит система. Но не только. Даже если денег много, это не повод писать кривой код.
  3. Сделать приложение легко расширяемым на случай, если это понадобится (как показывает практика, надо это почти всегда, и почти всегда не в ту сторону, в которую ожидали изначально). Надо помнить, что, как правило, расширяемое приложение — это простое приложение.
  4. Уменьшить количество ошибок, в частности например:
    • ошибок, связанных с потокобезопасностью;
    • работой кода только на тестовом наборе данных;
    • доступом разработчиков к внутренностям других модулей в обход документированных интерфейсов;
    • и т. п.




Вообще говоря, тут бы, конечно, вместо архитектуры придумать какой-то другой термин, но, с другой стороны, Википедия говорит, что:

Архитектура (лат. 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 и требовать от него высокой производительности — получится не очень. Если не получается, надо:
  1. Менять команду. К примеру, незачем знатока EJB заставлять делать приложение на Spring, если рядом простаивает Spring-гуру.
  2. Менять технологию. Иногда команду заменить или нельзя или поздно, технологию тоже можно поменять далеко не всегда, но иногда что-то подправить можно.
  3. Вести душеспасительные беседы. Звучит как пропаганда, но иногда вполне работает. Бывает, что проблемы возникают просто от незнания и/или недопонимания.
  4. Арсенал трюков тут бесконечен, причем и технических, и психологических. В целом это тема для отдельного разговора.


Если что-то делаешь — делай так везде

Приезжая в страну, я не спрашиваю, хорошие или плохие здесь законы. Я спрашиваю, выполняются ли они? ©. Интернет расходится в авторстве этого мудрого высказывания, лично я вычитал это у Стругацких. Но в любом случае сказано верно.

Если какое-то решение принято, оно должно быть использовано везде и всеми. Если это где-то неприменимо, должно быть четко описано, почему это неприменимо, и описаны исключения. Ни в коем случае не должно быть ситуации, когда 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 Документация в этом длинном списке хороших вещей вы, скорее всего, проигнорировали.

продолжение следует
Denis Tsyplakov @Semenych
карма
182,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (54)

  • 0
    Очень длинное предисловие :( Пришлось перемотать, зато остальное прочитал не отрываясь.
    • 0
      Да предисловие длинновато. Порезать что-ли. А с какого именно места «не отрываясь»? До когда резать?
      • +3
        Я начал с «Итак хватит предисловий:» :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Ну как оказалось у habrahabr.ru есть ограничение на длину поста. Может если хорошо пойдет — пока мои в деревне остальное до-выложу.
      • 0
        Прочитал полную статью. Спасибо! Очень поучительно. В некоторых примерах узнал себя :)
        • +1
          Cтойте, стойте, а кто будет карму второй и третьей части повышать, когда я их таки выложу :-)
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Хитро тут устроено. Век живи, век учись. Что обидно кто-то -1 к статье поставил, а не узнаешь, что ему не понравилось.
              • 0
                Еще, если хватает кармы, стоит перенести в какой-нибудь блог. Например «Разработка». Без этого на главную пост не попадёт.
                • 0
                  Мысль дельная осталось выяснить что у меня с кармой. Точнее сколько ее надо.
                  • 0
                    Ты смотри, хватило мне кармы. Пусть будет в Разработке.
  • +1
    Видно что работу большую проделали. Сначала все советы казались очевидными, но потом, подумав пришел к выводу, что вряд ли все это может прийти в голову само по себе человеку без опыта разработки. В общем, спасибо за статью!
  • +3
    В последнее время очень мало таких статей появляется, спасибо что разбавили хабровские топики с «устройствами для гиков» :)
  • +2
    Книг вообще и учебников в частности на эту тему написано множество, и я не чувствую себя достаточно крутым, чтобы написать еще один — самый лучший.

    (из третьей части) Я лично знал двоих людей написавших и издавших книги в издательстве Manning, оба они по профессиональному уровню тянули в лучше случае на мидлов.
    Это довольно типичная ситуация: люди, которые знают многое, так же понимают, как много они ещё не знают, и воздерживаются от написания книг… а в это время гораздо менее квалифицированные, но зато более самоуверенные пишут книжки. В результате действительно хороших книг в IT катастрофически мало, зато полным-полно «профи», которые подкрепляют свои заблуждения ссылками на «умные» книжки.
    он <художник, и он так видит>, тогда это больше к менеджменту и в сторону выхода
    Вы несколько раз это упоминаете (как минимум ещё было в четвёртой части), но с точки зрения менеджмента это не самое лучшее решение проблемы. Увольнение проф.пригодного сотрудника — это, по сути, знак ошибки менеджера. Одна из задач менеджера — найти способ получить максимальную отдачу от каждого. Да, этот у нас «художник», но ведь идеальных сотрудников не бывает, у каждого свои особенности и недостатки, все разные и это надо учитывать — хороший менеджер умеет организовать работу так, чтобы максимально использовать сильные стороны каждого сотрудника, а их недостатки при этом минимально мешали работе. Художники плохо работают в команде, но зачастую для них можно найти отдельные, небольшие, но нетривиальные проекты, исследовательские задачи, создание прототипов, и т.п. — и они в большинстве случаев решат эти задачи лучше, быстрее и дешевле (если не увлекутся мелкими деталями, но за этим уже должен следить менеджер), сэкономив таким образом ресурсы основной команды. Хотя, возможно, мы с Вами просто по-разному понимаем термин «художник», тогда всё что я здесь написал может быть не актуально.
    • 0
      > Это довольно типичная ситуация: люди, которые знают многое, так же понимают, как много они ещё не знают, и воздерживаются от написания книг… а в это время гораздо менее квалифицированные, но зато более самоуверенные пишут книжки.

      Вопрос Вам и автору топика: каким образом определяете «крутость» (по выражению ОПа) или же «квалифицированность» работника?
      • 0
        Я не совсем понял суть вопроса. При совместной работе и активном обсуждении текущих проблем уровень каждого определяется достаточно быстро, сам собой. Деление на конкретные уровни вроде junior/average/senior относительно условно и у каждого может быть своё, но общая квалификация определяется без проблем. Ну, если задуматься, то легко определяется квалификация тех, кто менее опытен, чем ты или равен тебе по опыту. Квалификацию более опытных товарищей определить вряд ли получится, кроме самого факта их большей квалифицированности.
    • 0
      Нет в данном случае «художник» это имеется ввиду стадия когда не лечится.
      Я сейчас работаю в компании где вообще к сотрудникам отнсятся более чем толерантно. Если человек дело делает и пользу приносит — то все остальное решаемо. Часто можно найти проект где надостатки этого конкретного человека превратятся в достоинства. Но не всегда.
      Но есть закоренелые случаи e.g. один коллега в результате отстаивания своей точки зрения — вышел работать очень рано утром и к моменту когда все пришли не работу поменял половину классов (своих и чужих) приведя проект в абсолютно хаотичное состояние.
  • 0
    если вы выложили чужую статью, следует отмечать авторство
    • 0
      К стати, и правда интересно, неужели всё вышеизложенное случилось с одним и тем же человеком и более того, автором данного поста? Я просто уже читал около половины баек из данной статьи в разных местах.
      • 0
        нет, такое вполне возможно, просто у меня возникли сомнения в авторстве из-за того, что в диалоге habrahabr.ru/blogs/development/90880/#comment_3069161 Semenych не ответил напрямую типа «да это ж я написал)», а свёл к тому, что ещё выложит.
        сомнения усугубились из-за истеричного поведения в моём жж — не знаю, может ли человек, пишущий предъявы в стиле блондинки, написать такую довольно годную статью.
        кстати говоря, напиши он спокойно здесь, что он автор — никаких проблем. я могла ошибиться. извинилась бы. теперь как-то совсем доверия нет
        • 0
          Вообще байки 100% реальные — произошли либо со мной либо у меня на глазах.
          Другой вопрос что байки эти я многим рассказывал, так что могло и расползтись.
        • 0
          Э-э-э извините истерическое поведение в Вашем ЖЖ это про меня? А Вы извините кто? Можно ссылку на истерическое поведение?
          Или это таки не про меня?
          • 0
            • 0
              OMG какой лавкрафт, какой анонимус, какая стать? Девушка Вы о чем вообще? Это вообще livejournal.com
          • 0
            если это не вы, то прошу прощения
            • 0
              нет это не я :-) извинения приняты
    • 0
      Спасибо если вдруг когда-нибудь буду выкладывать чужую статью обязательно отмечу авторство.
      • 0
        да, судя по этому ответу, действительно я ошиблась, а там, видимо, тролль написал.
        прошу прощения(
  • 0
    > Команда должна быть с архитектурой более или менее согласна. Если яростного фаната Oracle заставить делать приложение на PostgeSQL и требовать от него высокой производительности — получится не очень. Если не получается, надо:

    Вам когда-нибудь приходилось работать с «неяростными нефанатами», «негуру Spring» и т.п.? Иными словами, с людьми, которые не привержены определенной технологии из-за того, что умеют критически оценивать (и обсуждать, естественно!) недостатки и преимущества.

    Если приходилось, расскажите, пожалуйста.
    • 0
      Да приходилось и в довольно большом количестве.
  • 0
    «Группа из трех товарищей… все они были зрелые проверенные специалисты… один большой файл на 150 Кб, в котором захардкожена строка связи с БД, включая пароль, и оттуда же идут все обращения к БД»

    … вызывает «когнитивный диссонанс». За такое даже начинающим начинающим товарищам дают по пальцам.
    • 0
      Ключевое слово АСУТП. И вообще есть много тайных мест в нашем бизнесе где десятилетиями произрастают такого рода кадры.
      • 0
        Сам «родом из АСУТП». Не то, чтобы сильно подтвеждаю, но в части разработки бардака там немеряно. В частности, из десятка организаций, с которыми я сталкивался не было ни одной с «выделенным» QA. Может быть это чисто Воронежская черта (ну, помимо более известной...), кто знает.
        Но с АСУТП там опять таки есть один тонкий момент — пока не заработает — домой не уедешь. Шеф-монтаж — это такое дело…
        • 0
          Не у нас как раз было нормально мы были нормальными IT-шниками попавшими в АСУТП соответственно смотрелись мы там крайне чужеродно, зато у нас работало. И шеф-монтаж мы делали быстро т.к. готовились дома. А вот коллеги или московского оффиса это было да.
          Старые >40 лет программеры, хорошо умеющие держать в руках паяльник и знающие наизусть прерывания MSDOS. Увы про то что настройки надо хранить отдельно и про массу дпугих добрых вещей им не рассказали.

          Был вообще анекдотичный случай — один чел хранил исходники строго на той машине где стояла SCADA диспетчера. Т.е. он месяц бухал, потом ехал и месяц творил на месте, заводил там все прямо на месте и возвращался бухать. Правда его в конце 90-х уволили.

          BTW это какая такая еще более известная Воронежская черта?
          • 0
            «Жлобство», ну по рассказам по крайней мере. «В Воронеже желание заказчика получить всё и без оплаты достигает прямо таки невероятных размеров» — цитата бывшего коллеги.
            Баек травить не буду :)
            • 0
              ну насчет жлобства не знаю, с Воронежскими заказчиками не общался. А так это по моему общесоветская черта.
  • 0
    Роскошная статья. Ждем продолжений! (Кстати, о чем они будут? :-)

    В целом по архитектуре — считаю хорошей тенденцией появление многих фреймворков для реализации тех или иных архитектурных паттернов, которые при этом просты в использовании и (что важно) «навязывают» способ сделать что-то. Как, к примеру, Ruby On Rails — «нужно и правильно» делать так то и так то. И новичкам не удается отступить от православного способа, и любой другой разработчик уверен, что никто не придумал своих ненужных «джедайских штучек».

    «Выяснилось, что дела идут хорошо, но приложение должно работать в разных конфигурациях, и есть масса проблем с развертыванием и зависимостями между модулями для некоторых конфигураций, но их почти удалось решить, убрав плагины и ведя разработку для каждой из более десятка конфигураций в своей ветке svn.»
    Это очень интересный момент. В будущих статьях будет что-нибудь про multu-tenant-системы?
    • 0
      Сложно сказать. Сейчас немного времени появилось пока жена с дочками в деревне, там видно будет.
      Рассказать то есть о чем. Заявки принимаются. Вот черновик сделал одной статьи — если все будет ровно то думаю к среде «отправить в печать». Тема — про отказоустойчивость.
    • 0
      А да, про систему с плагинами и Multitenancy. Тут байками не отделаешься, надо писать вдумчиво, так что зависит от того как карта ляжет
  • 0
    Спасибо довольно интересно, особенно байки.

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

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

    Основная цель конечно качественный результат :)
    • 0
      *но программисты ее не переваривают
    • 0
      Какой ответ вы ожидаете? Переписывание, особенно если программа работает — страшное зло. Рефакторинг ради рефакторинга. Наверное у всех программистов, которые сталкиваются с чужим кодом возникает ощущение «что за… это все надо переписать». Не факт что новая архитектура будет лучше, будет удовлетворять требованиям. А что с ней (архитектурой) будет когда команда программистов снова сменится. Люди ведь часто устают или вырастают и переходят с проекта на проект через 2-3-4 года. А проект остается. Уверен, у следующей команды также возникнет ощущение, что все надо переписать.
      • +1
        Тут да сложно что-то добавить. Главное понимать что «кропотливое соблюдение сформировавшихся правил» это вообще-то и есть архитектура.

        Переписывать это не выход. Как говорит товарищ Брукс переписать приложение вообще нельзя. Можно только написать аналогичное новое.

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

        Хотя конечно что-то очень постепенно и итерационно можно менять, но не не видя кода точнее сказать сложно
        • 0
          С итеративными изменениями в целом согласен. В долго живущих проектах они нередко происходят сами собой. Важно ответить честно для себя какие плюсы принесет изменение, какие минусы. Не стоит даже начинать, если нельзя более-менее точно сказать, сколько времени займет переделка.

          Минус итеративного подхода в том, что во время переходного периода (а он, как все временное, может длиться бесконечно долго) придется поддерживать обе версии. Например, разработчики решили переделать библиотеку Х на Y, в новых фичах использовать Y. Но старые фичи используют X и переписывать все старые фичи, чтобы они работали с Y накладно. В итоге в проекте параллельно работают две версии одной библиотеки.
          • 0
            Ну может и менее болезненно делать. Как пример — новый функционал делается по новому и постепенно вытесняет старый — это конечно геморой для команды — но за изменения надо платить.
            А две версии — это жестко — лучше без этого обойтись.
      • 0
        Хорошо, я перефразирую вопрос: допустимо ли в рамках бюджета удовлетворять личные амбиции программистов, при условии что прибыль (денежная) от удовлетворения амбиции будет отрицательной. Например, допустимо ли написать фреймворк и потерять 5 процентов от бюджета на амбиции или стоит писать много кода без всякого фреймворка? В итоге получится что люди мотивируются в проекте не только результатом, но и интересностью (удовлетворением амбиций).

        Конечно многое зависит от, и все тут белые и пушистые, но все же…
        • +1
          Допустимо все что годится для бизнеса. Нормальна ли ситуация когда программер хочет уйти из компании, а ему говорят — скажи что тебе не нравится — хочешь давай мы тебе дадим денег а ты на них будешь удовлетворять амбиции? Сами знаете чем такая ситуация в реальной жизни закончилась.

          Дьявол кроется в деталях, что за амбиции, сколько это стоит и каков бюджет. Ну и не в последнюю очередь это персоналии.

          Писать много кода это дорого и расточительно тут дело не в амбициях. Так что framework нужен только нужно обоснование для бизнеса в чем будет выгода.
          • 0
            То есть получается что все нормальные программисты готовы всецело себя отдать целям бизнеса? Пожертвовав своими амбициями на благо заказчика? С трудом в это верю я :)

            Да и как определить полезность для бизнеса? Это ведь чистой воды продажа решения и рисковое производство.
            • 0
              Сюрприз сюрприз, на работе мы работаем зарабатывая деньги.
              Все что не для целей бизнеса — надо делать за рамками проекта.
              Это не значит что на надо предлагать менеджменту что-то новое сделать. Надо просто понимать что Ваше предложение будет рассматриваться с точки зрения бизнеса и денег.

              Пример из предидущего комментария закончился созданием платформы Java т.е. Гослинг хотел полета мысли пришел с этим к менеджеру и тот посмотрел на Гослинга и решил что дядька крутой и стоит ему дать бюджет. Но при этом что характерно он говорил с начальством с точки зрения нафига это надо компании и бизнесу.
              • 0
                И правда? Вот вы например, со своим опытом, работаете только за деньги на работе? И больше вас ничего не интересует? Например, вы выберете более денежный проект в ущерб интересности?

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

                А с менеджментом надо общаться, лично я не против этого. Но все же Гослингу с его Дубом повезло, а вот сколько подобных проектов загнулись нанеся убыток? И не надо в данном случае перекладывать вину на менеджера, он хоть и разрешает, но также он и доверяет разработчику.

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

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

                p/s
                Я сам сторонник стандартных решений, но почему то кругом вижу одних велосипедистов.
                • 0
                  Вы путаете два понятия.
                  1. Я работаю потому что мне такая работа интересна.
                  2. Но раз уж работаю то я делаю работу нормально, а не так как мне в голову придет.

                  Посмотрим на проблему со стороны заказчика — он нанимает людей сделать проект. Ему вообще все равно как будет сделано внутри. Ему важно
                  1. качество
                  2. срок
                  3. бюджет
                  4. возможность владения тем, что ему сделали. Т.е. если первые 3 пункта ОК но делать изменения в проекте может только та команда которая проект делала — то заказчик де факто заложник команды разработчиков и не владеет своим кодом.
                  5. также важна предсказуемость т.е. если сказали что сделаем к 1-ому числу то сделали к 1-ому.

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

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

                  Если девелоперам плохо — думаю это проблемы менеджера и/или компании.

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

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

                  Ваша реакция?
                  • 0
                    Эх, кто бы спорил. Я тоже работаю по похожим принципам и почти во всем с вами согласен.

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

                    Я думаю не стоит дальше продолжать спор, тем более вы не признаетесь, что и вас бывали случаи произвола ;)

                    p/s
                    Кстати вы довольно интересный человек (по внешним признакам :)), может быть вы запишите подкаст с товарищем golodnyj и расскажите пару интересных баек в эфире? Я имею ввиду подкаст taop.rpod.ru/

                    • +1
                      Ну записать то можно, вопрос в том каких и сколько телодвижений надо проделать :-)

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