《代码整洁之道 》第十四章 逐步改进

第14章 逐步改进

本章介绍一个开始还不错，规模扩大之后就出问题的模块，并且是如何重构的。
遇到解析命令行参数的情况，如果没有工具，就得遍历传入main函数的字符串数组。比如写一个Args。
你只要简单地用输入参数和格式化字符串构造Args类，再向Args 实体问参数值即可。

14.1 Args的实现

主要的代码的优化，写得还是优雅的。可以阅读一下。
要编写整洁的代码，就必须先写肮脏的代码。有时候就像写作文一样，需要先写草稿，二稿，一次次的修改，直到终稿。
许多人认为，首要任务就是能写出能工作的代码，只要程序“能工作”就转移到下一个任务上，而“能工作”的程序就一直停留在那个所谓“能工作”的状态。这是一种自毁行为。

14.2 Args：草稿

主要就是贴出Args的初始代码。

14.2.1 所以我暂停了

作者在草稿里没有把另外的类型也添加上，添加上还会更糟糕

14.2.2 渐进

毁坏程序的最好方法之一就是以改进之名大动其结构。有些程序永远不能从这种所谓“改进”中恢复过来。问题在于，很难让程序以“改进”之前的方式工作。
应该是大量小规模的修改，修改变量名、数据结构

14.3 字符串参数

优秀的软件设计，大都关乎分隔—创建合适的空间放置不同种类的代码。对关注面的 分隔让代码更易于理解和维护。

14.4 小结

很多团队的要求都只是让代码能工作，但是这样就留下了很大的隐患，而且会一直腐烂发酵，一片沼泽，不受控制，拖累团队。
保持代码的整洁和简单，不要让代码有腐败的机会。
本章的代码例子其实可以好好阅读，因为几乎一步步的优化。很好的案例。