工作上遇到“能用就行”，唯唯诺诺的指导人(小组长)，大家一般怎么办

[enuui]

每次项目定排期的时候，指导人那边的工作就希望我处理完我的工作之后参与进来，或者做着做着就问我还有多久做完，希望参与到他那边(因为我还是职场萌新啊，当时没怎么考虑就答应了，现在反思觉得是套路？)。

然后参与过去之后发现代码都是以“能用就行”的态度写的，有强迫症的我内心很抗拒啊，不过之前还是硬着头皮写了。



然后我发现指导人知识面和代码设计能力上很一般，和我想象中几年经验的程序员差很远。



直到最近一个项目延期了，在做项目的时候我对我这边的代码做优化和原本答应参与指导人那边的时间偏离了，做优化时也口头上沟通过(太年轻了，没在聊天软件上留下记录)，然后项目延期了，总结的时候原因重点都归到我这边代码设计有问题导致需要重构优化？？

我反思了一下主要项目收尾有一段我们共同参与的排期(就是前面说的我参与过去那块)，然后这块做的内容是没定的(感觉我是填坑的)。



而且指导人还很卷，基本是组里最后一个走的，就算是这样他也不会说延长下项目排期。



现在回想一下才知道是我太年轻了，刚进社会对指导人太信任，只想安心写好代码。

[Kaier]

建议提桶跑路

[enuui]

@Kaier ——怎么避免跑路后不会再遇到老油条

[Kaier]

@enuui 避免不了的...
找熟人内推, 有了解组内情况的人, 能避免一些

[CEBBCAT]

对构建良好代码的欲望，可以通过自己的小项目来释放，甚至是一个 demo 。怎么做一个小小的架构，这里面也有一番趣味

最近发现的，分享给你

[jmone]

都项目延期了，还在那扯代码优化，有什么意义呢？

[lairdnote]

如果是 to B 的思想 还能苟活一段时间。。如果 to C 走吧 。。

[l4ever]

收起你的完美主义思想, 90%的项目就是"能用就行"

[yanzhiling2001]

我就是这样人。从来没想过代码完美，都是能用就行。

应该是以前在外包时候养成的坏习惯。只想着快点搞完，只要不出纰漏就行。天天糊屎。屎上堆屎。

[fl2d]

”小领导”权限并不高，小兵看不到的掣肘的地方太多了，进度 /需求 /预算 等等，不得不妥协出一个能用就行的东西。

[searene]

代码从来就没有“能用就行”这一说，即使是你的领导让你“能用就行”，你也要尽量写出高质量的代码，否则到时候业务拓展，屎山堆屎，倒霉的还是自己，你的领导是不会替你写代码的

[Lefi]

不然怎么弄，刚进入社会就想追求完美？

[tg3253]

本来不就是能用就行吗？刚毕业时我也喜欢重构代码，现在发现没事摸摸鱼、搞搞副业、考考证提升自己才是硬道理，什么代码、工作都是混日子

[v2hh]

我觉得你说的是我

[vvhhaaattt]

小组长视角
项目人力不急的时候会对质量要求高点，看到代码有比较大的优化点，会指出来让返工。
着急的时候，即使 review 到效率低的代码，也确实是能用就行。

[tg3253]

得过且过当咸鱼拿个平均薪酬就挺满足的，优化不好了，万一出问题就是你的责任，出力不讨好的事情傻子才干。。。 以上是在央企工作快两年的工作体会

[awanganddong]

能用就行这句话的含义在不同阶段是不同含义的。
比如我们公司刚起项目，我基本上对下边的同学，也是说的能用就行。
这个阶段，用户没几个，更多的是起功能。
遇到在合理工期完成项目，并且代码写的优雅，这种是非常赞同的。
但是前提条件必须是在工期内完成。
因为资源总是有限的，最害怕就是那种这里怎么优化会怎么怎么好，然后交付的时候，延期了。这种就会很被动。

以上就属于项目第一个阶段吧。
接下来阶段，就是用户量在十万级，百万级针对不同的情况的业务优化了。当然现在我只能达到这个程度，这时候的能用就行，就是你这个项目能保证业务需求。

总之就是务实一点，踏踏实实的。

[dengji85]

职场都是这样的，底层背锅 好的直接领导在你刚来的时候会“实在”的指导你 5%吧

[vvhhaaattt]

有指导人，应该还在试用期之类的吧
你的指导人把项目延期的原因甩锅给你其实是非常傻的行为，如果他确实是这样汇报给上级的话。
任务是他分配给你的，又没有做好技术兜底工作……

[zhea55]

作为一个他们眼中的傻子。我想说的是，保持你内心里面的对与错，好与坏。

时间充裕的情况下，尽量写出整洁，逻辑清晰的代码。

时间不充裕的情况下，可以“能用就行”

混日子的人很多，才显得你有责任、有对代码质量的追求。

这不是对公司的交待，而是对自己的交待。

很多人代码都写的稀烂、整天房子、车子、女人，我无法想象他们的脑子。


最后，你的领导帅锅给新人，明显不合适。

[saulshao]

