软件工程

我知道，除了打破嵌套在循环中的循环之外，其他方法都是这样。该goto语句是易于出错的编程风格，因此一直被人们回避和谴责。 替代文字： “尼尔·斯蒂芬森（Neal Stephenson）认为给他的唱片公司定名为“ dengo”很可爱”， 请参见以下原始漫画：http：//xkcd.com/292/ 因为我很早就学到了 对于什么类型的错误goto实际上导致什么，我真的没有任何见识或经验。那么我们在这里谈论什么： 不稳定吗？ 无法维护或无法读取的代码？ 安全漏洞？ 还有其他东西吗？ 实际上，“ goto”语句会导致哪种错误？有历史上重要的例子吗？

103 coding-style  history  bug  bad-code  goto 

我是一个网络开发人员，由三个开发人员和一个设计师组成。现在，我们已经实施了五个月的敏捷Scrum软件开发方法。但是我有一种奇怪的感觉，我只想在这个网站上分享。 决策过程是人类生活中的重要因素。但是，您做出的决定有很大的不同。有些决定只是内部力量或外部力量的结果，而其他决定则完全基于您的自由意志，而某些决定只是介于两者之间。您做出决策的自由度越高，您的工作就会越自我驱动。这似乎是规则。因为我们倾向于自己塑造生活。 您决定做什么或被告知要做什么之间有很大的不同。 争球之前，我感觉自己就像做了哪些相关的发展，分析了决定，优先执行，等我有更多的感觉就像有更多的自由，我决定我在做什么。 但是，由于采用Scrum的方法论，现在许多决定只是来自产品所有者。他优先考虑PBI，他分析软件应如何工作，甚至有时应如何实现UI和功能。我知道这是Scrum方法论的一部分，我也知道这可能会导致将来更好的产品销售。但是，我现在感觉总是被告知要做某事，而不是决定做某事。现在，这种综合症使我对工作更加被动了。 我倾向于减少搜索以找到更好的解决方案，方法或技术 我不会在早上醒来，希望能得到愉快的工作。相反，我觉得自己被迫为了生存而工作 下班后我更渴望从事自己的业余爱好项目 我不会再推动团队达到更高的技术水平了 我现在花更多时间在晚餐或下午茶时间上，而对恢复工作的热情却降低了 我现在愿意为工作早日完成做好准备，以便我可以回家 最大的问题是，我也在同事中看到并诊断了这种行为。是混乱的结果吗？Scrum是否真的使开发团队感觉自己没有参与整个软件的开发，从而使项目变得被动了？我该如何克服这种感觉？

103 agile  self-improvement  scrum 

我想知道，业余时间编程有多重要？是否有必要以9-5的程序员身份工作，然后回到家并按自己的爱好工作，成为一个更好的程序员？ 这就是说，我知道您只会在编程方面变得更好。 准雇主在面试中是否考虑了业余爱好编程，还是出于好奇而问这个？ 我没有一个业余项目而感到内gui，但是我能想到的一切都已经完成了。因此，我对此有两种想法，开始做一些已经完成的事情，或者离开它直到我想出一些原创的东西？

103 skills 

软件工程师和程序员之间的主要区别是什么？

103 skills 

我了解自动测试的价值，并在问题足够明确的地方使用它，以便我可以提出好的测试用例。但是，我注意到，这里和StackOverflow上的某些人只强调测试一个单元，而不是测试其依赖项。在这里我看不到好处。 为避免测试依赖性而进行的模拟/存根增加了测试的复杂性。它在生产代码中增加了人工灵活性/去耦要求，以支持模拟。（我不同意说这会促进良好设计的任何人。写额外的代码，引入诸如依赖注入框架之类的东西，或者以其他方式增加代码库的复杂性以在没有实际用例的情况下使事情变得更灵活/可插拔/可扩展/解耦是过度设计，而不是好的设计。） 其次，测试依赖项意味着使用其他输入的测试关键的底层代码，而不是那些编写测试的人明确想到的输入。通过在高级功能上运行单元测试而不嘲笑它所依赖的低级功能，我发现了低级功能中的许多错误。理想情况下，这些可以通过单元测试中的低级功能找到，但是总是会漏掉一些情况。 另一面是什么？单元测试不要同时测试其依赖关系真的很重要吗？如果是这样，为什么？ 编辑：我可以理解模拟外部依赖项（如数据库，网络，Web服务等）的价值。（感谢Anna Lear激励我进行澄清。）我指的是内部依赖项，即其他类，静态函数等。没有任何直接的外部依赖关系。

