关于软件架构师能力要求的评论

    今天在网上想买一本关于系统架构方面的书，自从上次从当当上买了劣质书以后，我就有了经验，所以，买书必看评论。因为我是消费者，给的评论都是发自内心的，不瞎编，反正我是这样的，So，别人的评论还是有一定的参考价值的。

 

    先看了一本《系统架构设计教程》，是国家指定的软考教材，一看评论说书薄，写的空洞，范范。Pass。

    又看了一本《创业必经的那些事》，评论写的还不错，放入购物车先。

。。。

 

    有点跑题了，我是想买软件架构方面的书，接着看列表中的架构书籍，点《架构实战—软件架构设计的过程》，看评论，书的内容还没看，但看到评论感觉很给力：

 

架构师的能力和职责 

 

中级评论员:naibayin

 

读《架构实战》前，和几个阿里的架构师聊天，讨论架构师最基本的素质，总结出两点，1是技术知识广度，2是业务行业深度。
　　
　　自己细化后，和《架构实战》这本书的架构师的定义不谋而合。
　　
　　1 架构师是技术领导。
　　架构师必须要有技术，而且还是领导。架构师要带领自己团队完成自己的任务，完全凭借自己的能力做事情，完全是匹夫之勇，根本不提倡。
　　
　　2 架构师理解软件流程。
　　架构师必须了解软件流程，否则无法驱动整个团队前进，如果一个架构师不熟悉开发流程，无法协调产品线相关人员进行高效工作，也无法指导团队成员完成自己的工作。所以来说架构师一般不是空降兵（除非是全新的部门），因为空降兵一般不会熟悉新公司的开发流程，即使是同一个行业的，各个公司的差别还是很大。所以说听说某某去某某公司做首席架构师或者首席科学家，一般是高风险的事情，即使他对这个行业很了解。
　　
　　3 架构师必须熟悉业务领域。
　　如果一个架构师不熟悉自己的行业，做的架构就是纸上谈兵，熟悉业务领域的架构师，才能很好的理解需求，做出合适的方案。互联网和网络安全是完全不同的两个方向，即使你熟悉里面的各种具体技术，但是以互联网的架构来做网络安全产品，肯定是100%的失败。
　　我做PKI的时候，项目最初的使用.net，使用微软的crytoAPI，开发的很顺利。后来来了一位新的架构师，觉得.net不能跨平台，决定选用java，做出产品后，发现找不到arm cpu的jdk，使用平台有限。再次决定使用openssl做，最后这个项目以失败而告终。后来我想过arm cpu都是嵌入式设备用的，根本没有任何嵌入式设备提供CA服务。
　　
　　4 架构师必须要有广度的知识。
　　架构师考虑的问题必须全面，必须了解的要广，具体的细节可以不关注，因为细节变化很快。很多具体技术人员出身的架构师，只关注于具体的细节，某些方面做的很好，整体的性能很差。
　　下面这个项目的成功可以理解为一个笑话。某公司的两个部门都做c程序的，A部门做的平台使用的x86和mips，B部门使用平台是x86和 arm，后来A部门的一个模块要给B部门用，最后发现根本不能运行。最后A部门发现arm平台使用big endian模式，这样A部门的20多名员工，检查代码中所有非零整数，经过数个月苦战，才修改完毕。其实解决方法很简单，因B部门的代码也是首先在 x86做的，做的时候他们考虑了cpu的endian模式。这并不能说B部门架构师很牛，从另一个方面说他的无知。因为板子有跳线，专门切换cpu的是 big endian还是little endian，这样两个部门都可以不修改程序。
　　
　　5 架构师必须是写程序的高手。
　　架构师一般都是开发人员出身，一般都是团队的核心。优秀的架构师应该了解团队使用各种技术，有了这些知识，才能和开发人软进行有效沟通。
　　有一个项目架构使用xml做配置，因为病毒库很庞大，最后导致xml 达30多兆，服务端的java程序使用dom 进行过滤的时候，30兆xml加载很慢，频繁出现out of memory。这个项目后来搁浅。根据以前的经验发现 msxml加载30多M的xml 不过几秒，而且msxml的xpath速度很快，后来专门为此写了JNI处理xml的。
　　
　　6架构师是优秀的沟通人员。
　　架构师一定要会忽悠，至少要扯淡。架构师不但要指导本部门员工的工作，也要协调其他部门的资源，还要向用户收集需求，制定规格说明书，重要的把用户的不合理要求砍掉，合理需求遵循自己的思路。

 

 

当然，后面也有一些不好的评价，不过，我还是觉得买来看看，开卷有益。

 

在做了一段时间管理后，发现，做技术出身的总有一种情结，那就是自己做的要比别人更细致、更好，我一定要掌握细节。

 

可是，在现在的开发团队中，都是合作，不是什么事情都能亲历亲为。更甚者，都把活安排出去，自己就不用做细节的技术，于是就有一种“漂浮”的感觉，很不踏实。

 

所以，我还是不懂管理，不懂技术。O(∩_∩)O~