软件工程

令我高兴的是，C ++ 11具有一系列std::sto@函数，可以轻松地从字符串中解压缩int / floats / longs。但是令我惊讶的是，没有实现相反的情况。标准委员会为什么不包括std::itos从int / floats / whatever（返回）到字符串的函数族？

37 c++  parsing  strings  c++11 

我们正在开发一项新服务-该服务可能会直接从用户设备上的应用程序中调用。这些应用程序将由组织中的多个开发团队开发并提供支持，所有这些均取决于我们提供的数据。 我们渴望确定哪些应用程序正在发送哪些请求，以便我们可以确定使用模式和负责的开发人员。（为避免疑问，用户身份验证是单独处理的。） 我们的解决方案是要求API密钥（每个应用程序一个）–然后我们需要开发团队的详细联系信息。 我们不想让API密钥成为麻烦，但是我们担心开发人员会将其共享给其他团队的同事，这意味着我们不再能够仅为一个应用程序识别流量。 我们如何激励开发人员不要在内部共享API密钥？

37 api  enterprise-development 

我们的业务线软件允许用户将某些数据保存为CSV。由于野外使用了许多不同的格式（都称为“ CSV”），因此我们试图确定“默认格式”应是什么样。 关于行/字段分隔符和转义，我们可以使用一个标准：RFC 4180。 关于文本编码，UTF-8似乎在过去十年中以“默认文本文件格式”出现，因此我们将使用它。 一个悬而未决的问题是：我们是否应该在开始时添加BOM？我已经阅读了有关BOM总体使用的多种观点和优缺点，但是对于在CSV文件中使用BOM而言，是否存在“正式”建议或至少某种形式的社区共识？

37 standards  unicode  csv  file-formats 

我正在提议对一个架构很差的软件项目进行更改，该项目会遇到很多问题。在较高的层次上，该项目在前端使用了Angular，并使用了各种REST API。一切都很棒（我看不到需要更改我们的技术或工具）。问题在于，UI中的代码库比服务器端API大得多。大多数业务逻辑都存在于UI中，而REST API是与UI层的简单CRUD数据库接口。 例如，发给客户的POST将创建客户记录，而PUT将修改该客户。不多，也不少。但是，我们的业务逻辑要求更高。创建客户的一般过程所要做的不仅仅是插入1条数据库记录。它将在其他必要的表中提供数据，执行某些验证和计算等。我更愿意进行单个POST / PUT调用来封装所有这些行为，从而减轻使用方客户端的负担。 因此，我的观点是，这种总体编排应该驻留在服务器（我们拥有完全控制权，日志等）上，而不是UI上，但是一个反对意见是该方法将不再是RESTful。因此，当我的建议是继续使用现有的技术堆栈，但在代码所属的位置实现根本的转变时，我不确定如何最好地描述这种方法。

37 rest  api-design  enterprise-architecture 

我已经读到，在构造函数中使用“ new”（对于除简单值对象之外的任何其他对象）是一种不好的做法，因为它使单元测试变得不可能（因为这些协作者也需要创建并且不能被模拟）。由于我没有真正的单元测试经验，因此我试图收集一些我将首先学习的规则。另外，无论使用哪种语言，这是一条通常有效的规则吗？

37 unit-testing  constructors 

