When developing an app, we need to care about a lot of things:
- dealing with client
- the code itself
Even if we know about the rules and how "it should" be done, in real-world things may look different. Especially in the smaller teams, applying all of the procedures can become overkill and can prevent actual code delivery.
In the real world
- the budgets are tight and a lot of clients are not willing to pay for e.g. testing,
- the deadlines are short and you're late with coding (yes, you are), so you need to catch up with the features instead of reviewing the docs, writing the tests and cleaning up the code,
- you might have an unexpected party all over the weekend, your kids may get sick and stay home, you just feel bad and are not able to work with 100% performance,
- the new team member is not that experienced and you spend time on code reviews and training.
If you are able to keep all of the app delivery items mentioned above - that's perfect. But if you are not, try to set the minimal rules for the project or organization that will be reasonable. It's much easier to have some rules to follow, but it's even better if the rules are achievable and can be easily applied by the team members.
Dealing with the client
It's the part that usually isn't handled by the developers, but still, some feedback from the dev team is often needed.
What works best in my experience is to set up weekly / monthly / daily updates that give the client feedback on the stage that we're currently working on. Let's put in such an update a short summary of what was done last week (day, month) and what's scheduled for the next period. This prevents ongoing questions, emails, messages from the client, who is curious about what are we working on.
What is important - the update has to be sent on time - it doesn't matter if it fully covers last week's schedule or not. If you failed with developing a feature on time - let the client know, it prevents cumulated disappointment a week later. Anyway, come on - you're a developer - you can use dozens of phrases that mean "failure", but sound professional ("We moved form validation to the next week as we need to move it to the backend API") 😊
It may sound silly, but coding should be the main part of your work.
If it's not, something is wrong in other areas that consume too much time. I worked for some companies that needed everyday conference calls or meetings, daily updates (which were discussed on the calls by the way), plus far too complex project management tools. Handling all of them took me more than 50% of the day which made the app's progress really poor.
In terms of coding itself, it's important to have a repository and some basic rules of contribution and code consistency which are followed by the developers. If you decided to use React Hooks, use them. If you code a WordPress plugin - you have the guidelines prepared by the vendor. If you use feature branches - use them and merge properly. Make sure the team follows the rules - otherwise your code will be inconsistent and harder to maintain.
Testing is nice. I like testing much. Your clients like testing too, they think that it's a great idea to test everything, but they don't want to spend money on this ("Let's do the testing part later"). If you persuaded your client to invest in testing from the beginning - that's perfect - but this is a hard task.
Unit testing takes a lot of time, it includes a separate testing environment, and often it's not resistant to client's updates ("Let's update the registration flow with the middle step").
Anyways, even if you're easy-going and hope that your app is doing well, still - it needs some testing. At some point in development, a question
"will it work if..."
will grow in your head and tests will answer to this. What to do if you don't have much time to fully test your product, but still need to sleep well without waking up and checking if all is ok with your app? Of course, you can ignore this and have a shot of vodka, but still, you can also use E2E tests.
E2E tests can be created faster and give visible results, which are easy to show to the client. I usually used Cypress, which could record videos from the testing browser.
With E2E you can quickly create tests for the most important flows of your application (registration, login, purchasing a product, etc.). It's fast (you can do a lot in 1-2 days), impressive, and ensuring that your app behaves as it should in critical flow.
If you're lucky - you have a knowledge of DevOps and are able to configure domains, databases, auto deploys, and can control the machines with some scripting. If you don't have such knowledge but are smart - you can persuade the client to hire someone to set it up for you. Otherwise, you will need to create the servers manually or use some SaaS like Ploi, which can do a good job for the process of the deployments.
Environments can be configured in many different ways, but the good idea is to set them up early. I mean, really early, before actual coding. Usually, you start coding and put the first effects on some testing domain and temporary server. Then, you don't have much time to move it, client has further expectations and the app is still there. And it grows - it's not so easy to transfer it now.
Think about the deployments early - choose the deployment model, whether you need load balancers or not, how many machines should it run, should it have a local or remote database, certificates. It's the work you would do anyway at some stage - let's move it to the beginning. If possible, also run everything on the final domain and client's owned machines - it's easier to migrate everything when the work is just beginning than to work on extended (or even already launched) project.
That's the part that we like to think about: "Ok, the app is working - let's do some docs for this". In fact - creating the documentation is simple - maintaining it is tricky.
If you don't have time to to the documentation updates, you shouldn't create one. Docs once done are outdated after 2 months, it's an ongoing job to update it.
What I do recommend here is to write good Readme (or Readmes). Really, one good and working Readme makes a difference. Write how to launch the app for the development, how to deploy it, how to contribute, what SaaSes it utilizes, where to look for the keys to them and how the infrastructure looks like (is it AWS or Google Cloud, with EC2 machines, with a load balancer or not, uses Lambda, API Gateway, etc.).
Think of Readme as a guide for a developer that joined your team after you were hit by a bus, and no one can tell him how to work on the app. After reading a Readme he should be able to know where to start and the next steps to make.
- As a developer - you're still human (or I hope so) - remember that the rules are for you, they can help you a lot to keep your project clean but use no more rules as you are able to follow
- communicate with the client with the development updates and schedule
- send updates on time, build trust
- set up some code rules and follow them (whole team)
- if you can't do full testing, use E2E tests for the critical flow of your app
- Set up deployments + environment early, before you start coding
- If you can't do the documentation, good readme will do a minimal job