送给加班的兄弟们


算了一下,从开工到12月18号上线,接近三个月,三个月时间里,做了一些东西,一个垂直行业的B2B商城,后端pc管理,前端用户商城,移动端包括IOS和Android,整个过程惊心动魄,因为不可能完成的东西居然上线了。

一般来说一个做互联网产品的公司,产品经理、程序员、技术总监、测试、运维等都是标配,这些我们都是有的,而且我们还有deadline,有了deadline才有激情,这个才是真理。任务分配好后,就撸起袖子开始干了!

“喂!哥们!这数据库的表字段是啥意思啊?有数据库设计文档吗?”,”文档,什么文档!我们没有,自己看数据库吧!“

“老大!订单这块需要考虑对账吗?”,“什么对账!先把订单功能完成再说,二期在考虑对账!(你懂得)”

“产品兄弟,这块逻辑要怎么处理?你这原型图上面反应不出来啊?”,“我来和你讲,这样这样这样就行了!文档后期再补,先上线!”

两个月过去了,明天是第一次联调的日子,“今晚和移动端的接口一定要调通,否则都不能回去!”老大发话了。消灭掉最后一个排骨,兄弟们把嘴巴擦干净,提枪上阵。

一个星期后,公司内部要做一次全流程演示,可目前线上签约还没通!那只能老鸟上场了,加班加点,核对签约服务商的每一行代码,排除前人留下的每一个bug,终于在演示前一天晚上11点整,流程跑通!老鸟的眼睛已经彻底红了,其他兄弟也都倒在桌子边,杀场一片狼藉。“为保证明天演示成功,今天在做最后一次全流程测试!测完通过就回家睡觉!”,领导这个时候又发话了。

上线日降临,全部技术人员严阵以待,配合发布会现场的演示,后台运营人员的协作有条不紊,截止下午发布会结束,系统运行正常,订单正常生成,流量稳定,压力平稳,整个流程走完闭环!

这种场面每个互联网公司几乎都有,只是惨烈程度不同而已!一个初入市场的互联网产品,总是以功能为主,架构、优化那是后期的事情,在deadline和市场的压力下,是可以理解的,但是,下面发生的事情,就无法同情了!

上线后,对于二期的工作重点,除了重构以外,功能性需求也增加了很多,这样导致下一次上线前重构时间被严重压缩;从市场实际反馈来看,一味的堆积功能并没有多大的益处,而平台如果不做大手术,随着用户增多,后期重构风险也越来越大;由于前期数据库设计不合理,带来的业务层无法有效隔离,导致业务逻辑混乱,很难理清和分辨,不利于后期业务流程的扩展;整个平台工程划分不精简,后端服务没有统一,平台工程组织不合理,公共组件抽象不够,业务抽象不够,重复组件太多,业务编码不规范等等问题是急需要解决的。

而更可怕的是,从产品到研发流程,也是不够清晰的,说好的产品文档呢?产品需求评审哪里有?架构设计评审和重要模块的代码评审都没人想起来。代码依旧是嗖嗖的写,连测试到发布居然还是人肉,我想这些都应该是技术负责人份内的事情!没有安排好,没有提高效率,自然就只能堆积人力去完成需求了!最诡异的是,任务的分配也是欠妥的,一个人可能同时做几个不相关的模块,而一个模块可能由几个人在做,工作量分配也是不够理想的,接口理解几乎靠嘴巴,没有规范合格的接口文档,二期其实大家都不是很忙!

在有限的时间内,我们把平台工程用maven进行了重构,合并了多余的工程,抽取部分公共组件和后端服务,并且用新的分布式服务化框架替换了原始的PRC服务调用方式,为以后的扩展打下了一定的基础,并在安全和在线管理上做了加强。但是数据库还是没有时间重构,内部重复代码和坏味道的代码没有时间去剥离!在发布流程上部署了jenkins,做到了测试和预发布环境的持续集成发布,生产环境扔需人肉!

任何一个产品的市场化过程,都是一个充满血淋淋的深刻教训的过程,但是意识到问题后不修复,是无法原谅的!

以上文字仅怀念几个月来一起加班的兄弟们!