いつも以上に頭ん中推敲もせずに書いてるので斜めに読んでくださいませ。
考えながら書いてるから、多分文体も激しく乱雑ですし(苦笑
発端は、最近見たいくつかの…ソースっつかクラス群っつか、まぁそんな感じのひとかたまり。
全体が10だとすると、大体６くらいの仕様を詰め込むのにぎりっぎりで(締め切り日程もかな〜りバーンしたしねぇ…)、残りの４は「まず乗らねぇだろうっていうか無理だろう」という感じ。
ただ…おそらく、作成者は「追加できる！！」って言い張るだろうなぁ、というのが一つ。
一方で「すでに、細かい変更やら追加やらだけで四苦八苦してぐちゃんぐちゃんになっていた＆かなり莫大な工数かけてた」のもまた一つの事実。そこから「乗せられないか、或いは、出来るにしても膨大な工数を費やす」可能性は否定出来ない(ついでに、あちこち仕様確認ミスによるバグが溢れてたし)ってのが一つ。
そのあたりをまとめると。
とりあえず「とあるソース」があって。これはどこにでも。
その「とあるソース」は
・簡単に追加/修正が出来るレベルの要求
・トリッキー＆工数は食うが、なんとか追加/修正が出来るレベルの要求
・ほぼ無理
という流れを経るんじゃないかなぁ、と予想。
特に、一端「なんとか」の流れにはいると、大体「加速度的にメタボ化して」身動きが取れなくなる事が、少なくとも過去を見ている限りでは多々。
っていうか「なんとか」に入ってから「ある程度でセーブできた」のを見た事がない。大抵、奈落の底まで真っ逆さま。
概ねそこら辺の流れを経て「…んぢゃ、汚いソースってなんだろう？」「そも、本当に追加は無理なのかなぁ？」ってあたりを思考してみたくなったのが、この記事の原点。
「汚いソース」の定義を、一端
・機能の修正や追加が(極度に)やりにくい
と仮定。
「なぜ」機能の修正や追加がしにくいのだろう？
まず。よく耳にする
・ドキュメントがない
・コメントがない
については２見解。
一つ目。
「何をしているか」については「スキルを上げてソースを読む」で終了。
ビット演算程度を見て「何をしているかわからない」とか言われても困るし。その辺は学ぶべし。
「ソースコードから生成できる程度のクラス図」には全く興味なし。ソースコードから生成出来るってことは「そのプログラムに書いてある」のだから、読めばよいだけなので。
「あったらより読みやすい」についてはYesなので、コメントにしてもクラス図にしても「あれば好ましい」とは思うけど。ただ「ないと駄目」なものではないと思う*1 *2。
二つ目。
「何をしたいか」及び「どんな経緯でこうなったか」は、どうやったってソースじゃわからんので*3。
このあたりについてはドキュメント切望。「こんなことしたくて書いてみました」なコメントも大歓迎っていうかむしろMust。
無い場合、本質的には「パストコグニション(過去視) ＋ 読心」あたりの超能力が不可欠。
あなたが「完璧なパストコグニションと潜在意識までも微に入り差違に入り読み取れるような読心」が出来ないのであれば、それを他人に期待しちゃいけないとボク思う。
つぎ。
「既知のアルゴリズムを知らないからひねり曲がったトリッキーなコードになる」は概ねNG。
globalは昔から嫌いだけど、switch文が思った以上に危ない事に気付いた今日この頃。
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E8%87%AD%E3%81%84
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
あたりが面白い。
つぎ。
「１つの修正に対して、修正箇所が多い」は、ありがちで、かつ、どこまでも困った状況。
初手の組み立て(設計)が悪いと、どうやっても「ある処理を一箇所にまとめる」のが困難になり。「やむを得ない場当たり」が積み重なって、自重崩壊スパゲティへの一途を辿る。
そこを冷静に考えると。
おそらく「初手の、一番の大枠の組み立て」の時点でおそらく「修正変更に対する許容量」が決まっていて。
それを使い果たした時点で「作り直し」しなきゃ駄目なんだろうなぁ、って思う。
という事は。
「修正変更に対する許容量」に対する、目安でもいいからある程度の数値化とか指針とかが出せると。
そのプログラムが「適切なのか」「適切じゃないのか」が見えるのかもしれない。
一応念のため。
「修正変更に対する許容量」は、大きく取るほどプログラムの難易度が上がるので == お値段が上がるので。
「適切な」許容量が一番大切だと思われます。
さて…この雑感をどうやって生かそう？(苦笑
