В том же треде:

📝 "All architecture is design, but not all design is architecture.
Architecture represents the set of significant design decisions that shape the form and the function of a system, where significant is measured by cost of change."
- Grady Booch
https://twitter.com/Grady_Booch/status/1301810380675588096?s=19

#SoftwareDesign #SoftwareArchitecture

Там же:

📝 "You cannot reduce the complexity of a software-intensive systems; the best you can do is manage it."
- Grady Booch
https://twitter.com/Grady_Booch/status/1301810363734736896?s=19

#SoftwareDesign #SoftwareArchitecture

Гы... недавно был холиварчик в архитекторской группе на эту тему. Там же:

📝 "A software architect who does not code is like a cook who does not eat."
- Grady Booch
https://twitter.com/Grady_Booch/status/1301810374598033408?s=19

#SoftwareDesign #SftwareArchitecture

📝 "An honest estimate is not a date. It is always a range of dates with probabilities assigned to the range."
- Robert C. Martin
https://twitter.com/unclebobmartin/status/1302600840138485760?s=19

#Agile

Знаете этого парня, да?
- https://leanpub.com/u/johnbywater
А его книгу?
- https://leanpub.com/dddwithpython

#DDD #DistributedSystems #EIP #EDA #Microservices

Две превосходные статьи о том, как устроено сжатие данных в time-series расширении TimescaleDB для PostreSQL.

- https://blog.timescale.com/blog/time-series-compression-algorithms-explained/
- https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/

#Database #PosgreSQL #HighLoad #Scaling

Интересное видео от сообщества @drypython

#FunctionalProgramming

Немного дискуссионный, но весьма интересный материал от Vladimir Khorikov ( @vkhorikov ) на один из самых частых вопросов в DDD - может ли один агрегат иметь ассоциацию по ссылке с другим агрегатом?

"Link to an aggregate: reference or Id?"
https://enterprisecraftsmanship.com/posts/link-to-an-aggregate-reference-or-id/

#DDD #Microservices

Знатный холиварчик титанов получился на тему FP vs OOP. Не без интересных исторических подробностей.
https://twitter.com/Grady_Booch/status/1302678071049216000?s=19

#FunctionalProgramming #OOP

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

Пути решения проблемы здесь есть два:

1. Обретать знания. Страх - всегда от незнания.
2. Воспитывать в себе храбрость. Это может показаться неуместным, но именно об этом говорит Кент Бек:

#Agile #Career

📝 "Храбрость

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

Я расскажу вам о том, как храбрость срабатывает в реальной жизни. В середине восьмой итерации включающего в себя 10 итераций рабочего графика (25 из 30 недель) первой версии первого крупного ХР-проекта команда обнаружила фундаментальную ошибку в архитектуре системы.

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

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

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

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

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

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

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

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

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

- "Extreme Programming Explained" 1st edition by Kent Beck

#Agile #Career

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

📝 "Courage

Courage is effective action in the face of fear. Some people have objected to using the word "courage", reserving it for what a patrolling soldier does when going through a darkened doorway. Without intending to diminish the kind of physical courage demonstrated by the soldier, it is certainly true that people involved in software development feel fear. It's how they handle their fear that dictates whether they are working as an effective part of a team.

Sometimes courage manifests as a bias to action. If you know what the problem is, do something about it. Sometimes courage manifests as patience. If you know there is a problem but you don't know what it is, it takes courage to wait for the real problem to emerge distinctly.
Courage as a primary value without counterbalancing values is dangerous. Doing something without regard for the consequences is not effective teamwork. Encourage teamwork by looking to the other values for guidance on what to do when afraid.

If courage alone is dangerous, in concert with the other values it is powerful. The courage to speak truths, pleasant or unpleasant, fosters communication and trust. The courage to discard failing solutions and seek new ones encourages simplicity. The courage to seek real, concrete answers creates feedback."

- "Extreme Programming Explained" 2nd edition by Kent Beck

#Agile #Career

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

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

Правда, исключить полностью "prudent-inadvertent technical debt" вряд ли удастся:

📝 "I hear this all the time from the best developers. The point is that while you're programming, you are learning. It's often the case that it can take a year of programming on a project before you understand what the best design approach should have been."
https://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html

#Agile #Career

Awesome EventStorming
https://github.com/mariuszgil/awesome-eventstorming

#DDD #Microservices #EventStorming

Опубликована третья статья мини-серии статьей про Agile and Architecture by Gregor Hohpe (автор EIP)
"Conversation stopper: IT Should Become Agile"
https://architectelevator.com/transformation/agile-conversation-stopper/

#Agile #SoftwareArchitecture

Неплохую статью упомянул Максим Смирнов:
"The Scale Cube" by Marty Abbott
https://akfpartners.com/growth-blog/scale-cube

