架构师之路---面向过程和面向对象

架构师之路(1)---面向过程和面向对象王泽宾收藏

1、引言

机算机科学是一门应用科学，它的知识体系是典型的倒三角结构，所用的基础知识并不多，只是随着应用领域和方向的不同，产生了很多的分支，所以说编程并不是一件很困难的事情，一个高中生经过特定的训练就可以做得到。但是，会编程和编好程绝对是两码事，同样的程序员，有的人几年之后成为了架构师，有的人却还在不停地coding，只不过ctrl-c、ctrl-v用得更加纯熟了。在中国，编程人员最终的归途无外乎两条：一是转向技术管理，它的终点是CTO；二是继续深入，它的终点是首席架构师，成为CEO的人毕竟是少数。如果你现在还是个普通的程序员，希望继续在技术这条路上前进的话，我想你还是应该先补充一点软件工程的思想，学习一点有关设计模式的知识，只有具备这些能力，你才能从整体和宏观层面来考虑问题、分析问题和解决问题。本人Coding了很多年，中间走了不少弯路，虽然最终没什么大成就，但总算有一些心得，很愿意把自己的一些经验拿出来跟大家分享，这或许对你的发展有所帮助。

由程序员转为架构师，最绕不开的概念就算是面向对象(OO)了。记得在大学的时候，我们专业开了一门课叫《面向对象的编程》。那个时候，我们刚刚学了一门C语言，开发环境用的还是DOS下的Turbo C，半点项目开发的经验都没有，纯粹的空对空。所以，一学期下来，我始终处于一种懵懂状态，既没领会面向过程和面向对象到底有什么区别，也没搞懂面向对象能带来什么好处。

2、面向过程(OP)和面向对象(OO)

2.1 蛋炒饭和盖浇饭

有人这么形容OP和OO的不同：用面向过程的方法写出来的程序是一份蛋炒饭，而用面向对象写出来的程序是一份盖浇饭。所谓盖浇饭，北京叫盖饭，东北叫烩饭，广东叫碟头饭，就是在一碗白米饭上面浇上一份盖菜，你喜欢什么菜，你就浇上什么菜。我觉得这个比喻还是比较贴切的。

蛋炒饭制作的细节，我不太清楚，因为我没当过厨师，也不会做饭，但最后的一道工序肯定是把米饭和鸡蛋混在一起炒匀。盖浇饭呢，则是把米饭和盖菜分别做好，你如果要一份红烧肉盖饭呢，就给你浇一份红烧肉；如果要一份青椒土豆盖浇饭，就给浇一份青椒土豆丝。

蛋炒饭的好处就是入味均匀，吃起来香。如果恰巧你不爱吃鸡蛋，只爱吃青菜的话，那么唯一的办法就是全部倒掉，重新做一份青菜炒饭了。盖浇饭就没这么多麻烦，你只需要把上面的盖菜拨掉，更换一份盖菜就可以了。盖浇饭的缺点是入味不均，可能没有蛋炒饭那么香。

到底是蛋炒饭好还是盖浇饭好呢？其实这类问题都很难回答，非要比个上下高低的话，就必须设定一个场景，否则只能说是各有所长。如果大家都不是美食家，没那么多讲究，那么从

饭馆角度来讲的话，做盖浇饭显然比蛋炒饭更有优势，他可以组合出来任意多的组合，而且不会浪费。

2.2 软件工程

盖浇饭的好处就是“菜”“饭”分离，从而提高了制作盖浇饭的灵活性。饭不满意就换饭，菜不满意换菜。用软件工程的专业术语就是“可维护性”比较好，“饭”和“菜”的耦合度比较低。蛋炒饭将“蛋”“饭”搅和在一起，想换“蛋”“饭”中任何一种都很困难，耦合度很高，以至于“可维护性”比较差。软件工程追求的目标之一就是可维护性，可维护性主要表现在3个方面：可理解性、可测试性和可修改性。面向对象的好处之一就是显著的改善了软件系统的可维护性。

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

以OO为例，对应于软件开发的过程，OO衍生出3个概念：OOA、OOD和OOP。采用面向对象进行分析的方式称为OOA，采用面向对象进行设计的方式称为OOD，采用面向对象进行编码的方式称为OOP。面向过程(OP)和面向对象(OO)本质的区别在于分析方式的不同，最终导致了编码方式的不同。

2.3 面向过程(OP)和面向对象(OO)

2.3 面向过程编程(OPP) 和面向对象编程(OOP)的关系

关于面向过程的编程(OPP)和面向对象的编程(OOP),给出这它们的定义的人很多，您可以从任何资料中找到很专业的解释，但以我的经验来看，讲的相对枯燥一点，不是很直观。除非您已经有了相当的积累，否则说起来还是比较费劲。

我是个老程序员出身，虽然现在的日常工作更多倾向了管理，但至今依然保持编码的习惯，这句话什么意思呢？我跟大家沟通应该没有问题。无论你是在重复我走过的路，或者已经走在了我的前面，大家都会有那么一段相同的经历，都会在思想层面上有一种理解和默契，所以我还是会尽量按照大多数人的常规思维写下去。

面向过程的编程(OPP)产生在前，面向对象的编程(OOP)产生在后，所以面向对象的编程(OOP)一定会继承前者的一些优点，并摒弃前者存在的一些缺点，这是符合人类进步的自然规律。两者在各自的发展和演变过程中，一定会相互借鉴，相互融合，吸收对方的优点，从而出现某些方面的趋同性。但是，即使两者有更多的相似点，也不会改变它们本质上

的不同，因为它们的出发点不同，完全是两种截然不同的思维方式。关于两者的关系，我的观点是这样的：面向对象编程(OOP)在局部上一定是面向过程(OP)的，面向过程的编程(O PP)在整体上应该借鉴面向对象(OO)的思想。这一段说的的确很空洞，而且也一定会有引来争议，不过，我劝您还是在阅读了后面的内容之后，再来评判我观点的正确与否。

象C++、C#、Java等都是面向对象的语言，c,php(暂且这么说，因为php4以后就支持OO)都是面向过程的语言，那么是不是我用C++写的程序一定就是面向对象，用c 写的程序一定就是面向过程呢？这种观点显然是没有真正吃透两者的区别。语言永远是一种工具，前辈们每创造出来的一种语言，都是你用来实现想法的利器。我觉得好多人用C#,J ava写出来的代码，要是仔细看看，那实际就是用面向对象(OO)的语言写的面向过程(OP)的程序。

所以，即使给关羽一根木棍，给你一杆青龙偃月刀，他照样可以打得你满头是包。你就是扛着个偃月刀，也成不了关羽，因为你缺乏关羽最本质的东西---绝世武功。同样的道理，如果你没有领会OO思想，怎么可能写得出真正的OO程序呢？

那是不是面向过程就不好，也没有存在的必要了？我从来没有这样说过。事实上，面向过程的编程(OPP)已经存在了几十年了，现在依然有很多人在使用。它的优点就是逻辑不复杂的情况下很容易理解，而且运行效率远高于面向对象（OO）编写的程序。所以，系统级的应用或准实时系统中，依然采用面向过程的编程(OPP)。当然，很多编程高手以及大师级的人物，他们由于对于系统整体的掌控能力很强，也喜欢使用面向过程的编程(OPP)，比如像Apache,QMail,PostFix,ICE等等这些比较经典的系统都是OPP的产物。象php这些脚本语言，主要用于web开发，对于一些业务逻辑相对简单的系统，也常使用面向过程的编程(OPP)，这也是php无法跨入到企业级应用开发的原因之一，不过php5目前已经能够很好的支持OO了。

2.4 详解面向过程的编程(OPP)

在面向对象出现之前，我们采用的开发方法都是面向过程的编程(OPP)。面向过程的编程中最常用的一个分析方法是“功能分解”。我们会把用户需求先分解成模块，然后把模块分解成大的功能，再把大的功能分解成小的功能，整个需求就是按照这样的方式，最终分解成一个一个的函数。这种解决问题的方式称为“自顶向下”，原则是“先整体后局部”，“先大后小”，也有人喜欢使用“自下向上”的分析方式，先解决局部难点，逐步扩大开来，最后组合出来整个程序。其实，这两种方式殊路同归，最终都能解决问题，但一般情况下采用“自顶向下”的方式还是较为常见，因为这种方式最容易看清问题的本质。

我举个例子来说明面向过程的编程方式:

用户需求：老板让我写个通用计算器。

最终用户就是老板，我作为程序员，任务就是写一个计算器程序。OK，很简单，以下就是用C语言完成的计算器：

假定程序的文件名为：main.c。

int main(int argc, char *argv[]){

//变量初始化

int nNum1,nNum2;

char cOpr;

int nResult;

nNum1 = nNum2 = 0;

cOpr = 0;

nResult = 0;

//输入数据

printf("Please input the first number:\r\n");

scanf("%d",&nNum1);

printf("Please input the operator:\r\n");

scanf("%s",&cOpr);

printf("Please input the second number:\r\n");

scanf("%d",&nNum2);

//计算结果

if( cOpr == '+' ){

nResult = nNum1 + nNum2;

}else if( cOpr == '-' ){

nResult = nNum1 - nNum2;

}else{

printf("Unknown operator!");

return -1;

}

//输出结果

printf("The result is %d!",nResult);

return 0;

}

