陷入了写代码的完美主义陷阱怎么办？

　　＂如何提升代码能力，以及如何克服这种又菜又想追求完美导致低效的问题呢？我们总结了鹅厂程序员们的方法。＂
　　鹅厂内部，有一个关于＂陷入了写代码的完美主义陷阱怎么办＂的帖子，题主是这样写的：
　　自认为代码编写和设计能力不弱，一般的代码逻辑也比较清晰。但是当要设计一个略大的项目，或者接手一个相对较新的代码，想要适当地做一些较大的重构的时候，就总是会感觉这样也不好，那样也不好，怎么做都会有一些缺陷，难以下笔。虽然能合理地拆分成几个模块，但是对每个模块的代码怎么写还是十分纠结，然后总觉得自己还是思路不够清晰，没有想清楚怎么继续调整，空耗了一些时间，最后还是以一个自己不满意的结构写完，这个过程中虽然有思考，但是有明显的局限，也导致效率有下降。
　　求教：如何提升代码能力，以及如何克服这种又菜又想追求完美导致低效的问题。
　　这大概是很多技术同学都想了解的问题，那么如何解决这个问题呢?我们总结了鹅厂程序员们的方法： 1. 一边写代码，一边继续思考@A生.
　　看到问题比较能感同身受，因为我记得自己有一个阶段也是这样。可能是对＂代码完美主义＂心有余悸，我在写完自己的书《Python 编程进阶相关》时，还特意在结尾时留了一页，这么写道：
　　> 本书的最后，我想额外啰唆几句。
　　> 虽然本书自始至终都在说＂如何把 Python 代码写得更好＂这件事，但我还是希望最后提醒你一句:不要掉进完美主义的陷阱。因为写代码不是什么纯粹的艺术创作，完美的代码是不存在的。有时，代码只要能满足当前需求，又为未来扩展留了空间就足够了。
　　＂完美主义＂如何产生危害？主要在于当我们面对规模较大的任务时(比如你提到的＂设计大项目＂、＂较大的重构＂)，盘旋在脑海里的想法和声音太多了，每一个都在对我们说：＂这样做最好，能保你之后万事无忧！＂。在它们的包围中，我们先是花了大量时间纠结，之后无论做出哪种选择，似乎都＂不够好＂——不仅效率受到影响，心理上也十分难受。
　　要从＂完美主义＂的消极影响里走出来，最简单的办法就是不管它：继续写代码，继续纠结。当你重复做一件事情足够多次以后，那些宝贵的经验会自然而然地让你跳出＂完美主义＂，不再纠结。
　　除了放任＂完美主义＂不管之外，另一个行之有效的办法则是＂测试驱动开发(TDD)＂。采用 TDD 后，你能更流畅地在两种角色之间转换：设计者(编写测试时)和实现者(编写代码时)。不同的角色能有效为你的思维＂设限＂，让你更清晰地思考，从而打磨出更好的设计。
　　除此之外，TDD 对于克服＂完美主义＂还有以下优势： 编写测试本身就有助于写出耦合更低、结构更优良、更趋近于＂完美＂的代码 当你纠结于代码好坏时，单元测试会像一位旁观者一样告诉你：＂代码没毛病，别瞎纠结。＂ 当你发现旧设计有问题，想重构时，单元测试也会辅助你在追求＂完美＂的路上万无一失
　　最后，＂完美主义＂虽然有一些坏处，但适度追求完美也是必要的。反过来说，如果大家写代码时从不纠结，关于代码的最高指导思想就四个字：＂能跑就行＂，这样也很可怕吧。 @B生.
　　绝大多数好的设计不是一蹴而就的，而是逐步演进出来的，除非要应对的场景本身就在我们的经验范围之内。
　　大致路线可能是：先理解清楚业务需求，调研业界类似场景的解决方案。如果有解决方案，那这个设计一般已经是在别人那里演进过多轮了，结合自身场景的特殊性，加以适配使用现场的方案即可。如果没有解决方案，那首先应该感到兴奋，因为你正在做的事情很可能是在创新或者至少是微创新。这时候先设计一个版本把系统跑起来，后续迭代中再逐步去优化也是无可厚非的。
　　上述过程中，可能方案调研是一个关键环节了，就像写论文中的综述部分。 2. 给代码一个进化的过程@C生.
　　当接到完整的需求或者接手已有项目的代码，这种情况会存在两个问题:
　　一是大量需求并不是你和需求提出者一点点讨论、磨合出来的，没有经过长时间的需求分析、讨论，对需求的理解不够深刻。
　　二是在全部需求都已知的情况下你试图一下子设计一套完整的结构、框架，不像新项目先设计一个简单但灵活的框架，然后随着需求的滚动增长不断调整设计、不断重构，同时也对需求理解更加深刻，我管这个叫做＂给代码一个生长、发育的过程＂或者＂给代码一个进化的过程＂。
　　想一步到位设计出完美的架构是不可能的，编程最大的技巧就是无限深入需求，不断思考需求，让代码从小到大不断发展、重构，当然很多时候客观条件不允许，那就放下对完美代码的执着吧。
　　顺便说一句，我反对大部分代码重构的原因是：大部分重构人只是新接触一个项目，重构的理由有时是＂我比较闲、有时间＂，或者对之前的设计感到不舒服。但他们缺乏重构的最重要条件，就是对需求比以前更加深刻地理解，和需求摸爬滚打在一起的决心。 @D生.
　　引用 React 官网的一段话，也作为我陷入类似情况的一个破局之道——不要过度思考。
　　如果你刚刚开始一个项目，不要花超过五分钟在选择项目文件组织结构上。选择任何一种模版结构(或提出自己的方式)并开始编写代码。因为，在你编写了一些真正的代码之后，你将很有可能会重新考虑它。
　　如果您感觉完全卡住，请先将所有文件保存在同一个文件夹中。它最终会变得足够大，以至于让你想要将其中一些文件拆分出去。到那时，你将有足够的知识去区分你最频繁编辑的文件。通常，将经常一起变化的文件组织在一起是个好主意。这个原则被称为 ＂colocation＂。
　　随着项目规模的扩大，人们通常会在实践中混搭使用各种方式。因此，在开始时选择＂正确＂的那个方式并不是很重要。 3. ＂够好即可＂不意味着糟糕的代码@E生.
　　如《IEEE 软件》杂志上一篇由爱德华·尤登写的文章《够好即可的软件就是最好的》所述：
　　你能训练自己写出够好即可的软件——对用户、未来的维护者来说够好即可，只要好的程度能让你自己内心平静就可以。你会发现，你变得更有效率，用户也更快乐。而且，可能让你更开心的是，更短的孵化期促使你的程序实际上更好了。
　　在进一步讨论之前，我们需要对将要讨论的内容做一些限定。＂够好即可＂这个词并不意味着草率或糟糕的代码。所有系统必须达到用户的需求才算完成，需要达到基本的性能、隐私和安全标准。你做的东西，从用户需求角度来说是否足够好?最好还是留给用户一个机会，让他们能亲自参与评判。
　　与构想中的明天那个完美的软件相比，今天就还不错的软件通常更讨人喜欢。如果你早点给用户一点东西玩，他们的反馈常常能引领你做出更好的最终方案。
　　—— 《程序员修炼之道》 第 51 页 话题 12：曳光弹 @F生.
　　《重构》的作者Kent Beck的有个＂两顶帽子＂说法我觉得很有道理：就是软件开发的过程应该有两顶帽子换着戴，一顶是开发新功能的帽子，一顶是重构的帽子。
　　简单来说，就是楼主想添加新功能时，先不管实现是否优美，先把功能给写了;然后再切换成重构帽子，把它优化一下。注意，这两顶帽子是不断快速切换的，不是说你一下子写完好大一个模块再重构它，那是不行的。很多作家写作时大体也和这差不多。
　　我觉得挺好用的。但是实践中也有很多别的问题，比如开始选得不好后面不好改啊，写出来难得重构啦，选来选去也选不好啊等等。我觉得这些可以靠经验解决啦，如果很熟练的话就应该就能做到胸有成竹了。作为一个小菜鸡，我还不够有经验，我希望我有一天能做到胸有成竹。 @H生.
　　分享一下我的见解：
　　(1) 因为＂设计一个略大的项目，或者接手一个相对较新的代码＂是一个开放性的问题，较为抽象的问题。＂代码编写和设计能力不弱＂对于＂维护老的项目，做一些需求的改动＂这种依赖边界清晰的、具体的问题是足够的。要解决抽象的问题，还需要‘分析问题的能力’，以及‘创新能力’--解决新问题。
　　(2) 要能很好地认识新问题，你需要给自己时间思考、分析问题。不要急于写下第一行代码。
　　(3) 我们不要从头发明看似简单的‘牛顿经典力学’，从课本里学习，初中生就能掌握，自己去思考，可能一辈子也不够。所以，面对新问题，我们首先要去调查其他人遇到过么，积累了哪些思考、实践、认知。
　　(4) 工程师的能力的提升，就是解决越来越抽象的、边界不清晰的、依赖不清楚的、依赖众多的问题。比如，极度抽象的，spaceX项目。