Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à The Fundamentals of Continuous Software Design
Similaire à The Fundamentals of Continuous Software Design (20)
Dernier
Dernier (20)
The Fundamentals of Continuous Software Design
- 1. The Fundamentals of Continuous Software Design May 9th, 2020
- 2. About Me • Senior Architect at Calavista Software • (Mostly) Agile since 2003 • http://jeremydmiller.com • shadetreedeveloper@gmail.com • @jeremydmiller
- 4. Scrum
- 5. DeliveringValue WORKING SOFTWARE BUILDING FEATURES BY BUSINESS PRIORITY CONTINUOUS DELIVERY
- 6. Between Scylla and Charybdis Big Design Upfront (BDUF) No Upfront Design
- 7. What is Continuous Design? • Roots in Extreme Programming • “Evolutionary” or “Emergent” Design • Requires a High Degree of Discipline • Reacting to Feedback
- 8. Design Goals • Don’t Repeat Yourself • Explicit • Simple • Cohesive • Decoupled • Isolated • In the present
- 9. Pull vs Push • Build it and they will come • “You aren’t going to need it” – YAGNI • Do the Simplest Thing That Could Possibly Work
- 10. The Last Responsible Moment Make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision.
- 11. Reversibility “If you can easily change your decisions, this means it’s less important to get them right – which makes your life much simpler. ” Martin Fowler
- 12. Low Reversibility Plumbing through a slab foundation of a house under construction
- 13. Examples of Low Reversibility • Dependencies on External Organizations • Choosing Client Technologies • Basic Code Organization Strategies • Programming Languages • Architectural Patterns
- 14. Examples of High Reversibility • ASP.Net Core Middleware (The Russian Doll Model) • Document Databases • Effective Automated Test Coverage • Modular Code
- 15. Testability andTDD/BDD • Enables Refactoring • Feedback • Improves Reversibility • Heuristic to improve the low-level design of your code
- 16. “Jeremy’s Laws ofTDD Design” • Isolate the Ugly Stuff • Push, Don’t Pull • Test Small Before Testing Big • Avoid a Long Tail
- 17. Refactoring A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior Lies, damn lies, and “it’s just going to be some refactoring”
- 18. Bottom Up vsTop Down Design Avoid being frozen by the fear of what you don’t yet know Bottom Up start with individual tasks and assemble the coded elements later as a structure presents itself Top Down start with the basic workflow, leave placeholders for individual steps later
- 19. Spike • “A very simple program to explore potential solutions” • Quick and dirty prototyping • Throwaway the code
- 20. Process Stuff • Constantly challenge the design • Always be thinking • Socialize the design • Every developer contributes
- 21. Questions?
Notes de l'éditeur
- Heuristics, no prescriptive guidance. All about thinking through problems
- ”Get off my lawn!” Extreme Programming might have been a good thing going, but Scrum swept in. The potential problem with Scrum is that it focuses almost completely on projection management. “Agile” became associated with performative ceremonies like daily standup meetings, sprint reviews, and sprint planning
- ”Get off my lawn!” Extreme Programming might have been a good thing going, but Scrum swept in. The potential problem with Scrum is that it focuses almost completely on projection management. “Agile” became associated with performative ceremonies like daily standup meetings, sprint reviews, and sprint planning
- What’s important is your ability to continuously work on business priorities. Eliminates the possibility of upfront architecture phases or sprints. Puts a lot of stress on technical teams to deliver functionality and initial architectural work upfront. Requires us to put off structural elements for later. Puts an onus on the code structure to allow for later extension without too much rework. Talk about being late and having the entire database and data layer constructed, vs being late but having half the features completely deployable. Talk about the construction metaphor
- Worst failures
- Deciding when to decide, reacting to feedback. Requires a lot of feedback cycles, and there’s what XP really was