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