Engineering Practices

Acceptance Test Driven Development (ATDD) Practitioner Writing acceptance tests together with the business before coding, so everyone agrees what done means. Automated Testing Practitioner Tests that run by machine on every change, so teams can ship often without breaking things. Behavior Driven Development (BDD) Practitioner Describing software behaviour in plain-language examples that business and developers both understand, then automating them. Clean Code Practitioner Code that's easy to read, understand and change, written for the next person who touches it. Code Reviews Practitioner Having teammates read code before it's merged, to catch problems early and share knowledge. Collective Code Ownership Practitioner Anyone on the team can change any part of the code, and everyone is responsible for its quality. Containerization Practitioner Packaging an application with everything it needs to run, so it behaves the same everywhere. Continuous Delivery (CD) Practitioner Keeping software always in a releasable state, so any version can go live at the push of a button. Continuous Deployment Practitioner Every change that passes the automated pipeline goes straight to production, with no manual release step. Continuous Integration (CI) Practitioner Merging everyone's code into a shared branch many times a day, with automated builds and tests on every change. DevOps Practitioner A culture and set of practices that bring development and operations together to deliver software faster and more reliably. Domain-Driven Design (DDD) Practitioner Designing software around a deep model of the business domain, shared in a common language with experts. Emergent Design Practitioner Letting software design grow step by step as you learn, instead of fixing it all up front. End-to-End Testing Practitioner Testing a whole user journey through the real system, from the interface to the database and back. Feature Flags Practitioner Switches in code that turn features on or off without deploying again. Infrastructure as Code (IaC) Practitioner Defining servers, networks and other infrastructure in version-controlled files instead of manual setup. Integration Testing Practitioner Testing how parts of a system work together: modules, services, databases and external APIs. Legacy Code Refactoring Practitioner Safely improving old code that has few tests, by adding tests first and changing it in small steps. Microservices Practitioner Building an application as a set of small, independently deployable services, each owning one business capability. Mob Programming Practitioner The whole team works on the same thing, at the same time, at one computer. Pair Programming Practitioner Two developers work together at one computer: one types, the other reviews and thinks ahead. Performance Testing Practitioner Checking how fast and stable software is under expected and extreme load. Refactoring Practitioner Improving the internal structure of code without changing what it does. Security Testing Practitioner Finding security weaknesses before attackers do, built into everyday development rather than left to the end. Simple Design Practitioner Building only what's needed now, in the clearest way, so the design stays easy to change. Test Driven Development (TDD) Practitioner Writing a failing test first, then just enough code to pass it, then cleaning up: red, green, refactor. Trunk-Based Development Practitioner Everyone commits to one main branch at least daily, using short-lived branches or none at all. Unit Testing Practitioner Fast, automated tests that check small pieces of code in isolation.