There are only 4 operations a developer can make on a legacy system
- Fix
- Add
- Remove
- Refactor
It can be daunting to work with legacy systems. Especially when the manager tells you to just "add this" or "change that" without a detailed successful outcome.
90% of the work of a developer is typically finding what you're changing / removing / adding. Theerfore it is important to minimize this as much as possible by utilizing the correct questions.
Unfortunatley most "senior" developers and managers do not understand the best way to organise new projects. Most managers don't understand that not only do you need to program the computer system, you also need to program the developer. When I say "program the developer" I mean proper documentation, a good readme, automation of code linting, automation of testing, deployment automation, a set of developer guidelines, and an understanding of what you should not expect the developer to do.
In today's world, with the amount of development tools available, a good manager should be able to design a system that can onboard junior developers within 3 days.
Complete these steps once per project (once per repository)
- Consume the information within the readme
- Update what is incorrect where practical
- Check for a .editorconfig file (Does it exist? Is it valid? Are the rules being applied?)
- Just be sure your IDE is formatting new code correctly
- Does the project have linting packages that should be integrated with your IDE
- Does your project have a unique developer flow (do you need to run tests with a specifc command before deploying)
- Be sure you understand the process for deployment
- Does it use containers?
- Does it use single command deployment like firebase
Start at this stage for all new tickets. Make sure you know all of the points in the diagnostics stage before continuing. If you don't then you need to collect more information before starting
Diagnostics
- How can you re create this issue
- Is it an issue with the environment or with the software
- What is the expected behaviour
- Which branch is the code broken on?
Development
- Source the error
- Put in possible solution
- Test
- Push to repositiory
Diagnostics
- Establish a sucessful outcome (write a brief)
- What exactly should the user be able to do?
- What exactly should the delivered product be (a webpage, an api, a set of functions, a class...)
- Confirm with the appropiate stakeholders regarding the success outcome (be aware of inter-corporate miscommunication)
- Establish the inputs for this new system (compile all the necessary input information)
- What does this feature need to know, what variables need to be collected, outline all required inputs (can be abstracted)
- Establish what state this addition needs to be in for you as the developer to be done
- Does it need to be deployed to stage server / handed to a senior dev / pushed to a specific branch etc...
Development
- Establish a logical flow for your solution on paper or using psuedo code
- Write your solution
- If the legacy system is complex then create the feature as a plugin module with dummy input
- If the legacy system is simple then implement directly
- Get your module / final product reviewed and work with a senior developer to iron out the last parts (replacing the dummy data with data from the system)
Diagnostics for Refactor tbc: some elements from adding featrues can be resused