So-net無料ブログ作成

ホームページの再構築 [Google Web Toolkit]

ホームページの再構築を始めました。Google Web Toolkitを使用して、全面的に再構築中です。

http://www001.upp.so-net.ne.jp/yshibata/

まだ「書籍」「正誤表」しかありませんが、今後色々と追加する予定です。


リファクタリングしてますか? [プログラマー現役続行]

先日、書籍『リファクタリング』を読み直していることを書きました。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチン ファウラー
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本

「リファクタリングの第一歩」(7頁)として、次のように述べられています。
リファクタリングを開始するとき、最初にすることは常に同じです。対象となるコードについてきちんとしたテスト群を作りあげることです。リファクタリングは非常に順序だっていて、新たなバグを生み出しにくくなっていますが、人間が作業する以上、間違いを犯す可能性があります。このためテストは大切で、きちっとした一連のテストを用意するべきなのです。
10年前に読んだ時に、私自身がきちんと理解していなかったのは、この点です※1。きちんとしたテスト群があり、それらを使用してコードをリファクタリングすることが、リファクタリングの基本なのです。しかし、そのためには、自動化されたテストが必要となります。いくらテスト群があっても、すべて手作業を実行しなければならなければ、役に立ちません。

単体テストが自動化されておらず、手作業で行われているような組み込みシステムでコードレビューを行うと、「時間があれば、後でリファクタリングします」とか「リファクタリングする工数がもらえれば、リファクタリングします」という発言が聞かれたりします。

私が10年前にきちんと理解していなかったように、これらの発言は、「リファクタリング」を「コードを書き直してプログラムの構造を良くし、コードをクリーンにする作業」とだけ理解していることを意味しています。自動化されたテスト群が必要であることは、抜け落ちていることになります。自動化されたテストがなければ、再度、手作業でテストを実行しなければならないという余分な作業が入るため、「後で」行うという発想になっています。

この場合、テストをまず自動化することを検討して、それを最初に実施してくださいと指導します。しかし、そのための工数が無駄に思えるらしく、なかなか素直にやってみますという返事にはならないことがあります。テストコードを書き直す作業ですので、与えられた仕事である機能を作りこむ作業が遅れるという恐れから抵抗されます。

このような抵抗に対して、William Opdykeは第13章「リファクタリング、再利用、現実」※2で「リファクタリングのオーバーヘッドを減らす」(389頁)と題して、次のように述べています。
「リファクタリングは余分な作業だ。自分は、売上に貢献する新たな機能を書くことで給与を得ているのだ」。これに対する私の答えをまとめると、次のようになります。
  • 幾つかのツールや技法を使えば、リファクタリングは短時間で比較的苦痛もなく済ますことができます。
  • 何人かのオブジェクト指向プログラマから報告されて経験によれば、リファクタリングのオーバーヘッドは、それによりプログラム開発における他のフェーズでの労力の減少とあき時間でまかなって余りあるのもです。
  • 始めは、リファクタリングが多少扱いにくくて余分な作業項目であると映るかもしれません。しかし、ソフトウェア開発制度の一部になるにつれて、そういう感覚はなくなり、むしろ不可欠に感じるようになります。
実際、テスト駆動開発を行い、リファクタリングを開発プロセスの一部として常に行うようになると、「不可欠」になってきます。しかし、全く経験したことがない人に、テストの自動化とそれによるリファクタリングの可能性を説得するのは難しいと私自身も感じています。その点に関して、William Opdykeは続けて次のように述べています。
私の経験からは、リファクタリングが日常作業の一部になれば、余分な作業と感じることはなくなると思います。と言うのは簡単ですが、それを具体化するのは困難です。懐疑的な方に対して私が助言できるのは、ご自身で実行し判断していただくということだけです。ともかく、時間を割いてみてください。
とにかく、自分で実践して、経験してみることが重要だと思います。

※1 平成12年(2000年)に執筆した記事「リファクタリングの勧め」(Java PRESS, Vol.12)には、この点に全く言及していないことからも分かります。
※2 第13章は、Martin Folwerではなく、William Opdykeの寄稿となっています。

自動化されない単体テスト [プログラマー現役続行]

遠い昔、単体テストといえば、動作を確認するprint文を入れて、その出力を目視で確認するということが行われていました。私もそうしていましたし、多くの人達がそうしていました。たとえば、Martin Fowlerの『リファクタリング』に次の記述があります(90頁)。
テストは依然として極めて退屈なものでした。これは、コンソールに出力されるテスト結果を私がチェックしなければならないためです。さて、私は極めて怠惰な人間で、仕事をさけるためならどんなに厳しい仕事もいといません。私は、基準に合った情報が画面に出力されたかどうかを自分で調べるのをよめて、コンピュータに調べさせればよいことに気づきました。テストコードに期待される出力を書いて、その比較結果を見ればよいわけです。
つまり、Martin Folwerでも目視確認をしていたことがあるということです。Robert Martinもその著書『Clean Code』で、昔はどうように単体テストしていたかを同様に述べています。

