Our approach on Software Architecture and Agile Testing
Applications grow over time. You start with a small piece of software, but along with the business needs the list of functionalities and used tools keeps growing.
At this point, the structure of an application often starts to become confusing and the code more and more monolitic. If this process goes on over the years, you will have then an application that is bridle and slow because of too many bottlenecks.
To prevent or fix these problems, different measures can be taken:
Agile Testing: Start automated testing
There are different – complementary – types of Agile testing. Unit Testing or Test-Driven Development helps you keeping your source code clean by forcing to think about the code structure before coding. It helps you testing all the business rules of your application.
On the other hand, Acceptance Testing (or Behaviour Driven Development) helps you ensuring that all different scenarios or use-cases are working as expected. It is also a great way of testing legacy-applications that can’t be tested with unit tests.
Running these tests can be time-consuming. Therefore you should think from the start about a Continuous Delivery/Deployment environment to automate testing. This prevents regressions in your source code and restores confidence in your application.
Loose coupling: Start to break dependencies
In the past, applications often were run only on a web server and a relational database. Nowadays, the list of components is much more complex: NoSQL, caches, search engines, … To keep your application flexible, all these components shouldn’t know about the definitions of the other components, making it possible to exchange parts of your application easily. The concept of loose coupling also applies to your system infrastructure. Using independent micro-services instead of tightly coupled components increases flexibility and reduces costs.
Sometimes it can be necessary to rewrite code. Throwing away the entire application, to start over from scratch, mostly ends up in delays and abandoning the new version because you won’t get the time to implement all the features your existing application already possesses.
Instead, you should think about only rewriting – or refactoring – parts of your application. When respecting the right practices and rules, the refactored code can be modular, and thus being reused in any future version of your application.
There are different types of performance problems:
- Response Time:
- Countless studies have proven, that a too high response time make customers leave your website much earlier. The perhaps most interesting example is Amazon, who found out, that every 100ms of additional response time make the sales drop by 1%. So it is crucial not to think only about the code quality but also about the speed with which your application can deliver its content.
- What happens if your application gets more and more work? It is important to verify that your application can handle a bigger workload without consuming an un-proportional amount of resources. Problems can be in the way you address external resources like databases or entirely in the way your infrastructure is built.
Cloud Application readiness
Moving an application to the cloud is about making it horizontally scalable. This means that it must be able to be deployed and to run on a varying number of servers without configuring it for each machine separately. To achieve this goal, a few rules should be followed : Use a task runner to make your application configurable and to automate things that need to be configured. Use a database migration tool to automate schema changes and prevent inconsistencies during deployments, etc.