软件不软的一个主要原因，是其经常处于变化之中。所以，当策略分离不同的变化方向被提出后，一个随之而来的问题也就产生了：何时分离？
尽管一个软件已经满足了当前所有需求，作为富有经验，伤痕累累的程序员，我们却毫无喜悦，因为我们很清楚，事情还远未结束：用不了多久，新需求就会再次排山倒海般涌来。而当前设计能否顶得住下一波的冲击，没有人心里有底。
怀着不安的心情，我们打开IDE，调出代码，翻页跳转，试图从字里行间揣测未来变化的可能性。可深究起来，几乎每一行代码，每一项知识都似乎存在变化的可能性。但如果把每一种可能的变化方向都进行分离的话，系统又会陷入无边无际的复杂性。这种两难的境地让我们感到绝望，强大的无力感让我们一度怀疑自己是否选错了行。
一段时间之后，大批新需求终于来了。经过一番分析，变化的方向逐渐清晰明了。但交付期限所带来的急迫感和焦虑感，让我们觉得自己根本没有足够的时间深入思考如何对原有设计进行合理的修改以应对这些变化，而对于修改已有代码所可能带来的潜在风险，也在不断提醒我们应该“保守稳健”。于是，我们再次祭出杀手锏——copy-paste-modify 三步曲——这不仅可以让我们看似很快的完成交付，还可以让管理层看到：我们又在短时间内产出了如此巨量的代码，从而认为我们有着惊人的生产力。至于带来的可维护性问题，呵，堆自己的代码，让别人去重构吧……
这两种倾向在实际项目中都并不罕见。前者经常造成设计师徒劳无功的预测未来，其过度设计的倾向给系统带来诸多不必要的复杂度；后者则快速让一个系统陷入步履维艰的“焦油坑”。
与此有关的另外一个例子是，当年第一次读到单一职责原则时，对其含义一个类只应该有一个引起它变化的原因大惑不解：这个类未来会以怎样的方式变化我是无法预知的，我怎能在当下就判定一个类是否符合单一职责？
多年之后，我才意识到，对于这个问题的答案其实已经给出，只是隐藏于别处：当谈到何时应用开放封闭原则时，Uncle Bob给出的答案是：被第一颗子弹击中时。
这是一个绝妙的隐喻。
它首先强调了时机：不早不晚，第一颗。早了，过度设计；晚了，则成为再次被愚弄的傻瓜。
其次，它还隐含着变化的方向：当第一颗从某个方向射来的子弹击中你后，你就必须首先解决来自那个方向的威胁，尽管子弹还可能从任何其它方向射来，但那是另外一个问题。所以，开放封闭原则不可能对所有的扩展都开放，对所有的修改都封闭。只有每次当你被来自某个方向的第一颗子弹击中后，你及时运用了此原则，筑起针对此方向的防御工事，随后，你才可以对来自此方向的其它子弹做到“开放封闭”。
换一个说法，这个世界里，本质上只存在三个数字：0，1，和N。
0意味着当一个需求还没有出现时，我们就不应该在系统中编写一行针对它的代码。
1意味着某种需求已经出现，我们只需要使用最简单的手段来实现它，无需考虑任何变化。
N则意味着，需求开始在某个方向开始变化，其次数可能是2，3，... N。但不管最终的次数是多少，你总应该在由1变为2时就需要解决此方向的变化。随后，无论最终N为何值，你都可以稳坐钓鱼台，通过一个个扩展来满足需求。而这正是我们苦苦追求的正交性。
0，1，N就是简单设计的精髓。
从而，就不难理解：所谓单一职责，就是当变化还没有发生时，我们可以认为任何一个类都是符合此原则（除非特别明显的职责耦合）。当变化初次发生时，将一个个变化的原因分离出去，然后，得到了一组类，它们依然符合单一职责。
变化与职责，共生共灭。
最后需要强调的是：在被第一颗子弹击中时，能否做出正确的应对，除了辨别和解决问题所需的敏锐嗅觉之外，还需要勇气。当有人问我为何总是敢于在遗留系统上大刀阔斧时，答案很简单—— 胆大心细。
