鹅厂，有个帖子是《写代码陷入完美主义陷阱怎么办》。但是当你要设计一个稍微大一点的项目，或者接手一个比较新的代码，想适当的做一些大的重构的时候，你总觉得这个不好，那个不好，怎么做会有一些缺陷，很难写。虽然可以合理拆分成几个模块，但是我还是很纠结每个模块的代码怎么写，然后总觉得思路不够清晰，一直没有想好怎么继续调整。写出不理想的结构后，这个过程虽然有思考，但也有明显的局限性，也导致效率下降。求教：如何提高编码能力，如何克服追求完美带来的低效率。这大概是很多技术同学都想知道的问题，那么如何解决这个问题呢？我们总结了鹅厂程序员的方法：1、在写代码的同时，不断想@Raymond。看到问题更有同理心，因为我记得我也有过这样的经历。可能是我对“代码完美主义”心有余悸吧。当我写完我的一本书《Python 编程进阶相关》时，我特意在最后留了一页，写道：>在这本书的最后，我想多说几句。>虽然这本书从头到尾都在讲“如何写出更好的Python代码”，但最后我还是要提醒你：不要陷入完美主义的陷阱。因为写代码不是纯粹的艺术创作，完美的代码是不存在的。有时候代码只要满足当前的需求就足够了，并且为未来的扩展留有余地。“完美主义”怎么会有害呢？主要原因是当我们面对大型任务时（比如你提到的“设计大型项目”和“大型重构”），脑海中盘旋着太多的想法和声音，每一个都是对的。我们说：“这是保证您以后安全的最好方法！”。被他们包围着，我们花了很多时间纠结，然后无论做出哪个选择，似乎都“不够好”——不仅效率受到影响，心理也很不舒服。摆脱“完美主义”负面影响的最简单方法就是无视它：继续写代码，继续奋斗。当你把一件事重复的次数足够多时，那些宝贵的经验自然会让你跳出“完美主义”，不再挣扎。除了放下“完美主义”，另一个行之有效的方法就是“测试驱动开发（TDD）”。采用TDD后，你可以在设计者（编写测试时）和实施者（编写代码时）两个角色之间更平滑地转换。不同的角色可以有效地为你的思维“设限”，让你的思路更清晰，从而打磨出更好的设计。此外，TDD对于克服“完美主义”还有以下优势：编写测试本身有助于编写耦合更低、结构更好的代码，当你纠结于代码的质量时更接近“完美”当你在工作时，单元测试会像旁观者一样告诉你：“代码没问题，别纠结了”。当你发现旧的设计有问题，想要重构时，单元测试也会辅助你追求“完美”。最终，“完美主义”虽然有一些弊端，但也要适度追求完美。反之，如果你在写代码的时候从不挣扎，那么关于代码的最高指导思想就四个字：“能跑多久就跑多久”，这也是很可怕的。@盖东。大多数好的设计都不是一蹴而就的，而是逐渐演变而来的，除非要处理的场景在我们的经验范围内。大致的路线可能是：先了解清楚业务需求，调研行业类似场景的解决方案。如果有解决方案，那么这个设计一般都是从别人那里进化了很多轮，结合自身场景的特殊性适配使用现场的解决方案就可以了。如果没有解决方案，首先要兴奋起来，因为你所做的很可能是创新的，或者至少是微创新的。这时候，先设计一个版本来运行系统，然后在后续的迭代中逐步优化是可以理解的。在上述过程中，方案的研究可能是一个关键环节，就像写论文中的评论部分一样。2.给代码一个进化过程@Aproom。当你接到一个完整的需求或者接手一个现有项目的代码时，这种情况会出现两个问题：第一，大量的需求并不意味着你和需求者有一点商量和磨合就来了没有经过长期的需求分析和讨论，对需求的理解不够深入。第二，当所有的需求都知道的时候，你尽量一次设计一个完整的结构和框架，而不像一个新项目先设计一个简单但灵活的框架，然后随着需求的增长不断调整设计和重新设计。同时，对需求的理解也更加深刻。我称之为“给代码一个成长和发展的过程”或者“给代码一个进化的过程”。一步设计出完美的架构是不可能的。编程最大的技巧就是无限深入需求，不断思考需求，让代码从小到大不断开发重构。当然很多时候客观条件是不允许的，所以放过完美的代码的持久化。顺便说一句，我反对大多数代码重构的原因是：大多数重构者都是刚接触项目的新手，重构的理由有时是“我有空有时间”，或者对以前的设计不满意。但是他们缺少重构最重要的条件，就是对需求的理解比以前更深刻，以及和需求一起努力的决心。@泽林。引用React官网的一段话，也是我陷入类似情况时的破局之道——不要想太多。如果您刚刚开始一个项目，选择项目文件组织的时间不要超过五分钟。选择任何模板结构（或想出你自己的）并开始编码。因为，在您编写了一些实际代码之后，您很有可能会重新考虑它。如果您觉得完全卡住了，请先将所有文件保存在同一个文件夹中。它最终会变得足够大，以至于您想将其中一些文件拆分出来。到那时，您将有足够的知识来区分您最常编辑的文件。通常，将经常一起更改的文件组合在一起是个好主意。这个原则被称为“托管”。随着项目规模的增长，混合和匹配方法是一种常见的做法。因此，选择“正确”的开始方式并不是很重要。3.“足够好”并不意味着糟糕的代码@Luxx。正如爱德华·尤登在《IEEE 软件》杂志上的一篇文章中所说的《够好即可的软件就是最好的》：你可以训练自己编写足够好的软件——对用户、未来的维护者来说足够好，只要它足够好让你自己安心。您会发现您的工作效率更高，您的用户也更快乐。而且，可能是为了让你更快乐，更短的潜伏期实际上让你的程序更好。在进一步讨论之前，我们需要对将要讨论的内容进行一些限制。“足够好”这个短语并不意味着草率或糟糕的代码。除非满足用户的需求，并且需要满足基本的性能、隐私和安全标准，否则任何系统都是不完整的。从用户需求的角度来看，你做的是否足够好？最好给用户一个亲自参与判断的机会。今天的好软件通常比想象中的明天的理想软件更受欢迎。如果您尽早为用户提供一些可以玩的东西，他们的反馈通常可以带来更好的最终解决方案。——《程序员修炼之道》第51页话题12：tracer的作者KentBeck@Xiaoning.《重构》有一句“两顶帽子”的说法我觉得很有道理：软件开发过程应该有两顶帽子，一个是开发新功能的帽子，一个是重构的帽子。简单来说，发帖者要加一个功能，先写功能，不管实现是否美观；然后切换到重构帽并对其进行优化。请注意，这两顶帽子是不断快速切换的。这并不意味着您可以一次编写一个大模块然后重构它。这是不可接受的。许多作家的写作方式大同小异。我认为这非常有用。但在实践中，还存在很多其他的问题，比如一开始选的不好，后期改不好，写完了很难重构，选后选的不好等等。我想这些都可以通过经验来解决。如果你很熟练，你应该可以放心地去做。作为一名菜鸟，我的经验还不够，希望有一天我能自信起来。@骗子。分享一下我的看法：（1）因为“设计一个稍微大一点的项目，或者接手一个比较新的代码”是一个openquestion，一个比较抽象的问题。“写代码和设计的能力不弱”足以“维护老项目，对需求做一些改动”，有清晰具体的依赖边界。解决抽象问题，还需要“分析问题的能力”，“创新能力”——解决新问题。(2)要理解好新问题，需要给自己时间去思考和分析问题。不要急于编写第一行代码。(3)我们不应该从头发明看似简单的“牛顿经典力学”。初中生通过课本学习即可掌握。自己想一辈子可能还不够。因此，面对新的问题，首先要考察其他人是否遇到过，积累了哪些思想、做法和认知。(4)工程师能力的提升是解决越来越多的边界不清晰、依赖关系不明确、依赖关系多的抽象问题。比如极其抽象的，spaceX项目。
