24 | 技术债务：是继续修修补补凑合着用，还是推翻重来？

精选留言(17)

• 

  bearlu

  明白了为什么不要接到一个需求就马上写代码。没有经过设计的代码，后期维护成本极高。

  作者回复: 是这样子的，磨刀不误砍柴工

  2019-04-23

  

   6
• 

  clever_P

  对技术债务有深刻的感触，但凡对技术有深刻理解的人都会采取预防的策略。
  对于已经欠下的技术债务，如果软件生命不会很快结束，维持的策略长期来看是不可取的，债务只会越来越多，问题也会越来越多，在业务紧的情况下，不只是透支研发成本，还会透支工程师的健康。对于重构的策略，个人理解是从局部到整体的，在输出结果不变的情况下，改善内部设计，但是对于大的结构设计缺陷，有时局部重构也不太好做，整体结构会有很多限制。对于重写，要对原有系统的业务功能和业务特点有细致的理解，对业务发展有较为清晰的认识，最最重要的是能够清楚识别原有系统的设计问题，有针对性的提出解决方案来处理这些问题，不然重写就真的只是重写一遍了。

  作者回复: 预防是最好的方法，也是要求最高的。
  
  技术债务的问题确实是没有万能的解决方案，还是要先识别，然后理性客观的做一个方案，再有计划的去实施。

  2019-04-23

  

   3
• 

  Joey

  请教宝玉老师：
  
  1.如何更好地推广SonarLint白盒扫描工具。
  2.如何要求各开发团队更好地，有效地做代码走查，而不流于形式。（我们现在使用Gerrit）
  3.如何要求开发人员有效实施单元测试。
  
  我们一个研发部门人数1000左右，由于历史原因，大家根本不重视单元测试、代码走查以及白盒扫描，或者说这只是留于形式，走流程。久而久之，开发人员觉得我不关心这些东西，也没有出现很严重的事情啊，反正有测试人员对质量把最后一道关，我为什么要浪费时间呢？
  
  但是现在随着业务越来越多，系统越来越复杂，要从研发过程上加强质量，面临以上三个很突出的问题，请宝玉老师支支招，多谢老师解答！

  作者回复: 这种开发流程问题肯定还是要自上而下推才能推得动。
  
  我觉得首先应该先找一两个小项目组试点，摸索出一套适合你们的最佳实践，形成流程规范，比如说基于Github Flow，把CI（持续集成）环境搭建起来（如果没有的话），把你说的SonarLint、自动化测试加入到CI流程中。
  
  再就是逐步扩大范围，在更多项目组推行最佳实践和流程规范，并且改进流程规范。
  
  最后就必须要借助行政手段强制推行了。
  
  因为我对你的情况不是很了解，先简单回复一下，你有后续问题可以继续留言。

  2019-05-16

  

   2
• 

  果然如此

  最近遇到一些Bug 数量越来越多技术债务，而且都是同一类问题，因为数据准确性关系到月月末统计工资，所以临时解决方案是修复已知的错误数据。由于这个模块以前是其他同事做的，我在本周花了几天时间研究，得出结论是原设计没考虑到业务变化后的相关联数据如何跟着同步变化，导致了很多相关统计报表错误。
  这个债务临时解决办法只是头疼医头脚疼医脚，最终还要抽出时间根本解决数据同步变化问题。

  作者回复: 👍技术债务最重要的一步就是识别出来问题在哪，然后再有一个稳妥的方案。
  
  你这个问题，我建议你先把相应的自动化测试代码补上，然后保证有一定测试覆盖之后，再逐步用新模块替换旧模块，最终完全替换。

  2019-04-26

  

   2
• 

  纯洁的憎恶

  技术债务不全坏，与金融债务一样，需要具体问题具体分析。轻率&有意的债务要避免。谨慎&有意的债务有收益。轻率&无意的债务要警惕。谨慎&无意的债务要改变。识别债务防患于未然。根据成本收益分析，决定重写（一次性还款）、维持（只还利息）还是重构（分期付款）。

  作者回复: 突然感觉我们是金融行业从业者😄

  2019-04-23

  

   2
• 

  kirogiyi

  在研发过程中，产生技术债务的时候，稍微有点技术功底的人，或多或少都会有感觉的。比如：有重复代码的时候，会意识到好像已经写过了；函数命名的时候，会意识到好像有个相似的名称已经命名过；函数行数过多的时候，自己心里会感觉不舒服等等。更有甚者，你去整理这些问题还会被同事标上“强迫症”患者的称号，还是放弃吧。技术债务就这样在外部和内部双重压力下自然而然的产生了。
  
  那么如何产生有利的技术债务呢？我觉得应该从公司制度、研发流程、个人素质培养三方面入手。公司制度实际上是为领导层准备的，领导层以身作则去影响下面的员工，员工就没有冒犯的理由，比如：合理的奖惩制度，要做到公平合理，一视同仁；研发流程主要是让团队成员知道自己什么时候该做什么事情，如何去按照指定的约束去做好自己的事情，除此之外，还应该给予明确的成长上升空间；员工素质的培养则需要从一个人的职业素质，技能优化，团队协作方面着手，让他们拥有积极努力的心态参与到工作中去，这基本上就能解决最基础的技术债务问题（领导决策错误产生的技术债务另当别论）。
  
  在我遇到过的技术债务中，主要由领导决策、产品业务逻辑、技术最初选型、技术更新换代、团队综合素质中的一种或几种导致。对此，我只能说个人能力达到什么层次就应该去解决什么层次的技术债务，不能去推诿和落井下石，在你手中的技术债务就应该当成自己欠下的技术债务来解决，这样才能持续性的做好自己分内和分外的事情，工作起来才能得心应手。

  作者回复: “在你手中的技术债务就应该当成自己欠下的技术债务来解决，这样才能持续性的做好自己分内和分外的事情，工作起来才能得心应手。”👍👍
  
  说的真好，偿还技术债务，从自己做起！

  2019-04-23

  

   2
