软件工程

Ian Cooper 在他的演讲TDD中，哪里都出错了，将Kent Beck的初衷推到了TDD中的单元测试（测试行为，而不是具体的类方法），并主张避免将测试与实现耦合。 对于行为，例如save X to some data source在具有一组典型的服务和存储库的系统中，我们如何通过存储库对服务级别的某些数据的保存进行单元测试，而又不将测试与实现细节耦合（例如调用特定方法） ）？避免这种耦合实际上不值得付出某种努力/坏处吗？

16 unit-testing  tdd  coupling 

JSON支持以下数据结构（等同于Java）：标量，数组/列表和映射。 一个Set不支持出的现成的JSON。 我考虑了几种用JSON表示集合的方法： [1]-作为列表 然而，名单都有自己的排序，所以下面的两个列表，["a", "b"]并且["b", "a"]是不相等的名单，但他们应该是平等的套。 [2]-作为地图 使用地图的键集，并忽略值。 但是再次，使用标准比较，两者与地图不同： {"a": "foo", "b": "bar"}， {"a": null, "b": null} [3]-作为地图，具有特殊价值 取一个标量，说0或说，null并使其成为地图中每个键的值： {"a": 0, "b": 0} 这样，即使更改了键顺序，在标准比较工具下，对象也是相等的。 但是，此技术会使用不相关的数据污染JSON文档。 [4]-作为有序列表 回到第一个建议，但是这次作为有序列表。这种解决比较问题。 但是，我们还应该记住排序的复杂性，并且映射符号可以处理重复项，而排序列表则不能。例： {"a": 400, "a": 9}被处理为{"a": 9}，但["g", "g"]总是这样["g", "g"]。 说了这么多，在我看来，列表符号更清晰了，但是映射符号对键重复更健壮，并且很难使特殊值保持一致（尽管这null似乎是一个不错的选择）。 你怎么看？您将如何用JSON表示集合？ 聚苯乙烯 请注意，这个问题仅与JSON有关。我知道可以使用其他格式，例如yaml。仍然...

16 data-structures  json  formatting  notation 

根据在线可用定义，“ 多租户是一种架构，其中软件应用程序的单个实例为多个客户提供服务 ”。这意味着我拥有一家餐馆或学校的网站，并且我提供了访问其他餐馆或学校的权限，以便他们使用我在购买学校管理产品后提供的凭据将其应用程序与自己的数据一起使用。就像我的网站像schoolmanagement.com一样，我为不同的学校客户（例如school1.schoolmanagement.com和school2.schoolmanagement.com）提供了不同的子域，但是这两个子域后面的代码相同。两家学校都有不同的功能或主题，这取决于它们各自的数据库。所以我需要提供schoolmanagement.com进行登录，一旦我的客户基于他们的登录凭据登录，我就会重定向到他们各自的URL，例如school1.schoolmanagement.com。 这是我对多租户应用程序的理解。我的理解正确吗？我可以通过任何在线多租户应用程序吗？

16 architecture  multitenancy  product 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 我正在为我的硕士项目构建一个软件系统，并正在寻找适合“一个人的团队”的特定方法的建议。

15 development-process 

