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

Сказка ложь - да в ней намек. Может кто найдет что то полезное:) ибо проблемы с проектированием есть не только в разработке программ

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

в статье часто встречаются специфические термины - если надо могу прикрепить небольшой словарь

Заранее ответ на вопрос "почему ты это публикуешь на АШ а не на профильных форумах?" - к сожалению я невысокого мнения о многих профильных форумах, где очень любят догматы и не любят думать головой - а вот посраться ради срача точно любят :) ну и я не зарегистрирован ни на одном профильном форуме - мне некогда на них сидеть 

 

Введение

Все вокруг говорят: «Давайте проектировать» или «я проектирую», но зачастую даже не представляют, как это делать. Ниже описывается лично мое виденье этой проблемы на основании достаточно большого опыта (как удачного, так и не очень)

Данный документ не претендует на истину в последней инстанции. Предлагаемый подход можно использовать не только при проектировании ПО в целом но и при проектировании интерфейсов, классов, скворечников и для прочего. Можно даже и не использовать данную бумажку и дальше не читать – каждый сам себе «злобный буратино», а уговаривать кого-то – не есть цель данного документа.

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

Может показаться что написано несколько сумбурно, но, во-первых, я все-таки не писатель за деньги, а во-вторых все это было написано кусками без отрыва от производства, в коротенькие перерывы между различными авралами

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

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

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

Что такое проектирование

Сначала определение (в данном случае из педивикии, но не суть)

Проекти́рование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765). Результатом проектирования является прое́кт — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.

Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией для стадии реализации (воплощения) системы (англ. system realization).

Как можно видеть – проектирование это в первую очередь процесс из опыта зачастую итеративный, в большинстве случаев процесс «от общего к частному». На выходе этого процесса должен быть какой-то результат для реализации системы.

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

Про общее и частное это с одной стороны моя придумка с другой, например, проектирование самолета начинается с рисования общего вида и общей компоновки. В сфере разработки ПО есть такой термин как концепция, которая как раз является «общим видом» на архитектуру ПО, и после того как определена концепция системы, производится более подробное проектирование составных частей системы, вплоть до написания спецификаций на отдельные модули (чего в последнее время практически не делается)

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

Что нужно для успешного проектирования?

Самое главное, что нужно для успешного проектирования помимо светлой головы проектировщика это требования к системе.

Любые проектные решения и выбранные технологии должны прямо вытекать из заявленных заказчиком требований и ограничений. Не должно быть такого что «мы применим эту технологию/архитектуру потому что это прогрессивно/модно/круто/новая_строчкав_резюме».

Поскольку последнее время даже фразу «управление требованиями» все забыли, не говоря уже о ее применении – получаемые для проектирования требования становятся все хуже и хуже. Зачастую на вход для проектирования поступают сырые отрывочные требования от заказчика – и фактически работать с требованиями приходится самому проектировщику.

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

Приоритеты при проектировании

Очень важная вещь, с которой надо определиться при проектировании - это приоритеты для выбора решений и/или технологий.

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

Часть может неявно вытекать из различных требований (например, требование гарантированной доставки сообщений означает что при выборе технологий приоритет необходимо отдавать проверенным и надежным решениям)

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

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

