但是，令我感到困惑的是，在我交出完整的代码后，面试官告诉我，我唯一做错的是“不编译”。随着我的前进”。我问他有什么区别，他说：“如果您完成了代码，但未及时编译，您将怎么做”。对于给定的代码长度，“获取代码进行编译”通常涉及修复一定数量的编译错误，并且花费相当恒定的时间，无论您在编写代码后还是在插入代码后都应该这样做与您的编码时间有关。如果有的话，中断您的编码以搜索缺失的分号可能会损害您的效率。除非在极端情况下，当我尝试对派生类中的虚函数等事物的边缘情况进行模糊处理时，可以合理地预期由有经验的开发人员编写的代码将进行编译，减去偶然的输入错误，甚至如果没有，那不是我必须重写一部分代码以解决编译错误。
在另一起类似的事件中，在一次采访中给我一个不完整的代码库，要求我完成它并进行必要的修改以使其运行。我从阅读现有代码开始，然后过了几分钟（甚至在我看完代码之前），面试官告诉我就足够了。当我问他会做些什么（即“我做错了什么”）时，他告诉我说他本来会立即让代码进行编译。根据我的观点和经验，一段代码的编译本质上是随机的，涉及诸如分号是否丢失之类的事情，与底层程序的正确性无关。 （对我来说，专注于编译就像通过拼写检查运行文章而无需校对语法一样。）
如果给我一段不完整的代码，我要做的第一件事就是阅读它。在我知道代码在做什么并且算法正确之前，我什至不会尝试对其进行编译。
无论如何，这些只是最近发生的几次，但总的来说，我已经听到许多开发人员谈论编译过程中的代码，但没人能告诉我这样做的好处。我了解在进行代码测试的好处，但是为什么要编译？
所以我的问题是：我错过了什么吗？进行编译实际上有好处吗？还是由软件社区传播的某种神话，您必须经常编译代码？
#1 楼
进行编译实际上有好处吗？
有。它使您的反馈循环更短-通常，在设计（UI，编写软件，视觉设计等）时，这是一件好事。
较短的反馈循环意味着您可以快速修复错误
要借用您的示例，假设您正在使用类似C的语言进行编码，而在程序中间某处忘记了
}。 如果您在编写完语句后立即进行编译，则可以肯定您已经引入了编译错误，可以在几秒钟内修复该错误。 t，但是，您将不得不花费大量的时间阅读代码，寻找
}的确切位置，并确保一旦找到错误，便确定该修复确实是预期的。这将在您留下那段代码之后的一段时间内发生。 现在，是的，最终结果是相同的，但是您在语法问题上浪费了很多时间编译器在那里可以为您提供帮助-如果您在编译时进行编译，那么时间可能会大大缩短。
评论
确实，对于这样的语法错误，现代的IDE基本上一直在编译和重新编译，以使您的反馈循环尽可能地短，这对于捕获较小的错误是不合理的帮助。
– Ph子
14年6月23日，11：32
@CaptainCodeman-我要说有一些编译错误，这些错误将需要您挖掘很多代码。对于更大的代码库和更大的变更集，情况更是如此。
–奥德
14年6月23日，11：35
有时，编译器会给您带来困惑而不是提示，例如gcc模板错误。
– pjc50
14年6月23日在13:03
@ pjc50：绝对（通过在下一次编译之前一次不更改太多内容，因此更容易处理，因此您可以确切地知道最后更改的内容）。
–布朗博士
2014年6月23日13:07
这个想法不仅仅是随机编译。它是在每个重要步骤进行编译，并在您希望它仍然正常工作时进行编译。例如，我将进行编译以进行测试，以确保正确地创建/删除了对象，或者确保将事件正确地触发到我创建的新类。如果我创建一个类并以某种方式将其连接到程序中，那么在将更多内容连接到我的应用程序之前，我想确保自己正确地完成了操作。小型应用的重要性降低，而大型应用则至关重要。
– Thebluefish
14年6月23日在18:26
#2 楼
编译是一种测试形式，尤其是在广泛使用Haskell或ML等类型的语言中。在其他语言中，这是一个语法扫描，对您几乎没有什么帮助。我曾说过，“随行编译”在我看来是一种非常习惯的习惯。同样，您也可以因为比面试官的个人偏见更频繁地进行汇编而被“抽搐”，从而被打败。听起来像挑剔。没有人喜欢承认受访者已经通过了考试；它提示了薪资谈判的规模。
并非所有构建系统都很快。我在一个（C ++）项目中工作，其中Make会花费30秒只是统计所有内容以确定是否需要构建，如果进行了更改，大多数文件将花费几分钟。我们不愿意比每10-15分钟更频繁地执行此操作。毫无疑问，有人会提供编译时的趣闻轶事，包括拿出打孔卡甲板并将其搬到另一栋建筑物上。并准备对其进行验证。每分钟一次或每周一次，具体取决于工作流程。
评论
当您将打孔卡带到sysop进行加载时，请确保您从未放过它们，因为按正确的顺序放回它们是真正的PitA！嗯，在基本调试工具是松紧带的时代。
– gbjbaanb
2014年6月23日14:48在
刚开始编程时，我通过不进行编译就可以编写多少代码来衡量我的进步，而这主要取决于我的思维编译器的质量。最初是几个字符，然后是几行。现在我不在乎。我只为查看微小的变化就编译了很多东西，而在进行项目的结构布局时却很少编译。
–菲尔
14年6月24日在5:48
嗯只是想说，一个编写良好的C ++文件编译所花的时间不应超过几秒钟。如果更长，那是不好的代码的味道。而且，如果太大而使make出现问题，我会认为该应用程序过于单一。 “我的” make永远不会有问题，即使在编译Linux时也是如此。
–菲涅耳
2014年6月24日11:42
我离开时的LOC为150万。请注意，Linux不是C ++。模板在gcc中似乎很慢，并且如果您做了一些巧而有用的事情而恰巧编译起来很慢，则没有简单的方法可以对编译器进行概要分析以弄清其含义。
– pjc50
2014年6月24日12:41
@gbjbaanb我认为最好说“源代码控制是松紧带的日子”。 ;）
– JasonMArcher
14年6月25日，0：08
#3 楼
所以我的问题是：我错过了什么吗？
是的：您的想法不是编译器。虽然编译器每秒可以进行n次上下文切换，但您的想法却不能。您一天之内可以进行的上下文切换次数取决于许多因素，例如经验/对代码库的熟悉程度，您对代码的投入程度，代码的简洁程度，要解决的问题的复杂程度，如果您经常被打扰或在嘈杂的环境中等，您会感到多么疲倦。 ”）将迫使您将上下文从您正在考虑的内容中切换（例如“此值设置为5，然后在for循环中blablablabla，并且复杂算法在返回时产生正确的值”）到编译问题完全与您的想法无关（不同的文件/模块/功能/前提条件/语法/变量名称，前提条件等）。
一次编译的代码越多，上下文切换就越多头脑必须做出。当您编写的所有代码都是一小时内编写的代码时，对于少量的代码库而言，这并不是问题。但是，当在现有的代码库中工作时，存在多个（并且有很多未记录的）相互依赖关系，这是一个大问题。 br />
您可以最小化您必须进行的上下文切换，从而使您可以将更多的精力集中在所做更改的影响和副作用上。这也使您不那么累（并且更不容易出错），并提高了输出质量（即，一次更改和编译一个文件比编译十个文件更容易保证最小化的副作用）。 br />
如果您以非常短的迭代次数进行编译（假设编译过程已优化为花费很短的时间），则可以在不脱离“区域”的情况下修复编译错误。这是软件社区传播的一种神话，您必须经常编译您的代码吗？ br />
在我的理解中，这是一个无效的参数，因为对于给定长度的代码，“获取代码进行编译”通常涉及固定数目的编译错误，并且花费相当恒定的时间
在我看来，您在维护中型到大型遗留代码库（数百或数千个源文件）方面经验很少（或没有）。这就是这种态度（即“随您随便编译”）最有用的地方，这也是您养成这种习惯的地方。
我想，接受您采访的人也会得出类似的结论结论（“您在大型代码库中几乎没有经验”）。
评论
“编译并更改十” –在很多情况下，这是尝试的最小有意义的单元；例如向函数及其所有调用位置添加新参数。
– pjc50
2014年6月23日12:55
上下文切换。你在开玩笑，对吧？如果我们谈论自动后台编译以指示您在执行过程中的代码中出现语法错误，那很好。但是最快的上下文切换将无法告诉您算法逻辑是否正确实现或算法是否完全合适。但这是使工作解决方案与组织得井井有条，无错误的编译和快速爆发但完全错误的代码不同的地方。
– JensG
2014年6月23日下午13:13
@JenS，不，我不是在开玩笑。必须跳过所有代码以解决编译错误，从而确保您不再考虑当前正在解决的问题（使您脱离专区）。相反，如果您可以在编写代码时进行编译，则可以继续检查算法-而不是语法。处理上下文切换的最快方法是确保您不需要它们。我的帖子确实假定了理想的世界（使用大型代码库的快速C ++编译和最小的相互依赖性）。
–utnapistim
2014年6月23日13:28
@JensG似乎是一个逻辑上的谬误：这不是要在已编译的代码和糟糕的代码之间进行选择，而是要考虑一次以上编译可能带来的好处。
–乔治
2014年6月23日下午13:32
我怀疑这样一种说法，即在短时间内打破集中力数十次来修复单个语法错误，比一次打破一次并一次解决十二种语法错误的速度更快（在担心了实际算法之后）。当然，这不是上下文切换在计算中的工作方式（毕竟，我们正在尝试针对吞吐量进行优化）。而且我一直在从事具有超过50万个C ++代码的LoC的项目，该项目已经发展了十多年，所以我希望我们还没有画出经验卡吗？
– Voo
2014年6月25日23:31
#4 楼
我认为这里不仅有一些专业的势利小人。含义似乎是“如果您永远不需要定期编译，那么您就从来没有使用过任何复杂的东西-可以获取更多经验，并在学会完全按照我们的方式工作后返回。”但是显然还有另一面。有些项目需要一定的编译时间。我曾经使用过需要30分钟甚至更长的时间才能编译的框架。如果您需要编辑头文件，Heaven会为您提供帮助。完全重新编译通常在一夜之间完成，并且如果您依靠编译器来捕获错误，那么仍然存在一些罕见的错误，这些错误在部分构建期间不会被检测到。在这种情况下，您只是不会每5分钟重新编译一次-除非您感到懒惰。避免花半天时间进行编译变得值得。当然，您偶尔也会打错字，但我将假设您既可以打字，也可以阅读。如果您可以自由选择，请使用一种编码样式，该样式可以充分利用布局来直观地突出显示错误，并且永远不会再放括号，括号或分号。与大多数人相比，这需要一点练习和更多的纪律，但这是可能的。我可以在纯文本编辑器中一次写几个小时的代码，并且第一次编译要好于十分之九。当然，我可以更频繁地进行编译，但是我不记得上次出现错误时更容易纠正的错误。
如果您不喜欢不断地进行重新编译，您的公司很好。这是Donald Knuth：
关于您的实际问题，当我感觉自己的方式时，立即编译和“ unit
测试”的想法仅对我极少有吸引力完全
未知的环境，需要有关什么有效以及什么有效的反馈
没有。否则，很多时间会浪费在我根本不需要执行甚至想不到的活动上。
所有这些都是...您在编译是自由操作的环境中工作，为什么不呢？在家里，在个人项目中，我大约每30秒点击ctrl-S一次，并且在一个IDE中不断地点击“ compile”快捷方式，该IDE不断在编译器的前端运行代码以提供实时的错误突出显示。为什么要放弃免费午餐？
评论
我不同意编译是免费的，分神是昂贵的！但是，否则，好的答案，谢谢:)
– CaptainCodeman
2014年6月23日23:00
也许我应该将粗体，斜体的“ if”改为“ iff”……我认为，根据项目，编译器和环境的不同，接近自由操作可能会非常困难。如果您有第二个窗口或屏幕用于编译器输出，则几乎可以停下来进行编译。如果您真的很顽固（我不是），您甚至不需要看代码-前提是编译器产生了足够多的错误，可以在您的外围设备上进行注册。同样，这是因为编译速度相当快，否则请参见上文。
–DeveloperInDevelopment
2014年6月25日在1:10
我大约每30秒点击一次ctrl-S。我可能经常省下两倍的费用。这真是个坏习惯。有时我会保存在一行代码的中间，然后在代码末尾再次保存。每当我停下来思考一秒钟而不输入任何内容时，我都会保存。
– Cruncher
2014年6月25日18:00
#5 楼
编译时有优点。但是我非常同意，坚持执行任务是一种好的编码策略。增量编译最显着的好处是，如果他们等待编译和测试的最后阶段，他们就会有一种心态：最后，最关心的是使代码运行，而不是那一点。我们说“哦，只需添加此括号，以便编译器停止抱怨”或“哦，只需将其大写”，而不考虑是否存在该语法错误隐藏的潜在语义错误。我确实确实发现语法错误经常将自身嵌套在语义错误中（反之则不成立）。
例如，说我更改了变量的含义，并因此更改了其名称。名称更改稍后会在代码中生成语法错误，但是如果我只是通过更正名称来取悦编译器，我将忽略为什么该错误会出现的原因。
评论
+1突出显示语义错误与句法错误之间的联系
–布朗博士
2014年6月23日14:16
#6 楼
我了解在进行代码测试的好处，但是为什么要编译？
但是在不进行编译时如何测试代码？
极端情况是测试驱动开发（TDD）。显然，TDD不适用于您的策略，因为TDD意味着极短的写测试，编译（应该失败），写代码，再次编译，运行测试，修复错误，再次编译，重构，编译的周期-再次，运行测试，等等...
因此，并不是每个人都进行TDD，至少并非总是如此（我也承认）。使用当前的策略，您将永远没有机会尝试TDD。但是，即使您没有执行TDD，恕我直言，极端定期地测试您的代码也很有帮助-如果您不定期进行编译，这是不可能的。而且，当测试失败时，您就可以对其进行调试（这可以帮助您理解为什么几分钟前编写的漂亮算法不能像您认为的那样表现出色）。而且，无需编写而编写的代码越多，未经测试就编写的代码就越多，因此遇到无法预测解决问题的时间为“ O（1）”的情况的可能性就越大，因为你写的。
评论
我同意你的看法，但是我认为编译程序（因为要运行该程序）与编译程序（当没有任何有意义的测试内容（或用于解决编译错误）之间）有所不同。
– CaptainCodeman
2014年6月23日15:03
@CaptainCodeman：我认为在编写100行代码时，几乎总是应该有很多小部分可以单独测试。 100行代码通常意味着4到15个函数（如果使用Bob Martin的风格编写，则大于20）。
–布朗博士
2014年6月23日15:28
@CaptainCodeman：在TDD中，从来没有“毫无意义”的测试。经典示例是您要编写一个新类（我们称其为Foo），然后要做的第一件事是创建一个单元测试并编写新的Foo（）；由于您尚未编写类定义，因此显然无法编译。在TDD中，这是运行编译器的正当理由-证明您的单元测试正在运行（失败）。
– slebetman
14年6月24日在8:12
@slebetman：感谢您的有用评论。我想补充一点，恕我直言，这不仅限于TDD。编写100行代码时，无论是否进行TDD测试，两者之间总会有一些有意义的测试内容。
–布朗博士
14年6月24日在9:02
#7 楼
我实际上同意您的观点，对于有经验的开发人员来说，编译器错误应该没什么大不了的。我认为修复它们的成本不会随着时间的推移而显着增加，不必担心。如果可以将所有编译器错误的修复推迟到推送之前，我会这样做，因为这会带来更小，更统一的中断。编译器唯一能做的。冒着明显的危险，需要编译才能运行您的程序，并且需要运行程序来查找甚至有经验的开发人员也会创建的所有更复杂，细微且有趣的运行时错误。而且这些类型的错误更加困难，因此，您推迟调试的时间越长，修复它们的成本就越高，因为它们可以相互建立或相互掩盖。将采访推迟到最后的采访练习。面试往往很简单，有经验的开发人员通常知道自己的局限性。您对编写的内容越有信心，两次编译之间的时间就越长。那只是人的天性。为了不让你为此而失望，尽管如此，必须要有信心。如果您花了45分钟编写某些内容而不进行编译，然后又花了45分钟来调试它，那么我会对您造成很大的压力。
#8 楼
据我所知，经常进行编译的一个重要问题是，据我所知，它没有其他答案：如果编译很少并得到大量编译器错误，则大多数错误是无意义的，因为它们是由第一个错误生成的。可能是因为您输入了错误的类型，拼写错误或简单的语法错误，从而使某些声明无效。您始终可以修复第一个，重新编译，修复下一个其余的，等等。 ，但是如果代码库很大，这可能会很慢。但是，如果您尝试浏览一堆独立的编译器错误和发现错误，那么您将花费大量时间阅读不相关的消息，或者将代码从次要错误发现到实际原因。
进行常规构建的另一件事是，一旦编写了完整的应编译的代码块，任何事情都不会阻止您开始编译。然后，只要编译继续进行，只要不保存新的编辑，就可以继续编写更多代码。因此，几乎没有时间在等待构建上。如果您等到那时写完了要写的所有东西，那么您就必须等待编译而无需做任何事情。这基本上是现代IDE可以在后台自动执行的手动版本。
评论
有趣的是，即使编译缓慢，这也是定期编译的一个很好的理由。好点子。
–sleske
14年6月25日在9:19
#9 楼
对于一个有足够经验的程序员来说，编译代码从来都不是瓶颈。做出简单的语法错误。您所做的通常是拼写错误或复制粘贴错误，只需几次编译通行证即可很快清除它们。在提交我的代码之前，先编译并修复错误的语法错误和警告，然后编译器报告（带有“需要测试！”的注释）。在短短几分钟内，我就可以清理超过1,000行的C或C ++代码。另一方面，调试和测试需要一段时间。出于各种原因会出现逻辑错误，但我还没有遇到能告诉我完全忘记编写的子例程的编译器，或者会注意到我的二叉树无法正常工作，因为我在应该将
node->left粘贴到本应粘贴的地方。虽然我认为与面试官打架通常是不明智的，但我想说的是，如果您觉得自己的风格值得捍卫，应该指出您留给自己足够的时间调试代码d写。那是没有一个优秀的程序员会忽略的事情。
p.s. -如果我一直在看您通过阅读代码来审查代码，那么我会当场雇用您。专家每次都这样做。
评论
“我还没有遇到能告诉我完全忘记编写的子程序的编译器。”当我尚未完成深远的更改时，我完全依靠编译器来告诉我。有时，我甚至重命名了一个变量以防止编译成功，直到我检查了每个变量的用法实例并为其指定了新的名称。我不明白您怎么能说您还没有遇到缺少某些内容时不会警告您的编译器。除非您编写空的占位符子例程，然后忘记它们，否则天堂将为您提供帮助。
–伊恩·戈德比（Ian Goldby）
2014年6月24日11:57
@par感谢您的回答；很高兴知道我不是唯一这样编码的人！
– CaptainCodeman
14年6月24日在12:27
@CaptainCodeman我很清楚逻辑错误比编译器错误更隐蔽。但这是他的断言，即编译器无法告诉您我想提出争议的丢失代码。除非您故意编写错误（或不完整）的代码进行编译…，但这会否定编译器无法捕获的错误是IMO的真正问题。哎呀，我什至使用编译器将插入符号移到下一条需要编写代码的行。但是也许我很懒。
–伊恩·戈德比（Ian Goldby）
2014年6月24日13:20
@IanGoldby：您完全错过了重点，我什至会说您选择歪曲我的话。编译器无法像我无法告诉您明天早餐吃什么的方式来警告您丢失代码。故意引入语法错误，以便编译器使您想起某些东西是一种编程技术。它不会被视为错误，也不会赋予编译器心理超能力。
–标准
14年6月24日在17:57
@par我对我显然是由于我的评论造成的冒犯表示歉意-这不是故意的，而且我当然也不打算歪曲您的言论。现在，我看到当您编写仍可编译的不完整代码时，您可以通过添加#warning或TODO来确保不遗忘该代码。那是合法的技术。我们都同意的重要一点是，可编译但不起作用的代码比不编译的代码危险得多。
–伊恩·戈德比（Ian Goldby）
2014年6月25日7:32
#10 楼
不，在完成足够数量的代码之前延缓编译并不是没有道理的（“足够数量”取决于编码器和编写的代码）。例如，如果您真是个了不起的编码人员，他花时间把它做好，而且您并没有编写大量代码或繁琐的代码，因此定期进行编译是一种浪费，也可能会分散注意力。如果不是这样，那么编译每个函数可能是一件好事。作为一个反例，假设您正在编写JavaScript代码-没有编译器。相反（鉴于大多数JavaScript代码的性质），您将运行程序（或刷新页面）以查看编码结果。现在，除非编写足够的代码以使其有意义，否则您将无法执行此操作。结果，JavaScript开发人员倾向于尽可能多地“编译”，这不一定很频繁。
总之，这里没有正确的答案-面试官没错，但是你也不是。做能使您提高工作效率的事情，而忘记任何人告诉您您应该做的事情。有关编码的重要因素要多于您定期（或不定期）击中F7的趋势绝对没有影响。
评论
您的第二段不清楚；您可能需要对其进行编辑，以明确“超棒的编码器”是否应定期编译。 （您是否添加了“ t”并将“ no”更改为“ not”？）
–DougM
2014年6月23日15:52
@DougM-太好了。
– gbjbaanb
2014年6月23日15:55
脚本代码经常是“实时”开发的，也就是说，它是在REPL环境中执行的。因此，“编译”确实一直在发生，写入源文件的大多数代码也已执行一次。并非所有人都以这种方式编写脚本代码，但是我想说的是，任何人都喜欢并喜欢静态类型语言的相对“安全性”以及错误代码给出的编译器错误，他们应该以这种方式在脚本语言中工作。
–氢化物
14年6月23日在18:55
#11 楼
有了良好的开发环境，除非您实际上打算测试代码，否则几乎没有理由编译。后台语法检查工具捕获了面试官似乎在谈论的大多数内容，尽管我承认，仍有少数情况（涉及跨文件传播的更改）并没有得到完全识别。 >话虽这么说，我将尝试编译并运行几乎可以实际产生结果的最小代码单元。半个小时前，我正在创建一种打印一些搜索结果的方法，并做了六打测试打印（以.pdf而不是纸张的形式），对结果进行了更改以使其看起来更好-每10个编译一次行。#12 楼
在我看来和我的经验中，一段代码的编译本质上是随机的，涉及诸如分号是否缺失之类的事情，并且与底层程序的正确性无关。 （对我来说，专注于编译就像通过拼写检查来运行文章而无需校对语法一样。）
我的经历非常不同：少于5％的编译错误我了解语法。我很了解该语言，当我遇到错误时，主要是类型错误，告诉我语义是不正确的。这就是为什么我很乐意从编译器的反馈中尽快受益。 。
您是否曾经体验过使用强调实时编译错误的IDE？缩短反馈循环可能非常有价值。
如果给我一段不完整的代码，我要做的第一件事就是阅读它。在我知道代码在做什么并且算法正确之前，我什至不会尝试对其进行编译。
如果希望您使用别人编写的代码，您并非总是有时间阅读所有内容。好消息是：编写良好的代码具有较低的耦合度，应该使您能够仅对所需代码的一部分进行独立推理。
在这种情况下，您必须假定代码还没有阅读正确的书，在出现问题时会懒惰地研究。花费的时间是相当恒定的，无论您是在编写完代码后还是在编码时间中进行交错处理，时间都应该相同。
上下文切换对您的大脑来说是昂贵的，因此，在编写小错误时就更有效地解决它们。编辑：当整个团队都在同一个源上工作时，我也可以与源代码控制进行类比。在进行过程中进行编译就像进行频繁的提交一样，它有助于避免在最终不得不合并和整理所有内容时遇到很多麻烦。在您的文字下方。在键入电子邮件或撰写技术文档时，您还会这样做吗？然后，您必须重新校对所有页面，而不是在旅途中纠正错误。
另一个优点是，在处理代码时，如果始终保持编译或接近编译状态，您可以从许多基于语义的IDE功能（安全重命名，重构，查找符号的使用...）中受益。
如果您想更好地了解这些功能的帮助，您可以尝试启用它们并进行练习，以亲身体验它们的好处。
您还可以尝试与习惯于它们的任何人进行一些配对编程，并查看它们如何从中受益。
评论
我通常会关闭烦人的编译器“功能”，例如自动格式设置，在文本下方绘制红线等。因为我发现没有这些精简的功能，我的工作效率更高。
– CaptainCodeman
14年6月27日在8:45
#13 楼
我对此想了一点时间，因为我觉得面试官有个非常非常不对劲的地方，无法确切指出是什么。问题就来了：对于我过去二十年来编写的任何代码，将可行的算法转换为可编译代码所需的时间最少。该领域效率的任何提高对总开发时间的影响都很小，以至于可以忽略不计，而由于认为该领域效率低下而拒绝候选人的面试官也不知道什么才是优秀的开发人员。应将大部分时间花在收集信息上代码应该做什么，收集有关需要使用的外部服务的信息和规范，创建全局设计以替代正确和可维护的代码上。一起破解代码，并找到可以导致正常工作的代码的算法，而不是修补在一起的代码直到碰巧起作用的代码（显然没有错误的代码与没有明显错误的代码）。
然后花了很少的时间来编写可编译的代码。
然后需要花费大量时间来确保代码可以正常工作，并确保我们知道代码可以正常工作。这是通过编写单元测试，逐步执行代码以及首先在很大程度上具有精心设计的代码来完成的。
这位面试官专注于我的答复中用十个单词涵盖的内容。占实际工作时间的10％或更少。并且几乎对该开发人员产生可靠且有效的代码的能力几乎没有影响。
评论
这很有意义。在我看来，一个好的开发人员应该能够整天在纸上编写代码，然后在一天结束时将其键入。
– CaptainCodeman
14年6月27日在21:56
#14 楼
“按需编译”的优点是可以不断获得反馈，并且在朝着正确的方向推进之前不会出错。对于像您这样的称职的程序员来说，这不是一个很大的考虑因素，但对于其他许多人来说，则是这样。换句话说，即使您的案例中存在一些潜在的效率损失，“随行进行编译”也是“最小化最大损失”的一种方法。在成品中。他们想知道它一直处于“控制之下”。对于他们来说，“到那里去享乐一半。”评论
与之前的16个答案中所发布的内容相比，这似乎没有提供任何实质性的内容
– gna
14年6月27日在21:52
谢谢，但是我们在谈论什么损失呢？当然，除非您做了一些大胆的尝试，例如意外地使用错误的语言编写，否则您将永远不必仅由于编译错误而重写任何代码。
– CaptainCodeman
14年6月27日在21:53
@CaptainCodeman：它使公司感觉更好，是一种“保险”形式。这是要花钱的事情，但是会使大多数人（包括经理）“晚上睡得更好”。
–汤姆·欧（Tom Au）
14年6月27日在22:09
@gnat：我要提出的观点是，大多数收益是“公司”级收益，程序员应该这样做是因为老板告诉他，而不是因为程序员认为对与错。
–汤姆·欧（Tom Au）
14年6月27日在22:16
已经提出了支持“更短反馈回路”的要点，并在此处的第一个答案中作了很好的解释；老实说，我看不出对“这些天的公司”的盲目猜测会如何增加已经说过的东西
– gna
14-6-27在22:22
#15 楼
这里的其他答案为频繁地在工作中进行汇编提供了很好的辩护，但是由于您的问题集中在面试上，因此我想解决这个问题。我在面试中相反：考生不能使用编译器。他们在白板上编写了简短的程序，然后我们进行讨论。我发现太多的开发人员将编译器（或解释器）用作拐杖，这比不经常进行编译要浪费更多的时间。如果我为您提供了很多钱，而您甚至没有编译器也无法正确编写FizzBuzz，那么您将永远不会长期削减它，解决的问题比玩具练习困难100倍在面试中。然而，这些简单的练习比面试的任何其他部分淘汰了更多的候选人。
面试的目的是评估候选人与企业的相互适应性。一个好的面试题应说明问题的目的以及如何评估受访者。向被访者提出一个技巧性问题，然后因不知道隐藏的答案而对他们进行惩罚，这无济于事。不幸的是，大多数程序员（甚至是高级程序员）都没有接受过与其他程序员进行面试的培训，因此他们只是依靠陈词滥调，并在面试时提出与他们面试时所问的相同类型的问题，尽管这些对评估候选人的有效技巧没有多大帮助是否。
我并不是说我的方法是“一种真正的方法”，但它为我提供了很好的帮助。像许多以大写字母开头的软件方法一样，面试的“授权”也相同。他们都是双层床。您需要做对您和您的业务有用的事情。
#16 楼
在具有多个子例程的大型项目中，您希望先在大型方案中使用它们之前测试这些部件，因为如果您知道某些部件已经在工作，则调试起来会更容易。这些较小的部分，您需要进行编译。可能是面试官将这种情况与不是以这种方式设计的小程序混淆了。
#17 楼
关于第二次面试，编译的好处是您可以在几秒钟内观察到程序执行（或不执行）的功能。从那里更容易阅读代码并将精力集中在相关部分上。从头到尾读取这样的未知代码库可能会毫无用处（您不是编译器），而编译/运行应用程序将很快您更大。
评论
这似乎没有提供超过之前15个答案中所发布内容的任何实质内容
– gna
14年6月27日在21:52
评论
要么是因为我的习惯被习惯不同的人称为坏习惯。@DocBrown如果最终目标是使用正确的产品，则该比较有效。 “运行”的程序并不比运行错误的程序好。您不能期望编译器会比您期望拼写检查来修复语法错误还要多。
编译是否打扰您的工作流是非常主观的，并且取决于语言，构建环境，项目的大小/复杂性等。IMO在大型遗留项目中更可能成为问题。
我完全同意OP。我无法理解某人如何判断自己的工作习惯，例如当他/她用来启动编译器时。唯一重要的是努力的结果。这是对的吗？它可以维护吗？它是否在预期的时间范围内运行？实施需要多长时间？这些是有趣的问题。所有其他都是任意的BS。如果受访者编写了2个小时的完美代码，并且可以在第一次尝试时进行编译，那么问题出在哪里？仅仅因为面试官做的不同？我的天哪。
还应该提到的是，对于某些语言和IDE（Java / [Eclipse | NetBeans | etc]，C＃/ Visual Studio等），在键入时，IDE已经在后台实时编译所有内容。效果使您可以立即反馈是否犯错。希望IDE开发人员能够对这种随用随动的编译方法进行研究。