![]() It is important because as code becomes less maintainable the cost to maintain the code increases. (One was classic ASP, the other ASP.NET). Code maintainability is a fundamental part of good software development. I have successfully used this technique on a couple dozen projects including two websites each with hundreds of pages. ![]() You may want a handful of tests for the tricky bits, but you don’t want a bunch of low-level tests that are just going to be broken anyways. Keep a definitive version of the procedure, so if you need to make changes or add more functionality, you will only need to do so in one place. ![]() Since we are talking about fundamentally rearchitecting the application, writing a bunch of tests before this point is a waste of time. Eliminating code clones makes it easier to maintain or change your code. Step 4 (optional): Write automated tests. Enter these as normal tickets in whatever bug tracking software you use. Step 3: Now that you you've literally touched every function at least once go back and make a list of things that you think need to be changed. (For larger projects I assign my developers to do this one folder/namespace at a time.) Without changing what it does, make it look like something you would have written. Step 2: Pick a function, any function, and clean it up. Static analysis tools such as FXCop help a lot here. Prune out any class, function, or variable that isn't being used. "So no new features or benefits that we can sell? Then no." ![]() "A better product that is easier to extend and maintain for the developers." That conversation usually goes like this: The sad thing is, almost no one does this, and it's damn near impossible to justify a redesign to business people. If you're just writing code without a good framework in mind of how to lay out the various parts of your system, you are probably setting yourself up for a maintainability nightmare. I usually recommend DDD as a good framework for that. This is why designing things right in the first place is important. I find that most of the times "refactoring" is near impossible until it's redesigned. For instance, when the program is written in true spaghetti code fashion, it's usually damn near impossible to really refactor without rewriting and redesigning a good portion of the system, and that is not a small feat especially when you have a larger team working on it at the same time. ![]() The problem with refactoring is that it is only an "easy" process when the program is designed right in the first place. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |