软件架构师的错误

软件项目开发，亲啊，记住来了，再少再小的设计工作也是灰常有用有必要的。

烦人的问题来了，真的值得花时间和努力在架构设计上吗？好吧，得先回答介个问题，早期的设计工作真的能把风险规避到最小化吗？

越大越有挑战性的项目，随着而来的风险和困难也就越大。

如何认清风险：第一步也是最容易走的一步，从需求开始，在需求中找到看起来很不容易完成的东东。

收集需求对于决定要做啥，如何去做是非常重要的。然而可是，有些时候，在初始阶段各种问题如潮水般袭来可能导致整个项目就此歇菜。一些假想和猜测可能低估了项目的主要阶段，甚至动摇架构师的角色祸及整个项目的根基。

1.需求分析跟我不相干

业务决定了架构，而不是架构驱动业务。需求分析做的不好，很可能会给架构的设计带来难题。最起码，当业务分析师做需求分析时，你得在一旁协助。

其它翻译版本(1)

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

上来就先敲代码对于分析某一领域实在是在浪费时间，而软件原型化方法可以帮助降低工程风险，找出最难啃的问题。所以预先建模才更为有效且节省成本。

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

清晰交流顺畅沟通真泥马太太重要了，（不会表达不懂沟通的码农默默的流泪哀悼吧）你自以为甲乙丙丁各方对需求都已经了解了，可当有人搞不懂你在做什么你到底为什么要做那个鬼东东的时候，架构师的角色就显得非常有挑战性的。

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

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

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

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

来源：http://www.oschina.net/translate/software-architect-mistakes?from=20130103