软件架构师的错误(Software architect mistakes)

By | 2018年7月11日

I think that to get up in the morning and brew a good cup of coffee is one of the best way to start the day. You know, the heady fragrance that emanates from the machine-pot, it’s delicious. When it’s ready, pour the coffee into a cup, add some sugar, and finally you got it – end of the coffee making process.


Have you ever thought to design a coffee making process with some diagrams, or doing the same with other banal activities such as taking a shower? Of course not.


For other cases less trivial than these, including software project development, a minimal-design work can be quite useful and somewhat needed.

Often questions arise; is an architecture design worth the time and effort invested in it? Well, you may answer this question first: Are there risks in the project that could be minimized by an early design activity?



The more ambitious and challenging the project is, the higher the number of risks, and the more difficult it is to complete successfully.

How to identifying risks. The easiest place to start is with requirements, in whatever form they take, and to look for things that seem difficult to achieve.



Gathering requirements is fundamental for deciding what to do and how. However, sometimes problems arise at this starting point that lead to the ruination of the project. Some assumptions may underestimate this key phase and shake the architect role to its foundations:


1. It’s someone else’ responsibility to do requirements.

Domains drive the architecture choices, not vice-versa. Requirements can create architecture problems. At the very least, you need to assist the business analysts.

2. 老纸边敲代码边熟悉此领域。。。


3. The requirements are already fully understood by the stakeholders.

Clear communication is critical between people and the role of a software architect can be a very difficult one when others don’t understand what you do and why.

3. 各方对需求已经非常了解了


4. Domains are irrelevant to architecture choice.

Developers may copy an architecture from a past project. Maybe just following the company standard, but ignoring the motivations behind previous choices. They are more likely to be unaware of the qualities required in the current project.

4. 行业和架构选择木有半毛钱关系

(反正软件架构和所属行业也没太大相关性)码农想,那干脆从之前的项目中直接拷一个拿来用吧。 (这种偷懒行为)看似合乎公司标准,但却忽视了之前架构选择背后的动机,而有可能忽略了目前项目的质量需求。

5. I already know the requirements.

At least the documentation should be in your mind, but designers should use models to amplifying their reasoning abilities and unfold not clearly visible aspects that affect their own risks.

5. 小的的确知道您的需求了。



电子邮件地址不会被公开。 必填项已用*标注