Like any code no matter what language, you should only look at re-writting it because you can make it more efficient or easier to understand.
Based on my experiance I have been able to reduce badly written SQL 4 to 5 times its size and many times its performance because the origonal auther really had no idea.
Is it possible to maintain a 43 page function, say, in C#? The answer is obvious ;). I just cannot imagine this. If I were you I would break it into smaller parts.
If the query is generated by a tool (or by code), then it may be relatively simple to maintain (in the sense that the query generation code may in fact be well written and maintainable)
I ran into a problem similar to this recently and I came to a decision by considering a couple of things:
How long is this going to take to maintain vs. rewrite?
How critical is this? There may be a lot of logic that may be difficult to unravel and the value in the fact that "it works" exceeds the value from an immediate rewrite.
And of course, there was the political decision management had to make concerning risking explaining why something that was recently created would have to be rewritten.
In the end (for me), find + replace was my friend.
发布评论
评论（8）
如果它包含嵌套分配，我会说不。
就像任何代码一样，无论哪种语言，您都应该只考虑重写它，因为这样可以使其更高效或更容易理解。
根据我的经验，我已经能够将写得不好的 SQL 的大小减少 4 到 5 倍，并将性能减少很多倍，因为原作者确实不知道。
If it contains allot of nesting I would say no.
Like any code no matter what language, you should only look at re-writting it because you can make it more efficient or easier to understand.
Based on my experiance I have been able to reduce badly written SQL 4 to 5 times its size and many times its performance because the origonal auther really had no idea.
如果您认为这很糟糕，您应该观看 Industrial Logic 关于代码异味的示例视频：技术债务。 绝对不是自动生成的。
If you think that's bad, you should see Industrial Logic's sample video on code smells: Technical Debt. Definitely not autogenerated.
是否可以用 C# 来维护 43 页的函数？ 答案是显而易见的；）。 我简直无法想象这一点。 如果我是你，我会把它分成更小的部分。
Is it possible to maintain a 43 page function, say, in C#? The answer is obvious ;). I just cannot imagine this. If I were you I would break it into smaller parts.
有两件事：
如果您有一个 43 页的查询，并且对前两个问题的回答是“是”，欢迎使用 SharePoint 开发
Two things:
If you have a 43 page query and you answered yes to the first two questions, welcome to SharePoint development
显然，您从未见过来自 Sharepoint DAL 的 SQL。
Clearly, you've never seen the SQL that comes out of the Sharepoint DAL.
如果查询是由工具（或代码）生成的，那么维护起来可能相对简单（从某种意义上说，查询生成代码实际上可能写得很好并且可维护）
If the query is generated by a tool (or by code), then it may be relatively simple to maintain (in the sense that the query generation code may in fact be well written and maintainable)
我最近遇到了与此类似的问题，我通过考虑以下几件事做出了决定：
当然，管理层必须做出政治决策，以冒险解释为什么最近创建的东西必须被重写。
最后（对我来说），查找+替换是我的朋友。
I ran into a problem similar to this recently and I came to a decision by considering a couple of things:
And of course, there was the political decision management had to make concerning risking explaining why something that was recently created would have to be rewritten.
In the end (for me), find + replace was my friend.
使用 重构它WITH 语句。
添加很多很多很多评论。
如果你把它分解成可以管理的部分，你就有更好的机会。
Refactor it using the WITH statement.
Add lots and lots and lots of comments.
If you break it into pieces that can be managed, you stand a much better chance.