软件工程

我加入了一个已经运行了几年的中型项目的中间阶段。问题之一是从未描述过描述体系结构的文档。现在，我被分配了编写架构描述的任务。 在从事该项目的过程中，我收集了编写文档所需的所有信息。由于还添加了一些功能，因此确定了一些代码，这些代码显然破坏了所描述的体系结构。 例如，GUI应该是没有业务逻辑的薄层。那就是我被告知的。该实现包含很多逻辑。 老板给我分配了任务，写了描述系统体系结构的文档。目标受众是从事该项目的现在和将来的开发人员。我需要描述应该是什么，但是我还需要以某种方式描述偏差。 那么，我应该在哪里描述这些问题呢？错误跟踪软件？还是应该在描述系统体系结构的文档中描述实现与体系结构的偏差？

18 architecture  issue-tracking 

背景 从开发人员的角度来看，Windows 10的主要卖点是其新的Universal * Windows Platform（UWP）。 *如果“万能”的真正含义“万能到运行Windows 10的所有设备”，而不是“普及到运行不仅限于Windows 10的设备，但也是Windows 8.1和可能的Windows 7”。因此，如果您要构建UWP应用程序，则实际上只是在构建“ Windows 10应用程序”。UWP应用程序甚至无法在Windows 8.1和Windows Phone 8.1设备上运行，即它们根本不向后兼容。 从2015年第三季度开始，Windows 10可用于PC和IoT设备。至少要再过几个月才能向公众发布Windows 10移动版，但可能不会超过一年。这意味着Windows Phone 8.1将保留一段时间。 题 我将开始开发Windows Phone应用程序，由于它是一个相当简单的应用程序，因此我计划在下个月左右发布它。由于Windows 10移动版不会很快面世，更不用说升级的设备了，我现在必须瞄准Windows Phone 8.1。但是，由于它不会是那个视窗10没过多久手机的推出，我想知道，如果它会是明智的准备我的部署解决方案到Windows 10 UWP 以及 Windows Phone的8.1（这也会让我在需要时继续支持8.1）。 我看到我可以在同一解决方案中将UWP项目和8.1项目分组，并且可以像Visual Studio中的Windows 8.1 Universal模板一样通过共享项目共享源文件和资产。我在正确的轨道上吗？如果是这样，我是否应该遵循任何其他准则来确保所有功能（包括XAML，理想情况下，我希望在两个平台上都具有相同或至少相似的UI）在两个平台上均能正常工作（考虑到任何不一致性）？ 另外，我现在不必担心Windows 10移动版并从8.1项目开始，然后再将其迁移到UWP，但是由于我不打算放弃8.1，所以我仍然必须维护我的两个版本。用户立即。在这种情况下，我仍然需要担心功能/ XAML奇偶校验。

18 visual-studio  projects-and-solutions  windows-10  windows-phone-8.1  uwp 

C＃具有out和ref关键字。为什么需要这两个？免责声明：我对C＃并不了解。

18 c#  parameters  keywords 

公平的警告，我是函数编程的新手，所以我可能有很多错误的假设。 我一直在学习代数类型。许多功能语言似乎都有它们，它们在与模式匹配一​​起使用时非常有用。但是，他们实际上解决了什么问题？我可以像这样在C＃中实现一个看似（排序）的代数类型： public abstract class Option { } public class None : Option { } public class Some<T> : Option { public T Value { get; set; } } var result = GetSomeValue(); if(result is None) { } else { } 但是我认为大多数人都同意这是面向对象编程的混蛋，您永远都不要这样做。那么函数式编程是否只是添加了一种更简洁的语法，从而使这种编程风格看起来不太那么粗拙？我还想念什么？

18 functional-programming  algebraic-data-type 

我们的经理正在监视我们所有项目中的Git承诺；通常这不是问题，我喜欢这样一个事实，即版本控制提供了所有正在发生的工作的日志，尤其是对于以后的审核和分析（以防万一出现问题）。 但是，该经理发表了一些评论，询问人们在看到提交中看到“样式修复”的提交或在我们的任务管理系统中未引用故障单编号的任何提交消息时，人们在做什么。 有社会或技术解决方案吗？ 进一步的信息：这是一个维护项目，因此发生了很多“必须先执行A，然后是B，然后是C，然后是D，最后要实现X”的任务。 更多信息：特定的提交消息向管理器发出了标志，它接近“包含了一种更好的X，Y和Z方式”，这更多是重构消息，而不是简单的样式修复。

18 version-control  management 