Для большей наглядности приведу свой стандартный список приоритетов:

  1. Удовлетворение требованиям заказчика – это наивысший приоритет в любом случае. Если решение или технология не удовлетворяют всем требованиям заказчика – то это решение просто выбрасываем без сожаления.

  2. Быстродействие – я всегда ставлю этот приоритет выше других по той причине, что в процессе разработки и эксплуатации системы будет возникать очень много причин снижающих производительность (увеличение размера БД, костыли при реализации, слабое оборудование заказчика и т.п.). Чем больше система живет – тем больше таких причин, поэтому лично я стараюсь поставить этот приоритет на первое место (не всегда, не везде, но в основном). Так же из опыта я вынес одно простое правило – если быстродействию системы не уделялось достаточно внимания на этапе проектирования – система получится тяжелой и медленной, причем ее невозможно как-то значительно ускорить (к примеру, на кривой базе или с криво работающим ОРМ даже индексы не помогают).

  3. Надежность – по возможности используемые решения и технологии должны быть проверены опытом и временем. Бежать впереди паровоза и втыкать все новейшие проектные решения и технологии в проект означает только одно: проблемы в эксплуатации. При проектировании рекомендуется использовать условные “шаблоны проектных решений” которые хорошо зарекомендовали себя в прошлом.

  4. Простота реализации и поддержки – очень важно чтобы система была простой и понятной. Причем надо обратить внимание что этот приоритет не означает «поменьше кода» (или поменьше подсистем) – кода или подсистем может быть и побольше – если это упрощает понимание системы в общем и частном. Код можно (и временами нужно!) писать копипастом, а не использовать закрытые решения которые сложны для понимания, настройки, реализации и поддержки (сейчас это был камень в огород различных навороченных ОРМ, в которых просто сделать пример из туториала, а в серьезных решениях почему то нет-нет да встречается прямой доступ к БД в обход ОРМ - регулярно такое наблюдаю, и не надо мне рассказывать что люди просто не умеют готовить ОРМ, я уже накушался разных приколов от ОРМ – основной из них снижение производительности на порядки)

  5. «Связанность архитектуры и решения» - очень важно чтобы отдельные части решения были минимально связаны друг с другом – это позволит легко изменять отдельные части, не переделывая остальные. При этом не надо усердствовать в создании лишних интерфейсных слоев и прочего. Криво сделанные интерфейсы зачастую только ухудшают ситуацию, поскольку может потребоваться такое изменение, которое потребует изменения и связанных систем, и всех интерфейсов между ними.

  6. «Не плодить зоопарк» - по возможности система должна быть спроектирована и реализована с использованием небольшого набора проектных решений и технологий. Если к примеру веб-интерфейс в системе реализован в разных частях на разных библиотеках – это дополнительные сложности с поддержкой и развитием. Так лучше не делать!

  7. «Контроль кода» - все наиболее важные части системы должны по минимуму использовать решения и библиотеки от сторонних производителей (особенно если это не проверенный временем поставщик). Как вариант желательно иметь план или возможность обойтись без сторонних библиотек. Да я знаю, что нехорошо делать велосипеды, однако кривой чужой велосипед, во-первых, попортит крови в эксплуатации, а во-вторых свой велосипед всегда можно допилить до вменяемого состояния, чего зачастую нельзя сделать с чужим. Перебарщивать с велосипедами тоже не надо

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

 9. Новизна технологии – для меня это приоритет с низшей важностью, технологии появляются каждый день, так же быстро могут умереть. Для серьезной системы, которая живет годы – лучше использовать может быть «устаревшие» технологии и библиотеки, но при этом иметь нормальную поддержку поставщика.

Выбранные архитектором приоритеты и их важности должны быть все время на листочке перед архитектором (ну или в голове) все время пока производится проектирование. Во всех сложных случаях, когда непонятно что выбрать – нужно всего-навсего свериться с листочком и наступит полная ясность в выборе.

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

Этапы проектирования

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

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

Сбор бизнес требований

С одной стороны, самый простой этап – разговорить заказчика и просто все записать. Однако, как показывает практика зачастую заказчик даже не может сформулировать что он хочет. А бывает, что и поговорить то с заказчиком нет возможности или он неадекватен :) (см ниже про неполную и недостоверную информацию)

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

В качестве результата этого этапа у вас должен быть список всех исходных требований.

БАНАЛЬНЫЙ СПИСОК ИСХОДНЫХ ТРЕБОВАНИЙ ЗАПИСАНЫЙ НА ЛИСТОЧКЕ!

И НЕ НАДО НА ЭТОМ ЭТАПЕ НИЧЕГО ВЫДУМЫВАТЬ! ТОЛЬКО ИСХОДНЫЕ ТРЕБОВАНИЯ ЗАКАЗЧИКА!

Основная ошибка, которая делается на этом этапе – сразу пишется техническое задание, в которое вписываются не исходные требования заказчика, а какие-то придумки того, кто пишет.

Анализ бизнес требований

Один из самых сложных этапов и как ни странно один из самых игнорируемых.

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

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

Один мой коллега как-то сказал заказчику: «Мы автоматизируем процессы, если процесс отсутствует мы не можем его автоматизировать» - очень хорошая мудрость.

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

Кто-то скажет – это задача аналитиков, с одной стороны да, аналитики должны работать с требованиями, но лично я убежден что архитектор, который не влезает в анализ требований к системе – вряд ли способен сделать что-то полезное.

Как результат этого этапа должен быть сформирован документ с детальной (по возможности) проработкой бизнес процессов для проектируемой системы

Как часть этого этапа необходимо четко разделить требования на бизнес-требования (требования, без которых невозможно реализовать процессы заказчика) и функциональные (не относящиеся к бизнесу – например хотим, чтобы все было реализовано на java)