抛开细节不讲，我想大多数人差不多都会这么实现吧，很清晰，很简单，充分体现了“简单就是美”的原则，面向过程的编程就是这样有条理的按照顺序来逐步实现用户需求。

凡是做过程序的人都知道，用户需求从来都不会是稳定的，最多只能够做到“相对稳定”。用户可能会随时提出加个功能，减个功能的要求，也可能会要求改动一下流程，程序员最烦的就是频繁地变动需求，尤其是程序已经写了大半了，但这种情况是永远无法避免的，也不能完全归罪到客户或者需求分析师。

以我们上面的代码为例，用户可能会提出类似的要求：

首先，你程序中实现了“加法”和“减法”，我还想让它也能计算“乘法”、“除法”。

其次，你现在的人机界面太简单了，我还想要个Windows计算器的界面或者Mac计算器的界面。

用户需求开始多了，我得琢磨琢磨该如何去写这段代码了。我今天加了“乘”“除”的运算，明天保不齐又得让我加个“平方”、“立方”的运算，这要是把所有的运算都穷尽了，怎么也得写个千八百行代码吧。还有，用户要求界面能够更换，还得写一大堆界面生成的代码，又得来个千八百行。以后，这么多代码堆在一起，怎么去维护，找个变量得半天，看懂了代码得半天，万一不小心改错了，还得调半天。另外，界面设计我也不擅长，得找个更专业的人来做，做完了之后再加进来吧。这个过程也就是“软件危机”产生的过程。伴随着软件广泛地应用于各个领域，软件开发的规模变得越来越大，复杂度越来越高，而其用户的需求越来越不稳定。

根据用户提出的两个需求，面向过程的编程该如何去应对呢？我想大家都很清楚怎么去改。Very easy，把“计算”和“界面”分开做成两个独立的函数，封装到不同的文件中。假定程序的文件名为：main.c。

#include "interface.h"

#include "calculate.h"

int main(int argc, char *argv[]){

//变量初始化

int nNum1,nNum2;

char cOpr;

int nResult;

nNum1 = nNum2 = 0;

cOpr = 0;

nResult = 0;

//输入数据

if( getParameters(&nNum1,&nNum2,&cOpr) == -1 )

return -1;

//计算结果

if( calcMachine(nNum1,nNum2,cOpr,&nResult) == -1 )

return -1;

//输出结果

printf("The result is %d!",nResult);

return 0;

}

interface.h:

int getParameters(int *nNum1,int * nNum2,char *cOpr);

interface.c:

int getParameters(int *nNum1,int * nNum2,char *cOpr){

printf("Please input the first number:\r\n");

scanf("%d",nNum1);

printf("Please input the operator:\r\n");

scanf("%s",cOpr);

printf("Please input the second number:\r\n");

scanf("%d",nNum2);

return 0;

}

calculate.h:

int calcMachine(int nNum1,int nNum2,char cOpr, int *nResult);

calculate.c:

int calcMachine(int nNum1,int nNum2,char cOpr,int *nResult){ if( cOpr == '+' ){

*nResult = nNum1 + nNum2;

}else if( cOpr == '-' ){

*nResult = nNum1 - nNum2;

}else{

printf("Unknown operator!");

return -1;

};

return 0;

}

“计算”和“界面”分开之后，添加新功能或者修改bug就方便多了，遇到与“计算”相关的需求就去修改calculate模块，遇到与“界面”相关的需求就去修改interface模块，因此，整个系统模块之间的“耦合度”就被放松了，可维护性有了一定程度的改善。

面向过程的编程(OPP)就是将用户需求进行“功能分解”。把用户需求先分解成模块(.h,.

c)，再把模块(.h,.c)分解成大的功能(function)，然后把大的功能(function)分解成小的功能(function)，如此类推。

功能分解是一项很有技术含量的工作，它不仅需要分解者具有丰富的实战经验，而且需要科学的理论作为指导。如何分解，分解原则是什么，模块粒度多大合适？这些都是架构师的要考虑的问题，也是我们后面要着重讲的内容。

面向过程的编程(OPP)优点是程序顺序执行，流程清晰明了。它的缺点是主控程序承担了太多的任务，各个模块都需要主控程序进行控制和调度，主控和模块之间的承担的任务不均衡。

有的人把面向过程定义为：算法+ 数据结构，我觉得也很准确。面向过程的编程中算法是核心，数据处于从属地位，数据随算法而流动。所以采用面向过程的方式进行编程，一般在动手之前，都要编写一份流程图或是数据流图。

--------------------------------------------------------

如果大家对本文有意见尽可争论，欢迎大家随时拍砖。我有着钢铁一样的心脏和城墙一样的脸皮，承受能力极强，所以无论是支持意见还是反对反对意见，我都会认真阅读，只要不是色情淫秽和反动言论，我尽量不删贴。如果碰到不能理解或者错误之处，请指出，我会进行验证和修改。由于个人能力和时间有限，也只能写到这样的水平了，大家谅解。有的朋友找我的qq号，我的资料里就有，加为好友后就可以看到，我的qq对任何人开放

3 架构师的职责

近来看到CSDN上有个CTO俱乐部，里面聊得是不亦乐乎。我怀着无比崇敬的态度，拜读了一下牛人们的发言。里面有个哥们发起一个话题：“CTO, 你多久没有写程序了？”。有人回答：“不写代码的CTO,属于......这公司问题大了!”。看到这里，我就赶紧撤了，怕忍不住反驳几句，反而遭到牛人们的群殴。试想，一个上点规模的IT公司，还得靠CTO 来写程序的话，那是不是才叫问题大了呢。当然，我没有做过CTO，所以我有我的不同看法，而且还愿意表达出来，无知者无畏。我情愿相信：我所理解的CTO跟这位CTO所理解的是两回事。所以我想，如果有人能把CTO的职责给标准化了，也许就不会有这么多的争论了。

同样的道理，关于架构师的定义，大家也有着不同的理解。什么是架构师？架构师有哪些职责？我觉得有必要提前明确一下，要不然大家沟通起来也会产生类似问题，子说子理，卯说卯理，但是压根说得不是一码子事。

3.1 什么是架构师

曾经有这么个段子：

甲：我已经应聘到一家中型软件公司了，今天上班的时候，全公司的人都来欢迎我。

乙：羡慕ing，都什么人来了？

甲：CEO、COO、CTO、All of 程序员，还有会计、司机都来了。

乙：哇，他们太重视你了，人才啊，这么多人迎接你！

甲：没有啊，就一个人！

乙：靠，#%￥$%...

3.5 详解面向对象的编程(OOP)

3.5.1 什么是面向对象

刚接触编程的时候，多数人本能的反映可能是面向过程(OP)的，而不是面向对象(OO)的。这种现象其实是很正常的，改变思维方式是需要一个过程的，我大体归纳了一下其形成的原因：

1、直接原因

你还没有养成面向对象分析问题和解决问题的习惯。建立面向对象的思维方式需要一定时间的训练和揣摩才能形成，所以你可以在学习或具体项目中刻意地强化这种意识。一般情况下，经过一段时间之后，你会觉得这是自然而然的事情，只有心中OO，眼中自然OO了。

2、历史原因

我们从小接受的培训都是采用面向过程(OP)的方式分析问题和解决问题，尤其是数学，多数是强调按部就班的解决问题，计算机软件的发展一直就与数学是很有渊源，所以，顺理成章的，把面向过程(OP)的方式带入到软件开发也是很自然的事情。

什么是面向对象，或者谈谈你对面向对象的理解，这恐怕是软件开发人员，尤其是程序员和设计师应聘的时候，面试官常最挂在嘴边的问题吧。面向对象对应的英文是Object-O riented，把Object-Oriented翻译成“面向对象”，我一直觉得这个译法不太确切，因为多数人第一次看到“面向对象”这四个字，都很难从字面上理解它到底是什么意思。后来，我又查阅了一些有关的资料，发现港澳台的计算机书籍中是把它翻译成了“物件导向”，这个译法，我感觉不错，于我心颇有些戚戚焉。“物件导向”比较准确地反映了面向对象认识和解决问题都是要围绕对象展开的。

所以，面向对象的思维方式认为：软件系统是一组交互的对象的集合。一组相关的对象组合为一个子系统，一组子系统继续组合为更复杂的子系统，直至组合成整个系统。

面向对象方式的出发点是尽可能模拟人类习惯的思维方式，将“问题域”中涉及的内容抽象为“对象”，使软件开发的方法与过程尽可能接近人类认识世界解决问题的方法与过程。

面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使

用的时候一个一个依次调用就可以了。面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。

面向过程认识和解决问题的思维，可以称为“流程论”，重点放在处理过程的步骤，流程是整个系统的核心。

面向对象认识和解决问题的思维，可以称为“组装论”，重心放在对象的抽象和提取上，然后将对象组装为整体。

所以OO和OP从思维方式来讲，出发点还是完全不同的。

3.5.2 OP PK OO

