Дорвался до чтения, спешу поделиться радостью.
Открыл для себя чудесный журнал "ACM Queue". Понравившиеся цитаты:
"We replaced our monolith with micro services so that every outage could be more like a murder mystery." [1]
"It's only the law and other deleterious side effects that keep me on the "right" side of violence in some meetings. I'd like to think a jury of my peers would acquit me should I eventually cross to the wrong side, but I don't want to stake my freedom on that." [2]
А вот это очень похоже на то, как я сам всегда поступаю:
"A software design review is intended to answer a basic set of questions:
1. How does the design take inputs and turn them into outputs?
2. What are the major components that make up the system?
3. How do the components work together to achieve the goals set out by the design?
[...] In fact, questions 2 and 3 are going to be your main tools for figuring out what the software does and whether or not it is suitable for the task. [...] When I have to interview people for jobs, I always ask them questions about systems they have worked on while we draw out the block diagram on a whiteboard: What are the major components? How does component A talk to component B? What happens if C fails? [...] Remember that every box that this person draws can be opened if you think you're not getting sufficient detail." [2]
У меня еще есть 4-ый пункт: а что, если обойтись без вот этого квадратика? Можно ли достичь того же результата, но без этого компонента? Что усложнилось бы, а что упростилось?
И о том, как все же проводить дизайн-ревью и случайно не поубивать коллег и рабочие отношения. У меня такой способ работает для код-ревью тоже:
"I have found only one legal way to avoid giving offense, and that is always to phrase things as questions. Often called the Socratic method, this can be a good way to get people to explain to you, and often to themselves, what they think they are doing." [2]
Удивительно, как часто приходится объяснять что Single Responsibility Principle (SRP, оно же буква S в аббревиатуре SOLID) это не "у одного класса только одна обязанность" или "один класс исполняет / отвечает за одну обязанность" и совсем не "один класс -- один метод", а это про то, что у компонентов должна (в идеале) быть одна причина для изменения. Это про изоляцию точек вариаций, если уж совсем конкретно выразиться. Именно это и говорил Роберт Мартин:
"Gather together the things that change for the same reasons. Separate those things that change for different reasons." [3]
И конечное же, дьявольская деталька:
"However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don't want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons." [3]
"We replaced our monolith with micro services so that every outage could be more like a murder mystery." [1]
"It's only the law and other deleterious side effects that keep me on the "right" side of violence in some meetings. I'd like to think a jury of my peers would acquit me should I eventually cross to the wrong side, but I don't want to stake my freedom on that." [2]
А вот это очень похоже на то, как я сам всегда поступаю:
"A software design review is intended to answer a basic set of questions:
1. How does the design take inputs and turn them into outputs?
2. What are the major components that make up the system?
3. How do the components work together to achieve the goals set out by the design?
[...] In fact, questions 2 and 3 are going to be your main tools for figuring out what the software does and whether or not it is suitable for the task. [...] When I have to interview people for jobs, I always ask them questions about systems they have worked on while we draw out the block diagram on a whiteboard: What are the major components? How does component A talk to component B? What happens if C fails? [...] Remember that every box that this person draws can be opened if you think you're not getting sufficient detail." [2]
У меня еще есть 4-ый пункт: а что, если обойтись без вот этого квадратика? Можно ли достичь того же результата, но без этого компонента? Что усложнилось бы, а что упростилось?
И о том, как все же проводить дизайн-ревью и случайно не поубивать коллег и рабочие отношения. У меня такой способ работает для код-ревью тоже:
"I have found only one legal way to avoid giving offense, and that is always to phrase things as questions. Often called the Socratic method, this can be a good way to get people to explain to you, and often to themselves, what they think they are doing." [2]
Удивительно, как часто приходится объяснять что Single Responsibility Principle (SRP, оно же буква S в аббревиатуре SOLID) это не "у одного класса только одна обязанность" или "один класс исполняет / отвечает за одну обязанность" и совсем не "один класс -- один метод", а это про то, что у компонентов должна (в идеале) быть одна причина для изменения. Это про изоляцию точек вариаций, если уж совсем конкретно выразиться. Именно это и говорил Роберт Мартин:
"Gather together the things that change for the same reasons. Separate those things that change for different reasons." [3]
И конечное же, дьявольская деталька:
"However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don't want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons." [3]