Think component!

Stop writing complex code. Thinking with components can help you think complex but write simple, and pursue a sane practice of software writing.

Transcript

1. pursuing a sane practice of software writing Think component! Xavier Olive February 28, 2015 https://github.com/xoolive cba
2. a case study Say you want to write an app for ▶ taking pictures, ▶ applying filters on them, ▶ pinning the images on a map based on GPS data, ▶ and sharing them on social networks. 1
3. some like it with classes Image + Image(Camera) + applyFilter(Filter) + getDate() + getPosition() + publish(…) User + login() + getImages() + getFriends() SocialNetworkConnection + authenticate(User) + publish(Image) Filter + apply() SepiaFilter + apply() etc. CropFilter + apply() Camera + acquire() Position + getLatLon() + getDistance() Map + addPosition(Position) + display() friend Disclaimer: this class diagram is mostly wrong because of missing attributes, missing cardinalities, lack of clarification between aggregations and compositions, missing filters, missing specialisations for various social networks, etc. 2
5. a different picture API Control the camera Access world maps Publish to … Tools images filters geodesy design, storage, etc. 4
6. the limits of object-oriented programming ▶ OO programming refers to a mental model of the actual or imagined objects it represents, and of their interactions. ▶ Albeit a valid paradigm, it reaches limits as your project grows. ▶ Component-based design recommends to build complex systems by assembling largely cohesive loosely coupled components. ▶ Design components the way you like. Nothing matters but the interface. 5
7. components
8. specificity and genericity A component shall offer a specific service. You can explain what it does in few seconds/few words. If it can do many things, it is most likely not a component! A component shall yield a significant output from a minimal input. A component shall address specific needs without any adaptation. 7
9. robustness A component shall “behave” when it is used in unexpected ways. A component shall handle erroneous inputs, unexpected behaviour. A component shall be rigorous about versions and dependencies. Comprehensive testing 1 and benchmarking are considered good practice. 1 Understand unit testing, integration testing, input validity testing 8
10. performance Run after one hare for every component you work on. Hide your hard work and smart optimisations to the end user. You should be able to redesign/replace each component at a minimal cost. Don’t get misguided by the premature optimisation issue ✓ Be aware of what things cost. Complicated design often ends up missing the point. 9
11. interfaces
12. keep it a black box You get to choose what does not matter: ▶ the programming paradigm; ▶ the programming language; ▶ the elements of design; ▶ the pace of deliveries; ▶ the guy for the job; and may change your mind at any time. Interfaces do matter Start writing a readme, and a test case describing how people will make use of your component. 11
13. Sane practice from day #1 Give your data model a break Work on your interfaces NOW 12
14. work on your interfaces People willing to use your code will first look at how to call it. Avoid exposing your data model outside your component. Choose generic types, generic return codes, generic exceptions. Stop writing classes! 2 2 Check this talk [here] 13
15. A component wraps complex things and interfaces make it look simple. 14
16. a remarkable component grep ▶ A command line tool for filtering lines matching a pattern. ✓ Parses files or stdin, writes on stdout, Supports regular expressions ✓ grep does not need to read the whole input, without you needing to know it! 3 3 Check this video [here] 15
17. a remarkable component numpy ▶ Brings the performance of C arrays to Python. ✓ Totally transparent, you don’t need to know C. ✓ You can transform Python arrays to numpy arrays, and access numpy arrays as if they were Python arrays. 16
18. click, boom, amazing!
19. click, boom, amazing! Keep it simple, keep it beautiful! You provide a service, not extra pain! Questions to ask before delivering: 1. Is it simple to install? (or access for a web app) 2. Is it simple to use? 18
20. documentation People should have a way to see how the component behaves before installing it. There are lots of fun ways to write documentation ▶ Write a readme; ▶ Write a blog post; ▶ Prepare an iPython notebook 4; Do you know how to write man/help files? Do you know how to feed the Help menu of your application? 4 Also available for other languages, check [here] 19
21. add a license file Choose a license and name it 5 Decent people do care, and you should care too. No license is not an option. “Do whatever you want” is an option. Just say it! Check the MIT license if you want it simple and permissive. 5 Have a look at http://www.choosealicense.com 20
22. compilation Most people don’t know what it means. Lots don’t want to hear about it. Provide compiled versions for most architectures. If compilation must be performed on the user side, make it painless. Adopt a no questions asked policy But provide explicit error messages if things fail. 21
23. the importance of a package manager Have a place to store your components. Have a tool to install them and take care of your dependencies. Commonly used package management systems ▶ Python: pip (virtualenv helps), also conda; ▶ OCaml: opam / findlib; ▶ Ruby: gem / bundler; ▶ LaTeX: ctan; also Firefox add-ons, Linux repositories, etc. 22
24. my piece of advice
25. get familiar with command line tools OS are a great reference for remarkable design. All command line tools are remarkable examples of components, abiding by the Unix philosophy: 6 ▶ Write programs that do one thing and do it well; ▶ Write programs to work together; ▶ Write programs to handle text streams, because that is a universal interface. 6 Check this article [here] 24
26. publish your work Publish some of your most harmless components! 7 Respect intellectual property of others. Don’t publish others’ work without their permission. If you are concerned about money, publishing a compatible open version with degraded performance can be a strategy. 7 You may want to consider https://github.com/ 25
27. bright sides ▶ You get a reason to work on your interfaces and documentation. ▶ You get a reason to push yourself and show off your best. Hide your complex work, show how simple it really is. ▶ You harvest the benefits of your discipline for your own projects. ✓ You may even expect feedback. 26
28. conclusion
29. my bucket list ▶ Don’t be dogmatic 8 A lot of great software does not abide by your bottom lines, and it should not affect your mental health. ▶ Write code every day Practice makes better, which is already a lot! ▶ Write every day It’s all about human language in the end. 8 Read “Don’t be an ass” 28