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

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

#SoftwareDesign

> "Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано."

Здесь есть два важных момента, но рассмотрим мы только технический.

По всей видимости, речь идет о книге "Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Эта книга хорошо раскрывает основы экономики разработки. На эту тему у меня была серия постов, начиная отсюда https://news.1rj.ru/str/emacsway_log/119 (можно еще поискать в канале по термину "YAGNI"). Эта книга, как раз, учит не экономически необоснованному перфекционизму, а наоборот, достижению наилучшей экономики разработки в балансе краткосрочных и долгосрочных интересов. И Code Smell "Switch Statement" прямо гласит о том, что он требует исправления только тогда, когда он приводит к разлету дроби. В другом месте книги говорится о правиле трех ударов, и два дубликата - еще не повод для рефакторинга, но уже на грани.

#SoftwareDesign

Ключевой критерий качества кода - это темпы разработки, т.е. стоимость изменения кода. Это необходимое условие для Agile-разработки. На эту тему был пост: https://news.1rj.ru/str/emacsway_log/151

Все правила должны быть нацелены на достижение этой цели. Если возникают разногласия, то я рекомендовал бы обращаться к общепризнанным каталогам Code Smells. Доказано практикой - конфликты исчезают.

А про Code Style - очень хорошо у Steve McConnell в "Code Complete". Он дает понимание того, что и как оформлять в коде, что исключает догматичное следование правилам. Кстати, с некоторыми правилами, общепризнанными в Golang, я не согласен, и считаю, что слепо преклоняться не стоит. Например, я считаю, что функции-конструкторы обязаны содержать глагол, а не прилагательное.

#SoftwareDesign

> в любой команде есть какие-то законы, которые придуманы фиг пойми для чего

Вот это основная суть статьи. Это - самая главная проблема в разработке. И это касается не только правил, но и кода:

📝 "A six-month study conducted by IBM found that maintenance programmers “most often said that understanding the original programmer’s intent was the most difficult problem”" - Fjelstad and Hamlen

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

Классический пример - из-за неудачного названия микросервиса логика размазывается и дублируется. Из-за дубликатов и плохих названий становится непонятно, в каком именно микросервисе наращивать логику, куда "поселить" новый инкремент логики.

Но даже когда намерения автора понятны, должна быть возможность выполнить задачу в существующем коде, т.е. изменить код автора. Если код представлен лапшой, то придется изменять много кода, изменения будут лавинообразными. По этому поводу хорошо рассуждал Kent Beck: https://news.1rj.ru/str/emacsway_log/188

Чтобы код не был лапшой, нужно изолировать изменения. Поэтому, второе самое важное правило Software Design - это принцип "Low Coupling & High Cohesion" ( http://wiki.c2.com/?CouplingAndCohesion ), сформированный еще в 1974 году. Главное правило рыбака - не дать запутаться леске. Главное правило программиста - предотвратить Уроборос.

И, наконец, третье важное правило - чтобы что-то изменить, нужно понять, как оно работает сейчас. А для этого нужно иметь возможность рассмотреть фрагмент программы изолированно, чтобы сложность рассматриваемого фрагмента не превысила ограниченные возможности краткосрочной памяти человека.
https://ru.m.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0

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

> От навязанных необоснованных ограничений мы получаем выгорание.

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

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

#SoftwareDesign

> Раньше мне казалось, что начальство перегибает палку ради дисциплины в вакууме, и меня от этого бомбило.

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

Часто конфликтность подогревается дисфазностью "Спирали Обучения" оппонентов, об этом было в постах:
- https://news.1rj.ru/str/emacsway_log/48
- https://news.1rj.ru/str/emacsway_log/113

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

Да и изменяется качество самих правил - "орел мух не ловит", а "лев падалью не питается". Мелочь отбрасывается или полностью автоматизируется, а по-настоящему важные правила - подчеркиваются и усиливаются.

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

#SoftwareDesign

Конспект известной статьи V.Vernon о моделировании агрегатов:
https://m.habr.com/ru/post/543424/

(Источник)

#DDD

Статья С.Теплякова о Switch Statement:
"Что не так с оператором switch?"
- http://sergeyteplyakov.blogspot.com/2016/08/whats-wrong-with-switch-operator.html

#SoftwareDesign

К вопросу о паттернах проектирования:
"Шаблоны проектирования. История успеха"
- http://sergeyteplyakov.blogspot.com/2010/01/blog-post.html

#SoftwareDesign

Тут как раз Chris Richardson написал blog-post, затрагивающий проблему atomicity and resiliency of event publishing:
"Events on the outside, on the inside and at the core" by Chris Richardson
http://chrisrichardson.net/post/microservices/2021/02/21/events-are-the-core.html

Слайды заслуживают внимания. Также они демонстрируют сегодняшние тренды в микросервисной архитектуре, и какую роль в этом играет DDD.

#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign

Слайд 70 заслуживает отдельного поста. Варианты реализации OO/Functional Aggregates на примере Reference Applications by Chris Richardson:

Traditional OO mutable Domain Objects:
- https://github.com/cer/event-sourcing-examples/tree/master/java-spring

Functional Scala witn immutable Domain Objects:
- https://github.com/cer/event-sourcing-using-scala-typeclasses

Hybrid OO/Functional Scala with immutable Domain Objects:
- https://github.com/cer/event-sourcing-examples/tree/master/scala-spring

#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign

Листаю сейчас книжечку "Теоретический минимум по Computer Science", Фило Владстон.

В оригинале называется "Computer Science Distilled" by Wladston Ferreira Filho.

У профильного специалиста она вряд ли вызовет большой интерес, а вот для свитчеров (т.е. для перешедших из других отраслей и не имеющих профильного образования по IT) - вполне полезное чтиво на пару сотен страниц. Минималистичный ликбез по теоретическим основам.

Содержит основы математики (логика, комбинаторика, вероятность), алгоритмы и структуры данных, основы Баз Данных (RDBMS, NoSQL), описание Парадигм Программирования и основы архитектуры железа.

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

#Algirithms #Basics #Math

P.S.: эту же информацию (Retry pattern) можно найти еще и в каталоге Cloud Design Patterns:
- https://docs.microsoft.com/en-us/azure/architecture/patterns/retry

#Microservices

Rob Pike, оказывается, кроме Golang, любит покодить интерпретатор функционального языка программирования... на Golang... Так что, теперь уже никто не скажет, что FP и Golang несовместимы 🙂))