我不是在寻找有关语义的意见，而只是在明智地使用吸气剂是一个实际障碍的情况下。也许这使我陷入了对它们的永无止境的螺旋式旋转，也许替代方法是更清洁并自动处理吸气剂，等等。 我听过所有论据，听过它们很不好，因为它们迫使您将对象视为数据源，它们违反了对象的“纯状态”，即“不要给出太多，但要做好准备”接受很多”。 但是，绝对没有明智的理由说明a为何getData是一件坏事，实际上，一些人认为这与语义有关，吸气剂本身就很好，但只是不要给它们起名字getX，对我来说，这至少很有趣。 如果我明智地使用吸气剂，并且没有明显的数据（如果将其推出，则对象的完整性不会破坏），那么没有意见的一件事是什么？ 当然，允许使用getter来加密用于加密某些内容的字符串是很愚蠢的，但是我说的是系统需要运行的数据。也许您的数据是Provider从对象中拉出的，但是，仍然，对象仍然需要允许该对象Provider执行a $provider[$object]->getData，因此无法解决。 我为什么要问：对我来说，合理使用吸气剂并在被视为“安全”数据上使用吸气剂时，我有99％的吸气剂用于识别对象，例如，我通过代码询问Object, what is your name? Object, what is your identifier?，任何使用对象的人都应该了解有关对象的这些知识，因为关于编程的几乎所有内容都是身份，还有谁比对象本身更了解对象是什么？因此，除非您是纯粹主义者，否则我看不到任何实际问题。 我已经看过所有关于“为什么吸气剂/塞特器”很糟糕的StackOverflow问题，尽管我同意在99％的情况下塞特斯确实很不好，但是不必因为吸韵而对吸气剂一视同仁。 设置器会损害对象的身份，并且很难调试谁在更改数据，但是获取器却无能为力。

15 object-oriented 

假设我们有以下Python类（Java中存在的问题与equals和相同hashCode） class Temperature: def __init__(self, degrees): self.degrees = degrees degrees开尔文的温度在哪里？现在，我想实现平等的测试和哈希为Temperature的方式， 比较浮点数到ε差，而不是直接相等测试， 并履行a == b隐含的合同hash(a) == hash(b)。 def __eq__(self, other): return abs(self.degrees - other.degrees) < EPSILON def __hash__(self): return # What goes here? Python文档讨论了一些关于确保数字哈希hash(2) == hash(2.0)的问题，但这并不是完全相同的问题。 我是否在正确的轨道上？如果是这样，在这种情况下实现散列的标准方法是什么？ 更新：现在我知道这种浮点数相等性测试消除了==和的可传递性equals。但是，如何将其与浮动的“常识”一起使用，不应该直接进行比较？如果通过比较浮点数实现相等运算符，则静态分析工具会抱怨。他们这样做正确吗？

15 java  python  hashing  floating-point 

在查看新的代码库时，我喜欢从下至上的方法开始。 我在其中理解一个文件，然后移至下一个抽象。 但是很多时候我发现自己忘记了底层抽象在做什么。 因此，在这一点上，我发现自己陷入了无尽的循环，回到我以前完全理解的文件，然后尝试重新学习它们。同时尝试弄乱彼此之间相互联系的许多其他抽象。 是否有更好的策略来应对这种情况？ 我是否应该忘记较低级别的细节，并将其视为既定知识？但是即使如此，很多时候仍需要对底层抽象有一个先前的了解，以了解当前抽象在做什么。

15 programming-practices  abstraction  strategy  low-level  high-level 

我有一种方法，可以在与数字板交谈后创建数据文件： CreateDataFile(IFileAccess boardFileAccess, IMeasurer boardMeasurer) 这里boardFileAccess和boardMeasurer是相同的实例Board对象，同时实现了IFileAccess和IMeasurer。IMeasurer在这种情况下，仅用于一种方法，该方法将使板上的一个引脚处于活动状态以进行简单的测量。然后，使用将该测量的数据本地存储在板上IFileAccess。Board位于一个单独的项目中。 我得出的结论CreateDataFile是，通过快速测量然后存储数据来做一件事，对于其他使用此代码然后必须进行测量并写入文件的人来说，使用同一方法进行这两种操作更直观作为单独的方法调用。 对我来说，将同一对象两次传递给方法似乎很尴尬。我认为做一个本地接口IDataFileCreator，可以扩展IFileAccess和IMeasurer再有一个包含一个实现Board的实例，将只需要调用所需的Board方法。考虑到同一板对象将始终用于测量和文件写入，将同一对象两次传递给方法是否是一种不好的做法？如果是这样，使用本地接口和实现是否是合适的解决方案？

