1年間の技術的負債を返すために読んだ3冊の本

[この記事を読む前に]

タイトルに騙されて来た方はごめんなさい。
恐らく、知っていることばかりが書いてあると思います。
“3冊の本”もベストセレクションではありません。
“たまたま”選んだ3冊の本です。
それでも読んでくれる心優しい方はどうぞ、先にお進みください。

技術的負債は日々、返済していますか。
技術的負債って何？という方はこちらへ。

• 技術的負債 – Wikipedia

えー、正直、私は技術的負債が溜まっています。
お知らせメールを本格的に初めて1年が経とうとしています。
何も無い状態から、手探りで始めて今の状態までなんとか持って行きました。
この計画が立ち上がった当時(2年ぐらい前かな)、自分ができたのは、

• PHPが書ける(書けるだけ)
• サーバが少しわかる(cdとlsが打てるだけ)

これぐらいです。
ちょっと大げさですが、あながち嘘じゃない。

そんなこんなで、試行錯誤の毎日。
運営を始めるとさらに大変で、技術的負債がどんどん溜まっています。

やっと、機能追加も落ち着いてきたので、技術的負債を返そうという話が相方との間で出ています。
コードのリファクタリングを含め、開発環境を全面的に見直したいところです。

そこで、技術的負債を返すべく、勉強のために3冊の本を読みました。
今日はその3冊の内容にプラスアルファして、1年間で学んだことをまとめていきます。

そもそもなぜ、技術的負債が溜まったのか

私は新しいモノ好きです。
そして、気に食わないことはとことん突き詰める質です。

そんな性格から、モノを作っていると色々なことが気になってくる。

これはこれで、本当にいいのか。

これが頭の中に浮かぶともう止まらない。
これに追い打ちをかけるように、新しい技術や手法が次々と飛び込んでくる。

これを使えば、さっきの問題は解決するんじゃないか。

こんな毎日で、日々やり方を変えていきます。
そうすると残るのは、過去のやり方でやったコードや環境です。

確かに新しいやり方はしっくり来るし、とても心地良い。
しかし、”過去のやり方でやったところを直すには時間が掛かる“。

そもそも、現状のやり方で問題なく動いているところです。
これを直すには、気力と時間が必要です。

そして、”それじゃ後でまとめてやろう“という一言に甘える。
簡単に言ってしまえば、これが技術的負債の正体なんでしょう。

技術的負債を返して、負債を溜めないために

技術的負債を貯めない方法、その一つがアジャイル開発なんだと私は考えました。
TDDを取り入れた、スピード感のあるインテグレーション開発。

私はTDDを去年のCakeMatsuriから、試行錯誤で実践しています。

• CakeMatsuri 2009

今まで個人的にTDDをやってきて気がついたのは、”TDDは技術的負債を返すための道具ではない“ということです。
確かに、TDDを実践すると気持良く開発を進めることが出来る。
しかし、TDDだけでは技術的負債は溜まっていきます。
TDDを実践する前よりはマシですが、それでも溜まっていく。

TDDはアジャイル開発の一部だと言うことです。
恐らく、TDDはアジャイル開発の手法と併せて、初めてその威力を発揮する。
そのリズミカルな開発サイクルに乗せることで、日々技術的負債を返していける。
そう考えたんです。

前置きが長くなりました。
これが、今回読んだ3冊の本です。

アジャイル・プラクティス 著者: Venkat Subramaniam 出版社: オーム社 発売日: 2007/12/22

アート・オブ・アジャイル デベロップメント 著者: James Shore 出版社: オライリー・ジャパン 発売日: 2009/02/18

バグのないプログラムのつくり方 著者: 川端 光義 出版社: 翔泳社 発売日: 2004/09/22

この3冊の本から、私が重要だと思う点、そして今後実行すべきタスクをまとめてみます。

アジャイル・プラクティス

アジャイル・プラクティスはとても読みやすい本です。
アジャイル開発の入門には最適でしょう。

• 200ページの読みやすい厚さ
• 2500円という(技術書にしては)買いやすい値段

アジャイル・プラクティスはアジャイル開発の”スピード“とその”リズム感“を主眼において書かれています。
例えば、アジャイル開発の設計段階の解説では、こんな記述があります。

設計の出発点では、個々のメソッドやデータ型に注力する戦術的設計よりも、責務の観点から考えるクラス設計のほうがふさわしい。というのも、責務中心のクラス設計であれば、抽象レベルを高くしたまま、ゴール思考で考えることができるからだ。実のところ、CRCカードによる設計は、まさしくそのための手法だ。CRCカードによる設計では、クラスを次の視点から表現する。

