database queries that simply fetch data from the repository<\/li>\n<\/ul>\nWhen combined, the design elements described above provide a skeleton that covers all the requirements of a typical request-response flow. It is relatively easy for a new developer to implement a new feature, given she has understood the purpose of each design element, and how they relate to each other.<\/p>\n
Coding guidelines<\/h4>\n
There is no document to be followed blindly and religiously. There are no rules set in stone to be enforced. No one is being punished for not applying the Almighty Guidelines. However, we do set expectations by discussing “do’s and dont’s” during the code review sessions, the monthly lightning talks and the code katas we perform together.
\nAt the end of the day, the code must be written in such a way that we can answer with a resounding “Yes” to the following questions: Is it usable? Is it readable? Can it be easily changed?<\/p>\n
Testing strategy<\/h4>\n
Our testing strategy includes writing test suites that are executed on demand, or automatically before a new version is deployed into production. These suites serve as the entry criteria of a new deployment into production. The types of tests we employ are:<\/p>\n
Unit tests – are used to validate the behavior of individual classes in isolation, which means that its collaborators are being mocked<\/p>\n
Integration tests – are used to check the correctness of methods which store and retrieve data from the relational database without mocking it<\/p>\n
Functional tests – are used to verify the application as if a real user were using it, by going through the user interface and checking that the correct outputs are being displayed on the screen.<\/p>\n
Recently we were hit by the fact that the functional test suite was growing quite big and that the amount of time spent on executing it was soon to become unacceptable. It became evident that we were testing too much and that we were over-relying on this particular suite of tests. That is why we have organized a short session to determine the core functionalities that are critical to the product. Based on that, we have defined a new, slimmer suite of functional tests to replace the old one.<\/p>\n
On top of the unit, integration, and functional tests, we also make use of manual exploratory testing and some smoke tests after each new deployment. All of the above give us the confidence that we delivered the right thing and that it functions properly.<\/p>\n
Continuous deployments<\/h4>\n
Our implementation process setup consists of a continuous integration server connected to the source control repository. Whenever a change is pushed to the master branch, the application is built, tested and deployed into the production environment.<\/p>\n
Such a setup has the advantage of being configured once at the beginning of the project and then “forgotten.” Every time a new commit is pushed, it will churn out a new build, on its own without manual intervention. It is needless to say that a lot of time is being saved by not doing manual deployments. Our process is less error-prone and repeatable.<\/p>\n
Unlike in a traditional iteration-based agile process, we do not release once every two weeks, but rather every time we have a new feature ready to be deployed. Sometimes, this means several times a day. This approach removes the burden and the fear of deployment from the shoulder of developers and allows us to focus on what matters, which is to deliver value in the shortest cycle time possible.<\/p>\n
Conclusion<\/h3>\n
By now, you’ve taken into account why having a technical strategy pays off in the long term. Maybe the stories of the impact it had on my daily work will inspire you too. At the very least, I hope you’ll give it a try. Let us know in the comments how that worked out.<\/p>\n","protected":false},"excerpt":{"rendered":"
Doing your job as a software developer is not limited to writing code and attending meetings. It should also include keeping in sync with your company’s technical strategy. It may not be that obvious, but a developer should know what the technical strategy of the product is, why it needs a plan at all and […]<\/p>\n","protected":false},"author":11,"featured_media":9663,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"footnotes":""},"categories":[1103,1125],"tags":[1146,1333,1334,1123,1315,1319,1335],"acf":[],"_links":{"self":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12201"}],"collection":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/comments?post=12201"}],"version-history":[{"count":0,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12201\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media\/9663"}],"wp:attachment":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media?parent=12201"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/categories?post=12201"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/tags?post=12201"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}