5 Common Methods for Developing Robust and Maintainable Software
1. Think small and simple
Most developers try to comprehend the whole system when they start writing the first line of code. No one can predict what challenges you will face from the start. Of course the developer should have an initial plan or roadmap how the development should progress, but this never implies that everything is 100% decided up-front, and there is no room for error.
You have to start a project with a little humility. You don’t know everything upfront, you’re going to learn along the way, and then you’re going to change as a result of that. You’re going to do one iteration.
Darin Grove CEO @TrueFit
Thinking small and simple helped develop solid development patterns, such as DDD (Domain Driven Design), and event storming. These principles helped many developers to build solid and effective ways of implementing features. Although building features as fast as possible is important, another important aspect is that you need to minimize the error of implemented functionality.
2. Reduce complexity
It is easy to get lost in code while writing new features, but more often this results in increasing the complexity of a method. Even if you have a fully functional and working logic, in the end it causes difficulty when inspecting and tracing errors, and results in tightly-coupled code.
You can write a method as complex as you want. However, if you need to change it every time to interact with a new functionality (either completely, or partially), then the additional complexity was not needed. This not only applies to a single method, but the overall architecture; in other words, complex designs create complex problems.
We as developers work on many aspects of software, and tend to not fully remember what was our intention when we finally implement the logic. To avoid future confusion for ourselves and our fellow team members, handling functionalities in small chunks will ensure features are delivered quickly, and the business logic is maintainable in the future.
Think your software as a big storage room. If you put everything in one box you will never find what you are looking for quickly and efficiently. But if you divide your stuff into small boxes and label them in an understandable fashion, you will know where to look at from start.
3. Refactoring
Every developer likes to refactor (or so I think they like doing it; just my opinion!), and it is an important part of improving the efficiency and quality of the software. There is one big problem when we talk about refactoring: the size of the change, and how much it affects the overall software.
Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant.
Martin Fowler in Refactoring — Improving the Design of Existing Code
When a developer starts improving the code, it is like a chain reaction, it is like a plague. It starts from a single point, and grows and grows until the moment where the whole business logic is rewritten, which is not refactoring. The point is improvement, not to produce a new feature, or replace an existing system.
This topic directly interacts with the previous steps: keep it simple, and reduce complexity while refactoring the existing code base. This will allow you to not to get lost in the software, and gives you the opportunity to have more control over individual components.
4. Unit Testing
Everyone talks about unit testing, and how important it is to cover implemented features, but most developers write it only to cover predicted cases. What about the unpredicted situations? Shouldn’t we also think about those? Don’t we all have “what ifs?” in our mind, or do we just sit and wait for QA (Quality Assurance) people come to us with unexpected results from the software for unrealistic scenarios?
Another common mistake when writing unit tests is creating the test based on the logic implemented for the software. Of course, as a result, there will be cases that a given unit test will not cover because the input data and the output data was shaped based on expected parameters. Even if you do not follow TDD (Test Driven Design), you should approach each test case as if you don’t know the internal logic, but you know the expected outcome.
Do not modify the unit test logic just to pass the test scenario. The unit test case should be designed to simulate expected input and output. However when you change something in the code base and if it affects the test result, there are two possibilities:
- Poorly designed test case / scenario
- Testing too many functionalities at once.
A test means even if you refactor internal logic, the input and the output should be the same; your change should not be breaking any response if it is not by design of a major change in overall software. That’s why it is good to keep unit tests small.
Unit tests are not functional or integration tests. It is easy to confuse the two of them with each other.
5. Second pair of eyes
Yes, we are all confident in our knowledge on software, and yes we all know that we don’t know everything about software. As developers we find solutions to various problems and there are always multiple ways to reach the end goal.
When a developer sees a problem, it is not like those fancy Hollywood movies; the formulas are not flying around to point out the solution. There is always the initial idea for the feature or the problem. After that, a couple of ideas will arise before and during the implementation as well. However, there is always a limitation on a person’s own way of solving the problem if they are too deeply involved or too close. That’s why sharing your ideas with others before or during the implementation phase can result in a positive outcome; namely, helping your ideas to become more evolved and more polished, as well as giving you outside perspective.
If you are too close to something, there is always a high chance you will miss out some details.
About ParkBee
Sounds like something you would like to work on? We’re hiring!
I work for ParkBee. We develop smart tech. Our Mobility Management Solution optimizes the use of underutilized parking space to get cars off the street and KEEP YOUR CITY MOVING.
Check out ParkBee’s Careers Site , or follow our @lifeatparkbee Instagram account.
