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. 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
  2. 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.
  3. 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
  4. 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?
  5. 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
  6. 16.

    Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice

    Microservice Microservice Microservice Microservice Read-only Multi Repositories splitting
  7. 17.

    Microservice Microservice Microservice Microservice Microservice Microservice Mono Repository Microservice Microservice

    Microservice Microservice Microservice Microservice Read-only Multi Repositories packaging & deployment splitting
  8. 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.
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 31.
  14. 32.
  15. 33.

    Sebastian Daschner from his talk about “Design principles for the

    effective developer” at Devoxx Ukraine 2019
  16. 34.
  17. 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
  18. 37.
  19. 38.
  20. 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
  21. 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?
  22. 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
  23. 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
  24. 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
  25. 47.

    If you want to go fast, go African Proverb If

    you want to go far go alone together
  26. 48.

    If you want to go fast, go Software Development Proverb

    If you want to go far go with pair with mob
  27. 49.
  28. 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