软件工程

递归的想法在现实世界中不是很普遍。因此，对于新手程序员来说似乎有些困惑。虽然，我猜他们逐渐适应了这个概念。那么，对于他们来说，如何轻松地理解这个主意呢？

74 recursion 

假设您的团队编写的软件系统运行正常（非常令人惊讶！）。 有一天，一位工程师错误地运行了一些SQL查询，这些查询更改了一些数据库数据，然后忘记了。 一段时间后，您发现损坏/错误的数据，每个人都为解决该问题的代码部分以及原因而scratch之以鼻。同时，项目经理坚持认为，我们找到了导致它的代码部分。 您如何处理？

73 project-management 

我在代码库中通常使用的一种方法是拼写错误（并且早于我）。 这不仅激怒了我，不仅因为它的拼写错误，而且更重要的是，这使我在第一次键入它时总是总是弄错名字（然后我必须记住“哦，对，应该把它拼写错了……”） 我正在对原始方法进行一些更改。我是否应该借此机会重命名怪胎法？

73 refactoring 

每当需要除法（例如条件检查）时，我都希望将除法的表达式重构为乘法，例如： 原始版本： if(newValue / oldValue >= SOME_CONSTANT) 新版本： if(newValue >= oldValue * SOME_CONSTANT) 因为我认为它可以避免： 被零除 oldValue很小的时候溢出 那正确吗？这个习惯有问题吗？

73 coding-style  language-agnostic  math 

假设我有三个相关的资源，如下所示： Grandparent (collection) -> Parent (collection) -> and Child (collection) 上面这样描述了这些资源之间的关系：每个祖父母可以映射到一个或几个父母。每个父母可以映射到一个或几个孩子。我希望能够支持针对子资源的搜索，但具有过滤条件： 如果我的客户给我传递了一个祖父母的ID参考，那么我只想搜索是该祖父母的直接后代的孩子。 如果我的客户向我传递了对父母的ID引用，我只想搜索父母直接后代的孩子。 我想到过这样的事情： GET /myservice/api/v1/grandparents/{grandparentID}/parents/children?search={text} 和 GET /myservice/api/v1/parents/{parentID}/children?search={text} 分别满足上述要求。 但是我也可以这样做： GET /myservice/api/v1/children?search={text}&grandparentID={id}&parentID=${id} 在这种设计中，我可以允许我的客户端向我传递查询字符串中的一个或另一个：grandparentID或parentID，但不能两者都传递。 我的问题是： 1）哪种API设计更RESTful，为什么？在语义上，它们的含义和行为方式相同。URI中的最后一个资源是“子代”，有效地暗示客户端正在子代资源上运行。 2）从客户的角度看可理解性以及从设计者的角度看可维护性方面，每种方法的优缺点是什么。 3）除了对资源进行“过滤”外，查询字符串的真正用途是什么？如果采用第一种方法，则将filter参数作为路径参数而不是查询字符串参数嵌入到URI本身中。 谢谢！

73 design  rest  api 

if i>0 : return sqrt(i) elif i==0: return 0 else : return 1j * sqrt(-i) VS if i>0: return sqrt(i) elif i==0: return 0 else: return 1j * sqrt(-i) 给定以上示例，我不明白为什么我实际上从来没有在代码库中看到过第一种样式。对我来说，您将代码转换为表格格式，可以清楚地显示所需内容。第一列实际上可以忽略。第二列标识条件，第三列为您提供所需的输出。至少在我看来，它直截了当且易于阅读。但是我总是看到这种简单的案例/切换情况是以扩展的，制表符缩进的格式出现的。这是为什么？人们是否发现第二种格式更具可读性？ 唯一可能出现问题的情况是代码更改并变得更长。在那种情况下，我认为将代码重构为长缩进格式是完全合理的。每个人都只是因为它总是做第二件事而做第二种吗？作为恶魔的拥护者，我想还有另一个原因可能是因为人们根据if / else语句的复杂性找到了两种不同的格式，这令人困惑？任何见识将不胜感激。

73 coding-style 

未来和承诺之间有什么区别？（在Akka和Gpars中。） 在我看来，它们既相同，又阻塞并且在调用get时返回future的值，并且承诺将获得future的结果。

73 api  scala  groovy  akka 

《代码完整》一书附有以下引文： “将正常情况放在if而不是之后else” 这意味着在这种else情况下，应该放置与标准路径的异常/偏离。 但是，实用程序员教会我们“尽早崩溃”（第120页）。 我应该遵循哪一条规则？

73 design 

