态度决定一切

1、做事

     当出现问题,BUG的时候不要抱怨,指责,最终要的是解决问题。

2、欲速则不达

    不要坠入快速的简单修复之中,要投入时间和精力理解它,并使代码保持整洁、敞亮。

    不要孤立的编码,花时间阅读其他人的代码。

    使用单元测试。

3、对事不对人

    不要一味否定别人的意见,要提出自己的看法。

    只有更好,没有最好。

    不带任何情绪并不是盲目接受所有的观点。用合适的词和理由去解释为什么不赞同,并提出明确的问题。

4、排除万难,奋勇前进

    如果发现项目中代码有问题,向其他成员反馈问题,并且想办法重写它。

学无止境

5、跟踪变化

    迭代和增量式的学习:记录下想学的东西——当听到不熟悉的术语或短语时,简要的记录,然后有计划的深入学习。

    了解最新行情:选择一些公认的优秀技术博客,了解顶尖博客作者们在关注什么。

    参加本地的用户组活动。

    参加研讨会议。

    如饥似渴的阅读:好书,期刊杂志等。

6、对团队投资

    提供你和团队更好的学习平台:可以搞一些类似午餐会议,提供一个团队分享的平台

    不要局限于纯技术的主题

7、懂得丢弃

    学习新的东西,丢弃旧的东西。

    要果断丢弃旧习惯,一味遵循过时的旧习惯会危害你的职业生涯。

    不是完全忘记旧的习惯,而是在使用适当的技术时才使用它。

    对所使用的语言,要总结熟悉它的特性,并比较这些特性在新语言或新版本中有什么不同。

8、打破砂锅问到底

    要不停地问为什么,直到明白事情的本质。

9、把握开发节奏

    每天下班的时候提交所有的工作,包括测试代码。第二天开始新的内容。

    每天固定时间固定地点的站立会议。

    最大的节拍就是迭代时间,一般是1-4周。

    项目开发需要一致和稳定的节奏。编辑,运行测试,代码复审,一致的迭代,然后发布。

交付用户想要的软件

10、让客户做决定

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

    不要用低级别或没有价值的问题打扰业务人员。

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

    好的设计应该是正确的,而不是精确的。设计不应该涉及细节。

    做一些类层次的设计:类名,职责,协作者。

    白板,草图,便利贴是非常好的设计工具。

12、合理的使用技术

    根据需要选择技术。

    新技术就像新工具,它可以帮助你更好的工作,它自己不应该成为你的工作。

    不要开发那些容易下载到的东西。

13、保持可以发布

    提交代码之前: 在本地运行测试;检出最新的代码;提交代码

    可以弄一个持续集成系统.

14、提早集成,频繁集成

    决不要做大爆炸式的集成。

    集成也不要太频繁,一天几次就差不多了。

15、提早实现自动化部署

    系统安装、部署应该简单、可靠及可重复。

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

    需求就像是流动的油墨。

    定期地,如一个迭代的结束,就与客户会晤,并演示你已经完成的功能特性。

    维护项目术语表。

    会晤也不要太频繁,只有在你做完一些东西可以给客户演示的时候 ,才进行。

17、使用迭代,增量发布

    给我一份详细的长期计划,我就给你一个注定完蛋的项目。 (Show me a detail long-term plan, and I'll show you a project that's doomed.)

    确定产品可用的核心功能,然后把它们放在生产环境中,越早交到用户的手里越好。

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

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

    构建系统最初、小的和有用的部分,之后再根据功能迭代,每个迭代给客户选择继续还是取消合同。每个迭代的费用还是相对可以评估的。并且客户承担更低的风险。

    

    

敏捷反馈

19、守护天使

    编写能产生反馈的代码。-》自动化单元测试。

    在后台架设一台构建机器,不断获得最新版本的源代码,然后编译代码,运行单元测试,有错误及时通知。

    如果单元测试到位,可以随意重构代码。

    简单属性的访问方法和价值不大的方法是不值得写单元测试的。

20、先用它再实现它

    编程之前,先写测试。测试驱动开发

    使你站在代码用户的角度。

    有助于消除过度的设计。

    好的设计并不意味着需要更多的类。

    只有在具体理由的时候才开始编码,你可以专注于接口设计,而不会被很多实现的细节干扰。

    测试优先和提交代码之前的测试要区分开来,测试先行帮助改进设计,提交代码之前还需要进行测试。

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

    使用自动化在多个平台上运行测试。    

22、自动验收测试

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

23、度量真实的进度

     专注于你的方向。

    在真正完成一项任务时,要清楚知道完成这个任务真正花费的时间。

    使用×××事项。

    度量剩下的工作量。要评估那些需要完成的×××事项。

24、倾听用户的声音

    没有给用户很友好的提示。

    每一个抱怨的背后都隐藏了一个事实,需要努力找出背后真正的问题。

     如果代码问题解决不了,可以用修改文档和培训来解决。

    

敏捷编码

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

    开发代码时,应该更注重可读性,而不是只图自己方便。

    代码必须说出意图,而且富有表达力。

26、用代码沟通

    建立代码文档:利用代码本身;利用注释沟通代码之外的问题。

    不需要注释来包裹你的代码。

    使用细心挑选的名称和清晰的执行路径,代码几乎不需要注释。

    对于类中的方法,可能要说明下面的信息: 目的;需求;承诺;异常。

    解释代码做了什么的注释用处不那么大。注释要说明为什么这样写代码。

27、动态评估取舍

    强调性能的重要性情有可原。但如果性能已经足够好了,就没有必要再花时间去投入了。

    没有最佳解决方案。

    过早的优化是万恶之源。

28、增量式编程

    它可以精炼并结构化你的代码。

    会使你倾向于创建更小的方法和更内聚性的类。

    持续做一些细小而有用的事情,而不是做一段长时间的编程或重构。

    在很短的编辑/构建/测试循环中编写代码。

    要想重构代码一样重构你的测试,而且要经常重构测试。

29、保持简单

    不要被迫过分设计,也不要将代码过分复杂化。

    开发人员应该为自己创建一个简单并且可用的设计而骄傲。

    简单不是简陋。

    不要盲目使用模式、原则和高难度技术之类的东西。

    当你觉得代码中没有一行是多余的,并且仍能交付全部的功能,这种感觉就对了。

30、编写内聚的代码

    组件中各个类的功能类似,且功能紧密相关,这就是组件的内聚性。

    类中的方法和属性共同完成了一个或一系列紧密相关的功能,这就是类的内聚性。

    MVC模式分离展示逻辑、控制器和模型,它可以让开发人员获得更高的内聚性。

    内聚性会影响一个组件的可重用性。

    让类的功能尽量集中,让组件尽量小。