Look ma, No Frameworks - JBcnConf 2015
0 likes3,628 views
This document discusses the downsides of frameworks and provides alternatives. It argues that frameworks can do too much and constrain choices. Alternatives proposed include defining an architectural style or vocabulary, following a risk-driven design process, and documenting relevant elements of the system in a meaningful way. The key is to write programs that do one thing well and work together through well-defined interfaces, rather than relying on large frameworks.
Look ma, No Frameworks - JBcnConf 2015
- 1. Look ma, No Frameworks Pablo Chacin
- 2. Motivation So, you are a Java developer? What frameworks do you use? I don’t use any framework
- 3. What’s wrong with frameworks? This is not (only) a rant against frameworks, but an analysis of the consequences of using them and a proposal for alternatives.
- 4. Frameworkitis “Is the disease that a framework wants to do too much for you or it does it in a way that you don't want but you can't change it” Erich Gamma
- 5. “We might have been able to use Ruby on Rails. But It also adds a bunch of requirements for stuff you then have to write so everything will work nicely with your framework” Node at LinkedIn: The Pursuit of Thinner, Lighter, Faster Unneeded Stuff
- 6. Easy Yet Complex “Many complicating constructs are easy to use. However, what matters is the complexity they yield. And such complexity is incidental to the problem” Rich Hickey, author of Clojure
- 7. Power Requires Discipline “And because you stand on the shoulders of giants, you can accomplish something quickly. You don’t even know exactly what you have done.” Dr. Ian Malcolm
- 8. Restriction in Choices “Why did I leave .NET? In short, it constrained our ability to choose and turned our focus towards safety instead of helping us experience all of the possibilities out there” Jonathan Oliver, Why I left .Net
- 9. Design as Learning “While we all need to write code that others can use and maintain, I hope part of that process involves trying to increase our collective knowledge” James Coglan
- 10. “How do you teach magic to junior developers?” Greg Young, 8 lines of code The Problems with Magic
- 11. Why Agile Development won’t help “Software gets about 10x bigger each decade. So while our attention has been focused on fixing process problems, our software got an order of magnitude bigger. In my opinion, it's time to turn our attention back to design.” George Fairbanks, Just Enough Software Architecture
- 12. Hints for a Solution Create a vision Follow a risk driven design process Document relevant elements in a meaningful way
- 13. Define your Style Provide a vocabulary to describe your system and reason about its properties.
- 14. Unix’s Pipe Style Write programs that do one thing well and work together by handling text streams as a universal interface.
- 15. The problem with styles Msg. Passing EventsPipes Micro Services (a.k.a SOA) OOP
- 17. Follow a Risk-Driven Process Identify risks due to project, team, or technology factors Architect until main risks are covered
- 18. Risk storming Technical risk (failures, data inconsistency, incompatibilities, ...) Stakeholder’s concerns (cost, time, performance,...)
- 19. Architecturally-Evident Code Close the model- code gap by adopting an architecturally- evident coding style, embedding in code hints about design intent
- 20. Conclusions “Life is pain. Anyone saying differently is selling something” Iñigo Montoya
- 22. Acknowledgements 1. Keep calm.., source: http://www.keepcalm-o-matic.co.uk/ 2. Iñigo Montoya, source http://velvetgeek.com/ 3. Architecture Documentation, Code naming example, source http://www.codingthearchitecture.com/ 4. Risk Storming, source http://www.doyoubuzz. com/michael-keeling/cv/blog 5. Node at LinkedIn: The Pursuit of Thinner, Lighter, Faster, source http://queue.acm.org/detail.cfm?id=2567673