就像一个稻草人考虑的那样，java.util它是各种课程的垃圾场，在大多数情况下，除了让他们在那里的人懒惰或没有动力为他们的课程提出一个语义上更正确的软件包名称外，大多数情况下没有其他共同点。 作为一个示例，使用该类UUID在该语义上正确的包名称是什么？ 我正在努力实现自己的UUID类，以使其更加轻巧。我不想使用me.myproject.util.UUID我的包裹名称。 我考虑过，me.myproject.rfc4122.UUID但这并不意味着使用的语义UUID。 我也考虑过，me.myproject.uuid.UUID但我不喜欢重言式，尽管在Python中将同名的类放入模块中是一种流行的方法，而packagesJava在语义上并不等同modules于Python。 我也考虑me.myproject.UUID但拒绝了它，因为我不想用不相关的内容污染名称空间的那一部分。这只是使问题更上一层楼。 我也考虑过，me.myproject.lib.UUID但这并没有更多的语义含义.util，只是重命名了问题。 semantics：与意义有关的语言学和逻辑学分支。

18 naming  packages  namespace 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 假设我创建了一个新的（DSP）算法。如果我在copyleft许可证（GPL等）下开源算法，是否会有一些优势？从我对许可的了解中，这应该使人们避免使用与封闭源完全相同的代码，但是他们能够将算法“重写”为封闭源吗？ 注意：我真的不知道该算法是否是新算法，但尚未作为开源发布。因为我来自欧盟，所以如果我想版权所有，我需要寻找软件专利吗？

18 algorithms  licensing  gpl 

这个问题是关于我应该如何设计一个数据库，它可以是关系型/ nosql数据库，这取决于什么是更好的解决方案 根据要求，您需要创建一个系统，该系统将包含一个跟踪“公司”和“用户”的数据库。一个用户总是只属于一个公司 用户只能属于一个公司 一个公司可以有很多用户 “公司”表的设计非常简单。公司将具有以下属性/列：（让我们保持简单） ID, COMPANY_NAME, CREATED_ON 第一种情况 简单明了，用户都具有相同的属性，因此可以通过关系样式，用户表轻松完成此操作： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON 第二种情况 如果不同的公司想要为其用户存储不同的配置文件属性，会发生什么情况。每个公司将具有一组定义的属性，这些属性将应用于该公司的所有用户。 例如： 公司A要存储：LIKE_MOVIE（布尔值），LIKE_MUSIC（布尔值） 公司B要存储：FAV_CUISINE（字符串） 公司C要存储：OWN_DOG（布尔值），DOG_COUNT（整数） 方法1 暴力方式是为用户提供一个单一的架构，并在不属于公司的情况下让其为空： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON 这有点麻烦，因为您最终会得到很多NULL，并且用户行的列与它们不相关（即，属于公司A的所有用户的FAV_CUISINE，OWN_DOG，DOG_COUNT的值为NULL） 方法2 第二种方法是拥有“自由格式字段”： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON 由于您不知道什么是自定义字段，因此这本身就很麻烦，数据类型将无法反映所存储的值（例如，我们将int值存储为VARCHAR）。 方法3 …

18 database  database-design  sql  nosql 

有人告诉我“用户故事不是需求，它只是在提醒客户需要什么，您不能在故事中放入需求”。但让我们举一个例子，客户希望对不同的信用卡进行不同的处理。必须执行并知道严格的要求，以便可以编写测试用例。如果不在用户故事中，需求应该去哪里？ 如果没有更低的要求，开发人员如何从故事中发展？测试人员如何根据用户故事编写测试用例（详细的用例）？用户故事之外还存在DB约束，字段验证等需求吗？

