好失望，想在工作中写好代码真难。想得多了，容易过度设计导致项目延期；想少了代码又要被打回来重写。。。真难过，求大家骂骂我

[0x0208v0]

如题，深受打击。

本人从业三年多了，一直用的 python 。

组里做 toB 的，业务细节非常非常非常复杂，

项目代码要求写代码要写单元测试，结果代码在本机都跑不通，

如果提交到 GITLAB 上，build 镜像就要十多分钟，还不算跑历史的 testcase，

好烦

[DinoStray]

好代码是不停迭代, 重构来的, 除非很多年的经验和能力, 一蹴而就很难

[SuperManNoPain]

代码都是迭代才好起来的，慢慢来吧

[quanqiubiannuan]

转行吧

[patz]

其实世界本来就是不完美的，做事情存在各种限制和约束， 不过我觉得这个是个好事情，这使得我们逼着去想新的方法和创新。建议题主试试，习惯为每个项目或工作事项设一个时间 deadline， 然后尽量在这个时间点之前完成工作， 并同时把质量尽可能最大化。过度的完美主义，很多时候在实际工作会带来负面效果，因为代码总是可以写得更好，问题是你需要花多少时间？而且所谓的好代码，比起项目周期和时间成本来说， 一定更重要么？我之前在 youtube 看到一个视频，记录了张艺谋如何在紧迫的时间内完成了 08 年中国奥运的开闭仪式的表演项目， 建议有兴趣的朋友可以去看看，个人认为很有启发。

[jaredyam]

「完美主义是软件项目的绊脚石」

[wu67]

我写 js 的, 在我看来, 初稿不用写到完美, 能简洁易懂就行. 而且基本上也写不出完美的代码.

那么我平时是如何界定呢?
1. 避免嵌套地狱、回调地狱、异步 调用 /互套 地狱
2. 写一段相对复杂的逻辑之前, 想想如果明天要把这段代码介绍给项目组其他同事让他理解这段逻辑, 需要怎么写才能尽可能的降低需要给他解释的成本
3. 在第 2 点完成后, 给刚刚需要‘解释’的地方, 加上注释
4. 如果第 2 点写出来的逻辑还是难看懂, 那干脆就写面条代码
5. 后续在迭代中, 如果涉及到这段代码, 如果有更好的想法, 可以及时小范围重构

经过上述过程之后, 一般就能提交了. 另外值得一提的是, 第 2 点中提到的其他同事, 很有可能就是我自己...

[Biwood]

既然用的是 python 就不要想那么多，不是说“人生苦短”吗

[akira]

成年人的世界 没有容易二字

[xgfan]

这都是辩经，过度设计和缺少设计都是一句话的事情。
建议多学点高级名词，争取辩赢团队其他人。

[ayase252]

完善单元测试与不断重构

[zoharSoul]

转行吧

[abersheeran]

toB 的项目不需要快速迭代，只需要稳定。写代码之前问清楚需求，有多少需求就多少设计，做好当下。以后的事以后再说。不同的客户需求不一样，你考虑太多只能把自己搞死。

[shyangs]

有多少需求, 做多少, 多做沒加更多錢.

[tatu]

试试先写测试？

[zt5b79527]

做项目就是做工程，所有的工程都是各种“妥协”的产物，妥协于工期、妥协于资金、妥协于人力、妥协于管理等等。。。
完美主义者是很累的，建议能妥协的地方适当妥协，能（容易）完美的地方尽量完美，这样就皆大欢喜了。
什么，你不知道哪里该妥协？你还年轻，多干几年慢慢就懂了（狗头）

[missdeer]

如果你不是特别热爱写代码这件事，就转行吧，毕竟只是个谋生手段，360 行，总有合适的

[jorneyr]

要做好，必须定制好开发详细的规范 (内容会非常多: 例如代码风格、命名、各种场景的不同注释、设计文档、接口管理、代码片段库、已有功能的重复使用、git 规范、在线帮助文档等等)，大家做每一步都有相关参考，而且严格执行，否则平时自由发挥，审核时说这不好，那不好，那应该怎么改才好呢？

这个是自顶向下才能推广的事，做不好，主要责任在领导 (必须要他带头严格执行)，普通开发者说啥其他人肯定不会听你的，反而被大家讨厌，估计大家也会讨厌领导做这事，但是谁干反对？

[stirlingx]

只要遵循单一职责，接口隔离、依赖倒置、里式替换、开放封闭原则。，代码还有得救

[chenmobuys]

先把基本功能都写出来，再来考虑迭代，客户可没时间等你，他们要的是快速看到效果。后面再慢慢的优化。

[kingran945]

@xgfan 有什么推荐的书籍么？