由于我目前正在为工作中的项目而努力地学习WCF，所以在过去的几天里，我一直在在线学习关于制作WCF客户端的最佳方法的教程和示例；今天，当我告诉老板时，我很难找到好的教程，因为其中一些教程的示例不会详细介绍（例如，显示一段有效的代码，但不能解释其确切原因，或者他告诉我，我不应该尝试完全理解它们，因为有时代码只是会执行它的工作，而我应该把它留在那儿（他给了我例如，当进行微积分运算时，例如，我们使用的公式不知道它们是如何构思的或如何工作的，我们只是知道它们是如何使用的，而我们却使用它们。）
这很麻烦我是因为一直有人告诉我，了解您的代码非常重要，并且仅在不知道其工作方式的情况下进行复制和粘贴实际上是一种罪过；这就是为什么我总是花一些时间了解一些东西然后再继续前进的原因。并不是说我想了解特定类在汇编语言级别上是如何工作的，我只是想知道为什么一组指令可以实现窍门，为什么另一个指令不可以实现窍门，或者为什么两者都可以执行以及在什么情况下运行？情况。但是老板告诉我，我最终将浪费时间在这些小细节上，而我应该跳过它。所以我的问题是，他是对的吗？可以只在一定程度上理解您的代码并继续前进，我是否只痴迷于无关紧要的小事情？
#1 楼
软件抽象的唯一目的是隐藏功能细节。如果不是那些抽象，就不可能超越计算的某个特定点，因为系统会在自身复杂性的压力下简单地崩溃。人脑一次只能理解很多信息。考虑一下编写方法时会发生什么。编写方法时，您正在做的是在方法调用后隐藏一些软件功能。一旦编写了该方法并通过编写关于该方法的单元测试证明该方法可以工作，那么您无需再考虑该方法内部的内容，除非您需要对其实现进行一些更改。
大型软件系统是建立在这些抽象的许多层上。您在处理器，机器代码，地址和数据总线，语言编译器，面向对象，数据结构，特定于域的语言等中具有微码层。您具有在其他库之上构建的库，而这些库又是在操作系统之上构建的。您也不完全了解其中任何一种的工作原理，但是您仍然能够成功编写出有用的计算机程序。
那是...
您不能不理解代码的工作原理而仅复制/粘贴代码。试图通过复制他不理解的粘贴代码来使程序正常工作的人将自己设置为失败。您需要了解所编写的代码。这并不意味着您必须了解WCF的内部工作方式，但是您确实需要了解WCF的目的是什么，如何编写与WCF正确接口的代码，以及如何编写与之协同工作的代码。许多复制/粘贴程序员甚至对他们正在复制/粘贴的编程语言都不了解，更不用说他们正在使用的库的深入知识了。
因此，您需要具备一些体面的技能，并且需要了解编写（或粘贴）调用WCF的代码。但是您不需要对WCF内部工作方式有深入的了解。
类似地，认为可以通过随机连接软件模式将程序缝合在一起的程序员也没想到。我们称这些人为“货运崇拜”程序员。
评论
我有资格说明这一点，尽管我们所有人都必须放弃并将底层内部视为无限神秘的黑匣子，但我们确实必须知道哪种输入模式可以提供哪种模式或输出。货物崇拜的编程仅是由于缺乏理解，将输出从一个卡盘连接到另一个卡盘，然后又不了解吞吐量如何在过程中转换的结果。我不了解自己运行的90％的代码是如何在内部工作的，但我确实确切地知道该不可见的代码如何转换我的数据和状态。这种转变才是真正的程序。
– TechZen
2014年5月8日下午5:48
我认为“理解”和“能够理解”之间是有区别的。如果您盯着它看，无法复制/粘贴代码，那是复制/粘贴代码的另一种主张，如果出现问题，您很乐意仔细查看。
–史蒂夫·贝内特（Steve Bennett）
2014年5月8日在8:34
给出答案后，您可以说您至少必须了解所使用的抽象层。
– Rottem
14年5月8日在16:39
总而言之，在调用函数时，只要正确使用它，就不必关心如何实现该调用函数。但是，当您复制并粘贴函数的代码时，该代码将成为您的代码，并且您对此负全部责任。
– 200_success
2014年5月8日16:50
同意所有方面。我想指出的是，即使您的代码显然应该工作，但是当代码无法正常工作时，了解库的内部结构也是很有用的。当您了解该库的流程时，经常会发现最初的假设在哪里分解。
–塔恩·布里姆霍尔（Thane Brimhall）
2014年5月8日19:24
#2 楼
我认为答案是上下文。用于管理代码复杂性的最强大技术之一（在我看来，这是软件工程师的实际工作）是抽象。电气工程师不必为了开发新产品而对麦克斯韦方程进行验证，并且我不需要使用方向盘就可以了解汽车的任何知识。两者都是重要的抽象，因为它们允许我们在不了解它们的情况下直觉和使用事物。顺便说一句，这使我们能够构建更大的抽象。
另一方面，由于抽象是如此重要，因此我认为有时甚至与其他开发人员一起实施抽象也很好。例如，在我的办公室里，有时我们有一位开发人员在另一位开发人员编写代码块之前编写代码块的单元测试。它实现了简单接口和清晰抽象的思想。
话虽如此，抽象并不是您不了解代码如何工作的借口，因为当您知道代码如何工作时，它就很重要。重构代码是一个显而易见的场景，其中实现细节相当重要。我不需要知道汽车是如何运转的，但是机械工程师和机械师应该都可以理解汽车的运转方式，可以说是通过不同的方式。
顺便说一句，我在工作中的第一课是永远不要接触我不真正理解的代码。例如，我曾经在开发一项新功能，却注意到模块中没有意义的另一行代码，因此我“修复”了该错误，然后发布了一个错误。这给了我很大的教训，那就是当我不容易理解一段代码时要承认，并认识到好的，复杂和非琐碎的代码可能是不明显的。我对软件开发还很陌生，但是我发现“易于阅读的好代码”是一种阴险的想法，我认识的任何软件开发人员都没有将它付诸实践。当然，不要编写晦涩难懂的代码，但是困难的问题通常需要复杂的代码。如果您花时间了解事物，请不要感到沮丧。我最喜欢的费曼语录是：“但并不复杂；只有很多。”
那么，什么时候抽象，何时分解瑞士钟呢？我想这取决于您何时佩戴手表以及何时建造。我个人的观点是，任何领域的最佳人才都是T型的，这意味着他们在更大的背景下了解自己的工作（这只能通过抽象来实现），但也知道他们需要深入了解。
评论
“如果您花时间了解事物，请不要感到沮丧”-确实使我振奋！所以谢谢 ：）
–安娜·阿米尔（Ana Ameer）
2014年5月8日下午4:08
#3 楼
理解软件分为三个不同的部分：首先，要理解为什么存在一个软件（与应用程序一样大，或与单个功能一样小）。您需要知道它的要点，编写原因。最后是知道一段代码的工作原理，其内部结构以及
您需要掌握其中的哪些才能理解某个软件，具体取决于您需要对该代码执行什么操作。
例如，请使用.NET的String.ToUpper（）方法。我知道此方法的作用，以及为什么要使用它，但是我不知道它是如何编写的（这是实现细节），我也不在乎-只要我能正确使用即可。我永远不需要修改此方法，因此不需要了解内部结构。
如果要从Internet复制代码，则需要完全确定代码的作用以及为什么。如果我只是复制它而从未修改（不太可能），那么我就不需要了解它的工作原理。但是，如果我要（可能）对其进行修改，那么我将需要知道它的工作方式-否则，我只是使用猜测来修改代码，而且可能结局不佳。
评论
您可能要添加到答案中的一件事是“需要多长时间”。这可能是一条重要信息，可能适合您呈现的内容或方式。 +1
–sixtyfootersdude
2014年5月8日13:48
使用String.ToUpper（）之类的东西时，您确实需要知道它将成功使用哪些字符编码以及不支持的字符编码。例如，它采用的是Latin-1或Windows-1252编码，还是可以使用UTF-8？这是您需要了解的“幕后”信息-并非完全了解所有内部知识，但仍然是至关重要的知识。
–菲尔·佩里（Phil Perry）
2014年5月8日13:56
@PhilPerry这是接口的一部分，应予以记录。这不是内部细节。
–ignis
2014年5月9日在7:04
有时，它没有得到充分的文档记录（我相信你是在特定的实现中）。这是容易被破解的一件事，尤其是在志愿者支持的开源项目中，文档往往滞后。
–菲尔·佩里（Phil Perry）
2014年5月9日13:26
@PhilPerry：如果调用String.ToUpper的目的是为了加速例如重复进行不区分大小写的字符串比较，所有需要了解的有关UTF-16之类的处理都是希望与框架的不区分大小写的字符串比较方法应该工作的方式相匹配（不一定是它们的工作方式） ，因为对任何常量转换的任何结果进行序数比较都会定义一个等价关系，但是框架中的某些字符串比较方法被打破了，并且没有定义等价关系。）
–超级猫
2014年5月10日16:00
#4 楼
并不是说我不同意其他答案，而是让我对两句之间的内容做出回应。如果老板建议您不需要了解某些事情的工作原理，则可能是有些反馈表明您花费太长时间才能完成某件事。有些人很容易被无关紧要的细节分散注意力，因此对他们而言，建议您按时做事。另一方面，如果编程是您选择的专业，并且您确实有求知欲，融入一些对您的工作很重要的技术，那么我鼓励您花一些额外的时间来尽可能地关注自己的兴趣。您获得的见解虽然不会立即得到回报，但从长远来看会带来好处。它会帮助您理解该技术，使您能够在许多情况下进行扩展，并为将来的更深入了解做准备。随着时间的流逝，这就是专家与休闲用户之间的区别。
评论
您应该努力获得更多的知识，但是您的老板可能不希望您在公司时间做这件事（除非它是与您的工作直接相关的专门知识）。我同意他可能会暗示您太分心了，浪费时间在无关紧要的细节上。良好的时间管理是优秀，成熟的工人的特征。
–菲尔·佩里（Phil Perry）
2014年5月8日13:59
我仍在进行时间管理，但是我同意这是我必须改进的地方。谢谢你的建议。
–安娜·阿米尔（Ana Ameer）
2014年5月8日14:30
我认为老板和OP都只是试图“对冲”他们的赌注。当您的老板有疑问时，您想让您知道足够的知识来完成工作，但是，OP希望知道自己在做什么，以防万一有事情发生，并且希望早日知道。折衷方案是何时了解更多信息。有时，您必须在项目/任务完成后执行此操作，否则仍会有时间不足的风险。
– JeffO
2014年5月8日18:21
@Phil：这是老板应该理解的论点：如果员工在公司时间学习然后离开，那是不好的。如果他们不学习和留下，那就更糟了。
– gnasher729
2014年5月9日16:55
花费额外的时间来确保自己知道自己在做什么和每次都分心之间是有区别的。前者是一种美德（en.wikipedia.org/wiki/Festina_lente）。后者，有药物治疗。
–保罗·杰克逊
2014年5月9日18:14
#5 楼
在伟大的书中，实用程序员被称为“巧合编程”（http://pragprog.com/the-pragmatic-programmer/extracts/coincidence）更大的问题是，如果您不知道为什么这段代码由于某种原因而失败，为什么一段代码却无法工作，您不知道为什么失败，也无法修复。
#6 楼
我并不完全同意这样的说法：“不能在不理解其工作原理的情况下复制/粘贴代码。”原谅我的愚蠢，但从程序化的角度来看，它并不包括方法/函数库，我不知道它们的工作原理与将代码复制/粘贴到我自己的方法/函数库中一样？
即，如果我使用jQuery进行编程，则应包括jQuery库和然后使用它。使用罗伯特·哈维（Robert Harvey）的答案，这很好，因为jQuery可以抽象出我需要使用的所有内容，而无需自己编写代码甚至完全理解代码。在使用它之前，我真的需要确切了解jQuery是如何在幕后工作的吗？
我已经同意声明的原理，但想指出一下这个概念实际上，“复制/粘贴”代码（没有完整的理解）比人们想像的要普遍，并且不像此声明所显示的那样繁琐。
评论
区别在于jQuery不是您的代码。如果jQuery中存在错误，则其开发人员将对其进行修复并推送更新。如果您在复制和粘贴代码时有一个错误，而没有理解，则没有人能够修复它。
–红色警报
2014年5月8日19:40
如果库中存在错误，则开发人员可能会在将来的某个时候（也可能不会）对其进行修复。您的老板/客户不在乎该错误是在代码中还是在所选的库中。这里没有简单的答案，请记住，使用库既有好处，也有风险。
– DNA
2014年5月8日在22:23
两者都有好处。我应该补充一点，我确实看到了复制/粘贴10行代码与包含100s库之间的区别。如果我将代码粘贴到自己的代码中，则我应该努力尽可能地理解它，但是，在某些时候，我可能不得不接受一个事实，那就是我将无法完全理解它，而我相信这不应阻止我（或正在学习新语言的任何其他编码人员）使用其他人的代码段。当我回头看它并说：“哦！那就是代码正在做的事情！”
– reblevins
2014年5月9日15:49
@reblevins，我想您在这里没要讲。如果您使用的是某个库的API或类似的API，则应该由其他人负责确保该API根据规范工作，如果没有，请进行修复。您正在使用高级抽象。当然，您有责任阅读文档并了解其可以（或不能）做的事情以及如何正确调用它。 “复制和粘贴”是另一种动物。它是“低级”内容（内联代码），如果要使用它，您应该完全理解。
–菲尔·佩里（Phil Perry）
2014年5月12日13:13
@PhilPerry，好吧，也许我没有使用最好的例子，但是我仍然不完全同意在不理解代码的情况下复制和粘贴代码总是不好的。冒着使问题变得难以理解的风险，举一个在另一个讨论中提到的例子。如果代码包含由具有PHD数学能力的人编写的算法，该怎么办？使用它之前，我真的需要了解吗？
– reblevins
14年5月13日在18:59
#7 楼
在大多数情况下，这取决于情况。在最末端，使用了库。您不应该知道或关心它是如何工作的。您应该知道要放入什么，产生什么，可以做什么和不能做什么。在另一端，您不知道如何去做某事，因为您之前从未做过。您可以在Internet上找到十行代码，这似乎比在文档中找到正确的信息要容易得多（通常是这样）。在那时，我强烈建议现在是学习如何完成该任务的正确时机。因此，请拿起代码，理解它，然后自己编写。意识到互联网上的许多代码不一定是最聪明的人编写的，因此可能存在弱点和误解，因此，通过立即学习，您可以确保代码可以正常工作。在您将这十行包含在项目中时，它们是您的责任。如果代码不起作用，那是你的错。因此，您必须了解它，就好像您已经编写了它一样。
那么库有什么区别？那不是你的责任吗？库的代码不是。库的选择和库的用法是。如果该库每天使您的应用程序崩溃10次，那是因为您选择的库不可靠。您不必了解库的代码，但必须了解其可靠性问题并采取行动。
#8 楼
老板的建议可能会很好，但有风险。从长远来看，存在一个危险，那就是您会遇到更大的问题，而花点时间首先了解事情可以避免这种情况。如果这是一次性的事情，则风险相对较小。如果您以这种方式构建整个软件系统，那么您手上就会有滴答作响的定时炸弹。您不了解的内容是没有希望在不引起错误的情况下进行修复或更改的。另一方面，如果您不服从老板的话，您自己的工作可能会面临危险。如果您喜欢自己的工作，那么将来，在他必须参与之前，请尝试自己解决技术问题。我曾经有个老板，每当他参与技术决策时，他都会搞砸（尽管他在销售和客户关系方面很出色）。大多数技术人员学会了听他说的话，然后转身做一些不同的事情。只要软件有效，他就永远不会跟进并检查他的技术建议是否得到了切实执行。这份工作报酬不错，但我很高兴我不再在那里。
如果这种态度在您的工作地点普遍存在，我至少会考虑其他工作选择。
评论
没有工作能永远持续下去；您必须确保自己学到了什么，以便下次寻求工作时更有资格。你的老板不在乎；他只在乎自己的利润。 （优秀的老板意识到，如果您学习，它将受益于他们，因为他们可以获得更好的员工，而精明的员工会留得更长久）。
– gnasher729
2014年5月11日在1:42
@AlexD，您的老板碰巧头发很尖吗？您的同事叫沃利和爱丽丝吗？ :)
–菲尔·佩里（Phil Perry）
2014年5月12日13:15
评论
还相关：搜索文档和样本看起来不好吗？@gnat我不确定您是如何得到这两个问题的，但是它们与此完全不同。
@BЈовићmeta.stackexchange.com/questions/194476 / ...
至于微积分的例子，我认为那是很差的。当然，您可以在不了解的情况下使用微积分公式，但这不会使您成为数学家。但是也许就是我，把数学当作黑匣子是我的宠儿；）
@DavidWallace我在谈论我必须维护的代码。