如何习得优秀的编程实践或者保持优秀的变成习惯？
接下来讲的都是一些基础的一些知识，然而却很实用，也很考验一个人的编程能力，我相信拥有一定编程经验的小伙伴，都会在平时的实践中自觉或不自觉的往这些方面靠拢，无论是被动或主动。很多内容又和《重构》一书一致，然后再结合《大话设计模式》里的那些对话场景，如何引出不同的设计模式，如简单工厂模式代替条件等等，充分说明优秀的实践总是相通的。尤其是重点的一个“可读性”，能够用自然语言读出来，这一点对我自己启发很大。
方法或属性权限给private，这是个好习惯，按需暴露。以前也是按照这个原则，不多说。
命名这个，《重构》里面也讲了，方法的命名、属性的命名、变量的命名，由名词、动词、形容词的结合，一般就是动词+名词。并因此出现一些相关重构方法，如重命名等，好的命名，应该是通俗易懂的，只有这样，才能实现另一个点就是少注释，方法的命名、变量的命名自带注释，就叫它自解释或者自注释吧，只要一看名称，就知道是做什么的，就省了很多注释，而往往功能会增加，会改变，那么注释就会脱节、变形、过时，多了注释反而会让人更加不明白，甚至自相矛盾也会有。当然，要想真正做到没有注释，还需要重构里面的提炼函数，至少做到利哥说的，代码行数少于三四十行，做到单一职责，粒度要细、原子化，这样每一个功能没有和其他功能产生业务上的耦合，不仅仅是代码上的耦合，每一个方法都能自解释，再复杂的代码，就算合起来也不需要注释了。那些需要注释的，大多数也是因为做不到单一职责原则这一点吧。
代码行数，避免过长方法，面向对象自然要做到封装，好的方法应该是发扬这一点的，将不同的功能块封装起来，过长的方法，其实背离这一原则，类似vb里的面向过程了。重构里也讲了，将变量、方法体挪动在一起，然后封装提炼新的方法，充分体现乾坤大挪移手法，一行一行挪挪挪，让长的代码分崩离析。
单一职责原则：无论是避免长方法、优秀的命名、不要注释其实都是围绕单一职责原则来做的，粒度足够细（当然也不至于一个方法一行代码），一个方法就干一件事，说简单很简单，说复杂也很复杂，老话讲，多则惑少则得。好的方法，应该是符合开闭原则，当需求、业务、功能变动时，应该是增加而不是修改现有方法，切忌引入新的变动。
减少嵌套、用卫语句提前返回特例（当然平时还是要遵守一个入口一个出口），if条件要提炼，还是提炼函数或命名问题，过多的条件运算，本身就是反人性的，提炼并给一个好的命名，就是注释。按需传参，无用的不要传进去，不然方法就被限定死了，少用string返回值，用int、bool等返回。
方法具有可读性，不仅仅是命名，还有方法体的各个代码流程状态，说人话，自然就不需要注释了。