xsharp.eu

It is not the know how about refactoring that is missing, it is the time we want to spend on this code. We hope that X# will give us the possibility to run this code with few changes some other years and try to write some better code in the meantime using possibilities we did not have 20 years ago.

I look for something to talk about in a session. And refactoring code that is from me is a challenge for me, you know. That's why I asked for.

Hi Frank,
I believe that refactioring is only partially interesting for the visitors of the cologne conference: In case of trying to reuse as much code as possible that has been written with the dataserver/dbserver/sqltable objects and the VO GUI. And this must be done with the intention to be able to reuse old code and not having to rewrite all code.

Hi Arne,

you're kidding.
Right yesterday a got a bug report. After identifying the module where it occurs I started refactoring. At the end it was an incomplete DO CASE construct where not all possible data constellations were handled. I could not believe, that this situation could ever happen. I'm still surprised. BTW I found another bug there.

Instead of deploying an update, I searched for all remaining DO CASES to change them to SWITCH where possible. I found:
2 places with duplicate CASE blocks. A typical copy/past issue.
3 places with missing OTHERWISE block, so not reporting unusual/unhandled data.
1 uncomplete feature. (Right now a customer sent a mail complaining about. I could answer 'found already, fixed in the next update')

Saying the audience is not interested in refactoring is the same as saying the audience is not interested in delivering bug free high quality software. I really hope that this is not true for the VO/Vulcan/X# community.

I do not say that I'm able to write bug free software. But I'm always interested to find them all before my customers do. I'm doing this by spending a huge amount of time in permanent refactoring. This is as important as writing the initial version.

I see the mountain that shows up when looking to old code. What I want to show is that refactoring is not a rewrite. It's often only rearrange, sort out. It can be done in very small steps whenever you work on old code. And my experience is it's a time saver. On my side and on on my customers side.

Frank

Hi Frank,

I don't think Arne said that refactoring is not important. I'm doing it all the time, but I would never go to a session about refactoring because I think this is not something that can be handled in a session - it needs to be done in everyones code and therefore the proceeding is highly individual.
IMHO people does not go to a session to be convinced - people goes to a session to learn new things or proceedings.

Wolfgang

Yeah, Wolfgang is right. I have been in many of your sessions, Frank, and I liked them. But I cannot use many of the procedures you are using - because of another history and another environment I am working in. It is not easy to make a good session about refactoring and to be close enough to what the users of the cologne conference may need in the next 1 or 2 years.

Hi guys,

We seem to have gone off the original subject heading just a little, unless the 'Garbage Collector' is different to what I thought ;-0) Maybe these forums are GCs !?

On the subject of Frank and any session material, it seems to me that we are focusing our attention on 'refactoring' when in fact we need Frank to show us how to change our coding style from what we used in previous code we wrote - before and after approach.

If we are going to code, and NOT wait two years, I for one need to know how to write my new code so that it is suitable for 'Unit Testing' - and which parts of my code need this treatment. And now that we can do it all in X# he can give me/us all the syntax and tools and ideas to do the job.

For guys in small / medium sized companies, you need to be aware that selling on the company (when owners get to retirement age) means that the quality of the code written has a BIG influence on the sales value of that company. We have a good example of this in the UK and the guys have been working on bringing their app code, and data back-end, up to todays standards - for many years. Yes, its a big job. Like lots of us they started with VO and DBFs which worked very nicely, so why change? The value of their company on the open market was one simple answer.

Another answer was that we all need to change to 'keep up' with the rest of the world.

If it had not been for my local colleagues like Mike Pitcher then I would not be into LINQ and Code First and Entity Framework, or SQL, or WPF. Paul Piko has been a big influence on my changing of what software tools and technology I now use. Thanks Mike and Paul.

Can you all suggest ways and content of what, why, and how, Frank can help bring many of us up to date for new code we write in the next 2 to 3 years ?

Any thoughts and ideas ?
Regards,
Phil.

Hi Phil,

thank you for changing the direction. The thoughts that are always coming in my company if we speak about writing new code:
Should we put all main parts for reading/writing/handling/validating data into Webservices and write only "thin clients" to be more flexible for the future?

Arne

dr philip h. hepburn wrote:Hi guys,
Like lots of us they started with VO and DBFs which worked very nicely, so why change? The value of their company on the open market was one simple answer.

Another answer was that we all need to change to 'keep up' with the rest of the world.

I couldn't agree more.

Additionally (or consequently) if you don't refactor and keep up: productivity slows down and becomes costlier compared to the competition, difficult to attract and keep new employees.

Hi Arne,

We had the same debate a few years back when we decided we couldn't hold off replacing our VO program any longer. Our situation is slightly different, as we've reprogrammed from scratch (in C#, but of course now with X# the principles really are the same).

We've gone for a tiered approach, using WCF in place of traditional web services, but again the principle is the same. It's been completely liberating as far as app development and design goes. Our server modules (which sit behind WCF) are 100% responsible for CRUD operations on the database (SQL Server Express), and simply supply disconnected data to the clients. The client programs don't need to know anything about the db at all, they just deal with collections of objects returned from the WCF services.

In reality, validation needs to be partially handled on the client (basic stuff like x field shouldn't be empty), partly by the db itself (with constraints, unique indexes etc.) and partly in the server modules (eg. where we need to check something in the db before we can confirm and save new or edited data).

By working with a disconnected 'thin' client, you learn to make access to the server more and more abstract and it makes adding or improving functionality very simple. For example you may have a server method that retrieves a list of data from a certain table or view. The server method may have a simple enum as a parameter that defines what the search type should be. So you might start with options to search by name or city in a contact database... In the future you decide you want to add an option to search by postcode, so all you need to do is add a new enum value, and in the server add an extra search condition, and the client will be able to use it immediately without knowing anything about the database.

Again, with a disconnected server you can 'easily' swap back end database, as all you need to modify is the server modules... the interface to the client can stay the same because it holds no reference to the physical db.

The only thing that held us back to begin with was that quite a few of our smaller clients have single programs installed on a single machine, where the server/client model would just be unneeded complexity. But it's very simple to give the option for the client program to call the server dll methods directly, without going through webservices or WCF... so at that point your single install becomes a traditional desktop app. So we ended up with source code with a single compile producing a single set of exe and dlls, which can be installed either on a single machine, on a LAN (with server modules on the LAN server and thin clients on the workstations), or a web server (again with local thin clients).

We could also easily add eg. an ASP.NET type client if we wanted to in the future... server modules would still be the same.

HTH

Nick