Evaluating Rails Projects | Hacker News Reader

Evaluating Rails Projects

samuelmullen.com

48 pointssamullen21 comments

This is great and all, but now I've done some analysis on my own project and it depresses me. Thanks, dude. Thanks a lot.

Ah ha! My evil plan is finally revealed.

This is good stuff, reminds me of all horrible cancer I've had to deal with working on certain projects in past. This hopefully isn't an issue with anyone else out there, but there also should be a check for complexity in the views. Dealing with junk like anonymous classes, capture abuse, stateful partials, bloated clashing helpers, rjs, etc. have been worse for my health than 20 years of chain smoking, heavy drinking, and being stabbed.

Could you elaborate on the capture abuse ?

"For the controllers directory, expect higher scores; good scores are less than 20."

Ahem, anyone else run that and get scores like these?

$ flog app/controllers/ 7658.1: flog total 17.4: flog/method average

   174.4: BidsController#show              app/controllers/bids_controller.rb:17
   126.0: CompanyDocumentsController#update_verifications app/controllers/company_documents_controller.rb:85

Controllers are usually the most 'big ball of mud' in Rails apps, which is why the whole "fat model, skinny controller" thing caught on.

Running the same command on models... just crashes. Our God object (not User) weighs in at 1647.3. Yep, just one single model.

Another thing to do:

rake stats # Report code statistics (KLOCs, etc) from the application

A friend of mine also recommended seeing how RESTful the app is, which I think's a great idea as well.

Probably going to follow up on the article with a PDF download to summarize all the todos and allow notes to be taken.

Make sure you add all the extra dirs where code might be hiding

    ::STATS_DIRECTORIES << ["Admin", "app/admin"]
    ::STATS_DIRECTORIES << ["Cells", "app/cells"]
    ...

Minor errata: Rails was released in beta during the fall of 2004. The first Rails conference (Canada on Rails) was in early 2005 and the 1st edition of AWDwR came out in August 2005.

I believe Rails hit v1.0 in December of 2005, but by that point it was already a thriving ecosystem.

You could also upload the Gemfile / Gemfile.lock to a service like versioneye [1] which will then tell you which gems are outdated and what the current versions are.

[1] https://www.versioneye.com/

"bundle outdated" will do that too.

There's this too: https://github.com/nickjj/gemshine

It will recursively check a directory for gemfiles and then compare your installed version against the latest version.

It uses bundle outdated under the hood.

Great post. I do a lot of these same things whenever I join a new app or am evaluating a project to take on. There's definitely some doozies of Rails apps out there.

I also like to pry open the ApplicationController pretty quickly. You'll usually find all sorts of interesting logic and tight coupling in there.

In the example app you used, the models actually look pretty light on lines of code. I'm willing to bet the Views were full of conditionals, which is another thing I keep an eye out for.

A search tool like ack or grep are also incredibly useful to follow a trail of any interesting scent you might pick up.

>>In the example app you used, the models actually look pretty light on lines of code. I'm willing to bet the Views were full of conditionals, which is another thing I keep an eye out for.

I'm a Rails newbie so please excuse my ignorance... What is the connection between models being light on code and views being full of conditionals? What I assume you mean is that your models should also have view logic so that your templates aren't full of if-then statements. But isn't that what decorators are for?

No, the models shouldn't have view logic such as formatting, that belongs in Presenters. What I was implying is that the views likely have boolean logic/conditionals that are checking various states of the model and then rendering partials/HTML content based on that.

Of course, there could also be model logic in the controllers and helpers as well.

Most of the code was from a personal project, so the reason the models were light is because they weren't a 1:1 representation of the database.

I try to practice good OOP and stay with Sandi Metz' rules: http://robots.thoughtbot.com/sandi-metz-rules-for-developers

Well, you sure fooled me. I guess I didn't ask if you had app/services|presenters|etc directories. :)

Good article. In addition to running flog, I also run brakeman and rails_best_practices.

"source code management system i.e. SCM"? i.e. a VCS? They're not limited in utility to code.

Reply on news.ycombinator.com