软件工程

它不一定与编程或软件开发相关，而只是在面试中被问到与IT相关的工作。 我知道一些“左场”问题旨在说明应聘者如何应对意外和新颖的情况，但是在这里，我要寻找的问题似乎与他们面试您的工作完全无关，或者是您认为“他们从我对这个问题的回答中可能得到什么有用的信息？”。

38 interview 

我在一个项目中工作，该项目使用（Spring）依赖注入来处理实际上是类依赖的所有内容。我们现在已经将Spring配置文件增加到大约4000行。不久前，我观看了Bob叔叔在YouTube上的一次演讲（不幸的是，我找不到该链接），在该演讲中，他建议仅将几个中央依赖项（例如工厂，数据库等）注入到Main组件中，然后从它们分布。 这种方法的优点是将DI框架与应用程序的大部分解耦，并且还使Spring配置更干净，因为工厂将包含以前配置中的更多内容。相反，这将导致创建逻辑在许多工厂类之间传播，并且测试可能会变得更加困难。 因此，我的问题确实是，您会在一种或另一种方法中看到哪些其他优点或缺点？有没有最佳做法？非常感谢你的回答！

38 architecture  dependency-injection 

假设我提供4种服务类型（它们不太可能经常更改）： 测试中 设计 程式设计 其他 假设我有60-80个实际服务，每个服务都属于上述类别之一。例如，“服务”可以是“使用技术A的测试程序”，并且类型为“测试”。 我想将它们编码到数据库中。我想出了一些选择： 选项0： 使用VARCHAR直接直接编码的业务类型为字符串 选项1： 使用数据库enum。但是，枚举是邪恶的 选项2： 使用两个表： service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 我什至可以享受参照完整性： ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); 听起来不错，是吗？ 但是我仍然必须对事物进行编码并处理整数，即在填充表时。或者在填充或处理表时必须创建精心设计的程序或数据库结构。即，在直接处理数据库或在编程端创建新的面向对象的实体并确保我正确操作它们时，可以使用JOIN。 选项3： 不使用enum，不使用两个表，而只使用一个整数列 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …

38 database-design  efficiency  enum  normalization 

关于编译需要多长时间的战争故事不计其数。甚至xkcd都提到了它。 现在，我已经有很长时间没有编程了，并且几乎只接触过Java和Python（Python是一种解释性语言，而不是一种编译语言）。我意识到有可能我只是没有遇到过需要很长时间才能编译的项目，但是即使对于像样的应用程序，它对我来说是瞬时的（通常由IDE在后台处理）或花费不超过30个一个非常大的项目大约需要几秒钟。即使在商业环境中（发生漫画的地方），我也从来没有花太多时间来编译代码。 我只是没有接触过编译时间长的项目吗？这是过去的遗物，不再是现代发生的事情吗？为什么编译需要这么长时间？

38 compilation 

在任何给定的类定义中，我都看到了以各种方式排序的方法定义：按字母顺序排列，基于最常用用法的按时间顺序排列，按可见性分组的按字母顺序排列，按顺序将getter和setter组合在一起的按字母顺序排列的等等，当我开始编写新类时，我倾向于只输入所有内容，然后在写完整个课程后重新排序。关于这一点，我有三个问题： 顺序重要吗？ 是否有“最佳”订单？ 我猜没有，所以不同订购策略的优缺点是什么？

38 code-quality 

我想记住一个单词，我认为它与计算或数据库理论有关。最接近的同义词是，atomic但不完全是。基本上，这是一种计算，即使连续运行多次也应产生相同的结果，这意味着它不会自己产生副作用。 我在有关chmod命令（或其他一些与权限相关的操作）的堆栈溢出答案中专门遇到了这个词。 希望这足以进行下去。在Wikipedia上戳戳并没有太大帮助。

38 terminology  permissions 

什么是技术规格？它们是否与设计文件相同？如果没有，有什么区别和一些例子？

38 documentation  specifications 

我的老板目前正在尝试将一些开发标准应用到我们的团队中，因此昨天我们开会开会讨论了这些标准，在她提出之前，大部分进展顺利： 所有数据库表都将具有一个CreatedDate和LastUpdatedDate列，并通过触发器进行更新。 在这一点上，我们的团队意见分歧。我们中有一半的人认为，在所有工作台上执行此操作是一项大量工作，几乎没有收益（我们从事固定预算项目，因此任何成本均来自公司的利润）；下半年相信它将对项目的支持有所帮助。 我坚定地在前阵营。尽管我很欣赏某些外部情况会导致多余的列提高可支持性，但我认为，首先添加列所需的工作量以及维护工作将使我们花费更少的时间进行更多的工作重要的事情，例如单元测试或负载测试。另外，我相当确定这些额外的列会使使用ORM变得更尴尬-请记住，我们主要使用C＃和Oracle，但从一开始就对ORM不太满意。 因此，我的问题是双重的： 我在正确的营地吗？我并没有声称自己拥有享誉全球的数据库技能，因此这可能是一件容易的事，而且没有不利的副作用。 您将如何处理有关标准的会议演变为排渣比赛的情况？我如何才能真正卖出该标准不会长期帮助我们？

