【代码精进之路-01】
只是看起来对的代码，其实特别容易出问题，所以一定要反复查验，确认无误才能放心。
坚持使用最直观的编码方式，而不是追求代码的简短，真的可以避免很多不必要的错误。
减少错误、节省时间是我们选择编码方式的一个基本的原则。
最适合当前现实环境的代码，才是最优秀的代码。
从整个软件的目标思考，能服务于软件目标，适合软件目标，对整个软件生命周期都是经济最好的代码。
职责单一，不要把过多的东西塞到一个类或者方法里，同一个功能的最好放到一起或有联系的地方，尽量把变化的抽离出来，不变的封装起来。
好的代码不刻意追求形式上的简洁，追求经济，好理解、维护，不容易出错，写出规范性代码，注意代码安全问题。
简而言之，优秀的代码是经济、规范、安全的代码。
没有人是完美的，人人都会犯错，这应该是一个共识，这里既有技术层面的因素，也有人类行为模式因素，也有现实环境的影响。
对于一个团队，首先要思考如何提供一种机制，以减少此类错误的发生。
一旦陷入自责和指责的漩涡，很多有建设意义的事情，可能没有意识去做，或者即使意识到了，也没法做，做不好。
从别人失败和自己的失败中学习、积累、提高，是一个程序员成长的必修课。
优秀的代码源于我们对细节的热情及执著，如果你能找到哪怕仅仅是一个小问题的一个小小的改进办法，都有可能会给你的代码质量带来巨大的提升和改变。
就单个程序员而言，代码质量其实是一种意识和技能问题，代码质量取舍取决于具体的环境和你的真实目标。
程序员的存在不是为了写代码，而是为了解决现实问题，实现现实的价值。优秀的程序员是高效的时间管理者。
如果说花样的工具是外家功夫，思维能力和行为可以算是内功。
能够发现关键的问题，意味着我们可以从一个被动的做事情的程序员升级为一个主动找事情的程序员。做到这点，往往需要我们对一个领域有很深的研究和深厚的积累，并且对新鲜事物保持充分的好奇心和求知欲。
要做只有你能做的事情，要坚持做需要做的事情，把问题解决掉，就是脱颖而出的机会。
每一次危机都不应该浪费，危机虽然让人头疼，都是打怪升级、提升能力的时候。
编码规范指的是针对特定的编码约定的规则，通常包括文件组织、缩进、注释、声明、语句、空格、命名约定、编程实践，编程原则和最佳实践等。
名字是沟通的方式，错误的命名很难让我们清楚理解代码的真实意图，所以混淆的命名很难让我们阅读和理解代码。名字要能够准确，完整地表达出它代表的意义，可见字知意，名副其实。
有效使用空行，空格和缩进，简单的分割与对齐，就可以使得代码的视觉效果甚至质量发生巨大的变化，理顺编码的思路，提升编码的效率，这是一个付出少，收获大，值得养成的好习惯。
一个代码文件可以看成是一个杂志的版面，保持代码的单一性，一个代码块只能有一个目标，注意代码的完整性，代码块数量要适中。
空白区域，不仅仅可以用来分割代码，还展示了代码之间的关系。
每一行代码仅仅表示一个行为，这样每一行的代码才是一个常规大小，可以识别的基础信息块。
一般情况下，每行代码不要超过80字符。在逗号后换行，在操作符前换行，高级别的换行优先。
注释被我们用成万能的狗皮膏药，有时会让代码更糟糕，如果一段代码不再需要，要清理掉代码，而不要保留注释掉的代码块。
注释的维护是耗费时间和精力，所以不要保留多余的、不必要的注释。
如果接口的设计存在不合理性，或者新方法取代了旧方法，应该尽早地废弃该接口。不要等到亚历山大时候才救火。
越好用的东西，我们越容易忽视它的缺陷。
不要使用异常机制处理正常的业务逻辑，异常的使用要符合具体的场景。
组织代码是一项基本技能，最快的提升方法是仔细思考一下为什么我们要做出这样的选择，而不是其他。
代码的位置在现在的软件工程里有一定的共识，通常来说，源代码存放在根目录下的src目录。
一个软件通常划分为几个不同部分，MVC（Model,View,Controller)，可以降低复杂度，让程序结构更加直观。
对于接口规范，原则是能不变更就不变更，必须变更，一定要反复思量该怎样做才能把影响降到最低。
最好的用户指南是产品本身。一份合格的用户指南，要帮助用户减少产品使用的障碍，快速地使用产品。
在产品设计时，需要解决掉用户定位和怎么使用这两个问题，把用户假定为啥也不理解然后去写文档，写出来的文档就合格。
除了遵守编码规范外，还要做好随时重审，调整编码规范的准备，保持编码规范的活力，跟得上实际情况的变化。