Wikis > Co-op Student Projects > Ongoing Development Tasks

Ongoing Development Tasks

This article is meant for developers (CSC and SENG students). The VBRC codebase, webserver, and database all show their age. Decisions were made long ago that are no longer valid today. The accumulation of assumptions and poor design choices has resulted in a codebase that is difficult to maintain and extend. While it is true you will likely be working with a lot of legacy code in the industry, the industry is also adopting more modern approaches and you want to be prepared. I believe that maintenance of the older applications here will happen for a long time as the slow process of migration takes place, so it’s a roughly accurate experience.

Some of the projects you could adopt are:

  • [MEDIUM] Rewriting applications. Investigate existing apps and their usability and maintainability. It can be cheaper (in development time) to rewrite a legacy app than to maintain it indefinitely. Potential benefits of rewrites are better code, performance, documentation, ease-of-use, and a decrease in development time when adding new features. -> Adopt a better rich client platform/framework for new GUI apps. Everyone can agree that Swing is terrible. For anything more than basic forms, a rich client platform is beneficial. I chose to use DockingFrames and IntelliJ UI designer to augment Swing in Vocs2, but it’s not ideal. Things to consider are choosing a framework compatible with Maven builds (can come from a Maven repo itself hopefully), is editor-agnostic, is well maintained and a popular choice among developers (for support), has data bindings, and is preferably free and open source. There’s no perfect solution right now, so you might have to compromise.
  • [HARD] Creating a new database schema for current needs. A new schema is needed because the current one is full of redundant or unused data, empty tables (~half of them!) or columns, and is more difficult to program for than it should be. Features like cascading deletes, data integrity checks, or autogenerated primary keys are not used. Some tables are misused. Users should be redone too. This project has the challenge of what to do with existing data. Is it migrated, or supported in parallel? How will the new database be synchronized with the old one? This has the advantage of making newer apps cleaner with less development time down the road spent on schema changes. The disadvantage is finding a way to keep older apps operational.
  • [EASY] Open sourcing our code. There is no reason why our code shouldn’t be open to outside contribution. You will need to find a way to protect database and other credentials that might be in the codebase.

Comments are closed.