查找遗留应用程序中的冗余页面、文件、存储过程
我对旧的 ASP Web 应用程序有一些恐惧。有没有人有任何简单的方法来查找不再需要的脚本、页面和存储过程？ （除了“old___code”、“delete_this”等中的内容；-）
I have several horrors of old ASP web applications. Does anyone have any easy ways to find what scripts, pages, and stored procedures are no longer needed? (besides the stuff in "old___code", "delete_this", etc ;-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果存储过程无法运行，则很可能不会使用它，因为当其他内容发生更改时，没有人愿意更新它。对于每条记录都为空的表列可能没有被使用。
如果您的 sp 和数据库对象位于源代码管理中（如果没有，为什么不呢？），您也许能够找到并找到将其移至生产环境的其他代码，这应该给您提供线索至于什么可以称之为。您还可以看到谁最后触摸了它，并且该人可能知道是否仍然需要它。
我通常会首先列出所有进程（您可以从系统表中获取），然后将我知道正在使用的进程标记为从列表中删除。 Profiler 可以在这里为您提供帮助，因为您可以看到哪些内容经常被调用。 （但不要假设因为探查器没有显示未使用的过程，这只是为您提供了要研究的列表。）这使得需要重新整理的列表要小得多。根据您的命名约定，可能相对容易看出代码的哪一部分应该使用它们。研究时不要忘记过程是在应用程序以外的地方调用的，因此您需要检查作业、DTS 或 SSIS 包、SSRS 报告、其他应用程序、触发器等，以确保某些内容没有被使用。
一旦您确定了您认为不需要的进程列表，请将其与其他开发人员共享，并询问是否有人知道是否需要该进程。您可能会通过这种方式从列表中删除更多一些用于专门的东西。然后，当您获得列表后，将名称更改为某种约定，以便您可以将它们标识为要删除的候选者。同时设置一个删除日期（该日期有多远取决于调用某项内容的频率，如果它被称为“AnnualXYZReport”之类的内容，则将该日期设置为一年后）。如果在删除日期之前没有人抱怨，请删除该过程（当然，如果它位于源代码管理中，那么您仍然可以将其恢复）。
一旦你经历了识别坏进程的痛苦，那么是时候意识到你需要培训人们，开发过程的一部分是识别不再使用的进程并作为更改的一部分摆脱它们到一段代码。根据代码重用，这可能意味着搜索代码库以查看代码库的其他部分是否使用它，然后执行与上面讨论的相同的操作，让每个人都知道它将在该日期被删除，更改名称，以便任何引用它的代码将会中断，然后在删除日期删除它。或者，也许您可以拥有一个元数据表，在您知道自己已停止使用某些东西时，您可以在其中放置要删除的候选对象，并每月左右向每个人发送一次报告，以确定其他人是否需要它。
我想不出任何简单的方法来做到这一点，这只是确定哪些内容可能不会被使用并艰难地完成的问题。
Chances are if the stored proc won't run, it isn't being used because nobody ever bothered to update it when sonmething else changed. Table colunms that are null for every single record are probably not being used.
If you have your sp and database objects in source control (and if you don't why don't you?), you might be able to reaach through and find what other code it was moved to production with which should give you a clue as to what might call it. YOu will also be able to see who touched it last and that person might know if it is still needed.
I generally approach this by first listing all the procs (you can get this from the system tables) and then marking the ones I know are being used off the list. Profiler can help you here as you can see which are commonly being called. (But don't assume that because profiler didn't show the proc that it isn't being used, that just gives you a list of the ones to research.) This makes the ones that need to be rearched a much smaller list. Depending on your naming convention it might be relatively easy to see what part of the code should use them. When researching don't forget that procs are called in places other than the application, so you will need to check through jobs, DTS or SSIS packages, SSRS reports, other applications, triggers etc to be sure something is not being used.
Once you have identified a list of ones you don't think you need, share it with the rest of the development staff and ask if anyone knows if the proc is needed. You'll probably get a a couple more taken off the list this way that are used for something specialized. Then when you have the list, change the names to some convention that allows you to identify them as a candidate for deletion. At the same time set a deletion date (how far out that date is depends on how often something might be called, if it is called something like AnnualXYZReport, then make that date a year out). If no one complains by the deletion date, delete the proc (of course if it is in source control you can alawys get it back even then).
Onnce you have gone through the hell of identifying the bad ones, then it is time to realize you need to train people that part of the development process is to identify procs that are no longer being used and get rid of them as part of a change to a section of code. Depending on code reuse, this may mean searching the code base to see if someother part of the code base uses it and then doing the same thing discussed as above, let everyone know it will be deleted on this date, change the name so that any code referncing it will break and then on the date to delete getting rid of it. Or maybe you can have a meta data table where you can put candidates for deletion at the time you know that you have stopped using something and send a report around to everyone once a month or so to determine if anyone else needs it.
I can't think of any easy way to do this, it's just a matter of identifying what might not be used and slogging through.
仅对于 SQL Server，我能想到的 3 个选项：
当然，删除访问权限或删除它并查看谁调用...
For SQL Server only, 3 options that I can think of:
And of course, remove access or delete it and see who calls...