如何从普通程序员晋升为架构师Word文档下载推荐.docx

1、如果大家都不是美食家，没那么多讲究，那么从饭馆角度来讲的话，做盖浇饭显然比蛋炒饭更有优势，他可以组合出来任意多的组合，而且不会浪费。软件工程盖浇饭的好处就是“菜”“饭”分离，从而提高了制作盖浇饭的灵活性。饭不满意就换饭，菜不满意换菜。用软件工程的专业术语就是“可维护性”比较 好，“饭”和“菜”的耦合度比较低。蛋炒饭将“蛋”“饭”搅和在一起，想换“蛋”“饭”中任何一种都很困难，耦合度很高，以至于“可维护性”比较差。软件 工程追求的目标之一就是可维护性，可维护性主要表现在3个方面：可理解性、可测试性和可修改性。面向对象的主要好处就是显著的改善了软件的可维护性。面向过程（OP）和面向对象（OO）是不

2、是就是指编码的两种方式呢？不是！你拿到了一个用户需求，比如有人要找你编个软件，你是不是需要经过需 求分析，然后进行总体/详细设计，最后编码，才能最终写出软件，交付给用户。这个过程是符合人类基本行为方式的：先想做什么，再想如何去做，最后才是做事 情。有的同学说：“我没按照你说的步骤做啊，我是直接编码的”。其实，你一定会经历了这三个阶段，只不过你潜意识里没有分得那么清楚。对于拿到需求就编码 的人，可能编着编着，又得倒回去重新琢磨，还是免不了这些过程，以OO为例，对应于软件开发的过程，OO衍生出3个概念：OOA、OOD和OOP。采用面向对象进行分析的方式称为OOA，采用面向对象进行设 计的方式称为O

3、OD，采用面向对象进行编码的方式称为OOP。面向过程（OP）和面向对象（OO）本质的区别在于分析方式的不同，最终导致了编码方式的不 同。面向过程编程（OPP） 和面向对象编程（OOP）的关系关于面向过程的编程（OPP）和面向对象的编程（OOP）,给出这它们的定义的人很多，您可以从任何资料中找到很专业的解释，但以我的经验来看，讲的相对枯燥一点，不是很直观。除非您已经有了相当的积累，否则说起来还是比较费劲。我是个老程序员出身，虽然现在的日常工作更多倾向了管理，但至今依然保持编码的习惯，这句话什么意思呢？我跟大家沟通应该没有问题。无论你是在 重复我走过的路，或者已经走在了我的前面，大家都会有那么一段

4、相同的经历，都会在思想层面上有一种理解和默契，所以我还是会尽量按照大多数人的常规思维写 下去。面向过程的编程（OPP）产生在前，面向对象的编程（OOP）产生在后，所以面向对象的编程（OOP）一定会继承前者的一些优点，并摒弃前者存 在的一些缺点，这是符合人类进步的自然规律。两者在各自的发展和演变过程中，也一定会相互借鉴，互相融合，来吸收对方优点，从而出现在某些方面的趋同性， 这些是必然的结果。即使两者有更多的相似点，也不会改变它们本质上的不同，因为它们的出发点就完全是两种截然不同的思维方式。关于两者的关系，我的观点是 这样的：面向对象编程（OOP）在局部上一定是面向过程（OP）的，面向过程的编程

5、（OPP）在整体上应该借鉴面向对象（OO）的思想。这一段说的的确很 空洞，而且也一定会有引来争议，不过，我劝您还是在阅读了后面的内容之后，再来评判我观点的正确与否。象C+、C#、Java等都是面向对象的语言，c,php（暂且这么说，因为php4以后就支持OO）都是面向过程的语言，那么是不是我用 C+写的程序一定就是面向对象，用c写的程序一定就是面向过程呢？这种观点显然是没有真正吃透两者的区别。语言永远是一种工具，前辈们每创造出来的一种 语言，都是你用来实现想法的利器。我觉得好多人用C#,Java写出来的代码，要是仔细看看，那实际就是用面向对象（OO）的语言写的面向过程（OP）的 程序。所以，即

