One of the things I see software developers often talking about is how they refactor code. As they touch a class, method, etc., they may take the time to refactor the code to make it cleaner, perform better, or just add some documentation. It seems that a regular part of a software developer's job is refactoring code in the codebase.

That is unless they see a "don't touch this, no idea how it works" comment. There are plenty of those, and often everyone leaves that code alone.

I was thinking about this when I saw this article on strategies to refactor sql code. The article seems written more for PostgreSQL, but there are items that relate to T-SQL as well. The main thrust of the article is about trying to rewrite code to DRY (don't repeat yourself). The more changes you can make to shrink code, either to make it easier to read or avoid repeating those copy/paste items, the better off your team will be. It's easy to think those copies aren't a big deal, but it's easy to update code in one place because that solves the problem you were given, and forget to fix all the copies.

I don't know that anyone should implement all the techniques listed, but they are things to think about. Using CTEs, Views, APPLY, the WINDOW clause, and more can help improve the health of your codebase and make it easier for all the members of your team to understand how the system works.

I wonder how many of you have a refactor mentality when you touch code, or do you tend to leave things alone and add new queries/objects/etc. to your database. I wonder if the fear of breaking something that might be used by other code is on your mind. Or maybe you suffer from "not invented here" (NIH) and just add your own code.

If you refactor code, then what things do you look to change or improve? Any tips/tricks/guidelines you'd share with others? If you don't refactor code, why not?

I think testing is a big part of refactoring. If you have tests, then you can be less worried about your changes breaking something. There is a great video on practical refactoring. It's from the software engineering view, and it's long, but it's worth a watch if you have a few moments.

I wish more people tested their SQL code and refactored poorly written (or poorly performing) code on a regular basis.