• 

  WL

  老师能不能具体讲讲重构有哪些原则和要注意的地方，感觉一直得不到要领

  作者回复: 重构的要领我觉得两点：
  第一：你要先写一部分自动化测试代码，保证重构后这些测试代码能帮助你检测出来问题
  第二：在重构模块的时候，老的代码先保留，写新的代码，然后指向新代码，或者用特定开关控制新旧代码的指向（这样上线后可以自己先测试，有问题也可以及时关闭），然后让自动化测试通过，再部署测试，新代码没问题了，删除旧代码

  2019-04-23

  

   2
• 

  小老鼠

  1、技术债务是不是仅是产品质量低。2、重构：如何作好新老系统接口的一致性。

  作者回复: 1. 技术债务通常是指技术层面的，比如说代码质量底下，缺少良好的架构设计，缺少自动化测试覆盖等等，最终技术债务导致的结果就是产品质量低，难以响应需求的变化等
  
  2. 重构和接口设计是两个不同概念，重构是对代码或系统结构进行调整优化，接口设计是架构设计的一部分。
  
  大的系统重构也需要先进行架构的设计，其中包括接口的设计，在设计的时候就要决定新的接口是否兼容老的接口，设计完成后，在重构时，就应该遵循设计时定义的接口设计。

  2019-09-20

  

   1
• 

  Mr.Chen

  看了几次项目管理金三角后，发现有意思的是，这个图里，时间和成本的缩减，都会引起三角形面积减少，也就是质量变差，范围缩减也会引起三角形面积减少，但它应该是提升质量吧。😄

  作者回复: 这个三角形，更多的是反应各个因素的影响关系，不完全对应几何上的反应 😛

  2019-07-25

  

   1
• 

  hua168

  十年前的系统perl写的，很重要的，没办法维护，经常他会出问题，效率低下。
  如果用Go重写的话，之前的perl开发走完了，
  那如果重写，是按照业务逻辑来重写吗？
  
  就问那些经常操作人了解有哪些功能，结合他们的讲解，把业务功能列出来？然后用Go来重写对吧？

  作者回复: 是的，就是一个普通的软件项目，有需求说明，然后立项开发。

  2019-04-29

  

   1
• 

  hua168

  像我们公司有老系统，十年了，程序员都换完了，用perl写的，基本上都没有几个人懂perl
  无法重写、也无法重构怎搞？

  作者回复: 需要综合评估一下，如果很稳定也不重要，那就别动了，补一点文档。
  如果很重要又不稳定，建议对其立项，用开源产品或者商业产品或者新技术实现同样的需求，然后换掉。

  2019-04-28

  

   1
• 

  Charles

  我们的技术债务：单元测试覆盖率几乎为0
  主要两个方面原因，一个是一直创业公司待着，不知道单元测试好的实践到底是怎么样的，PHP的单元测试到底应该怎么做。另外一个就是项目排计划的时候总是不允许排单元测试实践，否则感觉整个项目周期太长
  所以就这么一直恶性循环下去，怕重构怕改需求导致系统不稳定，测试全靠人（测试工程师）
  
  最近每次一有空下意识就会补几个单元测试，希望能坚持下去，回头也得多找点这方面的书补一补

  作者回复: 单元测试、自动化测试在第27篇会再讲，希望到时候能解答你的一些困惑，当然也建议你看一些书，毕竟一些语言相关的还是得自己去学习研究。

  2019-04-23

  

   1
• 

  刘晓林

  偿还技术债务，最重要的还是要明白自己在哪个地方欠了债，深究问题的根源，然后才去寻找应对措施。比如你是因为流程不规范，没有必要的代码审查，那就应该规范流程，否则重写了之后，依旧是一堆乱代码。是因为测试没有做充足，那就应该把测试补上。是语言或者框架过时了，那么就要考虑更换语言框架了。但无论如何，最好还是分模块、有计划地把重构纳入到迭代中去逐步完成。防止步子迈太大，总是容易出问题

  作者回复: 是的，需要先识别，然后做方案，再做计划。线上项目不能太激进，不然代价很大的。

  2019-04-23

  

   1
• 

  空知

  基本隔个3年左右 全部推倒重建...债太多 还补上了

  作者回复: 这未必是最好的方式，可以尝试预防为主，日常及时小范围重构，应该效果更好

  2019-04-23

  

   1
• 

  Linuxer

  我们应该是这种谨慎 / 有意的债务，应该是通过重构来偿还

  作者回复: 👍先识别，然后定方案，最后再行动

  2019-04-23

  

   1
• 

  纯洁的憎恶

  投资的比喻很传神👍

  2019-04-23

  

   1
• 

  williamqian

  写代码只是最后一步，前期的思考设计很重要。

  作者回复: 👍谢谢总结分享

  2019-05-27

  

  