咱们用象棋对战的例子，来比较OP和OO的不同：

红方：功夫熊猫黑方：悍娇虎裁判：龟仙人

采用面向过程(OPP)的设计思路，首先分拆整个对战过程，分析双方对战的步骤，得到如下流程：

把上面每个步骤分别用函数进行实现，问题就解决了。

我们再来看看面向对象是如何来解决问题，整个象棋游戏可以抽象出3种对象：

1、棋手，负责行棋，这两者行为一致。

2、棋盘，负责绘制棋盘画面。

3、裁判，负责判定诸如吃子、犯规和输赢。

三者之间的关系如下：

第一类对象棋手负责行棋，并告知第二类对象棋盘中棋子布局的变化，棋盘接收到了棋子布局的变化后，负责在绘制屏幕，同时利用第三类对象裁判来对棋局进行判定。

从以上两种的实现方式可以看出几点：

1、可维护性

面向对象是以数据和功能来划分问题，而不是依据流程和步骤。同样是绘制棋盘的行为，在面向过程的设计中分散在了很多的步骤中，很可能出现在不同的绘制版本中，只是不是很像一份“蛋炒饭”中的鸡蛋？在面向对象的设计中，绘图只可能在棋盘对象中出现，从而保证了绘图的统一，这就是把鸡蛋从“蛋炒饭”中分离出来的效果。

2、可扩展性

假如我要加入悔棋的功能，如果要改动面向过程的设计，那么从行棋到显示再到判定这一连串的步骤都要改动，甚至步骤之间的循序都要进行大规模调整。如果是面向对象的话，只用改动棋盘对象就行了，棋盘对象保存了双方的棋谱，简单回溯，减一就可以了，而显示和判定不涉及，同时整体对各个对象功能的调用顺序都没有变化，改动只限定在了局部。

3.5.3 OO的深层思考

OO认为：软件系统是一组交互的对象的集合。

因为人类对现实世界是非常熟悉的，所以OO就是通过抽象的方式，把问题域映射到现实世界，尽量模拟现实世界的万事万物。通过这种方式，就可以运用现实世界中解决问题的方法与过程，来解决软件领域内的问题。

有人说：OO眼里一切皆对象，这句话还是很有道理的。

OO到底给软件开发带来了什么样的好处？OO的抽象的尺度是如何把握的呢？这都是问题。

很多的创业公司，一人身兼数职的情形还是很常见的。至少，我是经历过的，一个人包办了所有的开发过程，连测试我都做了，绝对的一条龙，但是经常踩钢丝、骑独轮车总会有失足的时候，结果有一次，从我手里发出去的光盘母盘，含有病毒僵尸，以至于被迫收回已经推上市场的2万张光盘，从那之后，我的心脏就开始变得无比坚强，现在就是整个后台服务都瘫痪了，我也只是微微一笑。其实，一个人身兼架构师和程序员，甚至多种角色，没什么不妥，后面还会讲这个话题，这种现象不是中国特色，跟国外是完全接轨的。我曾经跟米国的一个工程师在msn中聊过类似的话题，发现他们的路子跟咱们没什么不同，在IT

这个行业，我们跟世界的差距只有1天，他们刚弄出来的新东西，我们这里第2天保准见得到。

架构师这个称呼不是拍脑袋想出来的，是有国际标准（ISO/IEC 42010）可查的。架构师是软件开发活动中的众多角色之一，它可能是一个人、一个小组，也可能是一个团队。微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：企业架构师EA(E nterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构T SA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。微软的这个分类是按照架构师专注的领域不同而划分的。

EA的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title就是首席软件架构师，网易丁磊也喜欢这么称呼自己，实际上就是EA角色；IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一；特定技术架构师TSA，他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作；SA的工作则专于解决方案的规划和设计，“解决方案”这个词在中国已经到了严重泛滥的程度，大忽悠们最喜欢把它挂在嘴边。所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。售前工程师一般都是带着它到客户那里去发挥的。

大公司会把各种类型的架构师分得很清楚，小公司一般就不那么讲究了，架构师多数是是IA+TSA+SA，一人包打天下，所以说大公司出专才，小公司出全才。

实际工作中，我们也经常会见到另一种比较简单的分类方式，把架构师分为软件架构师和系统架构师。软件架构师基本上是TSA+IA，这也是程序员最容易突破，最可能走上的一条道路，比如JAVA架构师、DotNet架构师、LAPM架构师等等，我后面所讲的内容都是与软件架构师的相关的话题。系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。系统架构师要求通晓软、硬件两方面的知识，所以它的知识体系相对庞杂。关于系统架构师的话题，我们可以稍后再作讨论。

3.2 架构师的职责

架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。

架构师主要职责有4条：

1、确认需求

在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。

2、系统分解

依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层

或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。

软件架构师的功力基本体现于此，这是一项相对复杂的工作。

3、技术选型

架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。

Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mys ql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。

架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。

4、制定技术规格说明

架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。

架构师与开发者沟通的最重要的形式是技术规格说明书，它可以是UML视图、Word 文档，Visio文件等各种表现形式。通过架构师提供的技术规格说明书，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。

架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

3.3 架构师的误区

1、架构师就是项目经理

架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作，具备管理职能。一般小型项目中，常见项目经理兼架构师。

2、架构师负责需求分析

架构师不是需求分析员。需求分析人员的工作是收集需求和分析需求，并与最终用户、产品经理保持联系。架构师只对最终的需求审核和确认，提出需求不清和不完整的部分，他会跟需求分析员时刻保持联系。架构师是技术专家，不是业务专家。

3、架构师从来不写代码

这是一个尚存争论的问题。目前有两种观点：

观点1：架构师不写代码，写代码纯体力活，架构师写代码大材小用。架构师把UML的各种视图交给开发人员，如果有不明确的地方，可以与架构师随时沟通。

观点2：架构师本来自于程序员，只是比程序员站的层面更高，比程序员唯一多的是经验和知识，所以架构师也免不了写代码。

我个人觉得这两种说法是与架构师的出身和所处的环境有关。

架构师首先是一个技术角色，所以一定是来自于技术人员这个群体，比如系统架构师，

多是来自于运维人员，可能本身代码写得并不多，或者说写不出来很漂亮的代码。软件架构师多是来自于程序员，有着程序员的血统和情怀，所以在项目开发过程中，可能会写一些核心代码。我们的理想是架构师不用写代码，但事实上有时候过于理想。架构师写不写代码，可能取决于公司的规模、文化、开发人员的素质等现实情况。另外，架构师也不是跟程序员界限分得那么清楚，按照能力也有高中低之分，写不写代码不是区分两者的根本标准。

3.4 架构师的基本素质

周星驰有个片子《喜剧之王》，剧中的尹天仇整天揣着本《演员的自我修养》，一个好演员不仅需要天赋，也需要一定的理论指导，无师自通的人毕竟是少数。架构师的成长过程也是这样。从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程。经验积累是一个方面，素质培养是另一个方面，两者相辅相成，所以我觉得有必要把架构师的所要具备的素质罗列一下，作为程序员努力的方向。

1、沟通能力

为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师具有较强的沟通能力。沟通能力是人类最普遍性的素质要求，技术人员好像容易忽略，想成为架构师就不能忽略。千万不要抱着这样的观念：怀才跟怀孕似的，时间久了总会被人发现的。还是天桥上卖大力丸的哥们说得对：光说不练假把式，光练不说傻把式。看看你周围的头头脑脑们，哪一个不是此中高手，我们千万不要鄙视，认为这是阿谀奉承、投机钻营，凡事都要看到积极的一面，“沟通”的确是一种能力。我认为自己是一个略内向的人，因为我是农村出来的孩子，普通话都说不好，以前或多或少带有点自卑感，幻想着是金子总会发光，所以在职业生涯中吃了不少亏。现在，我深深懂得了沟通的重要性，我会很主动地跟同事们，跟老大们不定时地沟通，感觉工作起来顺畅多了。

这一条我认为最为重要，所以排在首位。我甚至认为下面几条都可以忽略，唯一这一条得牢记，而且要常常提醒自己。

2、领导能力

架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。架构师如何来保证这种执行力？这就需要架构师具有领导能力。

架构师的领导能力的取得跟项目经理不太一样。项目经理主要负责解决行政管理，这种能力与技术关系不大，他有人权和财权，再扯上一张“领导”的虎皮，采用“胡萝卜加大棒”的方式，基本上可以保证执行力。架构师在项目里面可能更多地使用非正式的领导力，也就是我们常说的影响力，里面包括个人魅力、技术能力、知识传递等等。

3、抽象思维和分析能力

架构师必须具备抽象思维和分析的能力，这是你进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局，这也是架构师大局观的形成基础。你如何具备这种能力呢？一是来自于经验，二是来自于学习。架构师不仅要具备在问题领域上的经验，也需要具备在软件工程领域内的经验。也就是说，架构师必须能够准确得理解需求，然后用软件工程的思想，把需求转化和分解成可用计算机语言实现的程度。经验的积累是需要一个时间过程的，这个过程谁也帮不了你，是需要你去经历的。但是，如果你

有意识地去培养，不断吸取前人的经验的话，还是可以缩短这个周期的。这也是我写作此系列的始动力之一。

4、技术深度和广度

架构师最好精通1-2个技术，具备这种技术能力可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。

架构师的技术知识广度也很重要，需要了解尽可能多的技术，所谓见多识广，只有这样，才可能综合各种技术，选择更加适合项目的解决方案。有的人说，架构师技术广度的要求高于技术深度的要求，这是很有道理的。

总而言之，一句话：架构师是项目团队中的技术权威。

面向过程和面向对象这两个基本概念，不仅架构师需要非常清楚，程序员、设计师也要非常清楚，这也是系统分析、设计和编码最基本的常识。我接触的程序员，很多人只停留在一种“似是而非”的程度，这是不行的，想要继续前进，就得把基础夯实，所以我觉得很有必要先回回炉，补补课。

架构师之路(5)---面向对象的设计原则王泽宾收藏

1 OO的设计原则

我们已经知道：面向对象的思维，为我们分析问题和解决问题提供了一种全新的方式。接下来的问题是：我们如何进行面向对象的设计呢？

在软件工程中，人们依据以往的经验，总结了五个面向对象（其实远不止）的常见而且简单的设计原则。它们是我们进行面向对象设计的基本依据：

1、单一职责原则SRP

对于一个类，它应该只专注于做一件事和仅有一个引起它变化的原因。

2、“开-闭”原则OCP

应当能够改变一个类的环境，而无须改变类本身。

3、里氏代换原则LSP

避免造成派生类的方法非法或退化，一个基类的用户应当不需要知道这个派生类。

4、依赖倒转原则DIP

用依赖于接口和抽象类来替代依赖容易变化的具体类。

5、接口隔离原则ISP

给一个对象的每一个用户一个接口，这个接口仅有用户需要的方法。

其中，“开-闭”原则是面向对象的可复用设计的基石，其他设计原则（里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则）是实现“开-闭”原则的手段和工具。

我会为大家一一进行讲解。

2 单一职责原则SRP(Single-Responsibility Principle)

2.1 什么是单一职责

单一职责就是指一个类应该专注于做一件事。现实生活中也存在诸如此类的问题：“一个人可能身兼数职，甚至于这些职责彼此关系不大，那么他可能无法做好所有职责内的事情，所以，还是专人专管比较好。”我们在设计类的时候，就应该遵循这个原则：单一职责。

我们以计算器编程为例：

在有些人眼里，计算器就是一件东西，是一个整体，所以它把这个需求进行了抽象，最终设计为一个Calculator类，代码如下：

class Calculator{

public String calculate() {

Console.Write("Please input the first number:");

String strNum1 = Console.ReadLine();

Console.Write(Please input the operator:");

String strOpr= Console.ReadLine();

Console.Write("Please input the second number:");

String strNum2 = Console.ReadLine();

String strResult = "";

if (strOpr == "+"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.To Double(strNum2));

}

else if (strOpr == "-"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) - Convert.To Double(strNum2));

}

else if (strOpr == "*"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.To Double(strNum2));

}

