My Software Engineering checklist

In this post, I am sharing the checklist I normally use when coding. At the same time, I am using this as a reminder to myself - as I usually tend to forget applying certain important principles.

The main idea is to avoid optimising the codes at the first but at the same time - not getting the work done - without proper design and thought for maintenance.

When working on a new problem:

1. try to understand the problem statement by rephrasing into user stories if that's not already the case
2. confirm my understanding with the Product Owner or Project Manager
3. analyse the solution using spreadsheets so that I can show different variations ( OK / KO cases)
4. confirm the solution to the same people as above
5. if I get the green light, I will code a first iteration just to make it work with hard coded values and match the spreadsheets results
6. at this point, I also try getting a feedback but sometimes I prefer completing a quick demo
7. once I get a working version and it's validated by the Product Owner, I will make it better by using good programming practices such as DRY, KISS and SOLID

Don't Repeat Yourself (DRY)

The main idea behind this principle is to avoid duplicated codes. This makes it tedious to maintain as the software scales. You want to have only one place to change the codes and it's reflected where needed.

KISS (Keep it Simple Stupid)

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Kernighan's law.

If we write codes that are too smart or clever, we won't be able to easily debug it when there is an error.

I often find people coding logic, myself included, in a single line. How do I debug one part of it when there is an error? The best case scenario is having logs for each variables or constants, written separately, even if this appears dumb or unoptimised. You can therefore directly see the logs, without having to change any code by adding debuggers which take time.

SOLID

The SOLID acronym means:

• Single responsibility
• Open–closed
• Liskov substitution
• Interface segregation
• Dependency inversion

I don't use all these principles all the time. But I think the Single Responsibility one is precious. Have a method do only one thing. Ideally, let a class have a single purpose. I find this highly efficient when writing unit tests.

For example, you can have a class Account, which deals with everything accounting. You have a method getAllAccounts - do only one thing - return the list of the accounts. You want to display it in a table. Have another method to do it.

Then, when you write unit test, you can easily mock these functions.

Open Closed is another design principle that is useful in real world applications. The idea is you can extend a behaviour of a method without changing the actual codes. In TypeScript, I use decorators to achieve that. For example, I parameter decorators to check if an applicationId is present in the request.body (expressJS).