#Database #HighLoad #Scaling

На вчерашней архитекторской тусовке ( @it_architect_party ) прозвучал вопрос: "что говорить разработчикам, злоупотребляющим микрооптимизациями"? И я вспомнил про подборку высказываний о premature optimization:

📝 "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason — including blind stupidity."
— W. A. Wulf

📝 "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
— Donald Knuth

📝 "Jackson's Rules of Optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet — that is, not until you have a perfectly clear and unoptimized solution."
— M. A. Jackson

📝 "No programmer has ever been able to predict or analyze where performance bottlenecks are without data. No matter where you think it's going, you will be surprised to discover that it is going somewhere else."
— Joseph M. Newcomer

📝 "If you make an optimization and don't measure to confirm the performance increase, all you know for certain is that you've made your code harder to read."
— Martin Fowler, "Yet Another Optimization Article" https://martinfowler.com/ieeeSoftware/yetOptimization.pdf

📝 "The interesting thing about performance is that if you analyze most programs, you find that they waste most of their time in a small fraction of the code. If you optimize all the code equally, you end up with 90 percent of the optimizations wasted, because you are optimizing code that isn't run much. The time spent making the program fast, the time lost because of lack of clarity, is all wasted time."
— "Refactoring: Improving the Design of Existing Code" 1st edition by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

📝 "The Pareto Principle, also known as the 80/20 rule, states that you can get 80 percent of the result with 20 percent of the effort. The principle applies to a lot of areas other than programming, but it definitely applies to program optimization. Barry Boehm reports that 20 percent of a program's routines consume 80 percent of its execution time (1987b). In his classic paper "An Empirical Study of Fortran Programs," Donald Knuth found that less than four percent of a program usually accounts formore than 50 percent of its run time (1971). Knuth used a line-count profiler to discover this surprising relationship, and the implications for optimization are clear. You should measure the code to find the hot spots and then put your resources into optimizing the few percent that are used the most. Knuth profiled his line-count program and found that it was spending half its execution time in two loops. He changed a few lines of code and doubled the speed of the profiler in less than an hour. Jon Bentley describes a case in which a 1000-line program spent 80 percent of its time in a five-line square-root routine. By tripling the speed of the square-root routine, he doubled the speed of the program (1988). The Pareto Principle is also the source of theadvice to write most of the code in an interpreted language like Python and then rewrite the hot spots in a faster compiled language like C.Bentley also reports the case of a team that discovered half an operating system's timebeing spent in a small loop. They rewrote the loop in microcode and made the loop 10 times faster, but it didn't change the system's performance — they had rewritten the system's idle loop! The team who designed the ALGOL language — the granddaddy of most modern languages and one of the most influential languages ever — received the following advice: "The best is the enemy of the good." Working toward perfection might prevent completion. Complete it first, and then perfect it. The part that needs to be perfect isusually small."
— "Code Complete" by Stive McConnell

#SoftwareDesign #SoftwareArchitecture #Career

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

"Все просто. Или ты читаешь, или проект гниёт. Чем больше читаешь, тем меньше он гниёт, тем больше velocity команды, тем больше времени на чтение. Вы не представляете, сколько я встречал на практике косяков, которые уже давно были разобраны в литературе. Или ты учишься на своих ошибках, или на чужих. Последний вариант банально выгодней."

#Career

В чате канала прозвучал очень хороший вопрос, на который лучше ответить здесь: "А как же вариант переусложнения как раз по причине "мы прочитали, надо так ..." ?"

В своей практике я не могу вспомнить такого случая. В нечитающих командах проблем всегда на порядок больше. Любое решение имеет свой контекст применения. Универсального решения не существует. Если решение не соответствует поставленной задачи, значит, читали не то или не о том. Т.е. не обладают теорией. Часто можно наблюдать ошибочное применение решений на основе разнообразных статей не самого высокого качества, в которых утрачен контекст применения (наглядный пример - бесчисленные на сегодня статьи о ТДД, в которых отсутствует даже элементарное понимание этой методики). Тут вопрос заключается просто в качестве источников информации - нужно просто быть избирательным и предпочитать работать с первоисточниками. По этому поводу красиво сказал Bertrand Meyer:

📝 "The zealots of an idea are often more extreme than its creators - the phase “more royalist than the King” captures that phenomenon - and you will find that foundational agile texts, such as those by Beck, Larman or Cockburn, occupy a higher plane of discourse; in particular they avoid below-the-belt hits at other approaches."
- “Agile!: The Good, the Hype and the Ugly” by Bertrand Meyer

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

Вторым, немаловажным моментом, является "Несовпадение фаз спиралей обучения"
- https://dckms.github.io/system-architecture/emacsway/soft-skills/learning-spiral-phase-mismatch.html

#Career