6、使给关羽一根木棍，给你一杆青龙偃月刀，他照样可以打得你满头是包。你就是扛着个偃月刀，也成不了关羽，因为你缺乏关羽最本质的东西 -绝世武功。同样的道理，如果你没有领会OO思想，怎么可能写得出真正的OO程序呢？面向对象（OO）和面向过程（OP）绝对是两种截然不同的思维方 式。那是不是面向过程就不好，也没有存在的必要了？我从来没有这样说过。事实上，面向过程的编程（OPP）已经存在了几十年了，现在依然有很多人在 使用。它的优点就是逻辑不复杂的情况下很容易理解，而且运行效率远高于面向对象（OO）编写的程序。所以，系统级的应用或准实时系统中，依然采用面向过程 的编程（OPP）。当然，很多编程高手以及大师级

7、的人物，他们由于对于系统整体的掌控能力很强，也喜欢使用面向过程的编程（OPP），比如像 Apache,QMail,PostFix,ICE等等这些比较经典的系统都是OPP的产物。象php这些脚本语言，主要用于web开发，对于一些业务逻辑相对简单的系统，也常使用面向过程的编程（OPP），这也是php无法跨入到企业级应用开发的原因之一，不过php5目前已经能够很好的支持OO了。详解面向过程的编程（OPP）在面向对象出现之前，我们采用的开发方法都是面向过程的编程（OPP）。面向过程的编程中最常用的一个分析方法是“功能分解”。我们会把用户需 求先分解成模块，然后把模块分解成大的功能，再把大的功能分解成小

8、的功能，整个需求就是按照这样的方式，最终分解成一个一个的函数。这种解决问题的方式称 为“自顶向下”，原则是“先整体后局部”，“先大后小”，也有人喜欢使用“自下向上”的分析方式，先解决局部难点，逐步扩大开来，最后组合出来整个程序。 其实，这两种方式殊路同归，最终都能解决问题，但一般情况下采用“自顶向下”的方式还是较为常见，因为这种方式最容易看清问题的本质。我举个例子来说明面向过程的编程方式:用户需求：老板让我写个通用计算器。最终用户就是老板，我作为程序员，任务就是写一个计算器程序。OK，很简单，以下就是用C语言完成的计算器：假定程序的文件名为：main.c。int main（int argc,

9、char *argv）/变量初始化int nNum1,nNum2;char cOpr;int nResult;nNum1 = nNum2 = 0;cOpr = 0;nResult = 0;/输入数据printf（Please input the first number:rn）;scanf（%d,&nNum1）;Please input the operator:%scOpr）;Please input the second number:nNum2）;/计算结果if（ cOpr = + ）nResult = nNum1 + nNum2;else if（ cOpr = -nResult = n

10、Num1 - nNum2;elseUnknown operator!return -1;/输出结果The result is %d!,nResult）;return 0;抛开细节不讲，我想大多数人差不多都会这么实现吧，很清晰，很简单，充分体现了“简单就是美”的原则，面向过程的编程就是这样有条理的按照顺序来逐步实现用户需求。凡是做过程序的人都知道，用户需求从来都不会是稳定的，最多只能够做到“相对稳定”。用户可能会随时提出加个功能，减个功能的要求，也可能会要 求改动一下流程，程序员最烦的就是频繁地变动需求，尤其是程序已经写了大半了，但这种情况是永远无法避免的，也不能完全归罪到客户或者需求分析师。以

11、我们上面的代码为例，用户可能会提出类似的要求：首先，你程序中实现了“加法”和“减法”，我还想让它也能计算“乘法”、“除法”。其次，你现在的人机界面太简单了，我还想要个Windows计算器的界面或者Mac计算器的界面。用户需求开始多了，我得琢磨琢磨该如何去写这段代码了。我今天加了“乘”“除”的运算，明天保不齐又得让我加个“平方”、“立方”的运算，这要 是把所有的运算都穷尽了，怎么也得写个千八百行代码吧。还有，用户要求界面能够更换，还得写一大堆界面生成的代码，又得来个千八百行。以后，这么多代码堆 在一起，怎么去维护，找个变量得半天，看懂了代码得半天，万一不小心改错了，还得调半天。另外，界面设计我也