18 agile  scrum  requirements 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 由于机器语言（例如0110101000110101）计算机语言通常已经演化为更高形式的抽象，因此通常将其应用于问题时更易于理解代码。汇编器是对机器代码的抽象，C是对汇编器的抽象，等等。 面向对象的设计似乎非常擅长于使我们能够根据对象对问题进行建模，例如，可以使用Course类，Student类等对大学课程注册系统的问题进行建模。然后，当我们编写解决方案时在OO语言中，我们有类似的类来承担责任，并且通常对设计特别是模块化代码有帮助。如果我将这个问题交给使用OO方法解决此问题的10个独立团队，通常这10个解决方案将具有与该问题相关的类。当您开始接触这些类的耦合和相互作用时，可能会有很多差异，因此不存在“零代表间隙”之类的问题。 我对函数式编程的经验非常有限（没有实际使用，只有Hello World类型的程序）。我没有看到这样的语言如何像OO语言那样轻松地将FP解决方案映射到问题（具有较小的表示差距）。 我了解FP在并发编程方面的优势。但是我是否缺少某些东西，或者FP是否不是要缩小代表差距（使解决方案更容易理解）？ 提出另一种方式是：10个不同团队解决同一现实问题的FP代码有很多共同点吗？ 摘自维基百科上的抽象（计算机科学）（重点是我的）： 函数式编程语言通常会展示与函数相关的抽象，例如lambda抽象（将术语变成某些变量的函数），高阶函数（参数是函数），括号抽象（将术语变成变量的函数）。 由于[某些]现实世界中的问题很难用这种抽象模型来建模，因此代表性的差距可能会增加。 我看到减小代表性差距的另一种方法是将解决方案元素追溯到问题所在。在0年代和1S IN的机器代码是很难追溯，而Student类是容易追溯。并非所有的OO类都可以轻松地跟踪到问题空间，但是许多类都可以。 FP抽象不是总是需要解释以找出他们要解决的问题空间的哪一部分（除了数学问题）？好的-这方面我很好。在查看了更多示例之后，我将看到FP抽象对于在数据处理中表达的问题的一部分非常清晰。 对相关问题的可接受答案UML可以用于对功能程序进行建模吗？-说“功能程序员在图表中没有太多用处。” 我真的不在乎它是否是UML，但是这使我想知道，如果没有被广泛使用的图，那么FP抽象是否易于理解/交流（假设这个答案是正确的）。同样，我对FP的使用/理解水平是微不足道的，因此我了解不需要简单FP程序的图表。 OO设计具有抽象的功能/类/包级别，每个级别都有封装（访问控制，信息隐藏），这使得管理复杂性变得更加容易。这些是使问题从解决方案回到解决方案的要素。 许多答案都谈到了如何以类似于OO的方式在FP中完成分析和设计，但是到目前为止，没有人引用任何高级信息（保罗引用了一些有趣的东西，但它是低级的）。昨天我做了很多谷歌搜索，发现了一些有趣的讨论。以下摘自Simon Thompson（2004）的“重构功能程序”（重点是我的） 在设计面向对象的系统时，理所当然的是，设计将优先于编程。设计将使用诸如Eclipse之类的工具支持的UML之类的系统编写。入门程序员可能会使用BlueJ之类的系统很好地学习视觉设计方法。FAD：Functional Analysis and Design中报告了类似的函数编程方法的工作，但几乎没有其他工作。可能有许多原因。 现有的功能程序具有不需要设计的规模。许多功能程序都很小，但其他功能程序（例如格拉斯哥Haskell编译器）则很实用。 功能程序直接为应用程序领域建模，因此使设计无关紧要。虽然功能语言提供了各种强大的抽象，但是很难说这些提供了对现实世界建模所需的全部和唯一的抽象。 功能程序是作为一系列不断发展的原型而构建的。 在以上引用的博士学位论文中，概述了使用分析和设计方法（ADM）的好处，而与范式无关。但是有人提出ADM应该与实现范例保持一致。也就是说，OOADM最适合用于OO编程，并且不能很好地应用于诸如FP之类的另一范式。我认为这是一个很好的报价，这就是我所说的代表性差距： 人们可以就哪种范式为软件开发提供最好的支持进行详尽的争论，但是当一个范式停留在从问题描述到实施和交付的单一范式中时，就可以实现最自然，有效和有效的开发包。 以下是FAD提出的一组图表： 功能依赖关系图，提供功能及其在实现中使用的功能； 类型依赖图，为类型提供相同的服务；和， 模块依赖关系图，显示系统模块结构的视图。 FAD论文的第5.1节中有一个案例研究，该系统可以自动生成与足球（足球）联赛有关的数据。这些要求具有100％的功能，例如输入足球结果，产生联赛表，得分表，出勤表，在团队之间转移球员，在新结果后更新数据等。没有记录FAD如何解决非功能性要求除了声明“应该以最低的成本允许使用新功能”之外，几乎无法进行测试。 遗憾的是，除了FAD之外，我没有看到任何针对FP提出的现代建模语言（可视化）参考。UML是另一个范例，因此我们应该忘记这一点。

18 object-oriented  object-oriented-design  functional-programming  abstraction 

