Apoptosis Gem - Which lines in your project need to die?

by Stwerner • 15 years ago

11 6 15 years ago

This is a great idea! You may want to use `git ls-files` instead of `Dir['/.']` in order to consider only tracked files inside the directory.

Stwerner2• 15 years ago

Cool, thanks! I whipped this up the night after the talk so there are probably some kind of inefficient parts in the interest of getting it released quickly. I'll get right on that.

j-kidd• 15 years ago

> He made a point that software is alive and unlike biological systems, doesn’t have an automatic way to kill off old ‘cells’.

That's just crazy talk. Software doesn't grow old!

saurik• 15 years ago

This is totally backwards: code you haven't touched in a while hasn't been touched /because it works/. It is the code you've recently edited where the larger number of buga are going to be found, and the more attention needs to be applied. When code is stable you don't delete it: you trust it.

Stwerner2• 15 years ago

Michael Feathers is the author of Working Effectively With Legacy Code. This is basically that software projects, as they age, have a tendency to become huge unwieldy monstrosities.

While this gem is kind of a joke, reminding you of older code that was written a long time ago when you knew less about the problem domain than you do now (since you've been working on it for the last year), checking older code for refactoring/rewriting opportunities can make life easier for you in the future or whoever maintains the code after you.

Speaking as someone who inherited a huge untested codebase - debugging those sections that were written early on and work most of the time, but have never been refactored to take advantage of things that were learned later on in the project, is pretty unpleasant.

madlep• 15 years ago

I'm gonna run Apoptosis over the Apoptosis code base in a year, and see what warnings it throws up ;)

Apoptosis Gem - Which lines in your project need to die?

Related Stories