Это нужно выделить отдельно. Более простого объяснения более важных вещей в IT-индустрии я пока еще не встречал:

📝 "These were elucidated in the mid-70s by Yourdon & Constantine in "Structured Design" https://amzn.to/2GsuXvQ and haven’t changed.

Their argument goes like this:

1. We design software to reduce its cost.

2. The cost of software is ≈ the cost of changing the software.

3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).

4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…

5. Coupling between elements of a design is this propensity for a change to propagate.

6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.

(This skips loads of interesting stuff, but I’m just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"

- "Monolith -> Services: Theory & Practice" by Kent Beck
https://medium.com/@kentbeck_7670/monolith-services-theory-practice-617e4546a879

Еще одна хорошая "шпаргалка"
Open Agile Architecture : 19. Event Storming
- https://pubs.opengroup.org/architecture/o-aa-standard/#event-storming-workshop

#DDD #EventStorming

Просто превосходный краткий материал по проектированию микросервисов:
"Building microservices on Azure"
- https://docs.microsoft.com/en-us/azure/architecture/microservices/

Особенно это:
- "Using domain analysis to model microservices" https://docs.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
и это:
- "Identifying microservice boundaries" https://docs.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries

#DDD #Microservices

Свеженькая статья на острую тему - " Are We Really Bad at Estimating?" by Mike Cohn:
- https://www.mountaingoatsoftware.com/blog/are-we-really-bad-at-estimating

Там есть ссылка на вот такой любопытный файлик (содержание которого уже не ново, но дает еще один угол зрения) - "Uncertainty Intervals versus Interval Uncertainty: An Alternative Method for Eliciting Effort Prediction Intervalsin Software Development Projects" by Jørgensen, M., Simula Research Laboratory:
- https://www.simula.no/sites/default/files/publications/files/promac-final2.pdf

#Agile

I have just released an article about Higher Kinded Types in Python! https://sobolevn.me/2020/10/higher-kinded-types-in-python

If you want to help our project, please share it 🙂

Уже не ново, но не теряет актуальности: https://www.youtube.com/watch?v=UoKlKx-3FcA
Самое интересное на 4:40 про геометрю...

#Юмор

Кому надо улучшать Английский с нативными спикерами - лекции MIT
- https://ocw.mit.edu/courses/audio-video-courses/

Стэнфордский университет, лекции Д. Кнута:
- https://www.youtube.com/playlist?list=PL94E35692EB9D36F3
и
- https://www.youtube.com/playlist?list=PLoROMvodv4rM2uc1Cg9oTblVaF-EEOlw-

Data Science, лекции Стэнфорда:
- https://www.youtube.com/playlist?list=PLoROMvodv4rO5jY6RA1eFVcLVY2kJU_EL

Блокчейны, лекции Стэнфорда:
- https://www.youtube.com/playlist?list=PLoROMvodv4rNYmdiYxWRVpxLj75R7oZ65

Другие лекции Стэнфорда:
- https://www.youtube.com/user/stanfordonline

#Algorithms

Превосходный материал по управленческим вопросам от 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