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

Category was added automatically. Read all entries about "архитектура".

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

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

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

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

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

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

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

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

Семейные расстановки

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

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

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

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

Посмотрим, что будет дальше.

Тем, кто в Харькове - могу дать контакт ведущего. Думаю, от ведущего эффективность техники тоже зависит. Остальным могу рекомендовать попробовать - техника распространена практически везде. Ключевое слово - Хеллингер.

Термы Тополшица и окрестности

Много раз по пути из Любляны в Грац и назад я замечал на автобане указатель "Термы Тополшица. Мозирский гай". Мозирский гай, к примеру, упоминается среди сотни мест Словении, которые стоит посетить. И вот однажды на скидочном сайте появилось предложение "Две ночи в термах на двоих с завтраком, за 86 евро". И конечно же, я не мог этим не воспользоваться :)

Collapse )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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