103 testing  unit-testing  dependency-injection  mocking 

我使用了大量的元编程来避免重复的任务，并建立更安全使用的抽象。 我最近搬到了一个新工作，在一个更大的团队中工作，这让我的一些同事感到担忧，因为他们不理解。 我总是尽力利用这种语言的全部潜力，但是我的一些（并非全部）同事认为这是一种风险（有些人欢迎这种方法）。 我同意编写团队中其他人无法理解的代码是一个问题。另一方面，我们都是C ++专业开发人员，我认为我们应该追求更高的标准，而不是使用类编写C。 我的问题是，谁是对的，我该怎么办？ 澄清： 试图充分利用语言的潜力，并不意味着我在所有问题上都投入了TMP。C ++是一个工具箱，对我而言，C ++熟练程度是指能够使用包装箱中的所有工具，以及为特定工作选择合适的工具。

102 c++  meta-programming 

我已经工作了大约一年了。我主要在GUI界面中工作，该界面使用C后端的方法，但是除了返回值外，我通常不必处理它们。考虑到我们的局限性，我们的GUI结构相当合理。 我的任务是向程序的命令行部分添加功能。这些功能大多数都长达300行，难以使用。我正在尝试收集其中的一些信息以获取特定的警报信息，但在保持井井有条的过程中遇到了麻烦。我知道我要通过一个长函数来使测试变得更加复杂。 我应该按照现有功能的样式将所有功能都保留在一个巨大的功能中，还是应该将警报封装在它们自己的功能中？ 我不确定是否适合违反当前的编码约定，或者我是否应该硬着头皮让代码编写自己的代码更加混乱。 总而言之，我正在比较 showAlarms(){ // tons of code } 反对 showAlarms(){ alarm1(); alarm2(); return; } alarm1(){ ... printf(...); return; } 编辑：谢谢大家的建议，我决定我将设计我的分解代码，然后询问他们想要什么，如果他们想要全部融合在一起，我可以从分解的代码中切下来，然后将其重新变成1大功能。即使他们希望所有代码都在一个定义中，这也应该允许我编写它并更轻松地对其进行测试。 更新：他们最终对分解式代码感到满意，并且有一个以上的人感谢我树立了这一先例。

102 coding-style  conventions 

我一直在工作中严格遵循DRY原则；每次我由于懒惰而重复编写代码时，都会在以后需要在两个地方维护该代码时再次出现。 但是我经常写一些小的方法（可能是10到15行代码），这些方法需要在两个不能互相引用的项目中重用。该方法可能与网络/字符串/ MVVM等有关，并且是一种通用的有用方法，并不特定于它最初所在的项目。 重用此代码的标准方法是为可重用代码创建一个独立的项目，并在需要时引用该项目。问题在于，我们最终遇到了两种不理想的情况之一： 我们最终得到了数以百计的小项目-每个小项目都包含我们需要重用的小类/方法。.DLL仅需少量代码就可以创建一个全新的应用程序吗？ 我们最终完成了一个项目，其中包含越来越多的不相关方法和类。这种方法是我曾经工作过的公司所做的。他们有一个名为的项目base.common，其中包含用于我上面提到的事情的文件夹：联网，字符串处理，MVVM等。它非常方便，但是不必要地将其与所有不需要的无关代码一起拖到它。 所以我的问题是： 软件团队如何最好地在项目之间重用少量代码？ 我特别感兴趣的是，如果有人在一家在这方面有政策的公司工作，或者像我本人那样亲自遇到了这个难题。 注意：我对“项目”，“解决方案”和“参考”一词的使用来自Visual Studio .NET开发的背景。但是我敢肯定，这个问题与语言和平台无关。

102 project-management  code-reuse  projects-and-solutions  dry 

虽然大多数面试问题都集中在候选人的当前知识或检查他/她解决算法问题的技能上，但我想聘请一个热衷于编程的开发人员。 如果不问类似的问题怎么办 您对技术“ X”了解多少？ 我将检查与解决软件工程问题不直接相关的知识，但会显示您对IT充满好奇。 例如，如果我寻找一名Java开发人员，我可以询问谁是Java世界上最有影响力的人，或者显示一个基本的Scala代码段，并请候选人解释该代码。 我什至考虑展示Alan Turing的照片，并让受访者猜谁在照片上。这种做法有意义吗？

102 interview 

最近的错误修复要求我检查其他团队成员编写的代码，在这里发现了这一点（它是C＃）： return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0; 现在，有充分的理由进行所有这些强制转换，这仍然很难遵循。计算中有一个小错误，我不得不解开它以解决问题。 我从代码审查中知道了此人的编码风格，他的方法是较短的总是更好。当然，这里还有价值：我们都已经看到了不必要的复杂的条件逻辑链，这些逻辑可以与一些位置合理的运算符一起整理。但是他显然比我更擅长追随运营商，他们陷入了一个单一的问题。 当然，这最终是样式问题。但是，是否有任何关于识别代码简洁性不再有用并成为理解障碍的观点的写作或研究？ 进行强制转换的原因是实体框架。数据库需要将它们存储为可空类型。小数？不等同于C＃中的Decimal，需要进行强制转换。

102 c#  coding-style  code-quality  clean-code 

在我的职业生涯中，我注意到一些开发人员不使用调试工具，而是对错误代码进行抽查以找出问题所在。 虽然很多时候无需调试器就能快速找到代码错误是一项很好的技能，但是当调试器很容易发现诸如错字之类的小错误时，花费大量时间查找问题似乎效率不高。 如果没有调试器，是否可以管理复杂系统？这是明智的吗？使用“ 心理调试 ” 有什么好处？

101 debugging 

我正在研究开放源代码框架的源代码，在该代码中我看到了多次提到的变量“有效负载”。有什么想法代表“有效载荷”吗？

101 terminology  variables 

“ 重塑方向盘 ”反模式非常常见-无需使用现成的解决方案，而是从头开始编写自己的解决方案。代码库不必要地增长，执行相同功能但接口略有不同的接口略有不同，浪费了时间来编写（和调试！）易于使用的功能。我们都知道这一点。 但是在频谱的另一端。如果不编写包含两行代码的函数，而是导入框架/ API /库，实例化，配置，将上下文转换为框架可接受的数据类型，然后调用一个可以完全满足您需要的函数，千兆字节抽象层下的两行业务逻辑。然后，您需要使该库保持最新状态，管理构建依赖关系，使许可证保持同步，并且其实例化代码比“重新发明轮子”要长十倍且更复杂。 原因可能多种多样：无论成本高低，管理层都严格反对“重新发明轮子”，尽管与要求之间存在边际重叠，有人推销他们所钟爱的技术，该系统以前主要模块的作用减弱，或者期望扩展和扩大使用这个框架，它永远不会到来，或者只是误解了“重量”，而一些导入/包含/加载指令却是“幕后”。 这种反模式有通用名称吗？ （无论是对还是错，或者它是一个真正的反模式或基于观点的任何内容，我都不会尝试进行讨论，这是一个简单明了的客观术语。） 编辑：建议的“重复项”讨论过度设计自己的代码以使其“为一切准备就绪”，完全与外部系统分开。在某些情况下，它可能源于此，但是通常它源于“厌恶重塑轮子”-不惜一切代价进行代码重用；如果存在解决问题的“现成”解决方案，则无论解决方案的适用性和成本如何，我们都将使用它。原则上赞成创建新的依赖项而不是代码复制，而与创建和维护新代码的成本相比，完全不考虑这些依赖项的集成和维护成本。

101 naming  anti-patterns 

目前，当我的网页首次加载时，我创建了一个数据库连接。然后，我处理页面并针对该连接运行任何查询。这是最好的方法吗？还是应该在每次运行查询时都创建数据库连接？ ps对我来说，创建1个连接并使用它更有意义，但我不知道这是否会引起任何其他问题。 我在MSSQL中使用C＃（ASP.NET）。

101 c#  database  sql-server 

我经常在C和C ++代码中看到以下约定： some_type val; val = something; some_type *ptr = NULL; ptr = &something_else; 代替 some_type val = something; some_type *ptr = &something_else; 最初，我认为这是从必须在范围的顶部声明所有局部变量的日子起遗留下来的习惯。但是我学会了不要这么快就消除资深开发人员的习惯。因此，是否有充分的理由在一行中声明并在事后分配？

101 c++  c