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

Software Construction/Design/Architecture - это довольно обширная область знаний, на глубокое изучение которой может и жизни не хватить. Но нужна ли глубина везде и во всем?

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

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

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

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

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

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

На этой неделе я посетил один из курсов от https://www.luxoft-training.ru/training/katalog_kursov/ именно по этой причине - мне нужно было в лимитированные ресурсы времени получить необходимый кругозор знаний по вопросам, которые для меня в настоящий момент не являются приоритетными, но с которыми мне тоже приходится работать (речь идет о методиках документирования архитектуры), вскрыть пробелы, систематизировать и подвергнуть ревизии свои знания.

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

Можно выделить следующие направления:
- https://www.luxoft-training.ru/training/katalog_kursov/arkhitektura-po/
- https://www.luxoft-training.ru/training/katalog_kursov/upravlencheskaya_effektivnost_i_kommunikatsii/
- https://www.luxoft-training.ru/training/katalog_kursov/lichnaya_effektivnost/
- https://www.luxoft-training.ru/training/katalog_kursov/testirovanie/
- https://www.luxoft-training.ru/training/katalog_kursov/sistemnyy-analiz/
- https://www.luxoft-training.ru/training/katalog_kursov/biznes-analiz/
- https://www.luxoft-training.ru/training/katalog_kursov/upravlenie_proektami_razrabotki_po/

Пост отражает мое мнение и не является рекламой.

Если вы ищите курсы, то я бы советовал еще присмотреться к курсам @vkhorikov (на мой взгляд, у него лучшие русскоязычные курсы по DDD и тестированию):
- https://www.pluralsight.com/authors/vladimir-khorikov
- https://it.eductera.com/experts/expert/52/

P.S.: посещение курсов и конференций у нас в компании оплачивается, засчитывается в рабочее время, и даже является обязательным. Так что, если вы в поиске более лучших условий для своего профессионального роста как разработчик (и есть желание делать это на Golang), то можете обратиться ко мне в приват - окажу содействие нашему HR.

#Career #SoftwareDesign #SoftwareArchitecture

Та самая книга, которую никто не читал, но которую все знают 🙂))
#Юмор

"The Architect’s Path (Part 2 - Implementation)" by Gregor Hohpe
https://architectelevator.com/architecture/architect-bookshelf/

#SoftwareArchitecture #Career

"C# 9 Records as DDD Value Objects" by Vladimir Khorikov
https://enterprisecraftsmanship.com/posts/csharp-records-value-objects/

#DDD

Две превосходные статьи про Культ Карго в программировании:
1. "Культ карго в программировании", Сергей Тепляков
http://sergeyteplyakov.blogspot.com/2013/09/blog-post_24.html
2. "Cargo Cult Software Engineering" by Steve McConnell
https://stevemcconnell.com/articles/cargo-cult-software-engineering/

#Career #Agile #SoftwareDesign #SoftwareDevelopment

"Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined" by Nick Tune
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c

#DDD #Microservices

Еще один комментарий в сторону Uber, на этот раз - от Nick Tune:
"If DDD had clear definitions, maybe Uber wouldn't have created their own definitions."
https://ntcoding.medium.com/my-main-problems-are-c779a6d62da

#DDD #Microservices

📝 "Patterns are the antidote to the suck/rock dichotomy.

There's far too many isolated tweets dispensing architecture advice that ignores context/problem + solutions/benefits/drawbacks. 😢"
- Chris Richardson
https://twitter.com/crichardson/status/1331696743382097920?s=19

#Microservices #SoftwareDesign #SoftwareArchitecture

📝 "✨New educational materials!✨
Today I'm announcing two new, free resources I've written: an 8-lecture course on fundamentals of distributed systems, and a 30-page tutorial on elliptic curve cryptography. https://martin.kleppmann.com/2020/11/18/distributed-systems-and-elliptic-curves.html "
- Martin Kleppmann
https://twitter.com/martinkl/status/1329051710019543041?s=19

P.S.: Если кто не знает, Martin Kleppmann - один из лучших авторов по распределенным системам. Автор "Кабанчика".

