Protos' Programming Logs - Episode 1

Problem Identification And Solutions to Many Interdependent Architectural Issues

With the program just being in its infancy, we are dealing with many architectural, design and build system issues. We're using the language's (C++) most practiced features and components. For example, we are using CMake as the build tool for the project as I've used other software which are game servers and have proven CMake to be industry standard. There are various features of CMake, GCC, Clang which we use to ensure that the software turns out to be of high quality.

CMake provides CTest which is its Test Driver Program. Currently and actually throughout the software's lifetime we're writing tests to ensure that 99% of all written code is covered in unit tests so that we close the gap between broken and working code. We don't want any code to go unnoticed and do something that we're not aware of or have not intended. Writing unit tests are the way to achieve this and CMake is a great tool along with boost's unit testing component we accomplish what we desire from it.

Right now, we're in the middle of getting things to work together, writing systems which are bridging the divide between software features and stability testing components. For example, we've just encountered issues with TSAN failing all tests which use threads because it was paired with gcov and coverage testing suites which created multiple additional functions or methods that compromised the software's safety and resulted in false positive thread race conditions. We've learnt to isolate the problems that are causing these issues and maintain a codebase which is aware of them and restrict the use of its software to the conditions that provide a fully useable and problematically corrected delivery ecosystem.

We want to elaborate on this and ensure that all measures of making software more stable help in also creating a correct and working ecosystem for its continuous integration and delivery. With the problems encountered in CI/CD environments we are able to solve many of the Architectural flaws that cannot be identified by just writing it. We allow the software to go through rigorous testing and validation before it alarms us of its flaws and incapabilities. These flaws shape the major architectural problems within the software itself and the external software ecosystem which help in building it. By identifying these problems we learn to create its environment and "biome" which help in its own building.

For example, in four of the test cases the ASIO / networking driver failed to connect to the MySQL machine due to an unidentified miscorrection in the configuration. Due to this only some of the test cases were failing. I failed to identify it because not all were failing, only some. After creating a new command for the connection parameter string, I was able to resolve the issue. This changed the way in which I understood the underlying architecture of the software, it wasn't that the software was failing under some circumstances, it was that the software was more rigorously tested under sanitization rules and that the failure was a major hinderance.

It is imperative that the software should go through major testing and validation procedures such as Continuous Integration & Delivery. Without the utilization of such advances in the software industry, major setback will be faced.