作为唯一开发人员工作：查看代码

我别无选择，只能独自工作，无法找到适当的解决方案来检查我的工作，进行理智检查，找人集思广益，讨论最佳做法等。

我以为我会通过Jeff Atwood的文章得到答案：在《编程》中，“一个是最孤独的数字”，这是我在该主题上能找到的最好的答案，但事实只是重申了我的问题。

我知道像这样的Stack Exchange网站和Code Review是一个明显的潜在答案，但正如许多人所欣赏的那样，这是理想的FAR：

虽然我无法列出所有陷阱，但经常提出一个问题并将其装箱成一个独立的问题通常需要花费大量的工作，以至于在您充分准备好它之后，您已经在更大程度上回答了自己的问题。时间比其他时间要多。同样，隐藏细节以提出明确的问题，也消除了有人发现您未曾想到的问题的可能性。另外，尽管我不能完全动手，但我能想到的任何形式的文本互联网讨论都无法与自由对话的响应能力相提并论。最后但并非最不重要的一点是，出于明显的原因，我不想将我的整个项目发布给全世界，让人们永生不衰。

除了付钱给顾问查看我的代码之外，还有其他答案吗？

我一直在你的鞋子里，我认为没有任何简单的解决方案。付钱给顾问查看代码不是花钱的好方法。如果您的问题是您感到孤独，并且没有人可以谈论编程，那么我无济于事，但是如果您真的对提高代码质量感兴趣，那么最好的方法就是设置代码放在一边，然后在一周左右的时间内恢复原状。如果代码确实很糟糕，那么它将很明显，因为您将无法对其进行任何理解，并且可以开始对其进行重构以使其具有意义。经过几次此过程的迭代，您将开始注意到使代码易于理解的代码模式，并且代码质量将得到改善。

除了付钱给顾问查看我的代码之外，还有其他答案吗？

没有。

我的建议是加入一个本地开发人员\用户组，并与他人讨论您的想法。谈论您的设计。询问其他人他们如何解决某些问题。

如果他们验证了您的设计，即使不看您的代码，也就足够了。

有诸如检查驱动开发之类的自检技术可以帮助提供反馈。当变得很难做时，您就会知道您的体系结构可能会过时。

提出一个问题并将其装箱成一个独立的问题通常需要花费大量的工作，以至于在您准备充分的时间之前，与其他情况相比，您回答自己的问题的时间就更多了。

问题解决了。您不需要对每一行代码都进行外部反馈即可进行改进，只需对道路上的关键分支进行一次良好的采样，并在中间的各个点进行仔细的自检即可。

您必须克服这样的想法，即与团队中的某人一起工作可以在相同的时间内保持相同水平的质量。人们在团队中工作是有原因的。好消息是您在设计决策上没有冲突。坏消息是您在设计决策上没有矛盾。希望您花费在保持质量上的额外时间可以被单独工作的优势所抵消。

我建议在会议和本地用户组中进行尽可能多的联网。我知道很多开发人员总是通过电子邮件或即时通讯来回拍摄经过清理的代码片段，以保持敏锐的眼光并一起研究算法。不，这不是面对面的对话，是的，有时清理代码是很痛苦的，但是不时查看20条即时消息传递者代码可能非常有用，尤其是当您急于要第二双眼睛时。

我处于类似的情况，我严重依赖Stack Overflow来获取有关粗糙问题的反馈。我还发现，由于实际上必须写下问题的描述，答案常常变得显而易见。在最佳实践方面，我是.Net开发人员，我使用ReSharper，它将为我编写的代码提供良好实践替代方法的建议（有时我会忽略它-可能有些花哨）。另一个有用的工具是FxCop，它将进行静态代码分析并突出显示任何不符合其规则集的问题。

否则，您需要阅读并保持最新做法。我喜欢Alvin Ashcraft的《晨露》，链接到.Net世界中的新功能和新功能。

我建议尝试创建（或找到）一个小的用户组。使您的代码可用，并使每个人都致力于使它正常工作-每天半小时或更长时间。

从我的经验中得出的建设性反馈是，在开发的最初几年中，有经验的开发人员查看您的代码以奠定基础是非常重要的，尽管不是强制性的。一旦您有经验，就可以遵循@ davidk01建议的方法，即定期检查自己的代码以提高代码质量。

我不知道你的情况的细节，但是我现在在哪里，那里有很多渴望有经验的学生，他们非常乐意作为实习生并学习一些东西。

您可能需要额外的工作来处理它们并教他们这些知识，但是当我们刚开始时我们就一直在那儿，我想现在该轮到您偿还了。

他们不是专家，有时甚至会误导您，但通常他们会挑战一切并且充满想法，非常适合在讨论中您必须捍卫代码的每个细节。

虽然我无法列出所有陷阱，但经常提出一个问题并将其装箱成一个独立的问题通常需要花费大量的工作，以至于在您充分准备好它之后，您已经在更大程度上回答了自己的问题。时间比其他时间要多。

在我发布的> 75％的问题中，我也遇到了同样的情况。

