Home > Archives > 2007年3月 Archive

2007年3月 Archive

DISTINCT と GROUP BY

職場であるソースを眺めていると、集合演算の無いGROUP BY句が出てきました。
しばし考えて、重複行を削除したいのだなと理解したのですが、実際どっちを使う方がいいのでしょうかねえ。

以下、簡単な例です。


SELECT DISTINCT
顧客CODE
FROM
注文


SELECT
顧客CODE
FROM
注文
GROUP BY
顧客CODE

ググってみると、ほとんどのデータベースでGROUP BYの方がパフォーマンスが良いようです。
(とは言っても、劇的に差が出るほどでもない)

本来の考え方からすると、重複行を削除するのはDISTINCTであり、GROUP BYは集合演算をするためのものです。
少しでも早いパフォーマンスが要求されたり、対象レコードが半端じゃない量だったり、繰り返しSQLを実行する必要があるときは仕方無いとしても、速度にほとんど差が無いのであれば、DISTINCTを使う方が本来の意味通りになるため、可読性が向上し、使いやすいんじゃないかなと思うんですけどね。

TextBoxのReadOnly属性をtrueに設定すると、PostBack時に値が初期化される

  • Posted by:
  • 2007年3月27日 23:44
  • ASP.NET

ReadOnlyなので入力はできませんが、JavaScriptで値を変えることはできる訳で、ちょっとハマりました。
PostBackすると、どうやら初期値に戻ってしまうみたい。

解決するには、デザイン時にReadOnly属性をfalseにしておいて、実行時のPage_Loadあたりで

TextBox1.Attributes.Add("readOnly", "readOnly");

をしてあげれば、無事に値が残っています。
なんか、ASP.NETのバグな予感。

コメントに愛を

可読性を上げるためにコメントを入れることは当然なのですが、ただコメントを書くだけでなく、書き方にも工夫してみようかという試みです。

例えば、


// 社員登録
社員マスタ.Save();

なんてコードがあったりします。
まあ、よくあるコメントですね。

では、この例ではどうでしょうか。


// 入力データを社員テーブルに登録します。
社員マスタ.Save();

少しコメントに温かみがあるような気がしませんか。
なぜかというと、文章で説明しているからです。
例えばコメントが一切書かれていないとき、コードの意味を作った人に聞いてみるとします。

「これってどういう意味ですか?」
「社員登録」

こう言われると、意味は分かりますがなんか気分良くないですよね。
それでは、次のケースではどうでしょうか。

「これってどういう意味ですか?」
「入力されたデータを社員テーブルに登録しています。」

こっちの方が普通の会話ですよね。
コメントというのは、自分以外の人がコードを見たときにきちんと理解できるように入れるものですが、理解できればそれで良いというものではなく、優しく語り掛けてあげるような書き方をすることで読む方も気分よく仕事をすることができるようになります。
「あいつのコード読みたくないんだよなあ」と思いながら仕事をするより、「あいつのコードを読むのは面白い」と思われた方が作業効率も違ってきます。

この僅かな気持ちの差は、長い期間で大きな差となってくるでしょう。
面倒くさいかもしれませんが、「ですますコメント」をやってみてはいかがでしょうか。

ちなみに、弁慶フレームワークは「ですますコメント」で書かれています。
弁慶フレームワークの半分は愛情で作られています(汗)

エントリを整理しました。

  • Posted by:
  • 2007年3月22日 12:42

タイトルのとおり、重複したエントリを整理しました。

私生活の日記はLibertyBoy
試験情報はIT試験受験日記

に残す形としました。
お探しの情報が削除されている場合は、上記リンクから辿ることができると思います。

  • Comments (Close): 0
  • TrackBack (Close): 0

なぜ弁慶フレームワークを作ったのか

オープンソースを作っていると言うと、「それってお金になるの?」と、よく言われる訳ですが。

・理由

オープンソースを作る理由は人それぞれで、ある人はお金儲け(独自のビジネスモデルに基づく)だったり、ある人は趣味だったり、ある人は修行だったりと様々です。

私の場合は、最初に就職した会社でリストラに遭い、仕事を失いかけていたところを多くの人に助けられ、これまでやってこれました。その際、多くのチャンスに恵まれ、多少なりとも技術と経験を積むことができたので、これをなんらかの形で世の中に還元したいなという気持ちがありました。


・環境

エンジニアを取り巻く環境は、一昔前より悪化していると言えます。
受注額の下落、短期間開発で受託開発は疲弊し、多くの企業は安易な偽装請負(※ 犯罪です)に手を出しています。
建築業界と同じ、請負のピラミッド構造になっているため、しわ寄せは末端のエンジニアにやってくるのです。
エンジニアは休むことなく、プロジェクトをたらいまわしにされ、スキルも身に付かないうちに転職を繰り返します。
そして、これが悪循環となっていきます。

この状況を変えることは簡単ではありません。
まずは経営者から末端のエンジニアに至るまで、現状を知る必要があります。
そして、それぞれの立場から、この負のスパイラルから抜け出す方法を考えなければいけません。
多くの経営者は、優秀なエンジニアを重要なポジションに置くことを考えますが、これは短期的な効果しか見込めない場合が多いようです。
長期的な視点から見た改善は、全体のスキルを底上げすることと、工学的なアプローチに基づいた生産手法の確立等の戦略上にあると考えられ、属人性の排除を前提とします。

弁慶フレームワークの自動生成機能は、このような環境を改善する一つの手段として考えたものです。


・ビジネス

最初の話に戻りますが、儲かるのかどうかというと正直儲かるとは思いません。(ほとんど趣味だし)
でも、それでもいいと思っています。
極論から言うと、弁慶を使ってくれなくても、理念を理解してくれて、少しでも環境が良くなる人がいるのならそれで良しとしたいと思うのです。
万が一にもビジネスに繋がるようなことがあれば、それはそれで嬉しいですけど。

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

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

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

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


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

検索ボタン押下→SelectOrder

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

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

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

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


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


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

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

DAOGenerator1.0.1リリース

DAOGenerator1.0.1をリリースしました。

ストアド用のAccess、Entityを作成するときに細かい不具合がありましたので修正しました。
弁慶フレームワーク自体は1.0.1のままとなっています。

ControlGenerator1.0.0を公開しました

リクエストのキューイングの記事で、ConfigGeneratorと宣言していたものです。
Configファイルを作成するだけでなく、Controller、Commandクラスのスケルトンを生成できる機能まで付けたので、名前を変更しました。

DAOGeneratorと同じく、弁慶フレームワークを使っているため、動作サンプルのコードとして研究目的で使うこともできます。

※ Configファイル、Controller、Commandクラスはこのツールを使用しなくても、手打ちで作ることもできます。(面倒くさいですけどね)
※ 弁慶フレームワーク自体は1.0.1のままとなっています。

Index of all entries

Home > Archives > 2007年3月 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