38 database  standards  meetings 

我不确定这两个术语是否可以互换使用。也许计算机科学上有一些学术上的区别与日常编程无关？还是我可以在不误的情况下互换使用这两个术语？也许这取决于我同时使用这两个术语的环境？ 编辑：关于为什么我发现两个术语可能可以互换的原因是有关抽象层的Wikipedia条目。在那里，您可以找到David Wheelers引述的“计算机科学中的所有问题都可以通过另一种间接解决方案来解决。”

38 computer-science  terminology 

通常，当我编写一个函数时，我想确保其输入有效，以便尽早检测到此类错误（我相信这些被称为前提条件）。当前提条件失败时，我总是抛出异常。但是我开始怀疑这是否是最佳做法，如果不是，则断言是否更合适。 所以我应该什么时候做：什么时候使用断言，什么时候抛出异常？

38 exceptions  assertions 

如今，几乎每个人都在其代码编辑器中使用深色方案-带有浅色文本的深色背景。甚至大多数基于Web的编辑器（例如，在Github上）都具有深色方案。 老实说，我看不到好处。人眼在明亮的背景上阅读深色文本方面要好得多。此外，当您在明亮的环境中，黑白相间的配色方案会更好。 我目前正坐在办公室里，阳光透过窗户照进来。我可以在编辑器中读取文本（白色背景上带有深色文本的gVim），但是在Linux控制台上要困难得多。对我而言，在console vim中编辑文本几乎是不可能的。 整个过程对我来说似乎有点奇怪，是由某些IDE /编辑器中的默认设置开始的。但也许我只是很奇怪..;） 无论如何，为什么每个人都在使用这些？

38 ui  text-editor  syntax-highlight 

大多数时候，我将开发应用程序配置存储在项目的根目录中，如下所示： app |-- config.json 但这似乎不是最佳方法，因为此配置最终存储在版本控制系统中-可能导致用户名，密码和其他敏感内容泄漏。 12 Factor App指南建议完全删除配置文件，并使用环境变量进行配置设置： ...将配置存储在环境变量中。Env var易于在部署之间进行更改，而无需更改任何代码。与配置文件不同，它们很少有可能被意外检入代码存储库；与自定义配置文件或其他配置机制（例如Java系统属性）不同，它们是与语言和操作系统无关的标准。 这对我来说听起来真的很不错，但是在没有将其检入源代码管理的情况下，该变量存储在哪里呢？我可以使用哪些工具将这些变量传递给应用程序？可能有数十种配置选项，每次启动应用程序时手动键入它们都不是一件好事-因此它们必须存储在某种文件中。这样，该文件将最终在源代码控制中，然后我们返回到开始的地方。 是否有一些公认的处理配置选项的方法，而没有将本地配置存储在源代码管理中的风险？

38 architecture  configuration  configuration-management 

我有一个来自客户端的规范，用于在模块中实现方法： // getGenres(): // Returns a promise. When it resolves, it returns an array. 如果给定种类， ['comedy', 'drama', 'action'] 这是一个带有承诺的框架方法： MovieLibrary.getGenres = function() { var promise = new Promise(function(resolve, reject) { /* missing implementation */ }); return promise; }; 是否可以保证返回流派中找到的数据？有没有更好的方法来实现规格说明？

38 javascript 

如果我的代码包含一个应该修复的已知缺陷，但尚未修复，并且不会在当前版本中修复，并且在可预见的将来可能不会修复，如果该缺陷中的某个单元测试失败，测试套件？如果添加单元测试，它将（显然）会失败，并且习惯于失败的测试似乎是个坏主意。另一方面，如果它是一个已知的缺陷，并且存在一个已知的失败案例，那么将其排除在测试套件之外似乎很奇怪，因为应该在某个时间点对其进行修复，并且该测试已经可以使用。

37 unit-testing  tdd 

什么是LPCTSTR和LPCTSTR-like（例如HDC）及其代表什么？

37 c++  windows