到了“低耦合”，你就可以把一个复杂的大程序当一组简单的短文甚至短信写。

因此，写程序时，事先的“谋划”非常重要。

本章已阅读完毕(请击下一章继续阅读!)

一个有经验的资工程师，可以在动手前就把一个复杂的大项目拆成一堆几乎互不关联的小程序，然后逐一实现它们、实现完再把它们组合起来就行了。

这样写程序，当然还是无法杜绝bug现；但bug的机率就微乎其微了。

既然“写长篇bug正常，发条短信就那么十几个字，错一个都不应该”；那么我们把长篇拆开成若章，一章只写三千字呢？再把一章拆开成若段，一段只写数百个字呢？

不能因为“linus也写bug”甚至“linus也写过低级bug”，就认为“我写个一百个整数里找最大值的简单程序三十个bug也是正常的”——初学者搞这事，正常。

不过……

不仅如此。

有的人敲字都错字连篇，但是有人手写几十上百万字的小说，随便截一段都差不多能语文课本……

至于专业人员嘛……一个都不正常。

ps：留个言，你们是不是不喜看代码相关的或者看不懂这些……说来我以后少写，毕竟前期还是需要程序员的技术去赚钱的。当然你们的意见我也考虑一下。

但是在程序里面，不同模块甚至不同函数之间，应该是毫无瓜葛的，每一个都可以摘来独立成库——有瓜葛就说明用了全局变量或者静态对象，或者通过参数或者约定等传递了过多的东西——这就叫“低耦合”。

当然了，有些情况下，程序逻辑非常复杂且无法拆分，也就是所谓“无法约分的复杂”，这代码就必须端起十二分小心来，当然即便如此，bug现率仍然要远于其他代码。

这个“不可约分”就是术语说的“内聚”：这段程序只一件事，这件事已经没法拆的更简单了，只能把它们放在同一段代码里一举解决掉。

这就是为何写程序要先模块设计、然后再把模块职责拆分成类、类功能拆分成函数、最后还要求一个函数不要超过一屏（大约80行）的原因了。

显然，“谋划”好了，一个程序的难度降低若个数量级都是可能的。

一般来说，要把程序拆成“不可约分”的一组最小单元来写。

小说里的角，尤其是主角和主要角往往是贯穿始终的，这就使得小说章与章之间存在很多内联系；稍微搞不好就会导致前后失去呼应，比如主角一会儿伤在左手一会儿伤在右臂、或者前面挖个坑然后设个伏笔后面却忘了用，等等。

“遭遇官方bug”问题——如果你自己理解上再有偏差，用新特就和作死无异了。

只不过，第一开发可能没想到，第二测试没测到，第三用没碰到，第四客服的反馈没收到，那么——这就是一个“成熟稳健”的产品。

经过拆分之后，一个一个函数填写实现、然后再一个一个函数单元测试，测完再组合起来搞功能测试、集成测试……

而且程序和长篇小说不同。

说实话，在绝大分能见到的件中，都是或多或少的有bug的……

所以，人与人还是有极大差别的。

这样自然就很难错了。