情境 目前，我是一个医疗保健项目的一部分，其主要要求是使用医疗保健提供者使用用户生成的表单来捕获属性未知的数据。第二个要求是数据完整性是关键，并且该应用程序将使用40年以上。我们目前正在将过去40年的客户数据从各种来源（纸张，Excel，Access等）迁移到数据库。将来的要求是： 表单的工作流程管理 表格进度管理 基于安全/角色的管理 报告引擎 手机/平板电脑支持 情况 在短短6个月的时间里，当前的（合同制）架构师/高级程序员采用了“快速”方法，并设计了一个较差的系统。由于他已经设计了一些bean来对数据库执行“删除”操作，所以数据库未规范化，代码已耦合，层没有专用目的，并且数据开始丢失。代码库极度膨胀，并且由于数据库未标准化，因此有些作业只是为了同步数据。他的方法一直是依靠备份作业来还原丢失的数据，并且似乎不相信重构。 将我的发现提交给项目经理之后，建筑师的合同结束后将被撤职。我已经获得了重新架构此应用程序的任务。我的团队由我和一名初级程序员组成。我们没有其他资源。我们已经获得了为期6个月的冻结要求，在此期间我们可以专注于重新构建该系统。 我建议使用像Drupal这样的CMS系统，但是由于客户组织的政策原因，该系统必须从头开始构建。 这是我第一次设计使用寿命超过40岁的系统。我只从事3-5年使用寿命的项目，所以这种情况非常新，但令人兴奋。 问题 哪些设计考虑因素将使系统更“面向未来”？ 应该向客户/ PM问什么问题，以使系统更“面向未来”？

73 design  architecture  project-management  web-applications 

我对此问题持谨慎态度，因为它可能看起来过于挑剔。我刚刚打开了JavaScript：权威指南，它指出了第一章第一页的内容。 “ JavaScript是一种高级，动态，无类型的解释型编程语言” 因此，我是否认为解释部分是语言规范中的要求，还是在尊重一种语言及其多种实现之间的差异时说该语言是一种解释性编程语言是否会产生误导？ 显然没有用于JavaScript的静态编译器-https: //stackoverflow.com/questions/1118138/is-there-a-native-machine-code-compiler-for-javascript，所以也许这只是对此的一种反映。

73 javascript 

我偶然发现了一个博客条目，不鼓励在Java中使用字符串来使您的代码缺乏语义，建议您改用瘦包装器类。这是该条目提供的用于说明问题的示例的前后： public void bookTicket( String name, String firstName, String film, int count, String cinema); public void bookTicket( Name name, FirstName firstName, Film film, Count count, Cinema cinema); 根据我阅读编程博客的经验，我得出的结论是90％都是胡说八道，但是我想知道这是否是正确的观点。不知何故，我觉得不合适，但是我无法确切指出编程风格的不对之处。

73 java  coding-style  semantics 

我一直在阅读Robert Martin的“ Clean Code ”，希望成为一个更好的程序员。尽管到目前为止还没有一个真正的突破性进展，但是它使我对我设计应用程序和编写代码的方式有了不同的看法。 我不仅同意书中的一部分，而且对我没有任何意义，特别是关于接口命名约定。这是直接从书中摘录的文字。我将这方面加粗了，我感到困惑，并希望澄清。 我更喜欢不修饰界面。前面的I在当今的一堆旧书中很常见，充其量可以使人分心，而在最坏的情况下则可以提供过多的信息。我不想让用户知道我正在给他们一个接口。 也许是因为我只是一个学生，或者可能是因为我从未做过任何基于专业或团队的编程，但是我希望用户知道它是一个界面。 实现接口和扩展类之间有很大的区别。 因此，我的问题归结为：“为什么我们应该隐藏一部分代码期望接口的事实？” 编辑 回答： 如果您的类型是接口或类是您的业务，而不是使用您的代码的人的业务。因此，您不应在此第三方代码中泄漏代码的详细信息。 我为什么不“泄漏”给定类型是第三方代码的接口还是类的详细信息？对于使用我的代码的第三方开发人员来说，知道他们将要实现接口还是扩展类不是很重要吗？差异是否不如我要记住的那么重要？

73 naming  interfaces  coding-standards 

为了便于阅读，我经常发现自己在调用函数时定义了临时变量，例如以下代码 var preventUndo = true; doSomething(preventUndo); 这个的简短版本是 doSomething(true); 但是，当我回到代码时，我常常想知道true所指的是什么。这种难题是否有约定？

73 coding-style 

我正在寻找专业的程序员来帮助解决困难的情况。 到目前为止，采访令人惊讶地令人失望。到目前为止，最好的候选人是从未使用过版本控制软件的，经验丰富的程序员。 问题本身可能并不太严重，因为可以在短时间内了解到这一点。 但是还有一个更深层次的方面，这让我担心： 如何在不需要版本控制的情况下主动开发10-15年的软件？ 本身不寻找解决跟踪问题的解决方案的事实本身是否表明对编程态度不正确？

73 version-control  experience 

我认为，敏捷方法最适合需求模糊且需要大量交互以帮助塑造最终用户想法的项目。 但是...在我的专业工作中，我一直不停地被那些使用“敏捷”方法作为为什么不花精力在前期设计上的公司作为最终结果。当要求很容易理解时。 我忍不住想，如果没有敏捷方法，我会坐在这里，拥有一个很好的高级规范，而不必在第二天左右出现其他问题时隔天重新访问相同的屏幕和功能所以没有想到这一点。 敏捷方法学的好处真的足以超过给牛仔技术领导者带来la脚的借口吗？ 更新：具有讽刺意味的是，我现在是一名认证的Scrum Master。在Scrum课程上发表的一篇论文指出，最好的开发过程是只有一个专家或专家来进行设计决策的过程，但是它存在明显的弱点。Scrum将生产高质量软件的责任转移到“团队”，这意味着不合格的团队可以摆脱意大利面条的困扰，我想这与其他敏捷和非敏捷开发流程没有什么不同。

73 agile  cowboy-coding