||Risk of Introducing bugs
|Poor syntaxChanges to the code to clarify it and improve readability.
||An example of this would be taking a bunch of If statements and recoding as a case statement.
||Badly written code can take much longer to understand than necessary and is frustrating to live with.
||SmallThe key issue is whether the code (badly written or not) is understood. The chances of a bug being introduced can be minimized by having two people read the code that has been changed.
||This level of refactoring should always happen whenever the code in question is being modified anyway.|
|Changing an algorithmSometimes we discover that there is a simpler and clearer solution to the problem.
||Some common occurrences; a solution that uses procedural logic (i.e. processing one record at a time) instead of using a set-oriented approach. Another example is taking logic branches (i.e. if step =5 next step = N) and driving it via a table.
||DependsThe new method will need testing, the extent of which depends on the level of complexity.
||This is a more extensive re-factoring and can produce much simpler and cleaner code.
||MediumWe need to prove that we have identified the correct way of solving the problem.
||Emphasis should be on a simpler algorithm, not a faster one, unless performance is an issue. Weigh this possibility along with others that suggest themselves on the project.|
|Modularizing codeOften enough, the code is written as one chunk and could be broken down into smaller and more manageable sections.
||I've seen stored procedures that are well over five hundred lines. That's a lot of code to take on in one piece.
||Moderatewe are not necessarily re-writing the code, simply breaking it up into separate procedures or functions.
||Small pieces of code are much easier to modify and work with. The level of effort required supporting drops dramatically with well modularized code.
||ModerateWe are reshaping the code, but we are not necessarily rewriting it.
||Walk through the proposed restructuring before attempting it. Balance this opportunity with others on the project.|
|Modifying schemaAs the business changes, we realize a way of modeling the data that better reflects the current business.
||This can be as simple as renaming some fields to better reflect their use to adding or dropping whole tables and or modifying the relationships between tables.
||ModerateCan be higher if a significant data conversion is needed.
||A bad data model can lead to garbage data. It also significantly increases the cost of maintenance.
||Moderate to highdepending on the amount being changed and the data conversion required.
||Because of the risks associated with anything more than a trivial change to the schema, this needs to be well thought out and is typically only justified when the business has changed enough that the schema must change.|