软件工程

在Go语言教程中，他们解释了界面如何工作： Go没有课程。但是，您可以在结构类型上定义方法。该方法接收器出现在FUNC关键字和方法名之间自身的参数列表。 type Vertex struct { X, Y float64 } func (v *Vertex) Abs() float64 { return math.Sqrt(v.X*v.X + v.Y*v.Y) } 接口类型由一组方法定义。接口类型的值可以包含实现那些方法的任何值。 这是在Go中创建界面的唯一方法。Google进一步说明： 类型通过实现方法来实现接口。没有明确的意图interface声明（即声明）。 隐式接口将实现程序包与定义接口的程序包分离：两者都不依赖彼此。 它还鼓励定义精确的接口，因为您不必查找每个实现并使用新的接口名称对其进行标记。 所有这些听起来都像C＃中的扩展方法，但是Go中的方法是残酷的多态的。它们将在实现它们的任何类型上运行。 Google声称这鼓励快速发展，但是为什么呢？您是否放弃了C＃中的显式接口而放弃了某些东西？C＃中的扩展方法能否允许人们从Go接口中获得C＃的某些好处？

21 c#  language-design  go 

一个asm.js应用程序非常快（接近本地C ++速度）： http://kripken.github.io/mloc_emscripten_talk/micro4b.png 但是，如何用C ++编写代码，将其转换为LLVM代码，然后使用emscripten / asm.js进行一些技巧呢？我还没有找到关于它的任何教程。 如果我用C ++编写代码，那么如何使用js API-s，例如XMLHttpRequest，WebSockets，Canvas或WebGL？

21 c++  javascript  llvm 

我具有强大的OO背景，并且我最近开始在一个组织中工作，尽管该代码是用Java编写的，但与过去相比，我对良好的OO设计的重视程度要低得多。有人告诉我，我引入了“太多的抽象”，而我应该以一直采用的方式编写代码，这是Java中的一种过程样式。 TDD在这里也不太常用，但是我想拥有可测试的代码。在大型“神类”（这似乎是该团队的常态）中以静态私有方法掩埋业务逻辑不是很可测试的。 我很难向同事清楚地传达自己的动力。有谁对我如何说服我的同事使用OO和TDD导致更容易维护的代码有任何建议？ 这个问题有关技术债务是关系到我的问题。但是，我试图避免首先产生债务，而不是在另一个问题所涵盖的事实之后偿还债务。

21 java  object-oriented  teamwork  communication  maintainability 

FP支持者声称并发很容易，因为它们的范例避免了可变状态。我不明白 想象一下，我们正在使用FP创建一个多人地下城抓取（类似于Rogue），其中我们强调纯函数和不可变数据结构。我们生成一个由房间，走廊，英雄，怪物和战利品组成的地牢。我们的世界实际上是结构及其相互关系的对象图。随着事物的变化，我们对世界的表示也会进行修改以反映这些变化。我们的英雄杀死一只老鼠，捡起短剑，等等。 对我而言，世界（当前现实）带有这种状态观念，而我却缺少FP如何克服这种状况。当我们的英雄采取行动时，功能会改变世界状况。似乎每个决定（人工智能或人为决定）都需要基于当前的现状。我们在哪里允许并发？我们不能同时有多个进程来修改世界状态，以免一个进程的结果基于某个过期状态。在我看来，所有控制都应在单个控制循环中进行，以便我们始终在处理由当前当前对象图表示的当前状态。 显然，有些情况非常适合并发（例如，在处理状态彼此独立的孤立任务时）。 我没有看到并发在我的示例中如何有用，这可能是问题所在。我可能以某种方式歪曲了这一主张。 有人可以更好地代表这一主张吗？

21 functional-programming  concurrency  state 

我目前在一个中型的Web开发人员团队中。我们正在使用jira进行错误跟踪。 我们正在开发频繁更改版式的产品。很多时候，在某些浏览器中都会提交有关布局中的错误的错误。有时，当我们开始处理低优先级错误时，布局已经更改，不再适用。 我们应该怎么关闭它？ 我的意思是我们应该如何对待这些问题？尽管Jira是我们使用的错误跟踪软件，但我对如何处理这类问题更感兴趣。 有关系吗 （我们可能稍后再返回布局，但这不太可能）

