今日推荐开源项目：《排版指南 chinese-copywriting-guidelines》
今日推荐英文原文：《5 Key Principles of Software Architecture》
今日推荐开源项目：《排版指南 chinese-copywriting-guidelines》传送门：GitHub链接
推荐理由：使用中文文案时的排版技巧，达成最起码的排版统一可以让团队更像一支团队。排版方面有许多细节是需要通过统一来实现美感的，中英文的空格、标点的使用、专有名词的书写等等，拥有统一排版的文案相较于没有的来说要更为美观这一点是不争的事实。不过不管怎么说，都不要把 github 写成和象形文字一样的 gｲんĤЦ8 才好……
今日推荐英文原文：《5 Key Principles of Software Architecture》作者：Semi Koen
原文链接：https://towardsdatascience.com/5-key-principles-of-software-architecture-e5379cb10fd5
推荐理由：设计软件架构时的关键技巧
5 Key Principles of Software Architecture
What great software architects hide under their belts
Solution architects are the designated experts responsible for a system’s architecture as well as the technical standards (inc. technologies, platforms, infrastructure) of a particular product. They set the vision and their analysis is key to the product’s successful definition, design, delivery and life-time support. They therefore need to understand not only what the business need, but also what is logical, scalable, cost effective and in-line with the overall technology goals of the organisation.One of the vital skills of an architect is to be able to view the architecture from many different standpoints: each one of them individually might not be fully relevant, but combining them together gives a helicopter view of the product. These standpoints comprise of principles, standards, patterns and anti-patterns, rules of thumb and empirical practices which are essential for decision making towards a particular direction and also evaluating the project’s success.
In this article we will cover those architectural principles that attribute to you ‘sinking or swimming’ in your role as an architect!
“If you think good architecture is expensive, try bad architecture!” — Brian Foote & Joseph Yoder
Solid principles
Let’s start with my favourite subject:The SOLID principles do not only apply on software development but also when architecting a system.
We will now see how…
Single Responsibility Principle
Each system capability (e.g. service/module/api) should have only one responsibility and as such one reason to change. Keeping the responsibilities as narrow as possible means that the users know of the intended purpose, which leads to less errors.Open-Closed Principle
This principle postulates that it is preferable to extend a system behaviour, without modifying it. Although it is often not a good idea to try to anticipate changes in requirements ahead of time (as it can lead to over-complex designs), being able to adapt new functionality with minimum changes to existing components is key to the application’s longevity.Liskov Substitution Principle
In Software Development, this means that derived classes must be substitutable for their base classes, but this principle’s resemblance with Bertrand Meyer’s Design by Contract is how it can be applied to Distributed Architecture: two services communicate effectively and repeatedly when there is a common ‘contract’ between them, which defines the inputs/outputs, their structure and their constraints. Therefore: given two distributed components with the same contract, one should be replaceable with other component with the same contract without altering the correctness of the system.Interface Segregation Principle
Interfaces/contracts must be as fine grained as possible and client specific, so calling clients do not depend on functionality they don’t use. This goes hand in hand with the Single Responsibility principle: by breaking down interfaces, we favour Composition by separating by roles/responsibilities, and Decoupling by not coupling derivative modules with unneeded responsibilities.Dependency Inversion Principle
High level modules should not depend on low level ones; they should both depend on abstractions. Likewise, abstractions should not depend on details, but details should depend on abstractions. As such this principle introduces an interface abstraction between higher-level and lower-level software components or layers to remove the dependencies between them.
Courtesy: Being a Data Scientist does not make you a Software Engineer!
The 'Least' principles
I am grouping these together due to their naming convention:The principle of Least Astonishment
The principle of least astonishment (or Least Surprise) suggests that a solution or approach would not surprise a reasonably knowledgeable person in the subject area when encountered for the first time (the audience may vary e.g. end-user, programmer, tester etc). In more practical terms, the principle aims to leverage the pre-existing knowledge of users to minimise their learning curve when using a module, so anything with high unpredictability factor is a good candidate for re-design.It applies to every single aspect of the architecture: from naming services, to the visualisation of user interfaces, to the design of the domain model.
There are good surprises and then there are bad surprises…
The principle of Least Effort
This principle (also called Zipf’s Law) stems from a basic human behaviour: Everyone tends to follow the path that is as close to effortless as possible. So for example if our design follows a particular pattern, the next developer will follow the same pattern again and again unless there is a significantly easier way to perform the task, in which case they will change! Or, taking this further, once they find acceptable results for a task, there is no immediate need to improve the current solution.Least effort is a variant of least workAs such it is imperative to aim for a strong start by putting the right architecture in place: it sets high expectations and ensures everyone understands that the quality is not compromised in the project’s lifecycle and it will be adhered to in case of future changes.
For me, the greatness of this principle lies in the fact that its benefits extrapolate: once we put a right design in place, we can create an architectural framework which will be the basis of the next systems we build. In other words, we are able to establish a successful and future-proof template for the organisation’s software systems.
Path of least resistance
The principles of 'Ecomonics'
These two principles have a common theme: the cost of making the most of an opportunity and the cost of delaying making decisions.The principle of Opportunity Cost
Every time we make a choice, there is a certain value we place on that choice. Value has two parts: benefits and costs. The opportunity cost of a choice is what we give up to get it. To make a good economic decision, we want to choose the option with the greatest benefit to us but the lowest cost.For example, if we have two choices, either an in-house built system or an off-the-shelf vendor product and we choose the latter, then our opportunity cost is the shiny new system our development team could have developed but didn’t.
This is what architecture is all about: weighing choices against each other and trying to make an informed decision on which one will add the most value for the project. For instance, a very common dichotomy is whether to create a tactical solution with quick time to market or a more strategic one which will be more expensive now with the view to leverage it in future projects and hence minimise the cost later down the line.
Here are some points to consider:
- What is the time available for the architectural analysis/evaluation? It is challenging enough to come up with one solution, let alone a few!
- What is the product pipeline for the next 1–3 years? And what other projects are lined up? Can you see any synergies?
- What is your current technical debt that you could potentially address?
- And turning this around: How much new technical debt will incur if you pursue a tactical solution?
- Which quality attributes tend to be the most important for systems in your organisation and how will they be compromised by the proposed solution?
- Apart from the architecture team who else is a stakeholder that will affect the decision? The Business? Your boss? The Technical Design Authority? What are the key objectives of each stakeholder? How will you mitigate conflicting needs?
Courtesy: What is opportunity cost
The principle of Last Responsible Moment
This principle (aka Cost of Delay) originates from Lean Software Development and emphasises holding on taking important actions and crucial decisions for as long as possible. This is done so as to not eliminate important alternatives until the last possible moment i.e. wait to narrow the options down until you are better informed.A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.
One way to mitigate the risk of deciding too late is to build Proof of Concepts (POCs) to prototype the alternative options and demonstrate to the stakeholders what they are asking for.
Early in a project we should make as few binding decisions as possible!
Epilogue
Architectural principles help us evaluate the decisions we make throughout the project and also ensure we are in line with the overall goals, not only for the project but also the organisation’s technology. This is an amalgamation of the five principles we elaborated on:
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