12、不擅长，得找个更专业的人来做，做完了之后再 加进来吧。这个过程也就是“软件危机”产生的过程。伴随着软件广泛地应用于各个领域，软件开发的规模变得越来越大，复杂度越来越高，而其用户的需求越来越 不稳定。根据用户提出的两个需求，面向过程的编程该如何去应对呢？我想大家都很清楚怎么去改。Very easy，把“计算”和“界面”分开做成两个独立的函数，封装到不同的文件中。#include interface.hcalculate.hif（ getParameters（&nNum1,&nNum2,&cOpr） = -1 ）if（ calcMachine（nNum1,nNum2,cOpr,&nResult）

13、= -1 ）interface.h:int getParameters（int *nNum1,int * nNum2,char *cOpr）;interface.c:int getParameters（int *nNum1,int * nNum2,char *cOpr）,nNum1）;,cOpr）;,nNum2）;calculate.h:int calcMachine（int nNum1,int nNum2,char cOpr, int *nResult）;calculate.c:int calcMachine（int nNum1,int nNum2,char cOpr,int *nResul

14、t）*nResult = nNum1 + nNum2;*nResult = nNum1 - nNum2;面向过程的编程（OPP）就是将用户需求进行“功能分解”。把用户需求先分解成模块（.h,.c），再把模块（.h,.c）分解成大的功能（function），然后把大的功能（function）分解成小的功能（function），如此类推。功能分解是一项很有技术含量的工作，它不仅需要分解者具有丰富的实战经验，而且需要科学的理论作为指导。如何分解，分解原则是什么，模块粒度多大合适？这些都是架构师的要考虑的问题，也是我们后面要着重讲的内容。面向过程的编程（OPP）优点是程序顺序执行，流程清晰明了。它的缺

15、点是主控程序承担了太多的任务，各个模块都需要主控程序进行控制和调度，主控和模块之间的承担的任务不均衡。有的人把面向过程定义为：算法 + 数据结构，我觉得也很准确。面向过程的编程中算法是核心，数据处于从属地位，数据随算法而流动。所以采用面向过程的方式进行编程，一般在动手之前，都要编写一份流程图或是数据流图。3 架构师的职责近来看到CSDN上有个CTO俱乐部，里面聊得是不亦乐乎。我怀着无比崇敬的态度，拜读了一下牛人们的发言。里面有个哥们发起一个话 题：“CTO, 你多久没有写程序了？”。有人回答：“不写代码的CTO,属于.这公司问题大了!看到这里，我就赶紧撤了，怕忍不住反驳几句，反而遭到牛人 们的

16、群殴。试想，一个上点规模的IT公司，还得靠CTO来写程序的话，那是不是才叫问题大了呢。当然，我没有做过CTO，所以我有我的不同看法，而且还愿 意表达出来，无知者无畏。我情愿相信：我所理解的CTO跟这位CTO所理解的是两回事。所以我想，如果有人能把CTO的职责给标准化了，也许就不会有这么 多的争论了。同样的道理，关于架构师的定义，大家也有着不同的理解。什么是架构师？架构师有哪些职责？我觉得有必要提前明确一下，要不然大家沟通起来也会产生类似问题，子说子理，卯说卯理，但是压根说得不是一码子事。1 什么是架构师曾经有这么个段子：甲：我已经应聘到一家中型软件公司了，今天上班的时候，全公司的人都来欢迎我。

17、乙：羡慕ing，都什么人来了？CEO、COO、CTO、All of 程序员，还有会计、司机都来了。哇，他们太重视你了，人才啊，这么多人迎接你！没有啊，就一个人！靠，#%￥$%.很多的创业公司，一人身兼数职的情形还是很常见的。至少，我是经历过的，一个人包办了所有的开发过程，连测试我都做了，绝对的一条龙，但是经常 踩钢丝、骑独轮车总会有失足的时候，结果有一次，从我手里发出去的光盘母盘，含有病毒僵尸，以至于被迫收回已经推上市场的2万张光盘，从那之后，我的心脏 就开始变得无比坚强，现在就是整个后台服务都瘫痪了，我也只是微微一笑。其实，一个人身兼架构师和程序员，甚至多种角色，没什么不妥，后面还会讲这个话

