问题标签 [sdlc]

这不是一个有准确答案的问题（严格来说，最好通过民意调查来获得答案，但该功能不可用），但我真的对答案很感兴趣，所以无论如何我都会问它。

在您的职业生涯中，与棕地相比，您在绿地开发上花费了多少时间？

在过去的 10 年里，我估计我在绿地上花费了 20%，在棕地上花费了 80%。这是典型的吗？

在我们当前的数据库开发环境中，我们已经自动构建过程从 svn create database 脚本中检查所有 sql 代码，并将它们应用于各种开发/qa 数据库。

这一切都很好，与我们过去所做的相比有了很大的改进，但我们在重新运行脚本时遇到了问题。显然，对于某些脚本（例如更改过程）来说，这不是问题，因为您可以一遍又一遍地运行它们而不会对系统造成不利影响。现在要添加元数据并运行诸如创建/更改表语句之类的语句，我们添加代码来检查对象是否存在，如果存在，则不要运行它们。

我们的问题是我们真的只有一次运行脚本，因为一旦脚本运行，对象就在环境中，系统不会再次运行脚本。如果在部署后需要更改某些内容，我们会遇到一个困难的过程，即针对更新脚本运行更新脚本并希望一切都按正确的顺序排列，并且所有 PK 在环境之间排列（我们应该说数据库是， “特别的”）。

没有删除数据库并从头开始流程（最新的最新版本），有没有人对此有更优雅的解决方案？

我的问题是，哪种版本命名方案应该用于什么类型的项目。

非常常见的是major.minor.fix，但即使这样也可能导致4 个数字（即Firefox 2.0.0.16）。有些有一个模型，奇数表示开发人员版本，偶数表示稳定版本。各种添加都可以进入组合，如 -dev3、-rc1、SP2 等。

有理由更喜欢一种方案而不是另一种方案，不同类型的项目（即开源与闭源）是否应该有不同的版本命名方案？

它在 Wikipedia 的系统开发生命周期页面上被提及：

为了管理这一点，已经创建了许多系统开发生命周期 (SDLC) 模型：瀑布模型、喷泉模型、螺旋模型、构建和修复模型、快速原型制作、增量模型以及同步和稳定模型。

我在谷歌上找到了一些东西，但我觉得它们很模糊，他们只是没有点击我。也许这里有人的解释可能更清楚。

您是否有任何方法/系统来激励您的开发团队成员编写“好”代码并向他们的代码添加注释？我认识到“好”是一个主观术语，它与一个较早的问题有关，即衡量代码的可维护性作为衡量好代码的一种方法。

以及如何使它们在测试和生产环境之间保持同步？

当谈到数据库表的索引时，我的理念是它们是编写任何查询数据库的代码的一个组成部分。如果不分析对索引的影响，就无法引入新查询或更改查询。

所以我尽我最大的努力让我的索引在我所有的环境之间保持同步，但老实说，我在自动化这方面做得不是很好。这是一种随意的手动过程。

我会定期查看索引统计数据并删除不必要的索引。我通常通过创建一个删除脚本来执行此操作，然后将其复制回其他环境。

但是这里和那里的索引是在正常过程之外创建和删除的，很难看出差异在哪里。

我发现真正有用的一件事是使用简单的数字索引名称，例如

其中 t 是表格的缩写。当我试图对所有涉及的列变得聪明时，我发现索引维护是不可能的，比如，

区分这样的索引太难了。

有人有将索引维护集成到源代码控制和开发生命周期中的真正好方法吗？

我相信敏捷不过是螺旋模型的另一种实现。我是 Spiral 的大力支持者（螺旋模型是一个软件开发过程，结合了设计和原型设计阶段的元素，努力结合自上而下和自下而上概念的优势），并且已经看到许多项目在不知道它们在螺旋世界中运行的情况下实施螺旋。从敏捷开始流行的那一天起，螺旋的概念就开始被忽视了。我确信对于复杂的项目螺旋仍然是最好的选择，但我想更好地了解敏捷和螺旋技术之间的异同。谁能解释他们的差异/相似之处？

我遇到过“维持软件工程”这个短语，但不知道它的确切含义。似乎有一些国防部联系？它与敏捷开发有关吗？

不久前，另一个问题提到了（可能是城市故事）统计数据，

... 软件的平均寿命约为 3 年

当时我想出了以下原因（我相信还有更多可能更好的原因）：

1. 实施了一个新的主要系统（ERP、CRM 等），它有一个“集成”模块来取代旧的应用程序。

2. 相同，但没有集成应用程序 - 但现有应用程序无法适应（人员离开、技术发生变化、当前 IT 政策发生变化、用户不喜欢现有应用程序。）

3. 您从那里获得基本应用程序以根据您的需要对其进行定制的公司已经消失了。

4. 或者你不再和他们相处得很好。

5. 现有应用程序的技术是“过时的”（根据框架供应商/微软/顾问/行业专家/新 IT 经理的说法，他们有管理层的耳朵。）

6. “我们正在逐步淘汰（Windows 95/Windows 98/Windows 2000/Windows XP/NT），我们需要在我们的应用程序中使用匹配技术”。

7. “我们从（App 版本 n）中学到了很多东西，我们会在第二次/第三次/第四次/n+1 次时做得更好。”

8. 开发人员/IT经理/部门副总裁/咨询公司的工作理由。

9. 用户讨厌它。

10. 我们已经合并/收购了竞争对手/被竞争对手收购，而他们的更好。

其中一些是不可避免的（例如，您的公司被收购），但总的来说，这肯定是需要避免的事情。您的组织是否有意对抗这种综合症？你会推荐什么有效的策略？

我想知道您当前的团队在报告和组织结构图方面的结构。如果有人能提供贵组织中使用的各种角色的名称，那就太好了。

我想我完全搞砸了这个问题。我还想知道理想的设置是什么，有点像你梦想的组织结构图。