你觉得同样需求实现,代码量少厉害还是代码量多厉害?

代码

KPI

厉害

考核

94 replies • 2023-07-29 12:27:34 +08:00

qsnow6

Jul 28, 2023

82

1

在团队中，在实现需求的前提下，清晰易懂最厉害。

laoluo1991

Jul 28, 2023

2

楼上正解

brader

Jul 28, 2023

1

3

没有看到具体代码之前无法评判，同样需求实现，我估计代码量差不了很多行数的，如果差出行数，那行数多的代码很可能做了更多的异常处理、数据校验。所以代码这种东西，一定要分个高下，还是拿出来比一比才知道

chengran630

Jul 28, 2023

4

能让别人（同级）看懂能运行就是好代码

crazyTanuki

OP

Jul 28, 2023

5

@qsnow6 但是也有一个可能,新来的实习生轻轻松松上手,显得你很菜...老板觉得实习生可以替代你,但代码绕,过度封装,层层跳转,实习生连试用期都过不了

iyiluo

Jul 28, 2023

6

可读性

DigitalG

Jul 28, 2023

7

赞同 1 楼，但 lz 显然说的是别的“厉害”，并不是在讨论技术。

sankooc

Jul 28, 2023

8

代码量考核 kpi... 冗余度计算在内么

ljsh093

Jul 28, 2023

9

@brader #3 我也觉得，给以后的需求多留点余地更好

crazyTanuki

OP

Jul 28, 2023

10

@brader 异常处理,数据校验属于需求内了,不可能一个做处理一个不做处理这样对比代码量

crazyTanuki

OP

Jul 28, 2023

11

@lcy630409 会不会没有护城河

crazyTanuki

OP

Jul 28, 2023

12

@DigitalG 综合性吧,纯技术或者纯人情世故都太片面了

crazyTanuki

OP

Jul 28, 2023

13

@sankooc 不计算,CV 的不算

maocat

Jul 28, 2023

14

没有注释我还能看的懂的代码最厉害

crazyTanuki

OP

Jul 28, 2023

15

@maocat 其实这个规范命名就很容易看懂了,基本上都不需要注释

tcpdump

Jul 28, 2023

16

可维护、可扩展

crazyTanuki

OP

Jul 28, 2023

17

@tcpdump 基本上面向对象或者函数式就能做到吧

brader

Jul 28, 2023

18

@crazyTanuki 那也会有差异化啊，就比如校验几个参数是否为空，有些后端喜欢用一个 if 或关系来判断，直接报参数错误，有些后端喜欢一个一个判断，告诉你哪个参数必须的。这两种做法都能实现需求，区别只在于对你的前端对接人报错是否友好，但是文档齐全的情况下，其实也没问题

volatileSpark

Jul 28, 2023

19

清晰易懂最厉害

akring

Jul 28, 2023

4

20

写出为难同行的代码并不能够成为你的护城河，因为大概率决定你去留的人，和接管你代码的人不是同一个。

最近的大型社会实验现场可以参见 Twitter 。

GeruzoniAnsasu

Jul 28, 2023

21

用时短的厉害

likang8210

Jul 28, 2023

22

同事有行代码是这样的：Map<String, Map<Boolean, List<Map<String, Object>>>> categoryDatas = endData.stream() .... 这[categoryDatas] 变量是不是叼炸天，就两行，没注释

Leviathann

Jul 28, 2023

23

code is all about expressiveness

witcat

Jul 28, 2023

1

24

在真正高手如云的团队里，故意写的抽象，是会受排挤的...

HB9527

Jul 28, 2023

1

25

和代码量多少没有关系，是别人能不能快速看懂有关，架构清晰、结构清晰最好，毕竟代码是给人看的，编译之后是给机器运行的。

bugmaker1024

Jul 28, 2023

26

抽象的代码还是不要写，因为过段时间你自己再看的时候你自己都可能不知道当时不知道为什么这样写。清晰易懂最重要

shyangs

Jul 28, 2023

27

大神在代碼塞魔術數字，不寫註釋，一樣有人吹，比如 John D. Carmack 的魔法數字 0x5f3759df

高手如雲的 Linux 內核也一堆奇技淫巧.

roundgis

Jul 28, 2023 via Android

28

收錢多的厲害

ox18

Jul 28, 2023

29

不能一概而论吧

pkoukk

Jul 28, 2023

30

我觉得都不是，清晰易懂也就一般般
厉害的是架构里有足够的灵活度适应瞎 JB 改的需求
当产品很不好意思地说这个需求估计要七八天吧，我只需要两三天的时候，别提有 TM 多爽了

silencil

Jul 28, 2023

31

一个方法只做一件事的就是好代码，在我这是个很简单的判断标准。代码写的再好，又臭又长真的是看的头大，不好抓主要的点。

tkHello

Jul 28, 2023

32

无所谓他司统计代码量

wangedenr

Jul 28, 2023

33

app 容量越小越厲害吧, 你看 apple 內建的 app 容量基本上都不大.

jeffh

Jul 28, 2023

34

@pkoukk #30 事实上产品只会说估计要半天吧，留下你在那里懵逼。代码清晰易懂才会少出 bug ，这才是重要的。

ArleneCheung

Jul 28, 2023

35