ホワイトボード、スケッチブック、付箋紙は、素晴らしい設計ツールだ。複雑なモデリングツールは、気づきを与えてくれることよりも、集中力を削いでしまうことのほうが多い。

アジャイル・プラクティス 戦略的設計と戦術的設計(p52)より

付箋とホワイトボードが好きな開発者は数多い。
その理由がこれなんでしょう。
私自身、なんとなく理解していましたが、さらにその利用用途が明確になりました。
どうせなら、どでかいホワイトボードが欲しいな、とぼんやりと考えてみたり。

ホワイトボードはさておき、私たちの開発環境で必要なもの、それはこれです。

製品が使い物になるために必要な本質的な機能はどれなのかをユーザに聞いてみよう。その際には、話が脇道にそれないように気をつけよう。素敵だけども実装できるかどうかわからない機能の話に夢中になったりしないこと。また、想像しうる限り最高に魅力的なインターフェースを目指したりしないこと。
アプリケーションを早めにユーザの元に届けると、うれしいことがある。

アジャイル・プラクティス 短いイテレーションでインクリメンタルにリリースする(p72)より

アジャイル開発では、作成したソフトウェアのデモやデプロイまでが小さなサイクルの中にあります。
そもそも、この”ソフトウェアのデモ“が重要なファクターだと思います。
つまり、このデモの準備も自動化し、高速に行う必要がある。

お知らせメールは受託開発ではありません。
完全に自社開発・自社運用でやっています。
顧客に見せるデモという段階はありませんが、開発した機能をトータルテストする段階はある。
これをアジャイル開発におけるデモと置き換えることが出来ると思います。

現状、これが自動化されていません。
これは、やろうやろうと思ってやってこなかった技術的負債です。
必ず自動化して、開発サイクルを高速化しようと思います。

その他にTDDの進め方から、コードの書き方までアジャイル開発に必要な事項を幅広く取り上げてあります。
アジャイルについてまったく知らないなら、この本から読むことをオススメします。
事実、アジャイルを知らない私が、とてもスラスラと読むことが出来ました。

アート・オブ・アジャイル デベロップメント

アジャイル・プラクティスの次に読んだのはアート・オブ・アジャイル デベロップメントです。
これはアジャイル・プラクティスの内容を詳細にしたような本です。

チームにアジャイルを適用するために、必要な事項がまとめられています。
例えば、アジャイルを始めるにあたって、チームの規模は初めに気にするところだと思います。
アート・オブ・アジャイル デベロップメントには以下のような記述があります。

もちチームのプログラマが4名未満だったら…
それでもXPプラクティスの多くはまだ適用できるが、ペアプログラミングは難しくなるだろう。この場合、そのプログラマが高品質なコードを書くのに情熱を持ち、誠実であるなら大丈夫だ。こうした情熱があれば、XPの技術的なプラクティスを規律を持って適用できるだろう。
常に同席してくれるオンサイト顧客を持つのにも苦労するかもしれない。代わりに彼らの近くに席を並べよう。そうすれば必要なときに彼らの関心を引くことができる。

アート・オブ・アジャイル デベロップメント XPを導入する(p50)より

プログラマが少ないチームだと、各人のモチベーションが重要だと言うのは納得出来ます。
二人で開発していると、チームとしてのモチベーションがほとんど存在しません。

個々のモチベーションが重要です。
二人三脚で一人が走らないとまったく動きませんよね。
そんな感じです。

やはり、小さなチームでやる以上、お互いの理解と同意が必要ですね。

その他に、アート・オブ・アジャイル デベロップメントで参考になるのはコーディング規約に関する話です。

私はかつてプログラマ4名からなるチームを率いていた。書式に関して、彼らは大きく異なるアプローチをとっていた。コーディング標準について議論するときに、私はカッコとタブに関して3つの異なるアプローチのカタログを作った。それぞれのアプローチには熱心な支持者がいた。私はそんな議論にはまり込みたくなかったので、好きなスタイルを使ってもいいよと言った。
結果は予想通りだった。コードの書式には、3つの異なるアプローチが使われていた。1つの短いメソッドの中に2つの異なるインデントが使われているのを見たことがある。
何が私を驚かせたか分かるかい？そんなにひどくなかったんだ。確かにレイアウトは見苦しいし、私は一貫性がある方が好きだ。それでもコードを読むことができた。結局、書式以外のコーディング標準のほうがもっと重要だったんだ。