else if (strOpr == "/"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.To

Double(strNum2));

}

Console.WriteLine("The result is " + strResult);

}

}

另外，还有一部分人认为：计算器是一个外壳和一个处理器的组合。

class Appearance{

public int displayInput(String &strNum1,String &strOpr, String &strNum2) {

Console.Write("Please input the first number:");

strNum1 = Console.ReadLine();

Console.Write(Please input the operator:");

strOpr= Console.ReadLine();

Console.Write("Please input the second number:");

strNum2 = Console.ReadLine();

return 0;

}

public String displayOutput(String strResult) {

Console.WriteLine("The result is " + strResult);

}

}

class Processor{

public String calculate(String strNum1,String strOpr, String strNum2){ String strResult = "";

if (strOpr == "+"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.To Double(strNum2));

}

else if (strOpr == "-"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) - Convert.To Double(strNum2));

}

else if (strOpr == "*"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.To Double(strNum2));

}

else if (strOpr == "/"){

strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.To Double(strNum2));

}

return strResult;

}

}

为什么这么做呢？因为外壳和处理器是两个职责，都是很容易发生需求变动的因素，所以把他们放到一个类中，违背了单一职责原则。

比如，用户可能对计算器提出以下要求：

第一，目前已经实现了“加法”、“减法”、“乘法”和“除法”，以后还可能出现“乘方”、“开方”等很多运算。

第二，现在人机界面太简单了，还可能做个Windows计算器风格的界面或者Mac计算器风格的界面。

所以，把一个类Calculator 拆分为两个类Appearance和Processor，更容易应对需求变化。如果界面需要修改，那么就去修改Appearance类；如果处理器需要修改，那么就去修改Processor类。

2.2 单一职责原则的使用

单一职责原则的尺度如何掌握呢？我怎么能知道该拆分还是不应该拆分呢？原则很简单：需求决定。如果你所需要的计算器，永远都没有外观和处理器变动的可能性，那么就应该把它抽象为一个整体的计算器；如果你所需要的计算器，外壳和处理器都有可能发生变动，那么就必须把它拆离为外壳和处理器。只能有一个原因可能引起计算器的变化。

单一职责原则把相同的职责进行聚合，避免把相同的职责分散到不同的类之中，这样就可以控制变化，把变化限制在一个地方，防止因为一个地方的变动，引起更多地方的变动的“涟漪效应”。单一职责原则实际上消除了对象之间的耦合，避免一个类承担过多的职责。单一职责不是说一个类就只有一个方法，而是单一功能。

我们在使用单一职责原则的时候，牢记以下几点：

A、一个设计合理的类，应该仅有一个可以引起它变化的原因，即单一职责，如果有多个原因可以引起它的变化，就必须进行分离；

B、在没有需求变化征兆的情况下，应用SRP或其他原则是不明智的，因为这样会使系统变得很复杂，系统由一堆细小的颗粒组成，这纯属于没事找抽；

C、在需求能够预计或实际发生变化时，就应该使用SRP原则来重构代码，有经验的设计师、架构师对可能出现的需求变化很敏感，设计上就会具有前瞻性。

面向对象程序设计与面向过程程序设计的区别

面向过程程序设计和面向对象程序设计的区别 面向过程程序设计我个人的理解简单来说，他考虑问题的方式是面向流程的，一个程序的设计思路就是解决一个问题的流程。就好比游戏先登入界面，再输入密码，然后选择角色，在然后进入游戏玩耍，结束... .... 这把这些步样就是面向过程。面向过程就是分析出解决问题所需要的步骤，然后用函数骤一步调用就可以了一步实现，使用的时候一个一个依次。可以看出面向过程化程序设计是先确定算法，再确定数据结构。而面向对象程序设计是面向问题中的各种独立个体的，程序的析设分计过程就是将程序分解成不同对象（不同概念体）之间的交互的过程。这就好比在针对某个工程或游戏设计程序时先不考虑，游戏是怎么玩的，工作是怎么做的，而先会去找，游戏或工程中有哪些人或事物参与（一般选择：用户，玩家，角色等等），然后再看他们都有什么用，都干了些什么，针对这个区设计方法。最后在通过这些千丝万缕的联系把他们分门别类的，组装在一起。可以看出面向过程化程序设计是先确定数据结构再确定算法。 从上面很容易看出，面向过程的程序上一步和下一步环环相扣，他只考虑实现客户的需求不考虑以后扩展，如果以后客户的需求有变化那代码量要改变非常大耗费的时间也相当多。从本质上说，面向过程基本上是一种状态机，不利于修改，当新状态出现的时候，甚至可能需要重设每一个状态解决实现。所以说面向过

程是一种直接的编程方法，它是按照编程语言的思路考虑问题。尤其是想C语言这种过程式语言，它就是通过顺序执行一组语句来实现一个功能，这些语句的执行过程就是整个程序。不同的语言解决同一个问题的过程是不一样的。 而面向对象的程序设计很多东西都是独立的，每个对象都可以重复使用。而面向对象程序设计强调“封装”，“继承“和“多态”。数据和与数据相关的操作被包装成对象（严格的说是“类”），每一种对象是相对完整和独立的。对象可以有派生的类型，派生的类型可以覆盖（或重载）原本已有的操作。所有的这些，是为了达成更好的内聚性，即一种对象做好一件（或者一类相关的）事情，对象内部的细节外面世界不关心也看不到；以及降低耦合性，即不同种类的对象之间相互的依赖尽可能降低。而所有的这些，都有助于达成一个崇高的目标，就是可复用性。 下面举个例子来说明面向过程的程序和面向对象的程序设计的区别： 用面向过程的思想去考虑它应该是这样的：如何启动汽车、如何起步、加速、刹车、熄火等一个个操作。面向过程是把所有的功能全部在一个大的类里定义出来，当系统庞大时，功能多了，各种操作之间的调用关系也很复杂，当需要修改一个功能时就可能引发一连串的改动，使修改和维护成本增加，而不利于修改。 而面向对象则以汽车为对象，一切由汽车开始，以上的可用操

面向对象与面向过程程序设计方法的比较