The distributed systems course comprises about 7 hours of video and 87 pages of lecture notes. It covers the following topics:
1. Introduction: distributed systems, computer networks, and RPC
2. System models: network faults, crash and Byzantine faults, synchrony assumptions
3. Physical clocks, clock synchronisation, and causality
4. Logical time, broadcast protocols (reliable, FIFO, causal, total order)
5. Replication, quorum protocols, state machine replication
6. Consensus, details on the Raft consensus algorithm
7. Replica consistency, two-phase commit, linearizability, eventual consistency
8. Case studies: collaboration software, Google’s Spanner

#SoftwareDesign #DistributedSystems #SoftwareArchitecture

📝 "The distributed systems course covers many of the fundamental algorithms behind today's apps. It consists of 87 pages of detailed notes (including exercises) https://t.co/5PmH0ESwDh and 7 hours of lecture videos https://t.co/oXvqzaTwrX "
- Martin Kleppmann
https://twitter.com/martinkl/status/1329052185183854593?s=19

#SoftwareDesign #SoftwareArchitecture #DistributedSystems

Мотивирующее фото для тех, кто сетует на нехватку времени и не может прочитать ни одной книги за полгода. Это фото Сергея Теплякова: https://www.instagram.com/p/CGv38kHnotb/?igshid=1nrcey0v5xa75
Который не только прочитал, по моим оценкам, уже более пары сотен технических книг, но и даже успел написать одну книгу, а так же кучу архи-полезных статей у себя в блоге http://sergeyteplyakov.blogspot.com/
Работает он сейчас в Microsoft и живет в США.

Это фото подтверждает слова А.В.Суворова: "Дисциплина - мать победы". У человека или есть дисциплина, и тогда он успевает все, или ее нету, и тогда он не успевает ничего.

#Career

Alexey Zimarev добавил аргументов к посту Nick Tune:
- https://alexey-zimarev.medium.com/i-become-to-believe-that-the-dub-domain-and-bounded-context-and-domain-model-concepts-arent-that-3d75c3861f3c
- https://alexey-zimarev.medium.com/i-see-that-kenny-wrote-almost-exactly-the-same-as-i-did-in-the-previous-comment-19d28142d669
- https://alexey-zimarev.medium.com/indeed-the-relativity-of-core-vs-supportive-vs-generic-in-business-lines-is-often-overlooked-4e70156288c1?source=rss-e500a4698713------2

#DDD #Microservices

C4-Model & Event Storming with ArchiMate, см. "Figure 13: Event Storming Model" of "Agile Architecture Modeling Using the ArchiMate® Language"
- https://publications.opengroup.org/g20e
- https://nicea.nic.in/sites/default/files/Agile_Architecture_Modelling_Using_Archimate.pdf
- https://nicea.nic.in/download-files.php?nid=247

Модель (обратите внимание на то, что автором модели является сам Jean-Baptiste Sarrodie):
- https://community.opengroup.org/archimate-user-community/home/-/issues/8

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

Плагин к Archimatetool для коллективной разработки:

coArchi - a plug-in to share and collaborate on Archi models.
- https://github.com/archimatetool/archi-modelrepository-plugin

Описание плагина:
- https://www.archimatetool.com/plugins/#coArchi

Документация к плагину:
- https://github.com/archimatetool/archi-modelrepository-plugin/wiki

Пользовательская документация к Archimatetool:
- https://www.archimatetool.com/downloads/Archi%20User%20Guide.pdf

Archimatetool использует Grafico format файлов:
📝 "GRAFICO stands for "Git Friendly Archi File Collection" and is a way to persist an ArchiMate model in a bunch of XML files (one file per ArchiMate element or view)."
https://github.com/archi-contribs/archi-grafico-plugin/wiki/GRAFICO-explained

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

Кстати, в Archimate можно делать и C4 Model, сохранив единую модель для всех её представлений:
- https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/

Event Storming by PlantUML:
- https://github.com/tmorin/plantuml-libs/blob/master/dist/eventstorming/README.md

#EventStorming #DDD #Microservices #SoftwareArchitecture #ArchiMate

Этот парень знает, что пишет:
https://news.1rj.ru/str/yarosh_log/73

#Algorithms #Parsers

Еще немного на тему Operational Transform and CRDT.

В конце т.н. "Красной Книги" - "Implementing Domain-Driven Design", Vaughn Vernon рассматривает автоматическое слияние изменений агрегата (автоматический резольв конфликтов версий агрегата), что позволяет повысить конкурентность. См. главу "Appendix A Aggregates and Event Sourcing: A+ES :: Concurrency Control" и картинку "Figure A.11. Using Event conflict resolution on the Event Stream of an Aggregate".

