软件工程

这是典型的C ++代码： foo.hpp #pragma once class Foo { public: void f(); void g(); ... }; foo.cpp #include "foo.hpp" namespace { const int kUpperX = 111; const int kAlternativeX = 222; bool match(int x) { return x < kUpperX || x == kAlternativeX; } } // namespace void Foo::f() { ... …

12 c++  unit-testing 

请考虑以下典型情况： if(myObject == null) { myObject = new myClass(); } 我想知道使用null-coalescing运算符进行以下替换的想法： myObject = myObject ?? new myClass(); 我不确定是否应该使用第二种形式。这似乎是一个不错的速记，但是myObject = myObject开始时的构造似乎有点代码气味。 这是合理的做法，还是我缺少更好的速记？或者，也许是“三行，克服它！”？ 编辑：如上所述，也许将其称为典型场景是一种夸大其词的说法。我通常会在从具有子引用类型属性的数据库中检索一个实体时遇到这种情况，该子引用类型属性可能已填充也可能尚未填充： myClass myObject = myClassService.getById(id); myObject.myChildObject = myObject.myChildObject ?? new myChildClass();

12 c#  operators 

本来这是另一个问题的一部分。 为什么sizeof称为编译时运算符？它实际上不是运行时运算符吗？而且，如果它确实是一个编译时运算符，那么它如何帮助产生在不同计算机上运行相同代码的可移植代码？请详细说明。

12 c++ 

我没有在特定的上下文中询问问题，但是在阅读有关C ++的初学者书籍时，我注意到在处理流对象时，既使用了endl流操纵器，也使用了换行符。 示例如下： cout << "Hello World" << endl; cout << "Hello World\n"; 我的问题是： 在特定情况下使用流操纵器（endl）并在其他情况下使用转义符是否更合适？ 使用两者之一是否在效率方面存在弊端？ 它们完全可以互换吗？ 我读到一个转义序列作为单个字符存储在内存中。这是否意味着如果要降低内存消耗，使用endl更合适吗？ 流操纵器endl是否以任何方式消耗内存，如果超过了转义序列，它会占用更多内存吗？ 谢谢，StackExchange Apologies如果将其发布在错误的部分，我认为它已被视为数据结构。

12 c++  data-structures 

有关默认值的一般问题-默认返回函数值，默认参数值，缺少某些内容时的默认逻辑，用于处理异常的默认逻辑，用于处理边缘条件的默认逻辑等。 很长一段时间以来，我都认为默认值是“纯粹的邪恶”，它“掩盖了灾难”并导致非常难以发现错误。但是最近我开始考虑将默认值视为某种技术债务……这不是一件坏事，而是可以提供一些“短期融资”的东西使我们能够在项目中生存（我们中有多少人可以负担得起）在没有抵押的情况下买房？）。 当我说“短期”时，我的意思不是“首先快速地做某事，然后在它投入生产之前再进行重构”。否-我说的是在生产软件中依赖硬编码的默认值。当然-可能会导致一些问题，但是如果仅在一年内造成一次麻烦该怎么办。 再说一遍-我在这里谈论的是“平均”主流软件（不是核电站软件）-会计软件的普通网站或UI应用程序，这意味着人们的生命不会受到威胁，也不会数百万美元。 同样，根据我的经验，业务用户宁愿使用“以某种方式工作”的软件，也不愿等待完美的软件。如果您以RAD风格开发软件，则使用默认值会很有帮助。但是，我再次使用了最长的调试会话，这是因为默认值引入的错误（在此过程中不再是“默认值”），或者由于小型子系统最近已升级，因此升级并没有正确处理默认值（例如，空列表vs空，或空字符串vs空字符串）。 所以我的问题是-默认值是好是坏。而且，如果这些债务属于技术债务，该如何计算您可以借入的金额，以便您有能力偿还还款？ 非常感谢您的投入。 干杯。 编辑： 如果我使用默认值作为在开发过程中偷工减料的方式-如果偷工减料会导致错误和问题-从这些问题中恢复的方法是什么？

12 programming-practices 

想到两个例子： 鼓励.Net程序员使用.config文件而不是Windows注册表的原因之一是.config文件是XML，因此易于阅读。 类似地，与专有格式相比，JSON有时被认为是人类可读的。 人类可读的格式实际上是人类可读的吗？在配置数据示例中： 格式不会改变信息的基本含义-在两种情况下，数据都代表同一件事。 注册表和.config文件在内部都存储为系列0和1。在这种程度上，人类同样无法理解基本的表示。 注册表文件和.config文件都需要一种工具来读取，格式化和显示0和1，并将其转换为人类可以读取的格式。对于配置存储在Windows注册表中的情况，这是一个注册表编辑器。对于XML，它可以是文本编辑器或XML阅读器。无论哪种方式，该工具都使数据可读，而不使数据格式可读。 那么，人类可读数据格式和非人类可读格式之间有什么区别？

