高效程序员的45个习惯总结...

1. 不管路走了多远,错了就要重新返回

文章上来就引用了一句土耳其的谚语“不管路走了多远,错了就要重新返回”， 这个说的容易， 做起来真的很难， 尤其是已经做了很多的时候， 放弃真的很不舍得…所以在开发一个软件之前最好要把需求整明确了， 而且开发过程中过段时间就要停下来审视一下目前的工作符不符合需求， 也就是敏捷开发中常说的多和客户进行沟通， 及早发现问题， 修改起来代价也小…

说到开发过程中过段时间就要审视的问题， 我又想到之前遇到的问题， 就是开始时为了赶时间， 代码写的很乱， 有得直接copy一段过来， 不用的就注掉， 有些注释也都和代码不搭调， 一直想着开发完在去整理代码， 可是等开发完了， 也测试的差不多了， 这时候有时间了， 但发现现在不敢动代码了， 怕动出问题来， 也没那心思去整理了， 导致代码简直可以用惨不忍睹来形容…所以还是要在开发过程中一步一步走，一段时间后在回过头来重新review下代码， 格式上， 逻辑上都看看， 这样心里也踏实， 即使花上休息的时间也值得， 利人利己…

 

2. 敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善

你要不断从自己写的代码中得到反馈,并且使用自动化工具不断地构建(持续集成)和测试系统.在前进过程中,你都会有意识地修改一些代码:在功能不变的情况下,重新设计部分代码,改善代码的质量.这就是所谓的重构,它是软件开发中不可或缺的一部分---编码永远没有真正意义上的"结束".

要以迭代的方式进行工作:确定一小块时间(一周左右)的计划,然后按时完成它们.给客户演示每个迭代的工作成果,及时得到他们的反馈(这样可以保证方向正确),并且根据实际情况尽可能频繁地发布系统版本让用户使用.

  总之就是在开发的过程中不断的进行测试， 集成， show demo，收集反馈然后进行修改， 还有就是要不断的重构代码， 使代码更健壮， 高效和易读…

 

3. 选定了要走的路,就是选定了它通往的目的地.

   说到这个， 我不禁回想一下自己现在的处境， 记得在上研究生之前自己最喜欢的方向是PC端的互联网， 就是路由器， 网络拓扑结构啥的， 感觉很神奇， 但是来到学校， 做的项目都是和手机相关的， 也就稀里糊涂的到了移动互联网行业， 想想挺好的， 现在特别喜欢这个方向。

   这一章节还有一段是这么说的” 有一种相当流行的软件方法学要求对一个项目分配35种不同的角色,包括架构师、设计人员、编码人员、文档管理者等.敏捷方法却背道而驰.只需要一个角色:软件开发者,也就是你.项目需要什么你就做什么,你的任务就是和紧密客户协作,一起开发软件.敏捷依赖人,而不是依赖于项目中的甘特图和里程表.” 这可能就是要求每个开发人员不仅要会编程， 还要会一个产品开发过程中需要的其它的一些技能， 以能够适应各种角色… 最近我就在看一些交互设计， 用户体验方面的文章， 多少懂点， 对开发出一些用户体验很好的产品还是很有利的， 我发现开发人员和用户的想法真的很不同， 我们总觉得这个功能用户怎么可能不会呢， 但是给用户试用的时候发现就是不会， 看来这个不能想当然…

   最近学习交互设计和用户体验最大的感受就是四个字“简单易用”， 当然简单和功能强大并不冲突， 后台你可以做的很复杂， 功能很强大， 但前台给用户展现的一定要是一个简洁， 易用的UI， 而且一定要快速响应用户的操作…（一点点感受啦， 很不专业）

 

4. 做事---指责不能修复Bug

   文章中原话：//start

   "出了问题,第一重要的是确定元凶.找到那个白痴!一旦证实了是他出的错误,就可以保证这样的问题永远不会再发生了."

有时候,这个老魔头的话听起来似乎很有道理.毫无疑问,你想把寻找罪魁祸首设为最高优先级,难道不是吗?肯定的答案是:不.最高优先级应该是解决问题.

  如果你说的话只是让事态更复杂,或者只是一味地抱怨,或者伤害了他人的感情,那么你无意中在给问题火上浇油.相反,你应该另辟蹊径,问问"为了解决或缓解这个问题,我能够做些什么?"在敏捷的团队中,大家的重点是做事.你应该把重点放到解决问题上,而不是在指责犯错者上纠缠.

