Category: архитектура

Верхний пост :)

Основной мой вид деятельности на данный момент - разработка ПО в области embedded. Опыт работы - с 2001 года. Сайт-визитка по этой теме: http://avl2.info/.

Кроме этого, есть еще несколько направлений, мне интересных, в которых я в той или иной степени "продвинулся". Никак не связанных с программированием.

1. Естественные роды. Все - на основании собственного (почти :)) опыта рождения двух детей. Я оба раза присутствовал на родах, во второй раз мы вместе с женой составляли план родов, выбирали и общались с акушерками, ходили на курсы подготовки и многое-многое другое :) Опыт вылился в сайт http://ru.naravniporod.com/. Буду рад ответить на вопросы, если кого-то мой опыт заинтересует подробнее.

Если же кому-то предстоят роды в Словении и его будет страшить неизвестность и неопределенность - как, где, с кем и т.п., тоже буду рад помочь, пишите!

2. Фотография. Началось это увлечение еще с 1996 года, с фотоаппарата "Смена 8М" и черно-белой пленки, проявки ее в бачке и печати фотографий в ванной под увеличителем и красным фонарем. Кое-что из того, что получается сейчас, можно увидеть здесь по тегу "Фото". Коммерческое предложение с ценами и вариантами - на еще одном моем сайте http://www.lepitrenutki.com/, который, правда, на словенском языке - для целевой аудитории.

И если вы планируете поездку в Словению (или ближайшие ее окрестности) и хотите, чтобы у вас на память остались фотографии, на которых бы были запечатлены и вы тоже (или вы вдвоем с партнером, или вся ваша семья) - буду рад оказать такую услугу. По себе знаю, что тот, у кого в руках фотоаппарат, очень редко сам оказывается в кадре. К тому же, часто приходится выбирать: сфотографировать момент или прожить его. И не лучше ли будет выбрать "прожить", а для "сфотографировать" нанять фотографа? :) Особенно в поездке в такую красивую страну, как Словения :)

3. Гимнастика для новорожденных. С первым ребенком я открыл для себя динамическую гимнастику. Со вторым - познакомился с абсолютно другим подходом, автором которого является словенка Андрея Семолич, и который она назвала "Педокинетика". (Сайт тоже на словенском). Подход очень и очень интересный, отлично дополняет собой динамическую гимнастику, со вторым ребенком я прошел всю ее методику, начав с 6 недель и закончив моментом, когда малыш начал делать первые шаги. И очень доволен результатом. В мае 2013 года я получил сертификат инструктора "Педокинетики" первого уровня (после двух лет обучения, в том числе более 200 часов практики с реальными детьми и 6-часового экзамена на реальных и непростых группах). Впереди еще минимум три года обучения :) Так что в ближайшее время появится еще одно направление в моей деятельности :) По которому я тоже буду рад помочь тем, кого это заинтересует!

97 вещей, которые должен знать архитектор ПО

Давно начатый проект перевода серии из 97 заметок наконец-то закончен!

Теперь ищу новую идею, чего бы еще интересного и непереведенного, перевести :) Если кто-нибудь знает что-то, буду рад!

Перевод "97 Things Every Software Architect Should Know"

97 вещей, которые должен знать каждый архитектор ПО



Оригинал лежит вот тут: 97 Things Every Software Architect Should Know

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

Переведено: 56 из 97.

И да, ссылки на оригиналы, конечно же, работать перестали.

Collapse )

Они же на моем сайте avl2.info

Текст оригиналов выложен под лицензией Creative Commons Attribution 3. C переводами можете поступать так же :)

56. Будьте осторожны с метафорами

