软件工程

想象一下一个具有大量服务器的系统。它们每个都有许多设置： 一些特定于服务器的 一些特定于该地区的 他们之间有些共同点 也许您可以进行一些自定义分组，例如这组服务器仅用于读取 等等 我想到的当前实践是具有压倒性能力的简单属性结构。 让我们以Google服务器为例。其中每个都有一个要加载的设置列表。 例如，伦敦服务器可能具有： rootsettings.properties，europesettings.properties，londonsettings.properties，searchengine.properties，等。 每个文件都包含一组属性，并且加载顺序使您可以覆盖属性，您可以走得更远。 举例来说：rootsettings.properties可有accessible=false作为默认，但重写在searchengine.properties与accessible=true 我在使用此结构时遇到的问题是，很容易失控。它根本不是结构化的，这意味着您可以在任何级别定义任何属性，并且许多项目可能会过时。 此外，随着网络的增长，更改中间级别变得不可能了，因为您现在影响了非常多的服务器。 最后但并非最不重要的一点是，每个单独的实例可能需要1个特殊属性，这意味着您的树最终还是为每个服务器配置了一个配置，这使其不是最佳解决方案。 如果您对更好的配置管理体系结构有任何建议/想法，将不胜感激。

15 configuration  configuration-management  properties 

我想在很久以前编写的某些仍能正常工作的代码中进行一些增强，然后再以其编写的编程语言具有更多功能。从理论上讲，整个项目都使用该语言的最新版本。但是，该特定模块（实际上还有许多其他模块）仍然使用较旧的方言编写。 我是不是该： 不用接触我不需要接触的代码部分，而是利用新的语言功能编写我的补丁程序，这些新功能使编写补丁程序更加容易，但是在模块中其他任何地方都无法使用？（这是我直观选择的解决方案。） 忽略岁月流逝的事实，并在编写补丁时反映出代码其余部分中使用的样式，就像我早在多年前一样正在做同样的事情一样吗？（我直觉上认为这种解决方案很愚蠢，但是鉴于每个人都在谈论“好的代码”而大惊小怪，因此不惜一切代价保持一致性，也许这就是我应该做的。） 更新整个模块以使用较新的语言构造和约定？（这可能是最好的解决方案，但可能需要大量时间和精力，而最好将其花费在其他任务上。）

15 programming-practices  maintenance 

