程序员的迷思——技术债
这个需求很简单。
1 引子
曾几何,一人一键盘,指尖到天明。跳动的字符,砰然的心动,这不是初恋,但很甜。
终有一天,心动变心痛。
从今天起,专注搬砖
什么需求,都能实现
复制粘贴,这很简单
一天不行,就两天
前后端到AI,不过是概念
总之,都能实现
2 技术债
“人一切的痛苦,本质上都是对自己无能的愤怒。”
我们既想保代码,又要保业务,当这两者产生冲突,且必须取其一时,就会痛。代码流产,业务发芽,说来侥幸。
离业务越近的代码,越痛。月月痛、周周痛、天天痛,流得稀里哗啦。从0到1的实现者们,着实是个幸运儿,闭目思索,便可忆起当年需求。嗯,这段IF-ELSE的故事我知道。
从1到N的接力选手,就不那么好命了。过尽千帆皆不是,手捧黑盒独懵逼。三下五除二,拨开乌云,三行代码,美其名曰的Feature来自于此。产品欢呼,喜悦中却难以颜开。
我们深知,下次的Feature将会付出更多代价。即使可以欺骗内心,手指还是很诚实,噼里啪啦敲打之下,除了Feature还有Hack。
令人悲伤的是,这种临时方案带来的债务,不会随着需求的满足而清零,反而会变本加厉,直至产品消亡。下一次的需求需要付出更高的代价,人力、时间、风险、效果,都在瑟瑟和我们招手。
资源限制导致技术复杂性提升,技术复杂性引发研发成本提升,这便是技术债。
技术债:指开发人员为了加速软件开发,在应该采用最佳方案时进行了妥协,改用了短期内能加速软件开发的方案,从而在未来给自己带来的额外开发负担。
——沃德·坎宁安(1992)
3 还债
没有人想背负债务,但现实情况是,我们都是债务加重的刽子手。
可以问自己两个问题:
- 如果接手一份完美的代码,能否保证其继续完美下去?
- 如果接手一份烂代码,能否保证其不会更烂?
能与不能我们无法定论,现实情况是,这很难。因为业务会拖着代码一起跑。
业务逼着你跑,你不跑不行,可能跑着就累死了;你停下来歇会儿,搞搞技术改造,又可能被业务压力压死了,反正都是死 。
——蚂蚁金服 右军
所以,结论是没有什么灵丹妙药。业务要跑,债务要还,老婆孩子都得保。
因此,一定程度的负债是正常的,保持还债是必须的。
能认识到这样点,再看还债,内心会好过一点。
- 曾经内心OS:业务给这么点时间,还要求代码质量,咋可能,应付着来吧。
- 现在内心OS:业务要支持,代码要保证,能保一点质量算一点,少挖坑,多填坑。
西去终有经,内心的坚定能与拧巴的日子抗衡多久?这样做,“小拧巴”可能会少点,但“大拧巴”仍有很多。
对于大拧巴,除了少挖坑,多填坑,更需要机遇:
- 抱紧大需求
- 暴露大问题
不要幻想有一天业务静止,给重构留有余地。机遇之下,顺势重写。
为什么要重写?因为这已经不是小拧巴了。对待大拧巴,重构会花费大量精力琢磨过去,而非思考未来。对待烂代码,不要留恋。
除了小大拧巴,还有一个超级大拧巴等着我们——架构。
设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。
——康威定律(1967)
架构的宿命早已写在康威定律里。架构是人的映射,有什么样的Team,就有什么样的架构。代码可以优化,结构可以改善,语言可以更迭,但架构不容易改变。
曾有人笑言,如果有4个软件团队开发编译器, 那么结果很可能是编译器有4个部分,或者有4步完成编译。
架构,已经不单单是一个技术问题了。
参考
- https://zh.wikipedia.org/wiki/技术负债
- https://zhuanlan.zhihu.com/p/23765415
- http://gitbook.cn/books/5878517d40d937d740e06add/index.html
- https://en.wikipedia.org/wiki/Conway's_law
- http://www.infoq.com/cn/articles/every-architect-should-study-conway-law
- http://36kr.com/p/5042735.html
- https://yq.aliyun.com/articles/8611
- http://dingdingpapa.blogspot.com/2012/10/conways-law.html