10 Exclusive Development Practice Every Developer Should Consider

10 Exclusive Development Practice Every Developer Should Consider

These are the slides I presented at DevFest Istanbul 2019 Conference

Dafc4723e9a1c067796c0fec6f509774?s=128

Lemi Orhan Ergin

November 24, 2019
Tweet

Transcript

  1. every developer should consider lemi orhan ergin 10 exclusive development

    practice
  2. LEMi ORHAN ERGiN co-founder, Craftbase founder, Software Craftsmanship Turkey alumni,

    Sony, eBay, ACM, iyzico programming, since 2001 with love speakerdeck.com/lemiorhan @lemiorhan
  3. Something is wrong in software development

  4. we are not developers anymore, we are framework implementers

  5. high coupling and low cohesion makes impossible to write tests

  6. we are afraid of refactoring even with a comprehensive test

    suite
  7. rework is inevitable even the development is already done

  8. we write unit tests, but functionalities still fail

  9. Start with a mono-repo 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.
  10. Clear ownership for each repo Possible to restrict access for

    each repo Lightweight repository, narrow clones Independent upgrade & versioning strategy Manage like open source applications Multi Repository System Cross repo changes and refactorings are painful Adds overhead if one team handles multiple repos Need to open multiple IDEs to write code Need to manage versions of many small libraries Need to pull changes on many repos
  11. All about moving fast and getting things done Enables experimenting

    cross-project More relevant pull requests & commits Cannot restrict to access for specific projects Low flexibility of dependency upgrade Needs special tooling for building Usefulness of tags diminishes Mono Repository System Easier to navigate on sourcecode Unified versioning, one source of truth You don’t need to define version numbers Easy cross-project refactoring Update dependencies to latest overall No wasting time with multiple git commands Increase developer productivity Twi!er, Facebook, Google, Digital Ocean, Foursquare, Etsy, Shippable, Ravelin Who migrated from multi to mono repositories?
  12. You can not do CI without using mono-repos Ivan Moore

  13. You can not do CI without using mono-repos Ivan Moore

    B C A unit tests integration tests component tests contract tests external verifier contract stub tests functional tests
  14. Demo Time: Special Tooling with Gradle

  15. Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice

    Microservice Microservice Microservice Microservice
  16. Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice

    Microservice Microservice Microservice Microservice Read-only Multi Repositories splitting
  17. Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice

    Microservice Microservice Microservice Microservice Read-only Multi Repositories packaging & deployment splitting
  18. Demo Time: Sparse Checkout

  19. Using microservices when you are not prepared

  20. Start with monoliths If you have no experience with building

    microservices at production, it could be a nightmare if you jump into it. Microservices requires to have devops culture, agile mindset and a new paradigm for software development. So be pragmatic.
  21. HELL DEPENDENCY OF MICROSERVICES

  22. Focus on modularity If you cannot develop well-crafted monoliths, how

    can you be sure you can build well- crafted microservices? Make your architecture clean and modular by following related design patterns and principles. Make your monolith well-crafted first. Then if you need to scale, split it to microservices.
  23. https://twitter.com/martinfowler/status/606096712969633794 Martin Fowler Author, speaker, and general loud mouth on

    Software Development. Works for ThoughtWorks. posted: the monolith-first strategy to building microservices (or not) Martin Fowler @martinfowler 4:54 PM · Jun 3, 2015
  24. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

  25. Image Credit: Benoit Hediard, https://medium.com/@benorama/the-evolution-of-software-architecture-bd6ea674c477

  26. ports business adapters mysql adapter stripe adapter rest api web

    ui domain
  27. ports adapters domain 3rd party apps command line soap calls

    admin gui batch jobs mobile apps other hexagons cache provider elastic search mail server database sms provider message queue other hexagons business mysql adapter stripe adapter rest api web ui
  28. ports adapters notification payment billing order basket restaurant scheduling caching

    search mail account messaging stripe adapter rest api mysql adapter web ui domain business
  29. Hexagons in practice

  30. domain infra

  31. None
  32. None
  33. Sebastian Daschner from his talk about “Design principles for the

    effective developer” at Devoxx Ukraine 2019
  34. None
  35. Let it shaped with Domain Driven Design

  36. ports adapters notification payment billing order basket restaurant scheduling caching

    search mail account messaging stripe adapter rest api mysql adapter web ui domain business
  37. None
  38. a SEARCH

  39. a c SEARCH PAYMENT

  40. c a SEARCH PAYMENT ACCOUNT

  41. Walking Skeleton First release delivers an extremely small, but functional,

    initial version of your system. Once the skeleton of the system is in place, we have various places where we can start fleshing out functionality - putting meat on the bones. from the book “Growing Object-Oriented Software, Guided by Test” Deploy to production early and often, even start from the first sprint Focus on integration tasks first Build CD pipeline from the first day
  42. Release and deploy code to prod multiple times a day

    Trunk Based Development lets you release multiple times a day. But it is a long journey to complete. do you really need that?
  43. Weekly Releases STEP-1 Multiple Releases in a Day STEP-3 Daily

    Releases STEP-2
  44. Daily Releases STEP-2 Multiple Releases in a Day STEP-3 Using

    Git-Flow Everyone codes individually No/few tests, huge manual test cost CI server used for building packages Weekly releases at best Manual deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Developed & tested at local
  45. Multiple Releases in a Day STEP-3 Master-Feature branching Active Pair

    programming Have a test suite CI server runs tests for validation Daily releases at best Pull requests for code review Automatic deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Deployed to pre-prod Using Git-Flow Everyone codes individually No/few tests, huge manual test cost CI server used for building packages Weekly releases at best Manual deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Developed & tested at local
  46. No branches, just master Feature flags Active Mob programming Have

    a elegant test suite Multiple releases per day at best No pull requests Each commit is deployable On-demand env. at each merge Automatic deployment to pre-prod Automatic acceptance testing Manual deployment to prod DoD: Deployed to prod Master-Feature branching Active Pair programming Have a test suite CI server runs tests for validation Daily releases at best Pull requests for code review Automatic deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Deployed to pre-prod Using Git-Flow Everyone codes individually No/few tests, huge manual test cost CI server used for building packages Weekly releases at best Manual deployment to pre-prod Manual functionality testing Manual deployment to prod DoD: Developed & tested at local trunk based development
  47. If you want to go fast, go African Proverb If

    you want to go far go alone together
  48. If you want to go fast, go Software Development Proverb

    If you want to go far go with pair with mob
  49. One driver, many navigators Switch the keyboard regularly At least

    half a day in every week Mob Programming
  50. 1. Start with mono-repository 2. Mono-repo splitting for easy CD

    pipeline 3. Advanced tooling with Gradle 4. Sparse-checkout for dealing with fewer files 5. Start with a monolith 6. Hexagonal architecture for modular monoliths 7. Mob programming 8. Trunk based development 9. Deploy to production from the first sprint 10. Release and deploy to production multiple times a day
  51. @craftbaseio craftbase.io LEMi ORHAN ERGiN @lemiorhan