6 Ruby questions to Piotr Szotkowski

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.

My recent programming-related work was quite interesting; at Rebased I’m working with a solar energy company, writing software for monitoring and administration of their solar panel farms, and at my university I’m researching reversible computing, while dabbling a bit in Crystal.

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?

RuboCop becomes more and more a widely-recognised set of standards for writing Ruby syntax, and while I wholeheartedly disagree with some of its rules and can fully understand the frustration it causes in some developers I still think it’s in general a welcome tool in our everyday life.

Reek, while seemingly similar, is totally different: rather than concentrating on the syntax it tries to point out potential architectural problems in a codebase on an OOP level. Reek’s results are much less rules and much more suggestions where to look for potential issues, and can’t really be auto-corrected (but rather require – often quite extensive – refactoring).

I talk about Reek because it taught me *a lot* about OOP, structuring my programs and, in general, moving code closer to where it belongs, even if it’s non-trivial. I got fascinated by the amount of OOP code smells that can be automatically recognized (and, as a result, became one of Reek’s maintainers).

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. ?