这是一个创建于 650 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位分享哪些实践可以提高团队简洁代码的质量避免技术债
第 1 条附言 · 2023-02-16 14:25:36 +08:00
 |
1
corcre 2023-02-15 10:31:07 +08:00
难道不是要求写注释和熟练使用 blame 命令...
|
 |
2
estk 2023-02-15 10:35:13 +08:00
也取决于产品定位是否清晰，否则中途也会一直改代码结构
|
 |
3
Chad0000 2023-02-15 10:37:43 +08:00  4
代码可以不简洁，但方案一定要简洁，也就是流程要简洁。
|
 |
4
wanziforever 2023-02-15 10:37:49 +08:00
简洁这个词不准确，应该是易懂。代码只是简洁了，可能功能就不完整了，或者特殊场景覆盖率不高。
而易懂这个说法，更能说明的是，首先代码在设计思路上面做到流畅，比如数据结构设计很好，导致代码算法部分可以简单易懂。应该追求的是易懂的设计，而不是代码本身。当然代码也很重要。 |
 |
5
kop1989smurf 2023-02-15 10:37:51 +08:00
技术债和代码是否“简洁”是完全两回事。
技术债务，指的是因为基于现有条件原因（顾及更稳定的开发进程、更高的开发成功率等），在最优设计、最优技术选型方案上面进行了妥协，导致设计过于趋近短期利益，而放弃长期利益（包括但不限于可维护性，可扩展性，工作量等等）的情况。 |
 |
6
8355 2023-02-15 10:38:29 +08:00
技术债务本质是代码不够健壮或者说在数据和业务量增长后架构和代码没有持续迭代升级优化
后期需要花费更多的时间和精力处理一个本质上应该在前期规避的问题 最简单的比如并发锁 低访问量几乎不会遇到 不处理也没问题 |
 |
7
Skifary 2023-02-15 10:40:45 +08:00 1
技术债最大的问题不是代码是否简洁，是市场和需求一直在变，之前设计的架构满足不了
|
 |
8
janus77 2023-02-15 10:53:49 +08:00
架构可以降低技术债
|
 |
9
wu67 2023-02-15 10:56:30 +08:00
写好注释, 代码少点嵌套, 不要过度拆分代码文件, 能省非常多的时间.
|
 |
10
mrgeneral 2023-02-15 10:57:48 +08:00
简洁代码是手段，减少技术债务是目标，得具体分析痛点是什么，不然可能事倍功半。
也有不少代码简洁优雅，但是维护起来才发现是给屎穿上了漂亮的衣服，这种得从技术架构上着手。 |
 |
11
nicebird 2023-02-15 12:16:35 +08:00
太泛的问题没有意义
|
 |
12
wanguorui123 2023-02-15 12:27:41 +08:00
严格的分层和抽象才能降低技术债，而不是简洁代码
|
 |
13
debuggerx 2023-02-15 12:36:56 +08:00
简洁代码看的是团队每个人的素养
低技术债看的是技术团队强不强势 |
 |
14
charlie21 2023-02-15 12:38:38 +08:00 via Android
如果想问一些有深度的问题，可以问一问如何在降低技术负债的情况下增加一个人的不可替代性
毕竟技术负债的降低（会让从业者轻松涌入、上手）会让你的可替代性大大增加 |
 |
15
jim9606 2023-02-15 12:58:21 +08:00 via Android 1
一般来说，不能。
如果业务复杂，简洁的代码可能意味着功能不全，或者不鲁棒。一个没有任何错误处理的程序可以很简洁，但没人敢用。 一个功能可以有高度抽象的简洁实现，但需求变更可能会破坏你的抽象，那还不如一开始就用繁琐的实现，还好改，又不用重构。 为了性能，有些简洁的途径可能不能用，例如可以动态绑定的改成静态绑定，或者生成代码。 |
 |
16
mingoing428 2023-02-15 13:17:19 +08:00 via Android
两个观点：
1. 没人可以完美地预测需求 2. 好代码是易修改的 |
 |
17
jones2000 2023-02-15 13:23:02 +08:00
人员稳定才是最重要的，换一个人，接手上一个人的代码，再简洁代码， 整个项目的代码能看明白 80%就不错了，你换 3-4 波人以后，基本就没人敢改了。
|
 |
18
liuidetmks 2023-02-15 18:27:42 +08:00
不能，业务整天想一出是一出，你疲于奔命
|
Select Language