这是一个创建于 838 天前的主题，其中的信息可能已经有所发展或是发生改变。
看到挺多公司喜欢考核代码量 kpi 的
 | 1 qsnow6 2023-07-28 09:59:10 +08:00  82 在团队中，在实现需求的前提下，清晰易懂最厉害。 |
 | 2 laoluo1991 2023-07-28 09:59:58 +08:00 楼上正解 |
 | 3 brader 2023-07-28 10:00:48 +08:00 1 没有看到具体代码之前无法评判，同样需求实现，我估计代码量差不了很多行数的，如果差出行数，那行数多的代码很可能做了更多的异常处理、数据校验。 所以代码这种东西，一定要分个高下，还是拿出来比一比才知道 |
 | 4 lcy630409 2023-07-28 10:01:29 +08:00 能让别人（同级）看懂 能运行就是好代码 |
 | 5 crazyTanuki OP @qsnow6 但是也有一个可能,新来的实习生轻轻松松上手,显得你很菜...老板觉得实习生可以替代你,但代码绕,过度封装,层层跳转,实习生连试用期都过不了 |
 | 6 iyiluo 2023-07-28 10:02:18 +08:00 可读性 |
 | 7 DigitalG 2023-07-28 10:03:03 +08:00 赞同 1 楼，但 lz 显然说的是别的“厉害”，并不是在讨论技术。 |
 | 8 sankooc 2023-07-28 10:03:18 +08:00 代码量考核 kpi... 冗余度计算在内么 |
| 10 crazyTanuki OP @brader 异常处理,数据校验属于需求内了,不可能一个做处理一个不做处理这样对比代码量 |
| 11 crazyTanuki OP @lcy630409 会不会没有护城河 |
| 12 crazyTanuki OP @DigitalG 综合性吧,纯技术或者纯人情世故都太片面了 |
| 13 crazyTanuki OP @sankooc 不计算,CV 的不算 |
 | 14 maocat 2023-07-28 10:05:57 +08:00 没有注释我还能看的懂的代码最厉害 |
| 15 crazyTanuki OP @maocat 其实这个规范命名就很容易看懂了,基本上都不需要注释 |
 | 16 tcpdump 2023-07-28 10:08:28 +08:00 可维护、可扩展 |
| 17 crazyTanuki OP @tcpdump 基本上面向对象或者函数式就能做到吧 |
| 18 brader 2023-07-28 10:12:41 +08:00 @crazyTanuki 那也会有差异化啊，就比如校验几个参数是否为空，有些后端喜欢用一个 if 或关系来判断，直接报参数错误，有些后端喜欢一个一个判断，告诉你哪个参数必须的。这两种做法都能实现需求，区别只在于对你的前端对接人报错是否友好，但是文档齐全的情况下，其实也没问题 |
 | 19 volatileSpark 2023-07-28 10:13:26 +08:00 清晰易懂最厉害 |
 | 20 akring 2023-07-28 10:20:29 +08:00 4 写出为难同行的代码并不能够成为你的护城河，因为大概率决定你去留的人，和接管你代码的人不是同一个。 最近的大型社会实验现场可以参见 Twitter 。 |
 | 21 GeruzoniAnsasu 2023-07-28 10:21:58 +08:00 用时短的厉害 |
 | 22 likang8210 同事有行代码是这样的：Map<String, Map<Boolean, List<Map<String, Object>>>> categoryDatas = endData.stream() .... 这[categoryDatas] 变量是不是叼炸天，就两行，没注释 |
 | 23 Leviathann 2023-07-28 10:23:18 +08:00 code is all about expressiveness |
 | 24 witcat 2023-07-28 10:23:50 +08:00 1 在真正高手如云的团队里，故意写的抽象，是会受排挤的... |
 | 25 HB9527 2023-07-28 10:24:11 +08:00 1 和代码量多少没有关系，是别人能不能快速看懂有关，架构清晰、结构清晰最好，毕竟代码是给人看的，编译之后是给机器运行的。 |
 | 26 bugmaker1024 2023-07-28 10:29:34 +08:00 抽象的代码还是不要写，因为过段时间你自己再看的时候你自己都可能不知道当时不知道为什么这样写。清晰易懂最重要 |
 | 27 shyangs 2023-07-28 10:32:07 +08:00 大神在代塞魔字 ，不，一有人吹，比如 John D. Carmack 的魔法字 0x5f3759df 高手如的 Linux 核也一堆奇技淫巧. |
 | 28 roundgis 2023-07-28 10:34:39 +08:00 via Android 收多的害 |
 | 29 ox18 2023-07-28 10:36:10 +08:00 不能一概而论吧 |
 | 30 pkoukk 2023-07-28 10:36:24 +08:00 我觉得都不是，清晰易懂也就一般般 厉害的是架构里有足够的灵活度适应瞎 JB 改的需求 当产品很不好意思地说这个需求估计要七八天吧，我只需要两三天的时候，别提有 TM 多爽了 |
 | 31 silencil 2023-07-28 10:38:31 +08:00 一个方法只做一件事的就是好代码，在我这是个很简单的判断标准。代码写的再好，又臭又长真的是看的头大，不好抓主要的点。 |
 | 32 tkHello 2023-07-28 10:40:11 +08:00 无所谓 他司统计代码量 |
 | 33 wangedenr 2023-07-28 10:41:58 +08:00 app 容量越小越害吧, 你看 apple 建的 app 容量基本上都不大. |
 | 35 ArleneCheung 2023-07-28 10:45:34 +08:00 @crazyTanuki 你这个话让我想起我高数老师说的一句话，有的老师为了证明自己的在学术界不可撼动的地位，把可以讲的简单的知识讲难，但是听他课的学生可就遭殃了，这种人就叫没有师德。所以这跟一个公司的氛围有关系，有的人觉得你写的代码新来的应届生可以看懂，觉得你成就了新来的人才，有的就觉得你可以替代，格局放在这里，如果真的被这样的公司觉得自己是不可替代的，那走了也罢，此处不留爷自有留爷处。 |