在敏捷团队中,情形截然不同.如果你向敏捷团队中的同事抱怨,他们会说:"好,我能帮你做些什么呢?"他们把精力直接放到解决问题上,而不是抱怨.他们的动机很明确,重点就是做事.不是为了自己的面子,也不是为了指责,也无意进行个人智力角斗. //end

   嗯， 这点上真的要反思了， 出了问题， 首要的是去解决问题， 而不是在谁造成了这个问题上纠结， 伤了和气还解决不了问题…以后要注意， 尽管现在我还没责备他人的资格~_~…

 

5. 勇于承认自己不知道答案,这会让人感觉放心.一个重大的错误应该被当作一次学习而不是指责他人的机会.团队成员们在一起工作,应该互相帮助,而不是互相指责.

   嗯， 所以做人还是要低调些， 这样犯了错误也容易去承认， 省的下不了台， 死要面子活受罪（好像这感概有些跑题J）…

 

6. 如果你没有犯过任何错误,就说明你可能没有努力去工作.

   这话说的太对了， 所以当自己的错误比别人少时， 也不要沾沾自喜， 而是要反思一下为什么会比别人少， 是自己做的也少吗？

 

7. 开发者和质量工程师(QA)争论某个问题是系统本身的缺陷还是系统增强功能

导致的,通常没有多大的意义.与其如此,不如赶紧去修复它.

   这个跟上面说的差不多， 总之就是发现了问题， 少去抱怨， 赶紧去修复

bug…

 

8. 如果一个团队成员误解了一个需求、一个API调用,或者最近一次会议做的决

策,那么,也许这团队的其他成员也有相同的误解.要确保整个团队尽快消除误解.

 

9．防微杜渐

    文章原话：//start

我们经常会遇到这种情况,出现了一个bug,并且时间迫切.快速修复确实可以解决它---只要新加一行代码或者忽略那个列表上的最后一个条目,它就可以工作了.但接下来的做法才能说明,谁是优秀的程序员,谁是拙劣的代码工人.

拙劣的代码工人会这样不假思索地改完代码,然后快速转向下一个问题.

优秀的程序员会挖掘更深一层,尽力去理解为什么这里必须要加1,更重要的是,他会想明白会产生什么其他影响.

千里之堤,毁于蚁穴,大灾难是逐步演化来的.一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽地,最终会吞噬整个项目中的生命.

只要我们继续进行快速修复,代码的清晰度就不断降低.一旦问题累计到一定

度,清晰的代码就不复存在,只剩一片浑浊. //end

  嗯， 说的很对， 自己以前就是那种边调试边修改的， 导致最后每个if（）里面的条件N多 && or ||， 自己都不想再看了…但是如果时间真的很紧， 该怎么办， 感觉还是得修修补补， 需要注意的是测试的时候不仅要测要改的bug fixed掉了没， 还要做下系统的测试， 省的发生那种拆西墙补东墙的情况…总之这个全看时间去权衡， 如果时间不紧， 一定要去找到问题的根源， 而不是简单的填堵…

 

10. 不要坠入快速的简单修复之中.要投入时间和精力保持代码的整洁、敞亮。

   在项目中，代码应该是很亮堂的，不应该有黑暗死角。你也许不知道每块代码的每个细节，或者每个算法的每个步骤，但是你对整体的相关知识有很好的了解。没有任何一块代码被警戒线或者"切勿入内"的标志隔离开.

 

11. 对事不对人

在团队讨论中， 不要去说一些否定他人个人能力的话， 而是要简单的表达一下自己的观点， 抱着一种和他们探讨的心态…让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。

我最早听这个说法“对事不对人”还是在阿里2010年校招时听当时的CEO卫哲说的， 当时感觉很有启发， 这也让我对卫哲很欣赏， 他口才不是一般的好…在和同事讨论问题时， 即使发生争吵， 也要把争吵点放在问题上， 而不是搞人身攻击， 在争吵过后， 还是要和以前一样共处， 而不要耿耿于怀…

 

12. 我们每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住，任何一个专家都是从这里开始的。用Les Brown的一句话说就是：“你不需要很出色才能起步，但是你必须起步才能变的很出色。”

 

13．设定最终期限

如果你正在参加设计方案讨论会，或者是寻找解决方案是遇到问题，请设定一个明确的最终期限，例如午饭时间或者一天的结束。这样的时间限制可以防止人们陷入无休止的理论争辩中，保证团队工作的顺利进行。同时（我们觉得）应现实一些：没有最好的答案，只有更适合的方案。设定期限能够帮你在为难的时候果断做出决策，让工作可以继续进行。

 

