1.BUG 是发现不足的绝佳机会，也是将代码优化的绝好机会。比如统计一下最常出现的BUG，并找到解决的方法。
2.将代码封装在方法里，可以降低复杂度、隐藏细节、提高可读性、减少代码重复。而我个人的体会是，阅读代码时，可以只阅读自己关心的代码，而不需要去在意与之无关的代码。DEBUG 的时候，只要看调用方法的输入输出就可以了。阅读的代码量将大大减少。
封装方法，使得业务代码和逻辑代码分开。而阅读代码的人，刚开始的时候，只会在乎实现业务的代码。遇到特定的问题后，才在意有逻辑问题的代码如何实现。这样在熟悉业务的时候，能减少阅读量。
3.第一次看《代码大全》的时候，收获并不大。当第二次在项目中，应用到代码大全的知识。Debug的时候、重构代码的时候，写伪代码的时候，将代码写在一个个的子程序中的时候。似乎对书中的知识理解的透彻很多。
4.将代码写在子程序的另外一个好处是，有时候你会发现以前没有发现过的事物的本质。——>你对程序理解的更加透彻了。
a.看代码现在都是一个业务功能一个业务功能的去看，而不是一行代码一行代码的去看。
b.代码的内在结构将会变得简单。(因为有重用的代码，因为有些初看不是一类东西的代码，其实却是一类东西。)
5.具有好结构的代码的另外一个好处是，插入新的代码的时候，能一目了然的知道代码应该插在哪里。
6.更好的代码是做到避免信息的重复，而不仅仅是代码的重复。区分开不易变和易变的东西。正如知乎轮子哥所说，去掉重复的信息会让你的代码结构发生本质的变化。
7.代码重构，会让你对你写的代码，以及业务有更新更深的理解。
8.将变量用途单一化的好处是，我在用这个变量的时候不需要去思考它在其他地方的使用。需求变更要删除代码的时候，顾及也少了。
8、原来看代码是一句一句的看，有良好结构的代码，你可以一段一段的看。更容易获取到自己想要的信息，也能对代码有一个全局的把握。
9.如果想要继续提高自己的编码能力。需要阅读源代码、和别人交流。
10、设计的过程中，应该尽量避免风险，风险越留到后面，更正的成本就越高。降低沟通成本，尽量少引入因为技术的问题带来的复杂度，通过迭代的方式沟通清楚需求，设计文档的记录，对数据库熟练设计都有利于风险的避免。
11、数据库设计和项目设计都要做适当的冗余，给变更留一定的空间。但是不要过度设计。
12、项目启动前，想办法和关键人员沟通，让他了解你的做事方法，在项目实施过程中，沟通成本会大大降低。如果是危机出现后再做这些准备，会让别人没有充分的心理预期。
