15 | 技术债务:那些不可忽视的潜在问题
该思维导图由 AI 生成,仅供参考
什么是技术债务?
- 深入了解
- 翻译
- 解释
- 总结
技术债务是软件开发中常见问题,团队为了实现短期目标选择了权宜之计,而非更好的解决方案,所要付出的代价包括团队后续维护代码的额外工作成本。技术债务的表现形式包括低质量的代码、不合理的架构、过时的技术等。为了量化技术债务,可以使用开源软件SonarQube,通过将不同类型的规则按照一套标准的算法进行识别和统计,最终汇总成一个时间,从而对代码质量有一种直观的认识。解决技术债务的方法包括共识、可见、止损和改善,遵循原则让技术债务呈良性下降趋势、优先解决高频修改的问题、在新项目中启动试点以及不等到太晚。最近智能研发的声音不绝于耳,其中关于使用人工智能和大数据技术提升代码质量的方法是目前的一个热门研究领域。
《DevOps 实战笔记》,新⼈⾸单¥59
全部留言(9)
- 最新
- 精选
- 桃子-夏勇杰老师可以分享一下,什么样的技术债还起来比较容易,收益又比较大的?或者分享一个你印象特别的技术债。
作者回复: 你好,我理解你的问题是哪些技术债修复的投入产出比最高,或者最应该优先处理对吧?这个因项目而已,我给你的建议是参考大厂比如阿里巴巴的编码规范,选择其中优先级较高的问题进行修复。另外在我们实际工作中,有以下这些问题的优先级较高,你也可以参考以下: 线程池不允许使用Executors去创建,而是通过ThreadPoolExecutor的方式 多线程并行处理定时任务时,使用ScheduledExecutorService。 在if/else/for/while/do语句中必须使用大括号,即使只有一行代码,避免使用下面的形式:if (condition) statements; 所有的包装类对象之间值的比较,全部使用equals方法比较。 在使用正则表达式时,利用好其预编译功能,可以有效加快正则匹配速度。 不要在foreach循环里进行元素的remove/add操作 避免通过一个类的对象引用访问此类的静态变量或静态方法
2019-11-149 - 陈斯佳这一周为了解决一个脚本的问题,硬是花了三四天的时间来理解同事写的这个代码,最后修改其实只要改一行代码就够了……我大好的青春啊!
作者回复: 看来这个代码的技术债已经已经达到几十小时的规模了,好人做到底多加点注释吧😂
2019-11-156 - 陈 争之前有一个项目由于时间紧张,没有抽取公共方法,每个人都按自己的逻辑写。比如一个下拉列表查询功能,三个人就会写出三种实现方式,这个不是代码重复的问题,而是完全不重复,无法复用!!! 今天学习了SonarQube,希望在以后的工作中能够把这个工具用起来,做到技术债直观可视,这样可以更方便的跟领导解释技术债的重要性。
作者回复: 是的,一定要让抽象的事物具象化话,整好我今天遇到一个公司,他们甚至将Sonarqube里面的规则定义了一套自己的算法,并结合多种代码质量类型,比如安全等,最终给出了一个可量化的得分,我个人觉得这个方法很不错,没有比较就没有伤害哈。
2019-11-144 - sugar感觉遇到的好多烂代码(小声哔哔),开发人员技术能力良莠不齐,多数都没有一个完整成熟的手册规范,一顿操作,先上线再说,哎
作者回复: 这就是典型的“先上再说”吧,这就看出来代码检查工具的必要性了,降低人与人之间的摩擦(哔哔),有一套客观的标准,谁也不能说啥。
2019-11-15 - leslie其实提及技术债就不得不去提及领导的魄力和远见以及管理能力。 领导有魄力:发现一堆技术债会定期清理,后续人员发现时上报的时候会在维持现有的情况下控制新内容的增速,为此换取陆续解决相关技术债的问题。没有大局观和魄力的:先解决当下,亡羊补牢,能补多少算多少,问题积累数目偏多,老项目就这样通过硬件优化算了,一切的防御改进新项目再说。 两种领导都碰过:一种-通过一段时间的治理后不会因为人员的流动而对现有系统产生如何影响;继任者是个高手性能提升不少,能力一般的勉强维持现状。 这是我对于企业技术债亲身的感悟吧😄
作者回复: 👍希望你能成为“前一种领导”
2019-11-14 - Robert小七最近又回看了这篇文章,然后我自己也读了一些技术债务的文章或书籍,有一个点想请教下,技术债务和坏味道的关系是怎样的?2023-02-03归属地:广东
- 张浩您好,老师,我目前主要写Ruby,比较好奇公司之前的Ruby系统,是不是当时就被重写了呢?2022-04-27
- BertGeek项目前期就应该共识规范,统一约定2021-05-25
- 苏进宇针对测试环境和生产环境上线时因环境差异造成的错误, 是否可以通过Docker做出环境差异的屏蔽呢?2020-03-261