Best resources to help improve/maintain old code
August 24, 2015 7:49 PM Subscribe
What are some resources (books preferred, but other resources are good, too) that I can use to help me improve/maintain some old vba models in my workplace.
At my workplace, we have a vba model that has been built over the past 15 years. The people who worked on the model were mostly students that had varying degrees of familiarity with vba, and the result is that much of the code looks like it could be improved (for example, a lot of the code is repeated and could be separated into it's own module, other parts of the code look like they are directly from the macro recorder, etc.). I'm fairly confident in my vba skills and I'd like to clean up the code as best I can. I'm wondering if anyone can recommend books/resources that deal with maintaining/improving legacy code and the best way to approach this? (I saw another thread where someone recommended http://www.refactoring.com/ , but it looks like that book doesn't really deal with vba and I'm wondering if there are more recent resources available)
At my workplace, we have a vba model that has been built over the past 15 years. The people who worked on the model were mostly students that had varying degrees of familiarity with vba, and the result is that much of the code looks like it could be improved (for example, a lot of the code is repeated and could be separated into it's own module, other parts of the code look like they are directly from the macro recorder, etc.). I'm fairly confident in my vba skills and I'd like to clean up the code as best I can. I'm wondering if anyone can recommend books/resources that deal with maintaining/improving legacy code and the best way to approach this? (I saw another thread where someone recommended http://www.refactoring.com/ , but it looks like that book doesn't really deal with vba and I'm wondering if there are more recent resources available)
I have heard several people recommend brownfield application development in .net before. Can't say I have read it myself though.
posted by phil at 5:48 AM on August 25, 2015
posted by phil at 5:48 AM on August 25, 2015
not a recommendation so much...The most valuable discussions probably won't be ones addressing VBA specifically. Rather, they'll discuss an approach.
Let me first say VB6/VBA language elements support OOD via Class and Interface. I advise you to do an 'objects' solution...
A legacy project with a history you describe likely unfolded as The Most Common Design Pattern. Which is maddening to work with.
Do you know of design patterns? An architect named Christopher Alexander cultivated the concept of a pattern language:
What should you refactor to patterns? Code smells.
ok...VBA specifically. My experience of legacy VB6 and VBA is: The languages (though flawed*) are not the problem. The code authoring is. The VB family is soooo hyper-accessible, you can do a lot with only a little knowledge. As this snowballs, the inexperience of the developers quickly shows up in catastrophic ways: huge (100s of LOC) procedures. Ugh. Modules (or classes) with too much responsibility.
Find some smells - fix 'em. One kind of arbitrary sounding fix is to reduce the size of everything. But - like a meditation practice - it pays great dividends after doing it a lot and making your own observations. So - short procedure. Give yourself a maximum of 50 lines, and just assume that if the urge is to go over fifty, there is something in there you can split out. Classes with no more than, say, five methods. Same idea.
Over time, this moves you toward a deep knowing of The Single Responsibility Principle. This is your gateway into effective refactoring, and eventually, loose coupling.
* VB/VBA does not have inheritance, but there is a lot to be done with composition and interfaces (via law of demeter).
posted by j_curiouser at 10:00 AM on August 25, 2015 [1 favorite]
Let me first say VB6/VBA language elements support OOD via Class and Interface. I advise you to do an 'objects' solution...
A legacy project with a history you describe likely unfolded as The Most Common Design Pattern. Which is maddening to work with.
Do you know of design patterns? An architect named Christopher Alexander cultivated the concept of a pattern language:
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher AlexanderSoftware design patterns were first well-described in this book, which is fairly dense. Anecdotes by software developers indicate that they really only 'get' design patterns after significant experience. So you need something that will demonstrate specific applications of patterns. This book uses Java as examples, but is not a 'Java' book. Its a patterns book.
What should you refactor to patterns? Code smells.
ok...VBA specifically. My experience of legacy VB6 and VBA is: The languages (though flawed*) are not the problem. The code authoring is. The VB family is soooo hyper-accessible, you can do a lot with only a little knowledge. As this snowballs, the inexperience of the developers quickly shows up in catastrophic ways: huge (100s of LOC) procedures. Ugh. Modules (or classes) with too much responsibility.
Find some smells - fix 'em. One kind of arbitrary sounding fix is to reduce the size of everything. But - like a meditation practice - it pays great dividends after doing it a lot and making your own observations. So - short procedure. Give yourself a maximum of 50 lines, and just assume that if the urge is to go over fifty, there is something in there you can split out. Classes with no more than, say, five methods. Same idea.
Over time, this moves you toward a deep knowing of The Single Responsibility Principle. This is your gateway into effective refactoring, and eventually, loose coupling.
* VB/VBA does not have inheritance, but there is a lot to be done with composition and interfaces (via law of demeter).
posted by j_curiouser at 10:00 AM on August 25, 2015 [1 favorite]
practical guidance:
this book will show you how to OOD in VB6. You can write COM dlls in VB6 for all your business logic, then reference that in the VBA (if you must).
you can also write COM dlls in VB.Net or C# and reference those from VBA.
fwiw
posted by j_curiouser at 10:34 AM on August 25, 2015
this book will show you how to OOD in VB6. You can write COM dlls in VB6 for all your business logic, then reference that in the VBA (if you must).
you can also write COM dlls in VB.Net or C# and reference those from VBA.
fwiw
posted by j_curiouser at 10:34 AM on August 25, 2015
This thread is closed to new comments.
posted by miyabo at 7:59 PM on August 24, 2015 [5 favorites]