面向对象与面向过程程序设计方法的比较摘要：区别于一般讲述面向对象技术的文章，本文系统地比较了面向对象技术和面向过 程技术的异同，并着重介绍面向对象技术以及它的封装、继承和多态三个特点，让读者对面向对象有一个形象的理解。然后通过比较和举例，文章分析了OO技术在软件工程中的三大优势。 Abstract：Being different from general articles about object-oriented technology , this paper systematically compared the object-oriented technology and the process-oriented technology, and mainly introduces the object-oriented technology and its three characteristics :packaging, inheritance and polymorphism, to make the reader have an image of understanding of object-oriented. Then through the comparison and some examples, this paper analyzes the OO based software engineering in three points. 关键字：面向对象面向过程软件工程 Key words：Object-Oriented Process-Oriented Software-Engineering 一引言 20世纪60年代中期开始爆发的软件危机，使人们认识到大中型软件系统与小型软件系统的本质区别，软件工程以及面向对象编程（Object-Oriented Programming）技术得以应运而生。从最初的SIMULA到如今的C++、JAVA和C#，面向对象程序设计语言已发展为当前最流行的程序设计语言。 谈到面向对象，一个不能回避的问题是面向过程的程序设计思想。作为一种常用的面向对象语言，C++自C语言发展而来，是一种混合型面向对象的程序设计语言，它既支持面向对象又支持面向过程。面向对象与面向过程虽然在设计理念上截然相反，前者是自底向上而后者是自顶向下的，但它俩仍有众多的相似之处。只有建立在深入理解二者的关系的基础上，我们才算是真正驾驭了面向对象与面向过程技术，以便在未来将它们熟练地运用于学习和生活中。 二面向过程的程序设计方法 著名的计算机科学家Nikiklaus Wirth提出了一个公式：程序=算法+数据结构。这个公式很好地诠释了面向过程程序设计方法的核心思想——算法和数据。 更加具体地说，面向过程的程序设计方法称为功能分解，即自顶向下。以两个人下五子棋为例，面向过程的设计方法是先决定二人中谁先手，然后是先手者下一子，判断游戏是否结实，后手者下一子，判断游戏是否结束……可以看到无论是猜先、落子还是最后的判胜负，它们都是一场五子棋游戏中不能再分割的逻

举例说明面向对象和面向过程的区别

举例说明面向对象和面向过程的区别 两种方法都是编程中的比较常用的方法，从理论上来说，都能达到用计算机程序来解决实际问题的目的，只不过是其中所体现出来的思想不一样而已。 面向过程：面向过程的思想是把一个项目、一件事情按照一定的顺序，从头到尾一步一步地做下去，先做什么，后做什么，一直到结束。这种思想比较好理解，其实这也是一个人做事的方法。 面向对象：面向对象的思想是把一个项目、一件事情分成更小的项目，或者说分成一个个更小的部分，每一部分负责什么方面的功能，最后再由这些部分组合而成为一个整体。这种思想比较适合多人的分工合作，就像一个大的机关，分成各个部门，每个部门分别负责某样职能，各个部门可以充分发挥自己的特色，只要符合一定前提就行了。 举例说明1：比如刚才说的一个大的机关，要做某一个项目，从面向过程的思想来说，应该是这样分析的，先怎么样，再怎么样，最后怎么样。第一样应该如何完成，第二样应该如何完成等等。等到每一步骤都完成，项目也就完成了。而面向对象的思想则应该是这样想的，这个项目是由几个部分组成的，我们就做好分工，成立一个部门来做一个部分的功能，另一个部门来做另一个部分。各个部门可以不用理解其他部门的事，只要完成自己那一部分的事情就OK了。 举例说明2：又比如我们有一台演出，为简单起见，假设有如下流程：主持人开场——演员一表演——演员二表演——主持人总结。用面向过程的思想来分析，就是先完成主持人开场，再完成演员一的表演，再完成演员二的表演，最后完成主持人的总结。而如果用面向对象的思想来分析，就应该是这样的。这个演出由两大部分组成：主持人、演员。与主持人相关的：开场、总结。与演员相关的：演员编号、所演的节目。然后这台演出就可以这样策划：需要一个主持人a，需

面向对象和面向过程的本质区别

怎么理解面向对象和面向过程到底的本质区别？ 2007-01-25 02:05:51| 分类：默认分类| 标签：|举报|字号大中小订阅 面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。 面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。 ----------------------------------------------- 面向过程的思维方式是分析综合。面向对象的思维方式是构造。 就是对C语言过程式解决问题时。一般是将现有的数据结构先定义出来。然后想办法构造出算法了。 而用C++这样的面向对象求解时，先是将对象抽出来。构造成一个仿真的环境，然后在这个环境里，把与最终要解决的问题间建立一个方法。 所以面向过程的程序设计有挑战性，技巧性强。 而面向对象主要在于对象抽象有技术性，抽象完了后，任何人都可以做后面的工作了。 ------------------------------------------------- 面向对象和面向过程的主要区别就是数据是单独存储还是与操作存储在一起。对面向过程而言，数据是独立的。而在面向对象中，对象本身就提供了存储数据的空间（类的数据成员），这样就是函数的参数传递简单多了，而且提供了数据封装后，数据的访问也变可靠了。 ------------------------------------------ 面向过程就是将编程当成是做一件事，要按步骤完成，每一步就是一个过程。比如作菜，先放油，接着是放菜进去炒，然后放水，最后菜就做好了。 这里面放油，炒，放水就是三个步骤。 面向对象就是将编程当成是一个事物，对外界来说，事物是直接使用的，不用去管他内部的情况。而编程就是设置事物能够做什么事。其实有点像是将面向过程给放到事物内部了。仍然举作菜为例，其实面向过程就好像你是个厨师，要自己炒菜，所以要讲究步骤，而面向对象就好像你是个食客，你只要通知厨师作

架构师之路----一个四年-JAVA-程序员的工作经历

论坛的帖子看的多了，讲大道理的也很多，可是真正懂的并去做的有多少？本人第一次发帖子，不说什么道理，只是个人的一点经历，很普通但是本人这几年的亲身经历。 首先介绍下自己，男，06 年毕业来的北京，从事J2EE 开发，现在 4 个年头了。 06 年和刚毕业的很多同行一样。二本毕业，CET-4，没有其它证书也没得过什么奖，很普通，面临找工作的问题。不过运气不错，刚来北京二周就拿了二个offer，一个是北京磁共振研究所，从事VB,DEPHI 开发，另一个是一个新成立的公司，从事JAVA 开发。我选择了后者，当时自己接受过 4 个月的培训，可能会比一般的学生多些动手能力，这公司的上机本来是一道题的，做一个GUI 画图程序，很简单，时间三天，不过我用了一天就搞定了，所以公司又多考了我二道上机题。只做出来了一道，当时很害怕公司不要我，后来才知道是公司有意试我的，无论后面两道我做成什么样，一样会拿到offer。刚毕业吗，没社会经验。工资2000，税后1600，试用80%，三个月，不过我二个月转正了，第 5 个月时提到了3000，第8 个月时提到了4000。当时开心的很，老板初看是很老实的人，开会还是私下给了我很多希望，甚至邀请我去他家去玩，自认为和老板的关系很好。不过后来证实这点是错误的，千万不要和你的老板走的太近。就是同事关系。工作内容吗是负责公司一个可视化程序的开发和对应的B/S 插件以及对外支持工作，产品要卖钱吗，当时工作真的很卖力，在这公司的时间真的把心都给公司了，基本没有11 点前过家，有时是工作，有时是学习，刚毕业吗，没经验，尤其是支持还需要很广的知识面。在这公司呆了三年，当时公司就20 多人，所以有些工作不是分的那么清，我呢基本是一个人做三个人的活，开发，测试，支持，后来又兼职售前。当时工作太忙，北京又太大，有时一天要跑几个地方，公司仅有的一辆车基本成了我的专用车了。当时老板对我也不错，这样过了两年多，我学了很多知识，而且了解了公司运作和产品开发流程，并一手支撑起了支持部门，一共 5 个人。 到第二年半的时间，公司新招了一批程序员，都是 2 -4 年工作经验的，他们工资都是7000+，我呢当时是4500，所以有点不得劲，找老板谈了次，我要求是5500，结果不欢而散，老板向我保证的是 5 年后，会有20W 的个人买房补助和车补，这时我才明白人们常说的不要和你的老板做朋友是啥意思。完了后我故意没以前工作努力了，但也没误过事。只是不会多做事，老板没办法给我涨到了5200。我这时才有了跳槽的想法，一个月后提出辞职。结果老板骂了我，说我应该提前3-4 个月和他说，还说我没职业道德。合同法规定是一个月，半个月时工作交接完了，到了一个月我要走了，办离职证明，公司不给开，不让我走，这之前老板找了谈了三回，最后一回才提涨工资的事，说实在的我当时就是因为这事要走的，不过都谈三回了，也没啥意思了。 当时我找到工作了，那边让我报到，这边不给证明，后来我和老板商量我先报到，然后再回来半个月，再帮半个月时间。还是不欢而散，我一生气，就直接走了，结果到了那边没有离职证明可以签个协议就行了。当时还有工资没结，取工资时老板不给我让扣一个月的，我真的生气了，我说我不要了，明天我去告他。我走到门口，老板拉住我又说可以给工资但不给开离职证明，我还是那句话，老板没办法，后来手续和工资都给我了。安心去第二家公司上班。 不过说实在的，我还是很感激这个公司和老板的，教了我N 多东西，我也在这公司学了N 多东西，很多是和技术没关的。 09 年，第二家公司是开发组长，带了7个人做J2EE，当时我就不会设计大的系统，不过我们经理是高级架构师，所以应聘时根本没在乎工资还是5000。这公司很大，但开发流程不太正规，底层开发人员不受重视，做了很多大的项目，和组员和经理处的都不错，我刚来时我们经理又是业务又是技术的累死了，我之前做过很多不同职位，所以我来了后技术这块我们经理基本是没操过心，唯一做的工作是看我的阶段报告。整体把控一下。和我们经理这时真的是朋友了，因为不涉及到钱。所以当时我请假啥的根本不用走流程，只要我事做完了，可以不来，也可以在家做，一周基本3-4 天班。 后来因为家里的原因，我08 年的房子要下来了，而且也结婚了，老婆是上家公司的同事。而且到2010 年时老婆又有小孩了，迫于经济原因只能走了。走时我们经理没有当面留我，只是找我抽烟的时候多了好多，而且从来不提我找工作的事，这事他早知道。说实的，我是真的不想走。 我之前没在网上写过任何东西，也没有博客和网站，甚至连QQ 空间都没。有时怀疑是不是搞IT 的，回

