1

We are currently supporting a very outdated, unstructred, untested and unstable ERP desktop application coded in Windev (on windows). As the days go on, we need to add more features for the users but we keep running into terrible bugs, data loss and integrity issues. Whatever we try to implement in order to save us from rewriting the whole thing is constantly failing because of how the application was structured.

I am tasked with finding a way to slowly merge into a new cleaner architecture without the need to close the business down for a complete rewriting. Since we don't have any tests and that the code is not meant to be tested, refactoring is extremely dangerous because we aren't covered by any safety nets.

Most of the bugs we have are data related and since every entities are accessed from all over the place, it is really hard to fix data issues or to ensure that it is robust. We run an ERP so what we sell should be robust data.

The current approach I am considering, is slowly merging everything into a backend API with a robust structure in C#. The plan is to make every new database accesses via the local API and to progressively merge existing data into the API. Since current resources are accessed from all over the application, many of them will be partly migrated into the API and partly still hardcoded in the Windev application until all accesses to a certain entity / endpoint is fully migrated.

The advantages I see in this is that we will be able to slowly merge through a new application and eventually have centralized all data access which will allow us to test the endpoints. Another positive point to this approach would be that most of the heavy work would be done if we decide to go into rewriting since we would only need to convert a bit of business logic and create a new UI. We could even go web if we decided to just by hosting the API. Client requests are not blocked since we only need to pass new data in the API and merge old data accesses into it.

I see some issues including the fact that it will be a pain to support both the application and the local server for a good while and that we could have a bit of impact in the performances but I still feel that the positive aspects greatly outweights the bad ones.

Am I completely insane by going with this approach and am I missing some obvious cleaner solution.

keep in mind that the programming language we are currently using comes with a whole closed ecosystem in which we are stuck with it's own deployment tools, it's own querying language and database with very little documentation and that it is extremely limited in terms of clean design. It is even very hard to be able to apply OOP principles to it so we need to escape this eco-system ASAP

  • 1
    Everything you wrote sounds pretty reasonable, but instead of asking some strangers on the internet, none of them actually know your application, you should simply test your strategy by implementing a small, isolated part of your new API and try to utilize it the way you have in mind. Moreover, be sure the part of the system you are going to replace is the really part which has the most issues. – Doc Brown May 8 '18 at 19:34
  • @DocBrown You are right and this question is on the side since I'm currently writing a POC to see how it all goes. I was just wondering if using a local API to assist such a huge turn was a common practice or an obvious huge mistake. You are right in saying tho that without much information on the application itself, it is a tricky question to tackle. Thank you for your time ! – PhaDaPhunk May 8 '18 at 19:36
  • 1
    If you put queries behind abstractions, you will be able to implement abstractions by moving actual queries to the implementatio ( not sever API, but just another library). Later based on requirements you can implement it by API on local server – Fabio May 8 '18 at 20:41
1

You can create the API and make Posts/Get calls through the interface you currently have. I am not familiar with WinDev, but putting in place what I suggest will allow you to keep the current interface while slowly decoupling. Once you're comfortable you can move the frontend to a web interface, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.