好久没有写读书笔记了，说来惭愧。最近一直在整理项目文档交接的事，感觉智商不够用。相信大家在理解别人写的代码的时候都有过这种经历，这块逻辑在干吗？这个算法解决了什么......一万个为什么在脑海中闪过。
一般来说，代码是对业务逻辑更高级的抽象描述。脱离实用场景和业务，代码只是一堆没有任何意义的散沙。那么在原有逻辑缺失，能不能从代码中去推导出原有的业务逻辑呢？难，然而我正在接收这样的考验。
下面是我反推逻辑时产生的一些想法：
1.必要的注解还是很有必要的。代码是凝聚了程序员的智慧。思想很抽象，每个人都有看问题的不同之处，当然也就有不同的解决方案。怎样帮助其他人更好的理解这块逻辑，除非你们思考的一样（哲学上说没有两片叶子相同）。虽然经过大量的时间理解了写的算法，并对作者的思维方式赞不绝口。可是换个角度这样的时间成本是否值得？读者又得到了什么？同样场景下的同样业务还会再次发生吗？也许一个简单的备注说明它处理什么，收效会好很多。
2.相信代码中的存在即合理。程序中的每一行代码都有存在的理由。对于没有产生作用的代码要及时的清理。就像建造一个大楼一样，每块砖都是一个必要的单元。多余的砖对于建造者来说无可厚非，不影响整体的稳定，留着就留着。但是对于参观者来说，那是不是艺术家故意为之的呢！为了增加美感而不能缺少的部分！当我们很仔细的了解了那段代码后，发现这部分在很长一段时间随着业务的调整就弃用了，但是代码保留了下来，这对于其他人来学习真是个悲伤的故事。及时clean code很有必要，让每行代码都有存在的依据。
3.文档的更新。上面说到代码依靠业务，业务需要文档来进行整理、存档，保留智慧。然而在teamsite上发现的都是最新的业务解释文档。这一做法很好，很方便新的业务人员及时了解项目的进展。但是对于开发人员来说，效果也许就没那么好了。代码是很容易看出历史痕迹的。毕竟从文档产生的第一天起，相关代码就开始随之生成。如果业务变化了，而相关代码没有及时的清理更新（在现实生活中很常见），历史遗留的代码就缺少了存在的依据。对于理解代码的同学来说也是灾难性的打击。那么有没有方法避免呢？我想到的一个办法就是让文档也具有历史性，每有一次新的业务，就生成一个新的版本。v1、v2、v3......
4.及时请教当事人。当理解完一段代码后，如果能找到当时写的人更好，找不到也要找找曾经参与的人帮助你检验下你的理解是否正确，能不能简单的还原出当时的场景。一个人的理解能力毕竟有限，特别是在对业务不熟悉的情况下，很容易就走向偏路。及时的沟通，就像敏捷迭代那样，真理也不是一个人慢慢的领悟出来的，都是在一次次的碰撞中形成的。
5.必要的流程图释义。对于一个细小的模块，代码足够清晰，流程图是没有存在的必要的。但是对于一个大的业务流水线，流程图就显得至关重要了。制作工艺也是先有图纸，要是看别人的代码有指导性图示解释，想想都觉得很美好。
