Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Ruby codebases in an entropic universe

by Niranjan Paranjape on Mar 22, 2010

1,628 views

How to manage entropy on Ruby codebase or, how not to kill a Ruby project in eighteen months

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Apple Keynote

Usage Rights

File a copyright complaint

5 Embeds 25

http://lanyrd.com	18
http://speakerrate.com	3
http://www.slideshare.net	2
http://www.lmodules.com	1
http://www.linkedin.com	1

Statistics

Likes: 5
Downloads: 5
Comments: 1
Embed Views: 25
Views on SlideShare: 1,603
Total Views: 1,628

1–1 of 1 previous next

Kapil Mohan, Technical Architect at SlideShare Good stuff this! 3 years ago
Are you sure you want to

intro
intro
intro
quality and entropy are the two themes underlying our talk.
Quality
how would you measure the value of a codebase? $ revenue generated? Time saved? LoC? None of these have a baseline against which you can measure success or failure
how would you measure the value of a codebase? $ revenue generated? Time saved? LoC? None of these have a baseline against which you can measure success or failure
The need to adapt software to changing realities is what drives feature requests. The quality of a static codebase doesn’t matter as long as it *works*
So... some part of code quality is encapsulation
is the code factored in a manner which allows tuning parts of it without affecting other parts
Which is encapsulation again
So what exactly *is* encapsulation
This is what we’ve been taught in college
David Parnas’ paper
This is a controller action. This is also really, really bad code. Is this familiar?
Which brings us to entropy
This is a controller action. This is also really, really bad code. Is this familiar?
As you work on a codebase the complexity of the code always increases and quality decreases. The difference is that unlike Physics, entropy increase isn’t constant - but more on that later, so hold your thoughts.
Let’s walk through this code quickly and see what’s the problem. We aren’t talking about fixing it - but just looking to understand the problems that exist.
Step 1 when dealing with ANY code - specs.
Ok, that’s good.
Coverage is good. It means we have *some* kind of safety net. How good that safety net actually is depends on how the specs were written, but lets defer looking into that for a bit.
This is a controller action. This is also really, really bad code. Is this familiar?
any method that has more handful of lines, or deals with more than a single concept is big. A one page method is an abomination.
This is a controller action. This is also really, really bad code. Is this familiar?
any method that has more handful of lines, or deals with more than a single concept is big. A one page method is an abomination.
This is a controller action. This is also really, really bad code. Is this familiar?
any method that has more handful of lines, or deals with more than a single concept is big. A one page method is an abomination.
Clearly this isn’t a good idea. And the people who wrote this would agree with me, and it was never their intention to get to this point. But they did, somehow, one if statement at a time and they started living with broken windows. That said, this could happen anywhere, in any language, right? Lets look at some Ruby specific fun and games involving the...
The Ruby programmer that starts to understand metaprogramming is like a Jedi apprentice with a lightsaber. Power without wisdom/experience. It appears that all problems are easily solved using a few quick slashes and hacks. For example...
Read the comment at the top of the page if you will. “This method is regenerated at runtime based on what the prefix is set to.” Uh, huh. And that’s a good idea how?
The metaprogramming lightsaber is fun, but sometime... ***? Like seriously, ***?
well, that’s a mechanic right there - the principle is that you need to wait until you have the judgement to apply the right tool for the job
Clearly, these are bad ideas. They might have seemed like good ideas to begin with, solving the problem quickly with a hiss and a sizzle. Even though they do solve the problem, they don’t do so in a manner that is well encapsulated, easy to spec and easy to understand. Over time, they act as points where cruft starts to accumulate.
eventually, you’re like the boiling frog. you did one little thing which wasn’t ‘clean’ as a quick hack, and then two months later you realise someone else saw it, though it was a good idea and replicated it everywhere. eventually you get
which, in a nutshell, is entropy on a codebase. After a while you can’t make any change without tripping over something (or someone).
entropy is a complex engineering problem
this is why Ruby codebases need more care and love than most other codebases
You need to know when, where and how to use the lightsaber
The point is... (next slide)
basically...
Step 1. Specs.
preferably one that doesn’t take too much time
Back to step 1. Specs.
no, seriously. we can’t emphasise this enough. with something as flexible as Ruby, you need specs.
Back to step 1. Specs.
As entropy on any code base always increases, it is essential to keep an eye on trends, and refactor/redesign every once in a while to make sure that it doesn’t go out of control
to make sure it doesn’t deteriorate like this
the trends you should watch
the trends you can quantify
the trends you should watch
the trends you should watch
the trends you should watch
the trends you should watch
reek
how long does it take a new person to get productive on your codebase
which means the same entity does more
first, you need a build
first, you need a build
bad specs, poor coverage
Using a hash

