Отпускное чтиво, навеянное чередой не связанных между собой событий, но приведших к одинаковым мыслям.
Заметки из книги "Just Enough Software Architecture".
1. Software architecture is about the design of your system and the impact it has on the system’s qualities, qualities like performance, security, and modifiability. This definition discusses how architecture differs from detailed design and how some of your biggest design decisions can have implications deep into the code.
2. 3 типа архитектурного подхода:
Imagine that your performance requirements say that your system must respond to requests within 50ms.
Here are some possible ways that you could approach the system’s architecture, given the three design approaches:
• Architecture-indifferent design. If you followed architecture-indifferent design, you could copy the distributed processing architecture from your last system and discover, hopefully not too late, that its inter-machine messaging over head eats up most of that 50ms, leaving little time to do the real processing. To succeed, you either change the architecture or write very efficient code that can complete in 10ms.
• Architecture-focused design. If you followed architecture-focused design, you would deliberately choose an architecture that is compatible with that requirement, such as a client-server architecture. The single remote call to the server might take 10ms, which leaves you a reasonable 40ms to do the real processing.
• Architecture hoisting. If you hoist the performance goal into the architecture, you would ask yourself how the architecture could ensure that a 50ms response was always achievable. Perhaps your investigation reveals that there are peak demand times that could overload your servers, so you build software to recruit additional processing, perhaps from a cloud of servers.
3. How much design and architecture should developers do?
There is much active debate about this question and several kinds of answers have been suggested:
• No up-front design. Developers should just write code. Design happens, but is coincident with coding, and happens at the keyboard rather than in advance.
• Use a yardstick. For example, developers should spend 10% of their time on architecture and design, 40% on coding, 20% on integrating, and 30% on testing.
• Build a documentation package. Developers should employ a comprehensive set of design and documentation techniques sufficient to produce a complete
written design document.
• Ad hoc. Developers should react to the project needs and decide on the spot how much design to do.
4. The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: “What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?”
The risk-driven model can be summarized in three steps:
1. Identify and prioritize risks
2. Select and apply a set of techniques
3. Evaluate risk reduction
5. Прочитал первые 3 главы. Пока не впечатлен. Продолжение следует. Дальше идут примеры. Посмотрим, как зайдет.
Заметки из книги "Just Enough Software Architecture".
1. Software architecture is about the design of your system and the impact it has on the system’s qualities, qualities like performance, security, and modifiability. This definition discusses how architecture differs from detailed design and how some of your biggest design decisions can have implications deep into the code.
2. 3 типа архитектурного подхода:
Imagine that your performance requirements say that your system must respond to requests within 50ms.
Here are some possible ways that you could approach the system’s architecture, given the three design approaches:
• Architecture-indifferent design. If you followed architecture-indifferent design, you could copy the distributed processing architecture from your last system and discover, hopefully not too late, that its inter-machine messaging over head eats up most of that 50ms, leaving little time to do the real processing. To succeed, you either change the architecture or write very efficient code that can complete in 10ms.
• Architecture-focused design. If you followed architecture-focused design, you would deliberately choose an architecture that is compatible with that requirement, such as a client-server architecture. The single remote call to the server might take 10ms, which leaves you a reasonable 40ms to do the real processing.
• Architecture hoisting. If you hoist the performance goal into the architecture, you would ask yourself how the architecture could ensure that a 50ms response was always achievable. Perhaps your investigation reveals that there are peak demand times that could overload your servers, so you build software to recruit additional processing, perhaps from a cloud of servers.
3. How much design and architecture should developers do?
There is much active debate about this question and several kinds of answers have been suggested:
• No up-front design. Developers should just write code. Design happens, but is coincident with coding, and happens at the keyboard rather than in advance.
• Use a yardstick. For example, developers should spend 10% of their time on architecture and design, 40% on coding, 20% on integrating, and 30% on testing.
• Build a documentation package. Developers should employ a comprehensive set of design and documentation techniques sufficient to produce a complete
written design document.
• Ad hoc. Developers should react to the project needs and decide on the spot how much design to do.
4. The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: “What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?”
The risk-driven model can be summarized in three steps:
1. Identify and prioritize risks
2. Select and apply a set of techniques
3. Evaluate risk reduction
5. Прочитал первые 3 главы. Пока не впечатлен. Продолжение следует. Дальше идут примеры. Посмотрим, как зайдет.
Комментарии
Отправить комментарий