面向对象和面向过程对比

Q：面对对象和面向过程的优缺点，结合实例进行阐述 A： 一、个人理解，面向对象相对于面向过程较显著的优势莫过于可扩展性、可维护性。众所周知在软件开发过程中，开发人员与客户需要不断的沟通，而客户的需求也往往在不断的变化，软件的功能也不是一成不变的。如果采用面向过程的方法来进行软件开发，当用户需求发生变化时，比如要求修改现有软件功能的实现方式或者要求追加新的功能时，就需要自顶向下地修改模块的结构，有时候甚至整个软件系统的设计被完全推翻。 相比之下，面向对象所提供的可扩展性保证了当软件必须增加新的功能时，能够在现有系统结构的基础上，方便的创建新的子系统，而不需要改变软件系统现有的结构，也不会影响已经存在的子系统。可维护性则保证了当用户需求发生变化时，只需要修改局部的子系统的少量程序代码，而不会牵一发动全身。 举一个例子，暴雪公司开发的魔兽争霸游戏，这个游戏里面有很多人物角色，例如我们要编程实现美杜莎这个角色的技能攻击动作。如果使用面向过程的方法来实现。本例使用C++，Visual C++ 6.0环境下调试。 #include using namespace std; #define SPLIT_SHOT 1 #define MYSTIC_SNAKE 2 #define MANA_SHIELD 3 void useSplitShot() //使用分裂箭技能 { cout<<"Split Shot"<>skill; //输入技能快捷键 switch(skill) { case SPLIT_SHOT: useSplitShot(); break; case MYSTIC_SNAKE:

自学双IECCIE和JncIE认证个人血泪史

自学双IECCIE和JncIE认证个人血泪史

自学双IE:CCIE和JncIE认证个人血泪史2009-06-04 08:36 枫速向航56CTO论坛我要评论(12)字号：T | T 与电影《我为玛丽狂》中主人公特德与赫利为玛丽疯狂相比，我敢自豪的说，那段对JNCIE执着追求，不断努力，时忧时喜的疯狂过程，是我今生永远值得回味的体验。从安装olive模拟器{模拟器真是个好家伙}(56cto网站下载)到最终得到认证JNCIE，共历时近2年时间，那段岁月是疲惫的，充满激情的，无法忘却的，值得自己慢慢品味的，更是值得与朋友们分享的。AD：2013云计算架构师峰会超低价抢票中 前言：(在CCIE实验和JNCIE实验共花费=1250+1250美元如有资金可个人推荐选择培训当时抱着去培训+自己一次考试都够考3次CCIE 了) 与学习思科认证到最终通过CCIE有所不同，学习Juniper认证的时候我已经离开大学校园，进入社会的大熔炉为自己的事业去奋斗，学习的时间和精力都没有在学校那么充足。但相同的是我对网络技术的兴趣和激情，以及JNCIE认证

在业界的权威性。我是2009年5月5日通过JNCIE 认证，全球认证编号为430号，也就是说目前全球通过JNCIE认证的总数也不超过450人，仅占全球超过20000人的CCIE的2%，相当于10多年前的CCIE 人数，这里并不是想说明通过JNCIE认证的人数少，对网络工程师就有更高的含金量，但毕竟是“物以稀为贵”。 从一些侧面也可以了解JNCIE认证的专业程度和对技术的严谨。其实很多朋友也了解思科认证从2000年左右，伴随着思科网络学院在国内高等院校的普及，全球几千人的CCIE互联网专家的榜样，成为高校学生、网络工程师，以及众多希望在网络技术殿堂有所建树朋友们所孜孜追求的目标。不可否认当时思科认证的价值是厚重的，但随着认证机构、培训机构如雨后春笋般涌出，题库(TK)，代考也伴随着互联网的热潮在网络泛滥，我们似乎感觉到所追求的认证变了味道，不再是对技术的追求和向往，而是对一纸证书含金量的盲目崇拜，思科的认证体系没有变，变的是我们的心态。 而Juniper认证体系对认证学习和考试一直都十分严谨，即使是在“人肉搜索”大行其道的今天，

面向对象与面向过程的区别

C是面向过程 C++、JAVA是面向对象 面向对象和面向过程的区别 一个博大,一个精深. 总体而言,面向对象简单,面向过程对人员要求素质过高 面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。 面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。 艾兰.库伯的《软件创新之路》中提到： 面向过程和面向对象的区别并不像人们想象得那么大 面向对象的大部分思想在面向过程中也能体现 但面向过程最大的问题（也许是唯一先天的缺陷）在于随着系统的膨胀，面向过程将无法应付，最终导致系统的崩溃 面向对象的提出正是试图解决这一软件危机 目前看来，似乎有一定成效 但仍任重道远 --------------------------------------------------------------- 做一些对比来说吧： 分析基本构件方法工具 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 面向过程基于算法函数／过程数据流图、伪代码... ... 面向对象基于对象类UML建模... Rose，viso等 --------------------------------------------------------------- 其实我始终认为，不管是面向对象，还是面向过程，都体现了一种软件重用的思想！ 只不过面向过程中重用的是过程和函数，但是面向对象重用的是类，一种将数据和处理数据的过程及函数封装在一起的实体，其实面向对象中的过程和函数和面向过程中的分别不是很大，所以数据流图和伪代码还是有用的。 面向对象一个很大的好处就是数据和方法的封装，由此面向对象的三大特性得到发挥 什么是面向对象面向过程面向事件 2010-06-05 11:26 面向过程是在面向对象出现之前，以及之后，甚至至今都应用于程序开发中的程序设计思想。 面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。面向对象是把构成问题事分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。 如： 一辆汽车

android从程序员到架构师之路介绍

麦可网https://www.wendangku.net/doc/5610738443.html,/ 高端android体系化学习 Android：从程序员到架构师之路 Android发展多年的今天，很多工程师都遇到职业发展瓶颈了，不知道如何向上走，因此麦可网携手台湾Android教父高焕堂老师推出了《Android架构师之路》这套国内唯一的课程，通过这套课程学习，学员们会学习高老师提出的EIT架构设计模式，能从普通Android工程师往Android架构设计师这个新的台阶攀登，同时更加熟悉Android本身体系结构设计，也可以换位以Android系统的设计师角度来思考问题。 由于Android是开源开放的平台，国内开发者不仅涉及App应用开发，也深入到底层软硬整合开发。 随着Android产业急速扩大，上下层模块日益增多，复杂性增高。无论是软硬件开发者都需要优越的架构思维、模式和方法，来支撑复杂的软硬整合、跨平台和自动化测试问题。 本课程解析移动应用开发的架构思维、模式和方法；并落实为Android的多层框架体系；所介绍的架构设计决策，都能落实为代码，为一个非常务实的课程。 随着这套课程的推出，麦可网已经有了高级应用，Framework，底层嵌入式，架构师之路等一系列互补系统的Android课程，全面覆盖纵横领域。毫无悬念的麦可网已经具备了国内最强大，系统，专业的Android课程体系。 这套课程的针对人群：Android开发已经有至少两年经验的IT工程师，多年开发经验想深入了解Android这个开源平台的资深工程师，Android项目团队的技术管理者。 我们不建议：不建议Android初学者学习这套课程；不建议没有项目经验者学习这套课程；不建议没有遇到瓶颈者学习这套课程。 有人问：架构课程是否会讲解的很虚？这套课程有超过2/5 都是案例，结合代码和UML案例来分析各个设计场景，所以大可放心，欢迎点击我们的试听课程。

面向对象程序设计与面向过程程序设计的区别 1

