研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

14 | 质量与速度的均衡:让“唯快不破”快得更持久

葛俊 2019-09-23
你好,我是葛俊。今天,我来和你聊聊团队可持续性的快速开发,怎样才能让“唯快不破”快得更持久。
最近几年,一提到开发,很多人想到的都是“天下武功,唯快不破”。也就是说,开发过程越快越好,越快越有竞争力。这的确是软件开发,尤其是互联网行业软件开发的不二法则。也正如我在前面文章中多次提到的,快速开发可以快速得到用户反馈,更快地验证用户价值假设。无疑,这是高效开发的重要原则。
因此,我们在实际工作中,往往会为了快而选择各种“捷径”。比如:
要开发已有功能的一个相似功能,因为时间很紧就先 copy & paste,保证功能按时上线。
需要在一个函数里增加功能,这个函数已经有 800 行了,加上新功能后会有 1000 行。重构这个函数是来不及了,先把功能加上去再说。
说是“捷径”,是因为这些都不是最优解,有点儿投机取巧。它们的确能让我们在短期内保证快速交付,满足业务发展需求。但如果没有任何补救措施的话,时间长了我们就再也快不起来了。
比如,“copy & paste”方式的编程,会导致后续添加功能时,需要在很多地方做类似修改,工作量大且容易出错。再比如,无视函数变大的操作,会导致后续的修改、调试异常困难。
这些问题都会成为开发工作中的技术债,也就是在开发产品或者功能的过程中,没有使用最佳的实现方法而引入的技术问题。无疑,这些技术问题会为将来的产品维护和开发带来额外开销。只有正确地处理技术债,才能让我们的研发持续地快下去。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 日拱一卒
    破产保护(bankruptcy protection): 破产保护是指不管债务人是否有偿付能力,当债务人自愿向法院提出或债权人强制向法院提出破产重组申请后,债务人要提出一个破产重组方案,就债务偿还的期限、方式以及可能减损某些债权人和股东的利益作出安排。这个方案要给予其一定的时间提出,然后经过债权人通过,经过法院确认,债务人可以继续营业。这就是重整的概念,在中文中又叫破产保护。


    对于技术债务来说,当积累到一定程度并严重阻碍正常开发的时候,必须要采取和破产保护类似的策略,梳理所有技术债务并做合理的计划,按照优先级去偿还这些债务。

    记住一句话,出来混,总是要还的。

    作者回复: 写的很棒!!

    不过似乎大家都忘了到还有一个借了债不用换的极端情况,比如一个实验项目,或者一个马上要被替换的项目。借再多的技术债也没关系。

    2019-09-23
    5
  • 李双
    敢于留债,并定期偿还技术债!

    作者回复: 简明扼要!

    2019-09-23
    1
  • Jxin
    1.试点项目,不怕债务,失败直接不用还。前提条件,有强力的中台背景支撑低成本试点。
    2.个人补充一点。债务不是理由。一个项目,要抢站市场,需要快速落地。产生债务是必然,但产生100w的债务和产生1000w的债务是两码事。合理的架构设计和分层,基本的代码规范还是要保证的,做这些并不会拖慢业务落地。但多少人,一句为快速落地牺牲质量,就肆无忌待的瞎搞,最后项目缓慢,失败都归于债高。成功又以债高为由要成本重写。
    3.互联网公司发展太快,高层水准层次不齐。

    作者回复: > 1.试点项目,不怕债务,失败直接不用还。
    是的

    > 2.个人补充一点...合理的架构设计和分层,基本的代码规范还是要保证的...瞎搞...
    补充的很好!!

    2019-10-04
  • 兴国
    偿还技术债同时也对研发人员提出了要求,要不断的学习新知识,不断优化代码,不断结合自身业务优化架构。所以平常不仅要低头拉车,还要经常抬头看路。

    作者回复: 是的。如果有环境,我觉得大部分开发人员应该还是愿意学习和提高的。

    2019-09-27
  • 麦兜
    技术债务的累积也是产品生命周期的末期,一个新产品的开端

    作者回复: 如果产品不维护了,的确是这样的。

    2019-09-26
  • 寒光
    质量和速度,两手抓,两手都要硬。只要速度不要质量走不远,只要质量不要速度走不动。

    我认为技术债也有申请破产保护的福利,因为业务如果发展起来了,就有钱去做重构,把之前的推到重来。而如果因为怕欠技术债,速度没跟上,错过了业务的发展,再好的质量也是白搭。

    作者回复: 👍👍👍

    2019-09-23
收起评论
6
返回
顶部