Опять же никаких придумок на этом этапе быть не должно!!

Основная ошибка, которая делается на этом этапе – не происходит выделения бизнес процессов, требования существуют как бы сами по себе.

Так же зачастую пишется какой-то бизнес процесс в двух словах, а подробности не изучаются.

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

Формирование функциональных и нефункциональных требований к системе

Часть требований уже сразу приходят в виде функциональных и нефункциональных (в основном) от заказчика (хотим, чтобы все было реализовано на java, на платформе Linux) и их можно непосредственно использовать при проектировании.

Но часть функциональных требований могут прятаться среди бизнес-требований. Поэтому на данном этапе мы еще раз исследуем все бизнес-требования и процессы.

Например, в приведенном выше примере – после исследования процесса птичка прилетела (что это за птичка?) - мы можем уточнить функциональные требования для скворечника – такое функциональное требование как диаметр входа.

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

• Необходимо клиент-серверное приложение с тонким клиентом
• Поддерживаемые браузеры (согласовать список с заказчиком)
• Необходима защита персональных данных, защита платежей

 

Так же из бизнес-процессов можно вычленить, например, минимальные скорости обработки данных, форматы обмена с внешними системами (периодичность обмена) и много всего другого.

В любом случае по возможности все эти требования должны быть согласованы с заказчиком

В качестве результата этого этапа – необходимо получить документ со списком всех заказанных и вычлененных функциональных требований (с указанием откуда появилось то или иное требование)

На данном этапе обычно как раз и надо писать то что в ГОСТ называют Техническим заданием.

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

Формирование концепции архитектуры ПО

После того когда вы более-менее поняли, что хочет заказчик, наступает самое интересное – собственно само проектирование.

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

Для начала я обычно предлагаю определиться с концепцией, т.е. в общих чертах (в крупную клетку) определиться с архитектурой. Например, уже по минимальным требованиям можно определиться будет ли это клиент-серверная архитектура или это будет stand-alone приложение или это к примеру будет некое интеграционное приложение от точки к точке, или это будет многокомпонентная система, включающая в себя и клиент-сервер и интеграцию с внешними приложениями и прочим.

К сожалению, на этапе формирования концепции сложно дать подробные рекомендации по выбору архитектуры. Основной критерий выбора архитектуры – требования к системе. Если архитектура (и ее реализация впоследствии) позволяют реализовать все требования – это хорошая архитектура. Идеальная архитектура должна удовлетворять всем требованиям к системе, быть простой в реализации, быть простой в поддержке, надежной в продуктиве … Но в общем идеал недостижим :)

Так что теперь мы призываем на помощь весь свой опыт, трезвый (если получится) разум, все знания, которые может дать нам Гугл или Яндекс и начинаем пробовать составлять «кубики возможных решений»

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

Необходимо так же отметить что на этапе формирования концепции архитектуры – сразу же возникает ряд ограничений (и изредка дополнительных возможностей), связанных с этой самой архитектурой. Эти ограничения необходимо зафиксировать и согласовать с заказчиком.

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

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

Для каждого варианта концепции попытайтесь отвечать на различные вопросы из жизни системы:

1. Насколько просто ее будет реализовать (тут мы пересекаемся со следующим этапом)?
2. Как вы будете ее обновлять в продуктиве?
3. Как вы будете искать неисправности в системе?
4. Как будет вести себя система при различных отключениях внешних систем?
5. Как будет вести себя система при увеличении нагрузки?
6. Какие возможности будут для расширения функциональности системы?
7. … (Любые вопросы которые вы сможете придумать)

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

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

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

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

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

В этих случаях нарисовать несколько вариантов архитектуры – это очень хороший способ выявить слабые места каждого варианта (и обсудить их с заказчиком)

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

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

Таким образом на выходе этого этапа мы получаем первую общую схему архитектуры приложения с указанием модулей и соответствующих требований которые будет реализовывать каждый модуль (нечто похожее на Эскизный проект).

Очень хороший совет: не стесняйтесь (или смирите гордыню) и попробуйте спросить совета у любого из разработчиков или более старших товарищей. Спросить совета не зазорно, а результат иногда превзойдет все ожидания. Даже не обязательно ваш собеседник будет что-то понимать в том, что вы делаете – возможно сам разговор с ним наведет вас на хорошую мысль или покажет вам что вам надо еще узнать допустим у заказчика чтобы правильно выбрать нужную архитектуру. У меня было пару случаев, когда даже не очень хорошая идея, поданная со стороны, при должном обдумывании могла хорошо вписаться в решение впоследствии.

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

