程序员进阶攻略
胡峰
京东成都研究院技术专家
立即订阅
7524 人已学习
课程目录
已完结 65 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序行知:走在同样的路上,遇见自己的风景
免费
征途:启程之初 (4讲)
01 | 初心:为什么成为一名程序员?
02 | 初惑:技术方向的选择
03 | 初程:带上一份技能地图
04 | 初感:别了校园,入了江湖
修炼:程序之术 (10讲)
05 | 架构与实现:它们的连接与分界?
06 | 模式与框架:它们的关系与误区?
07 | 多维与视图:系统设计的思考维度与展现视图
08 | 代码与分类:工业级编程的代码分类与特征
09 | 粗放与精益:编程的两种思路与方式
10 | 炫技与克制:代码的两种味道与态度
11 | 三阶段进化:调试,编写与运行代码
12 | Bug的空间属性:环境依赖与过敏反应
13 | Bug的时间属性:周期特点与非规律性
14 | Bug的反复出现:重蹈覆辙与吸取教训
修行:由术入道 (24讲)
15 | 根源:计划的愿景——仰望星空
16 | 方式:计划的方法——脚踏实地
17 | 检视:计划的可行——时间与承诺
18 | 评估:计划的收获——成本与收益
19 | 障碍:从计划到坚持,再到坚持不下去的时候
20 | 执行:从坚持到持续,再到形成自己的节奏
21 | 信息:过载与有效
22 | 领域:知识与体系
23 | 转化:能力与输出
24 | 并行:工作与学习
25 | 时间:塑造基石习惯(上)——感知与测量
26 | 时间:塑造基石习惯(下)——切割与构建
27 | 试试:一种“坏”习惯
28 | 提问:从技术到人生的习惯
29 | 偏好:个人习惯的局限与反思
30 | 写作:写字如编码
31 | 画图:一图胜千言
32 | 演讲:表达的技术
33 | 定义:阶梯与级别
34 | 晋升:评定与博弈
35 | 关系:学徒与导师
36 | 核心:安全与效率——工程技术的两个核心维度
37 | 过程:规模与协作——规模化的过程方法
38 | 思维:科学与系统——两类问题的两种思维解法
徘徊:道中彷徨 (15讲)
39 | 职业倦怠:如何面对?
40 | 局部最优:如何逃离?
41 | 沟通之痛:如何改变?
42 | 技术停滞:如何更新?
43 | 无法实现:困扰与反思
44 | 完成作品:理想与现实
45 | 代码评审:寄望与哀伤
46 | 人到中年:失业与恐惧
47 | 该不该去创业公司?
48 | 该不该接外包?
49 | 技术干货那么多,如何选?
50 | 技术分歧,如何决策?
51 | 技术债务,有意或无意的选择?
52 | 选择从众,还是唯一?
53 | 选择工作,还是生活?
寻路:路在何方 (7讲)
54 | 侠客行:一技压身,天下行走
55 | 江湖路:刀剑相接,战场升级
56 | 御剑流:一击必杀,万剑归心
57 | 三维度:专业、展现与连接
58 | 三人行:前辈、平辈与后辈
59 | 三角色:程序员、技术主管与架构师
60 | 三视角:定位、自省与多维
蜕变:破茧成蝶 (3讲)
61 | 工作之余,专业之外
62 | 跨越断层,突破边界
63 | 成长蓝图,进化跃迁
结束语 (1讲)
尾声 | 始于知,终于行
程序员进阶攻略
登录|注册

51 | 技术债务,有意或无意的选择?

胡峰 2018-11-28
在编程的路上,我们总会碰到历史系统,接手遗留代码,然后就会忍不住抱怨,那我们是在抱怨什么呢?是债务,技术债务。以前说过,代码既是资产也是债务,而历史系统的遗留代码往往是大量技术债务的爆发地。
然而,技术债务到底是如何产生的?它是我们有意还是无意的选择?这里就先从技术债务的认知开始谈起吧。

认知

技术债务,最早源自沃德·坎宁安(Ward Cunningham) 1992 年在一次报告上创造的源自金融债务的比喻,它指的是在程序设计与开发过程中,有意或无意做出的错误或不理想的技术决策,由此带来的后果,逐步累积,就像债务一样
当作为程序员的我们采用了一个非最优或不理想的技术方案时,就已经引入了技术债务。而这个决定,可能是有意的,也可能是无意的。有意产生的债务,一般是根据实际项目情况,如资源与期限,做出的妥协。
而无意产生的债务,要么是因为程序员经验的缺乏引入的,要么是程序员所处的环境并没有鼓励其去关注技术债务,只是不断地生产完成需求的代码。但只要程序员在不断地生产代码,那他们就是在同时创造资产与债务。债务如果持续上升,软件在技术上的风险就不断增加,最后慢慢走向技术破产。
以前看过另一位程序员写的一篇文章,名字就叫《老码农看到的技术债务》,印象还是比较深刻的。文中把技术债务分成了好几类,我记得的大概有如下:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《程序员进阶攻略》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • godtrue
    现在项目组正在重构我们的核心项目,系统使用每天,不过业务运营比较费劲,特别是特殊时期时,重复操作重复验证工作比较多,我们重构后,希望能够减轻一些运营成本。

    作者回复: 大规模重构一定要提前评估计划,期间的实施成本压力也很大的

    2018-11-28
    2
  • 丁丁历险记
    替前人还债中,当那天不能带来我成长时,我会离开

    作者回复: 技术债务无处不在^_^

    2019-10-13
    1
  • 楼上的风景
    观后感:
    所谓债务,归根结底是成本和收益的权衡。当初产生负债时,短期收益明显高于成本,故使用之。从长期来看,成本又大于收益,故需要及时偿还之。同时,负债除了本金外,还有利息,当利息越滚越大,甚至盈利无法覆盖时,系统就岌岌可危了。跟经济活动类似,当盈利连利息都无法覆盖时,就会爆发债务危机,进而经济危机。
    2019-10-03
    1
  • Allen_Go
    遇到产品快速迭代的时候,产品的需求在代码的实现来看就像是打补丁的实现,局部的快速迭代往往会会忽略整体性,当产品流程过长,后来的补丁对于前面的实现大都都像是债务的累积,或如果后面加进来的补丁没有考虑前面的实现,某一天债主就会找上门来了。这种算技术债务吗?

    作者回复: 所以程序员要往前走一点,考虑产品的生命周期,才能少负债,负债也不一定是坏事,特定时间和环境有需要

    2019-07-19
    1
  • 黄蓓
    为了加载数据更快,前人在provider进程当中实现了一个内存数据库,随着业务的增长,内存数据库越来越复杂,还出现了数据丢失和不一致的情况,这个债务已经还不起了
    2018-11-28
    1
  • JohnT3e
    知道引入了哪些债务,多少债务,何时偿还是关键,更多情况下往往是债务危机爆发时才发觉。
    2018-11-28
    1
  • 汪玉斌
    常常因为工期和变更的原因引入债务。
    如果决策的人能明白这些债务的存在和代价,那真的要谢天谢地了^_^

    遇到的客户,那些不太懂软件的,反而觉得软件改起来简单,举起例子来一套一套的。。。

    作者回复: 😄

    2019-04-04
收起评论
7
返回
顶部