Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Fixing the Typo in Softvare Devlpment

Fixing the Typo in Softvare Devlpment

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

Lemi Orhan Ergin

October 15, 2022
Tweet

More Decks by Lemi Orhan Ergin

Other Decks in Technology

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

    View Slide

  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

    View Slide

  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

    View Slide

  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:

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

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

    View Slide