GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

Ruby vs Java 5本勝負〜その2〜 コードのメンテナンス編

その2です。忙しい方は最後のまとめだけ読まれるとよいと思います。

Ruby vs. Java Myth #2: Ruby feature X makes code unmaintainable

Ruby includes a variety of features that lead to compact, expressive code, e.g. open classes, dynamic evaluation, soft encapsulation rules, easy metaprogramming, and closures. These features demo well, but developers who have not used them fear that they will lead to unmaintainable code.

In reality, Ruby's powerful features make code more maintainable, when used correctly. (Learning to use these features correctly will be the subject of another myth.)

Rubyの特徴「X」、Xとはオープンクラスだったり、動的型付けだったり、簡単にメタプログラミングができたり、クロージャだったりします。そういう特徴がいい感じで動いたとしても、「こういうのを使ったことの無い」開発者はメンテできないコードになっちまうんじゃないかと心配する。

実際のところは、「正しく使われたら」こういったパワフルな特徴はコードもよりメンテ可能なものにするよ、と言っています。

残念ながらこのエントリでは正しい使い方に言及してはいませんが、このシリーズの別のエントリで例示してくれるそうです。後で確認します。

  1. Understand the overall design of an application or module
  2. Find code you are looking for
  3. Read the code
  4. Make changes to the code
  5. Verify that the changes work

Given these criteria, how do Java and Ruby stack up? I believe that the responsibility for maintainable code lies 80% with the programmer, and only 20% language and tools.

コードをメンテナンスするってことは、「全体像をつかむ」⇒「自分が探してるコードをみつける」⇒「コードを読む」⇒「コードに変更を加える」⇒「ちゃんと動くか確かめる」という流れであるだろうと論じています。確かに。メンテするってことは、変更するってこと。

ですが、この基準に沿って考えればJavaRubyがどうやってその基準に達して議論が出来るのか、と。メンテできるコードへの責任は80%がプログラマにあり、言語やツールはたった20%だと信じている、とあります。

このエントリでは、その20%の議論を、前述の5つのStepに照らし合わせています。

Understand overall design

Advantage: Neither. In my experience, no language is very helpful here.

同感。全体感をつかむということに、言語そのものが寄与できることって無いと思う。

Find the code you are looking for

Advantage: Java. Java's IDE support wins hands down.

どこにあるかを探すのは、JavaのIDEサポートによってJavaの楽勝だと言っております。

Read the code

Advantage: Ruby. Now we are down to the level of individual classes and methods. At this level, Ruby code is easier to keep DRY, and therefore easier to read.

コードを読むってことは、個々のクラスやメソッドに依存してるよね、と。そうなればRubyのコードはDRYを維持するのがJavaより簡単だし、その上読みやすいよ、と言っています。

Change the code

Advantage: Ruby. (略) At this point the compiler gets in your way, because some of the original author's assumptions need to be bent or broken. Change is much easier in a dynamic language.

変更は動的言語のほうがずっと簡単だと言っています。これは無理やりって感じがする。何をもってして、ずっと簡単なのか。同じロジックをJavaRubyで書いたら、RubyのほうがXXだからずっと楽だ、ということを言語とツールのみに限定して主張することが出来るのか。それはないだろう・・・。

Verify that the changes work.

Advantage: Neither. If you are serious about quality, then you need to test.

変更したものを確証するには、テストをどうやっていくのかが重要になる。テストの自動化等については、RubyJavaも様々なものが提供されていると言っています。

かなり強引に残り20%の議論をしてきました。最後にこんなことを言っています。

Neither Ruby nor Java can make your code maintainable. I propose that we replace the old myth (feature X makes code unmaintainable) with no myth at all.

RubyJavaもあなたのコードをメンテ可能なものにはできやしない。私は、この古い都市伝説を何の伝説でもなかったことに置き換えることを宣言する、と。つまり、言語そのものとコードのメンテナンス性は関係が無いということを最後に結論付けています。

確かにコードは人に依存するものですが、「最低限これだけは守りなさい」をベースにした規律あるアプローチを作ることで、平均点をあげることはできるんじゃないだろうか?その辺りが気になるのです。

まとめ

  • コードのメンテは80%がプログラマ、20%が言語とツールがその責を負う。
  • 言語的にはRuby、ツール的にはJavaにが有利。
  • 変更の確証についてはJavaRubyもあんまり変わらない。
  • 人に依存すると突っぱねるのは簡単だけど、何か方法はあると思うよ。