トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
作者 Scott Delap, 翻訳者 松本 清一 投稿日 2007年9月5日 午後11時20分
Relevance社のStuart Halloway氏は、最近、「Ruby vs. Java の俗説」に関する連載をブログに投稿した。その連載は、彼が、未開発のRubyプロジェクトから、安定したJavaプロジェクトで仕事をするように切り替えた後から、刺激を与えられる内容となった。しばらくの間は、Halloway氏は、いくつかの「俗説」に関して考察している。俗説1:Rubyは小さなプロジェクトに向いていて、Javaは大きなプロジェクトや複雑なプロジェクトに向いている
要約すると、Halloway氏は、小さなプロジェクトの場合、確立したライブラリを探していることで、開発者が殆どコードにさわることが無く、放置状態となっている間の不確定な要因に応じて、スケジュールの調整が大胆にできるということを主張している。これらの要因は、定評のあるコミュニティや経験豊かな開発者を持つJavaに有利である。Holloway氏は、大きなプロジェクトに対しては、Rubyの利点である軽快なライブラリよりも、言語生産性の点を主張している。彼は、どちらが向いているかという論理は、今既にある見識に逆行していると言っている。彼は、次のように言って説明している。
現在、Rubyはある特定の種類の小さなプロジェクトにおいて、非常に有効です。例えば、データベースをバックエンドにおいたWebアプリケーションがそれにあたります。Ruby on Railsは、Rubyでの小さなプロジェクト全てが持つ不利な点を是正してくれます。
俗説2:いくつかのRubyの機能によって、コードの保守性が悪くなる
この俗説で言いたいことは、Rubyの機能を正しく利用することで、コードの保守性がよりよいものになるということである。保守性の高いコードとは、次のようなものである。
それぞれの優位性を比較した結果は、次の通りである。
見つけたいコードが(すぐに)見つけられる:Javaの勝ち
IDEのサポートをベースとして、Javaが勝っていると言えます。
コードの可読性が良い:Rubyの勝ち
ここで言いたいことは、RubyのコードはDRYなコードを書きやすいので、可読性が良いということです。
コードが修正しやすい:Rubyの勝ち
ここで言いたいことは、動的言語であるため、変更が容易であるということです。
変更作業の妥当性をチェックできる:引き分け
RubyとJavaは、共に単体テスト、受け入れテスト、継続的インテグレーション等に対するサポートが充実しています。
俗説3:Rubyは、非常に難しい
一般に、平均的な開発者にとってRubyは非常に難しいものであると言われている。Halloway氏は、プログラミングは難しいものであり、本棚にある本に書かれている言葉をよそに、21日で習得することはできないと主張している。結局、JavaとRubyは両方とも難しい。彼は、次のように主張している。
言語の機能を制限することによって、困難から離れたいと願うことなど無理な話です。
俗説4:Railsの素晴らしいアイデアをコピーするのは簡単である。
この俗説は、一部正しいという意味でトリッキーなものである。Railsの素晴らしいアイデアの多くは、他のどんな言語にもコピーすることができる。しかしながら、このことに対する反論として、次のことがあげられる。
俗説5:ゼロサムゲームである(中略) その他の素晴らしいアイデアとして、特定のRubyの機能に依存したものがあります。Railsでは、より良いものを作成し、より読みやすいオブジェクトモデルにするために、オープンクラスを利用します。例えば、StringUtilities.isBlank(x)と表すかわりに、x.blank?とすることができます。個人的には、そのような違いは大した問題ではないと思っているのですが、多くの人にとって、可読性を大きく向上させるために意味のあることです。
この連載を要約したものとして、Rubyは言語として勝っているが、Javaはプラットフォームとして勝っているという見地に立ち、次のように述べている。
私たち全て、うまくやっていけるのでしょうか?私は、言語をどれにするかによってプログラマが決まってしまうようなことのない世界に住みたいと思っています。Ruby、Scheme、Scala、Erlangとコードを書く人は様々なので、JVMの調和の中で、私たち全てがどこでも住めるようになれば良いと思います。
JRubyプロジェクトへのコントリビュートや、Antの代わりにRake("http://www.infoq.com/rake"を参照)を使った、Javaアプリケーションの管理といったことを含んだ、先に述べたような調和を前進させるためのステップをリストアップした。
(原文は2007年6月8日にリリースされました)
【無償】「Google Apps 企業向けソリューションセミナー」のご案内
12/16 ~野村総合研究所が提案~ 「不況を乗り切る!効果的なIT投資を考えるセミナー」
ITマネージャ必聴!IT活用セミナー 勝ち残りの法則~管理・統合化スペシャル~
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。
筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。
エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。
この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。
No comments
返信