《clean code》读书心得

later equals never；感觉不爽就要重构，不要等待，不要积攒坏味道。好的代码就像一件工艺品，在反复修改雕琢中成为精品；

永远不要忘记，编码的真正目标在于讲述软件系统的故事，我们的目标就在于如何把这个故事讲清楚。所以你编写的函数必须干净利落地拼装到一起，形成一种精确而清晰的语言，帮助你把故事讲明白；

代码应该清晰表达作者的 意图 ，对 意图 的理解需要长期的修炼过程；

别给糟糕的代码加注释，重新写吧；

之所以极力贬低注释，是因为注释一般可以用良好的代码风格来替代；另外一个原因，就是注释有可能会误导人，因为时间越长，注释跟代码意图的偏离越大，遗憾的是，很少有程序员愿意去维护注释；

用整理代码的决心替代创造废话注释的冲动吧，你发现自己会成为更优秀、更快乐的程序员；

其实没有必要在代码中标识某个函数的作者，修改或创建日期。更广泛一点讲，能够通过源代码控制系统（git, svn等）记录的信息，都没必要在代码中搞注释。甚至用于说明函数功能的整个函数头都没有必要，只要你的函数足够短小，并且有足够好的函数名；

当你致力于减少代码中注释的时候，就会逼迫自己改善代码可读性和简洁性。虽然一开始可能比较难受，需要坚持和修炼；

写代码就如同写报纸和写书，层次结构很重要；

Try-catch 结构比在流程中返回错误码更好，因为他能够在try语句块中清晰专注地说明正常流程，有利于代码阅读；

想要创建整洁的系统，需要有消除重复的意愿，即便对于短短几行代码也是如此；

所以，多少尊重一下你的手艺吧。花一点点时间在每个函数和类上。选用较好的名称，将大函数切分成小函数，试试照拂自己创建的东西。用心是最珍贵的资源；

优秀的软件设计，大都关乎分隔--创建合适的空间放置不同种类的代码。对关注面的分隔让代码更易于理解和维护；

不要以函数的大小长短来判断是否需要重构，是否需要提取函数出来。这个坏习惯要改掉。要根据概念来确定是否需要重构和提取，单一职责原则很有用。但是也要注意，提取出来的函数可能随着重构，它也不再适用，需要重新拆掉也是有可能的；

测试代码同样需要整洁，肮脏的测试代码会让你测试用例最终废弃掉，测试用例废弃掉会导致你的代码最终无法维护。