从组装鞋柜谈软件开发

下午没事帮家里人组装了一下鞋柜，发觉很多地方都和软件开发异曲同工。

图片发自App

从设计上谈，鞋柜本身是有自己的结构的，我组装的这个是大号复式的。软件当然也有自己的结构，专业点叫架构，这个架构可能只是简单传统的mvc，也可能从前端到后端到服务器架构都有。里面也很有可能涉及一系列的设计模式，策略模式、观察者模式云云。毕竟只是个鞋柜，如果是建筑就很有可能有一系列可复用的设计模式，比如卧室的设计、走廊的设计、客厅的设计，不同的设计模式会达到不同的目的。

图片发自App

从流程上看，组装鞋柜有说明书，书上有简单明了的安装步骤。类比软件开发，我立马想到的就是uml建模，安装步骤更像uml中的时序图，材料之间的连接关系则像类图，甚至可以说长木棍继承自短木棍，至于类与类之间交互就自由YY吧。

图片发自App

从功能上看，鞋柜的不同组件都有自己的功能，柜脚、长网格、短网格、三连通、四联通（看名字就基本知道啥功能了，不一一解释了）。软件当然一定肯定有很多功能，甚至很多软件就是功能驱动的，一个绘图软件，画笔、画刷、橡皮擦、复制、粘贴、剪切、选择等等都是功能。但功能也有主次之分。比如鞋架的核心功能肯定是放鞋，绘图软件的核心功能一定是绘制，至于你基于位图还是基于矢量图那另说。

接下来咱们再看开发过程。

图片发自App

软件开发通常以模块开发驱动，每个模块有自己特定的功能，有的模块比较重要类似于鞋柜的长网格和短网格，有些模块虽然功能不多但很可能使用量大比如鞋柜的木棍。模块之间怎么结合呢？先看看鞋柜，那个三连通四连通就是用来木棍和木棍或者木棍与网格连接的。软件开发里面管这个叫做接口，用来做模块之间的交互，4连通就是交互比较多的接口，3连通就是交互较少的接口。

图片发自App

软件开发通常要涉及到解耦合，就像鞋柜解耦合成了22条的20cm木棍、16条的25cm的木棍等，有什么好处呢？好处大了，如果你组装了半天发觉有个地方组装错了，要改的地方就很少，可能只要改一个就行，因为已经解耦合了，功能很独立，不会捆绑在一起。

至于重构呢？我也遇到了，当我发现要先穿好布垫再搭第二层时，我已经搭到第三层了。结果就是我重构了，怪谁？怪架构写的不清楚吧，哈哈。

组装鞋柜的时候你很容易发现，你每一层甚至每两个组件之间连接的不牢固或不合适会导致鞋柜不稳。在软件开发里面我们也需要让自己的代码具有很强的鲁棒性。鲁棒性怎么来呢？测试是个好方法，鞋柜商家送我一个木锤用来固定三连通和木棍之间的结合度并矫正木棍的位置，这个就是测试，具体一点黑盒测试吧。因为商家比较坑少了几个20cm的木棍，我自己锯完了以后用尺子测量了一下，这个勉强算白盒测试吧。集成测试当然也有，就是组装完鞋柜后测试每层的稳定度。

鞋柜的ui没其他的就是那块遮羞布吧，毕竟不是美工。

图片发自App

那鞋柜来类比软件开发还是以小见大了，软件开发远比这复杂的多，而bug这种可能神奇的事故才是程序员的症结。如果是庞大的建筑设计会有更多类比的价值，这个当是开胃小菜好啦。