Refactoring is considered a process trying to improve our code base, and is a common agreement on should be done as frequently as possible. The tool set can vary, but Reek and Rubocop should be part of the daily code basis process and enforced on the build process.
On this talk we can prove (statically), that beyond styling and CS theory, there's a real benefit not only code quality, accessibility, comprehensibility and maintainability but also performance of the product.
On this talk will try to prove how the tools (Reek + Rubocop) can of improve the performance, maintainability (at least) and accessibility of one of the ruby standard library (ruby/csv), benchmark it and propose the solution on real time (via PR).
I'll be touching the Pro's and Con's on having those static code analyzers, and expose my experience trying to introduce the tools on our build process at our engineering team: How people can be resilient of that change and how to get along with the resistance to this big change.
Can tools like Reek and Rubocop improve the performance of you code? What's can we find beyond of the noise? What are the real signals we should take to make it happen?
As an engineer that have been working on several languages (typed, untyped, scripting, dynamic, etc) I've been able to demonstrate how static analyzers can improve the performance of the code and more important how to persuade to managers and coworkers to improve not only the quality code but also engineering team and individuals.
Espartaco Palma
Senior Software Engineer.
Been involved on OSS since last century, TDD advocator and enthusiast of theoretical computing.
I'm looking for the meaningfulness of meaninglessness.