从技术债说起

黑妹妹牙膏  |  2017. 03. 19   |  阅读 579 次

作为一名超过10年的技术老兵, 做过无数系统, 也接手过无数系统. 感觉大部分时间都在重构, 不停的合并拆分, 叠加新业务. 老实说, 我不太喜欢技术债这个词, 不知道是谁发明的?

熟悉的场景

我来说说我对技术债的理解, 一般抛出这个词大部分有这些场景:

  • 系统出故障了, 作为开发很委屈, 表明我都不知道这里还有这么一段逻辑,居然还有这么一个坑. 背后的潜台词是我不知道(不知者无罪), 是前人留下的坑(把自己摘干净, 如果是我一定不会写这么蠢的代码)

  • 业务方提出新需求或者技术方要求系统改造, 这个系统历史遗留问题过多. 改动起来非常困难. 背后的潜台词是, 你们的需求哪有像你们说得那么容易, 你要给我多一点时间.

  • 在汇报的时候, 多少有点拯救者的高姿态. 因为债这个词是个贬义词. 很多时候的感情色彩是否定之前的. 所以我更喜欢用重构这样中性的词表达.

如果去跟大部分开发聊聊, 什么是技术债什么是不良代码, 大部分人都能侃侃而谈, 讲一堆债分良性债, 不良债巴拉巴拉.

在我看来文字游戏而已, 技术债也好, 不良代码也好, 甚至每个人都有自己的风格和技术偏好不认可也好, 都是之前遗留下来的问题或者说现在留下的隐患.

跟我接触多的人, 会知道我的几个价值观

  • 出了问题, 第一反应应该是解决问题, 而不是追究责任.

  • 讨论需求, 或者优化重构的时候, 我更关心怎么完成需求或者优化.

技术债到底从哪里来的?

如果像每个人说的汇报的那样, 各个都是精明能干, 只填坑不挖坑, 那么我们那么多的重构, 优化到底从哪里来的?

世界上唯一不变的就是变化本身, 无论是初创公司, 还是大公司, 一直都是雄心壮志要拓展自己的业务边界. 从业务的角度来说, 小步快跑, 快速试错.

业务的发展

互联网公司本身迭代速度就快, 往往留给测试的时间都不会很多. 大公司有预算, 初创公司更是资金有限, 很少会有不计成本的去做一个项目的时候. 那么在时间, 成本都受到约束的时候, 唯一能做的就是牺牲质量.

即使有时间和能力让你把系统设计得天衣无缝, 完美的毫无瑕疵, 那又如何?

  • 三个月以后, 业务部门说, 其中某一模块市场反应不好, 公司不再投入资源, 我们只要维持现状, 不做更多安排. 运营, 开发, 产品人员换了一拨又一拨. 谁都不愿意过多过问.

  • 业务发展形式一片大好, 我们要拓宽边界, 竞争对手正在追赶我们, 我们更要加快步伐. 扩大领先优势.

  • 该业务很好, 要与现有业务打通. 部分共用模块要沉淀

  • 业务线调整, 不断拆分合并

怎样? 业务永远在变化, 甚至会往你想象不到的方向发展. 一个好的架构师往往会预留好空间, 甚至提前设计好扩展点. 模块间松耦合. 的确这是一名优秀架构人员该有的能力.

但是往往在当时做设计的时候, 也不会过分的过渡设计. 一方面当前时间上不允许, 另一方面, 未来的变化未知. 过度设计也是一种浪费.

通常情况几个月下来原先的系统已经是千疮百孔, 补丁加补丁.

这就是最典型的技术债的来源, 由于业务的发展.

技术的变化

技术进步的速度非常快, 尤其是前端, 移动端的发展. 新名词层出不穷.

参考前面的业务发展规律, 必将有些系统茁壮成长, 有些业务只是维护原样. 有些会无人问津. 这是无法避免的.

  • 从Oracle换到Mysql

  • 从Php换到Java

  • 统一开发框架或者技术栈

哪一个不是惊心动魄, 翻天覆地的改变. 从老板的角度来看, 业务不能停, 需求不会断. 这就是我们常说的在高空飞行的飞机上换零件. 有人维护的系统自然能顺利完成, 那些维持现状的系统和无人问津的系统, 落后是自然的.

初创公司中, 必定有一些技术上很有追求的人, 架构师往往也是主程, 控制力不是那么强. 不能说谁对谁错, 也不适合打击这些人的热情. 所以百花齐放的局面很容易产生. 至于大公司, 神仙打架的情况也很正常.

怎么办? 架构师会告诉你要兼容老系统, 兼容其他技术栈, 业务部门会说, 老系统不能停. 这时参差不齐, 千疮百孔again.

人员变化

铁打的营盘流水的兵, 技术也好, 产品也好, 运营也好甚至高层. 人员是一直在流动的.

项目(业务)在交接的时候会有信息的丢失. 文档基本留下不会太多. 由于能力, 理解, 关键人员的偏好导致的整体偏差必定会发生.

性格和能力强的人会一把推翻, 重新构建, 一般几个月以后就面目全非了. 与之对接的系统被迫也要跟着变化.

别忘了, 对接系统的改造能力是不同的, 妥协的结果就是兼容, 整体的差距就是这么拉开的. 又是千疮百孔.

如何看待

所以一般两三年下来, 这些问题的积累, 不是靠个人能力能避免的. 以上逻辑一旦运作起来, 即使是老板, CTO这样的司机也只能控制在一定范围之内.

招聘, 不断的要招聘. 大家都很忙碌的样子, 但是产出好像越来越困难. 这就是我们所说的, 软件开发的最大成本就是维护的成本.

很多人离职其实是因为陷入在这个维护, 开发这个怪圈中. 一直到无法忍受, 觉得继续下去收获也不大. 对个人能力的提升帮助不大. 离职换一个环境, 摆脱了暂时的困境. 岂不知, 状态一直在, 只不过暂时缓解了而已. 这也是大部分人平均两三年就换一份工作的原因. 当然也有薪资的原因.

我眼中的高级

工作不可能一直换, 当级别到达一定程度的时候, 要想突破就会越来越难. 越早能看破其中的关键, 调整自己的状态才是正解.

功法

其实技术本身我称之为功法, 其实并不难, 技术的发明者最终的目的都是想传播, 让别人学会去用. 所以只要肯花时间, 肯定是能学得会的. 会某样技术, 会搭一个什么框架本身固然重要, 但更重要的是学习能力, 这才是核心.

经验

见得多了, 自然对变化的判断就更准了. 经验要积累, 靠经历, 靠交流, 靠总结, 靠分享. 我们大部分遇到的问题, 都是别人解决过的, 甚至是其他行业解决过的. 多参考他们的方案, 找到自己的方案.

心法

就跟武侠小说里写得一样, 绝世高手都是心法了得. 对于我们来说, 就好像如何看到技术债的问题一样. 几点心得:

  • 耐得住寂寞, 其实一件事坚持做一个月改变就会很明显

  • 忙里偷闲做一点点挑战, 别一直忙活在舒适区

  • 保持热情和坚定的目标, 没有什么能够阻挡

这些特质都是与外界环境无关的. 去到哪家公司都一样. 但这也是去到哪里都优秀的根本

联系我

分享到

   
我理解中的“大前端”/“大无线”