登录站点

用户名

密码

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

已有 1353 次阅读  2014-01-15 15:47   标签程序员 

一、敏捷——高效软件开发之道 

 

  • 敏捷的精神:它要求团队中的每一个人(包括与团队合作的人)都具备职业精神,并积极地期望项目能够获得成功。它并不要求所有人都是有经验的专业人员,但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。 
  • 敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。 

二、态度决定一切 

 

1、 做事

  • 符合标准不是结果。敏捷团队重结果胜于重过程。 
  • 指责不能修复bug 。把矛头对准问题的解决办法,而不是人。

2、 欲速则不达

  • 不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。 
  • 不要急于修复一段没能真正理解的代码。这种 +1/-1  的病症始于无形,但是很快会让代码一团糟。要解决真正的问题,不要治标不治本。 
  • 所有的大型系统都非常复杂,因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外,你还需要从更高的层面来了解大部分代码的功能,这样就可以理解系统各个功能块之间是如何交互的。

3、 对事不对人

  • 我们每个人都能有一些极好的创新想法,同样也会萌生一些很愚蠢的想法。 
  • 脱离实际的反方观点会使争论变味。若对一个想法有成见,你很容易提出一堆不太容易发生或不太实际的情形去批驳它。这时,请先扪心自问:类似问题以前发生过吗?是否经常发生?

4、 排除万难,奋勇前进 

  • 做正确的事。要诚实,要有勇气去说出实情。有时,这样做很困难,所以我们要有足够的勇气。

三、学无止境 

 

5、 跟踪变化

  • 跟踪技术变化。你不需要精通所有技术,但需要清楚知道行业的动向,从而规划你的项目和职业生涯。 
  • 许多新想法从未变得羽翼丰满,成为有用的技术。即使是大型、热门和资金充裕的项目也会有同样的下场。你要正确把握自己投入的精力。

6、 对团队投资

  • 你参加了一个课程或者研讨班之后,所学的知识如果不用,往往就会忘记。所以,你需要和其他团队成员分享所学的知识,把这些知识引入团队中。 
  • 坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

7、 懂得丢弃

  • 打破旧习惯很难,更难的是自己还没有意识到这个问题。丢弃的第一步,就是要意识到你还在使用过时的方法,这也是最难的部份。

8、 打破沙锅问到底

  • 不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。 
  • 你可能会跑题,问了一些与主题无关的问题,这样的问题是没有任何帮助的。要问到点子上。

9、 把握开发节奏

  • 解决任务,在事情变得一团糟之前。保持事件之间稳定重复的间隔,更容易解决常见的重复任务。 
  • 在每天结束的时候,测试代码,提交代码,没有残留的代码。

四、交付用户想要的软件

 

10、 让客户做决定

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

11、 让设计指导而不是操纵开发

  • 一旦开始了编码,一切都会改变。设计及其代码实现会不停地发展和变化。 
  • 好的设计应该是正确的,而不是精确的。也就是说,它描述的一切必须是正确的,不应该涉及不确定或者可能会发生变化的细节。它是目标,不是具体的处方。
  • 即使初始的设计到后面不再管用,你仍需设计:设计行为是无价的。正如美国总统艾森豪威尔所说:“计划是没有价值的,但计划的过程必不可少。”在设计过程中学习是有价值的,但设计本身也许没有太大的用处。

12、 合理地使用技术

  • 考虑引入新技术或框架之前,要先考虑几个方面:
    • 这个技术框架真能解决这个问题吗?
    • 你将会被它拴住吗?一些技术是贼船,一旦你使用了它,就会被它套牢,再也不可能回头了。
    • 维护成本是多少?
  • 每一门技术都会有优点和缺点,无论它是开源的还是商业产品、框架、工具或语言,一定要清楚它的利弊。

 

13、 保持可以发布

  • 任何时候只要你没有准备好,那就是敌人进攻你的最佳时机。 
  • 在团队里工作,修改一些东西的时候必须很谨慎。你要时刻警惕,每次改动都会影响系统的状态和整个团队的工作效率。

14、 提早集成,频繁集成

  • 绝不要做大爆炸式的集成。 
  • 提早集成,频繁集成。代码集成是主要的风险来源。要想规避这个风险,只有提早集成,持续而有规律地进行集成。 
  • 如果你集成得不够频繁(比如一周一次,甚至更糟),也许就会发现整天在解决代码集成带来的问题,而不是在专心写代码。如果你集成的问题很大,那一定是做得不够频繁。

15、 提早实现自动化部署

  • 一开始就实现自动化部署应用。使用部署系统安装你的应用,在不同的机器上用不同的文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。 
  • 部署一个紧急修复的bug 应该很简单,特别是在生产服务器的环境中。你知道这会发生,而且你不想在压力之下,在凌晨三点半,你还在手工部署系统。

16、 使用演示获得频繁反馈

  • 维护一份项目术语表。在项目的开发过程中,从术语表中为程序结构——类、方法、模型、变量等选择合适的名字,并且要检查和确保这些定义一直符合用户的期望。 
  • 清晰可见的开发。在开发的时候,要保持应用可见(而且客户心中也要了解)。每隔一两周,邀请所有的客户,给他们演示最新完成的功能,积极获得他们的反馈。

17、 使用短迭代,增量发布

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

18、 固定的价格就意味着背叛承诺

  • 软件项目天生就是变化无常的,不可重复。如果要提前给出一个固定的价格,就几乎肯定不能遵守开发上的承诺。 
  • 基于真实工作的评估。让团队和客户一起,真正地在当前项目中工作,做具体实际的评估。由客户控制他们要的功能和预算。 

五、敏捷反馈 

 

