需要长期维护的项目，投资单元测试是值得的，另外借助AI写单元测试效率可以大幅提升，有利于单元测试的普及//@Le_Ethan:看具体项目规模和复杂度. 单元测试不是一个银子弹. 但当业务发展到一定规模，投资单元测试是值得的.//@HideZ0911:单元测试就是个神话。 我知道肯定会拿 Google 等国际大厂的项目来举例，但视野小一点，就腾讯 oppo 等等，凡是搞单元测试都搞不下去。培训单测，写单测，维护单测的成本，比写代码高得多。（微博字数不够了，不能展开讲） 当然，我只搞过应用层，也就是所谓的大前端，不能代表所有领域。
问：对于小型团队而言，当代码量逐渐变大（大至一万行左右）时，有什么更好的控制代码质量的方法吗？
#软工好问题#
小才好精
无论是小团队还是大团队，要保证质量，最好的方式就是要让你的代码少、项目小，只有足够小，你才好让代码质量“精”。
那么怎么让代码少而精呢？
软件工程中一个重要的策略就是“分而治之”。
代码量大了，就要借助架构设计进行分拆，一个模块分成多个模块；当模块足够多了，就要考虑将一些模板拆到单独的库；当库也足够多了，就要考虑把一个服务拆分成多个服务。
软件工程中另一个重要的策略就是“重用”
你的代码到1万行了，这其中有多少“重复”的代码？是不是可以通过抽象来让很多代码“复用”起来？
你的这些代码里面，有多少代码是别人已经实现了，你只需要在项目中引用第三方库/包/服务就可以实现，而不需要自己实现的？
当你借助一些软件工程的策略和架构设计的手段，让你的代码重新回到代码少的状态，就好控制你的代码质量了！
#软件工程之美#
#软工好问题#
小才好精
无论是小团队还是大团队，要保证质量，最好的方式就是要让你的代码少、项目小，只有足够小，你才好让代码质量“精”。
那么怎么让代码少而精呢？
软件工程中一个重要的策略就是“分而治之”。
代码量大了，就要借助架构设计进行分拆，一个模块分成多个模块；当模块足够多了，就要考虑将一些模板拆到单独的库；当库也足够多了，就要考虑把一个服务拆分成多个服务。
软件工程中另一个重要的策略就是“重用”
你的代码到1万行了，这其中有多少“重复”的代码？是不是可以通过抽象来让很多代码“复用”起来？
你的这些代码里面，有多少代码是别人已经实现了，你只需要在项目中引用第三方库/包/服务就可以实现，而不需要自己实现的？
当你借助一些软件工程的策略和架构设计的手段，让你的代码重新回到代码少的状态，就好控制你的代码质量了！
#软件工程之美#
