the in softvare fixing The things I totally changed my mind 20 year later typos devlopment w e crafted by lemi orhan ergin co-founder of craftgate v2

Move Fast: How Facebook Builds Software book by Jeff Meyerson Reference: in 2009, as a 5 years old company 200M active daily users FACEBOOK ZERO TESTS

in 2009, as a 5 years old company 200M active daily users FACEBOOK ZERO TESTS They weren’t doing the things in my books. But they weren’t failing. I’m OK with people doing things differently than in my books; I just want them to fail. Kent Beck The author of 9 books including “Extreme Programming Explained” and “Test Driven Development by Example” joined Facebook in 2011 Move Fast: How Facebook Builds Software book by Jeff Meyerson Reference:

in 2020, as a 16 years old company 2.5B active daily users RELIES HEAVILY ON TDD Move Fast: How Facebook Builds Software book by Jeff Meyerson Reference: in 2009, as a 5 years old company 200M active daily users FACEBOOK ZERO TESTS

Works for me does not mean works for you. It depends! be aware of survival bias

hey! we are not google or facebook Mono-repo is totally a mess Scaling the environment, pipeline and practices is impossible for huge, multi-api, multi-team mono- repos. It adds architecture overhead and too much technical and managerial complexity. Every team has to access only their own repos

FIXED Mono-repo- fi rst pattern Refactoring is the most common activity you do for an immature in-progress product. So do not drown in change sets among multi repos. Start with one, split if required in the future. similar to monolith-first strategy

FIXED restricting repo access to a specific team is a smell most of the time fi Mono-repo boosts collaboration When teams are able to access and update repos of other teams, irrelevant dependencies disappear. Ownership spreads and collaboration increases. One mono-repo for one team (one domain) could be a start for having a cross-team mono-repo

Deploy to production when MVP is ready Production deployment is expensive and requires too much effort to build proper pipeline. Start with test environments and push to production whenever MVP is ready for the customers. No one loves to see half arsed product, even early adapters the deployment pipeline for development use the time of creating

FIXED Deploy to production early and often, even start from the fi rst days Focus on integration tasks fi rst. Build CD pipeline from the fi rst day. Early creation of deployment pipeline shortens the development and feedback cycles dramatically.

FIXED feature toggles generate waste, so use it carefully Deploy half features to production as hidden and disabled Being able to deploy half features immediately gives critical advantage to teams by shortening deployment and testing time, and increases customer satisfaction.

Microservices are for splitting the whole domain into pieces We need to decompose business domain into smaller, consistent, bounded contexts Microservices should be small enough obeying the Single Responsibility Rule.

FIXED Microservice is a deployment strategy Every team should own a bounded context, not a set of microservices. Microservices architecture has nothing about SRP. It improves scalability (technical & organizational) by providing a loosely-coupled system. SRP can be achieved by adding modularity to the system, not by adding new microservices to deploy.

Stop the pipeline below %80 code coverage Code coverage directly implies code quality. Sonar is our best friend. Every developer should write unit tests for every line. Never allow merging pull requests having coverage lower than 80%. (Sometimes adding fake/empty tests is ok)

FIXED Write enough number of tests till you feel comfortable to deploy to production Don’t care how much tests you wrote. Tests should be fast, tests should validate the app is working properly. If you feel comfortable enough, just move it to production. quality of tests are much important than the quantity

Use Pull Requests for code review Every team member checks the change-sets line by line and provide helpful comments Using pull requests guarantees that the codebase is fully reviewed, understood and approved by the team PR

FIXED Pull Requests are the least ef fi cient technique for reviewing change sets Pull Requests are ef fi cient if you have speci fi c owners of the codebase and need to keep the change sets in control To get real feedback, show and talk about changeset with the team or develop in pairs never trust PR reviews having more than 10 lines of code in the changeset

Unit tests are for testing methods, integration tests are for testing the fl ow Since unit tests fail all the time during development, it is safer to write integration tests only to validate the business fl ow Unit tests are for validating algorithms and mature logics

FIXED Unit tests are testing the behaviors, Integration tests are for checking integration, i.e. technology touching points Separate the code having domain logic from the code interacting with other technologies. That helps us to keep the behaviors together and prevent technology complexity leaks into domain. Then it is far easier to test behaviors with unit tests having all the components composing the behaviors. fl

