系统架构师要什么条件

系统架构师要什么条件

　　系统架构师在软件开发的活动中起到了纲领性的作用，就像建筑设计师一样，从大的方向来给软件定一个基调。软件开发中碰到的很多问题，归咎起来都可能和当初的架构设计有关，所以架构师要想不成为众矢之的，也不是容易的事情。那么要什么条件才能成为系统架构师呢?

　　1、完成此应用程序的基本功能。

　　如果这是一个通信程序客户端，那么它至少应该完成客户端所具有的功能，通过所有的测试用例。不同的功能是需要不同的组成架构的，从降低复杂度和提高可维护性的角度来考虑对系统进行解构，往往是最直观的做法。

　　2、健壮性。

　　这个程序不应该轻易的crash，如果是界面程序，在面对异常情况的时候采取柔和的方式来通知用户。如果是被别的程序所使用的库，保持健壮性更是非常重要。作为架构师，应该采取一定的措施来保证模块的'正确工作，至少应该保证在出错的情况下能够比较容易的区分是否是本模块造成的。也许有人说这是design和program的事情，但是架构师如果不在纲领上制定策略和要求，实现上也是很难操作的。

　　3、低的资源消耗。

　　很多软件架构，在架构文档里看时非常华丽，用了很多模式，一个普通的应用要拆分成多个进程，再用MVC分离各个模块，加上一大堆监听适配器过滤器等，可以说模式是能带来一些好处的，但是往往代价是更多的资源消耗，内存占的多了，性能下降了，逻辑变得更复杂了。作为架构师一定要权衡，而不是为了表达自己的知识能力。最好的情况是，能够给出在各种usecase下模块或应用对资源的消耗程度，比如会占用多少内存，某个接口需要多长时间等。因为现在的接口定义一般都只是定义使用方式，包括函数名和参数列表，至于使用时的代价由于没有说明，往往成为模块使用者和提供者之间争论的焦点。

　　从程序员的角度来讲，可维护性往往更为重要，因为维护的阶段比开发的阶段更长，面对的压力也更大，而且由于各种各样的原因，经常要一个新手来维护这个程序，如何让新手很容易的理解它并且马上具备解决问题的能力，对架构师来说也不是一件可以推卸的责任，采用常见的设计模式，制定或采用通用的代码风格，完善相关的文档等等，都是好的practice。

　　对于那些高层次的架构师来说，因为面对的是由很多模块应用组成的系统，他所要处理的实际上如何协调各模块关系，保证整个系统的功能性能和稳定性，至少他应该了解各个应用所具备的功能，基于此来制定各个模块之间的接口。在必要的时候，要去掉那些作用不大但影响整个系统性能和稳定性的模块，对各个模块的可选功能也要做一定的限制，不能允许其无限制的膨胀。架构师也往往面临着选择既有实现的困境，采用第三方或者开源实现时，一定要和已有的实现进行全方位的比较，在很难做出决定时宁可保持不变，或者采用小的实验步骤来获取真实的数据。