システム開発の現場に配属された後、初めの頃はコピー＆ペーストで実装してきた方も多いでしょう。
しかし、コピー＆ペースト実装が許されるのは１～２年目まで！
3年目ともなれば、そろそろ「あるべき姿」を視野に入れつつ作業することを求められます。
むしろコピー元、お手本になるようなものを作らなければなりません。
この記事では、既存システムの改修における実装について、注意すべき点を説明します。
ベテラン勢は長年の経験から身に付けていますが、なかなかまとまった情報としては教えてくれないものです。
改修時の心得として、頭の片隅に入れておきましょう。
影響範囲は限定・特定する
改修案件は、すでに本番稼働しているものを変更する作業です。
そのため、求められた場所以外は手を加えないのが基本です。
しかし、どうしても共通部分を直さなければならないケースも存在します。
その場合、どうすればよいのかを解説します。
影響範囲を調べる
泥臭い方法ですが「grep」を行うのが、最もお手軽で確実です。
それなりの機能をもったテキストエディタ（例：サクラエディタ）であれば、階層すべてのソースに対して特定キーワードで抽出できます。
大量に検出された場合は大変ですが、エビデンスとなること、職場環境に依存しないことが強みです。
洗練されたIDEであれば、ソースコード解析があるので楽です。
一般的にはこちらが使われるでしょうが、１点だけ注意が必要です。
それは、IDEが「ソースコードを理解している人が、楽をするためのツール」であるという点。
ソースコードの理解が追いついていない場合、むやみに利用するのは個人的には推奨しません。
初心者の中には、コンパイルエラーの原因解決を試みる際、IDEが勧めるまま無邪気にクラス追加してしまうことも…。
便利ツールは、意味をちゃんと理解してから使うようにしましょう。
影響が出ないように拡張する
少しテクニカルな方法になりますが、「オーバーライド」「オーバーロード」を駆使して、似て非なるものを作り出す方法があります。
- オーバーライド：継承先クラスで定義の上書きをする
- オーバーロード：同名で違う引数のメソッドを定義する
作りすぎると混乱するので避けた方が良いですが、拡張には便利です。
右に倣う
改修において独創性は必要とされません。
同じような機能であれば、同じようなコードであることが求められます。
むしろ同じような機能なのにコードが違うと「何か理由があるのかも？」と深読みが必要になるかもしれません。
特に困るのは障害が発生した場合です。
修正しなくてはならない、でも、同じような機能で別のコードになっている…。
そんな時は仕方がないので、それぞれのコードを読み込んで内容をしっかり理解し、その上で間違い探しをしてから修正をする必要があります。
そんなことばかりやっておかげでコードを読むのが上手くなりました^^;
手間がかかる、それなりに経験や慎重さが必要になる、と良いことがありません。
既存のソースの調査は面倒だったり、満足のいく品質ではなかったり、クリエイティブな仕事をしたくなるかもしれませんが、まずは右に倣うことを検討してください。
実際のところ、既存のソースを読み込むことが多くなるので、慣れないシステムの場合は勉強にもなります。
実稼働しているシステムを修正するのだから、今の状態くらいは把握に努めないとイカンでしょ、という話
ソースコードは読みやすくする
多くの現場において、設計書とソースコードは一致しません。
これを一致させようとすると多大な工数が発生するためです。
さらに、一致させたところで８割くらいの情報は利用されません。
これらを踏まえて「読みやすくする」コツを説明します。
高度な技術は使わない
必要とされる技術力と比較して、高度な知識が必要な技術は使わない方が良いです。
必要とされる技術力が不明な場合、システム自体の業務的な重要性で考えてもよいでしょう。
お金を利用するもの、大量データを扱うもの、命に関わるものは重要性が高いです。
上記以外は、重要性はさほど高くないです。
一般的に、社会的インパクトが大きいシステムには高度な技術を持つメンバが割り当てられます。
社会的インパクトが小さいシステムは、それほど知識のないメンバが割り当てられます。
知識のないメンバでも改修、運用できるように、必要以上に高度な技術を利用することは避けましょう。
泥臭い実装をした方が、良いかもしれません。
ソースコードだけで理解できるようにする
コメントを使うだけでなく、ある程度、処理をまとめて１メソッドにしましょう。
設計書の項目単位が目安です。
実装者にとって、基本設計や詳細設計は、「あるべきゴールに関する情報」というだけでなく、「実装前に考えた実現の算段」となります。
基本設計や詳細設計が存在しない場合でも、実装するときには結局、同じ工程を踏むことになります。
大枠から詳細へ落とし込んでいくのは訓練が必要です。
「概念」を理解し「具体化」する過程であるため、大変難しいです。
苦手を感じるのであれば数多くの「概念」を理解する訓練をした方がよいでしょう。
ちなみに「哲学」はそういった訓練をするための学問なのだとか。
モジュール化する
人間は長文を理解するのが困難です。
そのため、なるべく１機能を小さくした方が良いです。
Zip化のロジックを他の業務ロジックと混ぜて書いてはいけません。
Zip化のロジックだけを別にして、業務ロジックからは使うだけ、という形にしましょう。
モジュール化のコツは「入力」「出力」をメインとし「プロセス」は呼び出し元から見えないものとして扱うことです。
つい「プロセス」を一生懸命考えたくなりますが、それは最後の楽しみに取っておきましょう。
影響範囲の調べやすくする
多くのプロジェクトにおいて、コーディング規約があります。
その中では以下のようなものが挙がっていることが多いです。
- マジックナンバーを使わない（ソース上で「==10」とか脈絡のない数字を使わない）
- 変数名は意味のある言葉を使う（int a とかだと用途が分からない）
これらは、読みやすさもありますが、影響範囲を調べやすくするという意味もあります。
「==10」が「==ACCOUNT_TYPE」となっていれば、「ACCOUNT_TYPE」の実際の値が変わった時の影響範囲（利用箇所）を調べることが用意です。
「public」にも注意してください。「public」は「外部からアクセス可」を意味するので「public」修正後は、外部すべてを調査する羽目になります。
まとめ
既存システムの改修における実装について、注意すべき点を説明しました。
聞いてみれば当たり前のことばかりだったと思いますが、聞かないうちは意味のないルールに感じていたかもしれません。
過去の経験からルール化していることが多いので、疑問に思ったら、「ルール化した経緯」を確認してみるのがよいかもしれませんね。