@crazyTanuki 你这个话让我想起我高数老师说的一句话，有的老师为了证明自己的在学术界不可撼动的地位，把可以讲的简单的知识讲难，但是听他课的学生可就遭殃了，这种人就叫没有师德。所以这跟一个公司的氛围有关系，有的人觉得你写的代码新来的应届生可以看懂，觉得你成就了新来的人才，有的就觉得你可以替代，格局放在这里，如果真的被这样的公司觉得自己是不可替代的，那走了也罢，此处不留爷自有留爷处。

ArleneCheung

Jul 28, 2023

36

@ArleneCheung 纠正一下，觉得自己是可以随便替代的。

nekochyan

Jul 28, 2023

37

当然是清晰易懂最重要，我们前端代码一大堆结构体，看起来代码很多，但实际都是大神写的脚本生成的，看起来多但是在此基础上编程真的方便易懂

pkoukk

Jul 28, 2023

38

@jeffh 你说的这种产品在我们这活不过三天

Nazz

Jul 28, 2023

39

首先看功能是否有缺陷, 然后是性能和可维护性

gps949

Jul 28, 2023

40

得具体情况具体分析，哪种好不一定，代码量属于“标”，只看标不看本就是扯淡。
因为即使看本的话也不存在单一标准：
1 、从技术本身角度：
- 稳定性，边界情况覆盖程度
- 性能
- 资源运用（并发、分布等）
- 资源占用（算力、存储等）
- 易用性
- 复用度
- 兼容性
- 标准化
- 安全性
……
2 、从人的角度：
- 团队协作度（规范标准化）
- 不可替代性（代码易读性）
- 可复用性
……

代码量多和少时可在这些标准做到各有优劣，并且也不存在唯一的对应性。比如代码多就一定易读或不易读吗？

wuwukai007

Jul 28, 2023

41

你觉得中餐好吃还是西餐好吃呢？

zackzergzeng

Jul 28, 2023

42

1 、能写清楚没行代码的作用就行，多少无所谓
2 、代码少不代表性能就好

lsk569937453

Jul 28, 2023

43

不能简单的用多少来衡量代码的质量。可读性，可扩展性，都是衡量代码质量的指标。

dusu

Jul 28, 2023 via iPhone

44

资本环境下，能赚钱的最厉害

crazyTanuki

OP

Jul 28, 2023

45

@wuwukai007 帖子的初衷是学习不同的思维风暴,你是有这方面的疑问你可以自己开贴,没必要含沙射影

wqhui

Jul 28, 2023

46

方便易懂，好维护的代码厉害。
跟代码量不是强关联，有些算法代码就二三十行，有些巧妙（取巧）的设计，但你要理解半天，有些几百行但结构清晰，很容易看懂每个步骤在干嘛

zapper

Jul 28, 2023

47

0. 代码规范。遵守大家约定的规则。别人想看不用你答
1. 逻辑清晰，什么模块干什么事情。别人想改不用你教
2. 内聚，暴露接口在外。别人想用直接拿走
3. 符合架构设计（这算代码方面吗？）

做到以上四点，我会觉得你很厉害。但是我不是老板

woshinide300yuan

Jul 28, 2023

48

在不考虑其他头脑风暴的情况下，就问题本身：我选择代码少的。但事实往往没办法这么一杆子拍死的下结论，所以……默默给 1L 点赞，就看得懂最厉害，方便后续扩展。

tracymcladdy

Jul 28, 2023

49

十年前我还是小白时，写代码像写诗，还经常造轮子。
现在随性多了，怎么简单好摸鱼怎么来。

songjian447

Jul 28, 2023

50

对于我们公司代码量多厉害，因为每月要统计代码量，不够绩效 C ，哈哈

freemoon

Jul 28, 2023

51

要达到 [清晰易懂] 不仅仅是变量规范命名就行了，还要求清晰的逻辑实现（这是重点），以及适当的换行和简洁的注释，一个稍微复杂的需求要做到这一点就比较考验开发者的各项编码水平了。

cslive

Jul 28, 2023

52

写大量得 if (true) return true 类似得代码

tf2

Jul 28, 2023

53

给上级的越难懂越厉害，给平级的接口越合理越厉害，内部实现无无所谓，给下级的越明确越厉害。

imagecap

Jul 28, 2023

54

领导关心代码行数你就多写点，功能正常就可以了。一个同事把一个文件拆分成 20 多个文件其实是有点道理的，说明不了代码水平，但说明他干了很多活，领导就喜欢这种下属。

franklinre

Jul 28, 2023

55

当你是乙方时，代码量多比较厉害。

mshx

Jul 28, 2023

56

能让别人看懂最厉害

Lweiis

Jul 28, 2023

57

1 楼正解

chendl111

Jul 28, 2023

58

清晰易维护（逻辑清晰，代码注释全）> 代码量少 > 代码量多

juzisang

Jul 28, 2023

59

如果是频繁变动的业务代码，可读性最重要，扩展性会牺牲可读性，没到第二次复用甚至第三次复用，暂时都不用考虑代码扩展。
框架架构方面才是考研程序员功底的时候

libook

Jul 28, 2023

60

可读性、合理性、可靠性、可扩展性、性能，五边形战士最厉害。

代码量多少跟厉不厉害没关系。比如别人都解决不了的问题，你解决了，即便代码很多也是很厉害的。再比如完全可以用少量代码实现的功能写了个又长有难懂的代码实现，就算很菜。

当然 C 语言界有个著名的混乱代码大赛，那个代码文本写得越是不像代码越厉害。

在业务表现主要和功能有关的情况下，考核代码量 KPI 很蠢；管理者要么不懂技术，想找个自己可以理解的量化指标来量化绩效；要么懒，应付管理工作。