set类的add运算符返回一个布尔值，如果元素（要添加的元素）不存在则为true，否则为false。在写字 if (set.add(entry)) { //do some more stuff } 在编写简洁的代码方面被认为是好的风格？我想知道既然您一次执行两项操作。1）添加元素，2）检查元素是否存在。

15 java  coding-style  clean-code 

我们公司将购买大量且非常复杂的卫星通信源代码。 它使用C ++进行编码，我们还将使用C ++对其添加的代码进行编码，将我们的代码与购买的代码链接到单个可执行单元中。 是否有必要使用与开发购买的代码相同的编译器和相同的编译器版本？ 我们是否必须使用与所购买代码相同的C ++版本？如果不使用2014，我们可能想使用它的某些功能，但是如果混合使用不同的版本可能会出现问题，则不要。 从理论上讲，当然，这无关紧要，尤其是语言版本，但是可以想象，不同版本的编译器将生成不同的目标代码，从而可能导致时序差异等。 我们应该注意什么？

15 c++ 

我们正在设计一个RESTful API，主要用于满足单个客户端的需求。由于其非常特殊的情况，此客户端必须发出尽可能少的请求。 API通过请求中的Accept-Language标头处理i18n。这适用于客户端需要做的所有事情，除了一项功能外，在该功能中，客户端需要在所有可用的语言环境中存储对单个端点的请求响应。 我们是否可以以某种方式设计API，使客户端可以在单个请求中获取所有这些信息，而又不会破坏一致的，结构良好的RESTful API设计？ 到目前为止，我们已经考虑的选项： 允许在Accept-Language标头中包含多个语言环境，并在响应中为所有请求的语言环境添加本地化版本，每个语言环境均以其ISO 639-1语言代码标识为密钥。 为该端点创建类似“？all_languages = true”的参数，并在响应中返回所有可用语言环境的本地化版本（如果存在该参数的话）。 （如果以上方法对我们都不起作用），将发出多个请求以从客户端获取所有本地化版本。 哪一个是最好的选择？

15 rest  api  api-design  http 

假设有一个IReader接口，一个IReader接口ReaderImplementation的实现以及一个使用和处理来自读取器的数据的类ReaderConsumer。 public interface IReader { object Read() } 实作 public class ReaderImplementation { ... public object Read() { ... } } 消费者： public class ReaderConsumer() { public string location // constructor public ReaderConsumer() { ... } // read some data public object ReadData() { IReader reader = new ReaderImplementation(this.location) data …

15 mocking  code-smell 

很多时候，我发现自己从某些数据层次结构中获取值时会进行空检查，以避免NullPointerExceptions，因为我发现NullPointerExceptions容易出错并且需要大量样板。 我编写了一个非常简单的例程，使我在获取对象时可以跳过空检查... public final class NoNPE { public static <T> T get(NoNPEInterface<T> in) { try { return in.get(); } catch (NullPointerException e) { return null; } } public interface NoNPEInterface<T> { T get(); } } 我有点像这样 Room room = NoNPE.get(() -> country.getTown().getHouses().get(0).getLivingRoom()); 上面的结果导致我得到一个Room对象或一个null，而不必对所有父级进行null检查。 您如何看待以上内容？我在创建有问题的模式吗？您认为有更好的方法吗？

15 java  null 

在学习Redux时，我想到了上帝对象模式（或反模式）-两者都有一个大对象，其中包含所有应用程序数据和操作它们的方法。但是Redux施加了一些约束，例如使Object不可变以及事件纯函数保持严格的签名。 因此，问题来了，Redux是否使用了经过清理的God对象版本？还是与Javascript不是经典的强类型OOP有关？

15 redux 

我有一个类，它设置节点数组并以类似图形的结构将它们彼此连接。最好是： 保留用于初始化和连接节点的功能 在两个不同的函数中具有初始化和连接功能（并具有必须调用这些函数的依赖顺序-尽管请记住，这些函数是私有的。） 方法1 ：（因为一个功能要做两件事，但它会将依赖的功能分组在一起-除非先进行初始化，否则切勿连接节点。） init() { setupNodes() } private func setupNodes() { // 1. Create array of nodes // 2. Go through array, connecting each node to its neighbors // according to some predefined constants } 方法2 ：（从某种意义上说，这是自记录的，但决不要在setupNodes（）之前调用BUT connectNodes（），因此使用类内部知识的任何人都需要了解此顺序。） init() { setupNodes() } private func setupNodes() { createNodes() connectNodes() …

15 functions  code-organization  file-structure 

TL; DR-可以在服务之间共享POJO库吗？ 通常，如果可能的话，我们希望将服务之间的共享严格限制为无共享。共享数据的服务是否应提供客户端库供客户端使用一直存在争议。客户端库通常对于服务的客户端是可选的，并且可以使用API​​，但是无论他们愿意使用API​​，还是使用客户端库还是使用替代语言并使用库的一般方面，等等。 就我而言-我考虑一种创建数据对象的服务。假设此对象是PET。不是数据库实体，而是严格地隐式表示基础数据的POJO。该POJO是API定义的。假设：宠物-年龄，体重，姓名，所有者，地址，种类等。 服务1 -PetKeeper：无论出于何种原因，它都会生成一个pet，并保留所有数据，并且必须引用此服务来获取pet，或者对pet进行修改，可以说名称更改或地址更改必须通过以下方式完成：此服务的API调用。 服务2 -PetAccessor：此服务收集宠物并进行验证检查 服务3,4-更多中间服务呼叫 服务5-用户界面 这些都是很随意的，但重点很简单。UI或某些面向用户的服务希望以某种方式呈现此“ PET”对象。它必须通过API调用一个服务，该服务调用一个服务，再调用一个服务，依此类推，直到到达收集所需信息并开始中继的服务为止。最后，UI服务具有要显示的PET对象。 这很普遍-但出于我们的绝对思想，我们在每次服务中都复制了PET对象。DRY（请勿重复）原则仅适用于服务内的代码，不适用于所有服务，但重点仍然存在。如果我们添加一个字段怎么办...我们必须在每个字段中修改POJO的5个服务。 -或-我们可以提供一个Pet-Objects-Library，其中包含API中的一些pojo，并且每个服务都可以导入/依赖该库。与服务本身无关，而与常规库无关。我喜欢这个想法，以便每个服务都具有相同类型的对象，并且更新更加容易。但是我担心神物。 优点/缺点是什么-最佳设计是什么？您做了什么在服务之间传递数据，以最大程度地减少重复执行相同的POJO类，同时保持解耦状态？

15 java  dto  microservices 

在C ++中，size_t（或更正确地说T::size_type，通常是“ 类型” size_t；即unsigned类型）被用作的返回值size()，的自变量operator[]等（请参见std::vector等）。 另一方面，.NET语言出于相同目的使用int（并且（可选long））。实际上，不需要 CLS兼容语言来支持unsigned类型。 由于.NET是比C ++新的东西告诉我，可能会有问题，使用unsigned int连供的事情，“不可能”像数组索引或长度为负。C ++的方法是否“向后兼容”？还是这两种方法之间存在真实而重大的设计折衷？ 为什么这么重要？好吧……对于C ++中的新多维类，我应该使用什么？size_t还是int？ struct Foo final // e.g., image, matrix, etc. { typedef int32_t /* or int64_t*/ dimension_type; // *OR* always "size_t" ? typedef size_t size_type; // c.f., std::vector<> dimension_type bar_; // maybe rows, or x dimension_type baz_; // e.g., columns, …

15 c#  c++  array 

说我有以下ER图： 现在，如果我使用Schoolin 的外键表示关系Student，则可以具有NULL值（因为a Student 不需要属于a School），例如： 因此，正确的方法（基于我所读的内容）是创建一个交集表来表示这种关系，例如： 这样，NULL表格中就不会出现任何值School_has_Student。 但是，使用可为空的外键而不是创建交集表的缺点是什么？ 编辑： 我误选了（school_id，student_id）是用于主键School_has_Student表，这使得许多关系到多。正确的主键应该是student_id：

15 database  database-design  relational-database 

最近，我一直在阅读有关微服务的很多文章，这是到目前为止我得出的一些结论（如果我在任何时候错了，请更正我）。 微服务架构与域驱动设计配合得很好。通常一个MS代表一个有界上下文。 如果微服务A需要驻留在微服务B中的功能，则我的模型可能是错误的，并且A和B 实际上应该是一个微服务/ BC。 微服务之间的同步通信（直接HTTP请求）很糟糕，导致它违背了微服务的目的，并引入了组件之间的耦合。 服务之间的异步通信是可取的。服务应将事件发布到消息队列，以便其他服务可以订阅和处理事件的一部分，或使用它复制上下文所需的部分数据。这样，服务可以处理请求，甚至其他服务也已关闭，而在同步通信中则不会。 如果微服务A发布事件，微服务B订阅该事件并产生一个新事件作为结果，则微服务A不应是一个正在处理的新创建事件，因为这将是循环依赖性。在这种情况下，我们应该引入第三种微服务，或者将A和B合并到AB微服务中。 微服务实际上是一个误导性术语。我们应该为小环境而努力，但这不是必须的。术语不应该是“微服务”，而是“ 足够大以进行工作服务 ”。 微服务使我们可以更轻松地引入新功能，而不必担心会破坏整个系统。可以通过引入新服务或重构现有服务之一来完成。 每个微服务都应具有自己的数据存储。数据复制/复制是此体系结构中的理想行为。 除了证实我对这种体系结构的理解之外，问题的其他部分主要与服务发现有关。如果服务异步通信，并使用亚马逊SQS之类的中央事件队列，这是否意味着服务发现在这样的体系结构中没有位置？ 服务不应对系统中的其他服务有任何了解。他们只知道应该发布或订阅的上下文和事件吗？

15 architecture  domain-driven-design  soa  microservices 

从现在开始，我已经搜索并阅读了很多有关内存对齐方式，其工作方式和使用方法的内容。我现在找到的最相关的文章是这篇。 但是即使如此，我仍然对此有一些疑问： 在嵌入式系统之外，我们经常在计算机中拥有大量内存，这使内存管理的批评家减少了很多。我完全致力于优化，但是现在，如果我们将相同的程序与或进行比较，是否真的可以有所作为？没有它的内存重新排列和对齐？ 内存对齐还有其他优势吗？我在某处读到CPU可以更好地/更快地使用对齐的内存，因为这样可以减少处理的指令（如果你们中的某个人有一篇文章/基准的链接？），在那种情况下，区别真的很重要吗？有没有比这两个更多的优势？ 在第5章的文章链接中，作者说： 当心：在C ++中，看起来像结构的类可能会违反此规则！（它们是否取决于基类和虚拟成员函数的实现方式，并随编译器的不同而不同。） 本文主要讨论结构，但是局部变量声明是否也受此需求影响？ 您是否知道内存对齐在C ++中如何工作，因为它似乎有些差异？ 前一个问题包含“对齐”一词，但未提供上述问题的任何答案。

15 c++  c  optimization  memory-usage  speed 

如今，几乎所有的C ++开发人员都同意这std::vector<bool>是一个错误，因为它显然不是容器，而且其用例std::bitset无论如何都与大多数情况重叠。 它是如何被选为标准的？当时有争议吗？主要的支持论据是什么？

15 c++  history  stl