软件工程

摘自《 Java Magazine》最近一期对Kent Beck的采访： Binstock：让我们讨论微服务。在我看来，微服务的测试优先会变得复杂，因为某些服务要正常运行就需要大量其他服务。你同意吗？ 贝克：上一堂大班或上几堂小班，似乎是一组折衷方案。 Binstock：是的，除了我猜，在这里，您必须使用大量的模拟程序，以便能够建立一个可以测试给定服务的系统。 贝克：我不同意。如果它是命令式样式，则必须使用很多模拟。在一种功能样式中，外部依赖项在调用链中被聚集在一起，那么我认为这不是必需的。我认为您可以从单元测试中获得很多覆盖。 他什么意思？函数样式如何使您摆脱对外部依赖的嘲笑？

10 functional-programming  tdd  mocking 

当前，我们有一个经典的n层应用程序：DB / Web服务/前端。它具有其他组件，但这是基本布局。 我们要提高应用程序可用性的原因有3个： 我们的主机有时会遇到中断（就像它们一样），我们希望最大程度地减少对客户的影响，因此，例如，如果数据中心A关闭，他们将打开数据中心B。 升级版本时，我们会关闭站点进行维护，通常需要几个小时（迁移脚本等）。我们希望用户进行更无缝的过渡，并尽可能减少停机时间（他们在升级服务器A时使用服务器B）。 可选地，我们的客户遍布世界各地，尽管他们之间的联系不畅，我们希望他们能获得最好的体验（与印度开发人员合作的任何人都应该明白我的意思）。理想情况下，我们希望能够在其办公室中插入服务器（或使用其所在城市附近的数据中心），并将其无缝集成到我们的体系结构中。 我们远程不需要99％的可用性，甚至不需要95％的可用性。这是一个文档管理应用程序。没人在乎。但是，由于迁移可能需要一段时间，并且世界各地都有客户，因此有时我们会阻止客户在一天的大部分时间里工作。 对于SQL部分，即使没有“适当的” DBA，我们也了解SQL的可能性：复制，镜像等。在DB端，为此很容易找到资源。还有什么更困难的了：存储会话，代码等。如果我的Web服务服务器出现故障，我的UI如何知道它必须切换？我的会话如何在服务器之间持久化？ 不幸的是，我们都没有这方面的经验，我们甚至都不知道从哪里开始。是否有最佳做法？设计模式？图书馆（应该是免费的，因为我们没有钱）？ 我们使用的是ASP.Net和SQL Server，中间是WCF Web服务。我们有很多Windows服务，但它们不是关键任务，我认为处理网站的方法将适用于这些服务。 我知道大多数云平台都为此提供了内置系统，但是由于我们的系统管理员，云托管是行不通的，他想自己管理一切而不依赖任何人。

10 architecture  architectural-patterns 

我正在创建REST API，目前，我遇到以下问题： Foo是第一资源。可以通过/foo/URI 应用CRUD操作。 Bar是第二资源。可以通过/bar/URI 应用CRUD操作。 每个Foo都与零或一相关联Bar。之所以不将其Bar视为的子资源，Foo是因为Bar可以在Foo多个s 之间共享同一实例。因此，我认为最好通过独立的URI而不是通过URI访问它/foo/[id]/bar。 我的问题是，在很多情况下，请求Foo实例的客户端也对关联的Bar实例感兴趣。当前，这意味着他们必须执行两个查询而不是一个。我想介绍一种允许通过单个查询获取两个对象的方法，但是我不知道如何为此建模。到目前为止，我想出了什么： 我可以引入类似于以下内容的查询参数：/foo/[id]?include_bar=true。这种方法的问题在于，响应的资源表示形式（例如JSON结构）将需要看起来不同（例如，容器{ foo: ..., bar: ... }而不是仅序列化的容器Foo），这会使Foo资源端点“异构”。我不认为这是件好事。查询时/foo，无论查询参数如何，客户端都应始终获得相同的资源表示形式（结构）。 另一个想法是引入一个新的只读端点，例如/fooandbar/[foo-id]。在这种情况下，返回像这样的表示形式没有问题{ foo: ..., bar: ... }，因为那样的话，它只是fooandbar资源的“正式”表示形式。但是，我不知道这样的辅助端点是否真的是RESTful的（这就是为什么我在问题的标题中写了“ can”的原因。当然，从技术上讲这是可能的，但是我不知道这是一个好主意）。 你怎么看？还有其他可能性吗？

