« 2005年04月 | メイン | 2005年06月 »
2005年05月31日
分けるよりどう混ぜるか
分けたら、混ぜなければならなくなる。
分けることだけ考えていてはだめなコードになる。
混ぜた結果がよくなるように、分けなければならない。
投稿者 tatsugoro : 09:15 | コメント (0) | トラックバック
2005年05月30日
むやみに改行するな
空の改行が多いコードをよく見かけるがたいてい見難い。
改行は１回あたり１行も使うコストの高いコードだ。
意味のあるときだけ改行することを心がけると読みやすいコードになる。
投稿者 tatsugoro : 10:53 | コメント (0) | トラックバック
2005年05月28日
1つにまとめるのを目的にしてはならない
同じ様な画面、同じような処理があると、一ヶ所にまとめたくなる。
まとめた結果コードや設計がよくなるのならそうすべきだが、悪くなるなら考え直したほうがよい。
1つにまとめるのはよくするための手段であって目的ではない。
投稿者 tatsugoro : 00:15 | コメント (0) | トラックバック
2005年05月27日
何でも英単語にすればいいというものではない
ネーミングルールに「英単語をつかうこと」となっているものを頻繁に見かけるが、私はこれに反対する。
特定の顧客向けに作っているシステムならば、その顧客の使っている用語はそのままそのものをローマ字で使うべきだ。私はやっていないが、日本語文字を使うことについても容認派の方だ。
英単語にするとその言葉の意図を微妙に変化させてしまうことがありバグの原因になるし、引継ぎのときや顧客と話すときも行き違いになりやすい。
投稿者 tatsugoro : 23:12 | コメント (0) | トラックバック
2005年05月25日
VB.NET、C#はアプリケーション言語のための言語
VB.NET、C#などの汎用言語は、そのままでは特定アプリケーションを書くのにふさわしいだけの言語になっていない。これを特化して特定業務用途向けに変化させることで、その用途向けのプログラムを的確に書くことができるようになる。
特化する手段はアプリケーションフレームワークの構築、業務メタ言語の創造などである。これこそがアーキテクトの仕事だと思う。
投稿者 tatsugoro : 05:11 | コメント (1) | トラックバック
2005年05月24日
強く依存しあうくらいなら同じ場所にあったほうがまし
クラスやメソッドに分割しても、強く依存しあっているままでは分割することでかえって読みにくくなることがある。そういうときは同じプロシジャのままにして、コメントで消臭してあるほうがましだ。
長くなってもよい。
投稿者 tatsugoro : 15:19 | コメント (0) | トラックバック
2005年05月20日
ただ隠すのではなく、どう見せるか
クラスやプロシジャを作る目的として隠蔽もある。
隠蔽するのはいいのだが、それを使うためのコードがどういうものになるのか、どういうコメント・ヘルプをつけると読みやすいのかを考慮して設計すると、よいプログラムになる。
投稿者 tatsugoro : 13:09 | コメント (0) | トラックバック
2005年05月19日
プロシジャは共通の処理をまとめるために作るのではなく
プロシジャは共通の処理をまとめるために作るのではなく、粒度がそろわなくなったとき、そろうようにするために作るべき。
投稿者 tatsugoro : 22:22 | コメント (0) | トラックバック
2005年05月13日
フォーム認証でのログインとログアウト
ASP.NETでのログインとログアウトをフォーム認証(FormAuthentication)で実装するためのサンプルへのリンク。
大雑把に説明すると
ログイン
ログインページにFormsAuthentication.RedirectFromLoginPage
web.configを書き換える
ログアウト
FormsAuthentication.SignOut();
Response.Redirect("logon.aspx");
MSDN Library Japan .NET Framework 開発者ガイド 簡単なフォーム認証
.NET Framework クラス ライブラリ FormsAuthentication.SignOut メソッド
GotDotNet Japan .NET フィールドエバンジェリスト チーム コラム ASP.NET + IIS 6 のセキュリティ モデル - デモ解説
＠IT > Insider.NET > 連載：プログラミングASP.NET > 第19回 フォーム認証ASP.NETアプリケーション
キーワード
ログオン(logon)、ログイン(login)、サインイン(SignIn)、ログオフ(logoff)、ログアウト(logout)、サインアウト(SignOut)
投稿者 tatsugoro : 11:33 | コメント (0) | トラックバック
デバッグしやすさもシステムの品質のうち
私は他の人のプログラムを見る機会が多い。それらには、デバッグしやすいコードと、そうでないコードがある。
デバッグのしやすさはシステムの品質に大きく影響を与えている。デバッグしにくいコードで作られたシステムはバグが直らず、機能追加もできず、顧客の評価は非常に低い。業務システムは完成した瞬間からすでにバグや将来の仕様変更があるのが定めであり、デバッグ作業が必ず必要になるというのに、デバッグしやすくするということにあまり注目されていないのが残念でならない。
うまくないエンジニアが書いたコードがデバッグしにくいということはすぐに想像できるだろう。でも、高レベルのコーディング技術と、しっかりした設計のうえにコーディングをしたときですら、デバッグしにくいコードになることがあるようだ。高レベルのコーディング技術やしっかりした設計と、デバッグしやすいコードとの因果関係はあまりないということなのだろうか。
デバッグしやすいコードになるかどうかは、結局コーディング担当者の技量に依存していると思う。デバッグしやすいコードを書くためには開発ツールの習熟や、重複しにくい名前付け、適切な型付けなどがとても大事だからだ。うまくないエンジニアはこれができない。
コーディング規約によって経験の浅いエンジニアでもデバッグしやすいコードを書いてもらうということもよくやられているが、残念ながら多くの場合、コーディング規約はデバッグしやすさのために書かれているとは思えないことが多い。
たとえば、C言語系でコードブロックを構成するための中括弧「{}」をプロシジャ名やif文とは別の行に改行して記述する、としている規約が多いようだが、これは1画面に表示される情報量が少なくなるため、特に小さな画面しか与えられていない開発環境の場合は、非常にデバッグがしにくくなる様に思う。
他にも、むやみにFactoryを使うと型情報が欠損してVisual Studioのデバッグ機能のいくつかが使えなくなることがある、小さなスコープだからといって命名の手を抜く、名前とは違うことをするコードを書く、継承を多用しすぎる、プロシジャを分割しすぎてステップ実行がしにくいなどがある。
デバッグしやすいコードを書くのは簡単なことではないのかもしれない。だけど、私にとっては、デバッグしにくいコードのままデバッグしている方がよっぽど難しいことなのではないかと思う。デバッグをはじめてからデバッグしやすいコードにするのは難しい。だから、普段からデバッグしやすいコードを書くよう心がけることにしよう。
投稿者 tatsugoro : 03:08 | コメント (0) | トラックバック
2005年05月09日
良い設計と良いコード
コードの品質が悪いと、「設計が悪かったんですかねぇ。オブジェクト指向とかUMLとか苦手なもので」というようなことを言われることが多い。
だけど、こういうのが得意だからといって、それがコードの品質が良くなるとは限らない。
コードの品質は、コーディング担当者の腕前に一番影響を受ける。
だいたいここで書いた「設計」というものがあいまいだ。
すばらしい設計書を書いた、すばらしいUMLを書いた、として、それで本当に設計したといえるのだろうか。
そういう「設計」をした人は、その設計資料を基にコードが良くなるかどうか胸に手を当てて考えてほしい。ほんとうは無理だとわかっててやっているのではないですか？
コーディングを担当する人に負担をかけるのをやめたいなら、せめて「設計」の権限を与えてほしいと思う。
投稿者 tatsugoro : 23:57 | コメント (3) | トラックバック
2005年05月07日
市川さんの「@ITで「Enterprise Library概説」が公開されました」
市川さんの記事「Enterprise Library概説」が@ITにて公開されました。
＠IT Insider.NET Enterprise Library概説 マイクロソフトが推進するオープンソース・ライブラリ
Enterprise Libraryは、日本ではあまり知られていませんが、非常に役に立つプログラム群です。
まずは、市川さんの記事を読んでみてください。
投稿者 tatsugoro : 14:05 | コメント (2) | トラックバック
予約語を名前にするには、「[]」と、「@」
予約語を変数名、メソッド名、プロパティ名などの名前に使うには、VB.NETの場合は先頭に完全な名前空間を付けて修飾するか角かっこ ([ ]) で囲み、C#の場合は「@」を先頭につけます。
[VB.NET]
property [Integer] as Integer
[C#]
public int @int
MSDN Library Japan Visual Basic 言語の概念 コード内の要素名としてのキーワード
MSDN Library Japan Visual Basic 言語の概念 Visual Basic の名前付け規則
Visual Basic 言語リファレンス キーワード
C# 言語の仕様 2.4.3 キーワード
C#では「@ 文字を前に付けない限り識別子としては使用できません」とありますので、「@」をつけることで使えるようになります。しかし、C#内から使うときには、使う側にも「@」が必要ですのであまり役に立ちそうもありません。
こうやって作ったC#のアセンブリも、VB.NETからつかうときは@は不要ですので
[VB.NET]
CsKeywordControl.int = 33
と書けます。
結局は、使えたり使えなかったりということになってますので、予約語になっているものはできるだけ避けるのが懸命ということになりますか。
投稿者 tatsugoro : 09:09 | コメント (0) | トラックバック
2005年05月05日
Refactoringは再度因数分解すること
リファクタリング(Refactoring)が思ったほど現場に浸透していないのか、オブジェクト指向という単語をほとんどの技術者が知っているのに、リファクタリングを知っている人にはあまり会ったことがありません。
リファクタリングという言葉は知ってはいても、どういうものなのかを理解できていない人達も多い様で、これはもしかしてリファクタリングという単語が日本人になじみが無いからかと思いました。そこで、辞書をひいてみたのですが、リファクタリング(Refactoring)は英語を母国語とする人にとっても一般的に使う単語ではないようで、少なくとも私の使う程度の英和辞書には載っていません。
しかたがないので、英語は苦手だけど、Refactoringを分解してみました。Re(再度)Factor(原因・行う・ 因数分解・要素)ing(すること、している)になり、直訳だと「再度因数分解すること」になりますか．．．あってますか?
因数分解とは多項式を整式の積に分解することで、簡単なものだと「X2 + 3X + 2 = (X + 1)(X + 2)」というやつですね。
因数分解の説明のうち
・共通因数でくくる
・公式がある
・因数分解後にさらに因数分解できないかを調べる
・できるところから行う
・降べきの順にならべる
などは、プログラミングでのリファクタリングの考え方に通じます。
プログラミングで考えれば
・共通のものをまとめる。つまり同じことを2度か書かない。
・カタログ集としての書籍リファクタリング―プログラムの体質改善テクニックがある。
・リファクタリングは1度で終わりではなく、繰り返し行う。
・できるところから行う。
・プロシジャを並び替える。
同じ目的のまま理解しやすい別の形に変えるという点で、コードの因数分解がリファクタリングだと思うと理解しやすいでしょうか。
私は、リファクタリングは、「同じ目的のままコードの価値を高める作業」とよく説明しています。
さらに、ファウラーのリファクタリングでは、同じ振る舞いのままコードを改善することとしていて、UnitTestツールを使うことを強く求めています。
私は、オブジェクト指向より、リファクタリングのほうが価値があると思っています。
リファクタリングは学ぶことではなく、いますぐにでも実践できることです。
リファクタリング―プログラムの体質改善テクニック マーチン ファウラー
投稿者 tatsugoro : 10:24 | コメント (0) | トラックバック
2005年05月02日
プロシジャに複数の目的を持たせるな
プロシジャは明確な意味をもって、それのみを行うべきです。
呼ばれるついでに、別の目的のことをやってはいけません。
たとえば、
データベースを操作しているメソッドで画面表示のことをついでにやってはいけません。
初期設定ファイルを操作しているメソッドでキーバインドの変更などということをやってはいけません。
よばれるタイミングが同じでも、別のプロシジャに分けましょう。
簡単なことのはずです。
プロシジャとはほとんどの場合名前が付いた、意味のあるプログラムの塊のことを言います。
VB.NETやC#ではメソッド、関数、プロパティのコードはプロシジャです。