继续感受艺术，这一节的艺术已经进入了中高阶了，如果说前面的艺术说的是怎么把一块砖做好，把一堵墙砌好上，这一节主要讲的是怎么把房子的结构搭好。
搭结构比写一个代码片段要难一些，因为很多时候并没有一个规则，书上用了两节来讲述如何把一些代码抽取出来到一个独立的方法里，从而形成一个良好的代码结构。主要通过一些例子来阐述，作为读书笔记，我帮他抽象两个原则出来：
主要的原则：一个方法只做一件事。这句话看着正确无比，但是什么叫一件事呢？
一件事通常是可以不停的分解的，比如代码修炼，这是一件事吗？是的，然后他又可以分解为：读书，写笔记，分享，应用四件小事。读书又可以细分为找到书，打开书，看内容，合上书，放好。
不过有了这样一个树状分解结构，我们可以重新定义一下一个方法只做一件事：一个方法应该完成树状分解结构上的一个节点。不能多，不能少。
那么要思考的就是将事情做个分解，主方法就是根节点，碰到一个子节点，抽取一个方法来完成，叶子节点的逻辑自己写。 完美！
说起来容易，做起来可能还是有点难度的。
还有些原则，尽可能使抽取出来的方法更通用(意味着可以被别人使用，也可以去使用别人现成的方法)。
正好反思一下这两天比较痛苦的一个story
把到付应收从挂在收货人上边，放回到客户上面。
这个story十分应该做，到付应收用的用户非常少，上面这个逻辑又十分特别，与其他流程一结合就容易爆炸。所以报了这个story，具体来说是：
1,把到付应收正常的挂到客户上，消除他的特别逻辑。
2,把订单上的收货人(原来因为要关联收入做成了一个复杂对象)变成一个简单的字符串。
今天design的时候突然意识到这个story实际上有点违反了上面这个一个story只做一件事的原则。
因为要完成到付应收逻辑的简化实际上只要完成上述第一件事就可以了，第二件事是不是要做简化可以是另一件事，订单上收货人的复杂对象是不是只有到付应收会用到可能需要进一步分析。
实际上将第二步拆成另一个story来做，可能更稳妥一些。
网友评论