| 36 ArleneCheung 2023-07-28 10:46:59 +08:00 @ArleneCheung 纠正一下，觉得自己是可以随便替代的。 |
 | 37 nekochyan 2023-07-28 10:47:48 +08:00 当然是清晰易懂最重要，我们前端代码一大堆结构体，看起来代码很多，但实际都是大神写的脚本生成的，看起来多但是在此基础上编程真的方便易懂 |
 | 39 Nazz 2023-07-28 10:51:41 +08:00 首先看功能是否有缺陷, 然后是性能和可维护性 |
 | 40 gps949 2023-07-28 10:53:44 +08:00 得具体情况具体分析，哪种好不一定，代码量属于“标”，只看标不看本就是扯淡。 因为即使看本的话也不存在单一标准： 1 、从技术本身角度： - 稳定性，边界情况覆盖程度 - 性能 - 资源运用（并发、分布等） - 资源占用（算力、存储等） - 易用性 - 复用度 - 兼容性 - 标准化 - 安全性 …… 2 、从人的角度： - 团队协作度（规范标准化） - 不可替代性（代码易读性） - 可复用性 …… 代码量多和少时可在这些标准做到各有优劣，并且也不存在唯一的对应性。比如代码多就一定易读或不易读吗？ |
 | 41 wuwukai007 2023-07-28 10:54:30 +08:00 你觉得中餐好吃还是西餐好吃呢？ |
 | 42 zackzergzeng 2023-07-28 10:56:36 +08:00 1 、能写清楚没行代码的作用就行，多少无所谓 2 、代码少不代表性能就好 |
 | 43 lsk569937453 2023-07-28 10:57:48 +08:00 不能简单的用多少来衡量代码的质量。可读性，可扩展性，都是衡量代码质量的指标。 |
 | 44 dusu 2023-07-28 10:58:50 +08:00 via iPhone 资本环境下，能赚钱的最厉害 |
