ソースをレビューして… (2)
昨日の話と微妙に関連して(･∀･)
色々ソースを見ていて気がついたこと。
.NET初心者(っというかプログラミング経験自体の浅い人)が作るソースの共通した問題点についてです(´・ω・`)
だいたい以下のようなところが共通して分かっていないというか、勘所が無いと感じますね。
- 例外処理の考え方
「Javaと.NETの例外処理の違い」みたいな話だったら、議論にもなって良いんですけどね(´Д`)
いわゆる「ゴールキーパー以外はハンドで反則ですよ」の話ですね。
catchして何もしてない処理があったりとか。
後、catchとfnallyに正しくないクリーンナップ処理が入っていたりみたいレベルの話も…。*1
まあ、.NETでは原則「ゴールキーパー〜」で良いと思うんでむしろ単純に考えてくれた方が良いんですけど。
別の言語なんかで例外処理の経験が無い人が、異常系の扱いで戸惑っているという感じでしょうか。
例外処理一般について言えば奥が深いというか、Effective Exceptionみたいな本は無いものかと思ったこともありますが(´ω`)
- Dispose()
とりあえずusing句を正しく使いましょうということで。
途中でreturnしてるけど、そのケースだとClose()が呼ばれないぞとか、そんなんが結構あったり…。
ちょっと単純な言い方ですが、IDisposableなものはusingで使ってくださいという風に言ってます。
- レイヤ構成
これが一番の問題になるんですが(´・ω・`)
チェック入れないで物を作ってもらうと、画面もデータ処理も一緒くたになったようなソースが出来上がってきたり(´Д`;)
「データアクセスレイヤについてはこう分離する」っていう通知は一応出ているんですが、後から入った人や実際の製造者にまでちゃんと理解して貰っていないようです(´・ω・`)
例えば、1メソッドの中の処理がグチャグチャだろうと致命的な問題では無いですが。*2
最悪、それはメソッドだけを書き換えれば済む問題ですからね。
でも、レイヤがグチャグチャだとどうしようもなくて、保守が出来なくなりますよね。
画面からロジックを呼び出して、ロジック内から直接画面を操作して、そこからまた別のロジックが…みたいな最悪の構成を見たこともありますし(´Д`;)
「スパゲッティコード」とか言いますけど、より明確に言うなら問題は「スパゲッティレイヤ」じゃないかと思ったり。
それにクラスの責務の問題もありますよね。
責務のよく分からないクラスが勝手に追加されたりとかね〜(´・ω・`)
それなりの規模、要員スキルばらばらのプロジェクトでは、クラスの追加は申請式で良いんじゃないかと思ったり。
アーキテクトが判断して、責務が不適切なものは適切な所に処理を移動するように指導して。
画面、ロジック層とか、一覧があるものについてはあらかじめひな形を作っておいて。
スキルの無い人に無理にOOっぽいことをやってもらうすると、かえって訳がわからなくなりますから。
この手のプロジェクトでは、アプリケーションアーキテクチャ自体は(トランザクションスクリプトみたいに)単純にして、ロジック層の粒度を理解して貰うほうが失敗しないやり方かな〜っと。*3
詳細設計として、ユースケースからロジックへの落とし込みも各メンバーが行うわけですし、この辺の勘所を浸透させるのが重要だと思います。
後、思うんですけど、こういうケースで各メンバーに必要なのはオブジェクト指向とかデザインパターンの知識ではなくて、PoEAAとか(ちと古いけど)J2EEパターンみたいなアーキテクチャパターンの知識ではないかと思ったり。
…あ、それを理解するためにはOOの知識も必要なのかしら…(´ω`)
