Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
前回はコラムを落としてしまってスミマセンm(_)m
仕事の方が年明けに急に忙しくなってしまいました。
でも、今はだいぶ落ち着きました。
高負荷な作業が入っても、すぐにいつも通りまで回復する．．．これもXPを実践しているおかげですね(^_^)
本当にXPは変化に強いやり方だと、つくづく思います。
ちなみに今私がやっている仕事は、前回のテスティングのカバー範囲でもある「受入テスト」というものです。
そうです。私は、顧客側（ビジネス側）で働いているXPerなのです。
１年半前までは、開発側でXPを実践していたのですが、現在はビジネス側としてXPを実践しています。
そして、これまでの経験でわかったことは、「システム開発の成功要因の80〜90%はビジネス側にある」ということですね。
今回、要求を出すところから、受入テストの準備、開発側のフォローアップ、機能レベルの障害管理、機能レベルの変更管理．．．といったものをやりましたが、基本的にビジネス側が開発側に対して、こういったものをちゃんと準備してあげれば、高い品質を保ったままリリース期限を守ることは本当に簡単です。
開発半ばに成果物をチェックしたので、リリース直前になって焦ることは全くなく、要求の伝達ミスもほとんど発生しませんでした。
何回か仕様変更はあったものの、全くスケジュールを変更することなくリリースすることもできました。
バグや障害が起きても、ビジネス側で即座にチェックできたので、素早く開発側をフォローすることができました。
結果として、リリース予定日より前に十分余裕を持って満足できるものがリリースできたのです。
ですから、開発全体を見た場合、開発側が開発スピードやプロセスを向上させることはもちろん必要ですが、それ以上にビジネス側がXPをはじめとするアジャイル開発プロセスの知識を身に付け、プロジェクトをドライブした方が、投資効果は高いと思います。
もし、ビジネス側でこのコラムを読んでいる方がいれば、ぜひXPを覚えてほしいです。
そして、開発側に全部丸投げするのではなく、ビジネス側であるあなたがプロジェクトをドライブすることを検討して下さい。
プロジェクト成功の80〜90%は、ビジネス側であるあなたが握っているのです！
わからないことがあれば、記事の最後にある「フィードバック下さい！」でコメントを書いていただければ、できる限りお答えします。
また、公で相談できなければ、私宛に直接連絡をいただければ、できる限りお答えしたいと思います。
アドレスは、masq@timedia.co.jpです。
さて新年初の今回は、「リファクタリング」をお届けします。
リファクタリングは、簡単に言えば、「外部仕様を変更せずにプログラムの内部をよりシンプルに、よりわかりやすく改善する」行いです。
たとえば、前回のテスティングの例を引き合いに出すと、最初「1と2をインプットすると3がアウトプットされる」というテストのために「3をアウトプットする」という機能を作りました。
これを次の段階では、「2と3をインプットすると5がアウトプットされる」というテストに対応させるために「インプットを足した結果をアウトプットする」という機能へと作り変えました。
この作り変えの行いをリファクタリングと呼びます。
もう少し複雑な例を出すと、「データベースからデータを引っ張ってくる処理をファイルからデータを引っ張る機能に変更する」や「データの物理削除を行っていた処理を削除フラグを付けるだけの論理削除に変更する」といった内部的な機能変更もリファクタリングです。
こういったアイデアをビジネス側に話すと、決まって出てくる言葉は、
「そんなことは開発側の趣味の問題だろ。うちはとりあえず動けばいいんだから、そんなことに時間をかけないでくれ．．．」
もし、プログラムが一度できあがったら、もう二度と仕様変更や修正がなく、何の障害も出ないのであれば、確かにその通りです。
しかし、これは非現実的です。
一度で完璧なプログラムができると思いますか？
二度と仕様変更や修正がないプログラムってあり得ますか？
リリースされて何の障害もないプログラムなんてありませんよね？
つまり、プログラムが一度できあがったら、もう二度と仕様変更や修正がなく、何の障害も出ないなんていうのは、「幻想」そのものなんです。
ソフトウェア開発プロジェクトが数多く失敗するのも、こういった幻想にとらわれているビジネス側がいまだに多いからではないでしょうか？
．．．
もうそろそろ目を覚まして下さい。
私たちがやっているシステム開発というものは、極めて現実的な仕事なんです。
動くか、動かないか．．．そんなゼロか１かの仕事をしているんです。
ですから、幻想や希望をどんなに主張したとしても、動かないものは動かないし、できないものはできないんです。
現実を直視した上で極めて現実的なアプローチをする必要があります。
そしてXPは、現実的な答えを提供してくれます。
では、リファクタリングとは、一体どんな現実的な答えを用意してくれるのか？
それは．．．
「変化が起きても、最小のコストで変化に対応するための準備」です。
何のためリファクタリングを行うのかと言えば、後から変更が発生したときに、誰が見ても変更する箇所が一目でわかり、いつでも変更が簡単に加えられるようにするためです。
また、こういった設計を心がけることで、何度でもプログラムのやり直しがきくようになるため、結果として壊れてもすぐに修復できるプログラムができあがることになります。
決して、プログラマのエゴや潔癖症だけからくるものではないのです。
もっとも、エゴや潔癖症丸出しのプログラマがいることも確かな事実なんですが．．．(-_-u
実は、「ただのエゴ」なのか、「まともなリファクタリング」なのかを見分ける手があります。
それは．．．テストを書いているかどうかです。
そもそも、テストのないリファクタリングというのは、リファクタリングではありません。
リファクタリングは、冒頭で紹介したように「外部仕様を変更せずにプログラムの内部をよりシンプルに、よりわかりやすく改善する」行いです。
ですので、テストなしでこの”条件”を満たしているかどうかを判定することは不可能です。
また、テストなしでコードを変更する行為は、かなりリスクの高い無謀な行為と言えます。
もうそれはXPとは言えません。
リファクタリングは、必ずテストと共にあります。
ちなみに「うちはXPやってるよ。テスト以外はね」というXPerは絶対に信用してはいけませんよ。
テストのないXPなんて、あり得ませんから．．．
リファクタリングは、これまでの負の要素をテストと共に浄化するような、そんなプラクティスです。それ自体、プロジェクトの進捗を進ませるようなものではありませんが、その後の機能変更や機能追加をスムーズにしてくれるので、結果的にはプロジェクトの進捗が格段に上がります。
また、余計なコードハッキングに費やす時間は、限りなくゼロに近づきます。
あなたもリファクタリングでいつもスッキリしたプログラムを組んでみませんか？
次回、1/28(金)は「ペアプログラミング」です。
お楽しみに！
There is no comment.