Recommandé
Contenu connexe
Similaire à Writing Frameworks for Fun and Profit
Similaire à Writing Frameworks for Fun and Profit (20)
Dernier
Dernier (20)
Writing Frameworks for Fun and Profit
- 1. Writing a framework for fun @jhugman – James Hugman
- 2. Not him again • Software Engineer in industry for 10y+ • Written: • Compilers, Reasoning Engines, ETL systems, evolutionary algorithms, cross-platform mobile frameworks @jhugman
- 3. Contents • Why should I care • Words shape thought • Rules for enablers • Developers are users too @jhugman
- 4. Anti-Contents • A specific technology • The importance of encapsulation • An exhaustive list of anything @jhugman
- 5. Why should I care? Why would I want to write a framework? @jhugman
- 6. Your role changes • Tool user • Tool maker @jhugman
- 7. @jhugman Status
- 8. Architect @jhugman Status
- 9. What happens at @jhugman work…
- 10. What happens at @jhugman work…
- 11. @jhugman It feels like…
- 12. @jhugman It feels like…
- 13. Words Shape Thought Identifiers, Little Languages and Patterns @jhugman
- 14. Words shape thought • Find language that describe the concepts • Break concepts into smaller nouns & verbs @jhugman
- 15. Words shape thought • Make your code out of this language e.g. identifiers • Build your code bottom up @jhugman
- 16. Words shape thought • Over-generalizing is double-plus- ungood • process() • apply() • execute() @jhugman
- 17. Words shape thought • Wrong words require double-think @jhugman
- 18. Why Language Matters • Thought-to-code gap • More readable code • Better intra-team communication • Bugs are harder to write @jhugman
- 19. Other People’s DSLs • Integrate existing little languages with your framework • e.g. SQL, XPath, Javascript • Design patterns provide a vocabulary @jhugman
- 20. Definitional Interlude • Framework vs Toolkit (Hollywood Principle) @jhugman
- 21. Extendable systems Architect like you have a plugin mechanism @jhugman
- 22. Plugin systems • Modularity above the package level • Assume you have a plugin system, even if you don’t @jhugman
- 23. Rules for Enablers • Invitation Rule – Whenever possible, let others contribute to your contributions • Fair Play Rule – All clients play by the same rules, even me. • Explicit Extension Rule – Declare explicitly where a platform can be extended. • Diversity Rule – Extension points accept multiple extensions. @jhugman
- 24. Rules for Enablers • Explicit API Rule - separate the API from internals. • Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it. @jhugman
- 25. Architect for Participation • Requirements change, new features added • Multiple uncoordinated teams can work concurrently • Plugins limit negative impact of change • Containment of unpredictability @jhugman
- 26. Example Architecting for growth @jhugman
- 27. House Numbers • Physical world example • A street, where houses will be • How should we number the houses @jhugman
- 28. House numbers •Sequential •Row at a time •Simple at 1 2 3 4 build time road •Not 5 6 7 8 extendable •Not very navigable @jhugman
- 29. House numbers •Sequential •Odds/Evens •Extendable in 1 3 5 7 one direction road •Assumes no 2 4 6 8 space between houses @jhugman
- 30. House numbers •Distance from one end •Large scale 10300 17010 •Navigable road 15705 •No fixed 19010 construction order @jhugman
- 31. Developer UX Developers are users too @jhugman
- 32. Developer pain kills • Everything should be obvious • A good mental model @jhugman
- 33. API Usability • Design APIs upfront (almost BDD for APIs) • Seek feedback from real developers • Prototype, review, iterate @jhugman
- 34. Related • Paper prototyping • README driven development • Commit-log driven development @jhugman
- 35. Summary • Words shape thought • Build in extensibility, early • Think hard about developer experience @jhugman
- 36. Further Study • Graduates/Juniors: • Effective Java Josh Bloch • Huston Design Patterns (a website with GoF patterns) • Programming Pearls Jon Bentley • Pragmatic Programmer Andrew Hunt & Dave Thomas • @jhugman
- 37. Further Study • Principles of Newspeak George Orwell • Growing a Language Guy Steele • The Art Of War Sun Tzu • Unwritten Rules Of Engineering Skakoon & King • Developer UX @jhugman
- 38. Podcasts • Java Posse • this developer’s life • Hacker News Pod • Software Engineering Radio @jhugman
- 39. Thanks @jhugman – James Hugman @jhugman
- 40. Discuss AMA @jhugman
- 41. @jhugman
Notes de l'éditeur
- \n
- \n
- This is not just about encapsulation.\n
- This is not just about encapsulation\n\n I’ve learned over my career, distilled into an early morning talk.\n
- \n
- \n
- * Day-to-day: Tool-user --> Tool maker.\n * Status/Prospects: Jobbing builder --> Architect\n * Type of work: Soldier --> Scientists.\n * How I feel: Soldier ant --> Really Happy Dolphin\n
- If status is all you care about, we have a different problem.\n
- \n
- \n
- \n
- \n
- \n
- Notice this is quite top-down. But we can do this for even low-level sub-systems.\n
- Find language that describes the concepts of what you're doing.\nMake your code out of this language. \nNever settle for the over genral. process() apply() execute() doStuff() giesPeas()\nBreak down the concepts into smaller nouns.\nName your identifiers to follow this.\nBuild little languages.\n
- Never settle for the over general. process() apply() execute() doStuff() giesPeas()\n\nNewspeak joke\n\n
- When identifiers and concepts are not closely matched, you need to have two different (and perhaps conflicting) ideas in your head at once.\n
- Using the right words\n\nBugs are harder to write because\n * tests are easier to write, \n * the code is more readable.\n\nThis can apply to any layer of abstraction.\n
- Design patterns are explicitly designed to provide a shared vocabulary\n\nIntegrate: you don’t have to re-invent everything.\n
- Now we know the importance of words :)\n
- There are some technical differences between extensions, modules, plugins extension points\nbut I don’t want to go into them here.\n
- \n
- These changed my code style. Overnight.\n\nEspecially the Fair Play Rule - I have to expose enough API to build the system.\n
- \n
- Open beats closed.\n
- We’re inviting extensions into our framework.\nNeither the framework or the extension know what order they are going to be built.\n
- \n
- Fixed size housing\nNot extendable.\n
- Assumes:\n * no space between houses\n * fixed sized houses\n * house build order is fixed\n \n\n
- House number determined by 10s of meters from one end. (e.g. Melbourne to Adelaide)\nNo assumption of a house building order. \nHouses can be as big or small as you want.\n
- \n
- Principle of least surprise, \nEvery roadblock is an opportunity not to use your framework, or hate you, or both.\n * Installation\n * Common use-cases should be bug free.\n * Documentation\nMental model (i.e. the model of your framework in the user’s mind):\n * re-enforced by a clean API\n * does not need to bare any relation to the implementation. \n * a non-leaky abstraction.\n
- \n
- \n
- This is not just about encapsulation.\n
- Patterns should be on here, but I’m assuming this is a university book\n
- \n
- \n
- \n
- \n
- \n