21 issue-tracking  jira 

我正在处理一个处理请求的项目，该请求有两个组件：命令和参数。每个命令的处理程序非常简单（<10行，经常<5）。至少有20条命令，可能会超过50条。 我提出了一些解决方案： 一个大的开关/ if-else命令 命令到功能的映射 命令到静态类/单的映射 每个命令都进行一点错误检查，唯一可以抽象的位是检查为每个命令定义的参数数量。 什么是解决此问题的最佳解决方案，为什么？我也愿意接受我可能错过的任何设计模式。 我为每个提出了以下优点/缺点列表： 开关 优点 将所有命令保持在一个功能中；由于它们很简单，因此使其成为可视化查找表 不需要使用大量只会在一个地方使用的小功能/类来弄乱源代码 缺点 很长 难以以编程方式添加命令（需要使用默认大小写进行链接） 映射命令->功能 优点 一口大小的小块 可以以编程方式添加/删除命令 缺点 如果在线完成，则外观与开关相同 如果没有在线完成，很多功能只能在一个地方使用 映射命令->静态类/单例 优点 可以使用多态来处理简单的错误检查（仅3行，但仍然） 与map类似的好处->功能解决方案 缺点 很多非常小的班级将使项目混乱 实施并非都在同一个地方，因此扫描实施并非易事 额外说明： 我正在用Go编写此代码，但是我认为解决方案不是特定于语言的。我正在寻找一个更通用的解决方案，因为我可能需要用其他语言做一些非常相似的事情。 命令是字符串，但是如果方便的话，我可以轻松地将其映射为数字。函数签名类似于： Reply Command(List<String> params) Go具有顶级功能，而我正在考虑的其他平台也具有顶级功能，因此第二个和第三个选项之间的区别。

21 design  design-patterns  map  switch-statement 

我在一个产品组中有一个产品集合，例如： product-groups/123/products 如果我需要添加到集合中，可以通过PUT 只传递某些产品吗？ 如果我需要从集合中删除某些产品，可以通过DELETE 传递过滤器数据（ID数组）吗？ 秉承ReST精神实现功能的最佳方法是什么？ 编辑：项目是指向单独实体（基本上是产品ID）的链接。

21 rest  collections 