面向对象程序设计与面向过程程序设计的区别 想要知道面向对象程序设计与面向过程程序设计的区别，我们应先了解什么事面向对象程序设计，什么事面向过程程序设计，这样我们才能弄清他们之间的区别，下面我们就什么是面向对象程序设计和什么事面向过程程序设计展开论述。 面向对象的基本概念： (1)对象。 对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。 (2)对象的状态和行为。 对象具有状态，一个对象用数据值来描述它的状态。 对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。 对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中 (3)类。 具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。 类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。 类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。 (4)类的结构。 在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。 ①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。 ②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。 (5)消息和方法。 对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。 (1)对象唯一性。 每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。 (2)抽象性。 分类性是指将具有一致的数据结构(属性)和行为(操作)的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。 (3)继承性。

java架构师之路：JAVA程序员必看的15本书的电子版下载地址

作为Java程序员来说，最痛苦的事情莫过于可以选择的范围太广，可以读的书太多，往往容易无所适从。我想就我自己读过的技术书籍中挑选出来一些，按照学习的先后顺序，推荐给大家，特别是那些想不断提高自己技术水平的Java 程序员们。 一、Java编程入门类 对于没有Java编程经验的程序员要入门，随便读什么入门书籍都一样，这个阶段需要你快速的掌握Java基础语法和基本用法，宗旨就是“囫囵吞枣不求甚解”，先对Java熟悉起来再说。用很短的时间快速过一遍Java语法，连懵带猜多写写代码，要“知其然”。 1、《Java编程思想》 下载地址：https://www.wendangku.net/doc/5610738443.html,/share/p2446196.html 在有了一定的Java编程经验之后，你需要“知其所以然”了。这个时候《Java 编程思想》是一本让你知其所以然的好书，它对于基本的面向对象知识有比较清楚的交待，对Java基本语法，基本类库有比较清楚的讲解，可以帮你打一个良好的Java编程基础。这本书的缺点是实在太厚，也比较罗嗦，不适合现代人快节奏学习，因此看这本书要懂得取舍，不是每章每节都值得一看的，挑重点的深入看就可以了。 2、《Agile Java》中文版 下载地址：https://www.wendangku.net/doc/5610738443.html,/share/p2564807.html 这本书是出版社送给我的，我一拿到就束之高阁，放在书柜一页都没有翻过，但是前两天整理书柜的时候，拿出来一翻，竟然发现这绝对是一本好书！这本书一大特点是以单元测试和TDD来贯穿全书的，在教你Java各种重要的基础知识的过程中，潜移默化的影响你的编程思维走向敏捷，走向TDD。另外这本书成书很新，以JDK5.0的语法为基础讲解，要学习JDK5.0的新语法也不错。还有这本书对于内容取舍也非常得当，Java语言毕竟类库庞大，可以讲的内容太多，这本书选择的内容以及内容的多寡都很得当，可以让你以最少的时间掌握Java 最重要的知识，顺便培养出来优秀的编程思路，真是一本不可多得的好书。 虽然作者自己把这本书定位在入门级别，但我不确定这本书用来入门是不是稍微深了点，我自己也准备有空的时候翻翻这本书，学习学习。 二、Java编程进阶类 打下一个良好的Java基础，还需要更多的实践经验积累，我想没有什么捷径。有两本书值得你在编程生涯的这个阶段阅读，培养良好的编程习惯，提高你的代码质量。

如何理解程序设计中的面向过程与面向对象

如何理解程序设计中的面向过程与面向对象 摘要 程序设计语言的发展是一个不断演化的过程，其根本的推动力就是抽象机制更高的要求，以及对程序设计思想的更好的支持。具体的说，就是把机器能够理解的语言提升到也能够很好的模仿人类思考问题的形式。“面向过程”是一种以事件为中心的编程思想。就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。随着程序规模的不段断扩大，在60年代末期出现了软件危机，在当时的程序设计范型中都无法克服错误随着代码的扩大而级数般的扩大，以至到了无法控制的地步，这个时候就出现了一种新的思考程序设计方式和程序设计范型-----面向对象程序设计，由此也诞生了一批支持此技术的程序设计语言，比如EIFFEL，C++，JAVA，这些语言都以新的观点去看待问题，即问题就是由各种不同属性的对象以及对象之间的消息传递构成。 一、程序设计范型的演化 1过程式程序设计 原始的程序设计范型是： 确定需要哪些过程； 采用能找到的最好的算法。 这里所关注的是处理过程-----执行预期的计算所需要的算法，从程序组织的观点看，函数被用于在许多算法里建立一种次序。算法本身通过函数调用和其他语言功能写出，其典型语言是PASCAL。 2模块程序设计 设计程序的着重点已经从有关过程的设计转移到了对数据的组织，这种转移也反映了程序规模增大的情况。相关的过程与他们所操作的数据组织在一起，通称为一个模块，程序设计范型变成： 确定需要哪些模块；将程序分为一些模块，使数据隐藏于模块之中。 在这样的设计范型中，最重要的概念就是数据隐藏原理。 3基于对象程序设计 允许程序员直接定义类型，这种类型的行为方式与内部类型几乎完全一样，这样的类型常常被称为抽象数据类型，其程序设计范型是： 确定需要哪些类型； 为每个类型提供完整的一组操作。 支持这种范型的典型设计语言就是ADA。 4面向对象程序设计 在基于对象程序设计范型的基础上，加入继承和多态这两个组重要的概念就演变出了现在最流行的程序设计方法---面向对象程序设计，其范型是： 确定需要哪些类； 为每个类提供完整的一组操作； 利用继承去明确地表示共性。 支持此范型的典型语言就是EIFFEL，JAVA，C++等。 二、面向过程 “面向过程”是一种以事件为中心的编程思想。

JAVA程序员必看的15本书-JAVA自学书籍推荐

JAVA程序员必看的15本书-JAVA自学书籍推荐 作为Java程序员来说，最痛苦的事情莫过于可以选择的范围太广，可以读的书太多，往往容易无所适从。我想就我自己读过的技术书籍中挑选出来一些，按照学习的先后顺序，推荐给大家，特别是那些想不断提高自己技术水平的Java程序员们。此外，大家可以加QQ1006398762，互相分享一下关于JAVA方面的知识。 一、Java编程入门类 对于没有Java编程经验的程序员要入门，随便读什么入门书籍都一样，这个阶段需要你快速的掌握Java基础语法和基本用法，宗旨就是“囫囵吞枣不求甚解”，先对Java熟悉起来再说。用很短的时间快速过一遍Java语法，连懵带猜多写写代码，要“知其然”。 1、《Java编程思想》 在有了一定的Java编程经验之后，你需要“知其所以然”了。这个时候《Java编程思想》是一本让你知其所以然的好书，它对于基本的面向对象知识有比较清楚的交待，对Java 基本语法，基本类库有比较清楚的讲解，可以帮你打一个良好的Java编程基础。这本书的缺点是实在太厚，也比较罗嗦，不适合现代人快节奏学习，因此看这本书要懂得取舍，不是每章每节都值得一看的，挑重点的深入看就可以了。 2、《Agile Java》中文版 这本书是出版社送给我的，我一拿到就束之高阁，放在书柜一页都没有翻过，但是前两天整理书柜的时候，拿出来一翻，竟然发现这绝对是一本好书！这本书一大特点是以单元测试和TDD来贯穿全书的，在教你Java各种重要的基础知识的过程中，潜移默化的影响你的编程思维走向敏捷，走向TDD。另外这本书成书很新，以JDK5.0的语法为基础讲解，要学习JDK5.0的新语法也不错。还有这本书对于内容取舍也非常得当，Java语言毕竟类

面向对象的程序设计语言与面向过程的程序设计语言

面向对象的程序设计语言与面向过程的程序设计语言 首先C面向过程的编程，C++和JAVA都是面向对象的编程。 二者用最简单的例子来说 比如说：我吃饭 面向过程：着重在吃的过程，要具体描述吃的没一个步骤，比如夹米饭，张嘴，我进行咀嚼等之类的过程 面向对象：是先将我封装成一个类，米饭封装成一个类，然后把吃饭进行封装，来各自实现的。 面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。 面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。 例如五子棋，面向过程的设计思路就是首先分析问题的步骤：1、开始游戏，2、黑子先走，3、绘制画面，4、判断输赢，5、轮到白子，6、绘制画面，7、判断输赢，8、返回步骤2，9、输出最后结果。把上面每个步骤用分别的函数来实现，问题就解决了。