12 terminology 

一些基点： 由于其解释性质，Python方法调用是“昂贵的”。从理论上讲，如果您的代码足够简单，那么分解Python代码除了会提高可读性和重用性之外，还会带来负面影响（这对开发人员而言是一大收获，对用户而言却不是很多）。 单一责任原则（SRP）可使代码保持可读性，易于测试和维护。 该项目具有特殊的背景，我们需要可读的代码，测试和时间性能。 例如，像这样的调用多个方法（x4）的代码比随后的仅一个方法慢。 from operator import add class Vector: def __init__(self,list_of_3): self.coordinates = list_of_3 def move(self,movement): self.coordinates = list( map(add, self.coordinates, movement)) return self.coordinates def revert(self): self.coordinates = self.coordinates[::-1] return self.coordinates def get_coordinates(self): return self.coordinates ## Operation with one vector vec3 = Vector([1,2,3]) vec3.move([1,1,1]) vec3.revert() vec3.get_coordinates() 与此相比： from …

12 python  performance  single-responsibility  methods 

考虑到具有n层体系结构和依赖项注入的中型软件，我很高兴地说属于一个层的对象可以依赖于较低层的对象，而不能依赖于较高层的对象。 但是我不确定要考虑那些依赖同一层其他对象的对象。 举个例子，我们假设一个应用程序具有三层和几个对象，如图像中的一个。显然，自上而下的依赖关系（绿色箭头）没问题，自下而上的依赖关系（红色箭头）不行，但是同一层内的依赖关系（黄色箭头）又如何呢？ 除了循环依赖之外，我很好奇其他可能出现的问题以及这种情况下违反了多层体系结构的程度。

12 architecture  dependencies  layers 

我刚从大学毕业，所以对关系数据库的熟悉程度大部分来自于我的数据库课程，在该课程中，BCNF或3NF以外的任何事物都是荒唐的。当然，这是极端的目的，但是我的工作团队似乎确实将其推向了另一端。 在我们的微服务数据库架构中，实体很少有多个表。您通常会标准化到另一个表的所有内容都存储在json列中。如果以后发现需要查询此json中的属性之一，则会添加一个新列，并将数据存储在两个位置（是的，在同一表的两个不同列中）。 在许多情况下，这些json列绝对具有优势。如果您不需要查询数据，也不必单方面更改数据（这显然是您无法预测的），那么这不是一个坏主意。再加上我们的许多服务都看不到服务器，或者托管在具有淫秽磁盘空间的计算机上，无法满足他们的需求，因此数据复制不是一个大问题。（尽管我通常会出于哲学目的避免这种情况） 当前，我们正在构建一个服务，该服务根据规则所拥有的一组条件匹配规则，然后在规则为真（例如，所有条件都为真）时执行与这些规则关联的一组操作。我的最直接构建此服务的小组认为，从架构规则中规范动作和条件有很大的好处。显然，这些表与规则ID保持外键关系。从我们的角度来看，我们可以避免条件上的数据重复，这使我们能够确保仅对它们进行一次评估，并且在需要它们时很容易找到我们需要的条件和规则，而无需提取每个规则并在内存中进行搜索。 今天，他与我们的一位首席工程师交谈，试图使我远离这种模式。试图以各种方式争辩我们实际上并不需要它，这将在将来引起性能问题，并引用了我们拥有的旧单片，这是设计上的麻烦。他将我们正在做的事情称为“旧方法”，将带有json的平面表称为“新方法”。他争辩说，在我想要原子性的地方，我们不需要它，而不是查询，我们应该在内存中做更多的事情。这是我们许多服务现在遵循的设计原则。我们预计数据量不会大幅增长，这将使我们的查询保持快速。我们确实期望在规则评估和执行操作上花费大量时间。 我知道非关系数据库近年来已经变得越来越流行，但是即使在积极地搜索有关外键关系对性能的影响的信息时，我也看不到很多信息可以证明他的观点。我想他们可能会倾向于引入可能导致问题的大型事务，但这似乎是一个独立于外键本身的问题。 这是我的天真吗？还是我和我的子团队确实缺少某些东西？我没有明确提供有关我们问题的详细信息，因为我不一定正在寻找解决方案。考虑到这是我们大型团队的共同趋势，我真的很好奇他们是否对此有所帮助。

