我最近开始作为一名开发人员工作，并在一位更高级的开发人员的帮助下工作，这位开发人员正在监督/指导我。迭代开发和重构代码的真正含义
很多事情，他建议只是不正确。例如，他告诉我只是以程序的方式编写我的代码，而忽略了它的书写或其整体设计以及如何使其工作。然后迭代地，它会随着时间的推移而变得更好。
这让我感到很不自在，因为在编码之前花时间真正正确地思考解决方案和实际问题，我觉得通过这种方式进行编码和编码，最终会花费更多的时间。不幸的是，我并没有处于能够通过第一次编写完美代码立即解决问题的阶段。
此外，他不喜欢记录代码，相信它应该为自己说话。他认为每种方法的顶部的简短评论就足够了。这又似乎对我来说很直观。
总而言之，我觉得我现在正在编写真正的hacky代码，以便能够启动并运行。他是否正确，并且这是整个行业的事情吗？
而且，他皱起眉头在记录代码， beliveing它应该 自己说话。
这几乎是我需要阅读的所有内容。这个人真的不知道编写可维护代码需要什么。
就这样说，这个人显然是你的导师/主管，所以你不能只说“嘿，那很愚蠢”，你必须巧妙地去做。
但是没有记录代码，因为它“应该为自己说话”是灾难的秘诀。你一定要注意写清楚，有效和高效的代码。 从现在起6个月，做一些事情总比做一些你不会理解的事情更好。如果你不明白，那么其他人也不会有机会。
我想你应该跟他们的主管谈谈并解释情况。
随着中说，有时有原因走捷径，如果时间轴偏紧，报价杰米Jawinski，谁在Netscape中工作，
“我们要出货 最高质量的产品，我们可以在 3月31日“
所以你必须找到平衡。但总体而言，在代码编写有益的意见并没有采取更多的时间，当然不足以显著影响项目时间表，我喜欢什么Donald Knuth说：
...当你写一个程序，认为它主要是作为文学作品的 。 你正试图写出一些人类将要读的东西。不要 认为它主要是作为一个 计算机将要遵循。更 有效的，你是在让你 程序可读性强，更有效 这将是：今天 你会明白，你下周理解， 和你的继任者谁是要 维护和修改它会明白 吧。
总之，即使时间紧迫，编写高效，清晰和可维护的代码也无可替代。
谢谢你，这正是我所做的，并且违背了我在大学教过的所有事情。正如你所说，这也是非常困难的，因为他们本质上是我的主管。它也是一家小公司，所以很难超越他们的头脑。我想唯一的方法是真正做我自己的事情，并以他们的方式编写代码，我认为它应该是完美的（在课程的理由之内），虽然这会花费比他想要的东西更长的时间，所以会有一个不变的问题我花了太长时间。 – David 2010-08-08 13:05:29
以正确的方式做事情的问题在于，工具集通常不在那里，因为大多数事情都是以一种半开始的方式完成的，旨在让他们先出门，或者至少秒钟。除非你正在建造太空穿梭机或者（希望）纳米机器人，否则也不会有完美的期望。所以，尽管正确的方法比一般的方法更好，但在实践中，通常没有足够的人关心质量以使其具有实用性。整个unix基础设施建立在一半以上，（着名）“更糟更好”的理念之上。 – intuited 2010-08-08 13:34:20
不，这不是真的如何通常完成的事情。但有一些考虑因素。
有一种称为“测试驱动开发”的开发模式。在这种模式下，您基本上只需编写尽可能少的代码即可通过任何测试。随着需求的变化，您可以编写新的测试，然后更改代码以匹配。他可能会更加倾向于这样的事情。在这种情况下，如果你写得一手好足够的测试，不要紧的原代码是什么样子，如果你测试你需要，那么代码会永远做你想做的，即使它是乌七八糟每一个案件。 （顺便说一句，为什么有些人不喜欢测试驱动开发）。
关于评论的主题，当然评论很重要。但是，注释并不能代替易于阅读的代码，并具有正确命名的变量和函数名称。过度评论绝对是可能的，并使代码更难阅读和理解（因为其他每行都是像// increment i这样的评论）。此外，你有更多的评论，他们越大，他们越可能变得过时，并与实际代码不同步。每个人都会阅读并说“那不会发生”，但总是这样。总是有人在“小事情”上进行改变，并且不更新评论，然后在那之后发生大约三次评论就是错误的。
还有一件事要考虑。想想这个人可能不会把他告诉你的东西当成一种哲学，而是他只是想帮助你。也许在写任何东西之前，你花了太长时间来试图正确地设计你的解决方案，他觉得如果你首先在“论文”上找到一些东西，那么改进它会比试图把整个解决方案放在头上更容易。也许你已经写了太多评，差评，或者花费太多时间在评论（或者甚至在评论格式化，我已经看到了这一点），他觉得你想通过花时间学到了更多在这个阶段你代码比做出漂亮的评论。
其100％的意见在这里，但如果你的解决方案是精心设计的，我认为每个方法的注释可适量。你应该描述它的作用和原因，但不会详细说明如何做。除非你的方法非常长（表明设计不好），否则代码应该解释自己，即如果你的方法看起来很复杂并且很难理解，也许你应该分解它以便更自然地阅读。总有例外，但那是我的看法。
我在哪里工作，代码似乎有极少数的意见，但如果方法名是真正代表其功能，方法里面的代码是干净的，我没有任何问题的理解吧。
可惜我不是在 阶段能解决的问题立即 通过编写代码的完美 第一次。
有没有这样的事情作为一个完美的代码，它关于知道哪些comproises是可以接受的。
也许你的metor只是想通过说'不要担心设计'来让自己的生活变得简单。或者他可能指的是红色，绿色，重构（测试驱动开发）的实践 - 你应该先编写测试，然后将代码写入它的工作点 - 然后才能重构它。
有许多思想流派和许多不同的风格。我已经停止计数，而是尝试使用实用的方法。
在实现代码方面，我使用了“让它工作”，“把它做好”，“让它快”的原则。但是，我也使用“最简单的事情，可能工作”（DTSTTCPW）
你写多少意见取决于许多因素。一派思想的确提倡了好的代码是自我记录的论点。另外，我看到了与代码完全不同步的无尽评论。
另一派思想认为你需要评论。
我认为有几个因素会影响您的选择。一个是你的个人喜好。然后是你的老板。在其他情况下，你的团队。理想情况下，你们将通过共同商定编码标准来达成共识。最后，如果你始终有选择：爱它，改变它，或离开它。如果你的老板（或导师）不能确信或不愿意在团队中寻求共识，选择1和3可能是唯一的选择。
我对迭代开发的理解是，您可以以小增量添加功能。在任何特定的时间，您都准备好发货，并且您的代码尽可能精简并且意味着您可以得到它，包括适当的注释。
我对测试驱动开发（TDD）的理解是，您使用测试来驱动系统的设计。这不仅仅是测试优先编程。
这种方法在过去的10多年里一直为我工作，并与我一起工作过的很多团队。但我相信还有很多其他的选择，风格，偏好，方法论等同样出色。这完全取决于！
我同意在一定程度上自我记录代码。你应该很好地说明你的变量和方法，而不是依赖评论。例如你更喜欢哪个？
//Get the speed of the train from the database
int value = GetValue();
int trainSpeed = GetTrainSpeedFromDatabase();
如果我决定，我想现在得到一个XML文件中的trainspeed，在第二个例子中，我更可能是很有意义的，而不是离开误导性评论来更新它。
我要在这里出现一个肢体，并建议你可能会误解高级开发人员告诉你的内容。 “让它工作”和“代码应该为自己说话”是相互排斥的。如果我们假设这家伙不会真的知道自己在做什么，让我提供几个替代的解释：
很容易迷失在杂草痛苦新的开发者在正确的方式来设计软件。这是一种分析瘫痪。他可能希望你快速地直接进入代码，这样你就可以写出一些东西，并且很快发现哪些工作不好。这听起来像是让你早点失败并且经常为了学习而失败。
许多新开发人员大肆洒出他们的代码无用的评论。他要求你编写自我记录的代码，而不是冒充和混乱的代码。如果只允许在函数顶部使用简短的注释，则必须使用清晰的变量名称和简单明了的算法才能使代码更有意义。这是一件好事。
与导师坐下来澄清他告诉你什么是没有错的。你确实有有效的担忧。不要犹豫，问他更多的信息。它显示了自信和为自己思考的能力。优秀的员工不是心灵麻木的机器人。
+1非常好的答案，我完全同意。 – 2010-08-08 19:52:36
我同意代码应该为自己说话而不需要注释的想法，但是这仅仅是有时（大多数？）不是这种情况 - 如果您还提倡编写草率的代码，自己说话，确实很奇怪。但我不是专业人士。 – Phoshi 2010-08-08 12:58:21
我知道37 sig是热衷于现在得到一些东西的倡导者，在哲学之后改进它。在我看来，这不是一个糟糕的工作方式。 至于评论，以及我的文件尽可能多我想。显然这有点困难，因为他是你的导师，所以我建议按照他现在想要的方式去做，直到你离开他的影子。 – studioromeo 2010-08-08 13:14:24
@尼尔：但是你有没有遇到过（广泛的）文档与代码不匹配的代码？至少有两次工作要理解！ – mvds 2010-08-08 13:14:58