On 3-4 June 2017 Svitla is organizing the fifth annual Ruby Conference - RubyC! In terms of preparation for the event it has become a nice tradition to make small interviews with Speakers, to help participants know them a little better. This week we are happy to present answers from a brilliant Polish Ruby developer Piotr Szotkowski aka @chastell who presents a topic "Ruby Smells".
Ruby Smells.
Writing good object-oriented code is hard: object boundaries are not always as clear-cut as we’d like, their responsibilities and reasons to change tend to grow over time, inter-object coupling makes isolated testing complicated – and emergency refactorings are tiresome, gnarly and seem to always happen too late. At the same time it’s often hard to see the exact moment when a simple refactoring would save a given class from taking the wrong turn, and real-life projects tend to have real-life sad lines with their tireless chants of ‘let’s refactor this in the next sprint’. Ruby’s dynamism means static code analysis is tricky (to say the least), but tools like RuboCop and Reek bravely show it’s not impossible. This talk shows how to effectively use such tools, make informed decisions on when and how to refactor, and – most importantly – learn over time to spot potential code smells right when they’re introduced.
1. Tell us about your recent work, what have you learned/found out/achieved.
2. Your Topic “Ruby Smells” is devoted to RuboCop and Reek. Why have you decided to talk about them? What projects or problems motivated you?
3. Sometimes recommendations from RuboCop and Reek are different. How to bring them into line?
There are relatively few areas covered by both RuboCop and Reek; RuboCop is more of a syntax style enforcer, while Reek is an architectural tool. There are some common areas of interest –e.g., RuboCop tries to eradicate long methods because they’re a readability issue, while Reek points them out as potential code smells that mix the level of abstraction – but in general the best approach is to figure out what are acceptable thresholds for a given project (e.g., maximum number of lines in a method or maximum number of instance variables) and adjust them as necessary.
In general, RuboCop is much more opinionated because it usually deals with much cleaner choices – ‘this kind of syntax should be indented this many spaces’ or ‘single quotes where possible vs double quotes everywhere’ are relatively easily made choices that should indeed be uniformly enforced across the whole codebase if possible. Reek seldom deals in absolutes; there are often cases where a given piece of logic *technically* should live closer to class A, but *in practice* is much more useful when put in class B.
My general rule of thumb for RuboCop is ‘try to please it as much as possible and only reconfigure it on the most blatant disagreements’, while my rule of thumb for Reek is ‘this are fascinating suggestions, let me look at the smells one-at-a-time and I’ll probably whitelist quite a few of them – and that’s perfectly OK’.
4. We know that you often present at conferences around the world, can you share latest rumors?
? It’s surprisingly hard to share technical rumors without heavily coating them with your own superstitions (or hopes), but it’s really interesting what the Ruby world learns and picks up from functional languages like Elixir and Clojure. Also, the dry-rb family of libraries might be worth a closer look. ;) Also, TruffleRuby seems like a super interesting project…
5. What do you expect from 2017 for Ruby?
More advances in stability and performance, with wonderful results delivered by TruffleRuby and sustained progress of incremental improvements from the relentless JRuby team. Probably a few new libraries that will show how to do implement Ruby some interesting features of other languages.
6. What are you interested in above coding?
I really enjoy photography – nothing fancy, but some of my street shots can be found at http://chastell.net/1/125/
I also like casual city cycling, sadly I have time mostly on my daily 2×10 km commute. ?