И еще раз скажу – не плодите лишние сущности без необходимости – обычному интернет магазину без надобности та же микросервисная архитектура, а приложение hello world необязательно писать с использованием классов и наследования.

Проработка реализации функциональных требований к системе и выбор технологий.

Данный этап предлагает дальнейшее погружение в проектирование и фактически является логическим продолжением предыдущего этапа.

На предыдущем этапе мы выбрали некую концепцию архитектуры нашего приложения (например, клиент сервер с тонким клиентом, с реляционной БД, и модулем отчетов).

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

 При этом возможно часть технологий вам жестко задаст заказчик в требованиях (в некоторых случаях удается его убедить что он идиот – но тут уж как повезет). Часть технологий косвенно будут вытекать из требований, а вот с остальными технологиями вам придется сделать свой непростой выбор.

При этом вам придется затрагивать очень много аспектов и выяснять их приоритетность в конкретном вашем случае:

Так при выборе БД вы будете, например, рассматривать такие вопросы

• Цена (в последнее время очень важный параметр:))
• Возможность установки этой СУБД на территории заказчика (может быть у него только Linux машины)
• Возможность создания отказоустойчивой конфигурации и/или балансировки нагрузки (и ее надежность)
• И т.п.

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

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

Так же на данном этапе необходимо прорабатывать различные «мелкие проблемы» такие как структура БД, диаграммы последовательностей при взаимодействии модулей, разработка интерфейсов для обмена между модулями системы и обмена с внешними системами и подобное. На данном этапе особое внимание надо уделить вопросам аутентификации, разделения доступа, а также вопросам аудита системы.

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

Как результат данного этапа должен быть оформлен документ похожий на Технический проект из ГОСТ.

Данный этап может быть продлен вплоть до написаний подробных спецификаций программистам – но такое встречается все реже и реже

Оформление результатов проектирования

Когда-то давным-давно, в далекой галактике требовалось оформление всей документации проекта по ГОСТ. Сейчас в большинстве проектов даже заказчики не требуют даже минимально значимого оформления требований, не говоря уже о результатах проектирования.

Что из этого следует? – опять же повальная деградация как проектирующих, так и проектных решений. Тот же самый ГОСТ пусть и в рекомендательном порядке требовал хоть какого-то оформления эскизных и технических проектов с указанием хотя бы минимальной информации о результатах проектирования.

Сейчас же в большинстве проектов результаты проектирования не оформляются никак.

В тех же случаях, когда какая-то документация на проекте имеется – в большинстве случаев она содержится в устаревшем виде и не поддерживается. Толку от этой документации маловато.

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

Исходя из своего опыта могу порекомендовать в обязательном порядке оформлять хотя бы минимальный набор документов (или хотя бы диаграмм) и самое главное – ПОДДЕРЖИВАТЬ ИХ АКТУАЛЬНОСТЬ НА ПРОТЯЖЕНИИ ВСЕГО ПРОЕКТА.

Таких документов немного и их несложно будет создать и поддерживать

1. Исходные требования заказчика к системе. В процессе доработок стоит обновлять этот документ новыми хотелками.
2. Общая концепция системы в которой описываются бизнес процессы, ограничения, основные проектные решения и причины их выбора с указанием минусов и плюсов. Если есть какие-то нестандартные решения, то и их стоит вписать в этот документик. В процессе реализации стоит вписывать в него какие-то хитрые костыли с объяснениями причин и ограничений.
3. Общая схема подсистем, модулей и внешних взаимодействий системы – такой документ несложно создать и поддерживать, а для, например, нового разработчика на проекте – такой документ позволит относительно быстро понять связи подсистем и представить, как это все работает
4. Структура БД – обязательно необходимо создать диаграмму сущностей БД и поддерживать ее актуальность. Не надо надеяться на средства, которые могут по БД поднять ее существующую структуру. Смысл этого документа как раз в том, что сначала мы рисуем БД на бумаге – ручками щупаем каждую сущность и связь – это помогает понять, что сделано не так и исправить проблему ДО того, как началась разработка
5. Если есть сложные схемы состояний каких-то сущностей – то в обязательном порядке диаграммы состояний – это гораздо эффективней чем недельное изучение кода
6. Протоколы и схемы взаимодействия с внешними системами.
7. Для сложных взаимодействий – обязательно диаграммы последовательностей
8. Для систем с подсистемами на разных серверах – вам многие скажут спасибо за диаграмму развертывания, причем эта схема должна помогать соотнести сущности, изображенные в общей схеме (см пункт 1) с реальными серверами.
9. Даже если вы совершенно не хотите ничего этого записывать и рисовать – заведите маленький текстовый документ куда будете записывать короткие заметки о том, что вы решили и почему – это будет очень полезно тем же программистам на проекте.

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

