软件架构师最容易犯的错误

最近看了一些文章，加上自己的一些经验，总结一下软件架构师 （有的称之为解决方案架构师）最容易犯的一些错误。希望可以和架构师们共勉，个人观点，难免偏颇。

1。范围扩张

每个人都知道项目需要满足需求，但是由于架构师都是技术出身，所以老是会沿用程序员的那种完美主义精神，总是想把自己的系统做到最好，无形中却扩大了项目的范围，也就是经常说的“scope creep”，诚然，项目发起人一定是希望我们可以将功能作的更多，范围更多，但是，他们的前提是时间和资源不变。所以，我们在给系统增加范围的时候，一定要在时间资源容许的前提下，而不是自己觉得什么好就做什么。

2。过分设计

设计模式，软件的抽象，对象设计的精化都是好东西，他们可以让我们的系统可以在将来的变化到来的时候尽可能少的修改代码，也可以让我们的代码结构层次更加清晰，更加容易理解。但是，任何事情都有反作用。我们在做这些工作的时候，一定要同时考虑这么两个问题：一。是否有必要？有的地方业务可能变化很少或者基本不会变化，那也许我们就没有必要这么辛苦了；二。抽象越多，模式用的越多，以后的维护成本就越大，因为我们不能期望这个系统以后的维护，二次开发等等一定是用现在开发的这些人，人才会流失，也许项目开发完毕以后，大部分的开发人员都撤退了，这时候我们就需要新的开发人员补充进来，可是这些人的水平不同，理解能力不同，如果我们系统设计的过于“好”，那么这些人掌握程序的代价就会过大了。所以，设计是一个平衡。毕竟我们做的都是项目而不是研究。

3。忽略项目干系人

我们很多架构师总是和项目组成员打交道，和需求人员以及项目发起人打交道，可是往往忽略了其他人，比如测试人员，网管，将来系统上线以后的维护人员，DBA等等。但是往往对于他们的忽略可能造成系统的不完整或者失败。比如在有的地方，你的项目上线是需要其他人员来做的，是需要验收的，部署过于复杂或者维护手段不够，不符合企业的安全规定，网络规定等等，都有可能导致系统的失败。

4。忽略系统的质量要求

一个系统往往会在功能需求上面写的很清楚，但是需求人员很难提出具体的质量指标（也有叫做非功能需求），比如系统的高可用性，可维护性，安全性，性能等等各个方面的要素。这些要素其实往往是互相矛盾的，架构师需要充分了解需求，和各种人员沟通，在项目开始的时候明确这些非功能性要求，然后针对这些进行系统的设计。

5。设计过于简化

我们以前见过一些架构设计，就是一张大图，显得非常酷，但是用处却不大，因为我们不太可能在一张图里面描述清楚一个大型系统的一切。我们的架构设计实际上是给不同的人看得，比如给用户获得认可，比如给开发人员，比如给系统部署人员了解部署情况等等。所以，目前最好的方法就是多视图，多层次，针对不同的对象开发不同的视图，并且每一个视图都有一个逐步细化的过程，然后还要配上足够的文字说明，这样的架构设计才真正有用。这个业界有很多方法，比如微软有BAIT，IBM有4+1视图，还有著名的Zachman的六个视图六个模型等等。

6。不切实际的设计

很多架构师非常喜欢用新的技术，没有错，了解IT趋势，使用新的设计思路，平台，技术是应该的也是必须的，但是我们必须结合实际，如果一个技术太新，就意味着你的开发人员需要大量的学习成本，以为者这个技术可能还有很多bug，就意味着项目过多的风险，也可能意味着你的维护人员也需要足够的学习成本。所以，即使是新的技术，也应该结合项目的实际，尽可能的选择相对成熟的，当然，如果你的项目是那种研究性的或者其他特殊项目，另当别论。

还有的架构师喜欢什么东西都自己做，比如自己做各种底层的东西，自己做一套完整的安全机制等等，其实很多情况下，我们应该综合考虑时间，范围，成本，质量几个要素，也许可以选择一些公用的东西或者现有的东西，毕竟我们大多数的都是项目，项目还是以应用为主的。