软件工程

针对在系统开发生命周期中工作的专业人士，学者和学生的问答

2
工作流程，编辑当前任务中没有的内容
通常，当我编程时，我要完成一个明确的任务，但是会发现我想继续进行的烦人的事情要清理。 在这里，我看到三个选项： 以后再做（可能会忘记/不得不花费时间添加票证） 现在就做，并将其与我当前的工作一起提交（不清楚） 现在执行并分别提交（必须找到它，可能会犯一个错误，无意中选择了选项2） 这可能是相当基本的，但是有什么方法可以使用svn / git / other来规避呢？
5
最终和析构函数之间的概念区别是什么？
首先，我很清楚为什么C ++中没有“最终”构造？但是关于另一个问题的冗长的评论讨论似乎需要一个单独的问题。 除了finally在C＃和Java中每个作用域基本上只能存在一次（== 1）并且单个作用域可以具有多个（== n）C ++析构函数的问题之外，我认为它们本质上是同一件事。（存在一些技术差异。） 但是，另一个用户认为： ...我试图说dtor本质上是（发布语义）的工具，而最终本质上是（提交语义）的工具。如果您不明白为什么，请考虑：为什么在finally块中相互抛出异常是合法的，以及为什么析构函数则不这样？（从某种意义上说，这是数据与控制的事情。析构函数用于释放数据，最终用于释放控制。它们是不同的；不幸的是C ++将它们绑在一起。） 有人可以清理吗？
2
Java 8 Stream实例是否应该始终是close（）'？
对Javadoc的看法： 流具有BaseStream.close（）方法并实现AutoCloseable，但实际上几乎所有流实例在使用后实际上都不需要关闭。通常，只有源是IO通道的流（例如，由Files.lines（Path，Charset）返回的流）才需要关闭。大多数流都由集合，数组或生成函数支持，不需要特殊的资源管理。（如果流确实需要关闭，则可以在try-with-resources语句中将其声明为资源。） “几乎所有”和“通常”是模糊的-如果您正在编写库，并且要从该Stream的用户中提取Stream的源，那么无论如何，您总是必须问自己一个问题-“我应该关闭这个？” IO支持的流需要关闭，因为终端操作不会调用close，所以有效地我总是必须记住/记录我的Stream的来源，或者我总是必须这样close做。 我猜想，最明智的选择是不从方法中返回Streams或接受Stream参数，这是JDK团队中某些人所认同的观点。考虑到Streams的实用性，我发现这过于局限。 关闭Streams的最佳做法是什么？我在网上寻找了一些JDK人员的答案，这些人员通常都积极参与类似的社区问题，但是没有发现任何相关的内容。
12 java  resources  java8 
5
如何避免在管理缓存的类中违反SRP？
注意：代码示例是用c＃编写的，但这无关紧要。我将c＃用作标签，因为找不到更合适的标签。这是关于代码结构的。 我正在阅读Clean Code，并试图成为一个更好的程序员。 我经常发现自己难以遵循“单一责任原则”（类和功能只能做一件事），尤其是在功能方面。也许我的问题是“一件事”的定义不明确，但仍然... 一个例子：我在数据库中有一个Fluffies列表。我们不在乎什么是蓬松。我想上课恢复蓬松。但是，蓬松可以根据某些逻辑进行更改。根据某些逻辑，此类将从缓存中返回数据或从数据库中获取最新数据。我们可以说它管理蓬松，这是一回事。为了简单起见，假设加载的数据可以使用一个小时，然后必须重新加载。 class FluffiesManager { private Fluffies m_Cache; private DateTime m_NextReload = DateTime.MinValue; // ... public Fluffies GetFluffies() { if (NeedsReload()) LoadFluffies(); return m_Cache; } private NeedsReload() { return (m_NextReload < DateTime.Now); } private void LoadFluffies() { GetFluffiesFromDb(); UpdateNextLoad(); } private void UpdateNextLoad() { m_NextReload = DatTime.Now …
1
如何在GitHub拉取请求上进行同行评审？
我们正在从Bitbucket迁移到GitHub，而我们正在努力的一件事是对等代码审查，在Bitbucket上的运行非常顺利，如下所示： 作者打开了一个拉取请求（GitHub：相同） 作者将他/她的同事添加为审阅者（GitHub：??在这里与多个受让人苦苦挣扎） 评论者： 批准带有绿色复选标记的PR （GitHub：??） 添加了评论（GitHub：相同） 创建轻量级任务（GitHub：如果- [ ]PR描述中使用了语法，则类似；可耻的是，它不适用于任务） 有一个PR列表，我可以一目了然地看到它们，可以进行审查，可以合并，还需要进一步关注（GitHub：??） 我应该指出，我们要尽可能避免使用第三方代码审查工具，并希望通过某些解决方法保留在原始GitHub上。
1
Git从功能分支分支到子功能
我们目前处于以下情况，其中功能分支已分支为子功能分支（例如，为同一功能处理后端和前端事物）： o | o development |\ | o feature-a | | | o | |\ | | o feature-a-sub | | | | | | | \ | o merged feature-a into feature-a-sub | / o feature-a-sub merged into development | | | o feature-a with future work on it …
12 git  branching 
3
非可选指针与C ++中的非常量引用
在其他C ++功能，参考参数的的谷歌C ++风格指南，我读的非const引用，不得使用。 通过引用传递的所有参数都必须标记为const。 很明显，对于C程序员来说，使用引用作为参数的函数调用绝对令人困惑，但是C和C ++现在是不同的语言。如果输出参数需要，使用指针为所需的输出参数，可能对被跳过整个功能体，这使得更复杂的功能（正式增加的实施圈复杂和深度的函数的）。 我想使C ++代码尽可能容易理解/维护，因此我通常对阅读编码风格指南感兴趣。但是，为了适应团队中的最佳实践，我认为理解样式指导元素背后的原理是一个重要因素。 非常量引用真的那么糟糕吗？是只禁止Google禁止使用它们还是被普遍接受的规则？是什么证明了将输出参数实现为指针所付出的额外努力？
3
了解助焊剂模式
我实际上正在研究流量模式，关于商店我有些不了解。 他们到底是什么？ 我已经阅读了许多文章，似乎与该领域有关。 这是否意味着这是与api调用或后端调用相关的“抽象”部分？ 对我来说不是很清楚。 编辑：可能与角度工厂相同吗？获取远程数据，执行业务任务或存储某些应用程序状态（例如，当前连接的用户）？
2
JRE库中的类是否支持对外部/非JRE程序集的可观察和/或异步读取？
如何实现我的跨平台库（例如在JRE上）以对对象引用以线程安全的方式进行操作，以便其他平台上的本机前端可以观察对象并利用Observable模式？ 有一点背景-大多数前端框架中都使用了数据绑定的概念。在C＃和Java中，这与Observable特性有关，该特性使类能够在发生更改时触发事件，多个控件或“观察者”可以订阅该事件。这样，观察者就不必继续轮询/读取资源，进行更新比较。 我想研究一个分析引擎，该引擎会随着时间的推移对数据列表进行更改。能够让前端在分析运行时能够观察这些列表将是很好的。在我看来，这将要求前端能够将对象传递给分析引擎，并在希望跨平台的库中编写该对象，并且能够对该对象进行线程安全读取。否则，让图书馆满足可观察性合同。 在较旧的Unix风格的CLI引擎中处理此问题的方法是使用stdin / stdout / stderr，并使引擎定期更新更新。这需要标准的开销和文本解析，如果可能的话，我宁愿避免。
2
如何编写抽象数据库接口以支持多种数据库类型？
如何开始在其较大的应用程序中设计一个抽象类，该类可以与多种类型的数据库（例如MySQL，SQLLite，MSSQL等）接口？ 这个设计模式叫什么，它从哪里开始呢？ 假设您需要编写一个具有以下方法的类 public class Database { public DatabaseType databaseType; public Database (DatabaseType databaseType){ this.databaseType = databaseType; } public void SaveToDatabase(){ // Save some data to the db } public void ReadFromDatabase(){ // Read some data from db } } //Application public class Foo { public Database db = new …
12 c#  database 
2
为什么单元测试属性通常需要公共方法？
我最近注意到，不尊重在.NET程序集中的受保护方法中添加[TestInitialize]，但是如果我将该方法公开，则它会被单元测试运行程序（在这种情况下为Resharper）调用。我过去用测试方法已经注意到了这几次。 从技术上讲，它就像公开方法一样容易反映在私有方法上。实际上，反射是一种用于对私有方法进行单元测试的方法。 那么，为什么我需要公开我所有的单元测试方法？
3
是否适合将已知问题直接放入软件中？
我已经接管了一个Android应用的维护工作，虽然有一些残留的问题或多或少已经得到解决，但是由于Android操作系统版本不同，仍然存在一些问题。 例如，使用MediaPlayer类发送Web请求时，操作系统发出请求之前剥离了自定义HTTP标头，但仅在Android 4.X（我经过详尽测试）上，这导致该特定功能失败，因为它依赖在这些标题上。 这是一个已知问题，我正在尝试解决，但是有条件的检查是一个好主意，例如 if (OS.VERSION == 4) { knownIssueDialog(This feature will not work on your Android version... etc."); } 显然，我们会在支持渠道上对此进行说明，但我想知道将这些已知问题也嵌入到软件中并在必要时，必要时进行展示是否是一个好主意（假设一切都已被跟踪）例如我上面所描述的。 基于此类问题，我们不断收到许多不良评论和大量支持电子邮件，因此在我看来，仅阻止已知无法正常工作的功能，它将为每个人节省大量时间和头痛。 我看到两个潜在的问题： 用户以前可能从未见过类似“已知问题”对话框的内容。很多用户可能根本不明白这意味着什么。 有一些开发开销-需要确保在代码中的某些地方跟踪这些问题。幸运的是，有了Java批注，诸如此类的条件检查可以在其之前@KnownIssue或类似的东西进行，这使得查找/修改它们非常简单。 在软件中添加“已知问题”提示是否有意义？ 编辑：我将添加一个大约一个星期前才开始出现的问题。我已经修复了该问题的一半，并且不太可能能够为4.X修复此问题，因为导致问题的是操作系统。我可以发布包含此修复程序的新版本，并使50％的用户群再次满意，并警告其他50％（4.X用户）该问题将继续存在于4.X上，并提出升级建议（或其他建议） ）。问题是是否要在软件中执行此操作（即向4.X用户显示对话框），还是只让他们向我们发送垃圾邮件，我们将通过电子邮件支持“您的修复无效！”的电子邮件！然后将他们定向到支持页面，其中将详细讨论该问题。
2
如何处理C ++ 11中auto_ptr弃用的设计更改？
我们正在测试C ++ 11（即-std=c++11）下的库。该库使用auto_ptr以下模式： Foo* GetFoo() { autoptr<Foo> ptr(new Foo); // Initialize Foo ptr->Initialize(...); // Now configure remaining attributes ptr->SomeSetting(...); return ptr.release(); } C ++ 11已弃用auto_ptr，因此我们希望远离它。 但是，该代码同时支持C ++ 03和C ++ 11，因此它不是yanking那样简单auto_ptr。还值得一提的是该库没有外部依赖项。它使用C ++ 03; 并且不使用Autotools，Cmake，Boost等 auto_ptr在保持与C ++ 03的兼容性的同时，我们应如何处理设计更改以脱离C ++ 11？
12 design  c++  c++11 
3
如果某个接口继承自其他接口，是否将其视为“空”？
据我所知，空接口通常被认为是不好的做法-特别是在语言支持的属性之类的地方。 但是，如果某个接口继承自其他接口，是否将其视为“空”？ interface I1 { ... } interface I2 { ... } //unrelated to I1 interface I3 : I1, I2 { // empty body } 任何实现I3将需要实现I1和I2，并从不同的类，这些类继承的对象I3然后可以互换使用（见下文），所以是不是叫I3 空？如果是这样，哪种更好的架构方法呢？ // with I3 interface class A : I3 { ... } class B : I3 { ... } class Test { void foo() …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.