所有的代码，标准都是"能用就行"。
不然没什么代码可以上线使用......

[sarices]

能用就行啊，项目也不一定成功，等你完美搞好了项目估计已经失败了

[golangLover]

上班除了是为公司，更重要是你自己能够在工作得到什么。写清晰的代码，对你而言是有用的，这就够了

[newmlp]

你是在给公司写代码，项目能及时上线才是关键，代码好不好有什么关系，你代码写的再好的项目说不定几天后就黄了

[3dwelcome]

楼上说代码能用就行的同学，你们就没想过万一以后代码出问题，自己会花上几倍的时间去查 Bug 吗？

这样算下来，还不如一开始多花点时间，直接把代码写好。

[x940727]

@l4ever 不是百分之 90 ，是百分之 99 ，哪怕大公司也是一样……毕竟人员流失，文档不更新都是常事。

[x940727]

@3dwelcome 如果你的项目经历过七八年迭代，大几十个人维护过，百分之 99 都变成屎堆的。

[niub]

职场看直线老大的能力，不行的话赶紧换。（我前几天看到的比较同意的一句话）

[VictorJing94]

长期项目.....一般是先抓紧搞定上线,然后后期自己抽空慢慢优化重构....要是要求大家都严控质量,时间上没法算,而且审查也很耗费时间的

[pepesii]

典型职场萌新的理想主义

屁股决定脑袋，小组长要想的不是怎么写“完美代码”，想的或许是你们一个组的 KPI ，对外部扯皮，按时交付

[emeab]

百分之 99 的项目都活不过需要重构.. 能用就行了.

[mogutouer]

要先有再讲优化，如果是团队合作，尤其是前后端项目，其他的人都等你写完美的代码再跑起来不可能。
退一万步，能用就行的态度去写项目都延期了，当时开始时估时间怎么估的？是否对自己的能力有过高的期望

再退一万步，能用就行和效率最高的代码，在应用层来说，时间上其实差不了多少，很多事情都是顺手就优化的事儿，你是否项目开始前并未花上一天半天来做整体的架构规划逻辑梳理，边做边写最后把锅丢给重构，这很大一部分都是经验的问题，经验这东西值钱就值钱再能够节省大家的时间。

[3dwelcome]

@x940727 别人的代码可以封装后来用，自己写的代码，总要对自己内心有个交待吗？
以后是不是好维护，是代码生命力的一个重要指标。

[zjsxwc]

想起一个笑话，故意劣化代码的都有

[sagaxu]

@3dwelcome "你们就没想过万一以后代码出问题，自己会花上几倍的时间去查 Bug 吗？"

在管理层看来，这些人的不可替代性可能更强

[wolfie]

好一个《唯唯诺诺》
人还觉得你产出不高，事还多。

[newmlp]

@emeab 确实是，上家公司我们还预约了明天的会议讨论版本优化，结果下午服务端就全部被裁员了，一周后项目下线

[XCG0000]

看样子你是没遇见过，对技术蜜汁自信，一心想写好代码，导致 KPI 完不成，对业务贡献度有限甚至是拖累，导致整个团队被裁员的

[lasuar]

首先要保证项目顺利上线，然后再谈优化

[Leonard]

上面要求是能用就行，你写的时候不能“能用就行”，因为一般来说后期随意加 /改需求会拉低代码质量，你一开始就“能用就行”的话会渐渐变成“不能用”、“没法改”。
但是在项目要延期的情况下，就不要在这个时候做代码优化了。
另外留记录也是个良好习惯。

[jsjjdzg]

Windows 还一堆 BUG 呢，各种互联网大厂 APP 还一堆 BUG 呢。。99%的代码都是能用就行，慢慢打磨的机会很少

[dfkjgklfdjg]

review 很耗费时间，以前我也是每天最后一个走，很多时候可能连格式化都没做就提交上来了，真的很头疼，
而且一直打回去改代码对于开发进度的影响真的太操蛋了，所以现在基本上就是看得过去就不打回去了，只是让他们每次一直开着 lint ，并且每次提交前格式化一下。
偶尔进度不紧的时候会考虑优化一下，敏捷开发平时真的没办法做到优雅的代码。

[VIVVACI]

避免过早优化，注意上线时间，没有产品会为你的强迫症拖延。

[chenluo0429]

“能用就行”可能对也可能不对，商业项目因为各种原因必然会有妥协，主要是看妥协的方向。一般前期验证阶段，需求、边界条件、性能都是可以妥协的；架构设计可以简单，但是最好不要敷衍，以后要还的；代码质量是除非万不得已，否则决不能妥协。

[auroraccc]

谁都想写好代码啊，但是有时候真没办法。。。

[tankren]

你今年的绩效好不了了

[x940727]

@3dwelcome 不是这样的，如果是引用别人的代码，大概率是普适性的，非业务相关的，这种代码可能几年甚至几十年都不会变化的。业务代码无论是变动速度还是逻辑复杂度都要高的太多，所以维护难度也是指数级上升的。

[DelayNoMay]