C言語で開発をする場合でも、テスト項目を記述した(自然言語による)テストスクリプトを作成し、それをレビューし、そして、テストコードとして単体テストを記述したりします。テスト項目の抜け漏れがないことをレビューで確認したら、テストコードを作成します。

このテストコードを作成する段階で、残念ながら、テスト結果をすべて目視で確認するテストコードを作成してしまう開発組織もあります。個々のテスト項目を手作業で個別に実施して、目視で確認するのです。

今日のソフトウェア業界の基準に照らし合わせると、非常に非効率な開発をしていることになります。そうは言っても、10年以上前であれば、当たり前に行われていたテスト方法だった訳です。

では、なぜ今日のソフトウェア業界の基準に照らし合わせると当たり前のことが、行われていないのでしょうか。理由は、色々とあるかとは思います。その一つは、今までのやり方が当たり前だと思っていて、改善を考えたことがないということです。

どのような開発方法でも、当事者が当たり前だと思っている限り、当事者が開発方法の中に課題を見つけ出すことは、難しかったりします。当事者に言わせれば、やるべきことを淡々と行っているだけであり、課題もないし、改善する余地もないということになります。

改善は自分の頭だけで思いつくこともあれば、書籍を読んでいてヒントを得ることもあります。この10年間は、ソフトウェア業界に良い意味で影響を与えた書籍が多く出版されています。それらを地道に読んで、自分の開発に適用できないかを考えて、実践していけば、おそらくC言語であっても自動化されない単体テストというのは、少なくなっていったと思います。

ところが、C言語による開発には、大きな落とし穴があります。以前、アンケートを実施して調査したことがあるのですが、ずっとC言語でしか開発していないソフトウェアエンジニアは、オブジェクト指向言語(C++/Java)で開発しているソフトウェアエンジニアと比較して、圧倒的に本を読まないのです。C言語を学習して、業務がこなせる範囲まで学んでしまうと、特に新しいことも学ばなくて良いと思ってしまうのだと思います。

残念ながら、ソフトウェア業界に影響を与えた多くの書籍は、オブジェクト指向に基づく開発方法向けであり、C言語しか知らないソフトウェアエンジニアにとっては、自分とは関係ないと思うのだと思います。その結果、全く読まないことになり、開発プロセスも全く改善されないままになっているのかと思います。



書籍『リファクタリング』 [プログラマー現役続行]

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチン ファウラー
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本

10年前の1999年6月に原著が出版され、私が原著を読み終えたのが1999年8月中旬です。それから、ほぼ10年が過ぎて、今、日本語版を購入して読み直しています。まだ、全部は読み終えていませんが、第2章「リファクタリングの原則」(Principles in Refactoring)を読むと、まさに、この10年間で私自身がリファクタリングについて学んできたものがまとめられている感じがします。その趣旨の章なので当たり前と言えば当たり前ですが、おそらく、実際にリファクタリングを経験したことがないと、読んでもピントこないかと思います。

本書のレビューアー※1の一人に、Joshua Blochの名前が挙げられていました。Joshuaにその話をしたら、レビューに際して、金銭計算の例に浮動小数点を使用しないでくれと著者を説得しようとしたそうです。しかし、説得はできず、残念ながら金銭計算の例にdoubleが使用されています。それで、『Effective Java』には、「正確な答えが必要ならば、floatdoubleを避ける」(初版の項目31、第2版の項目48)が書かれたようです。

ちなみに、『リファクタリング』には、この件に関して次のように述べられています(101頁)。
たとえば、例の中で金額の表現にdoubleを使っていることに気がつくでしょう。リファクタリングにおいて表現形式は重要ではないので、例を簡単にするためにこうしました。私は、納入物件となるソフトウェアにおいて、doubleを金額に使うことは猛烈に反対します。
この注意事項は見落としてしまうことがあると思いますので、やはり、サンプルコードを直してくれるのが良かったのかもしれません。でも、今では多くのエンジニア※2『Effective Java』を読んでいるので、doubleが使われることはないかとは思いますが。

本書を読み返しながら思ったことの一つとして、この本をいつ若手に読ませるのが良いのかということです(答えは出ていませんが・・・)。

※1 技術書の謝辞の欄に掲載されている名前を見ると、米国では多くの技術者が会社という枠を超えて何らかの付き合いをしているのだなと思います。それと、日本語版の訳者の謝辞に堂坂真司さんの名前がありました。堂坂さんには、『Google Web Toolkit ソリューション』と『Effective Java 第2版』の翻訳のレビューを行ってもらいました。

