如何从普通程序员晋升为架构师.docx
- 文档编号:4114519
- 上传时间:2022-11-28
- 格式:DOCX
- 页数:13
- 大小:62.38KB
如何从普通程序员晋升为架构师.docx
《如何从普通程序员晋升为架构师.docx》由会员分享,可在线阅读,更多相关《如何从普通程序员晋升为架构师.docx(13页珍藏版)》请在冰豆网上搜索。
如何从普通程序员晋升为架构师
如何从普通程序员晋升为架构师
引言
计算机科学是一门应用科学,它的知识体系是典型的倒三角结构,所用的基础知识并不多,只是随着应用领域和方向的不同,产生了很多的分支,所以说编程并不是一件很困难的事情,一个高中生经过特定的训练就可以做得到。
但是,会编程和编好程绝对是两码事,同样的程序员,有的人几年之后成为了架构师,有的人却还在不停地coding,只不过ctrl-c、ctrl-v用得更加纯熟了。
在中国,编程人员最终的归途无外乎两条:
一是转向技术管理,它的终点是CTO;二是继续深入,它的终点是首席架构师,成为CEO的人毕竟是少数。
如果你现在还是个普通的程序员,希望继续在技术这条路上前进的话,我想你还是应该先补充一点软件工程的思想,学习一点有关设计模式的知识,只有具备这些能力,你才能从整体和宏观层面来考虑问题、分析问题和解决问题。
本人Coding了很多年,中间走了不少弯路,虽然最终没什么大成就,但总算有一些心得,很愿意把自己的一些经验拿出来跟大家分享,这或许对你的发展有所帮助。
由程序员转为架构师,最绕不开的概念就算是面向对象(OO)了。
记得在大学的时候,我们专业开了一门课叫《面向对象的编程》。
那个时候,我们刚刚学了一门C语言,开发环境用的还是DOS下的TurboC,半点项目开发的经验都没有,纯粹的空对空。
所以,一学期下来,我始终处于一种懵懂状态,既没领会面向过程和面向对象到底有什么区别,也没搞懂面向对象能带来什么好处。
面向过程(OP)和面向对象(OO)
1蛋炒饭和盖浇饭
有人这么形容OP和OO的不同:
用面向过程的方法写出来的程序是一份蛋炒饭,而用面向对象写出来的程序是一份盖浇饭。
所谓盖浇饭,北京叫盖饭,东北叫烩饭,广东叫碟头饭,就是在一碗白米饭上面浇上一份盖菜,你喜欢什么菜,你就浇上什么菜。
我觉得这个比喻还是比较贴切的。
蛋炒饭制作的细节,我不太清楚,因为我没当过厨师,也不会做饭,但最后的一道工序肯定是把米饭和鸡蛋混在一起炒匀。
盖浇饭呢,则是把米饭和盖菜分别做好,你如果要一份红烧肉盖饭呢,就给你浇一份红烧肉;如果要一份青椒土豆盖浇饭,就给浇一份青椒土豆丝。
蛋炒饭的好处就是入味均匀,吃起来香。
如果恰巧你不爱吃鸡蛋,只爱吃青菜的话,那么唯一的办法就是全部倒掉,重新做一份青菜炒饭了。
盖浇饭就没这么多麻烦,你只需要把上面的盖菜拨掉,更换一份盖菜就可以了。
盖浇饭的缺点是入味不均,可能没有蛋炒饭那么香。
到底是蛋炒饭好还是盖浇饭好呢?
其实这类问题都很难回答,非要比个上下高低的话,就必须设定一个场景,否则只能说是各有所长。
如果大家都不是美食家,没那么多讲究,那么从饭馆角度来讲的话,做盖浇饭显然比蛋炒饭更有优势,他可以组合出来任意多的组合,而且不会浪费。
软件工程
盖浇饭的好处就是“菜”“饭”分离,从而提高了制作盖浇饭的灵活性。
饭不满意就换饭,菜不满意换菜。
用软件工程的专业术语就是“可维护性”比较好,“饭”和“菜”的耦合度比较低。
蛋炒饭将“蛋”“饭”搅和在一起,想换“蛋”“饭”中任何一种都很困难,耦合度很高,以至于“可维护性”比较差。
软件工程追求的目标之一就是可维护性,可维护性主要表现在3个方面:
可理解性、可测试性和可修改性。
面向对象的主要好处就是显著的改善了软件的可维护性。
面向过程(OP)和面向对象(OO)是不是就是指编码的两种方式呢?
不是!
你拿到了一个用户需求,比如有人要找你编个软件,你是不是需要经过需求分析,然后进行总体/详细设计,最后编码,才能最终写出软件,交付给用户。
这个过程是符合人类基本行为方式的:
先想做什么,再想如何去做,最后才是做事情。
有的同学说:
“我没按照你说的步骤做啊,我是直接编码的”。
其实,你一定会经历了这三个阶段,只不过你潜意识里没有分得那么清楚。
对于拿到需求就编码的人,可能编着编着,又得倒回去重新琢磨,还是免不了这些过程,
以OO为例,对应于软件开发的过程,OO衍生出3个概念:
OOA、OOD和OOP。
采用面向对象进行分析的方式称为OOA,采用面向对象进行设计的方式称为OOD,采用面向对象进行编码的方式称为OOP。
面向过程(OP)和面向对象(OO)本质的区别在于分析方式的不同,最终导致了编码方式的不同。
面向过程编程(OPP)和面向对象编程(OOP)的关系
关于面向过程的编程(OPP)和面向对象的编程(OOP),给出这它们的定义的人很多,您可以从任何资料中找到很专业的解释,但以我的经验来看,讲的相对枯燥一点,不是很直观。
除非您已经有了相当的积累,否则说起来还是比较费劲。
我是个老程序员出身,虽然现在的日常工作更多倾向了管理,但至今依然保持编码的习惯,这句话什么意思呢?
我跟大家沟通应该没有问题。
无论你是在重复我走过的路,或者已经走在了我的前面,大家都会有那么一段相同的经历,都会在思想层面上有一种理解和默契,所以我还是会尽量按照大多数人的常规思维写下去。
面向过程的编程(OPP)产生在前,面向对象的编程(OOP)产生在后,所以面向对象的编程(OOP)一定会继承前者的一些优点,并摒弃前者存在的一些缺点,这是符合人类进步的自然规律。
两者在各自的发展和演变过程中,也一定会相互借鉴,互相融合,来吸收对方优点,从而出现在某些方面的趋同性,这些是必然的结果。
即使两者有更多的相似点,也不会改变它们本质上的不同,因为它们的出发点就完全是两种截然不同的思维方式。
关于两者的关系,我的观点是这样的:
面向对象编程(OOP)在局部上一定是面向过程(OP)的,面向过程的编程(OPP)在整体上应该借鉴面向对象(OO)的思想。
这一段说的的确很空洞,而且也一定会有引来争议,不过,我劝您还是在阅读了后面的内容之后,再来评判我观点的正确与否。
象C++、C#、Java等都是面向对象的语言,c,php(暂且这么说,因为php4以后就支持OO)都是面向过程的语言,那么是不是我用C++写的程序一定就是面向对象,用c写的程序一定就是面向过程呢?
这种观点显然是没有真正吃透两者的区别。
语言永远是一种工具,前辈们每创造出来的一种语言,都是你用来实现想法的利器。
我觉得好多人用C#,Java写出来的代码,要是仔细看看,那实际就是用面向对象(OO)的语言写的面向过程(OP)的程序。
所以,即使给关羽一根木棍,给你一杆青龙偃月刀,他照样可以打得你满头是包。
你就是扛着个偃月刀,也成不了关羽,因为你缺乏关羽最本质的东西---绝世武功。
同样的道理,如果你没有领会OO思想,怎么可能写得出真正的OO程序呢?
面向对象(OO)和面向过程(OP)绝对是两种截然不同的思维方式。
那是不是面向过程就不好,也没有存在的必要了?
我从来没有这样说过。
事实上,面向过程的编程(OPP)已经存在了几十年了,现在依然有很多人在使用。
它的优点就是逻辑不复杂的情况下很容易理解,而且运行效率远高于面向对象(OO)编写的程序。
所以,系统级的应用或准实时系统中,依然采用面向过程的编程(OPP)。
当然,很多编程高手以及大师级的人物,他们由于对于系统整体的掌控能力很强,也喜欢使用面向过程的编程(OPP),比如像Apache,QMail,PostFix,ICE等等这些比较经典的系统都是OPP的产物。
象php这些脚本语言,主要用于web开发,对于一些业务逻辑相对简单的系统,也常使用面向过程的编程(OPP),这也是php无法跨入到企业级应用开发的原因之一,不过php5目前已经能够很好的支持OO了。
详解面向过程的编程(OPP)
在面向对象出现之前,我们采用的开发方法都是面向过程的编程(OPP)。
面向过程的编程中最常用的一个分析方法是“功能分解”。
我们会把用户需求先分解成模块,然后把模块分解成大的功能,再把大的功能分解成小的功能,整个需求就是按照这样的方式,最终分解成一个一个的函数。
这种解决问题的方式称为“自顶向下”,原则是“先整体后局部”,“先大后小”,也有人喜欢使用“自下向上”的分析方式,先解决局部难点,逐步扩大开来,最后组合出来整个程序。
其实,这两种方式殊路同归,最终都能解决问题,但一般情况下采用“自顶向下”的方式还是较为常见,因为这种方式最容易看清问题的本质。
我举个例子来说明面向过程的编程方式:
用户需求:
老板让我写个通用计算器。
最终用户就是老板,我作为程序员,任务就是写一个计算器程序。
OK,很简单,以下就是用C语言完成的计算器:
假定程序的文件名为:
main.c。
intmain(intargc,char*argv[]){
//变量初始化
intnNum1,nNum2;
charcOpr;
intnResult;
nNum1=nNum2=0;
cOpr=0;
nResult=0;
//输入数据
printf("Pleaseinputthefirstnumber:
\r\n");
scanf("%d",&nNum1);
printf("Pleaseinputtheoperator:
\r\n");
scanf("%s",&cOpr);
printf("Pleaseinputthesecondnumber:
\r\n");
scanf("%d",&nNum2);
//计算结果
if(cOpr=='+'){
nResult=nNum1+nNum2;
}elseif(cOpr=='-'){
nResult=nNum1-nNum2;
}else{
printf("Unknownoperator!
");
return-1;
}
//输出结果
printf("Theresultis%d!
",nResult);
return0;
}
抛开细节不讲,我想大多数人差不多都会这么实现吧,很清晰,很简单,充分体现了“简单就是美”的原则,面向过程的编程就是这样有条理的按照顺序来逐步实现用户需求。
凡是做过程序的人都知道,用户需求从来都不会是稳定的,最多只能够做到“相对稳定”。
用户可能会随时提出加个功能,减个功能的要求,也可能会要求改动一下流程,程序员最烦的就是频繁地变动需求,尤其是程序已经写了大半了,但这种情况是永远无法避免的,也不能完全归罪到客户或者需求分析师。
以我们上面的代码为例,用户可能会提出类似的要求:
首先,你程序中实现了“加法”和“减法”,我还想让它也能计算“乘法”、“除法”。
其次,你现在的人机界面太简单了,我还想要个Windows计算器的界面或者Mac计算器的界面。
用户需求开始多了,我得琢磨琢磨该如何去写这段代码了。
我今天加了“乘”“除”的运算,明天保不齐又得让我加个“平方”、“立方”的运算,这要是把所有的运算都穷尽了,怎么也得写个千八百行代码吧。
还有,用户要求界面能够更换,还得写一大堆界面生成的代码,又得来个千八百行。
以后,这么多代码堆在一起,怎么去维护,找个变量得半天,看懂了代码得半天,万一不小心改错了,还得调半天。
另外,界面设计我也不擅长,得找个更专业的人来做,做完了之后再加进来吧。
这个过程也就是“软件危机”产生的过程。
伴随着软件广泛地应用于各个领域,软件开发的规模变得越来越大,复杂度越来越高,而其用户的需求越来越不稳定。
根据用户提出的两个需求,面向过程的编程该如何去应对呢?
我想大家都很清楚怎么去改。
Veryeasy,把“计算”和“界面”分开做成两个独立的函数,封装到不同的文件中。
假定程序的文件名为:
main.c。
#include"interface.h"
#include"calculate.h"
intmain(intargc,char*argv[]){
//变量初始化
intnNum1,nNum2;
charcOpr;
intnResult;
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("Theresultis%d!
",nResult);
return0;
}
interface.h:
intgetParameters(int*nNum1,int*nNum2,char*cOpr);
interface.c:
intgetParameters(int*nNum1,int*nNum2,char*cOpr){
printf("Pleaseinputthefirstnumber:
\r\n");
scanf("%d",nNum1);
printf("Pleaseinputtheoperator:
\r\n");
scanf("%s",cOpr);
printf("Pleaseinputthesecondnumber:
\r\n");
scanf("%d",nNum2);
return0;
}
calculate.h:
intcalcMachine(intnNum1,intnNum2,charcOpr,int*nResult);
calculate.c:
intcalcMachine(intnNum1,intnNum2,charcOpr,int*nResult){
if(cOpr=='+'){
*nResult=nNum1+nNum2;
}elseif(cOpr=='-'){
*nResult=nNum1-nNum2;
}else{
printf("Unknownoperator!
");
return-1;
};
return0;
}
面向过程的编程(OPP)就是将用户需求进行“功能分解”。
把用户需求先分解成模块(.h,.c),再把模块(.h,.c)分解成大的功能(function),然后把大的功能(function)分解成小的功能(function),如此类推。
功能分解是一项很有技术含量的工作,它不仅需要分解者具有丰富的实战经验,而且需要科学的理论作为指导。
如何分解,分解原则是什么,模块粒度多大合适?
这些都是架构师的要考虑的问题,也是我们后面要着重讲的内容。
面向过程的编程(OPP)优点是程序顺序执行,流程清晰明了。
它的缺点是主控程序承担了太多的任务,各个模块都需要主控程序进行控制和调度,主控和模块之间的承担的任务不均衡。
有的人把面向过程定义为:
算法+数据结构,我觉得也很准确。
面向过程的编程中算法是核心,数据处于从属地位,数据随算法而流动。
所以采用面向过程的方式进行编程,一般在动手之前,都要编写一份流程图或是数据流图。
3架构师的职责
近来看到CSDN上有个CTO俱乐部,里面聊得是不亦乐乎。
我怀着无比崇敬的态度,拜读了一下牛人们的发言。
里面有个哥们发起一个话题:
“CTO,你多久没有写程序了?
”。
有人回答:
“不写代码的CTO,属于......这公司问题大了!
”。
看到这里,我就赶紧撤了,怕忍不住反驳几句,反而遭到牛人们的群殴。
试想,一个上点规模的IT公司,还得靠CTO来写程序的话,那是不是才叫问题大了呢。
当然,我没有做过CTO,所以我有我的不同看法,而且还愿意表达出来,无知者无畏。
我情愿相信:
我所理解的CTO跟这位CTO所理解的是两回事。
所以我想,如果有人能把CTO的职责给标准化了,也许就不会有这么多的争论了。
同样的道理,关于架构师的定义,大家也有着不同的理解。
什么是架构师?
架构师有哪些职责?
我觉得有必要提前明确一下,要不然大家沟通起来也会产生类似问题,子说子理,卯说卯理,但是压根说得不是一码子事。
1什么是架构师
曾经有这么个段子:
甲:
我已经应聘到一家中型软件公司了,今天上班的时候,全公司的人都来欢迎我。
乙:
羡慕ing,都什么人来了?
甲:
CEO、COO、CTO、Allof程序员,还有会计、司机都来了。
乙:
哇,他们太重视你了,人才啊,这么多人迎接你!
甲:
没有啊,就一个人!
乙:
靠,#%¥$%...
很多的创业公司,一人身兼数职的情形还是很常见的。
至少,我是经历过的,一个人包办了所有的开发过程,连测试我都做了,绝对的一条龙,但是经常踩钢丝、骑独轮车总会有失足的时候,结果有一次,从我手里发出去的光盘母盘,含有病毒僵尸,以至于被迫收回已经推上市场的2万张光盘,从那之后,我的心脏就开始变得无比坚强,现在就是整个后台服务都瘫痪了,我也只是微微一笑。
其实,一个人身兼架构师和程序员,甚至多种角色,没什么不妥,后面还会讲这个话题,这种现象不是中国特色,跟国外是完全接轨的。
我曾经跟米国的一个工程师在msn中聊过类似的话题,发现他们的路子跟咱们没什么不同,在IT这个行业,我们跟世界的差距只有1天,他们刚弄出来的新东西,我们这里第2天保准见得到。
架构师这个称呼不是拍脑袋想出来的,是有国际标准(ISO/IEC42010)可查的。
架构师是软件开发活动中的众多角色之一,它可能是一个人、一个小组,也可能是一个团队。
微软对架构师有一个分类参考,我们参考一下,他们把架构师分为4种:
企业架构师EA(EnterpriseArchitect)、基础结构架构师IA(InfrastructureArchitect)、特定技术架构TSA(Technology-SpecificArchitect)和解决方案架构师SA(SolutionArchitect)。
微软的这个分类是按照架构师专注的领域不同而划分的。
EA的职责是决定整个公司的技术路线和技术发展方向。
盖茨给自己的Title就是首席软件架构师,网易丁磊也喜欢这么称呼自己,实际上就是EA角色;IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件,这些都是一个技术型公司传承下来的最宝贵的财富之一;特定技术架构师TSA,他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作;SA的工作则专于解决方案的规划和设计,“解决方案”这个词在中国已经到了严重泛滥的程度,大忽悠们最喜欢把它挂在嘴边。
所谓解决方案,就是把产品、技术或理论,不断地进行组合,来创造出满足用户需求的选择。
售前工程师一般都是带着它到客户那里去发挥的。
大公司会把各种类型的架构师分得很清楚,小公司一般就不那么讲究了,架构师多数是是IA+TSA+SA,一人包打天下,所以说大公司出专才,小公司出全才。
实际工作中,我们也经常会见到另一种比较简单的分类方式,把架构师分为软件架构师和系统架构师。
软件架构师基本上是TSA+IA,这也是程序员最容易突破,最可能走上的一条道路,比如JAVA架构师、DotNet架构师、LAPM架构师等等,我后面所讲的内容都是与软件架构师的相关的话题。
系统架构师实际上是SA+TSA,更着力于综合运用已有的产品和技术,来实现客户期望的需求。
系统架构师要求通晓软、硬件两方面的知识,所以它的知识体系相对庞杂。
关于系统架构师的话题,我们可以稍后再作讨论。
2架构师的职责
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调。
架构师主要职责有4条:
1、确认需求
在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可。
架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求。
2、系统分解
依据用户需求,架构师将系统整体分解为更小的子系统和组件,从而形成不同的逻辑层或服务。
随后,架构师会确定各层的接口,层与层相互之间的关系。
架构师不仅要对整个系统分层,进行“纵向”分解,还要对同一逻辑层分块,进行“横向”分解。
软件架构师的功力基本体现于此,这是一项相对复杂的工作。
3、技术选型
架构师通过对系统的一系列的分解,最终形成了软件的整体架构。
技术选择主要取决于软件架构。
WebServer运行在Windows上还是Linux上?
数据库采用MSSql、Oracle还是Mysql?
需要不需要采用MVC或者Spring等轻量级的框架?
前端采用富客户端还是瘦客户端方式?
类似的工作,都需要在这个阶段提出,并进行评估。
架构师对产品和技术的选型仅仅限于评估,没有决定权,最终的决定权归项目经理。
架构师提出的技术方案为项目经理提供了重要的参考信息,项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡,最终进行确认。
4、制定技术规格说明
架构师在项目开发过程中,是技术权威。
他需要协调所有的开发人员,与开发人员一直保持沟通,始终保证开发者依照它的架构意图去实现各项功能。
架构师与开发者沟通的最重要的形式是技术规格说明书,它可以是UML视图、Word文档,Visio文件等各种表现形式。
通过架构师提供的技术规格说明书,保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。
架构师不仅要保持与开发者的沟通,也需要与项目经理、需求分析员,甚至与最终用户保持沟通。
所以,对于架构师来讲,不仅有技术方面的要求,还有人际交流方面的要求。
3架构师的误区
1、架构师就是项目经理
架构师不是项目经理。
项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作,具备管理职能。
一般小型项目中,常见项目经理兼架构师。
2、架构师负责需求分析
架构师不是需求分析员。
需求分析人员的工作是收集需求和分析需求,并与最终用户、产品经理保持联系。
架构师只对最终的需求审核和确认,提出需求不清和不完整的部分,他会跟需求分析员时刻保持联系。
架构师是技术专家,不是业务专家。
3、架构师从来不写代码
这是一个尚存争论的问题。
目前有两种观点:
观点1:
架构师不写代码,写代码纯体力活,架构师写代码大材小用。
架构师把UML的各种视图交给开发人员,如果有不明确的地方,可以与架构师随时沟通。
观点2:
架构师本来自于程序员,只是比程序员站的层面更高,比程序员唯一多的是经验和知识,所以架构师也免不了写代码。
我个人觉得这两种说法是与架构师的出身和所处的环境有关。
架构师首先是一个技术角色,所以一定是来自于技术人员这个群体,比如系统架构师,多是来自于运维人员,可能本身代码写得并不多,或者说写不出来很漂亮的代码。
软件架构师多是来自于程序员,有着程序员的血统和情怀,所以在项目开发过程中,可能会写一些核心代码。
我们的理想是架构师不用写代码,但事实上有时候过于理想。
架构师写不写代码,可能取决于公司的规模、文化、开发人员的素质等现实情况。
另外,架构师也不是跟程序员界限分得那么清楚,按照能力也有高中低之分,写不写代码不是区分两者的根本标准。
4架构师的基本素质
周星驰有个片子《喜剧之王》,剧中的尹天仇整天揣着本《演员的自我修养》,一个好演员不仅需要天赋,也需要一定的理论指导,无师自通的人毕竟是少数。
架构师的成长过程也是这样。
从普通程序员到高级程序员,再到架构师,是一个经验积累和思想升华的过程。
经验积累是一个方面,素质培养是另一个方面,两者相辅相成,所以我觉得有必要把架构师的所要具备的素质罗列一下,作为程序员努力的方向。
沟通能力
为了提高效率,架构师必须
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 普通 程序员 晋升 架构
![提示](https://static.bdocx.com/images/bang_tan.gif)