(В оригинале - Don't Stretch The Architecture Metaphors)

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

В начале это срабатывает, люди начинают ощущать, что вещи движутся в правильном направлении. Метафоры появляются, и с течением времени начинают жить собственной жизнью. А всем кажется, что мы движемся вперед.

На самом деле в этот момент метафоры становятся опасными. Вот как это может повернуться против архитектора.


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

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

  • Команда разработки начинает думать, что метафора более важна, чем реальная бизнес-задача. Вы начинаете отстаивать странные решения из-за привязанности к метафоре.

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

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

    Пример: Почему объект Billing Factory создает канал для системы гребных шлюпок? Действительно ли он должен возвращать отображение граната для автовокзала? Говорите, вы тут недавно работаете?

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

Автор оригинала - David Ing

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

54. Данные - главное в системе.

(В оригинале - It is all about the data)

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

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

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

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

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

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

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


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

Автор оригинала - Paul W. Homer

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

53. Давайте разработчикам больше полномочий

(В оригинале - Empower developers)

Говорить гораздо проще, чем делать, и архитекторы ПО печально известны как раз первым. Чтобы ваши слова были не пустым сотрясением воздуха (что однако часто используется для создания vaporware*), вам нужна довольная команда разработчиков. Роль архитектора обычно заключается в установке ограничений, но архитектор может быть и тем, кто разрешает. Для этого вам нужно давать все возможные полномочия вашим разработчикам.

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

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

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

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

Автор оригинала - Timothy High

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

52. Фиксируйте обоснования

(В оригинале - Record your rationale)

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

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

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

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

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

Однако, самые важные плюсы этой практики – это то, что:

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

Усилия для создания этой документации эквивалентны написанию нескольких коротких заметок по результатам совещания или обсуждения темы. Какой бы формат вы не выбрали, это тот тип документации, вложения в который оправданы.

Автор оригинала - Timothy High

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

51. Проверяйте предположения, особенно собственные.

(В оригинале - Challenge assumptions - especially your own)

"Предположение – причина большинства неудач", или более популярно: "Don’t assume – it makes an 'ass' of 'u' and 'me', что в дословном переводе звучит как «Предположения делают из нас ослов», увы, не передавая замечательную игру слов оригинала. И когда речь заходит о предположениях, за которыми стоят тысячи или даже миллионы долларов, то вышеприведенная фраза – уже не просто смешная шутка.

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

Эта практика хороша тем, что когда эти факторы перечислены, то это может помочь выделить те предположения, которые были у архитектора, ответственного за разработку ПО. И часто эти предположения основаны лишь на «исторических причинах», традициях разработки, FUD-е или же даже на «Я где-то что-то об этом слышал»:

  • Open source проекты недостаточно надежны
  • Bitmap индексы приносят больше проблем, чем пользы
  • Заказчик никогда не согласится, что страница грузится пять секунд
  • Директор согласится только на продукцию крупного вендора

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

И не игнорируйте слово «релевантный». Иногда то, что было истинным в предыдущих версиях, не является таковым сейчас. Производительность bitmap-индексов в одной версии Oracle может отличаться от производительности в другой версии. Старая версия библиотеки могла иметь дыры в безопасности, исправленные в новой версии. Ваш поставщик надежного ПО может быть на грани банкротства. Технологии меняются каждый день, и с ними меняются и люди. Возможно, ваш шеф завтра станет фанатом Linux.

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

Автор оригинала - Timothy High

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

50. Границы и интерфейсы

(В оригинале - Architects focus is on the boundaries and interfaces)

C тех пор как Нельсон разбил флот Испании и Франции в Трафальгарском сражении, «Разделяй и властвуй» стало девизом при решении сложных проблем. Более простая формулировка, означающая почти то же самое – разделение интересов. Разделение интересов дает нам инкапсуляцию, а инкапсуляция приводит к появлению границ и интерфейсов.

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

И здесь приходит на помощь концепция ограниченных контекстов и их отображений, описанная в книге Эрика Эванса “Domain-Driven Design”. Ограниченный контекст – это область, в пределах которой модель или концепция однозначно определены, обычно представляемая в виде облака с информативным названием, определяющим ее роль и ответственность в предметной области. Например, в системе доставки могут быть такие контексты как «Погрузка», «Расписание» и «Доставка морем». В других предметных областях будут другие имена.

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

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

Автор оригинала - Einar Landre

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

48. Наблюдение вместо контроля

(В оригинале - Don't Control, but Observe)

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

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

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

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

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

Автор оригинала - Gregor Hohpe.

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