15 c#  interfaces  methods  parameters 

我敢肯定这不是一个罕见的主题。我们有两个Scrum团队可以很好地使用故事点来估计用户故事（当前团队的星座只有大约8个月大，尽管团队成员具有几年的Scrum经验）。但是，对于公司的业务部门而言，很难与用户故事相关联。他们想要实际的时间单位（或“将故事点转换为小时数的公式”），以便他们可以为何时准备就绪制定计划（“我们需要知道何时可以告诉客户Feature X即将投入生产”。 我和我的Scrum大师的前任当然已经解释说：“故事点和实际时间之间没有明确的关系”，并且“故事点用于确定团队适合冲刺的程度”，我确保您可以猜出他们对该答案的满意程度。他们仍然想在日历时间内知道何时获得积压的第27个用户案例。 无论如何，我一直在编辑一些统计数据，我们的SP估计值转化为实际花费的时间差异很大（由我们的Scrum Board软件衡量，该软件可以跟踪“在”列中花费的时间） ）。对于1-SP用户故事，当然会非常倾向于很短的时间跨度（偶尔会出现爆炸），但是特别是对于2-SP用户故事，它们无处不在：大约有20倍在“最快”和“最慢”完成之间。对于3、5和8-SP故事，传播也超过2倍。 这表明（a）团队需要在估计相似程度（应该是）的用户故事方面更加一致，并且（b）团队需要提高时间报告的准确性（即记住将票证移出当他们在会议上，午餐时或打足球时进行“锻炼”。 我已经计划改善（a）和（b），但是我觉得这还远远不够，因为企业期望比这些计划产生的结果更“具体”。 有什么好的策略可以使业务方面愉悦，从而使它们不会对我们的工作产生太大干扰（例如，通过使用单独的时间跟踪，恕我直言，这是愚蠢的，因为在任何情况下它的准确性都不如当前的“自动”跟踪），同时又让他们获得一些具体的度量标准来确定故事何时完成？ （从历史上看，在规划过程中，我们确实将用户故事分解为工作项目，然后在实际工作时间中分别进行估算，但是我在这里要说的是备用日志中的用户故事，而这些细节或详细程度不会-下。） 更新：我的经理有一种预感，即每个故事点花费的小时数呈钟形分布，但我整理的数据和他制作的图表使他完全没有这个想法。:-)

15 scrum  estimation 

我和我的一个朋友建立了很多项目，但我们总是一遍又一遍地遇到同样的陷阱。我知道如何编写PHP，Javascript以及所有其他内容（我也知道CSS和HTML），因此在构建实际功能时我可以完成大部分工作。但是，他不能，但是他可以做我几乎做不到的事情：设计站点。 但是每次，我们偶然发现一个问题，因为他不知道如何编写代码，所以这通常会大大减慢我们的开发速度。目前，这是我们的工作流程： 我们提出一个功能 他负责构建前端设计（应将其放置在哪里，外观如何等）。 他将完整的模板发送给我（Pinegrow的HTML导出） 我寻找他所做的更改，然后在实际站点中实现它们（自几周以来，我一直在使用CakePHP）。 当某件事情无法按预期进行时（例如，由于某种原因我们未能按计划完成），我将问题解决了，然后将模板发回给他 冲洗并重复 可以想象，这个过程非常缓慢且效率低下。所以我的问题是，我们如何才能使这一过程更加顺利？我已经看到了很多关于应该使用React并使用RESTful的东西，但我们不想要，但是我们想使用CakePHP。有人可以指导我一些有用的资源吗？我一直在寻找这个问题已经有一段时间了，但是从来没有找到一个合适的解决方案。 基本上，我的伙伴可以做的就是设计网站。他不能使用Docker（我一直都在使用Docker），PHP，Javascript以及几乎所有其他内容（他确实知道一些CSS，但是大多数情况下可以与WYSIWYG编辑器一起使用），我愿意向他学习，但是他是不感兴趣（所以我对此表示尊重）。我希望这里的人可以帮助我（可能以后还会有人回答这个问题），因为我认为这是一件很重要的事情。

