向“注重实效的程序员”靠近 ——读《程序员修炼之道》有感

       “书中自有黄金屋”，这真的是古人诚不欺我，书中的种种细节都是决定成败的致命因素，读后深受感触。今读书仅短短一章多，便受益匪浅。结合在小组开发游戏的过程，自己也渐渐明白了其中的个把缘由，也懂得自己还远远不够，仍需继续努力。

      “灵活”是代码生存的要素，不仅需要与时俱进，还要易于修理，否则会在近乎疯狂的步伐中掉队。本章便介绍了如何让我们的代码在一个多变的世界顽强的存活下去。编程可以像间谍、革命者以及类似的人，组织成最小组织单位（模块），并限制它们之间的交互，这样如果随后发生了某个模块替换的事，就可以不会太过波及到其他模块，保持程序的稳定性，否则对象间直接的横贯关系可能会带来依赖关系的组合爆炸，例如：1、用于链接某个单元测试的命令币测试程序自身还要长；2、轻微改动一个模块，就会导致无关模块产生影响；3、开发者不敢改动代码；看到这里的时，不禁笑出了声，因为我对此产生了很强烈的共鸣，过去的编程实验中，总会发生令我很无奈的事情，正如上面所讲，一个模块的修改轻者影响另一个，重者程序崩溃。书中介绍了函数的得墨忒耳法则，可以使任何给定程序中的模块之间的耦合减至最少，读到此处便不理解何为“得墨忒耳法则”，于是百度了一下，简言之便是：每个单元（对象、方法或模块）应当对其他单元只拥有有限的了解。打个比喻：你需要洗衣服，再使用洗衣机时，你需要做的是放入脏衣服、洗衣液，并按下按钮，而不是抱着洗衣机摇动，甚至是把衣服手动拧干。一些研究表明，在C++中，与具有较小响应集的类相比，具有较大响应集的类更容易出错，遵循得墨忒耳法则便可以缩小了调用类中的响应集的规模，当更改一个类时，可以无需因连锁反应再去改许多其他的类，从而可以减少错误的发生。事实上，在实践中这需要编写大量包装方法，既会带来运行时代价，也会带来空间开销。

      “细节决定成败”，同样细节会弄乱我们整洁的代码，每当我们必须去改动代码，以适应商业逻辑、法律等的某种变化时，我们都有破坏系统（引入bug）的危险。首先，我们要让我们的系统变得高度可配置，类似算法、数据库产品等的选择应该作为配置选项，而不是通过集成或工程实现。这就需要元数据，元数据是什么？简单说是数据的数据，主要是描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。我们要尽多可能通过元数据配置和驱动应用，目标是以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活和可适应的程序。有一条准则深深地印在了我的脑海：为一般情况编写程序，把具体情况放在别处——在编译的代码库之外。这样有若干好处：1迫使解除设计的耦合，从而带来更灵活、可适应性更好的程序；2、迫使通过推迟细节处理，创建更健壮、更抽象的设计；3、无需重新编译应用，就可以对其进行定制；4、可以通过一种大为接近问题领域的方式表示元数据；5、用相同的应用引擎，但是用不同的元数据实现若干不同的项目。在今天的小组项目会议中，组长便提到了这一点，在大体程序中不要附加一些特殊的情况，让代码越简洁越好。“渡渡鸟”，一种生长在毛里求斯岛上的灭绝动物，可不能让我们的代码变成它。

      “时间耦合”一个常常被忽视的软件架构，两个很重要的方面：并发和次序。我们经常会进行线性的事情处理，先做这个然后再做那个，但这样思考会带来时间耦合，也就是A总是在B之前调用，这样不怎么灵活，所以就需要分析工作流，以改善并发性。对并发和时序依赖进行思考还能够引导你设计更整洁的接口，因此我们总是为并发进行设计，如果我们在设计时就考虑了并发，到时候我们就可以更容易地满足可伸缩性或性能需求。

       课上老师的谆谆教导再一次在书中看见：不要把程序写成一个大块，而应该“分而治之”，把程序划分成模块，于是每次的C语言的作业中，都会出现一个孤零零的main函数和很多的调用函数，没想到这样的思想在编程与软件开发也是一样的适用。现在一个例程必须对许多对象间的交互有密切的了解，它还增加了耦合，而我们正在设法减少耦合，对象应该能进行登记，只接收它们需要的事情，并且决不应该受到它们不需要的事件，但我们可以使用一种发布/订阅协议，它可以实现一个非常重要的设计概念：模型与模型的视图分离。

      黑板，伴随我们走过童年的东西，重新出现在了书本中，这次的它成为了一个很好的设计解决方案，黑板系统让我们完全解除了我们的对象之间的耦合，并提供了一个“论坛”，知识消费者和生产者可以在那里匿名，异步地交换数据，并且减少了必须编写代码的数量。

     短短的一章便包含诸多重要的知识点，静静品味便能体会编程里的大智慧。