努力写的代码，说停就停了，失落，惊讶和困惑

[ericgui]

我在大概 1 个月前发现，我上一家工作的公司，由于我的离职（前端），然后后端程序员也离职了，这样，这个团队唯二的程序员就走了，公司然后就停止了项目的开发，这个项目前前后后 4 个半人搞了大概 10 个月（老板，项目经理，前端 1 个半人，后端 1 人），然后公司就因为人走了，就决定放弃了。

惊讶+1
失落+1
困惑+1

我当初那么在意代码质量，而且有空闲的时间不是去摸鱼，而是重构不漂亮的代码。都没意义了。

昨晚得知我第一个做的项目，上线后大概运行了不到 1 年，就不用了。。。。
当初那么纠结代码好不好，为了一个细节而折腾得晚饭都错过了，只好吃不健康的外卖。。。
有时为了修 bug，在办公室待到晚上 11 点。。。。

惊讶+1
失落+0.5
困惑+1


不知道说什么了。。。。。

[james122333]

先不要做的太好搂
吃力不讨好

[andrewpsy]

关于这个我也算是半个过来人了。
以前我也是那么得在乎，有内存使用能少用 1byte 的机会都绝对不会放过。
后来慢慢发现越高层的项目和开发管理人员看待技术人员越不在乎这些“小细节”，他们更关心大局上的 impact。
我自己也慢慢调整到面向工资编程，面向 KPI 编程，面向良心编程了。
由于输出还算高，我平时上班当着老板的面摸鱼划水都不会不好意思。

[johnnie502]

所以想让你自己感觉不错的代码流传下去的唯一方法就是到 github 上开源

[Yvette]

没必要，而且代码本来就不是永恒的，特别是这种互联网公司。刚学编程的时候有老师就跟我们说过，一般人为公司写的代码基本上两年左右就会被其他人替换掉，但这并不代表代码质量不重要。

[seki]

想开点
公司付钱请你上班，你的工作产出的权益归于公司，他们有处置权。不过写代码的时候学到的知识和经验，还是属于你的，你赚到了

[JamesR]

1.“重构不漂亮的代码”，我认为没事重构代码纯属浪费时间，除非这个代码功能彻底用不成，否则不论写得多烂，我不会去重构代码。重构代码的人低估了重构代码所需的时间，某代码要跑半年才能暴露出某个 bug，你重构？搞笑。
而且，在我看来重构代码和摸鱼没啥区别，你花费大把时间，却没有任何产出，也没有学习新的将要用的不会的技术，如果重构会生成一堆新 bug，那甚至还不如摸鱼休息会。除非干完活有大把时间，闲得发慌没事干，才可以重构那么一下下。

2.“上线后大概运行了不到 1 年，就不用了”，这个得怪老板，老板没有把项目进行下去，能怪干活程序员吗。

3.“在办公室待到晚上 11 点”，这个无力吐槽，别的同事不下班，害得我也下不了班。

[yilingersier]

@JamesR 哈哈哈，关于第 3 点，我们的组员就跟我抱怨，每周五就我去公司上班，给他们很大的压力

[Pastsong]

@yilingersier #6 现在周五上班也能给压力了

[yyfearth]

@JamesR “重构不漂亮的代码” 确实是浪费时间 但是 “除非这个代码功能彻底用不成，否则不论写得多烂，我不会去重构代码”也是不应该的 有时候可能会导致浪费更多时间
@ericgui 完美主义心里可以有 但是行动上要克制 过度浪费时间和生命在这些上面不值得 而且 bug 和问题反而可能会更多

我觉得产品代码是否需要重构要看“可维护性”和“可扩展性”
如果代码过于混乱 /过时 /局限太大 导致当前要修 bug 或者加 feature 过于困难 在时间允许的情况下就一定要重构
如果是多人大项目 当代码混乱到别人接手看不懂没办法下手 最好也要重构一下 如果时间允许
如果没有时间 那么就应该给项目管理或者上层提出重构的需求 然后安排时间 可以说如果不重构以后维护和加功能会多么多么困难需要多花多少多少时间这样
而且重构不应该是一股脑儿彻底重构 最好是是局部的和渐进的 如果有足够的 unit test 就更好了

重构是很花时间的 也是很危险的 可能之前的 bug 修好了反而产品坏了 以及可能引入很多新 bug
但是如果拖太久 后期的可维护性就会越来越低 可能会拖到整个项目不得不砍掉重来就得不偿失了

同时如果有比较全面的 unit test 或者自动 test 重构的难度和风险会降低很多

[wangxiaoaer]

@JamesR 你这种人哪家公司用了真是倒了八辈子霉。

[ericgui]

@wangxiaoaer +1

[vagrom]

认真干活的人越来越少了，追求精益求精的人也差不多被大环境带偏了。
差不多就行了的人越来越多了。这里差不多，那里差不多，最终的结果就差很多。

[taogen]

写漂亮代码是为了自己，优秀是一种习惯。

[ShotaconXD]

写能用的代码是本分
写优秀的代码是素养
能重构旧代码是挑战
被重用的代码是成就

[elfive]

@JamesR #6 分清楚重构和重写。

[mcfog]

普通人用茶壶的时候并不会关心茶壶的做工造型技术指标，也不见得多爱惜普通的茶壶，因为奇奇怪怪的原因导致坏掉扔掉没有用下去的茶壶也很多，作品被当作艺术品或是奢侈品重视珍藏的顶尖茶壶匠全世界只有几个，普通茶壶匠就因为别人随手摔个茶壶在这里多愁善感？现实就是你没这个斤两，你可以选择精益求精，做更好的茶壶，试图成为更好的茶壶匠甚至是名家，也可以选择混日子反正做做普通茶壶也能吃上饭，都是个人选择

哦对了，这种时候更卓越的人的选择是复盘思考，自己做的工作有哪些部分是没有考虑到商业风险导致的无用功，项目黄了是否和自己职责范围或是控制圈内的一些细节有关，有哪些地方可以做的更好，哪些地方可以做的更少，来提升自己以后的输出

[spadger]

这个太正常了。没必要纠结什么。

[TimeRain]

只是领一份工资而已，不要太在意了，就算公司倒闭破产也不要太在意

[ruijanlee]

推荐你看下梁朝伟的《流氓医生》，医生只负责治病，至于病人康复之后怎么糟蹋自己是管不了那么多的。

[tigerstudent]

有点玻璃心了。

这么爱你那些年写的代码，怎么就舍得离职了呢