​​Биометрия шагает в массы

Официально опубликованы:

• Постановление Правительства Российской Федерации от 15.06.2022 № 1066 «О размещении физическими лицами своих биометрических персональных данных в единой информационной системе персональных данных, обеспечивающей обработку, включая сбор и хранение, биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица».

• Постановление Правительства Российской Федерации от 15.06.2022 № 1067 «О случаях и сроках использования биометрических персональных данных, размещенных физическими лицами в единой информационной системе персональных данных, обеспечивающей обработку, включая сбор и хранение, биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица».

Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #Microservices

Читал на днях книгу Alberto Brandolini "Leanpub: Introducing EventStorming", где он говорит о распространенной ловушке моделирования агрегатов, когда на него возлагают функции Read Model:

📝 "A shopping cart will include the list of the items to be purchased, with the associated quantity and price.

Bread and butter, apparently, except that we now should be asking ourselves whether we need to include the ItemDescription in the ItemInCart. Feels like we should, because we’ll need to display the ShoppingCart info to the customer, in order to review the cart before proceeding to checkout “is this really the stuff you intended to buy? Have you looked at the grand total?”. Things might get awkward when starting to consider events like ItemPriceUpdated or ItemDescriptionUpdated, that should have us thinking whether we should include a copy of the entire description of the selected item, or just a reference to the Item in stock.

Hmmm… not. Sorry for the detour, but these are not the aggregates we’re looking for. “data to be displayed to a user in order to make a decision” will be a Read Model. Aggregates are something else, but we have to be aware of this vicious temptation of superimposing what we need to see on the screen on the internal structure of our model."
-- "Leanpub: Introducing EventStorming" by Alberto Brandolini

#DDD #Microservices

Две статьи о том, что проблема гонки сообщений в шине может решаться на уровне бизнес-логики. Одна из них - от Vaughn Vernon. Он даже видит в этом превосходство DDD.

1. "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts
2. "Nobody Needs Reliable Messaging" by Marc de Graauw

#DDD #Microservices #DistributedSystems

⚡️Перечень ключевых органов и организаций, которым необходимо оценить уровень защищённости своих ИС

Официально опубликовано распоряжение Правительства Российской Федерации от 22.06.2022 № 1661-р, утвердившее Перечень ключевых органов (организаций), которым необходимо осуществить мероприятия по оценке уровня защищенности своих информационных систем с привлечением организаций, имеющих соответствующие лицензии ФСБ России и ФСТЭК России.

Более подробно о зонах ответственности по исполнению Указа Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации» можно узнать здесь.

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

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

Достоверно известно, что эта проблема ведет к падению velocity со скоростью, близкой к геометрической прогрессии, а значит, к стремительному падению рентабельности и конкурентоспособности проекта. Разве является это чей-то целью? Но если это не является ничьей целью, то почему эта проблема все еще существует и прогрессирует?

Причины здесь три:

1. Как говорил Кент Бек: "Краткосрочные индивидуальные цели часто конфликтуют с долгосрочными социальными целями. Общество решает эту проблему при помощи набора ценностей, подкрепленных мифами, ритуалами, наказаниями и наградами. Без уважения к этим ценностям люди забывают о социальных нуждах и стремятся реализовать свой собственный индивидуальный краткосрочный интерес."
-- "Extreme Programming Explained" 1st edition by Kent Beck, "Chapter 7. Four Values", перевод ООО Издательство "Питер"

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

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

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

3. Как ни банально это звучит, но имеет место элементарная нехватка как управленческой, так и технической грамотности, преодолению которой зачастую препятствует "Эффект Даннинга-Крюгера".

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

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

Именно на этих принципах и должно основываться объединение, созданное для решения проблем отрасли.

Как же можно решить проблему? Для её решения требуется изменить сложившиеся стереотипы и изменить общественное мнение. А для этого нужно привлечь массовое внимание к самой проблеме и способам её решения. К счастью, о решении этой проблемы было много написано, но, к сожалению, мало кем читано.

А для того, чтобы обладать потенциалом, достаточным для привлечения массового внимания, нужно консолидировать усилия лидеров общественного мнения, что и является задачей такого объединения. Почему, например, о "Неделе высокой моды" в Москве слышали многие, а о "Неделе качественного кода" не слышал никто? Разве с модой у нас дела обстоят хуже, чем с ежедневным количеством WTF на работе?

Мы решили эту ситуацию исправить и начать цикл тематических месячников с целью концентрации внимания общественности на конкретных проблемах и способах их решения.

#Goal

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

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

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

#Trend

