DXの設計書㉓ – 既存システムの機能拡張

既存システムを機能拡張する場合、
他の機能への影響を考える必要があります。
一般に「ちょこっと機能を足すだけ」と思われがちですが、
既に存在する処理に新たに処理を加えていくのは中々骨が折れます。
今回は既存システムの機能拡張についてご説明します。


優れた仕様はシンプルです。
凝集度、結合度という言葉があります。
プログラマーは全員凝集度を高く、結合度を低くしようと心がけます。
と、思っていたのですがそうではないようです。

Wikipedia – 凝集度

凝集度は、あるコードがどれだけそのクラスの責任分担に集中しているかを示す尺度である。
オブジェクト指向プログラミングでは、クラスの凝集度を高めるようにそのクラスの責任範囲を設定することが有益とされている。
凝集度の高いシステムでは、コードの読みやすさと再利用の容易さが増し、複雑さが管理可能な程度に抑えられる。

Wikipedia – 結合度

結合度(けつごうど、カップリング、coupling)とは、コンピュータープログラミングで用いられる(機械よりは)人間寄りの尺度。ソフトウェア測定法の一種。
利用者またはメンテナンスをする者にとって対象を利用、保守しやすいように対象の内容が整理、分割できているかどうかを、その状態によって段階に分けて表現する。

凝集度や結合度が考慮されているソースコードは可読性と再利用性が高まります。
関数単位で再利用することもあるでしょう。
クラスやファイルを丸ごとコピーして別の仕組みに転用することもあるでしょう。
アプリケーションにちゃんとインターフェースが実装されていれば
元々狙った役割以外にも活用できたりします。

プログラマーたるもの
誰にでも役割が理解しやすく明確で、
他への影響が少ないものづくりを目指したいものです。

出典が何か失念しましたが良いインターフェースを
切っても血がでない。
と、誰かが表現をしていました。
うまいと思います。


例えば、ある変数の値を変更する処理を加える時、
どこまで影響するのかわからない場合があります。

複数のスレッドが動いていて
グローバル変数で定義されたフラグや変数で管理されているケースなどです。

同期をとるタイミングは不定でどのタイミングで値が書き換えられるかわからない。
全ファイル検索し影響範囲を調べた上で修正することになります。
同じ変数を違う意味で使いまわしたりしているものは悲惨ですね。笑えます。
コメントには言い訳やTODOが残っていたりします。

// こうしておかないと何故か落ちる
// TODO 後で何とかする

たった一人で長い間メンテナンスしてこられたのでしょうね。
誰かにもレビューしてもらうこともなく、とりあえず動けばよいというスタンス。
今にも崩れそうなジェンガ

データベースを使うような仕組みも上々です。
僕はフローチャートとかを見せてもらっても機能の外観を捉えることはできません。
きちんと設計されたテーブル定義とリレーション図を見るとシステムの動きがなんとなくわかります。

しかし、テーブル定義書やリレーション図がメンテナンスされていないと各カラムが何を意味するのかわかりません。

ある日を境にDummy1カラムに値が入ってますけど・・・?
カラムの説明がテーブル定義書ではXX区分ってなってますけど意味は?

カラム名から推測するには無理があります。
データの意味を知るにはデータをテーブルに挿入される処理から
ユーザーが入力するところまで遡って追わなければなりません。

ダブルミーニングは最早メンテナンスできる気がしません。
身長のカラムですけど68って何?みたいなやつですね。
処理を見ると、さも当然のようにコメントが書いてあります。

// XXの場合は体重を入れる

ご存知の通りソースコードに関連する仕様書はありません。
非常識な常識。


既存システムを拡張する難易度は元の設計に依存します。
とはいえ、何も考えずにリプレイスというのは芸がありません。
技術力が自分の方が勝っているとしても、モノマネがオリジナルに勝てることはありません。

リプレイスはマイナススタートでゼロを目指しますが、
機能拡張はゼロスタートでプラスを目指します。
拡張するのかリプレイスするのか、その選択は非常に重要です。

古いシステムのソースコードを開いて舌打ちし
機能拡張で行くべきか・・・作り直すべきか・・・
と、ブツブツ言っている人がいれば、おそらく僕です。

DXの設計書㉓ – 既存システムの機能拡張

おわり

PR

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です