送给一起加班的兄弟们

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

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

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

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

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

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

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

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

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

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

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

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

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

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