Plsql PL/SQL包的模块化

目前，我正在我们公司进行一个重组项目，主要针对Oracle PL/SQL包。它涉及到我们公司的许多核心软件包。到目前为止，我们还没有完成后端工作的文档，该项目的目的是以结构化的方式基于当前逻辑创建一组新的API，同时避免系统中当前存在的所有不需要的逻辑

我们目前还在为组织的主要业务制作一个新模块，该模块将基于这些新创建的后端API工作

当我开始这个项目时，我发现大多数包装器API大约有8000多行代码。我设法将这段代码转换成许多单个API，并从包装器API调用它们

这个活动本身就是一个耗时的过程，但我能够通过为每个业务功能调用独立的API，将包装器API中的代码行数减少到900行

我想从各位专家那里了解一下，这种模块化代码的模式是否好，是否值得为此投入时间，因为我不确定它是否会带来许多性能优势。 但从代码可读性的角度来看，这无疑是有帮助的，现在我能够更好地理解重组后的8000行代码，我相信我组织中的其他开发人员也会理解

请你让我知道我是否做了正确的事情，如果它有它的优点，除了可读性，请务必提及它们。对不起，解释得太长了。 在一个包装器API中有超过1000行代码可以吗。

• 易于调试
• 易于更新
• 易于修改/维护
• 由于耦合度低，变更倾向性较小
• 如果模块是通用的，则增加重用
• 可以轻松识别未使用的代码

---

您所说的“包装器API”到底是什么意思。一个包，一个包体，一个包中的单个过程？嗨，大卫，很抱歉我没有提到。这是一个程序包中的一个程序。非常感谢真实的精神。我100%同意这些观点，因为现在我清楚地知道，当我开始在这个程序中工作时，这些观点是缺失的。由于我已将其划分为许多独立的api，我希望以上几点对未来的开发和维护有用。@njnbat如果您对答案感到满意，您可以投票和/或接受答案，这将更加礼貌，但没有声誉，因此，很抱歉不礼貌。