一个函数只做一件事
一个函数应该只做一件事，这样不但你能够更好的命名你的函数，理解和阅读代码也变得更加的容易。如果你遇到一个特殊的情况不得不打破这个原则，可以 停下来，思考一下是不是你对这个“特殊情况”的理解还不够。函数应该很精确的执行一件事并且只执行这一件事。
鲍勃大叔在他的《Clean Code》里面提到这一点，还有一些其他关于代码甚至是架构方面的书也提到过。
在读到这个观点之前，我发现自己做重构的时候会不知不觉的朝这个方向走；知道这个观点之后，开始把它当作一种习惯 -- 当然，我承认自己写得很多代码都没有满足这个要求，因为知道离行道还是有一段距离。
但是如果你想让自己或别人在维护代码的时候轻松一点，你就应该尝试着尽量做好，然后想办法说服你的同事做好。
类的单一职责原则（Single Responsibility Principle）
类也会变得越来越小 -- 这也不是你的目的，但是当你遵守面向对象类设计的原则的时候，类就开始变小。我们希望实现类的高内聚、低耦合。当你要修改类时，你应该只有一个理由，也就 是说类应该只有一个责任。
单一职责原则是一个非常重要的概念。可能很多人像我一样一开始会惧怕一大推的小类--觉得会让项目变得更加的难以理解--对于这样的情况，我想说你 先尝试一下，看看结果如何？尤其当我们拥有强大的Visual Studio来管理类视图的时候，这样的尝试应该不是一种冒险。
一个前提：要有单元测试
写出“整洁”代码的一个前提是要有单元测试？你可能会觉得我跑题了。但是我发现如果没有建立起单元测试，我们就没有勇气不断的修改我们的代码，甚至 没有办法睡好觉。好的，我可以改一下小标题：睡好觉的前提：要有单元测试。
“变小”的代价
通常人进入改变模式的步骤是：听到一个新的概念->怀疑->执行->后悔->再坚持->接受或者回到原始状态。那么 函数和类变小的代价是什么呢？我自己的经历和体会是：
对于已有代码没有时间进行重构--非常可以理解，那么当需求发生变化的时候，当我要改变这些已有代码的时候，我就开始朝这个方向重构它们--让它们 比我“来”之前更“干净”。
对于新的代码，在编写的过程中不断的重构--你没有办法一开始就让你的代码完美。当你写了几个小时后，你发现自己代码并不漂亮，没有关系，不要怀疑 自己的能力，花时间进行重构，因为整洁的代码都是在重构中完成的。