📝 "This program was a joy to put together. Its purpose was fun and education, and in no way to create a modern or even realistic Lisp implementation."
- https://github.com/robpike/lisp

#FunctionalProgramming #Golang

📝 "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо."
- И.Е. Репин

#SoftwareDesign #SoftwareArchitecture

> "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо." - И.Е. Репин

Второе предложение этого выссказывания, "потом сложно и плохо", демонстрирует собою "Синдром второй системы". Мы его уже вспоминали.

#SoftwareDesign #SoftwareArchitecture

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

Для многих людей отправной точкой понимания OOP являются известные письма Alan Kay (стоит сразу отметить, что этот вопрос - дискуссионный, но мы беспристрастно рассмотрим различные точки зрения):

- http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

- http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Я выделю главное из них:

📝 "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
- Alan Kay

📝 "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)."
- Alan Kay

Интересный момент - на его мышление значительное влияние оказал язык LISP, впрочем, в то время языков было не так уж и много.

Почему Alan Kay? Потому что он считается автором термина Object-Oriented, хотя история самой OO-парадигмы уходит, как мы увидим, несколько глубже (вплоть до https://wiki.c2.com/?SimulaLanguage , и даже https://wiki.c2.com/?SketchPad ), а Alan Kay придумал только часть этого термина ( https://wiki.c2.com/?HeDidntInventTheTerm )

На эту тему есть страницы на сайте Ward Cunningham (как всегда, информация с его сайта бесценна):

- https://wiki.c2.com/?DefinitionsForOo

- https://wiki.c2.com/?NobodyAgreesOnWhatOoIs

- https://wiki.c2.com/?NygaardClassification

- http://wiki.c2.com/?AlanKayOnMessaging

- http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

- https://wiki.c2.com/?AlanKayOnObjects

- http://wiki.c2.com/?MessageOrientedProgramming

- http://wiki.c2.com/?ObjectOriented

- https://wiki.c2.com/?ObjectOrientedProgramming

- https://wiki.c2.com/?ObjectOrientedPurity

- https://wiki.c2.com/?OoFitsOurMentalAbilities

И интересное видео от David Wast:
- "David West OOP is Dead! Long Live OODD!"
https://www.youtube.com/watch?v=RdE-d_EhzmA

Grady Booch упоминает две фундаментальные статьи, оказавшие значительное влияние на становление OOP:

📝 "His is one of the influential papers [David Parnas' 1972 paper]; the work by Liskov on abstract data types was also very important"
https://twitter.com/Grady_Booch/status/1302747652426145793?s=19

Вот они:
1. "On the Criteria To Be Used in Decomposing Systems into Modules (1972)" by D. L. Parnas
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.7232

2. "Programming with Abstract Data Types (1974)" by Barbara Liskov, Stephen
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.136.3043
и
"Abstraction mechanisms in CLU." by B. Liskov, A. Snyder, R. Atkinson, and C. Schaffert. Communications of the ACM, 20:564–576, 1977.
https://web.eecs.umich.edu/~weimerw/2011-6610/reading/liskov-clu-abstraction.pdf

Более подробно историю OOP вы можете посмотреть в главе "2.2 Foundations of the Object Model" книги "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch and others. Там он приводит еще несколько статей, сыгравших значительную роль в истории OOP.

Есть еще интересная история от Ward Cunningham:
- https://wiki.c2.com/?InformalHistoryOfProgrammingIdeas

И история OOP от его пионеров - основателей Simula:
- https://web.archive.org/web/20021210082312/http://www.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

Как уже говорилось ранее ( https://news.1rj.ru/str/emacsway_log/393 ), самая большая проблема в разработке - это неясность намерений автора. С OOP - тоже самое. Информации много, но мало кто понимает, какую проблему оно призвано решить. Непонимание его целей приводит к некорректному его применению, что, в свою очередь, приводит к недовольству его применением. Непонимание его целей не позволяет оценить эффективность его применения.

Поэтому, мы начнем с цели OOP в следующих постах.

#OOP #SoftwareDesign

Начнем с определения OOP и его целей от Kristen Nygaard, который считается соавтором (вместе с Ole Johan Dahl) OO-парадигмы, хотя и не автором OOP термина.

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

📝 "Object-Oriented Programming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world."

📝 "The notion of a physical model should be taken literally. Most people can imagine the construction of physical models by means of, for example, Lego bricks. In the same way, a program execution may be viewed as a physical model. Other perspectives on programming are made precise by some underlying model defining equations, relations, predicates, etc. For object-oriented programming, however, we have to elaborate on the concept of physical models."

- Kristen Nygaard, https://wiki.c2.com/?NygaardClassification

📝 "It is difficult to discuss the benefits of object-orientation without first defining it. Before introducing the BETA approach, however, we shall briefly discuss what the benefits of object-orientation are considered to be. There are three main benefits: real world apprehension, stability of design and reusability of both designs and implementations. When people disagree about what object-orientation is, it is often because they attach different levels of importance to these aspects. We consider all three aspects to be important, though perhaps not equally so."

📝 "(Krogdahl and Olsen, 1986) (translated from Norwegian) put it this way:
‘The basic philosophy underlying object-oriented programming is to make the programs as far as possible reflect that part of the reality they are going to treat. It is then often easier to understand and to get an overview of what is described in programs. The reason is that human beings from the outset are used to and trained in the perception of what is going on in the real world. The closer it is possible to use this way of thinking in programming, the easier it is to write and understand programs.’"

- "Object-Oriented Programming in the BETA Programming Language" by Ole Lehrmann Madsen, Birger Møller-Pedersen, Kristen Nygaard
https://www.researchgate.net/publication/220695504_Object-Oriented_Programming_in_the_BETA_Programming_Language

#OOP #SoftwareDesign

В предыдущем сообщении было рассмотрено мнение людей, которые считаются первооткрывателями OO-парадигмы (если не учитывать https://wiki.c2.com/?SketchPad ). Теперь можно рассмотреть мнение человека, который считается автором OO-термина (если не учитывать https://wiki.c2.com/?HeDidntInventTheTerm ).

О том, что Alan Kay понимает под OOP, уже говорилось в здесь: https://news.1rj.ru/str/emacsway_log/415

Но более интересно то, решение какой задачи он возлагал на OOP. Он озвучивает интересную метафору сравнения с интернетом (позже мы услышим похожую метафору, но с операционной системой, от N.Wirt).

📝 "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas."
- Alan Kay, http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

📝 "Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether. As with most new ideas, it originally happened in isolated fits and starts."
- "The early history of Smalltalk", by Alan C. Kay, Apple Computer

OOP имеет много общего с моделью вычислений (что не является парадигмой):

📝 "The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as "messages" for what essentially are procedure calls rather than one-way notifications).

This has caused endless terminological difficulties especially when considering that the the other major sources of OO thinking--capability architectures and the SIMULA 67 research--were not in the least inspired by ActorsModel thinking."
- http://c2.com/wiki/remodel/?AlanKaysDefinitionOfObjectOriented

И тем не менее, кто бы что не говорил, Alan Kay прямым текстом называет OOP парадигмой:

📝 "Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm—which I called object-oriented—for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modeling the ever more complex dynamic systems and user relationships made possible by the silicon explosion."
- "The early history of Smalltalk", by Alan C. Kay, Apple Computer

Заканчивает эту книгу Alan Kay своим видением развития OOP:

📝 "This higher computational finesse will be needed as the next paradigm shift—that of pervasive networking —takes place over the next five years. Objects will gradually become active agents and will travel the networks in search of useful information and tools for their managers. Objects brought back into a computational environment from halfway around the world will not be able to configure themselves by direct protocol matching as do objects today. Instead, the objects will carry much more information about themselves in a form that permits inferential docking. Some of the ongoing work in specification can be turned to this task [Guttag][Goguen ]."
- "The early history of Smalltalk", by Alan C. Kay, Apple Computer

#OOP #SoftwareDesign