重构

  • 最近总能发现,很多东西,我在实践中总结出的的经验,都是别人在书中提到过的,就比如《重构》这本书,我一直认为重构不应该拿出专门的时间,而是应该在开发新功能或者修改bug的时候去做,作者也非常强调这种观点:

    不用专门时间,随时随地,比如以下三种情况:
    添加功能时
    修补错误时
    复审代码时

    比如在一个人员缺少的阶段,如果你跟产品汪或者CEO说,我需要几个星期甚至几个月去专门重构下,相信他们砍了你的心都有了。不是说这时间不该花,而是,这个时间可以算在功能开发上面,你跟产品沟通清楚:『
    我们开发的这个功能是基于某个以前的功能的,但是需要改进它,这样的话,以前的功能可以更稳当或者更快,然后呢,以后的相关


  • 最近看APM上面的API响应,发现有个API在挑事,平均响应时长4s,已经到了不可忍受的地步。

    仔细一看,发现是动态有关的API,类似于微博,进一步分析发现,这个API设计不合理:用了mongo的aggregate,占了响应时长的90%以上,这个不适合在API使用,因为非常耗数据库的计算性能。

    Mongo数据库结构

    User: {
      _id: ObjectId,
      followings: Number,
      followers: Number,
    }
    TweetPage: {
      user: ObjectId,
      count: Number,
      oldest: Date,
      newes
  • 这周五解决了挺有意思的一个 Bug。

    背景

    由于长期以来,在我们的 Node.js 服务端项目中,离线任务大部分用的是 kue,这是个轻量级的任务队列,之前 也有过介绍。而周五那天我正准备将之前的 kue 队列重构成 RabbitMQ 的队列的相关代码上线。

    RabbitMQ 任务队列是我基于 amqplib 实现的,在生产环境跑了半年有余,没什么大问题。

    但是,按照墨菲定理,你最担心的事情总会发生,或者说:出来混迟早是要还的。

    悲剧

    结果,明明在预发布环境测试没问题的,却在正式环境完全不起作用,一直在报 EPIPE 的错误,并且在之后 ack 时报 channel closed 的错误。

  • 背景

    我们团队有个项目由于开发时间较长,且是前后端杂糅的开发方式,维护成本很高,在线上暴露的问题很多。而且因为对接了公司一百多条产品线,每天都会接到大量的客诉和产品线反馈的问题。2017年11月份以产品为主导,从产品层面对流程进行重新设计,对该项目进行了前后端的重构。作为前端的负责人我用这篇文章分享下,整个过程从技术选型,开发,上线的一些经验。

    技术选型的思考

    首先我们先看下下面我们项目中的几个页面,来总结下一些他们的特点。

    我们的页面主要是需要用户填写的表单居多,在页面加载的时候不需要去请求获取和渲染大量的数据。而且一个页面需要显示的状态较多(比如上面的3张图,在项目中是一个组件)。还有一