Проектирование БД

Проектирование БД с одной стороны хорошо описано в книгах, с другой стороны мало кто их читает. Тем более мода на Code First подход совсем разрушила такую профессию как разработчик баз данных.

Ну и производительность железа выросла многократно – база прощает теперь и отсутствие индексов, и кривую структуру.

Но от судьбы не уйдешь и такие приложение все равно настигает кара небесная в виде медленных запросов (особенно если их генерит ОРМ), поэтому при проектировании БД рекомендуется делать все так как завещали деды в больших талмудах (вкратце пересказ):

1. Проработка сущностей и их связей (выявление сущностей, формирование связей, определение ограничений, нормализация и прочая скука)
2. Проработка основных запросов в системе и оптимизация структуры БД (возможно с денормализацией) под эти запросы

Так же дам несколько советов:

1. База должна быть спроектирована настолько идеально насколько можно – хорошая БД – половина успеха всей системы. Не жалейте времени на проектирование БД.
2. По возможности структура таблиц и их связи должна соответствовать бизнес сущностям и их соответствующим связям
3. По возможности проектирование БД и ее развитие, оптимизацию, поддержку должен вести какой-то один человек из проектной команды – желательно сам архитектор
4. Структура БД должна быть оформлена в виде документа и этот документ должен всегда быть актуальным
5. Необходимо заранее прорабатывать вопрос обновления структуры и данных БД при выпуске обновлений
6. Тщательней выбирайте типы для хранения данных. Например, не используйте типы с плавающей запятой там, где по требованиям достаточно обойтись типами с фиксированной запятой, иначе потом накушаетесь проблем с округлением данных. Дисковое пространство теперь дешевое и процессоры мощные, но не надо, к примеру, городить ключи из GUID без необходимости – и места много занимают и с производительностью может выйти нехорошо (да и некоторые задачи проще составными ключами решать)
7. По возможности используйте хранимые процедуры – именно для доступа к данным, а не для логики – это дополнительный слой абстракции данных.
8. Банально, но «не используйте триггеры» :) (если уж только совсем без них никак, но сперва проработайте другие варианты – те же хранимые процедуры если используются как дополнительный слой абстракции данных вполне подходят для большинства задач, которые вешают на триггеры)

«Связанность» архитектуры

Отдельно хотелось бы остановиться на «связанности» архитектуры, которая упоминалась в разделе «Приоритеты при проектировании». В большинстве решений, которые мне довелось увидеть в последнее время, различные компоненты настолько жестко связаны между собой, что небольшая правка в одном модуле требует изменений почти по всем компонентам. Зачастую тем самым «цементирующим» звеном являются модный Code First или какой-нибудь ORM. И это основная причина почему я не любитель таких технологий. Как только для реализации бизнес логики мы начинаем использовать сущности БД – сразу получаем проблемы с той самой «связанностью». Становится сложно изменить бизнес-логику, не поменяв БД и наоборот.

Типичный случай — это, например, построение отчетов по данным с которыми работает приложение, как показывает практика построение отчетов через ORM ведет к резкому снижению производительности, и поэтому движки для отчетов прикручивают к БД напрямую (или через view которые делаются вручную). В этом случае мы получаем очень странную с точки зрения архитектуры ситуацию: БД делается через код приложения и доступ к данным обеспечивается двумя интерфейсами (через ОРМ для приложения и напрямую для отчетов). Если вдруг для отчетов потребуются дополнительные таблицы (например, подгрузка данных из сторонних приложений) – их надо делать в коде приложения, и получается, что, изменяя отчет, мы правим все приложение.

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

В данном примере я хотел показать лишь то что данные (и в целом БД) – это отдельная подсистема, а никак не часть кода приложения как многим хочется видеть.

Раз это отдельная подсистема – у нее должны быть интерфейсы взаимодействия с другими подсистемами и желательно, чтобы количество этих интерфейсов было не более одного. Что резко упростит изменение как структуры данных, так и правки в смежных подсистемах.

Как вариант я встречал решения где над БД повешен веб-сервис – через который все остальные подсистемы запрашивали данные. Работало конечно небыстро, но изменения в каждой подсистеме минимально затрагивали другие. (тут как говорится надо искать компромисс между быстродействием и архитектурой)

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

