#знакомство Продолжение

Следующий виток расширения мировоззрения пришёлся на 2010-е.

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

Первым краеугольным камнем в фундаменте изменений стали книги по теории ограничений систем, начиная с почти развлекательных трех "Целей" и "Критической цепи" Голдратта, продолжая более серьезными книгами Уильяма Детмера и Лоуренса Лича. Теория ограничений произвела на меня глубокое впечатление, сильно изменила мой способ восприятия и понимания мира, научила обращать внимание на причинно-следственные связи, задавать вопросы "почему?" и "зачем?".

Вторым камнем для меня стали взгляды Насима Талеба. "Черный лебедь" и "Антихрупкость" хорошо легли на удобренную теорией ограничений почву. Пришло понимание, что просто делать свою работу хорошо и правильно - недостаточно для успеха, что ничего не существует само по себе, в отрыве от окружения. Миром правят случайности и вероятности, а наши возможности по прогнозированию сильно ограничены. Мало вкладываться в работу над понятными вещами, важно также, по "принципу штанги", защищаться от потенциально неизвестных событий. Теперь я всегда повторяю своим детям мысль, что если не хочешь ПОТОМ разгребать последствия неожиданных СЛУЧАЙНОСТЕЙ, лучше СПЕЦИАЛЬНО СЕЙЧАС что-то делать, чтобы снизить их вероятность или меньше от них зависеть. Банальный пример для детей - если ты специально всегда готов к уроку, то тебе неважно, когда учителю придет в голову дать контрольную. Более прикладной пример из программирования - если СНАЧАЛА реализовать простую обработку ошибок/исключений "вообще", которая для любой непонятной ошибки будет выдавать какое-то осмысленное, но главное - детерминированное поведение (запись в лог, сообщение об ошибке пользователю и т.п.), то тебе неважно, какие ошибки случатся ПОТОМ. Когда все неизвестные варианты "прикрыты", можно спокойно делать частные, улучшенные, специализированный обработчики конкретных ситуаций.

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

————————-
продолжение следует...

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

Самое сильное воздействие на меня оказали книги "Lean Startup" Эрика Риса про итеративный поиск места продукта на рынке, "4 шага к озарению" Стива Бланка про Customer Development и формирование понимания потребностей клиента и "Построение бизнес-моделей" Остервальдера. Будучи программистом мне казалось, что достаточно сделать хорошо работающую программу, а остальное приложится само. На деле оказалось, что работа программистов, безусловно, важна, но, как не противно было это осознавать, с точки зрения бизнеса глубоко вторична. Программа интересна лишь постольку, поскольку она помогает решать чьи-то проблемы, приносит кому-то какую-то понятную пользу, измеримую хотя бы в деньгах. А работа программистов с точки зрения бизнеса - это всего лишь вынужденные расходы. И, грубо говоря, если расходы меньше доходов (как меры пользы) - то это хорошая работа, а если больше - то плохая :) Хотя, конечно же, все гораздо сложнее, зависит от стадии развития продукта, зрелости рынка и т.п.

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

В частности, я считаю уверен, что на начальной стадии развития продукта нужно делать не все, что теоретически может понадобиться в дальнейшем, а только то, чем прямо сейчас, в обозримом будущем кто-то будет пользоваться, поскольку неиспользуемый код пользы не приносит, а вред от него есть - его надо поддерживать и сопровождать. Так мы сильно экономим в части объема работы СЕЙЧАС, но важно при этом не заблокировать себе возможности развития и масштабирования ПОТОМ, когда выяснится, какое именно направление роста является перспективным, а функционал - востребованным. Такой подход сильно противоречит часто принятому среди программистов подходу "давайте сразу делать нормально, чтобы потом не переделывать". Я не верю, что возможно заранее угадать, как будет правильно, все равно придется переделывать, и чем меньше кода будет написано - тем меньше придется переделывать. Но не путайте с подходом "делать по-быстрому по текущим задачам, а там посмотрим", который вообще не предусматривает мыслей о будущем :). Напротив, я говорю о том, что мы не знаем, что в итоге "вырастет", поэтому не строим заранее заборы, но закладываем множество "ростков" на будущее, те, которые будут востребованы - прорастут, тогда и заборчики расставим в правильных местах. Одновременно с этим мы понимаем, что какие-то части (мы пока не знаем какие) точно окажутся лишними, их придется вырезать. И потому программа сразу строится модульной/послойной, на каждом уровне разбитой на части-кирпичики, которые можно относительно независимо растить, подрезать, удалять, как ростки в саду, не затрагивая соседние грядки. Структура связей и декомпозиция модулей не статична, она развивается эволюционно, но она всегда есть, соответствует нашему текущему представлению о том, каким должен быть продукт. Архитектура продукта, соответственно, определяет не только его текущее состояние "в статике" но также принципы и возможности модификации и развития продукта в будущем. Да, в моменте мы можем иметь дело с примитивным монолитом, но в его "ДНК" уже могут быть заложены гены гигантской распределенной системы. А могут быть и не заложены. Все, опять же, зависит от контекста :)

Короче говоря, принцип-то в основе лежит простой, но его практические применения в каждом отдельном взятом случае могут сильно отличаться. Но это уже другая история.

все еще #знакомство

продолжение следует? 😉

