
Code statistics for Basecamp Next - andycroll
http://37signals.com/svn/posts/3094-code-statistics-for-basecamp-next
======
mhartl
It's interesting to see how few integration tests there are in Basecamp Next.
I used to use functional (controller) tests heavily, but in the last year I've
switched over to integration tests (plus Capybara) for controllers and views.
(I still use unit tests for models.) I really like their power and
flexibility, and I've found it convenient and intuitive to test, e.g., a web
form by visiting the page and (virtually) clicking "Submit". These are the
stats for the current Rails Tutorial sample application (taken from the in-
progress book at <http://railstutorial.org/book?version=3.2>):

    
    
        $ rake stats
        +----------------------+-------+-------+---------+---------+-----+-------+
        | Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
        +----------------------+-------+-------+---------+---------+-----+-------+
        | Controllers          |   164 |   139 |       6 |      23 |   3 |     4 |
        | Helpers              |    81 |    62 |       0 |      13 |   0 |     2 |
        | Models               |   102 |    58 |       3 |       6 |   2 |     7 |
        | Libraries            |     0 |     0 |       0 |       0 |   0 |     0 |
        | Model specs          |   256 |   198 |       0 |       0 |   0 |     0 |
        | Controller specs     |    29 |    22 |       0 |       0 |   0 |     0 |
        | Request specs        |   555 |   424 |       0 |       3 |   0 |   139 |
        | Cucumber features    |    87 |    34 |       0 |       0 |   0 |     0 |
        +----------------------+-------+-------+---------+---------+-----+-------+
        | Total                |  1274 |   937 |       9 |      45 |   5 |    18 |
        +----------------------+-------+-------+---------+---------+-----+-------+
          Code LOC: 259     Test LOC: 678     Code to Test Ratio: 1:2.6
    

(Note that "Request specs" is RSpec-speak for "Integration tests".) This is
probably a little heavier on the test code side than I would have in an app
designed for production rather than pedagogy, but it gives you the basic idea.

Even though there's some minor controversy about testing frameworks in the
Ruby community (you can see that I use— _gasp!_ —RSpec), I think it's great
that the only way to cause major testing controversy is not to do it.

P.S. I have some reservations about Cucumber, and the Cucumber features are
there mainly for _Rails Tutorial_ readers who want a quick introduction to the
subject. I don't use Cucumber much myself, although I do have a better
appreciation of its virtues than I used to.

------
andycroll
I still find myself worrying about the 'app-ness' of lots of JS in a web
application. Think it's derived from my web standards background.

Twitter is my least favorite site in this respect.

No idea what this means for of Basecamp Next, as there's no actual code yet,
but in my own work I like to make sure that no-JS doesn't necessarily mean no-
functionality.

~~~
dhh
Andy, Basecamp Next does not have a one-screen app feel at all. We're still
all about separate pages.

But we do rely heavily on JS for functionality, so it won't work without it.

~~~
andycroll
In an ideal world I'd like non-JS fallbacks but I'm torn as to whether I'm
being too 'old school' or stuck in a 'progressive enhancement' approach more
suited to a web site rather than a web app.

I suspect it comes down to the project and the trade offs therein. I'm no code
zealot.

I'm presuming you're serving just desktop interface to start as well? No
responsive or mobile at launch?

~~~
dhh
The UI has been designed to work great on tablets and it also works pretty
well on a phone (albeit a tad crammed). We'll probably do something more
dedicated for mobile after launch.

------
csallen
Wow, only 6334 lines of code? I find that to be shockingly small. It's less
than projects I've worked on by myself for 4 or 5 months, which is nuts
considering they've (presumably) had 5+ engineers working on Next for a year
now.

~~~
dhh
I worked pretty much alone on the code base for the first three months. Then
we were two people for another three-ish months. Then the last four months or
so we've ramped up the team to have 4-6 programmers on, depending.

But we're also ruthless about keeping the code base small. In the beginning I
would go through the entire code base every week and prune it. I still read
through the entire thing every now and then and make sure there's no excess
fat.

~~~
csallen
Ah, makes sense. I didn't realize you guys keep things so small. Is Next going
to have an API when it launches? And if so, do the stats posted include lines
of API-related code?

EDIT: And since I'm already asking so many questions, how do you guys feel
about supporting older versions of IE?

~~~
dhh
Yes, we're launching with an API. The code stats include those for the API.

We will not support old versions of IE. We support IE9+.

~~~
csallen
Cool. It's pretty impressive to fit an API in there, too. Do you guys
subscribe to the method of building your app on top of your own API? Or do you
place more of a priority on speed?

~~~
jkahn
It's Rails, so presumably the API will be one with the (regular) code for the
most part.

------
DanielRibeiro
DHH's take[1]: _we have almost as much CoffeeScript as Ruby code!_

[1] <https://twitter.com/#!/dhh/status/164038209267974145>

------
DavidChouinard
The most interesting tidbit is this:

    
    
      Code to Test Ratio: 1:0.8
    

That seems like an awful lot, no?

~~~
travisjeffery
No, not at all; especially not for enterprise applications.

The current project I work on has 292908 LOC, and Code to Test Ratio: 1:1.1.

~~~
hopeless
On the other hand, I work on enterprise apps with 200-500k LOC and maybe 1-2K
LOC for test. So "Enterprise" probably isn't a good indicator on test ratios.

------
wtn
Still awaiting the release of Cinco…

~~~
dhh
Don't hold your breath. We haven't revisited the mobile version of Basecamp
since we released it and haven't started any other new projects based on
Cinco.

I'm not sure when/if we'll have a chance to get back to it.

~~~
jashkenas
I think I may have asked this before, but would you mind describing a bit
about how you foresaw Cinco coming together? What would it have provided on
top of Backbone.js + Stitch/Sprockets?