※2 実際には多くないと思います。日本全体でJavaでプログラミングしているエンジニアの人数がどれだけかわ分かりませんが、実際に売れている部数を考慮すると、読んでいる人は、日本全体のJavaプログラマーのごく僅かだと思います。

テスト駆動開発とClean Code [プログラマー現役続行]

テストファースト開発では、テストコードを最初に書いて、そのテストが通るように実装を行っていきます。そうすると、ひたすら実装しているだけで、従来のデバッグという感覚はなくなります。そして、すべてのテストが通るようになれば実装が完了となるわけです。この場合、テストコードが必要なテストをすべて記述していることが重要です。

最近の教育や講演でも述べていることですが、「すべてのテストが通るようになったら実装が終りではない」と話しています。ソフトウェアエンジニアに求められるのは、すべてのテストが通った後に、コードをリファクタリングして、できるだけクリーンにすることです。

実際、テストは通っているが、コードは汚いものを見かけます。担当者は、テストが通ったので実装が終わったと思ってコードをコミットして終りにしているのです。あるいは、テストが通った後に、コードを見直してできるだけクリーンにする作業をしたのかと聞いても全くしていない人もいます。

テストが通ったということは、求められる機能を提供し、その実装が動作することが確認されたということです。それまでには何時間もあるいは数日とか要しているかもしれません。しかし、テストが通ったら実装作業が終了と思うのではなく、さらにクリーンにする作業をすることが重要だと認識する必要があります。自分で納得できるレベルのリファクタリングができた時点で、実装作業は終了です。

書籍『Google Androidアプリケーション開発入門』 [本]

Google Androidアプリケーション開発入門 画面作成からデバイス制御まで――基本機能の全容

Google Androidアプリケーション開発入門 画面作成からデバイス制御まで――基本機能の全容

  • 作者: 木南 英夫
  • 出版社/メーカー: 日経BP社
  • 発売日: 2009/06/04
  • メディア: 単行本(ソフトカバー)

Amazon.co.jpで予約可能になっています。著者の木南英夫さんとは、この10年ほど(同じ職場で)一緒に仕事をしています。私の翻訳本のレビューもずっと行ってもらっています。

出版おめでとうございます。

ElvisクラスのleaveTheBuilding()メソッド [Java]

『Effective Java 第2版』の項目3 「privateのコンストラクタかenum型でシングルトン特性を強制する」(17頁)のElvisクラスには、初版にはなかったleaveTheBuidling()メソッドが追加されています。翻訳した時は、メソッドが追加されているなという程度で深く気にしなかったのですが、調べてみました。

Wikipediaの"Elvis has left the buidling"よれば、次のように説明されています。
"Elvis has left the building!" is a phrase that was often used by public address announcers following Elvis Presley concerts to disperse audiences who lingered in hopes of an Elvis encore. Al Dvorin, a concert announcer who traveled with Elvis throughout the performer's career, made the phrase famous when his voice was captured on many recordings of Elvis' performances.
Elvis Presleyのコンサートで、アンコールを期待して帰らない聴衆に対して使われた言葉のようです。Elvisクラスに追加されたleaveTheBuilding()メソッドを見て、分かる人にはすぐに分かるのでしょうが・・・・

このようなpun(駄洒落)は、英語のネイティブスピーカーではない私にとっては、翻訳者泣かせです。今回のような例は、特に翻訳する必要もないので問題ないのですが、『Java Puzzlers』を翻訳した時は、かなり苦労しました。

Java Puzzlers 罠、落とし穴、コーナーケース

Java Puzzlers 罠、落とし穴、コーナーケース

  • 作者: ジョシュア・ブロック、ニール・ガフター
  • 出版社/メーカー: ピアソン・エデュケーション
  • 発売日: 2005/11/14
  • メディア: 大型本

この本では、とにかくパズルのタイトルが駄洒落や語呂合わせだらけでした。最初は著者のJoshua Blochに都度問い合わせして、訳注を追加していました。しかし、あまりにも多いので、訳注では無理と判断しました。それで、日本語版に向けて特別に付録C「語呂合わせとポップカルチャー参照」という解説のための付録を書いてもらって、それを翻訳したものを日本語版に含めたのです。

ところで、この『Java Puzzlers』ですが、タイトルが良くないのかあまり売れていないです。一度、その点に関してJoshua Blochと話した時に、『Defective Java』の方が良かったかもと冗談を彼は言っていました。内容としては、Javaでプログラミングする人にとっては、『Effective Java 第2版』と同様に必読だと私は思っています。Javaでプログラミングする上で知っておくべきことを、パズル形式で教えてくれる内容です。発売からすでに3年以上経過していますが、内容は陳腐化していません。


