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
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:
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
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
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
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
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
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.
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
need to decompose business domain into smaller, consistent, bounded contexts Microservices should be small enough obeying the Single Responsibility Rule.
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.
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)
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
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
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
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
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.
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.
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
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
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
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.
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.
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
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
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
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.
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.
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
lemiorhan
kkamegawa
naitosatoshi
ma3tk
biwashi
blue_goheimochi
tomu28
ks91
danielbryantuk
lycorptech_jp
maroon1st
yasumuusan
holman
kevinliebholz
shlominoach
jakevdp
revolveconf
marcduiker
matthewcrist
kastner
moore
zenorocha
pedronauck
pauljervisheath
