最近将自己写了几个月的代码，挑了一部分逻辑（1/5）往大项目提了 PR。在经历了 Conversation 100+、Commit 90+ 、Time 50d+ 之后，总算是将 1400 行的代码改好，进入等待最终合并的阶段。
---
这周将 PR 中的反馈整理成文档，并重构原有仓库。接近少了一千行….
1. 过度设计 : 有的功能明显是想多了，用 200% 的复杂度实现了 105% 的功能，以至于维护起来像是穿着重甲在水中行走。因为 PR 中要给人说清楚，就索性直接删掉了。
2. 没有遵守 Best Practice ：有很多逻辑既可以「这样写」也可以「那样写」，但这种视角一般是入门者才会这样。若是经验丰富的开发者他们眼中的方案或许就会收缩到少有的一两种，然后再根据项目的「惯例」来确定唯一的方案。而一般这样做的话，很自然就会发现有不少趁手的工具直接复用从而减少代码。（其实他们的文档中都有提到的）
3. 其他 ：删除过多的 log 以及混乱的 try-catch
---
四舍五入，这些都是 Vibe-Coding 的副作用了，「我没有足够的能力审查大模型编写的代码」。
因为言出法随，动动嘴皮子就能写好功能，自然多了许多无法掌控且不必要的功能；由于全程依赖大模型总结开发文档，只有在进度受阻时才查阅原文，很自然就不知道很多 Best Practice；至于过多 log 和混乱的 try-catch 就是处理各种无法控制的 BUG 频多的代码所遗留下来的。
---
我无疑走了弯路。但鉴于这是我第一次在工作上写 python 项目，且是单兵作战，且该大项目的要求确实挺多的。我挺怀疑有没有更好更快速的成长方法？（不过多看文档原文、多看别人的实现方案，这总归没错的）
有感于: The Programmer Identity Crisis #自说自话