書籍『Clean Code アジャイルソフトウェア達人の技』 [プログラマー現役続行]

講演でも紹介している書籍『Clean Code』の翻訳本がまもなく発売されるようです。

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

  • 作者: Robert C. Martin
  • 出版社/メーカー: アスキー・メディアワークス
  • 発売日: 2009/05/28
  • メディア: 大型本

原著は、こちらです(こちらの表紙が私は好きですね)。

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

  • 作者: Robert C. Martin
  • 出版社/メーカー: Prentice Hall
  • 発売日: 2008/08
  • メディア: ペーパーバック

原著は発売直後に読みました。そして、会社で読書会を開催して2回目の読み直しをしています。読書会は、週に一回で80分なのでそれほど進んでいませんが、残念ながら読み終える前に翻訳が出てしまいますね。

この本は、クリーンなコードを書くということに関して、必読の書籍だと思います。書かれていることで良いと自分が判断したものは、日々のソフトウェア開発で実践して、徐々にでも身に付けていくことが重要だと思います。

鹿児島での講演 [プログラマー現役続行]

鹿児島組み込みシステム推進協議会に主催していただきました講演を5月9日(土)に行いました。

P1020031s.jpg
講演

52名の参加がありました。主な参加者は、鹿児島大学、第一工業大学、鹿児島高専、ポリテックカレッジ川内からの学生さんと先生、それに、社会人や鹿児島市役所の方々が参加していただきました。暑い中、参加してくださりましたみなさん、ありがとうございました。

鹿児島へ行くのは初めてでしたので、8日(金)と9日(土)の午前中は、観光バスで色々な場所を妻と二人で観て回りました。駆け足でしたが、指宿、長崎鼻、知覧、城山、仙巌園、桜島と1日半で回ることができました。

P1020012s.jpg
桜島での写真

ゴールデンウィーク中は火山灰が降った日があったそうですが、8日と9日は火山灰が降ることも無く天候に恵まれました(暑かったです)。

NHKの大河ドラマ「篤姫」は全く見ていなかったので、見ていたら観光ももう少し楽しかったのではないかと、ちょっとばかり後悔したりもしました。

書籍 『突然聞きとれる!たちまち話せる!英語は「耳読」にかぎる!』 [英語]

松澤さんからは新しい本を執筆されていると聞いていたのですが、すでに出版されていたようです。

突然聞きとれる!たちまち話せる!英語は「耳読」にかぎる!(CD付)

突然聞きとれる!たちまち話せる!英語は「耳読」にかぎる!(CD付)

  • 作者: 松澤 喜好
  • 出版社/メーカー: 青春出版社
  • 発売日: 2009/04/25
  • メディア: 単行本(ソフトカバー)

「耳読」という言葉が使われていますが、書籍の紹介によると、次のようなことだそうです。
【本書のテキストとCDを使った「耳読」のステップ】
1 好きなストーリーをひとつだけ選びます(いっぺんに全部のストーリーに手をださないで!)
2 テキストを見ないで聴きます(意味がわからなくてもOKです)
3 テキストを見ながら聴きます(自分がどこまで理解しているか確認してみよう)
4 聴きながらマネして声に出します(コツは聴いたままを素直に声に出すこと)
5 テキストを閉じてイメージしながら聴きます(頭の中にはっきり物語が浮かぶはず)
多くのソフトウェアエンジニアにとっては、英語を使用しなければならない環境に身を置かない限り、動機付けがないため、英語を身に付けるのは難しいようです。一方で英語は言葉ですので、それに接した絶対時間に比例して伸びていきます。

ソフトウェアエンジニアが英語力を身に付けられないのは、英語に接している時間が圧倒的に少ないためだと思います。技術書を英語で読みなさいということではなく、好きなジャンルの小説を多読することが必要だと思います。つまり、若い時にペーパーバックを何冊読んだことがあるかということです。松澤さんは、年間1万ページを目標に読まれていると聞いたことがあります。

そして、英語の音に耳を慣らすために、英語をたくさん聞くことです。以前ブログで書きましたが、現在は、PodcastでCNNなどのニュースを簡単にiPodにダウンロードして聞くことができます。ニュースなどは速すぎるということであれば、本書のCDに収録されているストーリーを繰り返し聞かれるのも良いかと思います。

TOEICを受けなさいというと、TOEICの対策本を買ってきて勉強することしかしない人がいます。英語は言葉ですので、日本語で小説や新聞を読むように、英語で多くを読み多くを聞くことが生活の一部となっていることが重要です。そうして、身に付いた英語力を測定するためにTOEICを受けるのです。たとえば、半年に一回だけTOEICを受けるとしたら、半年間の自分自身の成長を確認するために受けるべきです。