アート・オブ・アジャイル デベロップメント コーディング標準(p138)より

これも長くコードを書いていると分かってきます。

コードは美しく書くのではなく、明瞭に書く。

明瞭というのはコードの意味が明瞭ということ。
例えばこんなコードです。

$artiles = array(
	'title1',
	'title2',
	'title3');
foreach($articles as $no => $article) {
	printf('No.%s : %s', $no, $article);
}

$vars = array(
	'title1',
	'title2',
	'title3');
foreach($vars as $key => $value) {
	printf('No.%s : %s', $key, $value);
}

明らかに、前者よりも後者が分かりやすいですよね。
明らかに、後者よりも前者が分かりやすいですよね。
レベルの低い例で申し訳ないのですが、これは本当に大事です。
この話がメソッド名やクラス名に繋がってきます。

PHPやPython、PerlやCというのは、全てプログラミング言語です。
言語なんです。
つまり、わかりやすい文章を明瞭に書く必要がある。
それを先程の引用から考えさせられました。

アジャイル・プラクティスを読んで生まれる、”じゃあ、実際にはどうするの？“という疑問に答えてくれる一冊です。

バグがないプログラムのつくり方

これはEclipseを使ったJava開発に向けて書かれた本です。
ですが、テストを書く上で必要なtipsが書かれた本でもあります。
個人的には”6章 テスト駆動開発のエトセトラ“だけ読めば十分だと思います。

6章には、TDDにおける犯しがちなミスとその解決策がまとめて載せてあります。

賢人さんたちは、その仕様変更や機能追加の際には、必ず先に従来のコードをリファクタリングしてから始めるようにしていました。そうすることで、機能追加する前に従来のコードに対する理解も深まり、追加後のリファクタリングできそうなポイントも見つけることができます。

愚痴さんの参加しているプロジェクトもTDDを採用しており、たくさんのテストコードがあって、すべて成功しています。ここまでの状況は、賢人さんのプロジェクトと同じです。しかし愚痴さんは、テストコードのメリットは何度も実行できることだけだと思っていたので、テストコードの見直しは行いませんでした。

賢人さんのところは、テストコード自体のわかりやすさを保ったまま、ソフトウェアを大きくすることができました。仕様変更や機能追加の際に、テストコードから見直す場合にも、わかりやすいのは非常に助かりました。
愚痴さんのところも、機能追加の際にテストコードは非常に役立ちました。しかし、仕様変更の際に従来のテストコードを見直す必要がある場合には、時間がかかるようになってしまいました。

バグのないプログラムのつくり方 テスト駆動のエトセトラ(p144)より

私も面倒臭いがために、この中の愚痴くんと化しているところがいくつかありました。
わかってはいたけど、修正できない。
まさに技術的負債ですね。

技術的負債を返すために、まずはテストコードのリファクタリングから始めましょうか。

買うのはちょっとという人は、立ち読みでも良いと思います。
6章を少し読んでみてください。
テストを見直すきっかけになります。

まだまだ得たものはたくさんあるのですが、記事に書けるのはこんなところです。
最後に個人的タスクをまとめておきます。
必ず実行して、技術的負債を完済します。

• 必ず実行するタスク一覧
• テストコードのリファクタリング
• コーディング規約の見直し
• コーディング規約チェック自動化
• テスト自動化
• デプロイ自動化
• デモ環境へのデプロイ自動化

最後に

最近、技術書に関する記事が盛り上がっていましたね。

• 全てのプログラマが読むべき本ベスト10冊
• 見習いプログラマが読んだら、すぐにジョブレベルが上がる１０冊
• 見習いプログラマが読んでも、ほとんど無意味な10冊

人それぞれ、各書籍に対して色んな意見があると思います。
とりあえず、立ち読みで、あるいは図書館で借りて読んでみてはどうでしょうか。
自分にとって役に立たないのであれば、読まなければ良いんですから。
(少しの時間が取られるかもしれませんが、良書にあったときに得られるものと比べたら大したことはないでしょう。)

私が今回読んだ3冊も、通読なんてしていません。
何を学びたいか、何を得たいかだけ意識して、自分の欲しいところだけ読みました。

自身のレベルによって学べるところは様々なんだから、読む本は自分で決めましょう！

これが言いたかっただけで、”最後に”を書いてみました(^^;

こちらもあわせてどうぞ

• CakePHPでフィクスチャに惑わされずにテストを書く方法 – モック編
• CakePHPを使ったテスト駆動開発