■

細かい話だ。
ソースの記述方式の差ってのは一つ一つ利点を挙げればとても細かい話だ。

「こういうほうがわかりやすい」
「こっちのほうが勘違いが少ない」
「こっちのほうが記述に便利」

実際にソースを作っている現場にいてようやく理解できるようなあいまいな文章になる。

ゆえに「どこの」「だれに」「どうなんだ」を考えるときに抜け落ちやすい。
プログラム作り大好き人間的には
「ほかならぬ」「自分に」「便利が(・∀・)イイ!」
で落ち着いてしまいたい衝動に駆られるが、
ぐっと我慢するココロが必要である。

・「周囲の」「開発仲間達に」「便利がいい」
・「後にくる追加変更の」「対応する人員に」「調査しやすくしたい」
・「新しく入ってくる」「追加人員に」「受け入れられやすい」
・「ひよっこの」「新入りのために」「敷居を低く設定したい」

などなど、共同開発、人員交代を前提においた心意気をあらかじめ持っておくことは必要である。
心意気は目的意識につながり、
目的意識があれば行動するにあたっての指標ができる。
指標があれば説明しやすい。
合点の行く説明であれば納得しやすい。
納得できれば自身が実行する際に生じる抵抗感はなくなっていく。

努力もしているし、調整もしている。
結果、目的に達しやすくなる。

ソースの記述方式ひとつとっても、
時としてプロジェクトの成否にかかわることになる。
クサレソースの生み出すバグは連鎖する。
周囲にわかりやすく、自分に便利で、新規追加要員への敷居が高くないソース形態であれば、
自分のミスは誰かがカバーしてくれる。
気づかれやすいからだ。
バグが発生しないことはないが、必ずつぶれる。
連鎖地獄に陥らない体制が取れるのだ。
ソースの記述方式をある程度の制約を設けて統一するというのはこんなことをしたいからなのだ。

命名規則は「ここにいる」「みんなが」「理解しやすい形でありたい」ためにあり、
ソースレビューは「仕様変更追加が発生した際の」「時の人員に」「負担かけたくない」ためである。

あいまいな言葉の中に、実用の知識を詰める。
これひとつ、経験の活用といえそうだ( ´∀｀)