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

软件开发管理 William 323浏览 0评论

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. 小的的确知道您的需求了。

除了将文档熟稔于心,(即使你真的懂大爷们的需求了)设计者还应当使用模型来增强他们的推理能力,把那些不易被看到察觉到的却极有可能引发风险的东西呈现出来。

转载请注明:AspxHtml学习分享网 » 软件架构师的错误(Software architect mistakes)

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址