Comments 15
Tl;dr
Тогда я не буду отправлять вас читать свой перевод статьи "Делает ли гугл нас глупее" 2008 года (я тогда был под ником amIwho) которую стырил Хакер: https://xakep.ru/2008/07/22/44551/
Просьба пояснить следующую мысль.
Например, эмерджентные свойства софтверной системы — это архитектурные атрибуты качества.
Не могу уловить, есть ли логическое следствие. Ведь любая система может быть сделана негибкой, небезопасной, немасштабируемой, непрозрачной и прочее "не", хотя быть при этом сложной.
Да, может. Значит при внесении изменений в систему не учитывались эти атрибуты качества.
Атрибуты качества - это то, насколько система масштабируема, поддерживаема, ортогональна и изучаема. Для того чтобы понять насколько - нужно покрыть систему метриками (квантифицировать).
Например, поддерживаемость можно посчитать по скорости внесения изменений (без ущерба другим атрибутам), по наличию тестов, документации, количеству зависимостей и когнитивной сложности алгоритмов.
Да, может. Значит при внесении изменений в систему не учитывались эти атрибуты качества.
То есть получается, что любая метрика это величина (если нормируем) от 0 до 1. При значении, равном нулю, атрибут качества крайне плох (например, вообще немасштабируемая система). Выходит, что эмерджентности здесь не возникло?
Пардон, я допытываюсь, т.к. заинтересовала мысль про то, что атрибуты качества это и есть эмерджентные свойства. Хотелось понять, почему Вы их считаете таковыми. Понимаю, вопрос сложный, и трудно сказать, где та грань разделения на подсистемы и конечные элементы, при достижении которых эти свойства не будут проявляться.
Вы, похоже, воспринимаете эмержентность как нечто обязательно хорошее. Нет. Части системы по отдельности могут быть очень масштабируемы, но если связать эти части, может получиться немасштабируемо потому что появится узкое место.
В этом случае немасштабируемость - эмержентное свойство системы.
Эмержентность это "Look and feel" работающей системы в целом. И восприятие пользователя тоже становится частью системы.
А архитектурные атрибуты качества - это эмержентные свойства, на которые опирается человек, исполняющий роль архитектора.
Почему IDEF0, а не Archimate?
IDEF0 прост и понятен. Состоит из 5-ти базовых элементов и одного опционального (вызов внешнего ресурса). Его можно дорисовывать под себя - добавлять важные детали - время прохождения процесса, например, как на рисунке от руки в статье.
Archimate я, банально, не осилил. Мне кажется, это спецификация ради создания курсов по обучению этой спецификации.
Олег, спасибо за статью. Кажется, что системное мышление, это довольно редкая компетенция у специалистов в продуктовых командах, что в ходе работы может прмвести к, так скажем, недопониманию внутри команды. Вопрос - как решаете эту проблему (если она, конечно, имеет место) - у вас безоговорочный авторитет или пользуетесь чем-то особенным для представления проблем и их решений с т.з. системного мышления, чтобы команда их поняла и приняла?
Авторитета у меня нет и никогда не было. Был институт репутации, но я его упразднил.
А команде важно донести какую ключевую проблему мы решаем. С "как понял"-приёмом.
PS: у нас это называется принести "фактуру". Показать (не рассказать) что проблема есть с помощью метрик, логов, показаний свидетелей. Очень похоже на работу следователя.
Здравствуйте Олег. Прочитал внимательно вашу интересную заметку, особенно ваш черновой вариант(написан от руки и в самолёте).
=
Меня интересуют несколько моментов: Начну по порядку. 1.Бывает возникает у вас мысль (insight) в голове(спонтанная) и её необходимо перенести. Как вы поступаете? Вы её отражаете на бумаге, а потом переносите в Приложение для Анализа? 2. Некоторые термины немного сложны для меня, по - этому тяжело уловить "целостность картины". Но это в основном везде бывает, особенно в IT и это не упрёк, а просто некоторая закономерность, что человек системного склада ума. Возникает мысль, как с таким огромным багажом знаний IT специалисты "разгружают" свой мозг. В таких случаях не исключены эмоциональные выгорания. Отдых особенно важен. Особенно когда ты в команде и действуешь как единое целое что-бы быть в общем "потоке". Возможно есть какие-нибудь техники(Медитация и т.д) ?Буду благодарен если поделитесь своим опытом.
С уважением Михаил.
1.Бывает возникает у вас мысль (insight) в голове(спонтанная) и её необходимо перенести. Как вы поступаете?
зависит от ситуации. сейчас, например, мысль - а почему форматирование слетело?
Вы её отражаете на бумаге, а потом переносите в Приложение для Анализа?
зависит от мысли. весь поток сознания отражать на дорогостоящих материальных носителях, а потом - читать - дорого. сознание это погода...
2. Некоторые термины немного сложны для меня, по - этому тяжело уловить "целостность картины". Но это в основном везде бывает, особенно в IT и это не упрёк, а просто некоторая закономерность, что человек системного склада ума.
в поисках попыток упаковать сложные смыслы в простые фразы, бывает, надеешься на интерес читающего.
Возникает мысль, как с таким огромным багажом знаний IT специалисты "разгружают" свой мозг. В таких случаях не исключены эмоциональные выгорания. Отдых особенно важен. Особенно когда ты в команде и действуешь как единое целое что-бы быть в общем "потоке". Возможно есть какие-нибудь техники(Медитация и т.д) ?Буду благодарен если поделитесь своим опытом.
я пишу статью о том, как быть внимательным в эпоху тотального клипового мышления на базе трудов Джо Кабат-Зина (а мой психотерапевт - диссертацию на эту тему). Жаль будет, если получится много букв.
Спасибо за публикацию и за материалы! Здорово дополнил учебный план. Интересно было узнать про IDEF0, выглядит относительно просто и эффективно. С первой иллюстрации в разделе про эмерджентные свойства смеялся.
Спасибо за статью, но, если честно, ничего не понял, что сделано. У меня гораздо ниже квалификация, поэтому искренне пытался понять заложенные смыслы статьи.
Тяжело сформулировано "В процессе рассмотрения одного из вариантов решения...", из которого, после 3-го прочтения, вроде бы понял, что не будет перехода на монорепозиторий. Однако в "В итоге..." уже говорится про монорепозиторий.
"В итоге..." напомнило "делай хорошо, не делай плохо", но что конкретно сделано?:
1) доработали Bitbucket в чём?
2) доп. ресурсы какие и для чего?
3) метрики чего и какие?
4) а если бы разработали не особый "ноу-хау", то что? В чём "ноу-хау" состоит, в чём его (неизвестного никому из непосвящённых) особенность? Какие особенности проектов здесь играют роль?
Иначе всю статью можно было бы уместить в 3 предложения: У нас проблемы (большой список). Мы придумали особый ноу-хау. Мы довольны, все свободны.
5) внедрили Yarn 4 и CODEOWNERS для чего? Какие проблемы закрыли каждым из этих слов?
6) ужесточили релизный цикл по каким его характеристикам?
7) в чём заключается доработка производственного процесса?
8) в какой части, что конкретно улучшили в онбординге?
Ну, это "монорепозиторий". Ни lerna, ни nx в нём нет. Каждый артифакт так и продолжает жить сам по себе. Это просто тула, которая удобна только техлидам у которых по 20 реп в попечении.
Отвечу на ваши вопросы.
1) добавили в наш общий на весь банк инстанс с 500 проектами CODEOWNERS.
2) для нагрузки, вызванной внедрением CODEOWNERS
3) метрики эффективности метрик. долгая нудная тема.
4) особенность проектов, которую нужно было сохранить - независимые деплои. рекомендовать как окончательное решение я ничего не буду, особенности ландшафта
5) для удобной жизни с 50-100 репозиториями и 70-ю командами
6) ужесточили значит привели в соответствие к текущему производственному процессу
7) в начале движений по его доработке - планированию его доработки и его доработке
8) мы его описали и автоматизируем
Системное мышление на практике: переход от монолита к микрофронтендам и обратно