边界处理、系统设计、单元测试和变发编程初探

边界处理、系统设计、单元测试和变发编程，每一个命题，内容都复杂到足以需要写一本书来论述。本文仅记录我读《代码整洁之道》所获得的零星知识。

边界处理，按字面意思理解，我以为是
a >= 5
这句代码中的“等于”情况。书中讲解边界处理的时候，举了使用第三方代码的例子。对于要使用的第三方代码，我们本没有责任去测试它。但要在自己的项目中使用，又不得不去测试它。

引入一个新概念“学习性测试”。测试，不是检测程序是否正确吗？学习性测试，是指通过测试来掌握和检测第三方代码是否可靠。这拓宽了我对测试的作用的认识。大部分第三方代码，文档要么缺乏，要么复杂得很。直接读第三方代码的文档，是一种学习使用第三方代码的方法。知道了学习性测试后，今后学习第三方代码，可以使用学习性测试方法。

系统设计，是现在很热门的架构师所做的工作。换言之，系统设计，即架构。不可能脱离具体的使用场景来谈合适的系统设计。淘宝的系统设计，不能说不好，但对于一个个人博客，使用淘宝的系统设计，就是用牛刀杀鸡了。

有一种观点，说是良好的系统设计，都是随实际情况的发展演变而来。这种观点，令我害怕。若如此，我没有机会接触一个系统从简单演变成复杂的好系统，我怎么能掌握高超的系统设计技巧，实现逆袭呢？即使我有幸接触了简单系统复杂化，若我不是系统设计的操刀人，我仍不能掌握系统设计技巧。

或许，不需要如此悲观。我虽不能从系统的演变实践中去领悟系统设计，但我可以看现有的复杂系统设计。再说，现实生活中，并没有那么多的从零开始设计一个简单系统、复杂化系统的机会，更多的机会是，在现有的系统上继续去演变它。

单元测试，被“测试驱动开发“的编程观点所提倡。测试，覆盖了所有的代码，程序员才敢随意重构、完善代码。没有测试代码，面对乱糟糟的代码，只要它还能运行，程序员就不敢随便改动。测试，是一种学习手段，还使代码可扩展、可维护。不能测试的代码，只能任由它们慢慢腐烂。

编写测试代码，应尽早抛弃那种用完即丢的小片段代码，而应像对待正式代码那样去管理它们。不管理的测试代码，最终不得不丢弃。

php使用的一个单元测试框架是phpunit，更完善的一个测试框架是codeception。我曾经尝试使用，耗时多，收益小（归咎于学习能力差，要通过多学新知识来提高学习能力）。由于我是在项目代码很复杂的时候才引入单元测试，时间和精力，不允许我写出覆盖所有代码的测试代码。吸取此教训，引入单元测试的最佳时机，是在写下第一行项目代码之前。

并发编程，与线程有关。一个采集web站点资料的程序，24小时之内刚好能采集的站点是100个。假如要求该程序在24小时采集10000个站点，是实现不了的。此时，并发编程可以派上用场。开启100个线程，24小时运行，能实现采集10000个站点的目标。

并发编程，涉及到一些概念：死锁、活锁、饥饿线程。死锁是指两个或两个以上线程，都在等待着对方释放资源。举个例子，A等待B执行完毕释放资源，才能继续执行；可B却等待A执行完才能执行。互相等待，造成了死锁。与数据库中的“死锁”含义相似。活锁是指两个线程串行执行，一个执行完之后，另一个再执行。可是第一个执行速度太快，执行完之后，马上开始下一次执行。第二个线程一直没有机会执行。

饥饿线程，是指一系列使用共享资源的线程，在一部分线程使用共享资源的时候，其他线程只能等待。反之，亦然。这就是著名的“哲学家的宴会”。一群哲学家围坐一张圆桌子吃意大利面条，每两个人之间放着一把叉子。当一个人拿起左右两边的叉子吃面，他左右的人没有叉子，只能饥饿地等待。

并发编程代码，常规测试难以暴露出问题。并发编程时，把并发编程代码和普通代码分割开。测试的时候，逐一测试。出现了问题，也便于定位问题。