优秀的程序员和一般的程序员差别在哪.docx
- 文档编号:27987327
- 上传时间:2023-07-07
- 格式:DOCX
- 页数:10
- 大小:477.61KB
优秀的程序员和一般的程序员差别在哪.docx
《优秀的程序员和一般的程序员差别在哪.docx》由会员分享,可在线阅读,更多相关《优秀的程序员和一般的程序员差别在哪.docx(10页珍藏版)》请在冰豆网上搜索。
优秀的程序员和一般的程序员差别在哪
优秀的程序员和一般程序员的差别
优秀的会计和一般会计的差别
优秀的编辑和一般编辑的差别
优秀的设计师和一般设计师的差别
........
在任何一个领域,优秀者总是拥有比平庸者更多甚至多得多的好习惯。
而最重要的好习惯,是动手之前先思考。
昨天我们带孩子去听一场钢琴独奏音乐会,演奏者是一位天才少年。
少年在演奏每一首曲子前,都会把手放在膝盖上,静默十余秒,我们知道那是在脑海中迅速地对他要演奏的曲子“过电影”,这便是思考。
然后他的大脑便驾驭着他的双手,奏出美妙的乐曲。
每次带孩子学琴,德高望重的银发钢琴老师都喜欢和我们点评前后学琴的孩子,他最夸奖的,是一位坐上琴凳后,会静静地等几秒钟才开始弹奏的小姑娘,老师说,10个琴童中难得挑出一个这样的孩子。
我们家的孩子性子躁,但也在老师每每的严格要求下,被训练着能在急于动手开始弹奏前,先双手放在膝盖上,静默数秒——思考要弹奏的曲子的难点、节奏,开始和结尾。
只要女儿能做到这一点,她的弹奏都会得到老师的夸奖,但有时她心浮气躁,坐到琴旁就开始弹奏,琴声也带着躁性,这时就会被老师喝止。
大家常说能坚持练琴的孩子,做什么都会更有耐心。
我们这些家长对此是认同的,身为学琴6年的女儿的家长,我们对比了不同的老师,现在这位老师才是我们最满意的,因为他会狠抓女儿的基本功,而此前的几位老师对基本功都有些忽视,这使得女儿越是弹奏难度高的曲子,越是能发现基本功不扎实带来的苦恼,所以回过头还是要补这些基本功,侥幸不得。
因此,今年考8级(业余)的女儿,一边练习有难度的乐曲,一边丝毫不敢掉以轻心地每天按照老师的要求弹奏练习曲。
周鸿祎写过一篇文章:
以色列军队是世界上最好的孵化器
文中提到:
以色列军队中有一种很特别的现象,基础训练给所有士兵设定了许多必须服从的条条框框。
但当你成为一名下级军官以后,就需要学会自己思考解决问题。
另外,即使基础训练使你具备了执行任务的基本条件,但要完成任务,必须要发挥自己的创造力。
不少人会看重上面这段话后面提到的创造力,在这里我感触更深的是“基础训练给所有士兵设定了许多必须服从的条条框框”这句话——这说明先约束、先有诸多规矩,是日后能发挥创造力的基础,这和我们中国练书法要求先一丝不苟练习楷书,到有一定基础了才能修习行书乃至草书是一个道理。
在中国IT行业的“好工程师”应该是什么样的?
有哪些客观标准可供自我评估?
这个回答中,列出了软件工程师能力自我评价表(37条)。
优秀还是一般,看看37条做到了多少。
在构建之法——现代软件工程这本书的第三章软件工程师的成长里,作者写了一节技能的反面:
【软件工程师的成长】练习与讨论也很有意思:
1选哪一种医生
作为一个软件工程师,你觉得自己表现如何?
有没有这样的体会:
看书的时候觉得“技止此耳”,开发项目的时候才觉得实际情况和书上讲的都有一些出入,一些重要的细节书上没有提。
我们很多人是边看http:
//A的书,边开发http:
//A的项目,这相当于一边看医学书一边动手术……
如果你是病人,你希望你的医生是下面的哪一种呢?
a)刚刚在书上看到你的病例,开刀的过程中非常认真严谨,时不时还要停下来翻书看看……
b)富有创新意识,开刀时突然想到一个新技术、新的刀法,然后马上在你身上试验……
c)已经处理过很多类似的病例,可以一边给你开刀,一边和护士聊天说昨天晚上的《非诚勿扰》花絮……
d)此医生无正式文凭或正式医院的认证,但是号称有秘方,可治百病。
事实上,很多软件项目就是用a)或者b)这样的方法搞出来的。
当然也有一些人走d)这条路。
讨论:
①你要选哪种类型的医生?
②医生、药剂师、律师和很多行业都有职业考试和职业证书,软件工程师需要有正式的职业证书才能上岗么?
请参考SteveMcConnell的观点[i]。
2工程还是艺术
软件开发是一门工程(Engineering),是一门艺术(Art),还是一门手艺(Craftmanship)?
你如何衡量艺术家?
如何衡量创造能力?
如果是一门工程,那工程师要守规矩;如果是一门艺术,那艺术家要创新。
∙写诗歌最多的人是谁?
∙最有创造力的诗人是谁?
一些最有影响力的作家,他们的作品都非常少,甚至只有一本,例如:
∙《飘》(GonewiththeWind)作者MargaretMitchel[ii]
∙《红楼梦》,作者曹雪芹(这一本据说都没写完!
)
另外,优秀的作品往往并不符合所有“好”的标准。
例如,找出下面这首词中重复的字:
念奴娇·赤壁怀古-苏轼
大江东去,浪淘尽,
千古风流人物。
故垒西边,人道是,三国周郎赤壁。
乱石崩云,惊涛裂岸,卷起千堆雪。
江山如画,一时多少豪杰。
遥想公谨当年,小乔初嫁了。
羽扇纶巾,谈笑间,樯橹灰飞烟灭。
故国神游,多情应笑我,早生华发。
人生如梦,一樽还酹江月。
出现了三遍的字有:
江,人;出现了两遍的字有:
国,生,千,故,如。
这符合“好词”的标准么?
南宋人俞文豹评价道:
今人看人文字,未论其大体如何,先且指点重字。
软件设计工程师们在做代码复审的时候,是看“重复字”的多少,还是程序的艺术性?
这个问题的另一个侧面是,在中国,一个成名的歌唱家往往出现在各种场合,演唱她当年成名的作品,观众们往往显得百听不厌。
一个软件工程师就不能这样,在舞台上展现他当年写的“helloworld”程序,或者是1.0的产品。
为啥有这样的区别呢?
3绞刑架和职业发展
移山公司的人力资源总监给同学们做了职业发展的演讲,大意是随着软件工具和软件工程理论的发展,开发软件将会越来越容易,软件企业的水平都是CMMi4级以上。
软件白领的生活指日可待,金领也不是梦,大家前途无可限量,学软件工程的同学越来越多,就是明证。
大家纷纷鼓掌。
最后他分享了一个故事:
两个劫匪在亡命的路上看到一副绞刑架,劫匪小弟说,大哥,如果这世界上没有绞刑架,咱们的职业就好干多了。
大哥说:
你真笨!
如果没有了它,这世上做劫匪的人怕是太多,我俩恐怕竞争不过同行,早就饿死了!
请同学们思考这个故事对个人及软件业发展的启示。
4案例
程序员小飞原计划三天完成某个任务,现在是第三天的下午,他马上就可以做完。
但是在实现功能的过程中,他越来越意识到自己原来设计中的弱点,他应该采取另一个办法,才能避免后面集成阶段的额外工作。
但是他如果现在就改弦更张,那势必要影响自己原来估计的准确性,并且会花费额外的时间,这样他的老板,同事会因此看不起他。
如果他按部就班,最后整个团队还要花更多时间在后续集成上,但那就不是他个人的问题了。
怎么办?
5成长和代码量的关系
软件工程师的工作就是写代码,相关专业的练习也是以阅读代码,写代码为主,那么代码量和工程师的水平是线性的关系么?
这个问题有人还研究过:
程序员的成长和代码行数的关系(翻译)
NorrisNumbers(原文)
当代码是在2,000行以下,程序员可以用“写了再改”的蛮干方法,并且靠记忆力搞定一个程序,但是,如果你的代码规模达到20,000行,你要用结构化编程(类,模块,API,细节隐藏,面向对象的其它方法,等)来保证程序不变成一团乱麻。
如果代码规模再大一个数量级,20万,200万呢?
[i]ProfessionalSoftwareDevelopment,ISBN0-321-19367-9作者:
SteveMcConnell,出版社:
Addison-Wesley
[ii]参见:
MargaretMitchell
在我平时所见到的程序员中,如果纯以编码能力来看,个人觉得可以分为五类,依次是:
1.拷贝型
拷贝型选手就是传说中的“代码拷贝员”了,他们对实现功能几乎没有思路,所作的事情就是从网上或是之前其他团队成员写的代码中拷贝出片段,然后放到项目中,如果运行项目出现了期望结果,则表示任务完成。
这类人只会改代码,却不会写代码。
他们大多对编程毫无兴趣,只是希望以此糊口而已。
2.新手型
当产品有功能需求时,由于经验有限,程序员并不完全知道要如何实现这个功能,需要通过学习、寻找资料等方式来解决问题。
这种情况下的编码过程,程序员的主要目标是“完成功能”,那么很难有多余的心思去考虑边界条件、性能、可读性、可扩展性、编码规范等问题,因此代码bug可能较多,稳定性不高。
常常会发生开发花费1个月,改bug却要改上好几个月的事情。
3.学习型
这类程序员对所在领域的语言已经比较了解,对于一般功能可以有较为清晰的实现思路,给出需求时可以通过自己的思路来实现,并且会一定程度上考虑边界条件和性能问题。
但仅此而已,他们对可读性和可扩展性考虑很少,也没有项目级别的考虑,主要是希望通过实现代码来练手或是学习。
这类程序员最大的表现在于喜欢“创造代码”,即使有现成的实现,他们也希望自己来实现一套,以达到“学习”的目的。
他们不喜欢复用别人的代码,看见项目中别人实现了相类似的功能,他们会以“需求不同”的借口来自己重新实现一套。
这类人一般来说对技术有着较为浓厚的兴趣,希望能够通过项目来进行学习。
从项目的角度来说,这种做法最大的麻烦在于开发周期可能较长(相比直接使用现成的实现),并且会使得项目代码膨胀,影响未来的维护。
但这类程序员由于有兴趣,如果好好培养或许会成为明天的牛人。
4.实现型
这类程序员一般有较为丰富的经验,由于写得太多,因此不再追求“创造代码”来进行学习,同时对所在领域可能涉及的很多第三方框架或是工具都比较熟悉,当接受到产品需求时,对功能实现方案已经了然于胸,因此他们可以快速的实现需求,并且对边界、性能都有一定程度的考虑。
因为能够快速实现需求功能,经常会被团队评价为“牛人”。
但他们一般仅仅停留在“完成功能”级别上,对代码的可读性、可扩展性、编码规范等考虑较少,对项目总体把握也较少(例如控制项目膨胀、方便部署等架构级别的东西)。
这类程序员最大的表现在于喜欢“开发项目”,却不喜欢“维护项目”。
他们产出的代码最大的问题就是维护较为困难,可能过上几个月回头看自己的代码都会晕头转向。
因此即使是自己写的代码,仍然不愿意维护,一般会苦了后来人。
因为接口设计的缺乏,当需求变更时,发现代码要改的东西太多,然后抱怨需求变化,却很少认为是自己的代码问题。
这样的项目如果经过长时间的变更维护,最终会变得难以维护(一般表现在需求变更响应时间越来越长)甚至无法维护,最终要么是半死不活,要么是被推倒重来。
5.架构型
这类程序员比实现型更进一步,他们经验丰富,对相关框架和工具等都很熟悉,“完成功能”“稳定性”“性能”这些已经不再是他们的追求,更优美的代码、更合理的架构才是目标。
这类程序员代码设计大多建立在对需求的详细了解和对需求变更的预测上——可扩展性较好;代码细节也尽量多的考虑边界情况、性能——稳定高效;代码命名和注释都恰到好处——可读性较高;同时在开发过程中他们会不断重构,对代码做减法——保证项目可持续发展;等等
但由于考虑问题较多,单从“实现功能”阶段来看,完成速度不一定会比“实现型”要快。
只是到了项目中后期优势才会慢慢体现出来
也许还有更优秀的程序员我没有见过,呵呵,欢迎大家补充
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 优秀 程序员 一般 差别
![提示](https://static.bdocx.com/images/bang_tan.gif)