Just started working with a new company, inherited sloppy code
Recognising Sloppy Code
Developers know it when they see it; non-modular; repeated, disorganised directory structure, editing on production systems.
Business operators on the other hand don’t, here’s some tips.
Examine the Project You don’t know code, but if you see many duplicate names.
Or files like like home.php, home-0.php, home-12july.php, home-bk.php, home.php~ that is an indicator of slop.
More importantly it highlights that there is no code tracking tools in place.
It’s very important that the code team use tools like Subversion or Git or Mecurial or Bazaar.
Third Party Review Get a second opinion.
Have an alternate, cash compensated dis-interested third party review the code.
The the report comes back an mentions duplicated code, lack of structure and other such then we have slop.
If the code as been identified as sloppy, it can be an expensive process to resolve it.
It’s important to enforce good development practices from the beginning.
- Use a Source Control system (Subversion, Git, &c)
- Host Multiple Environments: Work, Test, Beta, Live
- Review Code with a trusted third party
- Test, Test, Test
- Control the Team – Don’t let them stray or feature creep
Resolving Sloppy Code
Quite a tough problem, clean what is there or throw it out entirely and start over?
Depends on the depth of the project.
Many times small fixes to the slop can keep the system operational and continue to generate revenue.
Rebuilding requires to redefine the specifications and basically re-build from the foundation up.
Maintenance time is lost to rebuild-time – or one could bring in a new team for the rebuild.
Smaller teams are forced to try to re-work existing code to a more unified option, perhaps implementing one framework or another.
In some circumstances early projects have two conflicting methodologies in-place.
And the choice must be made to use one of those two, or fork to yet a third option.