Depending on the scope of a project, the actual development phase might take anywhere from a few months to a few years to complete. A poorly managed project, or a project that wasn’t scoped correctly from the get-go, has a significant potential for errors, unscalable parts, and an unwieldy code base.
In the case of Jobsity, for example, we’ve been working at Jtalent for almost two years. Developers have come and gone, and while the scope remains relatively consistent, there’s a constant need to add new features and fix functionality bugs.
Refactoring swathes of code is a costly approach that, while ideal, can inflate a budget and take resources away from finishing a product before the deadline.
A quick exercise to do with your existing codebase is re-reading through features you’ve already done and figure out why you did it that way. This test could give you an insight as to what you would do differently, what sort of logic you would use these days, and sometimes if you’d even keep the existing logic as is, but you would use a different framework to work it into the project.
Here are some tips on what to look out for when re-reading legacy code.
Classes are essentially line manufacturers of objects. They are made up of objects and can manipulate them.
Classes should come into play when they have a specific purpose. The general “best use” consensus these days dictates a move away from rich classes and into more stateful components.
Another good way of structuring code is to avoid mixing data and logic.
Also, since classes can become unwieldy and confusing, avoid using them as much as you can. If the need arises that you must use a class, it should do only one thing.
Modules should be used to create a single export (or few) that would result in one file per function, or one file per class, and so on. This way of grouping modules creates a large number of small files, which makes code much more readable and maintainable. Also, dependencies are declared more efficiently with this method.
Phase Out Untyped Objects
Smaller codebases don’t suffer much through the use of independent untyped objects all over the place, but when used liberally through larger projects, they become a liability.
Having dangling objects without a defined membership can cause significant headaches during runtime, as it’s difficult to infer if a property exists or if a type has been set. On first glance, these objects don’t tell you what their status is at runtime.