“完美”陷阱

在混乱系统中，你永远分析不清楚。只有动手了才会真正理解。 —— 我自己说的

刚拿到项目的时候心比天高，什么垃圾东西，我要重构！实际就改的时候，我是什么垃圾，敢碰它？每一次改动都举步维艰，像是抽积木游戏的游戏，每一次都是提心吊胆。代码的分层，调度器的设计，状态机的设计，代码的管理，规格书的管理，通信协议的设计，重构的每一步都不是这么简单，越了解就越懂得原来代码能稳定工作实属不易。

我目前举步维艰，理论上应该学习前人经验，集众之所长，但是我之前的经验并不适用现在场景，只能重新开始摸爬滚打。

但是我猛然发现，我陷入这个状态好像太久了。在不断反复的思考和推演过程当中，陷入自我怀疑，感到无能为力和痛苦。“本来是一个团队该思考的事情，我操什么心？”，“客户又改需求了，先按照原来的方式改吧，优化的事情下次一定！”。开始了一种闻着臭还要硬吃的恶臭循环，内心是抗拒的但是却又举步不前。

1. “等我分析清楚再开始”

在复杂的系统中，永远无法在开始前就掌握全部信息，受限于项目节点、项目输入需求的变化。因为项目总是动态，其中的变量往往不是只有你一个人，硬件、市场、客户需求，随时都在改变，最初的假设总会出错。等待完美的规划本质是拖延和恐惧。

事实上也是如此，我也一直都是这么做的。因为初出茅庐，经验不足的很，大多时候我接手的东西对我来说都是全新的，我没法获得太多信息，因为我对他们一点也不了解。这样的化我只能从目的出发，拆解问题。把拆解的问题在当作目标，逐一击破。等我实际上做了大量的准备工作和尝试之后，才对这个项目的框架逐渐清晰起来，这个时候，我再整理出大致的方案，然后不断的实践和修改，最后才能出一版较为完整的方案来接受评审，在评审的过程中，又被发现存在很多缺陷和问题，只得再进行进一步的完善和优化。虽说这样只是把开发的工作提前，但对于一个新手小白来说只能这样去解决问题，最后既能输出交付资料，项目至少也能稳步推进。

所以，无论是代码，还是文章，先弄出一个可行的看得见摸得着的东西。尝试做一个丑陋可运行的版本出来再说！

2. “要做一个完整的方案”

要意识到完整是一个结果，而不是一个前提，他是在不断的迭代、修正后才形成的。在信息不足时追求一个完美可行的方案，只是妄想罢了。除非之前有充足的可行的实践经验可复用，不然也只是沙丘中的空中楼阁。

在设计时，我也参考了很多方案，虽然我之前的经验不足，但是网上的经验充沛，想着取取经。看的越多，越破碎。这里一点，哪里一点，这里好像可行，能为作为参考，哪里好像也不错。最后形成左右脑博弈，想象很美好，但是没有牢固的地基，产生不了实际的问题？自然就会生成千万种方法而形成内耗。实践是检验真理的唯一标准，适合自己的才是最好的！

所以，管他三七二十一，先写一版再说！写的时候问题自然会出现，这时再根据问题求解答案。

3. “这个小改动没什么用”

大刀破斧的改动，拿不定主意；而小改动又感觉杯水车薪。这是最致命的陷阱。对于想搞钱的大家复利应该并不陌生，今天的收益投入到明天的生产，再创造收益。复利效应的威力是相当强大的，每一个微小的、正向的改动都应该是一次复利。每一次的小改动，可以立即改善我的工作心情，因为我在行动，我在变好！通过动手，也能获得一些“隐形知识”。哪些空想的认为“本应该”如此的代码，其实说不定有着隐藏bug。当前的小改动也会为下一个改进打下坚实的基础。

因为我拿到手的代码很乱，我一直想重构但又不敢开始。后来，每天花半小时，整理和优化很小的函数，删除没有用的逻辑，规范代码。这样开始，我不仅仅对代码更清晰了，更理解了原来代码模块间的耦合关系，为后续重构积累信息。

所以，别再等待那个“完美的开始时刻”了。它永远不会来。真正的清晰，来自于行动中的反馈；完整的方案，诞生于一次次的迭代。

😤感觉自己又行了！