2019-11-14老师可以分享一下，什么样的技术债还起来比较容易，收益又比较大的？或者分享一个你印象特别的技术债。作者回复: 你好，我理解你的问题是哪些技术债修复的投入产出比最高，或者最应该优先处理对吧？这个因项目而已，我给你的建议是参考大厂比如阿里巴巴的编码规范，选择其中优先级较高的问题进行修复。另外在我们实际工作中，有以下这些问题的优先级较高，你也可以参考以下：
线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式
多线程并行处理定时任务时，使用ScheduledExecutorService。
在if/else/for/while/do语句中必须使用大括号，即使只有一行代码，避免使用下面的形式：if (condition) statements;
所有的包装类对象之间值的比较，全部使用equals方法比较。
在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。
不要在foreach循环里进行元素的remove/add操作
避免通过一个类的对象引用访问此类的静态变量或静态方法 2
2019-11-14之前有一个项目由于时间紧张，没有抽取公共方法，每个人都按自己的逻辑写。比如一个下拉列表查询功能，三个人就会写出三种实现方式，这个不是代码重复的问题，而是完全不重复，无法复用！！！
今天学习了SonarQube，希望在以后的工作中能够把这个工具用起来，做到技术债直观可视，这样可以更方便的跟领导解释技术债的重要性。作者回复: 是的，一定要让抽象的事物具象化话，整好我今天遇到一个公司，他们甚至将Sonarqube里面的规则定义了一套自己的算法，并结合多种代码质量类型，比如安全等，最终给出了一个可量化的得分，我个人觉得这个方法很不错，没有比较就没有伤害哈。
2
2019-11-15这一周为了解决一个脚本的问题，硬是花了三四天的时间来理解同事写的这个代码，最后修改其实只要改一行代码就够了……我大好的青春啊！作者回复: 看来这个代码的技术债已经已经达到几十小时的规模了，好人做到底多加点注释吧😂
1
2019-11-15感觉遇到的好多烂代码（小声哔哔），开发人员技术能力良莠不齐，多数都没有一个完整成熟的手册规范，一顿操作，先上线再说，哎作者回复: 这就是典型的“先上再说”吧，这就看出来代码检查工具的必要性了，降低人与人之间的摩擦（哔哔），有一套客观的标准，谁也不能说啥。
2019-11-14其实提及技术债就不得不去提及领导的魄力和远见以及管理能力。
领导有魄力：发现一堆技术债会定期清理，后续人员发现时上报的时候会在维持现有的情况下控制新内容的增速，为此换取陆续解决相关技术债的问题。没有大局观和魄力的：先解决当下，亡羊补牢，能补多少算多少，问题积累数目偏多，老项目就这样通过硬件优化算了，一切的防御改进新项目再说。
两种领导都碰过：一种-通过一段时间的治理后不会因为人员的流动而对现有系统产生如何影响；继任者是个高手性能提升不少，能力一般的勉强维持现状。
这是我对于企业技术债亲身的感悟吧😄作者回复: 👍希望你能成为“前一种领导”