С чего начинается качественный код? Как говорил профессор Преображенский, разруха начинается с головы. И он был прав. Вернее, с «Закона Миллера»:

💬 «Магическое число семь плюс-минус два» («кошелёк Миллера», «закон Миллера») — закономерность, обнаруженная американским учёным-психологом Джорджем Миллером, согласно которой кратковременная человеческая память, как правило, не может запомнить и повторить более 7 ± 2 элементов.

Конечно, всегда найдутся желающие поспорить с Миллером, но только не Dijkstra:

💬 "The competent programmer is fully aware of the strictly limited size of his own skull; therefore, he approaches the programming task in full humility"
("хороший специалист всегда осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам с максимальной скромностью.")
—Edsger W. Dijkstra, 1972

И авторы KISS Principle с ним охотно согласились бы:

💬 "Be Humble, don't think of yourself as a super genius, this is your first mistake. By being humble, you will eventually achieve super genius status =), and even if you don't, who cares! your code is stupid simple, so you don't have to be a genius to work with it."
("Будьте скромны, не считайте себя супергением — это ваша первая ошибка. Оставаясь скромным, вы в конечном итоге достигнете уровня супергения, и даже если нет, какая разница. Ваш код должен быть прост настолько, что вам не нужно быть гением, чтобы работать с ним.")
—"KISS principle"

В принципе, «Закона Миллера» предопределяет потребность не только в качественном коде, но и в ставшей популярной в наши дни Team First Architecture.

#SoftwareDesign

Chat Digest

💬 Огненное видео от Майкла Нигорда:
- https://t.me/ru_arc_chat/1072

💬 Ряд мега-полезных файлов по архитектурной таксономии:
- https://t.me/ru_arc_chat/1062

💬 Атрибуты качества и их влияние на выбор архитектурного подхода к ядру системы:
- https://t.me/ru_arc_chat/998

💬 Architecture Characteristics Worksheet:
- https://t.me/ru_arc_chat/1005

💬 Матрица решений по выбору типа базы данных:
- https://t.me/ru_arc_chat/1052

💬 Архитектура = структуры + текстуры. Качество кода - это одна из текстур:
https://t.me/ru_arc_chat/972

💬 Про асинхронные и синхронные стили коммуникации:
- https://t.me/ru_arc_chat/956
- https://t.me/ru_arc_chat/935
- https://t.me/ru_arc_chat/896

💬 Чем отличается простой микросервис от BC?
https://t.me/ru_arc_chat/832

💬 Стратегические паттерны DDD:
- https://t.me/ru_arc_chat/813
- https://t.me/ru_arc_chat/821

💬 Чем отличается Бизнес-процесс от Workflow?
- https://t.me/ru_arc_chat/757

💬 Как легче всего думать о Бизнес-логике?
- https://t.me/ru_arc_chat/737

💬 С чего начинается EventStorming?
- https://t.me/ru_arc_chat/734

💬 Есть ли альтернатива для синхронных доменных событий в FP?
- https://t.me/ru_arc_chat/710

💬 Microservices and the First Law of Distributed Objects:
- https://t.me/ru_arc_chat/701

💬 Distributed transaction patterns for microservices compared:
- https://t.me/ru_arc_chat/691

💬 Ищут ли люди в споре истину?
- https://t.me/ru_arc_chat/651

💬 Какую проблему решают агрегаты и почему они возникли?
- https://t.me/ru_arc_chat/646

💬 Помогает ли EventStorming предотвратить ошибки при моделировании агрегатов?
- https://t.me/ru_arc_chat/636

💬 Если человек прав, то почему к нему не всегда прислушиваются?
- https://t.me/ru_arc_chat/628

💬 Какая роль микросервисов в топологии команд?
- https://t.me/ru_arc_chat/466

💬 Откуда легче всего начинать искать терминологию по Software Engineering:
- https://t.me/ru_arc_chat/441

💬 Как разрабатываются стандарты?
- https://t.me/ru_arc_chat/412

💬 Чем отличаются Architecture, Design и Implementation?
- https://t.me/ru_arc_chat/361

💬 Считает ли Robert C. Martin микросервисы архитектурой и все ли с ним согласны?
- https://t.me/ru_arc_chat/352

💬 О собеседованиях по System Design:
- https://t.me/ru_arc_chat/329

💬 Что не так с названием SRP, и почему он зачастую работает наоборот?
- https://t.me/ru_arc_chat/312

💬 Не могу заплатить за книгу. Что делать?
- https://t.me/ru_arc_chat/295

💬 Архитектурная ката победителей O'Reilly:
- https://t.me/ru_arc_chat/273

