今天下午花了一个小时分别和两位同事做了一些代码讨论，这两位同事正在编写的代码都具有一定的试验性质(暂不能进入项目代码库)。这里不谈代码如何如何，而是就我发现的一个问题谈谈我的看法。

问题其实也很简单：那就是两位同事“不约而同”的都没有对这类试验性质的代码进行很好的备份和版本管理。

也许你看到这里会觉得这个芝麻粒儿大的问题不值得一提。没错，可能很多人都不以为然，不过有过以下经历的朋友们也许会与我产生共鸣：
- 主机掉电，磁盘损坏，无法恢复数据，绞尽脑汁辛苦编写的数百上千行代码“付之一炬”，一切待重来;
- 一个rm误操作使你和积累了多天的代码说了"永别"，剩下的只有眼泪;
- 突然脑子中冒出一个想法，觉得应该如此重新设计并修改已有代码，加班+熬夜修改了数百行代码，横跨几个甚至是十几个文件，最终发现只是自己一时冲动，测试证明还是之前的设计是正确的。又加班+熬夜将代码恢复到修改前的模样。
- 前一天晚上新增了几百行代码、删除了若干行，修改了十几个文件，第二天醒来再打开这些代码，感觉有些陌生，记不清到底加了哪些代码，删了哪些代码，甚至为什么增加和删除也许都忘记了。

不知道上面的情景你亲历过几个？不管你是否亲历过，我想说都是：做好你的所有代码的备份和版本管理，哪怕这些代码仅仅是为自己所用，哪怕仅仅是用来做试验的，它们毕竟凝结了你的智慧和汗水。

前两种情况告知你应该做好代码的备份工作，只做本地备份还不够，还要进行多点备份。
第三种情况则提醒你做好版本管理，便于进行代码版本回溯。
第四种情况也是做好版本管理的一个好处：追踪你的修改记录以及回顾你的思维旅程（通过svn commit log）。

最好的方式就是你通过公司架设的版本控制Server管理你的代码，这样在版本管理的同时，代码也作了远程备份。如果是个人的非商业代码，你也可以尝试通过像Google Code这样的服务来管理和备份你的代码。如果你有条件的话，也完全可以在家里的另外一台机器上架设版本控制服务器，毕竟现在的硬件趋于白菜价。另外像Git这样的分布式版本控制工具既可以帮助你在本地做好代码版本管理，也方便你将代码与公司版本控制服务器之间做同步。

作为脑力劳动者，任何从你的大脑里流出的东西可能都是有价值的，最好都能像代码一样做好备份和版本管理。不以善小而不为，何况这是对你自己有益的事儿呢！

近一段时间重读了一些经典书籍，诸如《敏捷软件开发：原则、模式与实践》、 《程序员修炼之道》、《Unix编程艺术》等。这些书中关于如何衡量或评价一个类或函数设计好坏的几个原则(Principle)让人印象深刻。《敏捷软件开发》中谈到了SRP、OCP、DIP; 程序员修炼之道则以DRY、“正交性”为话题展开;《Unix编程艺术》围绕紧凑性、SPOT、分离等阐述作者立场。这么多经典原则，如何学习把握？我们不妨来挖掘一下这些新设计原则背后的本质。

追本溯源，从计算机编程语言的发展历史来看，成熟的结构化程序设计语言(如C语言、Pascal等)要先于成熟的OO设计语言(C++、Java等)出现，那么其成熟的设计理论显然也是要早于后者的。这里就不能不提到经典结构化设计的代表作：《Structured Design: Fundamentals of a Discipline of Computer Program and System
Design》，这本书出于1975年(年份来自维基百科，Amazon上卖的是1979年版)。说实话我也没有看过此书原版，不过书中的内容和思想早已被其他后继书籍引用和借鉴，我们在市面上能看到的关于结构化设计方面的书籍，尤其是中文书籍，多照搬了此书内容和思想，所以也算是间接学习到了。

书中对抽象、模块化、信息隐藏(黑盒)作了阐述，并介绍了数据流/控制流图、结构图等设计方法。特别是书中关于内聚(Cohesion)与耦合( Coupling)的讲解对之后的程序设计评价方法影响至深。我们一直常说高内聚低耦合的模块是良好的设计，这里的内聚和耦合概念的提出者恰是这本书的作者Larry L.Constantine。内聚和耦合这两个概念是用来评价一个module设计好坏的。module一词中文意为“模块”，模块一词的范围让人很难界定，关于module这个概念，书中给出了这样的解释："A module is a lexically contiguous sequence of program statements, bounded by boundary elements, having an aggregate identifier.  Another way of saying this is that a module is a bounded, contiguous group of statements having a single name by which it can be referred to as a unit." 显然类或子程序（函数）是符合module的定义的。用内聚和耦合来评价类或子程序（函数）的设计是适合的。

关于Cohesion(CC2e 7.2小节)和Coupling(CC2e 5.3小节)的具体内容，这里就不细说了，《代码大全2》作者说的肯定比我好多了，另外维基百科中对coupling和cohesion的描述也很详尽。

以上所说的内聚和耦合其实就是我认为的以上诸多经典设计原则背后本质的东西。诸多设计原则应该可以看作是耦合和内聚概念在不同语言范式上下文情境下的延伸、再包装或升华。虽然有些原则说法发生变化了，但是本质却是一样的。比如: 单一职责原则(Single Responsibilty Principle, SRP) 显然是"功能内聚(Functional cohesion)"的另一种表述; 有些原则虽然无法直接与内聚耦合概念进行直接对号，比如依赖倒置原则(Dependency Inversion Principle，DIP)，但是可以理解成追求低耦合的一种设计技法！

把握好内聚和耦合的核心理念，你将以不变应万变，你也会更深刻理解诸如OCP、DIP等新原则了。

俗话说“物以类聚”，这句同样适用于程序设计！一个module的设计如果有一处优点，那常常这个module也具备其他优点; 反之，如果发现这个module设计的一个缺点，那么离发现其他缺点也就不远了。

内聚与耦合的概念不仅仅适用于程序设计领域，在所有其他设计领域似乎同样普适！考虑对比一下一个具备电加热除霜功能的后视镜与一个普通后视镜在设计层面上的优点与不足吧！

发觉题目似乎有些夸张^_^。