19、 守护天使

  • 一些开发者会对单元测试有意见:毕竟,有“测试”这个词在里面,毫无疑问这应该是其他人的工作。从现在开始,忘掉“测试”这个词。就把它看作是一个极好的、编写能产生反馈的代码的技术。 
  • 使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试,不要进行任何代码设计和代码修改。 
  • 人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常,抗议越强烈,就说明设计越糟糕。

20、 先用它再实现它

  • 设计的一个重点是:确定什么是成功地实现特定功能的最低成本。程序员很容易走向另一个极端——一些不必要的过于复杂的事情——测试优先会帮助我们,防止我们走偏。
  • 先用它再实现它。将TDD 作为设计工具,他会为你带来更简单更有实效的设计。

21、 不同环境,就有不同问题

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

22、 自动验收测试

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

23、 度量真实的进度

  • 我们不应该去计算工作量完成的百分比,而应该测定还剩下多少工作量没有完成。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。 
  • 在你最后真正完成一项任务时,要清楚知道完成这个任务真正花费的时间。在为下一个任务估计工作量时,可以根据这次经验调整评估。

24、 倾听用户的声音

  • 不管它是否是产品的bug ,还是文档的 bug ,或者是对用户社区理解的 bug ,它都是团队的问题,而不是用户的问题。
  • 每一个抱怨的背后都隐藏了一个事实。找出真相,修复真正的问题。 

六、敏捷编码 

 

25、 代码要清晰地表达意图

  • 开发代码时,应该更注重可读性,而不是只图自己方便。代码阅读的次数要远远超过代码编写的次数,所以在编写的时候值得花点功夫让它读起来更简单。 
  • 要编写清晰的而不是讨巧的代码。向代码阅读者明确表明你的意图,可读性差的代码一点都不聪明。

26、 用代码沟通

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

27、 动态评估取舍

  • 动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了,就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅,而将设计复杂化。
  • 如果现在投入额外的资源和精力,是为了将来可能得到的好处,要确认投入一定要得到回报(大部分情况下,是不会有回报的)。 
  • 过早的优化是万恶之源。

28、 增量式编程

  • 在很短的编辑、构建、测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。 
  • 要像重构你的代码那样,重构你的测试,而且要经常重构测试。

29、 保持简单

  • 开发可以工作的、最简单的解决方案。除非有不可辨驳的原因,否则不要使用模式、原则和高难度技术之类的东西。 
  • 要将目标牢记在心:简单、可读性高的代码。强行让代码变得优雅与过早优化类似,统一会产生恶劣的影响。

30、 编写内聚的代码

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

31、 告知,不要询问

  • 面向过程的代码取得信息,然后做出决策。面向对象的代码让别的对象去做事情。 
  • 作为某段代码的调用者,开发人员绝对不应该基于被调用对象的状态来做出任何决策,更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任,而不是你的。 
  • 告知,不要询问。不要抢别的对象或是组件的工作。告诉它做什么,然后盯着你自己的职责就好了。

32、 根据契约进行替换

  • 通过替换代码来扩展系统。通过替换遵循接口契约的类,来添加并改进功能特性。要多使用委托而不是继承。 

七、敏捷调试

 

33、 记录问题解决日志

  • 维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。 
  • 如果通过搜索Web ,发现没人曾经遇到同样的问题,那也许是搜索的方法有问题。

34、 警告就是错误

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

35、 对问题各个击破

  • 很多应用的代码在编写时没有注意到隔离问题这一点,使得分离变得特别困难。此时,最好花一些时间把关注的代码提取出来,而且创建一个可让其工作的测试环境。 
  • 对问题各个击破。在解决问题时,要将问题域与其周边隔离开,特别是在大型应用中。

36、 报告所有的异常

  • 处理或是向上传播所有的异常。不要将它们压制不管,就算是临时这样做也不行。在写代码时要估计到会发生的问题。

37、 提供有用的错误信息 

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

八、敏捷协作 

 

38、 定期安排会面时间

  • 使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。 
  • 要保证会议议题不发散,每个人都应该只回答下述三个问题:
    • 昨天有什么收获?
    • 今天计划要做哪些工作?
    • 面临着哪些障碍? 
  • 虽然大多数团队需要每天都碰头,但对于小型团队来说,这样做可能有点过头了。不妨两天举行一次,或者一周两次,这对小团队来说足够了。

39、 架构师必须写代码

  • 设计会随着时间而演进,如果忽略了应用的现状(它的具体实现),要想设计一个新的功能,或者完成某个功能的提升,是不可能的。 
  • 优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况,是无法展开设计的。 
  • 不要运行任何人单独进行设计,特别是你自己。

40、 实行代码集体所有制

  • 在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码,可以提升团队整体的知识和专业技能。

41、 成为指导者

  • 成为指导者。分享自己的知识很有趣——付出的同时便有收货。还可以激励别人获得更好的成果,而且提升了整个团队的实力。 
  • 如果一直在就同一个主题向不同的人反复阐述,不妨记录笔记,此后就此主题写一篇文章,甚至是一本书。

42、 允许大家自己想办法

  • 给别人解决问题的机会。指给他们正确的方向,而不是直接提供解决方案。每个人都能从中学到不少东西。

43、 准备好后再共享代码

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

44、 做代码复查

  • 复查所有的代码。对于提升代码质量和降低错误率来说,代码复查是无价之宝。如果以正确的方式进行,复查可以产生非常实用而高效的成功。要让不同的开发人员在每个任务完成后复查代码。 
  • 同样的功能,不同开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码变得更好,否则不要随意批评别人的代码。 
  • 如果不及时跟进讨论中给出的建议,代码复查是没有实际价值的。可以安排跟进会议,或者使用代码标记系统,来标识需要完成的工作,跟踪已经处理完的部分。

45、 及时通报进展与问题

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

九、尾声:走向敏捷

 

Bug Fix 


分享 举报