过程与结果之于文档

平生见过的文档不多。个人认为一个过程中的文档应该是一个做事的书面化。格式、范围也都是用来完成「做事」这个目标的。明确了目标就容易了。
有人说，有个文档，描述结果就可以了。这里的结果不是最终的结果，而是中间结果。举个例子，今天内幕提高准备金，你让人正飙涨的股票火速抛售。于是你就跟人说：全抛！大概就是这样。
就这事，有几个风险？
1、他信不信？
2、消息准不准？
3、他有没有其他干扰？
第一点，明明疯涨，为何要抛？你被怀疑羡慕嫉妒恨！
第二点，消息准吗？会不会是假消息？中途有没有变数？万一继续涨，怎么跟人解释？
第三点，你确定他一无所知吗？他是否比你知道的还多？万一你们的消息有冲突？
看到这个中间结果，问题就涌上来了。文档也类似，你拿到文档去做事却不知道为何这么做，结果会怎样？
文档里一定有很多你都没想到的细节在具体操作层面才会暴露出来。这时候去追诉为什么就显得尤为重要。不仅如此，过程还代表了一种思维方式，阅读文档的人也会因此而获益。当然，文档里的字就多了，但不代表你多想了，因为那些本来就要想。反而那些只有结果的文档不知道是不是灵感乍现的杰作？

坏设计下的烂代码无法应对变化

关于成本的系统，之前的结构，我是指数据部分还是有点儿复杂的，为bug埋下了伏笔，但最初期待的功能很多并没有实际作用，后面补充的需求却给这个模型带来了麻烦。是时侯砍掉那些多余的需求了，其实事情本没有那么复杂。之前我们用了类似视图的功能来做，对于查询我们可以无缝集成，不论sql还是代码，但对于插入和修改就必须跟踪数据来源，这仅是麻烦之一。当我们试图去操作excel这个平面结构的时候，操作excel本身就不同于sql，我们根据sql的数据来控制excel，这就存在对数据库的操作以及对数据指令的操作，严格上说我还应该保持二者的事务性，即便这一点已然被忽略了剩下的工作量也并不小。同样是因为excel，自动化测试并不容易做。因为excel是平面的，数据库也是，留下的部分其实都只是一些操作，所以也是我始终不接受所谓的面向对象的方式来做，务实点，这个底层并不适合，起码意义不大。2.0如果要做就一定涉及到领域对象和领域计算（规则），首先业务不简单，要学习，其次，一定要有一套能够支撑计算的计算框架，或者称为计算模型，这完全不同于增删改查，和流程也不是一回事，是个数学模型。如何做我并没有想好。我现在其实比较期望的是简化版的1.1而不是2.0。

如何用单元测试避免版本升级隐患

当我们的网站，在运行的时候，你是否考虑过做系统升级？OK，那些安全相关的漏洞，通常不会给你带来太大的影响，但是一些类似.net framework之类的，还有一些第三方的dll，则可能带来严重的问题。你的程序可能有意想不到的后果。虽然Microsoft在版本向下兼容方面做过了大量的测试，但也不见得就能保证你的正确性。你的所有问题，都变得连你自己都不知道了，你只有期盼上帝不要引爆那个炸弹。
单元测试，原本是用来保证代码正确，推动项目前进，描述用户需求的有效工具。但你想，如果你的项目对绝大多数的分支都做到完美的单元测试，你还害怕更换dll吗？版本升级，对你的影响是可控的，你可以重新运行所有的单元测试，并决定是否更新版本。
------------
本文因为篇幅较短，内容较散，所以列入该博客，大家笑笑就是。