继续艺术之旅，上一节学习了如何通过抽取方法来使得程序的结构从总体到局部到细节都更加清晰，这一节是结构清晰的又一个方向，如果说前一节说的是理性逻辑，那么这一节说的就是感性自然。
理性逻辑可以学，可以有规则，可以照猫画虎，感性自然就要更抽象一点，不过好在我们有一个非常好的工具可以使用叫自然语言。
也就是说，如果你的程序结构可以非常轻松的用自然语言描述，看上去没有什么别扭，不通顺的地方，那么这段程序的可读性通常没有什么问题。反之就要看看是不是有更自然的写法来满足同样的要求。
更重要的是用自然语言描述可以用在开发之前的Design的过程中，也就是在编写程序之前，先用自然语言描述一下看看，是不是通畅优美，如果不是，那么这个设计就存在优化的空间。
就像今天下午Retro上Dave同学提到的一个话题，叫开发同学们往往希望完整的解决BA同学提出的Story，而因为复杂度，或者时间的约束，勉强向前做，很多时候很难得到一个好的结果，可能整个Story最终都没有完成。
其实一直非常希望开发同学在Design的时候对Story的内容做一次开发层面的反馈：BA的Solution究竟行不行（相信大部分经过Scoping和Brief的Story是可行的），有哪些细节应该考虑，有哪些分支可以暂时忽略（可以暂时忽略的分支对Design非常重要，因为他可以最大程度的降低实现难度），最终形成一个开发的方案。
尝试从开发的角度用自然语言描述一下Story的方案是一个非常不错的办法（BA虽然已经用自然语言描述过解决方案了，不过开发层面的自然语言描述是不同的），找出清晰自然的部分，也辨别出模糊不那么自然的部分。大部分的Story内容是可以从需求的角度做一些优化和妥协的，在时间有限，系统复杂的前提下，集中精力完成主流程是开发和BA都希望做到的事情。那么这里面应该被考虑砍掉的首先是开发用自然语言描述不清的部分。
小结一下：1. 自然是非常重要的可读性原则；2. Design的时候先用自然语言描述逻辑，可以非常好的帮助我们理清思路，也可以使写出来的代码可读性更好；3. Design时候用自然语言描述不清或者困难的部分，80%的情况可以与BA讨论暂缓或者修改方案，集中精力解决主要矛盾。不要勉强向下做。
