这是一个创建于 100 天前的主题，其中的信息可能已经有所发展或是发生改变。
洁癖会严重限制生产力
而且很多时候，洁癖都是一种不自信的表现，因为不能容忍不完美，但什么代码是完美的呢，显然没有
我最近写一个 feature ，其实写完了也就写完了，但我为了所谓完美（还是对我自己最初的解决方案不自信，感觉不完美），拖了 3 星期，其实有点后悔，不应该搞这么久，而且犹犹豫豫，最后也没有一个更好的解决方案，还是用了最初的解决方案
 |
1
opengps 100 天前
但总得先过了这个阶段，才能彻底明白需求优先，才能不去计较那些屎山，不去争论哪家语言更好更坏，知道什么时候最应该怎么选择
|
 |
3
cookii 100 天前  1
多写，多反思，多重构。
底层原理就是：有目的性、挑战性的练习+反思和调整(也就是企业黑话中的"复盘") |
 |
4
tairan2006 100 天前
先写再改
|
 |
5
ksc010 100 天前
我也有这种问题，有时候就把这个限制在一个方法、或者类内；先实现功能再说
|
 |
6
fromzero 100 天前
加点 todo 之后再说。
|
 |
7
distleilei 100 天前
如果是公司，早点达到最低要求交差了事，多留点时间给自己才是正解
|
 |
8
NotLongNil 100 天前 via iPhone 1
可是不反思，永远都不会进步。这个要看你对写代码抱着什么样的态度。如果只是个吃饭的工具，确实没必要。
|
 |
9
kekeabab 100 天前
如果是自己感兴趣的项目，经常翻来覆去的想着优化感觉也挺好。
如果不感兴趣，只是纯粹为了吃饭的话，感觉没什么必要折腾，能跑就行。 |
 |
10
akira 100 天前 3
凡事都要适当。。 太完美主义不行， 完全不管不顾肯定也不行。。
|
 |
11
hao0oah 100 天前
我也是，这是毛病，得改啊！
|
 |
12
WhateverYouLike 100 天前 via iPhone
洁癖不是问题，别内耗精神和身体就行。总之就是在“洁癖不断修改代码”和“公司能容忍拖拉的时间”之间找一个均衡点。
|
 |
13
nyxsonsleep 100 天前
说明还是写得不够快，代码不够熟练（狗头
|
 |
14
Takamine 100 天前
其实还是见少了写少了，对于某种实现有一种源于自身设计不自洽的对“best practice”的执念，往往最后会导致很多无效 refinement 。
|
 |
15
weofuh 100 天前
时间充裕的情况下，感觉也没什么不好吧。按照你的描述，至少深度思考也实践过了。可以先提交一版再修改
|
 |
16
Tarek911 100 天前 1
我工作中遇到说这个词的人，一直是对别人代码挑挑拣拣，他自己写的一笔吊糟。
我遇到的是更恶心的那种，要求别人按照他自己想法来写，包括方法命名也要对你指手画脚，喜欢找你 1v1 对你的代码斟词酌句。 人总是会在隔段时间变换一种想法，随着思维迭代，代码总有不足。 没有绝对正确，当下看着顺心就好 |
 |
17
zhanlanhuizhang 100 天前
定好解决方案后，就要去实现一下。然后再改。
|
 |
19
ano 100 天前
[又不是不能跑！] 再次上大分
|
 |
20
fds 100 天前
感觉可以调整下目标？写出三个解决方案，选出最好的。这样就不觉得时间浪费了。
|
 |
21
Helsing 100 天前 via iPhone
出问题时你又会抱怨当初为啥没有好好写了，能好好写还是要好好写
|
 |
22
james122333 100 天前 via Android
不知道你说的洁癖是什么意思？ 如果你的完美是大而全那不叫洁癖 如果不是我觉得要看东西是谁的 如果是自己的当然苦思良久都值 不是那就过的去就好
|
 |
23
unbridle 100 天前
见过有人洁癖到纠结于 0.001 和 0.0001 秒的区别，非要追求后者，这种真的很无语
|
 |
24
adoal 100 天前
有可能你的洁癖只是别人的规范，人家已经把按规范做导致的出码速率“降低”作为规范化管理和质控的成本考虑进去了，也有可能人家出码过程的局部低效率换来的是程序质量提升带来的整体高效益。
|
 |
25
ZeawinL 100 天前 via iPhone
没有代码是最好的代码
|
 |
26
xuanbg 99 天前
只不过是代码乱写的人太多，而不是 OP 你有洁癖。代码干净整洁而不是没有规范，逻辑直接了当而不是弯弯绕。这些是程序员的基本素养
|
 |
27
linzyjx 99 天前
如果是代码规范这种，不太能叫洁癖。
除此之外，能让大多数人看懂的代码就是好代码。 |
 |
28
yagamil 99 天前
一般时间太多的人才会去追求这种洁癖。
项目明天上线，今天开始做一个 demo 给老板，你会想这个循环用 map 还是 forEach 这些鸡毛碎皮的事么 |
 |
29
blankqwq 99 天前
过于完美主义
|
 |
30
zhady009 98 天前 via iPhone
这是习惯问题看熟练度的
|
 |
31
abelmakihara 98 天前
不完美无所谓 只要留着后路 以后好改就足够了
|
 |
32
mcryeasy 98 天前
我也有这个问题，总是花很多时间在上面，过于最求完美主义。正确的做法是，适当的考虑，先实现了功能，后续根据反馈再优化。避免设计了很多用不上的东西，产生无效的内耗。
|
 |
33
JustBecause 98 天前
十分赞同，刚刚度过这个阶段。自己的项目，总想着能写的更优雅更完美，旧功能一直在拖着改，新功能没时间加。后来发现，能跑就行了，管他那么多干啥，再不济先把 feature 上了再说
|
 |
34
phatzhong24 98 天前
先做出一坨屎，再慢慢改
|
 |
35
edisonwong 98 天前
每次写 fea 的时候，写完留 10 分钟出来 review 优化下。大优化的话，看个人时间吧。我记得有个微软大佬说过：“绝大多数的 bug 都能通过重复读两遍代码发现”
|
 |
36
GeekGao 98 天前
完美主义将会害死未来被无辜裁员躺枪的自己
|
 |
37
lepig 97 天前
以前也有过楼主的经历，现在不会特别的纠结这些，只是先把大体流程和逻辑先写完在修修补补，不会为了完美来重新改写。
|
Select Language