14. 尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。也不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。

 

15. 如果设计或代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决的办法，但代码仍然另人费解，唯一的解决办法就是重构代码，让他可读性更强。如果你没有马上理解那段代码，不要轻易的否定和重写他们。那不是勇气，而是鲁莽。

 

16. 学无止境

软件开发行业是一个不停发展和永远变化的领域。虽然有一些概念一直有用，但还有很多只是很快就会过时。从事软件开发行业就像是在跑步机上，你必须一直跟上步伐稳步前进，狗则就会摔倒出局。

谁会帮助你保持步伐前进呢？在一个企业化的社会中，只有一个人会为你负责------那就是你自己。是否能跟上变化，完全取决于你自己。

 

17. 跟踪变化—跟上技术发展的步伐

迭代和增量式学习：每天计划用一段时间来学习新技术，它不需要很长时间，但需要经常进行。记下哪些你想学习的东西-------当你听到一些不熟悉的术语或者短语时，简要地把它记录下来。然后再计划时间去深入研究它。

了解最新行情：互联网上有大量关于学习新技术的资源。阅读社区讨论的和邮件列表，可以了解其他人遇到的问题，以及他们发现的很酷的解决方案。额一些公认的优秀技术博客，经常去读一读，以了解那些顶尖的博客作者们在关注什么。（//感想：嗯， 现在我每天都花上1个小时左右的时间看IT相关的资讯， 平时经常看cnBeta，CSDN, 腾讯科技， 互联网的那点事， 月光博客， 除了这些网站或是博客， 还有腾讯微博和新浪微博， 收听一些IT名人的微博， 能了解到很多国内国外的行情）

