网站地图
热门搜索: 更多
  这方面最明显的例子就是记账系统。许多人都见过“想当然”的记账系统,每一笔账目发生的时间、金额都要记录下来,但也仅此而已了,绝没有记录所涉及账户的即时余额,涉及的账户里也没有对应的记录。结果某天发现账户出错,只能手工一笔笔地追查,效率极低,而且容易额外引入错误。
 
  出现这种情况当然很糟糕,但也有一定的道理。记账这回事已经有几千年的历史,但“在会计活动中对每一项经济业务按相等金额在两个或两个以上有关账户相互对应地同时进行登记”的复式簿记法,直到12世纪才在意大利诞生,引入我国更是要等到晚清时期。如今许多做软件开发的人未必学过会计知识,做出的记账系统没有复式簿记的思想,也情有可原。
 
  其实按我的经验,往往越是复杂的系统,越是复杂的功能,越是应该学“复式簿记”,也就是不怕麻烦,清楚记录因果链条,提供详细回溯能力。以前我们曾做过一套计费系统,其实就是把一大堆阶梯价目表做到系统里,上线后经常有客户来吵架,说计费出错了,每次都要劳心劳力来核对。即便系统没有出错,也没有办法第一时间否认系统出错,第一时间证明给用户看。
 
  后来大家痛定思痛,花大力气把计算过程做成了“自解释”的:每一步都有详细的记录,按照哪一份标价表格的第几条规则,具体是怎么计算的……总之,每一笔费用都有详细的计算过程可查,而且各子系统之间需要维持状态关联,保证彼此的数据和状态实时一致,如果出现问题及时报警。 这样做繁琐是繁琐了点,但上线之后不久就解决了争议,程序员有了更多不被打扰的时间,用户也有了信心。我是在世界杯期间才知道有个旅游网站叫“马蜂窝”的,后来一直也没关注。没想到最近几天,马蜂窝重新回到了大众的视野,只不过,这次亮相好像是从广告的另一面出现的,因为这几篇文章对蚂蜂窝进行了数据分析,得出了若干结论。
 
  目前来看,马蜂窝网站对这几篇文章提出了异议,但是似乎还没有给出合理可信的解释。事实的真相如何,或许还要等等才有答案。不过我还是推荐大家阅读这几篇文章,相信大多数人会从中获得不少启发。
 
  说到数据分析,似乎许多人都会一点,无非是算算总数啦,算术平均啦,看看极值啦,好一点的还知道方差、标准差。但是光这样做数据分析,能得出的结论相当有限。怎么办呢?更复杂的数据分析要怎么做?许多人一看到“更复杂”,就想起复杂的数学公式、建模、曲线拟合等等,让人不胜头痛。
 
  其实数据分析也可以不用那么复杂,搞清楚数据之间的关联就可以有不少发现了。比如这几篇文章就提供了非常有趣的视角,比如:
 
  看到这些分析的时候,我忽然想起许多年前看过的一部破案电视剧。犯罪分子为了打劫资金,苦心孤诣提前半年做准备,有人提前“出国打工”,有人男扮女装,时间选择大年三十以鞭炮声为掩护……劫案完全按照预先的设计进行,可谓天衣无缝。警方翻来覆去侦查,始终找不到任何破绽和线索。最终,案件的突破来自一个小细节:犯罪嫌疑人说自己某年某月某日乘火车回来,所有的行程都能对上,都有证明。然而警方检查当天车站记录的时候,发现当天那次火车晚点了。沿着这条线索,之前那些精心设计、严丝合缝的环节就像多米诺骨牌一样悉数倒下了……
 
  这几天的蚂蜂窝事件,让我想起了之前的电视剧,它们说明的都是同样的道理:制造几份漂亮的数据(证据)是很容易的,但是制造内在逻辑统一的数据(证据)是很难的。
 
  那么,上面说的这些事情,和软件开发有什么关系呢?
 
  要知道,我们开发的软件大多是要运行在现实世界里的,是要与现实世界打交道,与现实世界保持一致的。只不过真实世界的内在逻辑——火车晚点了就不能直接坐上当班汽车,饭点才有事件和兴致发餐馆点评——往往不能原样进入软件世界,所以软件系统里只剩下数据作为真实世界的载体,用数据来反映世界。虽然大家常说“要用数据说话”,但许多时候数据也是会愚弄人甚至骗人的。那么怎样避免被数据愚弄,怎样识破数据的骗局呢?简单的经验是,不能仅仅就数据来看数据,而要看到许多数据之外的东西。
 
  数据之外有什么?最明显的是现实世界的约束。比如汽车上坡当然要比下坡慢,口袋里没有钞票了就买不了东西等等。在生活中,这些东西都很好理解,似乎是“不言自明”的,甚至你没觉察到也摆脱不了这些约束。但是进入到软件的世界里,程序员开发的时候往往就把这些约束忘在脑后了,或者完全依赖于产品经理给出的规则。所以有的游戏里汽车上坡和下坡的速度竟然是一样的,有的账户系统可以可以“逆向”充值给银行卡,储值余额却变成负数……
 
  我刚刚工作的时候,在书上看到的一个例子让我印象深刻。天上的飞机需要知道航向,所以Plane对象有个成员变量是heading。通常我们会用一个整型数值表示它,但是那本书上提到这是不对的!因为航向只能在0到360度之间,所以你用整型数值时一定需要给setter加上一段逻辑,确保这个值只能设置在0到360之间。否则,难保其它系统读到heading时不会出错。“只有加上了对应的约束,变量才不再是原始普通的数字,而变成了能承载业务价值的数据”。
 
  许多年过去了,我仍然记得当时的惊讶:原来竟然可以这样!原来竟然应该这样!
 
  后来我自己在开发中一直保持这样的习惯,虽然麻烦,也因此避免了许多故障。再往后看到《领域驱动设计》才明白:在设计软件系统时,领域知识往往是最重要的,而领域知识的一大部分就在于识别领域中的各种约束。这些约束很难由产品经理巨细靡遗地穷举出来,而必须由参与开发的所有人达成共识,在系统里实现它。但是无论如何,这些约束都是必不可少的,没有它们,系统就很可能出现各种稀奇古怪的现象。
 
Copyright © 2015-2016 辽宁省中国国际旅行社 版权所有