而面向对象的设计则是从另外的思路来解决问题。整个五子棋可以分为1、黑白双方，这两方的行为是一模一样的，2、棋盘系统，负责绘制画面，3、规则系统，负责判定诸如犯规、输赢等。第一类对象（玩家对象）负责接受用户输入，并告知第二类对象（棋盘对象）棋子布局的变化，棋盘对象接收到了棋子的i变化就要负责在屏幕上面显示出这种变化，同时利用第三类对象（规则系统）来对棋局进行判定。 可以明显地看出，面向对象是以功能来划分问题，而不是步骤。同样是绘制棋局，这样的行为在面向过程的设计中分散在了总多步骤中，很可能出现不同的绘制版本，因为通常设计人员会考虑到实际情况进行各种各样的简化。而面向对象的设计中，绘图只可能在棋盘对象中出现，从而保证了绘图的统一。 功能上的统一保证了面向对象设计的可扩展性。比如我要加入悔棋的功能，如果要改动面向过程的设计，那么从输入到判断到显示这一连串的步骤都要改动，甚至步骤之间的循序都要进行大规模调整。如果是面向对象的话，只用改动棋盘对象就行了，棋盘系统保存了黑白双方的棋谱，简单回溯就可以了，而显示和规则判断则不用顾及，同时整个对对象功能的调用顺序都没有变化，改动只是局部的。 再比如我要把这个五子棋游戏改为围棋游戏，如果你是面向过程设计，那么五子棋的规则就分布在了你的程序的每一个角落，要改动还不如重写。但是如果你当初就是面向对象的设计，那么你只用改动规则对象就可以了，五子棋和围棋的区

面向过程与面向对象程序设计(马京振)

面向过程与面向对象程序设计 一、面向过程的程序设计 面向过程（Process Oriented）这个词是在面向对象（Object Oriented）出现之后为与之相对而提出的，其实它在以前基本被叫做“结构化编程”。早期的程序设计，大量使用共享变量（全局变量）和GOTO语句一类的东西，后来有人证明所有的程序流程都可以使用三种基本流程（顺序、选择、重复）来实现，并提出“GOTO有害说”，从此人们进行编程的方式发生重大变化，每种语言都 提供这些基本控制结构的实现方式，并提供把数据访问局部化的能力，以及某种形式的模块化/分别编译机制。在这些基础上，人们所进行的编程活动基本是通过编写用于不同目的的功能函数/过程来实现，故称为“面向过程”。 1.1面向过程设计概述 面向过程的结构化程序设计方法就是采用面向过程的方法来设计结构化程序。结构化程序通常包含一个主程序和若干个子过程，其中每个子过程都描述了某一个小问题的解决方法再由主过程自顶向下调用各子过程，来逐步解决整个问题。结构化程序设计方法是一种数学思维或计算机思维方法，和人们认识世界时所习惯使用的方法不同。 面向过程开发方式是对计算机底层结构的一层抽象，它把程序的内容分为数据和操纵数据的操作两部分。这种编程方式的核心问题是数据结构和算法的开发和优化。C语言所提供的机制就是典型的结构化编程设施。 1.2面向对象设计的特点 面向过程的程序设计方法通过在程序中模拟问题求解中的过程来进行问题 求解，这种方法认为过程或函数可以作为建立大型复杂软件系统的抽象机制。但由于在问题求解过程中，一些过程比较复杂，为控制复杂性，引入了功能分解的方法，即将一个复杂的过程分解为复杂性较低的低级过程，这种分解一直进行到参与设计和编程的人员可以理解的步骤或过程为止。这样使得系统是过程的组件，在整个分解过程中，数据结构的安排是出于对过程组织的需要而进行的。因此，数据处于次要地位，而过程是关心的焦点。面向过程的程序方法把重点放在解决问题的过程上，将数据结构和操作这些数据结构的函数分开，在方法上存在明显的不足。 二、面向对象的程序设计 人们在认识客观世界中的各种系统时所习惯使用的方法是面向对象的方法。面向对象的程序设计（OOP）方法就是用人类在现实生活中常用的思维方法来认识、理解和描述客观事物，强调最终建立的程序系统能够映射问题域，即程序系统中的对象以及对象之间的关系能够如实地反映问题域中固有的事物及其关系。因此，它为我们提出了一个全新的概念，其主要思想是将数据（成员数据）及处理这些数据的相应函数（成员函数）封装到一个类（class）中，而使用类的数

……我的JAVA之路就是从考SCJP开始

我的JAVA之路就是从考SCJP开始。 起源： 一切都是源于CSDN上的SCJP的广告，那是在国庆长假前几天看到的。在2006年下半年，学生考SCJP是优惠价450。那时就想着趁着这个时机考个证来傍身，优惠800哦。顺便可以开始学习JAVA。 开始学习JAVA： 然后就在网上买了几本书，都是很多人都推荐的《Thinking in JAVA 3e》，《Core Java 7e》1，2卷，《Effective Java》。那时还完全不懂，不买Effective JAVA早知道买Java Puzzlers，因为其实Puzzlers是Effective的第二版，两位作者都是就职于Google的JAVA达人。而另外两本书用来入门还不错，两本书都有大量的代码例子，看代码来学习也许是最好的学习编程的方法了。TIJ这本书讲了很多编程技巧和JAVA的一些原理，而CJ这本书讲了很多在应用方面的技巧，两本书都很生动很有趣。 以前C++上我花了很大的精力在学习，一开始接触电脑就在学C++，有两年的C++学习时间。所以对JAVA的语法和面向对象概念能比较好的适应。对C++和JAVA比较直观的比较就是，JAVA的库比起C++的标准强大太多太多了，C++只提供了一些常见的数据结构和算法，而Java几乎提供了所有的基础功能。还有JAVA的API文档相当齐全，对方方面面都讲得很详细，而且有中文化，这相对于学习速度有很大提高。 小插曲： 一开始我就计划好，用一个半月的时间学习JAVA基本的知识，然后用一个月的时间复习考试。如果计划延误了就算了，不考了。计划其实不是很顺利，10月份因为学生会很多事要做，而且刚好学校要进行本科评估，抓的比较严不可以太常逃课，又刚刚好有朋友拉我去作一些商业活动。这时忽然因为和女朋友吵架了，所以心情很不好，有些自暴自弃，一下子把身边的事全部推了，把学生会的职务也辞了（在他们的挽留下虽然最后没有辞成功只是暂时离开学生会），什么都不理，专心地学习。结果进度又拉了上来，大概在十一月底就完成了基本的学习。 复习： 在十一月份买了那本Sun Certified Programmer for Java 5（Exam 310-055），这是对考试有极大帮助的一本书。这本书的作者就是大名鼎鼎倍受好评的《Head First》系列的作者，也是SCJP的出题人。这本书对055考试中每个考点，哪些必考哪些不考，而且对知识做了很细致的整理。里面的题目也出的很好，基本每个考点都有十几道题目，我基本可以维持在六十多的正确率。随书还附送一个模拟器，模拟真正的考试环境。之后因为对Lang包中

架构师的自学之路

架构师的自学之路 实现的原理。jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码;池技术，什么对象池，连接池，线程池…… 节码技术;nio，没什么好说的，值得注意的是”直接内存”的特点，使用场景;java 多线程同步异步;java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，好多五年以上经验的人都弄不清楚，还有为什扩容时有性能问题?不弄清楚这些原理，就写不出高效的代码，还会认为自己做的很对;总之一句话越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已,离会用还差的远。 熟练使用各种数据结构和算法，数组、哈希、链表、排序树…，一句话要么是时间换空间要么是空间换时间，这里展开可以说一大堆，需要有一定的应用经验，用于解决各种性能或业务上的问题。 熟练使用linux操作系统，必备，没什么好说的。 熟悉tcp协议，创建连接三次握手和断开连接四次握手的整个过程，不了解的话，无法对高并发网络应用做优化; 熟悉http协议，尤其是http头，我发现好多工

作五年以上的都弄不清session和cookie的生命周期以及它们之间的关联。 系统集群、负载均衡、反向代理、动静分离，网站静态化。 分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点，适用场景。 分布式缓存技术memcached,redis，提高系统性能必备，一句话，把硬盘上的内容放到内存里来提速，顺便提个算法一致性hash 。 工具nginx必备技能超级好用，高性能，基本不会挂掉的服务器，功能多多，解决各种问题。 数据库的设计能力，mysql必备，最基础的数据库工具，免费好用，对它基本的参数优化，慢查询日志分析，主从复制的配置，至少要成为半个mysql dba。其他nosql数据库如mongodb。 还有队列中间件。如消息推送，可以先把消息写入数据库，推送放队列服务器上，由推送服务器去队列获取处理，这样就可以将消息放数据库和队列里后直接给用户反馈，推送过程则由推送服务器和队列服务器完成，好处异步处理、缓解服务器压力，解藕系统。 以上纯粹是常用的技术，还有很多自己慢慢去摸索吧;因为要知道的东西很多，

做人、做事,做架构师——架构师能力模型解析

做人、做事，做架构师——架构师能力模型解析 要想从一名普通程序员发展成为优秀的架构师，“个人特性”与“技术技能”缺一不可；而“技术专业能力”、“人际关系能力”和“业务能力”更是优秀架构师重要的三种能力。 文 / 周爱民（《程序员》2008年4月刊） 引子 究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满……你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐忑。 如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去”，要么“顺着代码铺就的道路，亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型。 你能不能做一个好的架构师？ 架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表。 所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当工人。能做一份工作列表中的事，并不等于就成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪个位置，而技术技能只是做事实施的必需。架构师这个职务，同时要求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做人、做事，做架构师。 因此“模型”由“个人特性”和“技术技能”两个方面构成，在第一张图中，我特别说明“个人特性”既包括人际关系的能力，也包括（具体）业务能力；“技术技能”也是如此。所以个人特性主要与“做人”有关，部分地也包含“做事”的要素。