18、 题，这种现象不是中国特色，跟国外是完全接轨的。我曾经跟米国的一个工程师在msn中聊过类似的话题，发现他们的路子跟咱们没什么不同，在IT这个行业， 我们跟世界的差距只有1天，他们刚弄出来的新东西，我们这里第2天保准见得到。架构师这个称呼不是拍脑袋想出来的，是有国际标准（ISO/IEC 42010）可查的。架构师是软件开发活动中的众多角色之一，它可能是一个人、一个小组，也可能是一个团队。微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：企业架构师EA（Enterprise Architect）、基础结构架构师IA（Infrastructure Architect）、特定技术架构TS

19、A（Technology-Specific Architect）和解决方案架构师SA （Solution Architect）。微软的这个分类是按照架构师专注的领域不同而划分的。EA的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title就是首席软件架构师，网易丁磊也喜欢这么称呼自己，实际上就是EA 角色；IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一；特 定技术架构师TSA，他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作；SA的工作则专于解决方案的规划和设计，“解决方案”这个词在

20、中国 已经到了严重泛滥的程度，大忽悠们最喜欢把它挂在嘴边。所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。售前工程师 一般都是带着它到客户那里去发挥的。大公司会把各种类型的架构师分得很清楚，小公司一般就不那么讲究了，架构师多数是是IA+TSA+SA，一人包打天下，所以说大公司出专才，小公司出全才。实际工作中，我们也经常会见到另一种比较简单的分类方式，把架构师分为软件架构师和系统架构师。软件架构师基本上是TSA+IA，这也是程序员 最容易突破，最可能走上的一条道路，比如JAVA架构师、DotNet架构师、LAPM架构师等等，我后面所讲的内容都是与软件架构师的相关

21、的话题。系统 架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。系统架构师要求通晓软、硬件两方面的知识，所以它的知识体系相对 庞杂。关于系统架构师的话题，我们可以稍后再作讨论。2 架构师的职责架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。架构师主要职责有4条：1、确认需求在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。2、系统分解依据用户需求，架构师将系

22、统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。软件架构师的功力基本体现于此，这是一项相对复杂的工作。3、技术选型架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。架构师对

23、产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。4、制定技术规格说明架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。架构师与开发者沟通的最重要的形式是技术规格说明书，它可以是UML视图、Word文档，Visio文件等各种表现形式。通过架构师提供的技术规格说明书，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。架构师不仅要保持与开发者的沟通，也需要与项目经理

24、、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。3 架构师的误区1、架构师就是项目经理架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作，具备管理职能。一般小型项目中，常见项目经理兼架构师。2、架构师负责需求分析架构师不是需求分析员。需求分析人员的工作是收集需求和分析需求，并与最终用户、产品经理保持联系。架构师只对最终的需求审核和确认，提出需求不清和不完整的部分，他会跟需求分析员时刻保持联系。架构师是技术专家，不是业务专家。3、架构师从来不写代码这是一个尚存争论的问题。目前有两种观点：观点1：架

25、构师不写代码，写代码纯体力活，架构师写代码大材小用。架构师把UML的各种视图交给开发人员，如果有不明确的地方，可以与架构师随时沟通。观点2：架构师本来自于程序员，只是比程序员站的层面更高，比程序员唯一多的是经验和知识，所以架构师也免不了写代码。我个人觉得这两种说法是与架构师的出身和所处的环境有关。架构师首先是一个技术角色，所以一定是来自于技术人员这个群体，比如系统架构师，多是来自于运维人员，可能本身代码写得并不多，或者说写不出来 很漂亮的代码。软件架构师多是来自于程序员，有着程序员的血统和情怀，所以在项目开发过程中，可能会写一些核心代码。我们的理想是架构师不用写代码，但事 实上有时候过于理想。架构师写不写代码，可能取决于公司的规模、文化、开发人员的素质等现实情况。另外，架构师也不是跟程序员界限分得那么清楚，按照能力 也有高中低之分，写不写代码不是区分两者的根本标准。4 架构师的基本素质周星驰有个片子喜剧之王，剧中的尹天仇整天揣着本演员的自我修养，一个好演员不仅需要天赋，也需要一定的理论指导，无师自通的人毕竟是 少数。架构师的成长过程也是这样。从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程。经验积累是一个方面，素质培养是另一个方面， 两者相辅相成，所以我觉得有必要把架构师的所要具备的素质罗列一下，作为程序员努力的方向。沟通能力为了提高效率，架构师必须