Question

我最近开始以开发人员身份工作，并在一位更高级的开发人员的指导下工作，他是一名监督/指导我的人。

他建议的很多事情似乎都不对。例如，他告诉我只是以程序的方式编写我的代码，忽略它的编写或整体设计的好坏，并让它工作。然后迭代地，它会随着时间的推移变得更好，随着时间的推移改进代码。

让我感到不舒服的是花时间在编码之前正确地考虑解决方案和实际问题，我觉得通过这种方式进行编码，最终会花更多的时间在这上面。不幸的是，我还没有能够通过第一次编写完美的代码来立即解决问题。

此外，他对记录代码感到皱眉，相信它应该说明一切。他认为每种方法顶部的简短评论应该足够了。再次，这似乎与我相反。

总而言之，我觉得我现在正在编写真正的hacky代码，以便能够正常运行。他是否正确，这是整个行业的事情吗？

Answer 1

我会在这里走出困境并建议你可能会误解高级开发人员告诉你的内容。 “只是让它工作”，“代码应该为自己说话”是相互排斥的。如果我们假设这个人确实知道他在做什么，那么让我提供几个不同的解释：

新开发人员很容易迷失在通过正确的方式来设计软件的杂草中。这是一种分析瘫痪。他可能希望你快速深入研究代码，这样你就可以实际写出一些东西，然后你很快发现什么效果不好。这听起来像是他让你早早失败而且经常是为了学习。
许多新开发人员大量使用无用的评论。他要求你编写自我记录的代码，而不是hacky和令人困惑的代码。如果您只允许在函数顶部进行简短注释，则必须使用明确的变量名称和简单直接的算法来使代码有意义。这是一件好事。

与导师坐下来澄清他告诉你的内容并没有错。你确实有有效的顾虑。不要犹豫，向他询问更多信息。它表现出自信和自我思考的能力。优秀的员工不是精神错乱的机器人。

Answer 2

另外，他对记录代码感到皱眉，相信它应该代表本身。

这几乎是我需要阅读的全部内容。这个人真的不知道编写可维护代码需要什么。

话虽如此，这个人显然是你的导师/主管，所以你不能只说“嘿，这是愚蠢的”，你必须巧妙地做到这一点。

但不记录代码，因为它“应该说明一切”是一种灾难。你应该注意编写清晰，有效和高效的代码。 做一些正确的事情总比在黑暗中完成任务更好，而且从现在起6个月后你就无法理解。如果你不理解，那么其他人也不可能。

我认为你应该和他们的主管谈谈并解释一下情况。

话虽如此，如果时间紧迫，有时会有理由采取捷径，引用在Netscape工作的Jamie Jawinski，

“我们要发货了我们可以提供最高质量的产品 3月31日“

所以你必须找到平衡点。但总的来说，在代码中编写有用的注释并不需要花费更多的时间，当然不足以显着影响项目时间表，我喜欢Donald Knuth所说的：

...当你写一个程序时，想一想它主要是作为一部文学作品。你正在尝试写一些东西人类会读。别把它想象成一个主要的东西电脑即将效仿。 越多有效的你是在制作你的程序可读，更有效它会是：你会明白的今天你明天会明白的，和你的继任者维护和修改它会理解它

简而言之，即使时间紧迫，也无法替代编写高效，清晰且可维护的代码。

Answer 3

不，这不是通常如何做的事情。但是有一些考虑因素。

有一种称为“测试驱动开发”的开发模式。在这种模式中，您基本上可以编写尽可能少的代码，以便通过您拥有的任何测试。随着需求的变化，您编写新的测试，然后更改代码以匹配。他可能会把你转向更像这样的事情。在这种情况下，如果你编写了足够好的测试，那么原始代码看起来并不重要，如果你测试了你需要的每个案例，那么代码总会做你想要的，即使它是一个可怕的混乱。（顺便说一下，为什么有些人不喜欢测试驱动的开发）。

关于评论的主题，当然评论很重要。但是注释不能替代容易理解的代码，而是使用正确命名的变量和函数名称。过度评论肯定是可能的，并使代码更难阅读和理解（因为每隔一行都是// increment i之类的评论。此外，您拥有的评论越多，评论越多，它们就越有可能变得过时，与实际代码不同步。每个人都会读到并说“那不会发生”，但它总是如此。总是有人改变“关于小事”并且没有更新评论，然后在那之后发生了大约三次评论是完全错误的。

还有一件事需要考虑。考虑一下这个人没有把他告诉你的哲学作为一种哲学的可能性，而是他只是想帮助你。也许你在写任何东西之前花了太长时间试图正确地设计你的解决方案，他觉得如果你在“纸上”得到一些东西，那么你更容易改进它而不是试图把整个解决方案放在脑子里。也许你写过太多的评论，糟糕的评论，或者在评论上花费太多时间（甚至评论格式化，我已经看到这种情况发生了），他觉得你在这个阶段花了很多时间学习代码而不是发表漂亮的评论。

Answer 4

有许多思想流派和许多不同的风格。我已停止计算，而是尝试使用实用的方法。

在实现代码方面，我使用“使其工作”，“使其正确”，“快速”的原则。但后来我也使用了“可能最有效的东西”（DTSTTCPW）

您撰写的评论数量取决于多种因素。一派思想确实提倡好的代码是自我记录的论点。此外，我看到无穷无尽的评论与代码完全不同步。

另一种思想认为你需要评论。

我认为有几个因素会影响您的选择。一个是你个人的偏好。然后是你的老板。在其他情况下，有你的团队。理想情况下，通过共同商定编码标准，您将在同一页面上。最后，如果你总是有选择：喜欢它，改变它，或者离开它。如果您的老板（或导师）无法确信或不愿意在团队中找到共识，则选择1和3可能是唯一的选择。

我对迭代开发的理解是你以小增量添加功能。在任何给定的时间，您都准备好发货，您的代码就像您可以获得的那样精益和意义，包括适当的评论。

我对测试驱动开发（TDD）的理解是您使用测试来推动系统设计。这不仅仅是测试优先编程。

这种方法在过去10多年里对我有用，并且与我合作过很多团队。但我确信还有许多其他选项，风格，偏好，方法同样有效。一切都取决于！

Answer 5

这里有100％的意见，但如果您的解决方案设计得很好，我认为每种方法的评论都是正确的。你应该描述它的作用和原因，但不要详细说明如何。除非你的方法非常长（指示设计不佳），否则代码应该解释自己，即如果你的方法看起来很复杂并且难以理解，也许你应该将其分解以使其更自然地读取。总有例外，但这就是我的观点。

在我工作的地方，代码似乎只有很少的注释，但如果方法名称真正代表其功能，并且方法中的代码是干净的，那么理解它就没有问题了。

不幸的是，我不在现阶段能够解决问题立即写出完美的代码第一次。

没有完美的代码，关于知道哪些卷曲是可以接受的。

也许你的导演只是试图通过说'不要担心设计'来让你的生活变得轻松。

或许他指的是红色，绿色，重构（测试驱动开发）的实践 - 你应该首先编写测试，然后编写代码到它工作的点 - 然后才重构它

Answer 6

我同意在某种程度上自我记录代码。您应该很好地命名变量和方法，而不是依赖于注释。例如你更喜欢哪一个？

//Get the speed of the train from the database
int value = GetValue();

int trainSpeed = GetTrainSpeedFromDatabase();

如果我现在想要从XML文件中获取trainpeed怎么办？在第二个例子中，我更有可能更新它，因此它是有道理的，而不是留下误导性的评论。

迭代开发和重构代码的真正含义

6 个答案: