如何退后一步，以崭新的眼光看代码？[关闭]

去年，我以一个人的团队工作，开发了一个富客户端应用程序（价值35,000多个LoC）。目前处于稳定状态并已投入生产。但是，我知道我的技能在项目开始之初就生锈了，因此毫无疑问，代码中存在重大问题。在这一点上，大多数问题都在架构，结构和交互方面-容易的问题，甚至是架构/设计问题，已经被淘汰。

不幸的是，我在这个项目上花费了很多时间，以至于我难以思考它之外的问题-从一个新的角度来处理它，以查看深层掩盖或固有于设计中的缺陷。

我该如何超越自己的头脑和代码范围，以使外观焕然一新并变得更好？

解决方法：

• 找到一个熟悉技术和业务问题的人，并进行讨论。在单人团队中这可能很难，但通常是最佳选择。
• 在另一个项目上工作一段时间。这也可能很困难，但是即使休息一周也可以给您一个全新的视角。
• 查看类似的项目或产品，例如开源产品（如果有）。注意不要复制代码，但是他们可能完全不同地对待这个想法。
• 学习新的语言，库或框架。所涉及的技术可以使您洞悉如何处理不同的相同问题。
• 阅读有关设计或语言/框架的好书/博客/杂志。我不确定您的技能水平，但是此站点上的其他答案中有很多替代方法。

如果您有要解决的特定示例，则可以在此处发布。

橡皮鸭调试：坐下来编写一段代码或模块或功能，然后大声解释。当您发现自己说的话听起来有些错误，愚蠢或不正确时，请将其写下来作为调查的问题。

继续学习并扩大技能。很难知道您不知道什么，但是当您看到它时，那个“啊哈”时刻将打击您。它可能来自学习另一种语言或设计模式。

您将被要求进行更改。您可能会发现代码中的某些部分不够灵活，需要大量的返工。这不一定是失败的，因为您一开始无法想到一切。

用户将开始抱怨。就在您认为一切都很好的时候...

记忆力短会有所帮助。众所周知，我抱怨一个星期前改变了某些东西的“白痴”，但从源代码控制中才发现是我。

好的第一步是确定可以改进的代码。在源代码管理中查找最经常更改的文件。哪个代码最难使用？哪个代码产生最多的错误？哪些更改会在整个代码中引起连锁反应？在这个阶段，你不必知道为什么代码是麻烦的，只是说这是麻烦的。

确定要处理的区域后，请尝试找出问题所在。有些书采用系统的方法对设计问题进行分类。看一下Martin Fowler的Refactoring，Herb Sutter的C ++编码标准，Robert Martin的Clean Code等。它们有很多“规则”，可让您客观地查看代码。

确定可能的问题后，请尝试其他解决方法。例如，如果您违反的规则是“优先考虑合成而不是继承”，则将其更改为合成，然后看看它的感觉。

显然，它可以帮助让别人看代码，但它并不总是像你想象的那么有用，因为你是多少比较熟悉的各种问题的代码导致比谁，设计背后的原因。学习一些客观地评估自己设计的方法将大有裨益。

让其他人查看您的代码。如果找不到其他人看，请像完整的交互描述一样，将其展示给其他人。尝试向其他人解释您的决定的过程（即使只是为了实践）也可以帮助您真正地思考为什么要以某种方式做事，并帮助您发现逻辑上的任何漏洞。

我非常了解这种情况。当我陷入这种困境时，我会尝试对项目采取不同的观点。

1.）用户/客户的观点-使用反馈

不幸的是，由于无法使用我们自己的缺陷，因此我们无法看到自己的缺陷，因为我们以编码方式使用应用程序。查看人们如何使用它，并尝试找出最直观的用户指南。尝试UI原型。这似乎很有趣，但是如果您发现仅通过更改用法逻辑就被迫重新编码大量代码，则是时候开始重新设计周期了。

2.）对代码进行功能分析并将其可视化

一些IDE和框架会促使您例如将UI和后端代码混合在一起。如果您让这种情况发生，那么总有一天会遇到这样的情况，即由于模糊和难以破解的依赖关系，很难维护您的代码库。特别是将UI代码与其他代码混合会导致意大利面条式代码和冗余功能。将您的代码划分为功能块，例如数据库类，通信类，UI类，核心类等，并为功能块指定名称。然后使用图形工具（我使用思维导图工具）对功能进行可视化，以查明您的结构是否足够逻辑和模块化，从而可以将巨大的代码块用于不同的项目，并且可以用较新的版本替换它们而无需大痛苦。

根据我的经验，执行此操作的最佳方法是创建一个文档，以可视化您的类及其从代码中调用之间的所有依赖关系。结果是界面设计的可视化。如果此代码映射看起来像一个完整的集群，那么该采取行动了。如果还没有发生，那么您应该考虑一种合适的命名约定，以一种无需考虑如何调用以及如何执行的方式来表示代码结构。

3.）使用通用方法进行质量保证

我最喜欢的是FMEA。在编码方面，这不仅意味着要分析过去出错的地方，而且还要考虑可能出错的地方。一个非常常见的示例是突然断开的网络连接。完成此操作后，您可以根据数据丢失，崩溃，错误计算等后果对错误条件进行分类，并判断对用户的影响。如果尚未定义精简的错误和异常类以及例程，则可以帮助您保持代码整洁而直接。最好的方法是，在开始编写任何其他代码之前，以每一种新的代码实现这些代码。（嗯，我并不总是自己听从这个建议。）

此外，它还帮助我为自己的代码生成并经常更新“改进建议列表”。（老实说，我的项目中仍然有很多代码令我感到骄傲。）我还尝试花一些时间来收集并阅读API文档，开发者大会或开发者杂志中的最佳实践代码。