| 45 crazyTanuki OP @wuwukai007 帖子的初衷是学习不同的思维风暴,你是有这方面的疑问你可以自己开贴,没必要含沙射影 |
 | 46 wqhui 2023-07-28 11:02:20 +08:00 方便易懂，好维护的代码厉害。 跟代码量不是强关联，有些算法代码就二三十行，有些巧妙（取巧）的设计，但你要理解半天，有些几百行但结构清晰，很容易看懂每个步骤在干嘛 |
 | 47 zapper 2023-07-28 11:05:20 +08:00 0. 代码规范。遵守大家约定的规则。别人想看不用你答 1. 逻辑清晰，什么模块干什么事情。别人想改不用你教 2. 内聚，暴露接口在外。别人想用直接拿走 3. 符合架构设计（这算代码方面吗？） 做到以上四点，我会觉得你很厉害。但是我不是老板 |
 | 48 woshinide300yuan 2023-07-28 11:14:20 +08:00 在不考虑其他头脑风暴的情况下，就问题本身：我选择代码少的。但事实往往没办法这么一杆子拍死的下结论，所以……默默给 1L 点赞，就看得懂最厉害，方便后续扩展。 |
 | 49 tracymcladdy 2023-07-28 11:16:51 +08:00 十年前我还是小白时，写代码像写诗，还经常造轮子。 现在随性多了，怎么简单好摸鱼怎么来。 |
 | 50 songjian447 2023-07-28 11:18:12 +08:00 对于我们公司代码量多厉害，因为每月要统计代码量，不够绩效 C ，哈哈 |
 | 51 lasuar 2023-07-28 11:22:26 +08:00 要达到 [清晰易懂] 不仅仅是 变量规范命名就行了，还要求清晰的逻辑实现（这是重点），以及适当的换行和简洁的注释，一个稍微复杂的需求要做到这一点就比较考验开发者的各项编码水平了。 |
 | 52 cslive 2023-07-28 11:29:01 +08:00 写大量得 if (true) return true 类似得代码 |
 | 53 tf2 2023-07-28 11:30:05 +08:00 给上级的越难懂越厉害，给平级的接口越合理越厉害，内部实现无无所谓，给下级的越明确越厉害。 |
 | 54 imagecap 2023-07-28 11:30:47 +08:00 领导关心代码行数你就多写点，功能正常就可以了。一个同事把一个文件拆分成 20 多个文件其实是有点道理的， 说明不了代码水平，但说明他干了很多活，领导就喜欢这种下属。 |
 | 55 franklinre 2023-07-28 11:30:50 +08:00 当你是乙方时，代码量多比较厉害。 |
 | 56 mshx 2023-07-28 11:33:16 +08:00 能让别人看懂最厉害 |
 | 57 Lweiis 2023-07-28 11:36:30 +08:00 1 楼正解 |
 | 58 chendl111 2023-07-28 11:37:45 +08:00 清晰易维护（逻辑清晰，代码注释全）> 代码量少 > 代码量多 |
 | 59 juzisang 2023-07-28 11:38:48 +08:00 如果是频繁变动的业务代码，可读性最重要，扩展性会牺牲可读性，没到第二次复用甚至第三次复用，暂时都不用考虑代码扩展。 框架架构方面才是考研程序员功底的时候 |
 | 60 libook 2023-07-28 11:39:42 +08:00 可读性、合理性、可靠性、可扩展性、性能，五边形战士最厉害。 代码量多少跟厉不厉害没关系。比如别人都解决不了的问题，你解决了，即便代码很多也是很厉害的。再比如完全可以用少量代码实现的功能写了个又长有难懂的代码实现，就算很菜。 当然 C 语言界有个著名的混乱代码大赛，那个代码文本写得越是不像代码越厉害。 在业务表现主要和功能有关的情况下，考核代码量 KPI 很蠢；管理者要么不懂技术，想找个自己可以理解的量化指标来量化绩效；要么懒，应付管理工作。 |
 | 61 loryyang 2023-07-28 11:47:23 +08:00 容易看懂，容易维护最重要，其他都不重要 |
 | 62 Myprajna 2023-07-28 11:54:52 +08:00 黑猫白猫，能抓到老鼠就是好猫。 |
 | 63 kkkkk23232 2023-07-28 11:54:55 +08:00 性能不敏感，清晰易懂最重要，毕竟代码还是要给人看的 |
 | 64 wanguorui123 2023-07-28 12:07:36 +08:00 复用性 层次清晰 易于维护 性能可靠性 |
 | 65 oldking24 2023-07-28 12:09:39 +08:00 via Android @likang8210 这玩意怎么 debug 哈哈哈 |
 | 66 msg7086 2023-07-28 12:12:30 +08:00 @likang8210 没注释确实该打。代码这样写倒是还好，反正有测试覆盖，你知道输入和输出，处理没有错误，不需要 bug ，看不懂就看不懂了。 |
 | 67 akira 2023-07-28 12:21:47 +08:00 代码小白都能看懂的最厉害 |
 | 68 ijrou 2023-07-28 12:51:06 +08:00 via Android 在完成业务的前提下，代码量越少性能越高且晰易懂，那才是厉害的 |
 | 69 ZeroDu 2023-07-28 13:09:51 +08:00 一楼正解；扩展性，其实很多时候扩展这扩展这也成屎山了 |
 | 70 dezou 2023-07-28 13:11:04 +08:00 容易看得懂最厉害，最烦炫技的傻逼 |
 | 71 revlis7 2023-07-28 13:39:40 +08:00 1 同样是写代码，写底层和写业务完全是两种追求，越接近底层越需要榨干性能追求优化，用到奇技淫巧我觉得是可以理解的。你写个业务，目的是满足需求，如果写的太复杂抽象不利于扩展和维护，我觉得是不合适的。 |
 | 72 qiumaoyuan 2023-07-28 13:45:43 +08:00 刚毕业吧 |
