Given that you can do RefactoringInVbClassic, is it practical/desirable/appropriate/beneficial/... to practice ExtremeProgramming in VbClassic?
(Technical comments on how to do RefactoringInVisualBasic moved to that page. And suggestions on how to do VbClassicImplementationInheritance moved to that page.)
This is a vitally serious subject for the future of programming. The Professionals
meets Mission Impossible
Class Modules and Properties in VB5 and beyond (for all the Office 97 tools and standalone VB5 and 6) give you encapsulation, multiple instantiation of objects with proper object identity and a useful object browser. It's true that there is no class inheritance (implementation inheritance).
Now VB sure ain't uniform like Smalltalk - but the great news is that it's less strongly typed than Java - I trust that really encourages many of the people around here. ;-)
most definitely can and must be done in VB. But we find the lack of uniformity and internal simplicity in VB makes it far more difficult for many of us to conceive the most simple thing
. This is a vital cognitive issue to have a grasp of, not just for future language and tool designers but for current
Familiarity with any language and environment does I believe matter a lot for DoTheSimplestThingThatCouldPossiblyWork
to lead to dramatic C3 type results. What does the panel think on that ?
Familiarity with VBA and VB is a much longer and tougher road to travel. Yet the rapid feedback factor with VBA in Excel, say, can still be used to great advantage once the team knows its way around.
Can you maintain a relatively flat cost to make changes over time in VbClassic
? If so, the XP's DeferredDesignStrategy?
will work. Can someone who has lived with a VB app in production tell us if this seems plausible?
I think there is no difference here between Visual Basic and any other language. If you refactor your code to make any action occur in as few places (classes, functions, or even macros) as possible, it is not a big deal to change functionality and therefore the design. I have really loved my own unit tests in this respect. I can copy whole pieces of functionality (mostly classes, but single functions and subs as well) to a new application and immediately see if it works. This way, programming becomes more "assembling pieces together" instead of "building everything from scratch". In fact, you library of functions and classes grows along with your needs. -- WillemBogaerts
Imagine for a moment that XP became the standard way of writing business software, and that, therefore, Microsoft wanted VB to become the standard tool for XP. What would Microsoft have to change about VB, if anything?
It would be fairly easy to develop a refactoring browser for VB, altho it might be considerably weaker than the Smalltalk one. Also something like the KentBeck testing framework, altho the one that Rational sells might do the trick. One difficulty might be following the OnceAndOnlyOnce rule without implementation inheritance [VbDotNet has this]. Interfaces-only can give a decent object model, but seems to lead to a lot of cutting-and-pasting.
For those interested the VbUnit TestingFramework
is available. -BradTaylor
Detailed feedback should be available on a VBA5 development in around 3-4 months from around these parts. Would be very interested in others' views.
I believe that it should not take very long for XP to become a key influence on the standard way of writing business software
. Big M might not be so slow to respond to this, given the trends outlined in books like CodeComplete
, and VB is indeed their development flagship, at least while a clean-room Java and JVM is still blocked by the courts. But it's certainly possible to be wrong on the timing of perfectly rational trends. -- RichardDrake
Although I don't have much experience with Visual Basic, everything I know
about it says that it will be better suited for ExtremeProgramming
C++. Even the culture is better suited for it, because VB tends to be used
in places where there is little upfront design, where requirements change
all the time, and where documentation is not perceived as important. The
problem with VB programmers is that they never refactor and they do not write
unit tests. And they don't program in pairs, play the planning game, etc.
But I bet the hardest part is getting them to refactor.
Anyway, you don't need a tool to refactor. I've done heavy refactoring in C++,
and was refactoring Smalltalk programs for half-a-dozen years before having a
refactoring browser. The main requirement for refactoring is a nose (to detect
s) and a mind. A specialized browser is very useful, but not essential. --RalphJohnson
When using VBA in an environment like Excel, ExtremeProgramming
with Visual Basic is very practical. Worksheets used as primitive interfaces allow the coder to focus on core logic at the outset. UserForms?
can be built later, or forms can be imbedded in the worksheets themselves. Using the macro record button can generate marginal but correctly functioning code that can go through an immediate first pass refactoring before being pressed into use. Useful sets of refactored code can be exported as modules and brought back into other projects. Procedural code modules (procedure sets) can be refactored into classes. Implementation inheritance can be worked around by limited refactoring of single class modules in a class hierarchy.
Working with accountants tied to an external reporting driven closing cycle almost demands ExtremeProgramming
techniques. First version can speed up the closing cycle, while later version either speed it up even more or improve the efficiency or maintainability of the code. When the programmer decides to RefactorMercilessly
, non-programmers can maintain portions of the code where magic numbers (spreadsheet coordinate references) are involved.
VbeXtremeTeam in 2004
This is a group of people making a good stab at ExtremeProgramming
, using VbLiteUnit
as a UnitTest
Question about "When to clone a method" moved to CloneMethod
One thing VbClassic
did pretty well was to support changing code while it's running and then continue running.
This is something the SmalltalkLanguage
environment supplied, and it's quite helpful in TestDrivenDevelopment
This feature got kind of a bad reputation in VbClassic
because if you use it very heavily in a single run (typically lasting several hours), VisualBasic
would sometimes crash, causing you to lose ALL the source code changes you had made during the session.
That is, yes you could change the code and continue, but you could not
save any of these changes to disk until VB successfully terminated the process.
And when VB crashed, well of course all the VB windows holding your changed source code were lost.
This led to TurretsSyndrome?
-like experiences on many a (non-TDD) VbClassic