今天在网上想买一本关于系统架构方面的书,自从上次从当当上买了劣质书以后,我就有了经验,所以,买书必看评论。因为我是消费者,给的评论都是发自内心的,不瞎编,反正我是这样的,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~