Суть идеи в том, что хотя агрегат и был отредактирован одновременно двумя пользователями, но, используя Event Sourcing, можно слить изменения, если они не конфликтуют между собой (например, не изменяют значение одного и того же атрибута агрегата). Главное, чтобы это не нарушало инвариантов агрегата, которые на уровне слияния событий обеспечить редко когда возможно.

"Which Programming Languages Use the Least Electricity?" by David Cassel
https://thenewstack.io/which-programming-languages-use-the-least-electricity/

#SoftwareArchitecture

В продолжение темы - есть еще "Дивергентное мышление и конвергентное мышление"
https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B2%D0%B5%D1%80%D0%B3%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D0%B5_%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5

#Career #SoftwareDesign #SoftwareArchitecture

"Developer to Architect :: Training and resources for the journey from software developer to software architect"
by Mark Richards, Software Architect and Founder
https://www.developertoarchitect.com/lessons/

#SoftwareArchitecture

📝 "Motivation

Thirty years ago Yourdon and Constantine in Structured Design identified economics as the underlying driver of software design. Software should be designed to reduce its overall cost. The cost of software is divided into the initial cost and the cost of maintenance:

cost total = cost develop + cost maintain

Once the industry gained experience with software development, it was a big surprise to many that the cost of maintenance is much higher than the cost of initial development. (Projects with little or no maintenance should use a very different set of implementation patterns from those presented in the remainder of this book.)

Maintenance is expensive because understanding existing code is timeconsuming and error-prone. Making changes is generally easy when you know what needs changing. Learning what the current code does is the expensive part. Once the changes are made, they need to be tested and deployed.

cost maintain = cost understand + cost change + cost test + cost deploy

One strategy for reducing overall cost is to invest more in initial development in hope of reducing or eliminating the need for maintenance. Such efforts have generally failed to reduce overall costs. When code needs to change in unanticipated ways, no amount of forethought can perfectly prepare the code for change. The premature attempts to make the code general enough to meet future needs often interfere with the unanticipated changes that turn out to be necessary.

Substantially increasing the up-front investment in software runs counter to two important economic principles: the time value of money and the uncertainty of the future. Since a dollar today is worth more than a dollar tomorrow, in principle an implementation strategy should generally encourage deferring costs. Also, because of uncertainty an implementation strategy should generally take immediate benefits in preference over possible long-term benefits. While this may sound like a license to hack without regard for the future, the implementation patterns are focused on ways to gain immediate benefit while setting up clean code for ease of future development.

My strategy for reducing overall costs is to ask all programmers to address the cost of understanding code during the maintenance phase by focusing on communicating, programmer-to-programmer. The immediate benefits of clear code are fewer defects, easier sharing of code, and smoother development. Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts. When I began writing my first set of implementation patterns (The Smalltalk Best Practice Patterns, Prentice Hall 1996) I thought I was a proficient programmer. To encourage myself to focus on patterns, I refused to type a character of code unless I had first written down the pattern I was following. It was frustrating, like I was coding with my fingers glued together. For the first week every minute of coding was preceded by an hour of writing. The second week I found I had most of the basic patterns in place and most of the time I was following existing patterns. By the third week I was coding much faster than I had before, because I had carefully looked at my own style and I wasn’t nagged by doubts.

The implementation patterns that I wrote down were only partly my own invention. Most of my style was copied from earlier generations of programmers. They were the habits that resulted in code that was easier to read, understand, and modify, and by codifying them I was able to code more quickly and fluidly than I had before. I could prepare for the future and get today’s code done faster at the same time."

For the implementation patterns in this book I looked at existing code as well as my own habits for inspiration. I read and compared code from the JDK, from Eclipse, and from my experience of development. The resulting patterns are intended to be a coherent view of how to write code people can understand. Other points of view or sets of values would result in different patterns. For example, I sketch the implementation patterns for framework development in “Evolving Frameworks”. These are based on a different set of priorities and so vary from my basic implementation style.

The implementation patterns serve human as well as economic needs. Code is by people and for people. Programmers can use the implementation patterns to help satisfy human needs, like the need to take pride in work well done or the need to be a trustworthy member of a community. I discuss the human and economic impact of the patterns as we go in the following chapters."
- "Implementation Patterns" by Kent Beck

#SoftwareDesign