10 rest  web-api  resources 

我对此进行了大量研究，但我仍然很困惑。 我目前正在从事与Arduino兼容的软件项目。该项目是开源的，所以我希望其他人也可以使用它，但是我不希望他们使用封闭源代码的许可证来创建衍生作品。我希望他们承认他们在我的项目中使用的任何代码均源自我的工作，并要求他们也将其衍生工作保持开源。 同时，我可能希望将来在不公开源代码的项目基础上创建作品-例如，我希望能够在私有的不公开源代码咨询公司中使用自己的作品。 我认为GPL将是最适合第一部分的许可证。我的问题是，第二部分将涵盖哪些许可证？我可以使用GPL双重许可该许可吗？

10 licensing  gpl  closed-source 

在Java和C＃中，您可以创建具有可在初始化时设置的属性的对象，方法是定义带参数的构造函数，构造对象后定义每个属性，或使用builder / fluid接口模式。但是，C＃3引入了对象和集合初始化程序，这意味着构建器模式在很大程度上没有用。在没有初始化程序的语言中，可以实现一个生成器，然后像这样使用它： Vehicle v = new Vehicle.Builder() .manufacturer("Toyota") .model("Camry") .year(1997) .colour(CarColours.Red) .addSpecialFeature(new Feature.CDPlayer()) .addSpecialFeature(new Feature.SeatWarmer(4)) .build(); 相反，在C＃中，可以这样写： var vehicle = new Vehicle { Manufacturer = "Toyota", Model = "Camry", Year = 1997, Colour = CarColours.Red, SpecialFeatures = new List<SpecialFeature> { new Feature.CDPlayer(), new Feature.SeatWarmer { Seats = 4 } …

10 c#  object-oriented  builder-pattern 

最近，我开始玩node.js。 现在，每个节点教程都指出您应该从 npm init 然后，说您想要一些标准的服务器框架，说您选择express： npm install express 但是您会想要从ASP.NET这样的世界中获得更多习惯。 我谈论模板引擎（Jade）和样式表预处理器（SASS）。 然后他们告诉您“安装gulp / grunt！这样您就可以自动最小化和丑化并运行服务器以及许多其他东西！” 这意味着安装gulp，node-sass和gulp-sass和gulp-uglify，以及一些更酷的东西（tsd或babel，markdown等）... 但是所有这些都在您的磁盘和项目上很繁重。不要浪费时间，您可以轻松地找到该项目的100MB +磁盘大小（甚至还没有开始！），更不用说10000+个文件了，因为每个节点模块都具有自己的依赖性，无论相同依赖关系被另一个模块使用。移动到任何地方都是一件非常困难的事情，更不用说Web服务器了。 我想念什么吗？我认为，在存在如此明显的缺陷的同时，对节点环境给予如此多的赞扬是不可能的。我是否期望太多（毕竟我确实曾经尝试过一次使用许多工具），Node退伍军人知道有什么琐碎的事情可以绕过它吗？

10 node.js  dependency-management 

从SO的这个问题中，我读到： 专有源代码+ LGPL源代码 静态链接： 您必须将两个零件都作为LGPL发行。 或提供一切使用户可以将应用程序与另一版本的LGPL源代码重新链接的功能。在这种情况下，其他要求与动态链接一样。 因此，就静态地将LGPL库链接到专有代码应用程序而言，听起来确实提供目标文件足以满足LGPL的要求。当可执行文件被静态链接时，提供目标文件可以使最终用户重新编译应用程序，从而链接到库的不同版本。 这是正确的吗？如果不正确，为什么呢？

10 lgpl  static-linking 

我是DDD的相对新手，但是我正在阅读任何东西，只要我能动手实践并提炼出我的知识即可。 我遇到了这个DDD问题，答案之一吸引了我。 DDD有界的上下文和域？ 在一个答案中，张贴者给出了一个电子商务系统的示例，其中产品至少在两个域中： 1）产品目录2）库存管理 好的，这一切都有道理，即在您的电子商务前端中，您对显示产品信息感兴趣，而对库存管理不感兴趣。 但。您可能要在网页上显示库存水平，或者要显示库存的版本号（假设库存是书籍，杂志等）。此信息来自库存域。 那么，您将如何处理呢？你会 a）加载产品域和库存域聚合？b）您是否会在“产品”域实体上保留一些属性，以用于库存数量和库存版本，然后在“库存”实体更新时使用“域事件”来更新这些属性？ 最后一个问题。我知道我们注定要忘记/忽略域的持久性，而只需考虑域。但是，请仔细考虑一下，在上面的示例中，我们最终可能会有2个DB表用于产品目录和产品库存。现在，我们在这些产品中使用相同的标识符吗？或者，我们可以对数据使用1个表行还是1个表行，并简单地将相关数据映射到聚合属性上？

10 domain-driven-design  domain-model 

在阅读Mary Rose Cook的《函数式编程实用入门》时，她以反模式为例。 def format_bands(bands): for band in bands: band['country'] = 'Canada' band['name'] = band['name'].replace('.', '') band['name'] = band['name'].title() 以来 该功能不只是一件事 名称不是描述性的 它有副作用 作为建议的解决方案，她建议通过管道传递匿名函数 pipeline_each(bands, [call(lambda x: 'Canada', 'country'), call(lambda x: x.replace('.', ''), 'name'), call(str.title, 'name')]) 但是，在我看来，这具有无法测试的缺点。至少format_bands可以进行单元测试以检查它是否符合预期，但是如何测试管道？还是说匿名函数如此不言自明以至于不需要对其进行测试？ 我为此的实际应用程序是尝试使我的pandas代码更具功能性。我经常会在“ munging”函数中使用某种管道” def munge_data(df) df['name'] = df['name'].str.lower() df = df.drop_duplicates() return df 或以管道样式重写： …

10 python  unit-testing 

在实施我们的API时，出现了日期时间和时区的问题。 所有日期均已标准化为数据库中的UTC。当前，在非API应用程序中，所有日期时间都是根据用户的偏好设置先转换后才呈现。 现在，对A​​PI提出了同样的问题：API是否应该能够基于请求语义返回适合时区的datetime？ 例如GET /posts?timezone=America/Sao_Paulo？ 还是应该在正在访问API的任何客户端上完成此操作？ 更新：因为它出现了几次：当前返回带有时区的时间戳（尽管始终为TZ offset +00:00）。格式是流行的8601：2015-10-29T23:00:49+00:00

10 rest  api  time 

如维基百科所述，我正在研究调车场算法。 与运算符打交道时的算法描述如下： 如果令牌是运算符，则为o1，则： 而在运算符堆栈的顶部有一个运算符令牌o2，或者 o1 is left-associative and its precedence is less than or equal to that of o2, or o1 is right associative, and has precedence less than that of o2, 然后将o2从运算符堆栈中弹出，进入输出队列； 将o1推入操作员堆栈。 但是，他们给出了以下示例： 输入： sin max 2 3 / 3 * 3.1415 当算法命中/令牌时，对应该发生的情况的描述如下： Token | Action | Output …

10 algorithms  operator-precedence  shunting-yard 

C＃的一般指导原则是始终在公共领域使用属性。这很有意义-通过公开一个字段，您将公开许多实现细节。通过一个属性，您可以封装该详细信息，从而使其在使用代码中不会被隐藏，并且实现更改与接口更改脱钩。 但是，我想知道在处理readonly关键字时有时是否存在此规则的有效例外。通过将此关键字应用于公共领域，可以额外保证：不变性。这不仅是实现细节，不变性是用户可能感兴趣的东西。使用readonly字段使其成为公共合同的一部分，并且在将来的更改或继承中也不会破坏，而不必修改公共接口。那是财产所不能提供的。 那么，readonly在某些情况下，确保不变性是在属性上选择字段的合法理由吗？ （为澄清起见，我当然不是说您应该总是仅因为该字段恰好是不可变的而做出此选择，只有当该字段作为类设计的一部分是有意义的并且打算将不可变性包括在其合同中时才使用。我最感兴趣的答案是侧重于此是否合理，而不是在某些情况下不合理（例如，当您需要将该成员放在interface或希望进行延迟加载时）。

10 c#  immutability  properties 

假设我有一个使用知识共享许可的博客。此类许可证将显示在每页底部，并带有指向实际许可证的链接等。 但是，显然，知识共享许可并不真正适合于软件或源代码的分发，那么，可以成为博客文章一部分的任何代码（例如，片段/片段甚至完整程序）怎么办？ 如果我选择以GPLv3的形式发布此代码，那么在页面底部是否可以接受并且足够清楚地表明：“ Foo先生的此网站是根据知识共享而发布的，除了任何源代码片段/片段/样本形式的源代码，这些代码在GPLv3下发布？ 还是有更好/不同/更正式的方式来澄清这种情况？

10 licensing  source-code  creative-commons 

我正在使用嵌入式设备的状态模式进行编码。我有一个称为State的基类/抽象类，然后每个离散（具体）状态类都实现了抽象State类。 在状态类中，我有几种抽象方法。如果我不在离散（具体）类中实现抽象方法，Visual Studio将给出如下错误： ...错误1'myConcreteState'未实现继承的抽象成员'myAbstractState' 现在：我正在尝试为每个名为StateName的州创建String属性。每当创建新的具体类时，都需要定义StateName。如果不使用VS，我希望VS抛出错误。有没有简单的方法可以做到这一点？ 我已经在抽象/基类中尝试过此操作： public abstract string StateName { get; set; } 但是我不需要在每个州中实现Get和Set方法。 修订的问题：在理想情况下，将要求每个状态类都具有StateName定义并从抽象基类继承。 StateName = "MyState1"; //or whatever the state's name is 如果缺少该语句，则Visual Studio将生成如上所述的错误。这可能吗？如果可以，怎么办？

10 c#  design-patterns  visual-studio  abstract-class 

是否有客观的论据支持或反对使用对象vs唯一ID作为方法/函数参数？（以及其他对象的成员？）。特别是在静态类型语言（C＃/ Java / Scala）的上下文中 对象本身的优点： 更多类型安全的调用。使用ID时，存在参数错误排序的风险。尽管可以通过为每个仅保留该类ID的类保留一个“ mini”类来缓解这种情况。 从持久中获得一次，无需再次获得 使用ID时，如果id类型发生更改，例如int-> long，则将要求全面更改，并且可能会出错。.（courtsey：https ://softwareengineering.stackexchange.com/a/284734/145808 ） 使用ID的优点： 在大多数情况下，不需要唯一的对象，只需要uniqueid即可，因此拥有ID可以节省从持久性获取ID的时间。 据我所知，将这些技术混合使用既有弊又无利。 鉴于这是一个具体定义的问题，我希望有客观的答案，而不是-“我认为”或“我喜欢”类型... :-)。 编辑：评论者建议的上下文-唯一的限制是静态类型的语言。该应用程序是一个通用应用程序，尽管也很高兴能够根据特定的使用场景获得答案。 编辑：更多的上下文。说我有一个图书管理系统。我的模型是： Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member } Member: {id: Int, name: String} Table- wishlist: { isbn: String, memberId: Int} Table- borrows: { id: Int, memberId: Int} Method: …

10 coding-style  methods  parameters