我开始为当前项目编写一些单元测试。我真的没有经验。我首先要完全“得到它”，所以我目前既不使用IoC框架也不使用模拟库。 我想知道在单元测试中向对象的构造函数提供空参数是否存在任何问题。让我提供一些示例代码： public class CarRadio {...} public class Motor { public void SetSpeed(float speed){...} } public class Car { public Car(CarRadio carRadio, Motor motor){...} } public class SpeedLimit { public bool IsViolatedBy(Car car){...} } 另一个Car Code Example（TM）仅简化为对该问题重要的部分。我现在写了一个类似这样的测试： public class SpeedLimitTest { public void TestSpeedLimit() { Motor motor = new Motor(); …

37 unit-testing 

在开发计划与某个框架一起使用的系统或应用程序时，最好的做法是在不考虑框架的情况下设计系统，还是最好以一种思维定势来设计系统，“那么框架将拥有更轻松的时间有了这个”。

37 development-process  systems 

我有一种更新数据库中员工数据的方法。该Employee班是不变的，所以“更新”的对象实际上手段来实例化一个新的对象。 我希望该Update方法返回Employee具有更新数据的新实例，但是由于现在我可以说该方法的责任是更新员工数据，并从数据库中获取新Employee对象，这是否违反了单一职责原则？ 数据库记录本身已更新。然后，实例化一个新对象来表示该记录。

37 single-responsibility 

假设您刚开始在一个非常小的团队中从事{目前相对较小，但希望以后会更大}的项目。请注意，这是一个旨在供现实世界中的其他开发人员使用的实际项目，而不是一些打算在学期末取消的学术项目。 但是，该代码尚未发布给其他人，因此尚未确定任何决定。 方法论 你们中的一个喜欢在开始编写代码并使各部分组合在一起之前，必须对所有组件的交互方式（自下而上的设计）有个清晰的认识。你们中的另一个人喜欢先进行整个设计，然后在编码解决方案之前确定所有组件和通信的细节。 假设您正在开发一个新系统，而不是模仿现有系统，因此，正确的最终设计应该是什么样子并不总是显而易见的。因此，在您的团队中，不同的团队成员有时甚至对最终产品所需的要求有不同的想法，更不用说如何进行设计了。 当自下而上的开发人员编写一些代码时，尽管该代码可能会解决手头的问题，但自上而下的开发人员还是会因为设计中可能会遇到的未来问题而拒绝该代码，并认为正确设计更重要在尝试编写解决方案的代码之前。 当自上而下的开发人员在开始编写代码之前尝试设计出完整的设计和设想的问题时，自下而上的开发人员会拒绝它，因为自下而上的开发人员并不认为实际上会出现某些问题，并认为，当要求和约束变得更加清晰时，将来可能需要更改设计。 问题 这导致的问题是自下而上的开发人员最终浪费了时间，因为自上而下的开发人员经常由于设计缺陷而决定废弃自下而上的开发人员编写的解决方案，从而需要重新设计。 -编写代码。 自上而下的开发人员最终浪费了时间，因为自上而下的开发人员现在经常坐下来与自下而上的开发人员一起制定正确的设计，将两者序列化到甚至更快的程度比2人多做1人。 两位开发人员都希望继续合作，但似乎合并实际上并没有帮助他们中的任何一个。 目标 显然，共同的目标是最大程度地提高编码效率（即，将时间浪费最小化）并编写有用的软件。 问题 简而言之，您如何解决这个问题并应对这种情况？ 我能想到的唯一有效的解决方案不会浪费时间，就是让每个开发人员都遵循自己的设计风格。但是，这比您进行代码审查并实际上需要批准彼此的更改以及尝试设计一个供他人使用的一致框架时听起来的困难。 有没有更好的办法？

37 design  development-methodologies  methodology 

我想知道while循环本质上是否是递归？ 我认为这是因为while循环可以看作是最后调用自身的函数。如果不是递归，那有什么区别？

37 recursion  loops 

聊天中已经讨论了一个问题（该问题本身与该问题无关），这表明我可能不知道Python。 在我看来，尽管术语在不同语言之间是不同的，但我们通常可以将功能归类为： [免费]功能 静态方法/静态成员函数 非静态方法/非静态成员函数 显然，在Python中，还有另一种不适用于上述类别的函数，一种是方法，但“不知道其类”。 在Python中，什么是“类方法”和“实例方法”？

37 python  terminology 

过早发布开源软件的道德责任是什么？例如，尚未完全测试的接近完成的产品。 程序员的期望是什么？等待，直到它经过完全测试，或者发布到开源，然后继续进行进一步的开发，测试和改进？ 担心的是软件是开源的，并有可能为消费者带来问题。 这是没有根据的恐惧吗？

37 open-source 

我已经在许多地方看到，规范知识1是调用者的责任，以确保您在更新UI组件时位于UI线程上（特别是在Java Swing中，您位于Event Dispatch Thread上） 。 为什么会这样呢？事件分发线程是MVC / MVP / MVVM中视图的关注点；在视图之外的任何地方处理它，都会在视图的实现和该视图的实现的线程模型之间建立紧密的耦合。 具体来说，假设我有一个使用Swing的MVC架构的应用程序。如果调用者负责更新事件调度线程上的组​​件，则如果我尝试将Swing View实现换成JavaFX实现，则必须更改所有Presenter / Controller代码以改为使用JavaFX Application线程。 因此，我想我有两个问题： 为什么调用者有责任确保UI组件线程安全？我上面的推理中的缺陷在哪里？ 我该如何设计我的应用程序以松散耦合这些线程安全问题，但仍然是适当的线程安全？ 让我添加一些MCVE Java代码来说明“调用者负责”的含义（这里还没有其他好的做法，但我试图将其尽量减少）： 来电者负责： public class Presenter { private final View; void updateViewWithNewData(final Data data) { EventQueue.invokeLater(new Runnable() { public void run() { view.setData(data); } }); } } public class View { void …

37 mvc  multithreading  user-interface 

我当时正在与一位同事进行讨论，但最终我们对继承的目的产生了矛盾的直觉。我的直觉是，如果子类的主要功能是表达其父级的可能值的有限范围，则它可能不应该是子类。他主张相反的直觉：子类化表示对象的“特定性”更高，因此子类关系更合适。 更具体地讲，我认为如果我有一个扩展父类的子类，但是该子类覆盖的唯一代码是构造函数（是的，我知道构造函数通常不会“重写”，请耐心等待），然后真正需要的是一种辅助方法。 例如，考虑一下这个现实生活的类： public class DataHelperBuilder { public string DatabaseEngine { get; set; } public string ConnectionString { get; set; } public DataHelperBuilder(string databaseEngine, string connectionString) { DatabaseEngine = databaseEngine; ConnectionString = connectionString; } // Other optional "DataHelper" configuration settings omitted public DataHelper CreateDataHelper() { Type dataHelperType = DatabaseEngineTypeHelper.GetType(DatabaseEngine); DataHelper …

37 design-patterns  object-oriented  inheritance  anti-patterns 

我正在清理正在处理的C ++项目中的包含，并且我一直在想是否应该将直接使用的所有标头明确包含在特定文件中，还是应该仅包含最低要求。 这是一个例子Entity.hpp： #include "RenderObject.hpp" #include "Texture.hpp" struct Entity { Texture texture; RenderObject render(); } （让我们假设对它的前向声明RenderObject不是一种选择。） 现在，我知道其中RenderObject.hpp包括Texture.hpp-我知道，因为每个人RenderObject都有一个Texture成员。不过，我还是明确地将Texture.hppin 包含在内Entity.hpp，因为我不确定依赖于in是一个好主意RenderObject.hpp。 因此：这是一种好的做法吗？

37 c++  c  headers  include