20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting
As
we mentioned in our previous discussion of software quality, maintainability of
a program or maintainability of code is one of the six key measures of software
quality. It is also the area where the Magic xpa Application Platform
absolutely shines over alternative means of software development and deployment
such as C#, ASP and Java.
Maintainability of C#.NET code is such a common and ongoing problem for developers that
Microsoft, although unable to control bad coding practices, created a
maintainability index that tells you just how bad your code is. If you are
considering migration of Magic eDeveloper, uniPaaS or Magic xpa to C#.NET
instead of upgrading to .NET directly with Magic xpa, then you shouldn’t ignore
the problems of maintainability in C# versus Magic xpa. Here’s why:
C#
software projects are commonly derailed by bad engineering decisions that make
the code un-maintainable. These bad decisions often fall into one of two
categories: over-engineering or under-engineering.
Under-engineering results in spaghetti code. This is particularly common with code conversion
projects. The code conversion creates a giant meatball of code. Thick,
impenetrable and impossible to understand. Those charged with maintaining that
code by manually programming in C# start by adding a string of spaghetti here,
a string of spaghetti there. Pretty soon you have a giant wad of overcooked,
undercooked and raw spaghetti smothering your poor meatball. There was no plan,
no experience and no recipe for code maintenance. The situation gets worse when
a renegade hacker is called in to rescue the code. But all they can do is add
more spaghetti of their own and the code gets worse and worse.
With
Magic xpa, the platform itself provides the needed “applistructure” for an
easily maintained application. Magic xpa applications are more like a finely
layered lasagna, well thought out, uniformly structured and therefore highly
maintainable.
Over-engineering
results in bloated code. A great many C# developers, including those who create
code-generators, are overly enamored with patterns. Since they have no
application platform to work with, they are forced to create application design
patterns and it is extremely common to go overboard with these code snippets.
Developers who inherit migrated code are also highly likely to overcompensate
and be pattern-happy. It is almost impossible to see it in the early stages of
code maintenance. The over-engineering
of converted code is problematic however, because it causes incremental amounts of overhead code to be added for each
new change or piece of functionality implemented. Over-engineering will crop up
when trying to cope with new operating system and database changes as well. Over
time, these chunks of overhead snowball and negatively impact maintenance costs,
lag schedules and ultimately cause projects to be abandoned and fail.
The Magic xpa Application Platform provides the applistructure
that allows you to focus on business logic. Maintaining code is never a matter
of over or under engineering but instead a focused activity of measurable
improvements.
The vulnerabilities of C# are also found in the area of code
redundancy. Whereas Magic xpa leverages a platform, C# programmers have to
create their own application architecture from scratch. The .NET framework is
not an application architecture, that’s why the word framework was carefully
selected because it is neither platform nor architecture. While every developer
knows the DRY principle: Don’t Repeat Yourself. The problem with a code
generator is that it is impossible for the developer to know when they are
repeating code that was generated elsewhere. The converted Magic applications
become so bloated and complex when deconstructed into C# code that the code to
be maintained ends up having massively repetitive aspects. While efforts will
be made and assurances given, it is just impossible to avoid code bloating by
duplication of nearly-matched patterns.
Since the code generator won’t see the repeatability within
complex patterns, it will simply engage in wholesale duplication of code. The
code is not DRY conformant and therefore nearly impossible to maintain over
time.
Magic xpa’s repository-based development approach enhances
project organization. Rather than dealing with mountains of text, you work in well-organized
Magic xpa repositories. C# on the other hand allows for wreckless programming.
Poorly organized code can lead to the introduction of dumb bugs and will result
in slipped schedules or worse.The superior organization of a Magic xpa
application means that it is easier to on-board a new Magic xpa programmer from
scratch than it is to orient even an experienced C# programmer to
code-generated projects.
No comments:
Post a Comment