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. ;-)
RefactorMercilessly 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 for
DoTheSimplestThingThatCouldPossiblyWork. This is a vital cognitive issue to have a grasp of, not just for future language and tool designers but for
current XP coaches.
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.
--
RichardDrake
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 than
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
CodeSmells) 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.
--
ScottHamilton
more:
http://www.programmersheaven.com/zone22/articles/article289.htm
VbeXtremeTeam in 2004
This is a group of people making a good stab at
ExtremeProgramming in
VbClassic and
VisualBasicForApplications, using
VbLiteUnit as a
UnitTesting tool.
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 project! ;->
--
JeffGrigg
CategoryVbClassic