Code Quality

An illustration of the Bridge design pattern

At TenTwentyFour1024, we aim at writing code that is of high quality, thorougly tested and well documented. The resulting code base is thus easy to understand and maintain. To achieve this, we adhere to established and proven design patterns, automated tests and regular peer reviews of new code.


Current web applications easily reach a size of ten or even hundred thousand lines of source code. When the amount of written code lines increases so does the probability of loosing the overview of the project and such introducing bugs. Not only is bad code often a security risk, but can become really expensive once your company decides to switch - you will have your reasons - the current developer/IT service provider and to sign a contract with one of their competitors. The later hopefully being us ;)

Various aspects may engender that code is difficult to maintain and modify. This may be a lack of documentation, insufficent separation of logic, display and content or missing test suites. As a result, the new company needs to invest a huge amount of time into understanding the current source code, before they can even get started fixing bugs or implementing new, urgently required features. For your company, that pretty much represents an investment loss.

Unit Tests

Besides making sure that our code implements the features our customers requested, we equally want to ensure that each and every unit of our code works correctly. We start by writing the tests and only then write the corresponding source code. An initial successfull test means that the code has been correctly written and running the same tests after each set of modifications ensure that new features don't inadvertently break existing functionality. At the same time, covering a high percentage of the code with tests adds to its documentation: In parallel to testing the correct execution of functions, unit tests also document a functions' expected results.

Code Review

Nobody's perfect, but two pairs of eyes and the combined experience of two or more developpers sure helps in finding code that could be refactored or rewritten in order to become more elegant, more efficient and more secure. To peer review source code written by its developers. TenTwentyFour1024 uses the code review tool Differential, which is part of the Phabricator suite of web-based software development collaboration tools. Differential delegates testing to our Jenkins continuous integration instance and automatically triggers a build when new or modified code has been submitted to a project's git repository. Our workflow thus guarantees that the code is both beautiful and functional.