但是，这不是不愿意这样做的理由。这实际上是橡皮鸭调试。你找到问题的答案，你认为可能会在针对您的问题冒出来; 这意味着您正在从不同的角度考虑问题；这意味着您正在从所有可能的方向考虑问题；这是发现缺陷的最佳方法。

充其量，您已经明确证明了您显然无法想到这里的答案。在“最差”时，您最终会回答自己的问题。注意引号，因为这一点都不好。可能时间上效率不高，但是慢解决问题比快速决定不解决问题要好。最终您会更快地解决问题。

例子：

当我还是一个刚起步的开发人员时，我经常处理ASP.Net错误页面。我需要在Google上找到消息，以找出问题所在。我可能需要几个小时才能找到正确的解决方案。我基本上在书中犯了每个错误，随后不得不处理必须调试问题的后果。

现在，当错误弹出时，我已经知道可能引起此问题的“常见嫌疑人”。我对“通常的嫌疑犯”的心理清单有效地基于我在职业生涯中遇到最多的问题。如果没有先完成谷歌搜索所花费的时间而浪费时间的腿部工作，我将永远不会列出这份头脑清单。但是，既然有了该清单，就可以更快地进行故障排除。

另外，尽管我不能完全动手，但我能想到的任何形式的文本互联网讨论都无法与自由对话的响应能力相提并论。

我在这里有些不同意。您认为互联网通信的响应速度较慢是正确的，但是（我认为）您认为这对您不利是错误的。

作为单独的开发人员，您将依赖橡皮鸭调试。使RDD起作用的关键因素是您预料到橡皮鸭可能会给您带来的问题。您显然不能依靠橡皮鸭的真实话语。

在处理慢速消息传递系统时（在StackOverflow上发布消息或通过写信进行交流），您会受到内在的激励，以确保您第一次就能正确使用它。因为需要纠正错误将是一个缓慢而艰巨的过程。
相比之下，考虑到快速消息传递系统（对话，即时消息传递），您可以立即更正某些问题。快速纠正某项错误的能力使人们减少了确保正确的动机。

有四种情况：

• 当我以开发人员的身份创建自己的个人分析/待办事项列表时，我仍然会使用笔和纸。我注意到在键入笔记时，我会掩盖假设和错误，因为我的想法是“以后我可以轻松解决此问题”。但是，必须纠正您在纸上写的东西很烦人，您需要把事情弄清楚并在各行之间写，而文档上面有文字时看起来会糟得多。在纸上写东西使我在致力于写纸之前先进行事实核查。在我什至没有编写会产生错误的代码之前，这就很早就引起了很多误解。
• 我的祖母是秘书（打字机年龄）。在正式文档中打错字意味着必须再次键入整个页面。我的姨妈是秘书（文字处理机的年龄）。她可以依靠自动拼写检查器，并且可以轻松，轻松地解决错误。毫不奇怪，与姑姑相比，祖母的打字错误和拼写错误要少得多。
• 视频游戏曾经被打印在墨盒上。发布后修复错误几乎是不可能的。您需要重新打印所有墨盒，再将其分发给所有供应商，并希望这些供应商能够以某种方式与已经购买游戏的客户取得联系。这将花费大量金钱（实际生产成本的两倍），并且仍无法覆盖某些客户。现在，在互联网补丁时代，游戏开发人员已显示出在测试游戏方面的投入大大减少，因此他们可以避免发布日错误，因为直接向每个客户推送修复程序要容易得多。错误的影响被最小化到一个事实，即与必须测试所有可能的问题相比，事后解决一些问题更好 可能发生的错误。
• 我曾经住在第三层的公寓里，没有电梯，而且不得不经常停在我建筑物的一两个街道上。我几乎从未忘记从车上取走东西。现在，我住在车道上紧挨着我的车子里。我忘了把东西从我的车所有的时间。

这里的基本思想是，一个困难的交流系统会激励人们进行正确且经过事实检验的交流。惩罚的严重性（=困难的更正过程）告诉您不要犯错误。

同样，隐藏细节以提出明确的问题，也消除了有人发现您未曾想到的问题的可能性。

制作MCVE时，您不应该只是创建它并将其发布到问题中。您首先应该自己动手做，以便可以隔离问题。然后，当您认为问题无法再解决时，您仍然看不到原因；那么您有一个关于StackOverflow的有效问题。

例子：

我总是有第二个Visual Studio与一个名为Sandbox的简单控制台应用程序一起运行。每当遇到技术问题时，我都会将有问题的代码复制到沙箱中并开始使用它。

• 更改此设置会怎样？
• 如果我缩短代码，可以重现该问题吗？
• 哪些设置可以/不可能重现该问题？

在90％的情况下，我发现了问题的原因，因为沙箱帮助我查看了有问题的代码，而不会被周围的环境所干扰（例如，代码不同部分的值存在任何不确定性）。

在其他10％的情况下，我只剩下最少的代码来重现此问题，这是可发布到StackOverflow上的完美示例代码段。

最后但并非最不重要的一点是，出于明显的原因，我不想将我的整个项目发布给全世界，让人们永生不衰。

当您已经拥有MCVE时，其中不应包含太多个人信息（或公司信息）。如果这样做，由于代码很少，因此很容易将事物重命名为更基本的foo / bar / baz示例。