■
ソースの形態が保守性に優れている形式になっている。
からといって、すんなりメンテナンスされるわけじゃない。
メンテナンスをすんなり行うためには何か要る。
先日こんなよな会話があった。
相手：(,,・Д・)＜そういやいつぞやのプロジェクト、大変なことになったらしいっすよ。
オレ：(..´Д｀)＜まぢで。
(,,・Д・)＜仕様を全部知っている人間がいないとか。
(..´Д｀)＜うわぉ。
(,,・Д・)＜バグ修正をスーパークラスでやってるとか。
(..´Д｀)＜まぢで？
(,,・Д・)＜ボクはあかんゆーたんですよ？けど時間がなくてやったらしくて、後からえらいことに。
いわゆる「やってもーたプロジェクト」の気配が濃厚です。
なぜなになんで？
忙しい時ほど、１つの修正に対して「やっつけ仕事」を行わない。
時間が無い時ほど、クラスの関連性を調べる。
目先のコード修正をして万が一問題なく済むなんていう賭けをするのは、
リカバリを行って余りある時間のゆとりが許されている時だけだ。
っという今の自分がある。
ソースコードの概略を読み、構成を把握し、不具合のポイントと、修正の影響範囲を調べる。
簡単に言い換えると「事態を掌握する」ことをする。
いわゆる一般的な手法を語るとき、
事態を掌握している事が「最速最善の１手」への道であると胸を張って言い張る。
タイトロープを走って渡るとか、
青信号を待てず、でもこわいからといって横断歩道を目隠ししてダッシュするとか、
万人が成功しない手法によるたまたまの「最速」なんてのは必要ない。
でもなんでやってしまうのだろうか。
それがキケンと知らないからだ。
もしくは自分の願望と現実の判断が付いてない状態に陥っているかだ。
こうなった旗振りの元にあれば、
ソースのメンテナンス性やコードの再利用も無用の長物だろう。
これらによる利点が目に入っていないし、理解できる知識もない。
ゴチャいわれて*1、時間がかかって*2なんて手法は「使えない」としか思わないだろう。
観点はだいじだ。