12 database  relational-database  nosql 

DDD存储库的典型实现看起来不太像面向对象，例如一种save()方法： package com.example.domain; public class Product { /* public attributes for brevity */ public String name; public Double price; } public interface ProductRepo { void save(Product product); } 基础架构部分： package com.example.infrastructure; // imports... public class JdbcProductRepo implements ProductRepo { private JdbcTemplate = ... public void save(Product product) { JdbcTemplate.update("INSERT INTO …

12 design-patterns  object-oriented  domain-driven-design 

以下代码导致内存泄漏： #include <iostream> #include <memory> #include <vector> using namespace std; class base { void virtual initialize_vector() = 0; }; class derived : public base { private: vector<int> vec; public: derived() { initialize_vector(); } void initialize_vector() { for (int i = 0; i < 1000000; i++) { vec.push_back(i); } } }; …

12 c++  inheritance  memory  allocation 

一项Scrum测试包含有关定义的问题，该定义最能描述当多个开发团队对同一产品执行工作时的“完成”。 一个正确的答案是，这些开发团队必须对“完成”进行这样的定义，使他们的合并工作有可能被释放。 从这个测验的正确答案中，我不清楚： 团队可以对“完成”有不同的定义吗？在什么程度上？

12 agile  scrum 

因此，我注意到可以通过执行以下操作来避免将私有函数放在标头中： // In file pred_list.h: class PredicateList { int somePrivateField; friend class PredicateList_HelperFunctions; public: bool match(); } // In file pred_list.cpp: class PredicateList_HelperFunctions { static bool fullMatch(PredicateList& p) { return p.somePrivateField == 5; // or whatever } } bool PredicateList::match() { return PredicateList_HelperFunctions::fullMatch(*this); } 私有函数永远不会在标头中声明，并且导入标头的类的使用者永远不需要知道它的存在。如果helper函数是模板，则这是必需的（替代方法是将完整的代码放在标头中），这就是我“发现”它的方式。如果添加/删除/修改私有成员函数，则不需要重新编译包含头文件的每个文件的另一个好处。所有专用功能都位于.cpp文件中。 所以... 这是一个众所周知的设计模式吗？ 对我来说（来自Java / C＃背景并且自己学习C …

12 design-patterns  object-oriented  c++  encapsulation 

免责声明：有一些类似的问题，但是在查看大型拉取请求时，我没有发现任何能特别解决您面临的问题的问题。 问题 我觉得我的代码检查可以通过更好的方式完成。我特别是在谈论大型代码审查，其中涉及20多个文件的许多更改。 捕获明显的本地代码问题非常简单。但是，了解代码是否符合业务标准是另外一回事。 我在遵循代码作者的思考过程时遇到了麻烦。当更改数量众多且分布在多个文件中时，这非常困难。我尝试着重于与特定更改相关的文件组。然后逐一查看组。不幸的是，我使用的工具（Atlassian Bitbucket）不是很有帮助。每当我访问文件时，即使经常证明它与当前检查的更改都不相关，它也会被标记为可见。更不用说一些文件应该被多次访问，并且它们的更改要逐个进行审查。当您走错路时，要返回相关文件也不容易。 可能的解决方案，以及为什么它们对我不起作用 通过提交复审拉取请求通常可以解决大小问题，但是我不喜欢它，因为我经常查看过时的更改。 当然，创建较小的拉取请求似乎是一种补救方法，但这是正确的，有时您会收到一个大的拉取请求，必须对其进行审查。 您也可以整体上忽略代码的逻辑方面，但这似乎很有风险，尤其是当代码来自没有经验的程序员时。 使用更好的工具可能会有所帮助，但我没有找到。 问题 您的代码审查是否遇到类似的问题？你如何面对他们？ 也许您有更好的工具？

12 code-reviews 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 XSLT是成熟的，被广泛接受的标准。 它可以在浏览器（甚至在旧的IE中）和服务器端使用（nginx具有XSLT模块，当然可以从编程语言中使用它）。它的实现是经过编译的，因此应该比Python或JS快得多。JS实现Saxon JS至少可以用作后备。Jinja，Angular，Ruby的Slim，ASP和PHP模板还差得远。 可以在IDE中轻松验证XSL模板。有多少个IDE可以帮助Jinja或Angular？ 用XSLT分解UI和数据似乎是一个绝妙的主意。 诚然，在某些特殊情况下，实现可能会给出不同的结果，但这仅是在客户端进行模板处理才是问题。与HTML，CSS和其他在客户端完成的操作相同。 那么，为什么不使用XSLT？

12 web-development  web-applications  web  front-end  xslt