| 73 qiumaoyuan 2023-07-28 13:49:04 +08:00 3 为什么会有人觉得写代码让人看懂是很简单的能力？还护城河，说得好像写出易读的代码很容易能做到似的。“消除重复”能做到的都是少数。真把代码写清楚了，那才是你的护城河。 |
 | 74 yxisenx 2023-07-28 13:59:21 +08:00 @crazyTanuki 那这公司也没啥呆下去的必要了 |
 | 76 deplivesb 2023-07-28 14:01:16 +08:00 写出难以维护，难以读懂的代码不是你的护城河，只会是你被替换的理由 |
 | 77 736531683 2023-07-28 14:13:20 +08:00 你可曾听过奥卡姆剃刀原理 |
 | 78 fano 2023-07-28 14:44:42 +08:00 软件设计有两种方式：一种是设计得极为简洁，没有看得到的缺陷；另一种是设计的极为复杂，有缺陷也看不出来。第一种方式的难度要大得多。 C. A. R. Hoare, CACM Feb 1981 |
 | 79 ttwxdly 2023-07-28 15:11:19 +08:00 清晰易懂最厉害 |
 | 80 zhu327808 2023-07-28 15:23:50 +08:00 比较笨的代码, 读起来不用太动脑筋 |
 | 81 s5s5 2023-07-28 15:36:31 +08:00 看单元测试覆盖率啊，谁单测高谁安全 |
 | 82 hansomeneil 2023-07-28 15:40:36 +08:00 压工期的前提下，代码连基本 case 都不一定覆盖完，强求优雅是不现实的。你把优化的时间算进去，大领导就跟吃屎了一样难受，杭州很多都是这德行。。。 但不管怎么说，力所能及的情况下，还是会尽量追求最佳实践，给自己节省后期维护成本，也给后人少埋坑。。。 |
 | 83 8355 2023-07-28 15:43:52 +08:00 代码少 可能简洁易用 代码多 可能健壮度好 逻辑严谨 |
 | 84 DoWnH 2023-07-28 15:59:47 +08:00 对程序员：干净、整洁、清晰 对老板：量大管饱工作量多 |
 | 85 thinkwei2012 2023-07-28 16:00:56 +08:00 一楼正解 写代码就像写小说，逻辑清晰看得懂最重要。即使前期再烂，后期也很容易对照逻辑来优化 |
 | 86 he007h 2023-07-28 16:02:20 +08:00 完成需求，完成 KPI ，领导满意就行了，过程怎么实现的，简单或者复杂不重要，一份工作罢了 |
 | 87 aliveyang 2023-07-28 16:19:08 +08:00 能够 1 天内交接的厉害，无法 1 月内交接的也厉害 |
 | 88 20g 2023-07-28 16:22:53 +08:00 我觉得看功能时间要求吧，先写好再优化 |
 | 89 polo3584 2023-07-28 16:25:14 +08:00 清晰的，整洁的，留有拓展性的， |
 | 90 liuidetmks 2023-07-28 16:39:16 +08:00 需求 80%代码是用来处理 20%的异常 如果功能完全一样，那么肯定是简洁的好。 |
 | 91 zhuangzhuang1988 2023-07-28 20:31:50 +08:00 看人，比如看 vscode 的代码里面一堆注入的 看不懂的人就说 这是 Java 的荣誉写法 |
 | 92 cbais7890 2023-07-28 21:21:44 +08:00 准时下班最厉害 |
 | 93 please0stop 2023-07-29 00:22:37 +08:00 我的衡量就是看用处，看作用，如果两个达到的目的相同，那么二者差距为无穷小 |
 | 94 evalcony 2023-07-29 12:27:34 +08:00 用代码量考核，就像在考核搬砖，搬的砖头越多，付出越多，价值越大。 这种考核方式问题就是把写代码这件事看成和搬砖一个层次的事情。 |
Select Language