这是一个创建于 174 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家对这个怎么看，以前的话我贼喜欢造轮子，写算法，纯手撸东西 后来慢慢的，不知道从什么时候，可能是被训的，嫌写得慢，让我去抄，去降低代码质量 要速度 也可能是屎山见的多了，现在以速度业务优先了 反正现在我虽然还是会下意识的去考虑一些，设计模式啊，性能啊，程序原则啊之类的，并随手写进去。 但是已经不是纯粹的去极致的优化性能代码了，而是慢慢的转向业务速度优先，开发速度优先，质量这玩意属于必须的，但是不是那么极致的要求了 因为现在代码迭代速度也快 需求变动也快 而且这两年现在发现 代码没有那么极致的去优化简化之后，反倒更易读了，以前写的代码属于，没点水平看不懂，现在的代码属于，有点水平都能看懂，感觉各有利弊吧
 |
1
shitcode 2025 年 7 月 21 日
先让业务跑起来，剩下的再说
|
 |
2
tyrantlucifer 2025 年 7 月 21 日
黑猫白猫，抓住耗子的就是好猫，能跑就行
|
 |
3
spritecn 2025 年 7 月 21 日
java 么,java 这里不存在看不懂的,只存在套太多层不好找
|
 |
4
YanSeven 2025 年 7 月 21 日  1
以后先让业务跑起来的事情可能需要 llm 来了，人 debug 和接管 llm 的屎山，估计更难受。
|
 |
5
lneoi 2025 年 7 月 21 日
不要预先优化代码, 所以写简单的, 看起来可能啰嗦点的代码, 在很多时候反而是正确选择
|
 |
6
MIUIOS 2025 年 7 月 21 日
业务不跑起来 饭就没得吃，这两个是冲突的，政策
|
|
7
MIUIOS 2025 年 7 月 21 日
正常
|
 |
8
windyboy 2025 年 7 月 21 日
工作和兴趣不太一样，当然也有人能同时满足，很难
造轮子这事情只有极少数的场景合适，你总不能每个项目都发明一种新语言吧 |
 |
9
zgzhang 2025 年 7 月 21 日
@BortonJones 我以前有类似 op 这样的一个同事，极度爱造轮子，为了抠一点内存性能代码写的很复杂。作为他的 leader 真的很烦躁，我最需要的是结果，是排期，是产出。如果他真的能解决什么了不得的技术问题我可能还能接受点，但实际上工作中很多情况没什么太大的挑战，效率更重要，更别说已经有很多聪明人已经有现成的轮子了，后面是在受不了给了个 C 淘汰了他，接受了他项目的人没人不骂娘，没办法只能全部重写。最后我想说的是，来公司是来干活的，不是秀的，质量不出事，或者出事能快速解决就好了
|
 |
10
HeyWeGo 2025 年 7 月 21 日
正常情况下，你能遇到的问题大部分都能遇到，有现成的就用现成的，想学习东西堆好了之后再看就是了。AI 让我这个编码白痴学到了很多。扩宽了不少眼界
|
 |
11
Cruzz 2025 年 7 月 21 日
其实工作中最重要的并不是什么设计模式，也不是什么算法，最重要的技能是，怎么从屎山里抓到你想要的那坨屎。
|
 |
12
weixind 2025 年 7 月 21 日
“代码是用来让人读的，只是顺便让机器执行而已” —— 鲁迅
|
 |
13
RightHand 2025 年 7 月 21 日 via Android
换条思路，尽量把与业务无关的做开源，就能既要又要了，业务就去堆
|
|
14
RightHand 2025 年 7 月 21 日 via Android
接上面，大部分的同事都是混口饭的。还会认为你在炫技来排挤你
|
 |
15
liuidetmks 2025 年 7 月 21 日
大多数人发明的轮子没什么用，承认吧。
本身就是业务高度相关，离开业务一钱不值 |
 |
16
jackOff 2025 年 7 月 22 日
先最快完成老板想看的东西，然后偷偷完成架构优化和 bug 修复，先把态度做好就行。如果有不合理需求，先把不合理的结果丢给他看，丢人就一起丢人吧
|
 |
17
1024potato 2025 年 7 月 22 日
我们项目组有一个同事和你之前一样，简单的业务代码上来就各种设计模式,代码复杂各种类和方法间跳转。开发的功能 bug 多到改不完，bug 分给其他组员一起改别人都说“看不懂”。
|
 |
18
HENQIGUAI 2025 年 7 月 22 日
主要是为了解决问题，如果想炫技可以自己回去脱敏之后发到网上随便炫。
|
Select Language