继续修炼，今天修炼的小伙伴们晒了一些修炼的成果，虽然有些小伙伴被我轻拍了一下，还是觉得都非常不错。
R同学提出的整理接口记录的写法非常重要，期待优化及规范；
F同学的util类合并和统一管理也是基础，期待retro分享；
L同学通过代码分析，发现了潜在的系统问题，强；
W同学的消息状态机非常重要，清晰而明确的状态变迁能减少问题的发生以及查错的难度；
新加入的Z同学令人惊艳，能从分享中感受到对代码的热爱。
继续修炼下一个话题叫有始有终。作者通过了一个非常详尽的例子说明了有始有终的含义。其实我觉得作者通过这个例子想表达的并不是说提醒大家有始有终，在第一个错误示范中，代码其实也做了终的事情，所以他更强调的是要考虑意外情况下的终。
正常流程的终大家都记得，但是在分支流程，甚至意外情况下，这个终还是不是按预想的起作用，这是重点。对于程序来说开始就意味着消耗资源，结束释放资源，但是即使只有百分之一的情况没有释放，随着程序的不断运行，累积资源会越来越多，直到把系统压垮。
例子我就不举代码的例子了，说一说一种类比的情况，就是我们的产品story，我们经常因为客户的需求开辟一条新路，因为老路满足不了新的要求。但是在新路顺利通车后的一段时间后一定要想着把老路断掉，否则的话，路越来越多就会导致系统逻辑不堪重负。这种情况有很多，比如我们的新老菜单，并行存在超过两年了，终于要把它废弃了；再比如为某个客户加的水路整箱，在FCL的康庄大道建设好了之后也应该摒弃LCL的临时做法了。
不过story的有始有终难度更大一些，因为时间跨度大，很多时候一个flow已经没有太大意义了但是我们不会主动的感受到，这就需要定期的review和Refactor来整理并有意识的终了一些流程，这又像有一些语言有定期自动释放资源的能力，这是有始有终的最后一道防线。
