posted on Wednesday, January 21, 2004 8:45 PM
by
stefandemetz
Visual Studio.NET and code serviceability
In the inifinite diatribes pro and against our favorite
visual IDE I have to sit on the fence.
While VS.NET is very good at helping beginners at entering
in the environment it gets a bite leightweight when
starting to maintain big codebases(100 KLOC +).
That is also a disadvantage for MS push for the enterprise market.
As a modest project evolves during its lifetime and adds pieces
it becomes more difficult to re-engineer (refactor) a codebase
or modify an existing architecture. Granted, the design should be done
at the beginning, but in the real world, feature requests will arrive
and we developers want to make our users happy.
Therefore an evolved project, maybe passed though various project leaders
or developers, will bloat to no end.
The maintainance gets more expensive and the codebase loses its vitality and zest.
As for MS, detractors will happily declare that .NET does not scale,
costs to much to keep alive and other bad stuff we don't want to hear.
And just because the project initiator hired cheap developers who could only make
the datagrid pretty - and fast.
With ISV still a bit weak on .NET refactoring VS Whidbey is the first version with a
few basic items of refactoring, but needs to do lots more for code serviceability,
especially if MS is serious of getting the upperhand in enterprise development.
What do you think needs to be done for .NET code serviceability?