在此之前，无需触摸您的代码。只是要了解出了什么问题并找到定义如何改进代码的方法。

最后，从旧屁上讲一些日常工作的小窍门。尽量避免吃太多东西。这会给清洁编码带来太大压力。您很少有时间做正确的事，但是之后您将必须花些时间来修复缺陷。

没有什么比临时解决方案长久的了，但是当临时解决方案崩溃时，及时修复它通常为时已晚。例子是令人讨厌的hack或奇怪的异常，尽管例如底层框架或OS中存在缺陷，但我曾经使它们起作用。然后修复漏洞或新版本只需删除API ...

如果您陷入困境并被迫寻找解决方法，则可以发表评论并做笔记，并应不时进行审查。通常，由于学习新知识，我们会变得越来越好。如果您找到了更好的方法，请尽快实施。否则，您可能会发现自己为变通办法编码了，并且有一天会例外。（在你们中间没有罪的那人，让他向我扔第一字节。）

不要汗流stuff背。

每个人都可以编写更好的代码。我们可以快速完成工作，然后在几周后意识到可以更高效地完成工作。关键是90％的代码可能已经足够好了。

查看您的错误日志，找到可能引起问题的例程。找到错误后，您还可以查看代码并考虑可能会使代码更高效的原因。大多数时候，您会意识到，除了修复bug本身之外，您将无法做出明显的改进，但是有时，您会意识到有更好的方法来做某事。

与用户交谈，查看他们在哪里注意到问题，即UX或速度问题。解决这些问题，着眼于尝试改进您的代码。

在某些时候，您会发现您的代码变得过于脆弱，根本无法进行所需的更改。然后考虑如何通过API或测试驱动的开发使系统更加灵活。在许多情况下，您会发现无需进行大量更改就可以直接将这些API放入代码中。在其他情况下，您会意识到改进代码的努力是不值得的。

增量更改可能很难。目的是不必完全重写代码库。当然，与一年前相比，现在您是一名更好的程序员，但是您必须立即开始工作。从现在开始的5年后，当一个初级程序员向您抱怨遗留代码时，他们不得不尝试解决，只是微笑并点头，却不承认您编写了该代码。

您是否考虑过离开并找到可以加入团队的公司？我非常感到孤零零或处于停滞状态，开发人员错过了该专业所提供的很多东西。

同行评审可以让已经不在您脑海中的人提供您的建议。堆栈交换代码审阅可能是个不错的地方，可以将一些不是您公司专有的代码进行审阅。它可能无法处理巨大的块，但是许多程序是由许多简单的代码组成的，而其他一些不是很简单的代码则构成了很多问题。如果您有一些典型的代码示例，但是在许多地方重复并更改了它，那么它也可能是一个很好的复习对象。例如，如果您格式化消息，则不要要求审查所有已通过的消息，而只是要求其中一个相当复杂的示例消息。

如果您想对自己的代码更加客观，我想您可以将其与编码标准进行比较，在其上运行静态或动态代码检查器，或者如果文档稀疏，则添加注释可能会有所帮助。

有一种测试心理使得很难测试您自己的代码，但是我们当然会在单元测试中尽力做到这一点。读取自己的代码可能是一个相似的或更糟糕的问题。许多领域都使用导师，竞争性裁判，教练等。如果您算架构师，系统工程师和测试人员，我们也会这样做。一旦产品投入使用，有权访问错误报告工具或客户支持部门的客户就会从您的脑海中为您提供反馈。这是敏捷早期和经常发布的方法的另一个重要原因。您可能是公司的唯一开发人员，但是有些人受到您的代码的影响，可以从某种角度为您提供有关它的反馈。

“这是比我想象的要小的问题，还是其他人也遇到的问题？”

嘘。已经足够。如果代码正在生产中，没有错误并且可以执行应做的工作，那么体系结构就不重要了。至少现在（是。

希望我们所有人都能学到东西。我写了很多代码，令我为之骄傲，只是一两年后才发现这很糟糕。现在，我正在一个多年项目中，其中充满了难以置信的代码，但是这些代码有效。我正在采取一种非常保守的方式来接触任何一种方式。

您也应该如此。如果您在经过一年的工作之后现在没有发现任何重大的体系结构问题，那么我认为现在就可以假设没有重要的问题是安全的。这不是坏工艺。它正在前进。

除了其他答案，我建议您参加开发者大会。

这将使您接触到很多主题和人员，这会让您考虑自己的应用程序和工作场所。特别是因为他们将谈论什么是可行的，而不是当时可行的，以及即将出现的问题。您的应用很可能存在一些重叠。

最好花3天。我发现它足够长，可以与我自己的工作保持必要的精神距离，并可以通过一个更大的社区（可以这么说）而不是我自己的视野来观察它。

顺便说一句，这也适用于团队成员，因为集体思考可以发生在任何地方。

最后，如果您没有为此获得批准，例如每年一次，请换工作。

• 实践设计模式和最佳实践
• 根据您的应用程序需求和需求选择框架，工具，软件包等-为此，您需要阅读大量的etch博客并找到针对每个技术问题的解决方案
• 创建设计/架构草案，并与擅长技术/建筑方面的人员进行讨论。使用反馈和评论来完善该草案。继续这样做，直到达到稳定状态。

• 实施代码，使应用程序所需的一切都可以配置和维护

  重新架构和重新实现您的项目肯定会导致应用程序具有更好的一致性，性能等。

我相信与一些聪明的人“解决”问题会有所帮助。需要特定的信息。是24x7x365的网站吗？LoB应用程序？它在哪里运行或托管？

一旦您达到了核心目标和期望的结果，其他人就可以帮助您集中注意力并引导您的注意力。您的代码可能是针对一项特定任务编写的最好的代码，也可能是最糟糕的代码。真的没关系-对预期目标有何影响？