×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
My advice:
Always consider yourself a software engineer, not just a coder. Don't
just slap together something that "will work", but make something that
will be easy to maintain over time, including adding new functionality,
tweaking existing functionality, etc.
Don't fall into the trap of doing it the same as before. I see this
happening already, as you started your message with "I have 4 programs,
3 of which have screens". No, no, no! It doesn't matter how many
programs and displays you have right now, not if you're rewriting it!
Instead, think about if there was nothing out there now and I had to do
the same task, what would be the BEST way to design it? Sure, look at
the existing program for ideas... and yes, maybe they did it that way
for a good reason, but... don't think in terms of "anytime I have 4
programs, the new result should be X number of programs/service
programs". Don't copy what exists just because it's there... THINK.
Engineer the best solution.
Think about:
1. anything that that's a "utility" that makes sense to re-use across
multiple programs. That should be obvious that it should be a
subprocedure in a service program (I hope?)
2. anything that should can be tested independently of the larger
program. This is really important to having a robust application.
Anything complex should be callable independently of the whole
application so that it can be tested by itself.
3. keep UI logic separate from business logic. Each UI should be a
separate service program or at least module. Many people today are
writing one set of business logic, but multiple UIs for it... so your
application might have green screen, printer, web, GUI and mobile UIs.
if you design it well, you don't need to rewrite anything except add a
new UI onto it. The MVC pattern helps a lot for this.
Looking at how other applications (I don't mean the one you're
replacing, but rather well-designed commercial-grade applications) do
things for ideas is often very useful, too.
-SK
On 2/16/19 12:35 AM, Booth Martin wrote:
This exercise is not going well. Lets say I have 4 programs, 3 of
which have display screens, and each program has one to four specific
activities. There are two data files used.
1. Do I combine all 3 display files into one?
2. Do I compile the programs as modules?
3. Do I write a service program, turning every activity into a procedure?
midrange.com