5 Likes

blmlcu 11 months ago
StephenOrr 2 years ago
philipped 3 years ago
Kapil Mohan, Technical Architect at SlideShare Tags rubyconfindia 3 years ago
Kaushik46 3 years ago

Ruby codebases in an entropic universe Presentation Transcript

ruby codebases in an entropic universe or, how not to kill a Ruby project in eighteen months
niranjan paranjape
mechanical engineer. one rube goldberg machine. lots of ruby code.
http://github.com/niranjan http://twitter.com/niranjan_p
sidu ponnappa
programmer. bibliophile. failed entrepreneur.
http://github.com/kaiwren http://twitter.com/ponnappa
quality / entropy
quality
quality is valuable
quality is hard to measure it’s effects are also hard to measure
(especially in software)
ﬂexibility
encapsulation
scalability
encapsulation
encapsulation?
grouping related data and behaviour. also, data hiding.
not really
the principle of segregation of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modiﬁcation if the design decision is changed.
so... encapsulation is a means of limiting the effects change
conversely in a system that does what is needed, and, if what we need never changes, we don’t care about encapsulation
so, what’s the problem with change?
eventually, it comes to this:
entropy
codebases have entropy given enough time, the entropy of a codebase increases to a point where changes become impossible
analysis
1
ok, it’s covered let’s get back to the analysis
quick analysis • this method is HUGE (smell!)
quick analysis • this method is HUGE (smell!) • multiple branches (obscene number, actually)
quick analysis • this method is HUGE (smell!) • multiple branches (obscene number, actually) • multiple exit points
boiling frog once upon a time a domain rule wound up in a controller over time controller became the place to put domain rules
the metaprogramming lightsaber
another example
basically
metaprogramming...
don’t
other fun examples • overriding responds_to? on Object • un-deﬁng id on Object (thanks Brian!) • editing boot.rb in your Rails project • using instance_variable_get anywhere
bad ideas attract other bad ideas
entropy
complex engineering problem
made worse by... the lightsaber in ruby
lightsabers require discipline
lightsabers require precision
http://www.thetoque.com/images/stories/lightsaber.jpg
yeah, like that anyways...
ruby projects require more care
solutions?
1
specs
everything begins with a safety net
they describe how the next developer (including yourself) should consume your code.
they are speciﬁcations. a spec doesn't prove anything, but it does tell you that for one very particular scenario, your code probably works.
2
specs
they are the only conﬁdence you, as a developer, should have in your code. whether it's an acceptance test script written by a QA (manual or automated) or the world's tiniest spec, this is your starting point. without specs, the only assumption you can reasonably make about your code is that it doesn't work.
3
observe trends
trends to watch
quantiﬁable
code coverage
cyclometric complexity
ﬁle size
spec ﬁle size
call duplications
churn
class reopen count
performance
environment setup time
unquantiﬁable
public API methods stay the same, but the specs increase
modules without a contract
number of entities that need setup for one spec
how?
ci builds (ratcheted?)
metrics
speciﬁc issues
bad code
specs
DRYing prematurely
poor modelling
team dynamics
stick to idiomatic code conventions
but know when to deviate
too many conventions in a codebase
principles vs. mechanics

Ruby codebases in an entropic universe

by Niranjan Paranjape on Mar 22, 2010

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 25

Statistics

Ruby codebases in an entropic universe Presentation Transcript