从“架构师书单”讲开去

标签: 架构师 | 发表时间:2010-05-13 02:14 | 作者:aimingoo 黄立
分享到:
出处:http://blog.csdn.net/aimingoo

【源起】

琉璃要我推荐一下给工程师们的各阶段的书单,这件事被我压在手边好些天了已经。然后呢就看见了公司内网中孙坚的一份推荐。其实那份书单的一些信息也是有出处的(或者说有类似介绍的地方),是江南白衣的另一份架构师书单,目前已经“翻新”到2009年版和第3版了:

http://calvin.javaeye.com/blog/351007

http://calvin.javaeye.com/blog/57670

http://blog.csdn.net/calvinxiu/archive/2007/03/06/1522032.aspx

 

看来白衣兄的确是要把这份书单做到穷极。但事实上我在看到他的最初版的书单时,就提出过反对意见:

http://aimingoo.spaces.live.com/blog/cns!F9303C43D5CEAFB3!516.entry

 

换句话说,从4年前白衣兄就开始出书单,再结合他在主页上常常提到的“种种书”,大概到现在他已经读了许多,以至于架构纯熟了吧?

但,真的如此吗?架构师就是一本书一本书地读出来的?

 

进一步地说,工程师也是一本书一本书读出来的?

 

好象不太对吧?其实就我的学习历程来说,书读的多少,只是一个次要条件,而书读得多透,才是充要条件。50本书翻下去,不见比专读一本有效果。我的读书也就向来如此,读一本,就往深透里读,多次地、带批判与反省地读。

 

【关于开发类书目的推荐】

软件开发方面,我下过功夫的是《数据结构》、《汇编语言》、《操作系统原理》这些基础课,应用类的书里,有《Windows核心编程》和《Windows技术内幕》等等,但应用类的书没有太多的可推荐性。除了这些,给我最深启发、感受一本书是:

 

《结构程序设计》
最经典的有关结构化程序设计理论的论著。O. J. 达尔、E. W. 戴克思特拉、C. A. R. 霍尔著,陈火旺等译,1980年出版,已绝版。

对于开发人员的具体工作来说,除了各类的“手册”,我觉得《代码大全》是非常值得推荐的:

http://www.china-pub.com/28351

 

 

【关于架构类书目的推荐】

接下来,架构的书都有什么是可以看的呢?除了我在前面

http://aimingoo.spaces.live.com/blog/cns!F9303C43D5CEAFB3!516.entry

中提到的两本:

http://www.china-pub.com/25013

http://www.china-pub.com/23970

之外,我唯有一本是要推荐的,就是新近的一本《架构之美》:

http://www.china-pub.com/196084

 

如果你真的想要看看“术”的问题,我可以建议你看看另一本也叫《架构之美》的书:

http://www.china-pub.com/195142

不过,我需要说明的是:可以看,不可以学。至于为什么,后面我会讲到的。

 

【关于工程类书的推荐】

工程类的书呢?两本:《人月神话》与《人件》。看懂了,工程的全局基本上就在心里了。

 

【我为什么做这样的推荐?】

可能有同学已经注意到了,我的推荐里,关于“工程师”和“程序员”的部分还有实作,还有一些基础,但对于架构与工程,就没有这些类型的书了。为什么呢?

 

我这样推荐的根本原因其实也在这个问题之中:因为,事实上,工程和架构不是“学”出来的,而是“战”出来的。而战局中的人,其实没有那么多条理那么多章法。你让风清扬到千军万马里去打仗,他也是见一个砍一个,而不会使那个孤独九剑,因为剑法还没使出来,就被一枝飞箭给灭了,或者让某个半死的小兵抱住了大脚。

 

剑谱里,不会讲半死的小兵,也不会讲飞箭。前者叫包袱,后者叫风险。无论是架构还是工程,最终决定你是否能推动它的因素,在于你处理这些包袱和风险的能力。这种东西,在书里,从来没有。

 

所以我推荐的这两类书,就是希望同学们从这些书中看到一个“全局的映象”。从书中看到“源由”,看到“选择”,以及看到种种“问题”。只有从结果看到了问题,才真正地读明白了这些书。而读明白了,过去几十年的工程经验或架构思想,也就在心里面了。具体到架构与工程的做法,你再去手册,再去看“江南白衣”兄推荐的那些书,找到解决问题的法子,就可以了。

 

我们大多数人,只是看得到事,看不到问题。所以读书,也就只是读文字,读方法,而不是读那本书的故事。

 

同样地,我们多数人在架构和工程上,也秉承了程序员的思维,应对“种种事”,而不是“种种问题”。所以工程被做到手忙脚乱,架构被做得乱七八糟。

 

【结语】

所以当年诸葛先生挥了挥泪,把马谡给斩了。其实没有人知道,他或许并不心疼。

作者:aimingoo 发表于2010-5-13 18:14:00 原文链接
阅读:12436 评论:35 查看评论

相关 [架构师] 推荐:

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从“架构师书单”讲开去

- 黄立 - aimingoo的专栏
琉璃要我推荐一下给工程师们的各阶段的书单,这件事被我压在手边好些天了已经. 然后呢就看见了公司内网中孙坚的一份推荐. 其实那份书单的一些信息也是有出处的(或者说有类似介绍的地方),是江南白衣的另一份架构师书单,目前已经“翻新”到2009年版和第3版了:. 看来白衣兄的确是要把这份书单做到穷极. 但事实上我在看到他的最初版的书单时,就提出过反对意见:.

迷你书: 架构师(8月刊)

- 去北方-Jack - InfoQ中文站
InfoQ中文站的电子杂志《架构师》(2011年8月刊)出炉了. 本期的主编是InfoQ中文站总编辑霍泰稳. 本期《架构师》月刊专题为云计算的安全风险. 安全风险”作为云计算中重要的一环,一直备受关注,本期的专题我们和IEEE合作就这一话题进行深入讨论,并借助一个调查看看当前已经实施云计算的企业是如何看待云计算和安全的.

软件架构师的沟通修炼

- - 博客 - 伯乐在线
在架构师的角色中,沟通是要求有效果的必备技能与工具. 换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的,也可能会跨好多个行业单位. 由于不能直接管理他人,所以架构师指示别人或群体完成特定行动的能力就受到限制.

一线架构师实践指南(一)

- - CSDN博客架构设计推荐文章
       从本质上,架构设计是需求驱动的,而不是模型驱动的. 但当很清楚需求却依然设计不出架构时,就说明“需求驱动的架构设计”的总结还“缺点什么”. 架构设计是一门艺术,不可能把“一桶需求”倒进某台神奇的机器,然后等着架构设计自己被“加工生成”完毕,因此“需求驱动的架构设计”的总结给架构师的启发不够.

一线架构师实践指南(二)

- - CSDN博客架构设计推荐文章
Conceptual Architecture阶段.        有经验的架构师不会一上来就关注如何定义“接口”,他们在大型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求,据此来设计概念架构. 概念架构是对系统设计最初构想,就是把最关键的设计要素和交互机制确定下来,然后考虑具体技术的运用,设计出实际架构.

系统架构师笔记(二)

- - CSDN博客Web前端推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 七、架构权衡分析法:ATTM(Architecture Tradeoff Analysis Method). 评价软件架构的一种综合全面的方法. 这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标.

系统架构师笔记(一)

- - CSDN博客架构设计推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 1、性能:系统的响应能力,即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数. 架构设计策略:增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等).

软件架构师的职责

- - 研发管理 - ITeye博客
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调.     在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求.