15 design  cakephp 

开发人员创建脚本来帮助他们的工作。例如，使用某些参数运行Maven，杀死在开发中突然出现的不需要的后台任务，或者连接到特定的服务器。这些脚本不是核心构建脚本，也不在我们的Continuous Integration服务器中使用。 最好的管理方式是什么？要将它们放入目录（也许是 /scripts）并将其检入Git？要将它们分别维护在某些文件服务器中？ 将它们视为源代码的理由是它们是源代码并且可以更改。不这样做的理由是它们只是辅助工具，并非所有开发人员都需要任何给定脚本（例如，某些Windows上工作的Linux特定脚本）。

15 scripting  command-line 

在URL中指定REST API的版本是很普遍的，特别是在路径的开头，例如： POST /api/v1/accounts GET /api/v1/accounts/details 但是，我还没有看到将版本与每个API关联的任何设计。换句话说，我们分别维护每个API的版本。即： POST /api/accounts/v2 GET /api/accounts/details/v3 使用这种方法，当需要中断更改时，我们可以增加特定API的API版本，而无需增加整个API的版本。 使用此样式而不是通用样式有什么弊端？

15 rest  api-design  versioning  enterprise-architecture  engineering 

目前，我正在通过以下方式在项目中使用logger： private static final Logger LOGGER; static{ LOGGER = logger.getLogger(); } 我获得了使用静态块初始化logger变量的代码审查。有人告诉我在声明语句本身中初始化logger变量。 private static final Logger LOGGER = Logger.getLogger(); 我试图弄清楚如果不在静态块中初始化它会有什么区别。我想知道这是否是一种做法。

15 java 

如果您有一个仅带有值的枚举（没有任何方法可以像Java中那样），并且此枚举是系统业务定义的一部分，那么应该为它编写单元测试吗？ 我一直认为应该编写它们，即使它们看起来很简单而且很多余，但我认为应该在测试中明确编写与业务规范有关的内容，无论它是使用unit / integration / ui / etc编写的。测试或使用语言的类型系统作为测试方法。因为从业务的角度来看，枚举（例如Java中）必须具有的值不能使用类型系统进行测试，所以我认为应该为此进行单元测试。 这个问题是不是类似于这一个，因为它没有解决同样的问题我的。在该问题中，存在一个业务功能（savePeople），而该人员正在查询内部实现（forEach）。在那里，有一个中间业务层（该功能可节省人员），封装了语言构造（forEach）。这里的语言构造（枚举）是用于从业务角度指定行为的一种。 在这种情况下，实现细节与数据的“真实性质”相吻合，即：（在数学意义上）一组值。您可以说使用了一个不可变的集合，但是相同的值仍然应该在那里存在。如果使用数组，则必须执行相同的操作来测试业务逻辑。我认为这里的难题在于，语言结构与数据的性质非常吻合。我不确定我是否正确解释了自己

15 unit-testing  testing  type-systems  enum 

protobuf的语法3使所有字段成为可选字段，从而删除了关键字required以及optional以前的proto2语法。阅读开发人员的一些评论似乎是为了增强向前/向后二进制兼容性而完成的。 但是对我而言，这可以通过仅对软件包名称进行版本控制（例如说）com.example.messages.v1，然后让客户端实施他们理解的反序列化程序来实施。同时，它删除了一些从软件工程的角度来看有用的合同类型。例如，如果我有 message Location { double latitude = 1; double longitude = 2; } 在proto3中，可以Location通过不提供必填字段之一来创建半备份但完全有效的文件。 创建基于模式的序列化格式以在客户端之间交换数据时，这不是一个很大的缺点吗？将额外的验证代码移至每个客户端以检查所有必填字段均具有有效值，这不是更糟吗？

15 event-programming  event-sourcing  protobuf