问题标签 [maintenance]

我有几个编程工作。每个有 20-50 名开发人员，项目进行 3-5 年。

每次都是一样的。有些程序员很聪明，有些程序员很普通。每个人都有自己的 CS 学位，每个人都读过设计模式。意图是好的，人们正在努力编写好的代码，但几年后代码还是变成了意大利面条。模块 A 的更改突然破坏了模块 B。代码中总是有这些部分，除了编写它的人之外，没有人能理解。更改基础架构是不可能的，并且向后兼容性问题阻止了良好的功能进入。一半的时间你只想从头开始重写所有内容。

比我更有经验的人认为这是正常的。是吗？它必须是吗？我能做些什么来避免这种情况，或者我应该接受它作为生活的事实吗？

编辑：伙计们，我对这里的回复数量和质量印象深刻。这个网站和它的社区摇滚！

我现在负责一个 Rails 应用程序，该应用程序以非常快速和肮脏的方式构建。它有许多未使用的视图文件（html 模板）。它还有许多未使用的 css 文件。

确定不再需要哪些文件以便删除它们的最佳方法是什么？

我正在寻找一个通用的解决方案，而不是一个特定于 Rails 的解决方案，但是一个 Ruby/Rails-only 的解决方案肯定会受到欢迎。

只是为了让事情开始，我有一个（我不是特别喜欢）确定使用哪些视图的想法如下：

1. 编写一个脚本，将一行代码插入每个视图文件的顶部。这行代码会将视图的名称附加到某种日志中。
2. 递归地 wget 整个站点
3. 浏览日志并删除重复项 - 然后我们有一个使用的视图列表
4. 删除日志中未列出的视图

我不知道，有人告诉我，以前的开发人员在学习并直接进入编码方面做得很好，没有什么大问题。我想知道我是否做错了，我要求我的经理在这里与一些高级程序员进行一些简短的会议。是谨慎地完成这个时间敏感的跟踪器，还是赶在最后期限前完成？

顺便说一句，以前维护这个应用程序的程序员都在公司不到一年就走了。不知道有没有什么关系。

从我的阅读来看，规范模式似乎可以大大减少过滤数据所需的方法数量。您看到使用规范模式有什么好处？您是否注意到了不可预见的好处。相反，你遇到了什么陷阱？

正如我发现的那样，许多开发人员避免进行任何更新（自动或手动），因为他们担心这可能会对他们不了解的机器进行更改，并且他们正在开发的软件可能会在某些时候由于他们不知道的原因而失败.

策略 A.) 尽可能长时间地保持系统不变。

我个人喜欢让我的系统尽可能“最新”（操作系统和应用程序），因为通常我觉得以这种方式工作的麻烦更少。

策略 B.) 始终保持最新

你是什​​么类型的开发者？为什么？

是否有一个实用程序/库可以促进多台服务器之间的任务协调？对我来说，我需要运行计划任务，在服务器之间复制大量数据，并重新启动进程（在集群中不同机器上发生的一系列相关操作）。

我可以使用 cronjobs 和批处理脚本，尽管我不禁想到有一种更强大、更优雅的方式来解决这个问题。

我正在尝试起草一份全面的文档，以协助维护小组建立新的 Sharepoint 2007 Intranet。

我在决定什么是将各种不同元素迁移到客户批准和生产环境的正确工具时遇到的问题。我们预计将来必须处理新列表、新自定义类型/列表模板、修改页面、新页面等。

换句话说，虽然我认为添加整个子站点相对简单，但对现有区域的增量更改对我来说似乎并不容易。特别是因为生产现场有各种由客户更新的列表（公告板等）。

到目前为止，最好的答案似乎是http://www.codeplex.com/SPDeploymentWizard但我有一些遗留问题：

1) 它是测试版，不是微软官方产品。所以我们的客户可能不太有信心 2) 它需要安装在您要交付更改的所有服务器上，并通过 GUI 组件工作。再一次，这将是客户不太满意的事情（他们的东西由第三方管理，想想 EDS 或类似公司）。

有没有人在生产相关场景中有信心使用它？你有不同的选择建议吗？

TIA,

保罗。

假设有一个 C# 程序，它被用作 Windows 服务。让我们假设服务变得疯狂并且疯狂地消耗 CPU 和内存。它需要尽快重新启动，因为它是一个生产系统。所以我没有太多时间来收集运行时信息。也许快速浏览一下任务管理器......就是这样。

之后，我只有 log4net 日志文件和用于事后分析的 Windows 事件日志。

假设我找到了问题的原因。其他人修复了它，也许程序员添加了一些额外的日志记录，这样我下次可以更快地找到类似的问题。尽管如此：我仍然依赖于日志文件的质量，并希望下次出现问题时会以某种方式在日志中显示出来。

还有其他方法可以进行事后分析吗？也许像线程转储（如在 java 中）、内存转储或其他可能有助于事后分析的东西？也许一些内置的 .NET 框架工具可以提供帮助？

我对真实的项目经验以及您将如何尝试解决这个维护问题非常感兴趣，我认为这对大多数程序员来说都是非常真实的。

对于糟糕的问题标题，我感到非常抱歉，但我会尝试更详细地解释一下自己：

我正在为我的软件项目使用 Git（但我猜在这种情况下特定软件并不重要）。与许多项目一样，我计划发布各种版本。当有发布时，我可能会为提交分配一个标签——例如“1.0”。时间流逝，代码被黑，最终发布了一个带有另一个标签的版本——这次是“2.0”。

有一天，我注意到一个严重的错误，它存在于 1.0 和 2.0 版本中，需要修复。为了让事情变得困难（也可能更现实），我不能只在当前的主干/主干中修复它并假设每个人都会使用它，因为 2.0 与 1.0 存在一些向后不兼容，人们很懒惰并且不要不想升级。

那么，为了支持这种行为，有什么好的方案：能够在旧版本中进行更改。git describe由于命令（“ [latest tag]-[commits since the tag]-[current commit hash]”）的输出，Git 似乎在某种程度上将标签等同于发布。那么，我可能无法避免完全使用标签。

我觉得标签和分支的组合是个好主意，但由于某种原因，我无法用这个来解决细节问题。

您是否对正在逐步采用以替换执行相同功能/担任相同角色的旧版本的 API 或类的命名约定？

例如，Windows 通过在函数末尾添加“Ex”来做到这一点：

你更喜欢什么，你的理由是什么？

• 附加2, V2, New, NowInStereo?
• 将旧 API 一次性重命名为SomethingtoSomethingOld并Something用于新的东西？当涉及到版本控制时，这个选项让我很担心，但它似乎也最不可能在未来被一个V3或ReallyNew问题所困扰。
• 组成一个完全不同的名称，可能不太准确地描述功能，但至少是不同的。