代码提早集成.频繁集成.代码集成是主要的风险来源.要想规避这个风险.只有提早集成.持续而有规律地进行集成
倾听用户的声音
“用户就是会抱怨，这不是你的过错，是用户太愚蠢了，连使用手册都看不懂。它不是bug，只是用户不明白如何使用而已，他们本应该知道更多”。 Stupid user…所以不要想当然的去认为用户应该会怎么怎么样，尽量去引导用户，简化交互流程，做到简洁优雅…
敏捷代码
开始看起来非常正常的项目,是什么让它最终变得难以掌控?开发人员在完成任务时,可能会为节省时间而走”捷径”.然而,这些”捷径”往往只会推迟问题的爆发时间,而不是把它彻底解决掉.当项目时间上的压力增加时,问题最终还是会在项目团队面前出现,让大家心烦意乱.如何保证项目开发过程中压力正常,而不是在后期面对过多的压力,以致噩梦连连呢?最简单的方式,就是在开发过程中便细心”照看”代码.在编写代码时,每天付出一点小的努力,可以避免代码”腐烂”,并且保证应用程序不至变得难以理解和维护. 嗯， 每天抽出一点时间整理下代码， 让代码看起来漂亮些， 不要整到最后一团糟…
开发代码时,应该更注重可读性,而不是只图自己方便.代码阅读的次数要远远超过编写的次数和,所以在编写的时候值得花点功夫让它读起业更加简单.实际上,从衡量标准上来看,代码清晰程度的优先级应该排在执行效率之前.
27.用代码沟通
应该文档化你所有的代码吗?在某种程度上说,是的.但这并不意味着要注释绝大部分代码,特别是在方法体内部.源代码可以被读懂,不是因为其中的注释,而应该是由于本身优雅而清晰------变量名运用正确.空格使用得当,逻辑分离清晰,以及表达式非常简洁.如何命名很重要,程序元素的命名是代码读者必须的部分.通过使用细心挑选的名称,可以向阅读者传递大量的意图和信息.反过来讲,使用人造的命名范式会让代码难以阅读和理解.这些范式中包括的底层数据类型信息.会硬编码在变量名和方法名中.形成脆弱,僵化代码,并会在将来造成麻烦
在编写代码的时候，要经常留心可以改进的微小方面。这可能会改善代码的可读性。也许你会发现可以把一个方法拆成几个更小的方法，使其变得更易于测试
优雅的代码第一眼看上去，就知道它的用处，而且很简洁。但是这样的解决方案不是那么容易想出来的。这就是说，优雅是易于理解和辨识的，但是要想创建出来就困难多得多了。
让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
记录问题解决日志
面对问题（并解决它们）是开发人员的一种生活方式。当问题发生时，我们希望赶紧把它解决掉。如果一个熟悉的问题再次发生，我们会希望记起第一次是如何解决的，而且下午下次能够更快地把它搞定。然而，有时一个问题看起来跟以前遇到的完全一样，但是我们却不记得是如何修复的了。这种状况时常发生…这就需要我们维护一个保存曾遇到的问题以及对应解决方案的日志。这样，当问题发生时，就不必说：“嘿，我曾碰到过这个问题，但是不记得是怎么解决的了。” 可以使用以下格式来记录：
- 问题发生日期。
- 问题简述。
- 解决方案详细描述。
- 引用文章后网址，以提供更多细节或相关信息。
- 任何代码片段、设置后对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。
警告就是错误忽略编译器的警告信息继续开发代码，会导致什么状况呢？这样做等于是坐在了一个嘀嗒作响的定时炸-弹上，而且它很有可能在最糟糕的时刻爆炸。所以，不要无视警告信息，可能会导致问题的都要fix掉…