■
とりあえずﾌﾟﾛｸﾞﾗﾏﾚﾍﾞﾙを見極める際のｵﾚ的注視ポイント。
(1) コメント付け
(2) メソッドの中身
(3) クラス構成
見極めはソースが全て。
ソースを見たらどんなレベルかは大体判断つく。
何を考え。何を思い、何を解して生み出したソースであるか。
概要を把握した後、口頭の質疑応答で残りを判断できる。
コメント
よく語られてるので簡潔に。
無いのは論外。
ソースコードの日本語翻訳のみってのも形式次第。
ソースコードと同居していて双方に意味がある形式が望ましい。
ちなみに。
ある程度知識と経験をつけたプログラマが陥ってしまうことがある。
(,,ﾟДﾟ)＜コードが十分にシンプルならコメントなんていらんのですよ
コードを読む力がついたころにこれにｺｺﾛを奪われてしまう者たちがいる。*1
が。しかし。
重大な、そして盲目となったものには見えないないが目の前にある事実がある。
『ソースコードはシンプルなだけのものでは成り立たない』
必ず少量の複雑さを込めないと成立しないのだ。
とりあえずでもつけときゃいいやんと。
コメントの無いソースの9割9分9厘がこ汚いソースである現実を知るものとしては
コメントの無いソースを美しいと感じる前に、恐怖を感じる対象なんだというのに
心を配れるだけの器量を持つに至っているかどうかの判断ポイントにはなる。
メソッドの中身
機能がてんこもりな１メソッドってのを作るやつは間違いなく要修行者だ。
この業界によくいてる「言語だけさわれます」レベルのプログラマ入門生。
世の中の営業さんは出来る人が多くて、こんなレベルのに付加価値をつけて売ってくるんだから
たいしたもんだとようやく思えるようになって来ましたよ。いやもちろん皮肉ですが。
そんなのをあえて語っても世にある意見の範囲は超えれないので忘れてみて。
ソースの目に付くところは
コメントもさることながら、
インデントと空白のとり方だ。
4タブ計算で、ソースの始まりが7タブからとか、8タブからとかありえないし、
がっつがつに空白が無いようなソースは読みにくさ抜群だ。
それらには「必然性」が無いからあかんといわれる。
なぜそうなるか、なぜそういう形態をとるのか、とらねばならないのか。
これらに明確に答えられなければそれはロジックではない。
たんなる惰性である。
長いソースを作る者がいる。
そういう傾向にある者は、まずメソッド分割を嫌がる。
ヘッダコメントをつけ足したくないという理由で、新たなメソッドを作成しない。
苦労して動いたものを分割して整理することに拒絶反応を持っている。
もしくはその発想すらない。
めんどくさいからやらないって理由にしろ、
発想がないって理由にしろ、
やれば出来るんだと本人は思うかもしれないけれども、
要修行者から抜けれる理由にはならない。
言語の得手不得手こそあれ、ソースの仕分を行う者は行う。
不得手であっても、そのうちコツを掴む。
整然とした形態であるから、修正も楽だし、
何がダメで何がいけるかを試すのに適しているために本人の学習効果も高い。
ソースの作り方は各個人で千差万別。
しかして理想形は数少ない。
ソースはロジックを組み上げる作業であるがゆえに、
雑然としているソースにまともなロジックが組まれているなどと考えることなどどーしてできようか。
ちなみに世の教科書やプログラム本で見てきたほぼ全ては雑然としている。
あからさまにダメソースってのもある。
クラス構成
機能分割をする際にどこで区切っているのだろうか。
「機能」を「ソースの範囲」として捉えた場合、
クラスとメソッドの構成をどうするかってのは間違いなくプログラマの腕に依る。
シンプルな実装、シンプルなコードを実現したいと願うものにとっての実現形は自ずと決まる。
メソッド数は間違いなく増えるのだ。
クラス数も間違いなく増えるのだ。
数が増えれば管理や把握が大変になる。
コードはシンプルでもメソッド数に悩まされることもある。
これを出来る限り回避するにはコメントによる把握補助が必要になる。
ちなみにおいらの作ったソースの1ファイル内の行数の内訳をみてみると、
(a) メソッドのヘッダコメント*2＋メソッド宣言そのもの（引数込）
(b) 実ソースのみ
この2つの割合は大体２：８前後、
(a)にソース内のコメントを含めると２：８〜３：７前後になってた。*3
もちろん上の数値はテキトー抜粋した数値なので一般的とはいえないかもしれない。
しかして、1:100とか1:200以上のバランスを持つソースの多くが美しくまとめられているとは思えない。事例もみたことがない。
間違いなく1メソッドが長いからだ。
必然として長いのではない。惰性で長くなった結果であることが想像に易い。
1テーブルの項目数が100や200もあるもののSelect文をサボらずに立て並びで書いてみたとかいう
特殊状況なんざめったにないだろう。
メソッド数が多くなれば必然としてヘッダコメントの行数も増えるのは間違いない。
Utilityのようなメソッドも数が増えればUtilityクラスとして昇格し、
それに伴い、吐き出したほうのバランスは(b)の割合が高くなるだろうし、
Utilityクラスだと(a)の割合が高くなる傾向があるだろう。
とはいえ。
単純にメソッド数とかクラス数が増えていればよいのかというと、そんなことはもちろんない。
モデリングのみで構築していく実装ってのは最終的に弊害しかもたらさないクラス構成に陥る。
プログラム言語ほどの柔軟性が無いから、ニッチもサッチも行かない状況にはまり込んだときに
ヘンな対処するしかなくなるのだ。
そうしてオブジェクトの一貫性は失われ、コピーされた同機能が増殖し、
それぞれがあっちこっちで使用されるようになり、
8割方同じなのに細部が違うために統合すら難しいとことになっていく。
クラスは増えどもよいとは限らない状況想定。
クラスの構成にはバランス感覚が大事なのだ。
クラスに役割を当てはめる力。
肥大化するクラスを分割する力。
機能別に仕分ける力。
仕分結果を整理整頓する力。
どれかだけが突出していても、へこんでいてもよろしいことはない。
っとはいうものの
今の世の中プログラマに求められる技量は高い。
実装設計も実装も技術調査も学習も全部こなさなきゃいけない。
それに加えて無理難題がやってくる。
対応しようと思ったら、まず人間的に柔軟性が大事なのかな〜なんて思えてきた。
