自上世纪末，有关仅以测试和代码驱动设计的概念一去不复返。相对于任何宏伟的愿景，对于细节的关注甚至是更为关键的专业性基础。
当然，开发人员通过小型的实践获得可用于大型实践的技能和信用度。
其次，宏大的愿景中最细小的部分没有把握好，都会将整个大局的魅力毁灭殆尽。
这就是整洁代码之所系。神在细节之中
软件的生命周期= 20%生产 + 80%维护
即便是汽车行业里，大量的工作也并不是在于生产而在于维护或者避免维护。对于软件而言，百分之八十或者更多的工作量集中在我们美其名曰的“维护”的事情上：其实就是修修补补。
精益（Lean）代码整洁5S原则
整理 Seiri：搞清楚事物之所在，或谓sort排序。
整顿 Seition:或整齐systematize系统化一词。物皆有其位，而后物尽归其位（A place for everything , and everything in its place）.
清楚 Seiso:shine对于那种四处遗弃的带注释的代码及反映过往或期望的无注释代码，除之后快。
清洁 Seiketsu：标准化，使用一贯的代码风格和实践手段。
身美 Shisuke:自律，在实践中惯侧规程，乐于改进。
A stitch in time saves nine.
即便是在宏伟的建筑作品中，我们也听到关注细节的回响。无论是架构还是代码都不强求完美，只有求竭诚尽力而已。人孰能无过，神亦容之
---------------------------------------------------------------------------------------------------------------------------------------------------------------
催赶着退出产品，代码写的乱七八糟。特性越来越多，代码也越来越烂，最后再也没有办法管理这些代码。是糟糕的代码毁掉了一家公司
随着混乱的增加，团队的生产力也持续下降，趋于零。
管理层就只有一件事情可以做了：增加更多的人手到项目中，期望提升生产力。可是新人不熟悉系统的设计。他们不明白什么的修改符合设计意图，什么样的修改违背设计意图。而且，他们以及团队中其他人背负着提升生产力的可怕压力。于是他们制造更多的混乱，驱动生产力向零端不断下降。
花时间保存代码整洁不但有关效率，还有关生存。
在很多时候，我们编程时，其实并不是把所有时间都花在写代码上，更特别的是，我们大部分时间都花在读代码中。
经过测试，大致得出这样一个公式：编码 = 90%看代码 + 10%写代码
可以看出，容易让人看懂的代码，更容易修改。
很多时候，我们在混乱状况下，写出了很多糟糕的代码，我们不要责怪管理层，因为我们是自作自受，我们太不专业。
同理，程序员遵从从不了解混乱风险的经理的意愿，也是不专业的做法。
C++程序设计发明者：我喜欢优雅和高效的代码。代码的逻辑应当直接了当。叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护。根据某种分层战略完善错误处理代码。性能调制最优，省的引诱别人做没规矩的优化，搞出一堆混乱出来。整洁的代码只做好一件事。
---------------------------------------------------------------------------------------------------------------------------------
下一次将分享代码整洁之道的实践。
----------------------------------------------
努力，让世界比你来时更干净些......