刚接手项目不长，近个月，需求添加一个小功能。

要求处理后台通过 X 后，通知用户。

然后改需求到 Y 后，X Y 是同一个 service 里 function， 早一步预留接口，改一个参数完事。

再改需求到 Z 后，在不同一个 function ， 基本思路是一样的。 谁料。。。

[x] bug1 : 这个 function 会被另一个逻辑定时调用，本地时还没来得及发现，线上调试却是莫名其妙，最后被同事发现问题，修复之。 [ ] bug2: 更新数据库后，小功能再读数据库，取更新成功的数据，和判断再实现。出现数据读取不对，原来是数据延时。 线上 使用复制集3节点，应用读写分离。使用 writeConcern 暂无效，无不知道哪里的问题。

解决 bug2 的思路有如下： 1、setTimeout ；2、看上游数据流，避开读取数据库"变化的"数据。

1、还没试。 2、暂看看。

上游 cb 是无关数据，改动大，不然也不会在 service 下追加 service 。上上游是核心业务，非常重要的，不想碰，更不想读。cb 的数据看到相关。想到可能不固定，比上次粗看更用心了。好吧， 一个 service 10+ function 飞流直下三千尺，哦，不，近1000行而已。（更核心封装已做成 npm package 了）module.exports = {四个fuction}。

不知道哪个 function 调用哪个，打开 webstorm 跳转吧。记得上次对同事使用鸭子调试法，找到入口，关闭 api ，直接 cb。现在忘了。主要四条分支跳上跳下。好吧，再看一眼就洗洗睡，没办法了，就看一眼 controller 吧，很短，很好，业务逻辑都写在 service 里。当我看到第一句时，我看到曙光。是这样的：

if (req.method !== 'POST') return res.json(xxxxx);

革命尚未成功，壮士仍须努力。早点洗洗睡吧。往后还有很多活。

P.S. 我司使用 sails , node 0.10.x.