Друзья!
Спасибо что читаете этот канал, и мы встречаем этот год вместе! 🎊🎉
Поздравляю всех с наступающим новым годом! 🎄🎄🎄
Пусть все неприятности останутся в уходящем 2024-ом, а новый год принесёт драйв, новые интересные вызовы и достижения!😜

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

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

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

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

Так вот, в условиях вечной нехватки времени я решил попробовать на время отказаться от идеи писать вдумчивые посты, а зайти с другой стороны. Беру 10-15 минут, хватаю пролетающую в голове мысль и коротко выписываю все, что прямо сейчас приходит в голову.

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

Как часто мы слышим фразы типа "так делать неправильно, а правильно вот так"? И я как-то задумался, а что такое "правильно"? помните "что такое хорошо и что такое плохо" Михалкова? Там все четко расписано - вот так делать хорошо, а так плохо. Жаль, что в мире ИТ архитектуры нет такого мануала. Тут принято говорить, что все "зависит от контекста". Но почему-то часто, когда приходишь в команду с таким контекстно-зависимым решением, то через раз слышишь, что так неправильно...

Мне видится, что правильные или неправильные решения могут быть в математике, когда есть строгие и четкие правила построения выводов и вычислений, когда любое рассуждение формализовано и воспроизводимо, т.е. можно гарантированно на тех же входных данных получить тот же результат. Наверное, в ИТ можно поступать так же, т.е. составить алгоритм принятия решений, накидать в него все возможные входные условия и формально прийти к решению. Но что-то мне подсказывает что это нереально. Во-первых, входных условий невообразимо много. И даже если вы думаете, что учли все, всегда есть еще одно. Методы принятия решения на одних и тех же входных данных тоже разные, опираются на разные принципы, зависят от состояния и стадии ЖЦ. Зависят от внешней реальности, которая вообще часто непредсказуема и носит "полувероятностный" характер.

Вспоминается фраза одного из сейлов - Мы выиграем этот тендер с вероятностью 90%, но вероятность вот вот тех 10% - примерно 60%.

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

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

Пока читал статью, #анекдот вспомнился.

Чувак выпал из окна 20-ти этажного дома. Пролетая мимо 10-го этажа думает: "пока все идет нормально...".

Захотелось перефразировать:

Менеджер начал управлять по #Agile проектом, который сдавать через 20 недель. На 10-й неделе смотрит на диаграммы в jira и думает "пока все идет нормально...".

И еще #цитата в тему

Экзамены, сэр, – это чистейшая чепуха, от начала до конца. Если ты джентльмен, так тебя учить нечему, тебе достаточно того, что ты знаешь. А если ты не джентльмен, то знания тебе только во вред.
О.Уайльд, "Портрет Дориана Грея"

превращается в ...

#Agile методологии - это чистейшая чепуха, от начала до конца. Если ты умеешь работать и выдавать результат, так тебе и методологии не нужны, тебе достаточно того, что ты знаешь. А если ты не умеешь работать, то любые методологии тебе только во вред.

Судя по реакциям, эта мысль требует пояснения.

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

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

😭 Нихуя не просто

Ловушка индустрии №1 — думать, что должно быть просто.

«Просто используй golang»
«Просто перейди на микросервисы»
«Просто тебе нужен kubernetes»
«Просто используй фреймворк»
«Просто найми аналитика»
«Просто покрой всё тестами»
«Просто перейдите на kanban»
«Просто подключи left-pad в npm»

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

Просто было в детском саду.
Покушал, поспал, покакал, проснулся.

#сракигорят | Предложка

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

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

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

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

#документация

Простой #рецепт как делать полезную документацию на основе сценариев:

1. Определиться с адресатами документации - кто, зачем и как будет её использовать. Наивно думать, что пользователям, администраторам и, скажем, продавцам программного продукта нужен один и тот же документ. Это будут разные документы и по структуре, и по содержанию. Хотя, конечно, в них могут быть общие части.

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

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

#документация

Еще несколько слов про требования к документации, в ответ на комментарий. Действительно, требования к документации не "висят в воздухе", они привязаны к контексту, к цели проекта, продукту, зависят от текущей стадии ЖЦ, объемов инвестиций/финансирования и т.п. Я хотел акцентировать внимание на том, что часто встречающееся требование "полноты" документации бессмысленно и даже вредно.

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

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

Документация должна быть:
1. Полезна для .... — тут вставляем для кого и чего пишем документацию
2. Своевременна — первый полезный вариант должен быть не позже чем ...
3. Посильна по ресурсам — ограничения на объем и ресурсы, которые можем потратить

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

А уже дальше, под каждым пунктом будут прорастать более детальные требования и ограничения - по структуре, формату и т.п.
И тут очень важна прослеживаемая трассировка Цель — характеристика — конкретное требование
Например,

Делаем продукт для B2E
документация должна быть полезна для инженеров внедрения
Нужен документ "Руководство по развертыванию и настройке"
Структура документа: .....
Доступен онлайн
Поддерживает поиск по ключевым словам

все еще #документация

P.S. А если самим требования к документации формулировать лениво - используйте ГОСТы и не жужжите :) Некоторые заказчики так и делают.

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

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

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

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

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

- Разбиение по конструктивным элементам деплоя - контейнерам/сервисам, которые могут быть независимо развернуты в среде исполнения

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

- Разбиение по архитектурным "слоям", когда базовые, низкоуровневые слои предоставляют функциональность для реализации слоям на более высоком уровне абстракции.

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

- В конце концов, разбиение по ограниченным контекстам в соответствии с моделированием бизнес-доменов.

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