Fixing the Typo in Softvare Devlpment

The points I mentioned are the ones TI totally changed my mind 20 years later.

Transcript

1. 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
2. LEMi ORHAN ERGiN lemiorhanergin.com @lemiorhan software crafter, coding since 2001 co-founder @ Craftgate the community guy @ Software Craftsmanship Turkey 21 years of blood and tears ;) current mood CRAFTGATE one-stop shop payment hub payment gateway for your poses with dynamic pos routing, you always pay the lowest commission to banks craftgate.io @craftgateio with fraud detection and autopilot pos monitoring features
3. 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
4. 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:
5. 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
6. Works for me does not mean works for you. It depends! And vise versa. be aware of survival bias
7. 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
8. FIXED Mono-repo-first 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
9. FIXED 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 restricting repo access to a specific team is a smell most of the time
10. 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
11. FIXED Deploy to production early and often, even start from the first days Focus on integration tasks first. Build CD pipeline from the first day. Early creation of deployment pipeline shortens the development and feedback cycles dramatically.
12. FIXED 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. feature toggles generate waste, so use it carefully
13. 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.
14. 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.
15. 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)
16. 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
17. 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
18. FIXED Pull Requests are the least efficient technique for reviewing change sets Pull Requests are efficient if you have specific 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
19. Unit tests are for testing methods, integration tests are for testing the flow Since unit tests fail all the time during development, it is safer to write integration tests only to validate the business flow Unit tests are for validating algorithms and mature logics
20. 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.
21. 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.
22. 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
23. 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
24. 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 first solution comes to your mind. every domain has its own challenges like, scalability, performance, infra, bounded contexts, complex business flows
25. GitFlow is great for managing the features, hot fixes 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 flow of development.
26. 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 verified 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.
27. 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.
28. FIXED 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 SOLID is a guideline, usually have real value while reviewing the written code
29. 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
30. 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
31. 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.
32. 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 fit Scrum, change them.
33. 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.
34. Mono-repo-first strategy Deploy to production early and often, even start from the first days Microservice is a deployment strategy Write enough number of tests till you feel comfortable to deploy to production Pull Requests are the least efficient 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
35. THANK YOU FOR SHARING YOUR TIME WITH ME speakerdeck.com/lemiorhan twitter.com/lemiorhan lemi orhan ergin co-founder, craftgate mail: lemi@craftgate.io