WHATで考える練習
プログラムの設計を勉強していると、”WHAT” と ”HOW” という言い方を、よく見かけます。
WHAT : 何を HOW : どうやって
プログラムのアルゴリズムを考えるのは、”HOW”。 ですから、プログラムを作ると、必ずHOWは考えます。 しかに、それが ”何を” 実現する目的で作られているか、設計者がそこに注目して思考し、アウトプットしなければ、 WHAT は 見えるモノ として残りません。
連載の2回目の「”いきなりプログラミング”は危険だ」では、 ”仕様との関係性が読み取れないコードは危険” といったことを書きました。 HOWでプログラムを作ってしまうと、全体の構造が ”仕様との対応が理解し難い入り組んだ構造(≒スパゲティ状態)” になりやすく、またそうなってしまっていることも気づきにくいのです。
仕様との関係が解るプログラムにすると何が良いのか?
・ プログラム構造が理解しやすい
・ 後々、そのプログラムは保守しやすい
・ 再利用できる場所を考えやすい
2番目以後は、理解しやすいからこそ、使いやすいという二次効果になります。
「イメージ的には解かるけど、本当に?」と思われるかもしれません。
HOW で作ったプログラムと、WHAT で作ったプログラムがどう違うか、システムテスト以後で何か障害が見つかった場合の対策方法を例として考えて見ましょう。
● HOWで考えると...
出来上がったプログラムが、HOWで考えられた構造になっている場合、設計図は実装をそのまま絵にしただけなので、「コード見たほうが確実だよ!」といったことになりがちです。そのため、障害が起きたときにも、事象から「コードのどの辺が怪しい」と、開発者は頭の中で辺りをつけて、コードを直接調べているでしょう。
それで、問題箇所が見つかった後も、コード上で修正方法を考えます。そして、他にどんな影響があるのか、工程を遡って、全体を調査するような作業が必要になります。また、修正結果を確認するためにも、修正したコードから必要なテストがどれかを調査し、沢山のテストケースを実行しなければならなくなるでしょう。
といった具合に、調査・修正・確認 のすべての工程がコード基点での考え方になってしまいます。
● WHATで考えると...
WHAT で考え出来上がった構造は、仕様からどうプログラム構造に展開したか、さらにどうやって詳細に実装したかが、設計図に残っています。障害が起きたときにも、仕様の中のどれに絡んでその事象が起こっているかを考えれば、自ずと原因調査としてどこにプログラムのどこに焦点を絞るかが考えやすくなっています。
また、それで原因箇所が見つかれば、それに影響を受ける箇所も、またそれらの再確認のためのテストケースがどれかも、仕様を基点として、考えられるでしょう。
それは、WHATで思考した結果、仕様と実装とのつがなりが、設計図として残してあるためです。
ただ、これは開発時にも、保守時にも WHAT で考える癖がないと、途中で破綻してしまいます。
・ アーキテクチャ設計時に ”WHAT:何を” の塊で作るように、考える。
・ ”WHAT” で考えた結果を、設計図(= 仕様との関連がわかるドキュメント) に残す。
・ 対策考えるとき、”WHAT:何を” するところに問題があるのか、考える。
・ 修正するとき、”WHAT:何を” しているところを、どう変更するのか、考える。
・ 修正確認は、 ”WHAT:何に” ついて確認が必要かを考える。
っと、くどくど書きましたが...
伝えたかったこととしては、「常日頃 ”WHAT” 基点で考える癖をつけて、よいプログラム構造が作れるようになりましょう。」 ということでした。
連載記事のほうは、今月発売の2011年6月号から、ちょうど DFD を使って WHAT でプログラムを分析する例をご紹介しています。よかったら、こちらも書店で眺めてみてください。
※ 関連記事: Interface 2011年2月号
Interface 2011年6月号