如饥似渴的阅读:找一些关于软件开发和非技术主题的好书,也可以是一些专业的期刊和商业杂志，甚至是一些大众媒体新闻（有趣的是在那些常常能看到老技术被吹捧为最新潮流）。(//感想： 嗯， 最近在网上下了好多程序员修养的书籍， 都还没看， 准备以后抽时间把这些书都看掉， 我觉得缺少的就是程序员职业修养， 视角太过狭窄， 所以想多看点这方面指导的书籍启发启发， 《高效程序员的45个习惯》是第一本阅读的书， 还有几本如《疯狂的程序员》， 《人月神话》， 《程序员自我修养》， 《程序开发心理学》， 《软件开发沉思录》， 《软件随想录》， 《人件》， 当然这些我都还没看， 只是看着名字， 觉得应该还可以， 以后都要看掉)

参加研讨会议：计算机大会在世界各地举行，许多知名的顾问或者作者支持研讨会或者课程。这些聚会时向专家学习的最直接的好机会。

 

18. 每个人都比你厉害吗？嗯，那太好了…

为什么是这样呢？如果你是团队中最好的队员，就没有动力继续提高自己。如果周围的人都比你厉害，你就会有很强的动力区追赶他们。你将会在这样的游戏中走向自己的顶峰…

   所以遇到比你强的人要放平心态， 努力学习他人长处， 早日超越…

 

19. 学习新的东西，丢弃旧的东西

在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强得多。

 

20. 不停的问为什么

不能只满足于别人告诉你的表面现象，要不停地提问知道你明白问题的根源。

----为什么要问为什么呢， 开个玩笑， 嘿嘿…

 

21. 时间盒

   文章原话 //start

敏捷开发者可以从多方面得到反馈：用户、团队成员和测试代码。这些反馈会帮助你驾驭项目。但是时间本身就是一个非常重要的反馈。

许多的敏捷技巧来源于时间盒-----设定一个短时的期限，为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务，但是最终期限是不变的。你可能不知道完成所有的任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标。

例如，迭代一般是两周的时间。当时间到的时候，迭代就完成了。那部分是固定不变的，但是在一个具体的迭代中完成哪些功能是灵活的。换句话说，你不会改变时间，但是你可以改变功能。相似地，你会为设计讨论会设定一个时间盒，即到了指定的时间点，会议结束，同时必须要做出最终的设计决策。

当你遇到艰难抉择的时候，固定的时间期限会促使你做决定。你不能在讨论或功能上浪费很多时间，这些时间可以用于具体的工作。时间盒会帮助你一直前进。//end

   嗯， 给自己限定一个时间， 会督促自己去赶紧完成…

 

22. 让设计指导而不是操纵开发

设计满足实现即可，不必过于详细：好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。（如何知道一个设计是好的设计，或者正合适？代码很自然地为设计的好坏提供了最好的反馈。如果需求有了小的变化，它仍然容易去实现，那么它就是好的设计。而如果小的需求变化就带来一大批基础代码的破坏，那么设计就需要改进）

关于上面那段描述什么是好的设计的时候， 虽然说是那么说， 但是如何做到？自己理解的就是要做到代码的可复用性强吧， 在设计类的时候每个类都有一个特定的功能， 而不是集各种功能于一身， 同样， 每个函数的功能也都要尽量的单一， 用这些单一功能的函数去组合完成一个较大些的功能， 当这个较大些的功能需要改变时， 只需要改变一下这个小的功能函数的组合方式即可， 而不用去改底层的函数…晕， 这个我也没经验， 只是自己的一点想法， 还得学习…

 

23. 代码提早集成.频繁集成.代码集成是主要的风险来源.要想规避这个风险.只有提早集成.持续而有规律地进行集成.

 

24. 倾听用户的声音

“用户就是会抱怨，这不是你的过错，是用户太愚蠢了，连使用手册都看不懂。它不是bug，只是用户不明白如何使用而已，他们本应该知道更多”。

  Stupid user…所以不要想当然的去认为用户应该会怎么怎么样，尽量去引导用户，简化交互流程，做到简洁优雅…

 

25. 敏捷代码

开始看起来非常正常的项目,是什么让它最终变得难以掌控?开发人员在完成任务时,可能会为节省时间而走”捷径”.然而,这些”捷径”往往只会推迟问题的爆发时间,而不是把它彻底解决掉.当项目时间上的压力增加时,问题最终还是会在项目团队面前出现,让大家心烦意乱.

如何保证项目开发过程中压力正常,而不是在后期面对过多的压力,以致噩梦连连呢?最简单的方式,就是在开发过程中便细心”照看”代码.在编写代码时,每天付出一点小的努力,可以避免代码”腐烂”,并且保证应用程序不至变得难以理解和维护.

   嗯， 每天抽出一点时间整理下代码， 让代码看起来漂亮些， 不要整到最后一团糟…

 

26. 开发代码时,应该更注重可读性,而不是只图自己方便.代码阅读的次数要远远超过编写的次数和,所以在编写的时候值得花点功夫让它读起业更加简单.实际上,从衡量标准上来看,代码清晰程度的优先级应该排在执行效率之前.

 

27.用代码沟通

   应该文档化你所有的代码吗?在某种程度上说,是的.但这并不意味着要注释绝大部分代码,特别是在方法体内部.源代码可以被读懂,不是因为其中的注释,而应该是由于本身优雅而清晰------变量名运用正确.空格使用得当,逻辑分离清晰,以及表达式非常简洁.

如何命名很重要,程序元素的命名是代码读者必须的部分.通过使用细心挑选的名称,可以向阅读者传递大量的意图和信息.反过来讲,使用人造的命名范式会让代码难以阅读和理解.这些范式中包括的底层数据类型信息.会硬编码在变量名和方法名中.形成脆弱,僵化代码,并会在将来造成麻烦.

 

28．在编写代码的时候，要经常留心可以改进的微小方面。这可能会改善代码的可读性。也许你会发现可以把一个方法拆成几个更小的方法，使其变得更易于测试

 

29. 优雅的代码第一眼看上去，就知道它的用处，而且很简洁。但是这样的解决方案不是那么容易想出来的。这就是说，优雅是易于理解和辨识的，但是要想创建出来就困难多得多了。

 

30.  让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。

 

31. 记录问题解决日志

面对问题（并解决它们）是开发人员的一种生活方式。当问题发生时，我们希望赶紧把它解决掉。如果一个熟悉的问题再次发生，我们会希望记起第一次是如何解决的，而且下午下次能够更快地把它搞定。然而，有时一个问题看起来跟以前遇到的完全一样，但是我们却不记得是如何修复的了。这种状况时常发生…

这就需要我们维护一个保存曾遇到的问题以及对应解决方案的日志。这样，当问题发生时，就不必说：“嘿，我曾碰到过这个问题，但是不记得是怎么解决的了。”

  可以使用一下格式来记录：

u      问题发生日期。

u      问题简述。

u      解决方案详细描述。

u      引用文章后网址，以提供更多细节或相关信息。

u      任何代码片段、设置后对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。

 

32. 警告就是错误

忽略编译器的警告信息继续开发代码，会导致什么状况呢？这样做等于是坐在了一个嘀嗒作响的定时炸弹上，而且它很有可能在最糟糕的时刻爆炸。所以，不要无视警告信息，可能会导致问题的都要fix掉…