Code Hygiene: Lessons from Scala
- 1. Code Hygiene: Lessons from Scala Hila Noga CTO @ Hello Heart
- 2. A story about language adoption
- 3. Why Scala? Runs on the JVM, supports Java libraries Statically typed, combines functional and OOP styles and all that jazz Productive Fun All our brilliant friends loved it
- 4. A perilous Journey Steep learning curve Learning new ways to think is HARD! Not enough guidance, we learned as we went The result?
- 5. Some pretty ugly code in our codebase!
- 6. Scala: The good, the Bad and the Dirty
- 7. The good: It gives you all the toys
- 8. The bad: It gives you all the toys
- 10. The dirty?
- 12. “An expert is a man woman who has made all the mistakes which can be made, in a narrow field.” Niels Bohr
- 13. Coding is an exercise in reading comprehension You spend more time reading code than writing code Code should be written in order to be read So it should be clean and self-documenting
- 14. Clean up your mess!
- 15. Coherent what?! Scala gives you a million valid, good and simple ways to do the same thing. You might think that’s a good thing...
- 16. The zoo example Because what is a lecture without some silly code examples...
- 17. Error handling
- 18. Error handling
- 19. Error handling
- 20. Error handling
- 23. Async computation This can get busy quickly if you have many levels of nesting...
- 25. Which should you use?!
- 26. Async computation and error handling with futures
- 27. Lesson: Have a convention Follow the rule of least surprise Prefer a convention that’s easy to read and understand Prefer small functions that do one thing and have meaningful names Have a training plan
- 28. Refactoring is Magic You always learn new things. Unless you are dead. Leave every place you visit a little bit cleaner than the way you found it. How can you do it without fear?
- 29. Lesson: Write testable code, and TEST IT! Keep testing in mind when writing your code Small functions with no side effects are easy to test
- 30. We use ScalaTest Example shamelessly stolen from the Scala Test website
- 31. A less obvious point...
- 32. Use the type system to make things explicit
- 33. Use the type system to make things explicit
- 34. Use the type system to make things explicit
- 35. Use the type system to make things explicit
- 36. Use the type system to make things explicit Now if you do something illegal, your code won’t compile
- 37. Lesson: Let your compiler help you Make your assumptions about the code explicit Make your code self- documenting Catch errors early Why wouldn’t you?!
- 38. Into the lion’s den
- 39. Compare this: Quick! What does this code do? So much information you just.don’t.care about in here!
- 40. To this: Wait... Can we improve this?
- 41. A bit of magic:
- 42. So much easier on the eyes!
- 43. Lesson: The right level of abstraction creates expressive code The code is the best system documentation It should read like a story of what the system does
- 44. Lesson: You CAN have too much of a good thing
- 45. OMG! It’s almost as if it’s a coherent worldview!
- 46. “Clean code always looks like it was written by someone who cares” ~ Michael Feathers
Editor's Notes
- #2: Hila Noga CTO at Hello Heart A startup that helps people with high Blood Pressure and other heart-related medical conditions understand and engage with their health. Now, it turns out that engaged patients tend to heal better than disengaged one - so we are really proud of what we do. I came here today to tell you what I learned about clean code after 4 years of working with Scala
- #3: And I want to start by telling you the story of how we adopted Scala As I said, I am the CTO of Hello Heart but I didn’t start as a CTO, Started as a developer, first task in Hello Heart was to write our server code in Scala
- #4: We chose Scala because of all sorts of reasons that seemed good at the time like The fact that we come from the Java world and felt comfortable with the Java ecosystem and technologies Static typing (I’m strict like that), functional Productive All the cool kids love it “OMG, you must use Scala, you will love Scala, you must use it!”
- #5: Adopting Scala hasn’t been an easy journey One of the reasons is that Scala is a language with a learning curve so steep it’s practically a wall OOP -> Functional (new way of thinking) No guidance
- #6: Learning as we go - some pretty ugly code in our codebase You could say that about many languages, but Scala has some special properties that make it extremely problematic in that respect
- #7: Love it as a developer (amusement park for software engineers). Still undecided as a CTO Reason: It’s a mixed bag
- #8: Whatever you want - scala has it! Functions? Objects? No problem! Implicits? For sure! Static typing? Duck typing? Type parameters? Traits? You got it! Funky syntax? Symbolic names? Brackets? Semicolons? Dots and marks galore? It’s all there! Use it or don’t - the language doesn’t care Glorious pieces of code, the language will not limit you in any way
- #9: Then there’s the bad thing about Scala, which is that it gives you all the toys
- #10: With certain programming languages favoured in big enterprises - can’t do anything too good, but can’t do anything too horrific either Which is a good thing in certain settings (saying as a CTO, would have been really angry if someone said it to me as a developer) No people running rampant and being creative with their programming Reasonable, working code written at a reasonable pace Not too good but not too bad either Easy to find people that can maintain it
- #11: But in Scala, if you don’t know what you are doing (or, sadly, if you know too much for your own good) You can shoot yourself in the foot, and that’s bound to get messy
- #12: WTF, Scala, Seriously?! All this features mean that you can easily get a codebase that looks like it was profanityped by a developer with massive anger management problems and a very dirty mouth
- #13: Having made many of the possible mistakes with this language and having fixed a good deal of them, I’m here to tell you what scala taught me about clean code
- #14: We like to imagine developers as people who spew large amounts of code but in fact we spend more time reading code than writing it Read to learn Read to modify & extend Read to debug It follows that your code should be written in order to be read Your compiler doesn’t care if your code is obfuscated!
- #15: Strive for clean code - to make our lives easier
- #17: Time to get codey in here
- #18: True to its Java origins... Scala does not believe in checked exceptions and it seems like most of the developed world doesn’t either...
- #19: Algebric data types
- #22: What should you do? Combine the approaches? How do you combine libraries that take different approaches into your codebase?
- #25: Does exactly the same The difference is syntactic
- #27: We use futures with for comprehensions (one way to rule async computations and error handling beautifully) Why we chose this style? Built in async and error handling Reads like a story Promotes small functions with meaningful names That do just one thing
- #28: Having a coherent codebase is more important than writing a single solution Follow the rule of least surprise Pick one way & know why
- #29: Unified code requires refactoring and makes it easier to refactor You will always learn new things Always haunted by the fear of breaking things
- #30: Example - writing tests with Scala Test Functional style
- #32: Let your compiler help you by choosing the right type for the job
- #33: If you forget to check the returned value, you get a bug
- #34: There are other ways to handle options more elegantly
- #39: Back to the zoo example
- #40: Example: Use functional features to abstract away implementation details
- #41: Example: Use functional features to abstract away implementation details
- #42: Example: Use functional features to abstract away implementation details
- #43: Example: Use functional features to abstract away implementation details We simply fed the lions...
- #45: Here’s the thing about Scala - it allows you to write code so good it comes right out of the other side and turns bad
- #46: We spend more time reading code than writing it -> write code that’s easy to read Always write your code in the correct level of abstraction so it reads like a story So it should be clean and self documenting Make sure your functions are small, do one thing and are properly named Follow the rule of least surprise And to that end, choose one solution to each problem But refactor your ugly-ass old code to reflect your new understanding of the language Make sure you have tests so that you don’t break your stuff when you do it And let your compiler help you by making things explicit Because it makes your code less surprising And because why wouldn’t you? But keep in mind that you can have too much of a good thing!
- #47: Quote I found on the interwebz Questions?