对于项目工程来说，"能用"就是一个不低的要求了。你搞这么好的代码，是公司会颁奖给你还是你就是公司老板？说真的，我最烦的就是像你这样的同事，把整个就业环境卷得不行，你想拿 100 分+附加题的 20 分，你就自己玩去吧，别来卷我们

[zhq566]

在央企。曾经热血的主动说能怎么优化，怎么解决，结果发现就是给自己找垃圾活，干不好还挨说，干好了也不会加钱，时间节点天天卡着你，干活的也只是你。最后，劣币驱逐良币，组内人都是能推各种推的做事态度了。

[enuui]

忘记说明下项目背景——，这是 C++写的 sdk 代码，是会有其他组共同用的。C++的接口和 abi 限制导致基本定下来就很难改，但上级和产品不会关注这些…

[song135711]

接口要仔细定义好, 后续代码怎么实现, 可以先面向交付, 后续再谈优化.

[jsjgjbzhang]

换位思考下，你做指导人会怎么做，从全局看待问题和站在自己角度看问题是截然不同的

[ncepuzs]

done is better than perfect

[JoeBreeze]

看惯了组里大量的复制粘贴+能用就行
优化 /迭代时需要改到别人的代码确实会很头疼, 自己也有过紧急需求复制粘贴的情况
只能是能写好就尽量写好, 在有空的时间多打磨自己

[xz410236056]

人家写能用就行的代码说不定比你还好。
“现在回想一下才知道是我太年轻了，刚进社会对指导人太信任，只想安心写好代码。”
你这也太高估自己的代码能力了吧，按时交付不也是能力的一种吗。

[xz410236056]

你这 3 5 年后再看看自己当初写的“完美”代码，估计也会觉得屎山

[leoShen]

@xz410236056 当然了，这才说明自己进步了。如果过了 3 年还觉得当初的代码很完美，那才惨吧

[liprais]

"然后我发现指导人知识面和代码设计能力上很一般，和我想象中几年经验的程序员差很远。"
看到这就不用看了，楼主眼高手低而已

[zpxshl]

一般来说领导不会觉得你写出 “好代码” 是错误的。 前提是你他给你的工作你都能按期完成。

[enuui]

后面评论有点断章取义了哈…

[yagamil]

大部分项目其实撑不到后面模块多重复用。 而且对于项目紧张而言，一切都是以项目为主。项目交付不了，过了招标演示时间，后面给你再多时间优化也没有用的。

只要你做过项目组长等，你就知道了。

[huZhao]

如果你不怕，牵一发而动全身。即刻发挥你完美主义，出了问题，解决不了，坐等被开也许是最好的结果。

[Akiya]

确实不存在完美的代码，而且对于需要快速上线的项目来说速度确实比质量更重要。项目能活下来才有谈质量的可能，如果对质量看重的话应该去一些比较成熟并且有机会做重构的组

[cyrbuzz]

最近实践了一下#4 的观点，围绕项目做一些插件以及一些使用到的组件自己造造轮子的时候倾注了心血，比起纯业务方的优化也有趣很多。从小点上的逻辑到继承多态，从意识不到要预留出可扩展的接口到实践开放闭合原则等等都妙不可言。

[IsaacYoung]

图样

[lvdb]

组长算什么？我们公司领导直接在会议上说，程序跑起来就行

[susecjh]

淡定点，年轻人，你会遇到比这更蛋疼的事情

[westoy]

每一个还在这行里得过且过的老油条都曾经是追求完美的青葱少年

唉， 岁月......

[omysho]

做软件是做工程，工程不是艺术品，是需要妥协的，工程应用就是如何将『真空中的球形鸡』妥协到真实世界的走地鸡。

我现在给人做 review 代码的时候都会考虑，这个改动意见是不是值得现在就做，如果不急的话就以后再做。

但是！一家有前景的公司应该能够让你对一些库进行重构的工作，如果一年之内都在做这种赶工的很低级的工作的话，我觉得可以跑了

[ClericPy]

从入职一年半的一个公司学到一个词: MVP

然后发现这就是个拿 prototype 直接上线的玩法, 别说工匠精神, 完全就是乱搞, 没招唉, 还好写的是 Python, 排期上还是能以 mvp 的开发时间做出点不那么随便的项目来

现在的状态就是上班不摸鱼守住职业道德, 平时不主动加班回家写自己想写的东西

[0Vincent0Zhang0]

每个功能开发都有一个 deadline ，不能无限优化下去的，看菜食饭，开发的工时需求可以和指导员商量，时间和质量是有一定冲突关系的。
只有一周时间你就直接做核心功能部分，以复制粘贴操作为主，半周开发半周调试 /测试。
有两周时间的话可以加点边界检查，日志输出，代码注释。
有三周就可以把重复的代码提炼成函数，考虑通过缓存来提高运行效率。

[nspih]

一切的东西不都是先建立在按时完成得条件下吗

[killva4624]

优先：按时完成目标；
其次：保证一定质量；
再其次：有自己的风格和标准；
退而求其次：把苦闷和不得志写到别的项目上。
不过想了想，如果都没时间按时完成主项目了，那也就没时间写别的项目。
还是跑路吧。