高效程序员的45个习惯

度决定一切

  • (1) 做事,把矛头对准问题的解决办法,而不是人,这是真正有用处的正面效应
  • (2)欲速则不达,要投入时间和精力保持代码的整洁、敞亮
  • (3)对事不对人,让我们骄傲的应该是解决了问题,而不是比较出谁的主意更好。
  • (4)排除万难,奋勇前进,要诚实有勇气去说出实情,有时候这样做很困难,所以我们需要有足够的勇气

    学无止境

  • (5) 跟踪变化,不需要精通所有技术,但需要清楚知道行业的动向,从而规划你的项目和职业生涯。

  • (6)对团队投资,通过午餐会议可以增进每个人的知识和技能,并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的激情,将会对项目大有裨益。

  • (7)懂得丢弃,在学习一门新技术的时候,要丢去会阻止你前进的旧习惯。毕竟,汽车要比马车强得多。

  • (8)打破沙锅问到底,不能只满足与别人告诉你的表面现象。要不停地提问直到你明白问题的根源。

  • (9)把握开发节奏,保持时间之间稳定重复的间隔,更容易解决常见的重复任务
      

    交付用户想要的软件

  • (10)让客户做决定,开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言,向他们详细解释遇到的问题,并让他们做决定。

  • (11)让设计指导而不是操纵开发,设计指引你向正确的方向前进,它不是殖民地,它不应该标识具体的路线。你不要被设计(或者设计师)操控。

  • (12)合理地实用技术,首先决定什么是你需要的,接着为这些具体的问题评估使用技术,对任何要使用的技术,多问一些挑剔的问题,并真实地作出回答。新技术就应该像是新的工具,可以帮助你更好地工作,她自己不应该是成为你的工作。

  • (13)保持可以发布,保证你的系统随时可以编译、运行、测试并立即部署。

  • (14)提早集成,频繁集成,代码集成式主要的风险来源。要想规避这个风险,只有提早集成,持续而有规律地进行集成。

  • (15)提早实现自动化部署,使用部署系统安装你的应用,在不同的机器上用不同的配置文件测试依赖问题。质量保证人员要像测试应用一样测试部署。

  • (16)使用演示获得频繁反馈,在开发的时候,要保持应用可见(而且客户心中也要了解)。每隔一周或者两周,邀请所有客户,给他们演示最新完成的功能,积极获得他们的反馈。

  • (17)使用短迭代,增量发布,发布带有最小却可用功能块的产品。每个增量开发中,使用1~4周左右的迭代周期。

  • (18)固定的价格就意味着背叛承诺,让团队和客户一起,真正地在当前项目中工作,做具体实际的评估。由客户控制他们要的功能和预算。
      

    敏捷反馈

  • (19)守护天使,好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试,不要进行任何的设计和代码修改。

  • (20)先用它再实现它,使用测试驱动开发作为设计工具,它会为你带来更简单更实效的设计。

  • (21)不同环境,就有不同问题,使用持续集成工具。在每一种支持的平台和环境中运行单元测试。要积极地寻找问题,为不是等问题来找你。

  • (22)自动验收测试,为核心的业务逻辑创建测试,让你的客户单独验证这些测试,要让它们像一般的测试一样可以自动运行。

  • (23)度量真实的进度,不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。

  • (24)倾听用户的声音,每一个抱怨的背后都隐藏了一个事实,找出真相,修复真正的问题。
      

    敏捷编码

  • (25)代码要清晰地表达意图,向代码阅读者明确表明你的意图。可读性差的代码一点也不聪明。

  • (26)用代码沟通,使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。

  • (27)动态评估取舍,考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了,就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅,而将设计复杂化。

  • (28)增量式编程,在很短的编辑/构建/测试循环中编写代码,这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。

  • (29)保持简单,除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术之类的东西。

  • (30)编写内聚的代码,让类的功能尽量集中,让组件尽量小。要避免创建很大的类或组件,也不要创建无所不包的大杂烩类。

  • (31)告知,不要询问,不要抢别的对象或者是组件的工作。告诉它做什么,然后盯着你自己的指责就好了。

  • (32)根据契约进行替换,通过替换遵循接口契约的类,来添加并改进功能特性。要使用更多的委托而不是继承。
      

    敏捷调试

  • (33)记录问题解决日志,保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。

  • (34)警告就是错误,签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。

  • (35)对问题各个击破,在解决问题时,要将问题域与周边隔离开。特别是在大型应用中。

  • (36)报告所有的异常,不要将它们压制不管,就算是临时这样做也不行,在写代码时要估计到会发生的问题。

  • (37)提供有用的错误信息,提供更多易于查找错误细节的方式,发生问题时,要展示出尽量多的支持细节,不过别让用户陷入其中。
      

    敏捷协作

  • (38)定期安排会面时间。使用立会(站着开的会议)可以让团队达成共识。保证会议短小精悍不跑题。

  • (39)架构师必须写代码。优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况。是无法展开设计的。

  • (40)实行代码集体所有制。让开发人员轮换完成系统不同领域中不同模块的不同任务。

  • (41)成为指导者。分享自己的知识很有趣——付出的同时便有收获。还可以激励别人获得更好的成果,而且提升了整个团队的实力。

  • (42)允许大家自己想办法。指给他们正确的方向,而不是直接提供解决方案。每个人都能从中学到不少东西。

  • (43)准备好后再共享代码。绝对不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码,对项目来说,应该被视作为玩忽职守的犯罪行为。

  • (44)做代码复查。对于提升代码质量和降低错误率来说,代码复查是无价之宝。如果以正确的方式进行,复查可以产生非常实用而高效的成果。要让不同的开发人员在每个任务完成后复查代码。

  • (45)及时通报进展与问题。发布进展状况,新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。

2015-10-20 19:5344