我正在使用Visual Studio在C＃中创建GUI应用程序。工具箱是一个漂亮的组件面板，它使我可以轻松地将按钮和其他元素（为清楚起见，每当我表示“控件”，我都会说按钮）拖放到表单上，这使得静态表单非常容易做到。但是，我遇到两个问题： 首先创建按钮需要很多工作。当我使用的表单不​​是静态的时（即，根据用户的操作在运行时创建了按钮或其他控件），我根本无法使用调色板。相反，我必须通过使用我使用的任何方法调用构造函数来手动创建每个按钮，然后通过指定按钮的高度，宽度，位置，标签，事件处理程序等手动进行初始化。这非常繁琐，因为我必须猜测所有这些修饰参数，而又看不到表格的外观，而且每个按钮都会生成许多行重复的代码。 使按钮执行某些操作也是很多工作。在功能齐全的应用程序中处理事件是一个巨大的痛苦。我知道如何执行此操作的唯一方法是选择一个按钮，转到其属性中的“事件”选项卡，单击该OnClick事件，以使其在Form的代码中生成该事件，然后填写该事件的主体。由于我想分离逻辑和表示，因此所有事件处理程序最终都是对适当的业务逻辑功能的单行调用。但是，将它用于许多按钮（例如，想象像MS Word这样的应用程序中存在的按钮数目）会Form用数十种样板事件处理程序方法污染我的代码，并且很难维护。 因此，要让我真正使用任何比Hello World更复杂的GUI程序都是不切实际的。明确地说，在编写具有最小UI的程序中，处理复杂性没有任何问题-我觉得我能够使用具有相当能力的OOP来整齐地构造我的业务逻辑代码。但是在开发GUI时，我陷入了困境。似乎很乏味，以至于我感觉自己正在重新发明轮子，并且那里有一本书解释了如何正确地做GUI，而我还没有读过。 我想念什么吗？还是所有C＃开发人员都只是接受无尽的重复事件处理程序和按钮创建代码列表？ 作为一个（希望有帮助的）提示，我希望一个好的答案可以谈论： 使用OOP技术（例如工厂模式）简化重复按钮的创建 将许多事件处理程序组合到一个方法中，该方法检查Sender以找出哪个按钮调用了它，并相应地运行 XAML并使用WPF代替Windows窗体 你不需要有提，当然任何这些。关于我要寻找的答案，这只是我的最佳猜测。

18 c#  gui  visual-studio 

我正在编写（递归）代码来浏览依赖关系图，以查找依赖关系中的循环或矛盾。但是，我不确定如何进行单元测试。问题是我们主要关心的问题之一是将对可能出现的所有有趣的图结构进行代码处理，并确保所有节点都将得到适当处理。 尽管通常100％的行或分支覆盖率足以确保某些代码可以工作，但即使100％的路径覆盖率，您仍然会有疑问。 因此，如何为测试用例选择图形结构，以确保其代码可以处理您在真实数据中发现的所有可能的排列。 PS-如果重要的话，我图中的所有边都标记为“必须具有”或“不能具有”，并且没有琐碎的循环，并且任何两个节点之间只有一条边。 PPS-此附加问题声明最初由问题的作者在以下评论中发布： For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.

18 unit-testing  graph  test-coverage 

为什么我们需要同时包含.h和.cpp文件，而仅通过包含.cpp文件就可以使其起作用？ 例如：创建一个file.h包含声明，然后创建一个file.cpp包含定义，并将两者都包含在中main.cpp。 或者：在中创建一个file.cpp包含声明/定义的声明（没有原型）main.cpp。 两者都为我工作。我看不出有什么区别。也许对编译和链接过程有一些了解可能会有所帮助。

18 c++  c  headers  linking  include 

我正在努力通过工作流程策略在我的公司中实施Gitlab。我的想法是，将为开发人员提供访问存储库的权限，但是，无论何时他们尝试提交，都必须对其代码进行审查。 我知道我可以让他们在提交之前创建一个分支，然后在将其推送到存储库之后创建一个合并请求。我仍然不清楚某些事情……我们依靠人们创建分支然后合并请求的想法似乎是错误的，是否存在一种解决方案，该解决方案会强制执行某种策略，除非master分支保持“干净”管理员”批准将要合并到其中的代码。我已经阅读了“ github团队工作流程”，但是它似乎没有提供可行的解决方案。关于过程或您自己的最佳实践的任何建议都将受到赞赏。谢谢！

18 development-process  git  gitlab 

为两个通用目的相同的名称完全不同的文件将它们分成不同的目录，这是一种不好的做法吗？ <script src="client_scripts/app/player_stats/generator.js"></script> <script src="client_scripts/app/coach_settings/generator.js"></script> 我想使文件名简短，并且两个文件具有相同的通用目的，但不完全相同。我不确定在专业编程环境中这是否会被视为不良做法。我想知道在这种情况下的最佳做法。 或者，以牺牲名称的简短长度为代价，我可以使用： <script src="client_scripts/app/player_stats/player_stats_generator.js"></script> <script src="client_scripts/app/coach_settings/coach_settings_generator.js"></script>

18 naming  file-structure