💬 О метамоделях:
- https://t.me/ru_arc_chat/270

💬 Что читать по DDD?
- https://t.me/ru_arc_chat/268

💬 Каталоги и матрицы устарели и не соответствуют вызовам времени. Что применить взамен?
- https://t.me/ru_arc_chat/250

💬 Метамодель GoF:
- https://t.me/ru_arc_chat/246

💬 Шаблоны стабильности от Майкла Нигорда:
- https://t.me/ru_arc_chat/241

💬 Читать ли синюю книгу от Эванса? Не устарела ли она?
- https://t.me/ru_arc_chat/235

💬 Мега-статья о жертвенной архитектуре:
- https://t.me/ru_arc_chat/161

💬 Почему не все проекты успешны?
- https://t.me/ru_arc_chat/160

💬 Эффект новизны Хотторна от изучения новых технологий:
- https://t.me/ru_arc_chat/159

#ChatDigest

👀 Новое видео на канале!
Топ жести на собеседовании: https://youtu.be/KdmYL8TJEIA

Что делают большинство разработчиков, когда им нужно провести собеседование? Правильно, гуглят 100 вопросов на собеседование на ${любимый_язык}. А потом мы все жалуемся, что на собеседованиях творится какая-то вакханалия.

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

🙏 Не забудьте поставить лайк и подписаться на YouTube канал, если видео вам понравилось!

Проще всего пояснить "Закон магического числа 7 ± 2" этой картинкой☝️(кликните для увеличения). Как говорится, лучше один раз увидеть. Такой же процесс происходит, когда уровень сложности рассматриваемого фрагмента кода превышает возможности краткосрочной памяти человека.

Просто ваши глаза не могут увидеть все 12 точек одновременно. Ninio's extinction illusion. Twelve black dots cannot be seen at once. Ninio, J. and Stevens, K. A. (2000) Variations on the Hermann grid: an extinction illusion. Perception, 29, 1209-1217.

#SoftwareDesign

Какую же задачу решает качественный код?

💬 "Nothing kills speed more effectively than poor internal quality."
—"Planning Extreme Programming" by Kent Beck, Martin Fowler

💬 "... the activity of design is not an option. It must be given serious thought for software development to be effective."
—"Extreme Programming Explained" by Kent Beck

💬 "The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin

💬 "In most contexts higher quality ⇒ expensive. But high internal quality of software allows us to develop features faster and cheaper."
—"Tradable Quality Hypothesis" by Martin Fowler

💬 "The value of good software design is economic: you can continue to add new functionality quickly even as the code-base grows in size."
—"Design Stamina Hypothesis" by Martin Fowler

💬 "The fundamental role of internal quality is that it lowers the cost of future change. But there is some extra effort required to write good software, which does impose some cost in the short term."
—"Is High Quality Software Worth the Cost?" by Martin Fowler

💬 "The whole point of good design and clean code is to make you go faster - if it didn't people like Uncle Bob, Kent Beck, and Ward Cunningham wouldn't be spending time talking about it."
—"Technical Debt Quadrant" by Martin Fowler

💬 "If you're a manager or customer how can you tell if the software is well designed? It matters to you because poorly designed software will be more expensive to modify in the future."
—"Is Design Dead?" by Martin Fowler

Сама по себе скорость разработки - это еще не цель. Это только задача в достижении цели.

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

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

#SoftwareDesign

О том же самом от редкого Мастера слова - Kent Beck:

📝 "Сделайте изменение легким, а потом делай легко изменение.

Make the change easy then make the easy change."

—Kent Beck, "Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020"

#SoftwareDesign

Сегодня Big Design Up Front (BDUF) даже в проектах средней величины практически не применяется. Обрабатывать неопределенность заблаговременно (Prediction), путем логического вывода - это очень дорогая задача, стоимость которой может достигать экспоненциального роста по мере повышения точности прогнозирования (по крайней мере, по утверждению Robert C. Martin). В то время как бизнес-выгоды от этой точности возрастают куда скромнее, вплоть до логарифмического характера. Иными словами, нельзя повышать точность прогноза до бесконечности - у него есть предел экономической целесообразности.

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

💬 "To deal with the issues of incompletely known requirements and inaccurate estimates, a number of other types of models have been proposed: incremental, spiral, iterative, and evolutionary (adaptive)."
—"ISO/IEC/IEEE 12207:2017 Systems and software engineering - Software life cycle processes"

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

💬 "Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements...

I would go a step further and assert that it is really impossible for clients, even those working with software engineers, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.

Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements."
—"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.