关于我们在团队中实施的单元测试，我一直在遇到越来越烦人的问题。我们正在尝试将单元测试添加到设计不良的旧代码中，尽管我们在实际添加测试方面没有遇到任何困难，但是我们开始为测试的结果而苦恼。 作为问题的一个示例，假设您有一个方法在执行过程中调用了5个其他方法。此方法的测试可能是确认是否由于调用这5个其他方法之一而导致了行为。因此，由于单元测试应该仅出于一个原因和一个原因而失败，因此您希望消除调用这四种方法并对其进行模拟而导致的潜在问题。大！执行单元测试，忽略模拟的方法（它们的行为可以作为其他单元测试的一部分进行确认），并且验证有效。 但是存在一个新问题-单元测试对您如何确认将来行为和任何其他4种方法的签名变化或需要添加到“父方法”的任何新方法有深入了解。导致必须更改单元测试以避免可能的故障。 自然地，可以通过简单地使更多的方法完成更少的行为而在某种程度上缓解该问题，但是我希望可以找到一个更优雅的解决方案。 这是捕获问题的示例单元测试。 简要说明一下，“ MergeTests”是一个单元测试类，它继承自我们正在测试的类，并根据需要覆盖行为。这是我们在测试中采用的“模式”，允许我们覆盖对外部类/依赖项的调用。 [TestMethod] public void VerifyMergeStopsSpinner() { var mockViewModel = new Mock<MergeTests> { CallBase = true }; var mockMergeInfo = new MergeInfo(Mock.Of<IClaim>(), Mock.Of<IClaim>(), It.IsAny<bool>()); mockViewModel.Setup(m => m.ClaimView).Returns(Mock.Of<IClaimView>); mockViewModel.Setup( m => m.TryMergeClaims(It.IsAny<Func<bool>>(), It.IsAny<IClaim>(), It.IsAny<IClaim>(), It.IsAny<bool>(), It.IsAny<bool>())); mockViewModel.Setup(m => m.GetSourceClaimAndTargetClaimByMergeState(It.IsAny<MergeState>())).Returns(mockMergeInfo); mockViewModel.Setup(m => m.SwitchToOverviewTab()); mockViewModel.Setup(m => m.IncrementSaveRequiredNotification()); mockViewModel.Setup(m …

21 c#  testing  unit-testing  mocking 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 我的老板发现我不像他想的那样聪明。 以我的经验为例： 我是一名初级程序员，并且由两个人（老板（高级程序员）和我自己）组成。 我的任务是为我们工作的公司开发内部Web应用程序。我将后端写到了前端（数据库设计已经到位，服务器技术已经被选择）。他会通过观察Web应用程序的运行情况来定期检查我的进度，并对它的出现感到高兴。当我完成网络应用程序时，他对最终产品的性能感到满意。 几天前，他对代码产生了兴趣，所以我告诉他我使用了哪些技术（用于前端），这就是它的发展方向。对于Web应用程序的前端，我使用了Javascript框架（Backbone.js）。当被问到为什么我会做这样的事情。我的回答是因为我觉得该框架非常适合该应用程序，并且比起我从头开始编写代码，它可以帮助我更好地构建代码。 因此，给出此示例，我的问题是： 如果您是一名高级程序员，并且对初级程序员的能力失去了信心，那么您希望从初级中看到什么以重新获得信心？ 编辑：谢谢大家的出色回答和支持性反馈！

21 self-improvement  junior-programmer 

除了偶尔的工厂和MVC之外，我不经常使用设计模式，我想更多地使用它们。 我手头有一个具体案例，希望您对在这种情况下使用设计模式有意见。 在我的应用程序中，我不得不经常在不同情况下转换对象。我可能必须将Hibernate POJO转换为DTO，因为我使用GWT，并且Hibernate POJO不能序列化，也不能通过线路发送。 在另一种情况下，我可能需要将Java对象转换为SolrInputDocument的对象，以便由Solr进行索引。 我想知道是否应该为此使用设计模式。看来“对象转换”是一种通用任务，可以通过一种模式以灵活/抽象的方式进行处理，但是我真的不知道如何实现。 如果没有模式，我只会为每种转换类型创建一个单独的类，例如CourseToSolrInputDocument（Course是我的应用程序中的Hibernate实体）。或CourseToCourseDTO。这些转换类中的每一个都可能具有一个称为的静态方法convert()，该方法将源对象作为输入并返回输出对象。 但这不是一个真正的模式，对吗？因此，我从泛型入手，并创建了实现Converter接口的此类。但是以某种方式感到傻傻的创建了一个通用的接口，除了能够祝贺自己使用通用外，我没有真正的优势。 public class CourseToSolrInputDocument implements Converter<Course, SolrInputDocument> { @Override public void convert(Course source, SolrInputDocument destination) { //To change body of implemented methods use File | Settings | File Templates. } } 因此，这里的真正问题是：是否存在适用于通用对象转换的模式？您的方法是什么？与仅使用每个转换类的类型方法相比，优点是什么？

21 java  design-patterns  object 

在我目前的工作中，我曾几次被要求清理旧代码。通常，代码是迷宫式的，其背后的数据甚至更复杂。我发现自己将事情整理成漂亮，整洁的模块化方法。每种方法都做一件事并且做得很好。那时候事情开始往南走... 最终，我总是得到一个干净的API，并且没有真正的方法将它们捆绑在一起。解决方法是编写一个大的丑陋的“粘合”方法（通常充满条件语句），该方法最终调用我所有的“清洁”方法。 胶水方法通常最终是我试图清除的代码/数据缠结的简洁版本。它通常更具可读性，但仍然很烦人。 如何避免这种方法？这是数据纠结的征兆还是我做错事情的反映？

21 design-patterns  object-oriented  programming-practices  ruby 

我们开发基于社交的移动应用程序。每个应用程序都使用RESTful API Web服务。实施登录时，我通常将用户名和密码存储在设备上的某个位置。然后，我发送给他们，作为回应，我可以访问我的个人资料。但是我也知道还有另一种方法。 一个人用一种特定的算法生成令牌，然后发送令牌而不是用户名和密码来获得访问权限。 我应该如何实施？除登录外，我是否应将此令牌与其他所有请求一起发送？

21 mobile  rest  login 

有人向我解释说，由于在敏捷开发中，策略和应用程序逻辑应该比持久性方法之类的细节更为重要，因此持久性决策应该在最后做出。因此，从简单的持久性（例如平面文件）开始可能是一个好主意，直​​到我们意识到该方法的弱点显而易见，然后才更改持久性（例如，使用关系数据库）。 这是真的吗？还是我误解了这个概念？这是敏捷团队通常如何构建应用程序吗？有什么理由？何时不应该采用这种方法？

21 architecture  agile  database  persistence 

我在develepors团队中很新。 我需要一些强有力的论据和/或“陷阱”示例，因此我的老板将最终了解Unobtrusive JavaScript的优势，以便他和团队中的其他成员停止这样做： <input type="button" class="bow-chicka-wow-wow" onclick="send_some_ajax(); return false;" value="click me..." /> 和 <script type="text/javascript"> function send_some_ajax() { // bunch of code ... BUT using jQuery !!! } </script> 我建议使用一种非常常见的模式： <button id="ajaxer" type="button">click me...</button> 和 <script type="text/javascript"> // since #ajaxer is also delivered via ajax, I bind events to document …

21 design-patterns  javascript  jquery 

我是GitHub和VCS的新手。我多年来一直使用各种语言进行编程，但是我一直在自定义项目（未公开发布）中一直独自工作。我最近开始在我正在研究的项目中使用从GitHub下载的jQuery UI小部件。该存储库不再由原始作者维护。另一个fork已合并了一些原始的请求请求。这是我分叉的那个。 我发现了几个错误，并提出了相应的修复程序。我想提供这些修复程序，但是我还想作很多其他更改，供我们自己使用，这些更改将破坏某些现有功能。另外，我想从另一个分支中引入一个想法。 我仍在学习GIT和GitHub，并试图找出解决所有问题的最佳方法。我已经阅读了很多有关不同概念/任务的文章（在这里，SO，GitHub帮助页面，Pro Git）：工作流，合并，拉取请求，挑选，重新设置，分支。我的灰质是游泳，所以我需要开始这样做，这样我才能更好地了解自己阅读的内容。 主要问题： 我想（在某处）我读到您一次只能在一个分支上有一个请求请求。那么这是否意味着我应该为每个错误提供一个单独的分支，然后为每个错误执行一个单独的提取请求？ 我想清理空白问题，而且我似乎还记得读过，最好在单独的提交中执行此操作。我应该在我的主数据库还是在另一个分支中进行此操作？我不想对如此琐碎的事情进行拉取请求，但是如果我在分支之前进行空格更改，这会影响对错误修复的拉取请求吗？一些fork进行了空格清理，这实际上使diff变得毫无用处。 我当时想用叉子创建问题，以作为记录bug的一种方式，即使我已经针对它们进行了修复。这是一个好主意吗？如何将问题，提交和合并合并到主节点？如果我向上游发出拉取请求，我的问题也会出现在上游还是会丢失该文档链接？我无法针对上游仓库打开问题（没有问题标签）。 在我想使用他的想法时，最好的办法是赞扬另一个叉子作者？我无法完全使用他的代码，尤其是因为他的更改是针对较旧版本的上游应用的，并且与我的其他更改不兼容。但是我想用这个主意，我想在应得的信贷额上给予好评。我应该只在提交消息中链接到他的回购（或个人资料或特定提交）吗？ 更改自述文件和主文件顶部的DocBlock的礼节是什么？可以进行更改，添加我的名字，添加指向我的repo和演示的链接，删除指向原始演示的链接（因为我的fork最终将与原始版本不兼容）吗？当然，我将保留原始作者姓名和许可证信息。作为记录，它已获得MIT许可。 作为从未使用过VCS的独立开发人员，我习惯于重写历史记录。我是一个完美主义者，喜欢事物要整洁。记录历史的想法使我有点紧张，我想第一次做对。我创建了一个新的供您玩耍/学习的仓库，但是我急于继续固定jQuery UI小部件，以便继续进行我的项目。

21 open-source  github  workflows  etiquette