技术债务

背景：最近一直在给研发团队强调必定要把产品平台关键的帐号系统分离出来，而不是和业务产品线有瓜葛。可是由于涉及改动太大，业务线很忙迟迟获得不到执行。在这种状况下，我协调召开了研发的紧急会议，要求务必在近期解决这个问题，甚至不惜减慢业务线的进度。其实若是你们仅仅是由于时间紧、任务重没法改动我倒不担忧，我最怕的就是你们认为这件事情并不严重，在我作技术的9年生涯中见证过太屡次由于不重视这种状况、或者推迟修正形成的更大或者不可挽回的问题，那咱们用2周或者更多时间来修正半年前犯下的错误是彻底值得的。

---

       为何我强烈要求这么作，具体缘由不作分析，只须要说明咱们是平台级的产品，帐户系统是公共组件，若是这些公共组件却附属在其中一个或某个业务产品线中，你们就知道咱们后期的灵活性和可扩展性面临怎样的困境了。

上面谈的这种状况就属于技术债务，技术债务的造成每每有两个主要缘由：

1. 没有架构能力，对将来可能面临的糟糕状况没有预知；

2. 知道可能后期会面临问题，可是为了追求进度，暂时放弃精细化的架构设计；

       对于第一种状况，很少说，等你发现问题时估计就有些晚了，相应的付出的成本也会更大。因此对软件为何咱们经常强调高端的架构能力，而不是仅仅机械的代码能力。

       第二种状况其实你们是知道后期可能会遇到的糟糕状况，可是为了求快并无进行好的架构设计，在此以后，大多数人会由于心理上的拖延或者生理上的懒惰把重构任务推后，这时技术债务就会像高利贷同样越滚越多，你要么倾家荡产去还债（彻底重写），还有可能 go to dead!（产品失败）。

       听上去很危言耸听，可是这偏偏是我在工做生涯中屡屡看见的。当你由于技术债务积累了一年、两年、三年时，你基于此的产品实现也会愈来愈复杂。即便你招聘到了业界大牛，当得知这种改动是颠覆性的，须要消耗大量的时间和人力时，也每每使其没法下手。反过来我也经历过几回发现这种问题时，咱们据理力争，投入阶段性的力量全力还债的场景，我记忆中的几回通宵就是在那个期间发生的。

       因此谨以一个技术人劝你们：前期若是能预见到技术债务，并且时间又紧张的话，本身多努力再努力去解决，由于这是为你之后争取时间和精力；中期若是能及时发现技术债务，无论付出再大也要有勇气决然解决，由于这可能关系到产品和你的生存；后期发现了这些问题那你就吸收教训，开展下一个项目时去避免。

      再以一个处 女座的工程师劝你们：请把本身写代码、作产品看成是在打磨一件艺术品，质量好坏是能够迭代的，可是若是你没这个态度我想永远不会产出优秀的做品。