Превосходный материал по управленческим вопросам от Craig Larman:

Перевод:
https://less.works/ru/less/principles/systems-thinking.html

Оригинал:
https://less.works/less/principles/systems-thinking.html

#Agile #Career

https://github.com/microsoft/TypeScript/pull/40368

HKTs and TS

Функциональное программирование на TypeScript: полиморфизм родов высших порядков

https://m.habr.com/ru/post/526024/

#FunctionalProgramming

⚡ "Domain model purity and lazy loading" by Vladimir Khorikov ( @vkhorikov )
https://enterprisecraftsmanship.com/posts/domain-model-purity-lazy-loading/

Критически важная статья❗ Я ждал ее публикации.

#DDD #Microservices

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

#Career

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

📝 "Refactoring is a kind of reorganization. Technically, it comes from mathematics when you factor an expression into an equivalence - the factors are cleaner ways of expressing the same statement.

Refactoring implies equivalence; the beginning and end products must be functionally identical. You can view refactoring as a special case of reworking (see WhatIsReworking).
Practically, refactoring means making code clearer and cleaner and simpler and elegant. Or, in other words, clean up after yourself when you code. Examples would run the range from renaming a variable to introducing a method into a third-party class that you don’t have source for.

Refactoring is not rewriting, although many people think they are the same. There are many good reasons to distinguish them, such as regression test requirements and knowledge of system functionality. The technical difference between the two is that refactoring, as stated above, doesn’t change the functionality (or information content) of the system whereas rewriting does. Rewriting is reworking. See WhatIsReworking.

Refactoring is a good thing because complex expressions are typically built from simpler, more grokable components. Refactoring either exposes those simpler components or reduces them to the more efficient complex expression (depending on which way you are going).

For an example of efficiency, count the terms and operators: (x - 1) * (x + 1) = x^2 - 1. Four terms versus three. Three operators versus two. However, the left hand side expression is (arguably) simpler to understand because it uses simpler operations. Also, it provides you more information about the structure of the function f(x) = x^2 - 1, like the roots are +/- 1, that would be difficult to determine just by “looking” at the right hand side."
- “What Is Refactoring” on c2.com
http://wiki.c2.com/?WhatIsRefactoring

#SoftwareDesign #Agile #Refactoring

📝 "The obvious answer comes from the notion of factoring in mathematics. You can take an expressions such as x^2 + 5x + 6 and factor it into (x+2)(x+3). By factoring it you can make a number of mathematical operations much easier. Obviously this is much the same as representing 18 as 2*3^2. I’ve certainly often heard of people talking about a program as well factored once it’s broken out into similarly logical chunks."
- “Etymology Of Refactoring” by Martin Fowler
https://martinfowler.com/bliki/EtymologyOfRefactoring.html

#SoftwareDesign #Agile #Refactoring

📝 "Decomposition in computer science, also known as factoring, is breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain."
- “Decomposition”, Wikipedia
https://en.wikipedia.org/wiki/Decomposition_(computer_science)

#SoftwareDesign #Agile #Refactoring

Довольно ценные советы по проведению EventStorming в удаленном режиме от его создателя:

- "Remote EventStorming" by Alberto Brandolini
https://blog.avanscoperta.it/2020/03/26/remote-eventstorming/

- "EventStorming in COVID-19 times" by Alberto Brandolini
https://blog.avanscoperta.it/2020/03/26/eventstorming-in-covid-19-times/

P.S.: обновил свой список литературы по этому вопросу:
https://emacsway.github.io/ru/self-learning-for-software-engineer/#event-storming

#DDD #EventStorming

Новая статья от разработчиков Watermill
"Combining DDD, CQRS, and Clean Architecture by refactoring a Go project"
https://threedots.tech/post/ddd-cqrs-clean-architecture-combined/

#DDD #Microservices #Golang

"Using Event Sourcing and CQRS with Incident - Part 1" for Elixir-developers
https://pedroassumpcao.ghost.io/event-sourcing-and-cqrs-using-incident-part-1/

P.S.: не читал, не могу прокомментировать. Но, думаю, что у функциональщиков она вызовет интерес.

[UPDATE]: тут ребята-функциональщики еще обращали внимание на https://github.com/commanded/commanded

#DDD #FunctionalProgramming

Список литературы от Kamil Grzybek:
http://www.kamilgrzybek.com/programming-and-design-resources/

#DDD #Microservices #SoftwareDesign #SoftwareArchitecture #Career

Проанализируем популярную на этой неделе картинку.

1. С ходу бросается в глаза противоречие между "авторитарный Product Owner" и "каждый принимает участие в принятии решений". На деле в Agile экономика разработки критически зависит от достижения баланса бизнес и технических интересов https://news.1rj.ru/str/emacsway_log/124

2. Не совсем понятно, что именно автор противопоставляет Agile. Вероятней всего - BDUF.

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

В то время как капиталистические рыночные экономики хорошо знакомы с таким кризисным явлением, как "перепроизводство", - которое является следствием недостаточности заблаговременного планирования и координирования.

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

#Agile

3. Является ли Agile идеологией и религией?

На самом деле, трудно сделать экономику исключительно плановой, как и трудно достигнуть в чистом виде Top-Down или Bottom-Up проектирование. Обычно имеет место некий баланс с преобладанием одного или другого аспекта. И при Сталине была кооперация, и был даже период НЭП.

Методики разработки тоже имеют разное соотношение заблаговременного проектирования (прогнозирования) и адаптации.

В BDUF доля заблаговременного проектирования составляет 100%.

В RUP (спиральная методика) уже присутствует адаптация, но доля заблаговременного проектирования все еще велика.

В Agile (итеративная методика) доля заблаговременного проектирования минимальна.

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

Т.е. в каждом конкретном проекте выбирается сбалансированное соотношение заблаговременного проектирования и адаптации в пределах их экономической целесообразности. Len Bass, Grady Booch и Craig Larman хорошо раскрывают эту тему.

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

Серебряной пули нет. Любая методика выбирается исходя из контекста её применимости и экономической целесообразности. А значит, выбор методики не может быть вопросом веры.

#Agile

4. "Маленькие команды продуктивней больших" - это, на самом деле, Закон Брукса, и Agile тогда еще не было.

#Agile

5. "Работа разделена на спринты" - действительно ли работа (т.е. реализация), а не решения?

Итерация - это математический термин, which means applying function to itself. Каждая итерация на вход принимает результат работы предыдущей итерации. Это позволяет принимать решения на основе практического фидбэка предыдущих итераций с целью обработки неопределенности в тех случаях, когда осуществить прогноз трудно или дорого (дороже, чем реализовать итерацию).

Таким образом, итерация необходима для принятия решений в условиях недостаточной информированности, а не для разделения работ по реализации.

#Agile

6. На английском Murcs != Marx. Если перевести Scrum на Русский, то опять не совпадает.

#Agile