Для примера хорошего решения проблемы связанности архитектуры приведена байка о бассейнах в конце документа.

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

ПЛАН Б

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

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

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

Так же опять надо отметить что новые технологии обладают очень нехорошей способностью подкидывать проблем как раз под конец разработки или уже в процессе эксплуатации – необходимо либо иметь запасной план по переходу на другие технологии или еще в самом начале разработки проверять выбранные технологии в окружении максимально схожем с условиями будущей эксплуатации (например проведите нагрузочные тестирования как можно раньше и по возможности проводите разработку и тестирование на данных приближенных к тому что будет в реальной эксплуатации)

Основные ошибки при проектировании

Главная ошибка проектирования

Главная ошибка проектирования – игнорирование этого самого проектирования, попытка сразу делать реализацию, когда кажется, что «все понятно».

Это самая к сожалению распространенная ошибка всех разработчиков ПО и не только разработчиков ПО.

Конечно если вы пишете программу hello world или какой-то пробный проект для знакомства с какой-то технологией, возможно этап проектирования можно и опустить (или по-быстрому в уме прикинуть что и как)

Но как только задача выходит за рамки «попробовать» «для себя» - ни при каких условиях этап проектирования не должен игнорироваться. Ошибки в реализации относительно легко исправить, а вот ошибки на этапе проектирования зачастую нельзя исправить никакими усилиями. Ведь когда система перешла в промышленную эксплуатацию – в зависимости от принятых решений заказчик уже и оборудования, и лицензий накупил – и даже криво спроектированная (и само собой плохо работающая) система обречена на жалкое длительное существование (и бедные пользователи вместе с ней). Это влечет за собой разочарование заказчика в ваших умственных и профессиональных способностях. Далее это влечет банальную потерю денег либо прямую (заказчик требует вернуть деньги за некачественную работу), либо косвенные (заказчик ищет исполнителей поумнее)

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

Построение архитектуры от реализации

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

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

Очень часто встречается еще один подвид такой ошибки – заказчику «втюхали» крутейшую (и дорогую) софтину и необходимо создать решение, обязательно использующее это ПО. Правда в таком случае к архитектору вряд ли можно сильно придраться – у него почти нет выбора кроме как сделать что-то плохое :)

«Рюхающее» ядро

Очень часто из-за недостатка требований к системе или по глупости – все стремятся делать «универсальную систему, которая может все». Сложность системы получается совершенно неадекватна решаемой задаче, плюс сложности с поддержкой и доработкой.

Из этой же серии структура БД из двух-трех таблиц в которой можно хранить все (правда с производительностью проблемы и лучше застрелиться чем поддерживать, но зато структура универсальна!!!)

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

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

Неполная или недостоверная информация на этапе проектирования

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

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

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

Так же регулярно встречается практика, когда разработка фактически ведется еще на этапе сбора требований и для проектирования фактически даже время не выделяется

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

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

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

В общем и целом – собирайте всю доступную информацию о заказчике и его хотелках, пытайтесь представить его бизнес-процессы, это даст хоть какую-то информацию к размышлению.

Как стать архитектором? (полушутливое дополнение) :)

Считается что архитекторами становятся опытные программисты, которые все видели все знают и прочее. При этом каких-то курсов где учат на архитектора как уже было отмечено – не существует. В книгах все вопросы проектирования обходятся лихим кавалерийским налетом. Например, чтобы сдать экзамен по архитектурным вопросам – достаточно просто выбрать правильные ответы из учебника. Причем выбор по технологиям на экзамене обычно совершенно банален – надо выбирать самые модные технологии для реализации – вот и сдал экзамен на архитектора :)

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

При этом надо отметить один важный нюанс – зачастую получив погоны «архитектора» - многие уже не желают быть разработчиком – и вот тут и наступает деградация такого «архитектора». Напроектировать можно все что угодно «бумага ведь все стерпит» и не реализуя самостоятельно собственную архитектуру – эти архитекторы теряют важную обратную связь.

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

Так что постоянная практика проектирования (классов, интерфейсов, подсистем) и непосредственное участие в разработке и ПОДДЕРЖКЕ напроектированного – единственное что может поддерживать навыки хорошего владения проектированием.

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

Что делать? (совет всем, кто берется за проектирование)

В первую очередь: ДУМАТЬ

Причем думать СВОЕЙ ГОЛОВОЙ

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