问题标签 [code-maintainability]

Gridview 和 detailsview 应用程序：旧程序的 select 语句、aspx.cs 代码等是从 Visual Studio 向导自动生成的。现在，他们要求在 select 语句中添加另一列，并在现有详细信息视图中为该列添加一个下拉框。我该如何更新它？

通过手动键入新代码并将其插入现有文件，还是使用 Visual Studio 向导重新生成具有新要求的旧代码？我会丢失旧的作者姓名缩写和评论，因为它会自动重新生成所有代码吗？

正则表达式很快变得太复杂（对我来说）无法理解。即使像[ab][cd], 这样简单的东西也有几个逻辑分支。我的目标是提高代码库的可维护性，因此这些问题的答案可以帮助我们检测和修复复杂代码：

1. 是否存在包含正则表达式固有的复杂性的计算复杂度度量（类似于圈复杂度）？
2. 是否有任何工具可以为正则表达式生成复杂度数？
3. 是否有可以建议简化正则表达式的工具？

计算一个表的最佳方法是什么，其中许多列是从同一个表中的其他列计算出来的，并且公式以复杂的方式相互建立。

如果您不关心性能，您可以简单地使用自己的更新语句计算每一列：

或者，如果您手动扩展公式，您可以在一次更新中完成所有操作：

这里的问题是这些公式可能会变得庞大且难以更改和调试。

Postgres（或者甚至是一般的 SQL）中是否有某种方法可以在这些情况下同时具有性能和可维护性？

这是我希望我能做的事情：

我有一个可行的解决方案，其中公式在具有多个返回值的函数中定义，但这在其他一些方面相当不灵活，所以我正在寻找替代方案。

最近，我知道以模块化或组件的方式编写代码很重要。但我不确定为什么它如此重要。

如果你知道，有人可以解释为什么它很重要吗？

我计划跟踪 5-10 之间的方法和类的圈复杂度。如果我们将其保持在该范围内，编写单元测试会更容易吗？它是否有助于我们编写有效的单元测试，从长远来看是有价值的？

我知道可以在不跟踪圈复杂度的情况下正确编写单元测试。

有什么想法吗？

是否可以将 EF 查询写入模型文件夹内的单独类文件中，而不是将其写入控制器本身。

因为我在 msdn 中看到在控制器本身中编写所有 EF 查询。同时，我也曾在 msdn 中阅读过该控制器的简短说明。

使用模型我使用这种方法：

在控制器中：

在模型类中：

还是在控制器本身中编写所有代码更好？

方法 1：在一个 android 应用程序中，显示了一个持续时间 TextView（如：“ 2 h 45 m”）和另一个带有 Stops 数量的 TextView（如：“Stops: 15 ”）。它们之间是另一个 TextView (" | ") 来分隔它们。

方法 2：仅使用一个 TextView、一个 String 模板和串联将其放在一起。

考虑数据（2 45和15）来自后端，并且停止的数量在逻辑上与持续时间没有真正的联系。

我的问题是：

考虑到性能和代码可维护性，哪种方法更有效？有没有更好的方法来做到这一点，或者是否有任何最佳实践？

谢谢

我们正在创建一个大项目，该项目将持续大约 10 年并得到改进。

在我们的代码库中，已经有很多针对特定浏览器不兼容的代码、针对浏览器中不同错误的解决方法、第 3 方工具和库等等。代码本身通常运行良好，但随着时间的推移，它会变得更难调试、阅读和重构。

是否有一些标准方法来管理问题并在不需要时删除代码？

我想到的想法：

1. 手动维护带有问题链接的解决方法表 -> 说明如何删除它们。可能带有一些元数据。
2. 在以下情况下，设置一项将在公司问题跟踪系统中创建低优先级条目的任务：
   • Github 问题页面上的状态更改。
   • 浏览器使用率降至阈值以下（以识别不再需要的变通方法）。
   • 代码覆盖检测到不再访问“if 分支”。
   • 很长一段时间没有重新讨论这个问题。

假设有一个 C++ 应用程序在 Oracle 数据库上执行特定的 SQL 查询。

该查询在过去几年在客户环境中的生产环境中运行良好，但突然有一天，查询开始花费大约 10 倍的时间来执行。（假设在此查询工作的表中不断添加数据）。

在进行分析时，专家发现Oracle 的优化器没有生成最佳计划，原因可能与数据库统计/数据倾斜/所有其他可能影响优化器生成次优计划的参数有关。

通过在查询中放置提示来强制优化器生成一个好的执行计划非常有效。

应用程序开发团队现在被迫更改应用程序代码并在构建查询时将提示注入查询中。

应用程序开发团队不想更改应用程序代码，因为他们有数百名其他客户没有抱怨这种特定的查询性能。更改应用程序代码也意味着更多的维护成本，因为他们需要适当的机制来禁用提示，当客户将数据库升级到新版本时不再需要提示。

有问题的客户不愿意聘请可以执行 SQL 命令以使用计划基线功能调整查询的 DBA。

在这种情况下，应用程序开发团队有哪些选择？

简短的问题。

从 DDD 的角度来看（或者只是可维护的架构和常识），我应该在哪里放置一个没有域对象可操作但进行一些“智能”数据准备和编排一堆副作用调用的业务逻辑层？我所说的“智能”是指它有一些规则和操作的顺序限制，而不仅仅是构建 DTO。在每个调用方法之前进行数据准备的幼稚实现看起来很混乱，并且随着逻辑变得更加复杂，情况变得更糟。此外，如果不“模拟整个宇宙”，这种实现是不可测试的。

一个长而具体的例子。

我有一个与 Order API 通信的订单 Web 应用程序。My Web App 有一个在订单抛出 API 中更新订单位置的操作。从前端获取数据并保存的实现方法包括三个阶段：

1. 删除现有职位
2. 添加新职位
3. 重新申请折扣

这是 Order API 的一个奇怪实现，我无法控制它。代码看起来像这样

正如我所看到的，这段代码 a) 无法通过单元测试进行测试，b) 一些重要的逻辑位于 dto builder 中，c) 随着新规则的出现或 API 的更改，它只会变得更加混乱。（也许我错了，没关系）

我的想法

所以在这里我看不到任何域模型对象可以用来使代码更具可测试性和可扩展性。

1. 第一个想法 - 构建订单对象并执行类似的操作

但是创建整个 Order 对象是一项昂贵的操作，并且 ViewModel 以外的数据实际上对于 Save 操作并不是必需的

2. （愚蠢的一）实现位置域模型。

好的部分是一些业务逻辑与应用层解耦并且是可测试的。但是位置模型（因为它在构造后具有不相关的状态）或其 Save 方法也没有现实意义，因为位置不会自我保存。照我看来

3. 创建域服务。看起来像我需要的东西 - 包含不属于任何实体的操作的东西。但是也有人说域服务应该在几个聚合上运行，我一个都没有。另外，在这种情况下，这种服务的方法应该返回什么？在 API 调用中使用的一堆事件或类似 DTO 元组的东西？

所以实际上我正在努力将代码从程序方式转移到面向对象和 DDD 方式，因为我的域中没有对象负责所需的操作。（或者我只是没有看到）