Start designing the app from designing the database DB model is the hardest part of software to refactor. The earlier we design, the less need to refactor. Data model guides domain model, and domain model guides customer contract.

FIXED Start designing the app from customer perspective, database design is the last step of all Start from where you can afford deletion and total rewrites, db is not the best place for it Separate data model should be derived from the domain model

I am a programmer, not a payment specialist Domains can easily be learned and adapted. Focus on technologies, tools and languages and that leads to a better developer. No one asks me how 3DS payment happens, they ask me how Spring executes transactions Being a full-stack developer is my goal learn little little in the middle

FIXED Know your domain well We need more domain experts than technology experts in sector. Only the ones who knows the domain well can create proper solutions that really solve a problem. Else you do only the fi rst solution comes to your mind. every domain has its own challenges like, scalability, performance, infra, bounded contexts, complex business flows

GitFlow is great for managing the features, hot fi xes and releases Merge feature branches to develop branch to let it be tested, and deployed to environments Slow down the merge pipeline to have more controlled fl ow of development.

FIXED GitFlow is for teams having long release cycles Trunk based development is for the others The teams doing frequent releases need no branching model. Main branch is enough to keep the veri fi ed changeset of the next release and tags are right there to mark the deployed commits to environments. trust your team, guarantee quality by pairing, having test suite, etc.

SOLID principles are about writing clean code using OOP These are the principles that we should follow during development even though I only know the full name of SRP and OCP.

FIXED SOLID is a guideline, usually have real value while reviewing the written code SOLID Principles are about managing dependencies and can be applied in any paradigm Solid is about preventing software from being rot from uncontrolled dependencies by separating concerns. Solid is about limiting the impact of change by making the code easy to change and keeping it backward compatible. Reference: https://speakerdeck.com/lemiorhan/it-is-not-solid-anymore https://speakerdeck.com/lemiorhan/solid-is-dead-long-live-solid

DDD is an overkill at the beginning and too much effort after the start DDD can be done by experienced developers knowing the domain well in no-deadline conditions. DDD is like doing big up-front analysis by doing many meetings

FIXED DDD is about thinking on the problem before jumping into (premature) solution DDD lets you understand the business problem and propose solution with all parties involved. That leads to the correct solution. It does not guarantee the solution is coded well. imposes domain level thinking and eliminates object myopic

FIXED DDD is about sustainable growth of building software regardless of its size It is an holistic approach for understanding, designing and building software applications. It does not dictate an architecture style and the layered approach. DDD can be used along with any other software architecture.

Doing Scrum by the book is crucial for happy customers, good product and high-performance team If your organization structure, communication style, team formation or rituals do not fi t Scrum, change them.

FIXED Customers do not care what you do. There is no formula for success. Find your own model. Customers don’t care whether you do Scrum or Kanban, whether you run sprints or estimating story points. Customers care about the product or solution you deliver. Reference: https://speakerdeck.com/lemiorhan/pure-agile-building-a-culture-without-scrum-kanban-and-xp

We cannot adapt engineering practices in the team if the team is not capable of It’s about people and their motivation to change the way they work. No matter how you are eager to write tests, if the others do not like or capable of it, tests won’t be written. like code review, pair programming, automated testing

FIXED When what you are doing is a project, main goal is catching deadlines. Building a product change the rules. Building a product requires to achieve sustainable growth and continuous customer satisfaction. Therefore quality has always been the main goal.

Mono-repo- fi rst strategy Deploy to production early and often, even start from the fi rst days Microservice is a deployment strategy, modularity is for sustainable growth Write enough number of tests till you feel comfortable to deploy to production Pull Requests are the least ef fi cient technique for reviewing change sets Unit tests are testing the behaviors, integration tests are for checking integration Start designing the app from customer perspective, database design is the last step of all Know your domain well GitFlow is for teams having long release cycles, trunk based development is for the others SOLID Principles are about managing dependencies and can be applied in any paradigm DDD is about sustainable growth of building software regardless of its size Customers do not care what you do. There is no formula for success. Find your own model. 1 2 3 4 5 6 7 8 9 10 11 12 K EY TA K EA W AYS

THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: [email protected]

THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: [email protected]