Home > プログラミング > アーキテクト Archive

アーキテクト Archive

なぜプログラムが追いにくいのか?

ある理由から、意味の分からないソースコード(C#)を読んでいます。
資料はそれなりに揃っているものの、ソースコード上にコメントがほとんど無く、資料と整合性が合っていない場合、なぜ違うのかが全く分からないんですよね。
かなり苦戦している訳ですが、せっかくなので、なぜ読みにくいコードになっているか考えてみようと思います。

簡単に思いつくあたりでは、
・コメントが圧倒的に足りない。というか必要なところになく、役に立たないコメントだけ存在。
・「とりあえず動けばいいや」的な場当たりな作り方。
・間違った共通化。共通ロジックの呼び出し方が暗号みたいな作りになっていた。

と、こういうのは大体どこにでも存在するコード(泣)で、どちからというとマナーみたいなもんなんですが、果たしてこれが解決すると読みやすいか?というと、そうでもない気がしてきました。
根本的な問題があるのはプログラムの構造で、モジュール分割や機能と実装の分離が正しく行われていないことが原因だと思います。


特に重要だと思うのが、機能と実装の分離です。
例えば、機能説明に「検索ボタン押下時に受注情報を取得する」と書いてあるのに、その処理を示すメソッドが「SelectOrder」となっていたとします。
これは最終的な結果から見ると正しい動作になっていますが、構造では欠陥があります。
つまり、「受注情報を取得する」をしたいときに、何故「SelectOrder」なのか関連性が不明だからなんです。
(この例は単純な例なので容易に想像できちゃいますが...)

検索ボタン押下→SelectOrder

ではありません。
この場合は、

検索ボタン押下→Get受注情報→SelectOrder

とすべきです。
なぜなら、機能説明に忠実に作成するなら、検索ボタン押下に要求される機能は「受注情報を取得する」ことだからです。
そして、「受注情報を取得する」ための実装として「SelectOrder」が呼ばれます。
このように、機能と実装を分離すると、もし実装が変わっても(例えばデータベースが変わるとか)、ボタン押下イベント側には影響が出ません。
また逆に、ボタン押下イベント側から利用する際にも、どんな実装をしているかを気にせずに呼び出すことができるようになります。

さらに付け加えると、ボタン押下イベント側から呼ばれるメソッドは、機能を表す名前をつけることが望ましいです。
なので、この例でも「受注情報を取得する」のような機能の場合、動詞を前に出して「Get受注情報」としています。


他に気をつけるべき点として、メソッドを単一機能に限定することが挙げられると思います。
つまり、メソッドの説明をするときに「このメソッドは○○と××をします」のようになってしまうのは問題があります。
正しくは、「○○をする」メソッドと、「××をする」メソッドの2つのメソッドに分割することです。
そうすることにより2つの機能が独立するため、単純な構造になります。


実はこういう事を言うと、「こんなことをしたら、クラスやメソッドがいっぱい増えて、処理が遅くなってしまう」と反論する人がいます。
これはある意味では正しいと言え、実際にクラスやメソッドが増えるし、処理も遅くなります。
しかし、オブジェクト指向言語を選択した時点で、パフォーマンスが最重要課題でない(最重要課題ならC等を選びましょう)ため、例えば0.01秒掛かっていたのが0.02秒になったとしても、実際にほとんど影響が無いと言えます。(それでも早くしたいなら、性能の良い動作環境を買ってもらいましょう)

確かにわずかながらデメリットはありますが、システムの将来を考えると、より可読性の高いコードを生産する方が価値が大きいのではないでしょうか。

アーキテクト

最近アーキテクトという言葉を目にするようになってきました。
先日のデブサミ2007でも、カテゴリにアーキテクトがありましたし、これも時代の流れなんでしょうか。

個人的には、アーキテクトが見直されるようになったことは大きな変化だと思います。
アーキテクチャ不在によるプロジェクトの破綻が少しでも減ってくれればなあという期待の半面、ダメなアーキテクチャを作って失敗するプロジェクトなんかも出てくるのかもしれません。

いずれにしても、今後の動向を見守っていきたいということでカテゴリを追加しました。

あ、コレか...

先日のデブサミ2007で萩原さんの話している内容が自分の考え方に似ているなあ(O/Rマッピングとか)と感じていたのですが...

ITアーキテクト vol.1

私がもの凄く参考にしている、ITアーキテクトの記事を書いたのが、なんと萩原さんでした。
かなり記事の影響を受けていたので、そりゃ似てて当たり前だなあと。

デブサミ2007 - 2日目

デブサミ2日目です。

今日は2つ目のセッションから受講予定だったのですが、早めについたので空いていた「徹底討論:日本のIT技術は世界一になれるか?」を聞いてみることに。
昨日から薄々気付いていたのですが、人気の無かったセッションが意外と面白いんですね。
人気のあるセッションの多くはタイトルのインパクトが強いんですが、実は商品説明な場合が多くて、期待はずれが多かったように思いました。

でも、さすがGoogle、「Googleを支える大規模分散システム / Google における開発プロセス」の内容は秀逸だったとのこと。
Googleと言えば、止まらないシステムで有名ですが(過去には火事になっても止まらなかったこともあり)、サーバが数万台あるので、常に何パーセントかは故障しているとかって話もあったようです。

午後はコミュニティライブを2つほど覗いてみました。
オブジェクト倶楽部さんのライブは討論会みたいな流れでしたが、Judeでマインドマップを書きながら進行していたは新鮮でした。
Judeっていいね、明日ダウンロードしようっと。

そして締めくくりは「対談:ITアーキテクト大解剖」を受講。
例によって空いていた訳ですが、これが大当たりでした。
アーキテクト3人が討論するというものなんですが、進行役の鈴木雄介さんに対して、マイクロソフトの萩原正義さん、建築家の大川信行さんという異色の組み合わせ。
アーキテクトとか、デザインパターンって建築用語から来ているわけで、抽象的なモデリングを重視するあたりは共通点も多く、目からウロコでした。
全体を通して、建築家の大川さんの存在が大きかったと思います。
大川さんがいたことで、あまりテクニカルな話にならず、バランスの良い流れになったように感じました。
また、建築という視点から見た世界の話を通して、何かがつかめた感覚があります。
企画した鈴木さん、ナイスです!

そして、マイクロソフトの萩原正義さん、この方は凄い思考回路を持っています。
正直、神だと思いました。
萩原正義さんが最近捨てた技術に「O/Rマッピング」を挙げたときに笑いが起こりましたが、実は私も弁慶フレームワークで悩んだ末に「O/Rマッピング」を採用しなかったので、あながち間違ってなかったのかな?とホッとしてみたり。
エンジニアとして生きてきた中で一番勉強になった1時間半を挙げるとするなら、確実にこのセッションだったと言い切れる、そんな有意義なセッションでした。

Continue reading

Index of all entries

Home > プログラミング > アーキテクト Archive

Search
Feeds
Tag Cloud
Recommend

SQLパズル 第2版 プログラミングが変わる書き方/考え方
SQLパズル 第2版 プログラミングが変わる書き方/考え方

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

ITアーキテクト vol.1
ITアーキテクト vol.1

オブジェクト指向における再利用のためのデザインパターン
オブジェクト指向における再利用のためのデザインパターン

増補改訂版 Java言語で学ぶデザインパターン入門
増補改訂版 Java言語で学ぶデザインパターン入門

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

J2EEデザインパターン
J2EEデザインパターン

アンチパターン―ソフトウェア危篤患者の救出
アンチパターン―ソフトウェア危篤患者の救出

世界でいちばん簡単なネットワークのe本―ネットワークとTCP/IPの基本と考え方がわかる本
世界でいちばん簡単なネットワークのe本―ネットワークとTCP/IPの基本と考え方がわかる本

Return to page top