メンテナンスしやすいコードとは何だろうか?
こんにちはnasustです。
プログラマの仕事をしていると、自分的に多いのがゼロからの開発ではなくて、 途中参加して、機能を追加することが多いです。
そして個人的にアプリや小規模のWebサービスの開発に関わる事が多いです
この時困るのが、コメントやドキュメントが無い場合が多いです。
こういう仕事の場合、コードが理解しやすいかで仕事の難易度が決まることです。
個人的には、コメントやドキュメントが無くても構わないです。コメントやドキュメントは、 度重なるバージョンアップでロジックの実態を表していない場合があるので、有ろうが無かろうが、 コードを理解する為にどのみち読んだりしますので重要視していないです。
しかし、コード自体がスパゲティであると、とても理解するのに困難になります。
ゼロからの開発に関わっている開発者であれば、理解しているかもしれません。 しかし、途中参加であれば理解するのが困難なので、機能を追加するのが大変です。
では理解しやすいコードとは
全てがシンプルで、一貫性のあるコードです。
文章で表現し辛いですが、理解しにくいコードというのは迷路のようです。 くねくね曲がり食って、街の未計画的な道路のように目的地に付くまでの道順が分からないようなものです。
逆に分かりやすいコードは、答えまでの目的地までの道順が分かりやすい事です。道の曲がる回数も少なく、 分かりやすい場所で曲がる為にたどり着きやすい、そんな感じです。
この辺の理解出来やすいかは、UIの設計に似ていると思います。分かりにくいUIは、目的の機能まで辿り着くのが大変ですが、 優れているものは、簡単に操作できます。
メンテナンスしやすいコードとは
一貫性を持たせるの一言です。ですが様々な開発者が作業する為に一貫性を保つのが大変です。 コーディングルールというレベルでは無くて、構造の設計の仕方などの問題です。
現在の開発は大抵オブジェクト指向ですが、クラス設計の良し悪しが強く属人的な為に一貫性が保ちにくいです。
僕が出会った最悪のクラス設計した開発者は、派生クラスを作る度に、親のクラスに派生クラスの共通コードを追加していた事です。 クラスの抽象化という概念が抜けています。これでは派生クラスをメンテナンスする度に、親クラスのメンテナンスが必要になります。
素晴らしい開発者は、こういう間違ったクラス設計はしないと思います。しかし実際の現場では、出来る人できない開発者が混じり合って開発していきます。
これらを防ぐために、ペアプログラミングなどしますが小規模ですと実施も難しいです。コードレビューも適切に指摘する人がいなければ、ぐだぐだです。
では、こういう構造的問題が出やすい環境でメンテナンスしやすいコードにするには、オブジェクト指向を止めるという選択肢もありだと思っています。
オブジェクト指向のクラスの抽象化という作業は、属人的すぎるので品質を保てないと思います。 その代わり、プロトコル指向で開発することで品質を保ちやすいじゃないかと思っています。
オブジェクト指向は素晴らしいですが、実務に関しては人類には早すぎた概念かもしれません。誰もが使いこなせるとは思えないです。 クラスの抽象化という作業は、自分の頭で想像出来ていても、第三者にはとても理解しにくいです。また抽象化が適切であるのかという議論も泥沼化しやすいです。
クラスはシンプルに機能の塊にします。
プロトコル指向では関数の設計だけなので誰でもある程度の品質のものが出来きて、第三者でも評価しやすいと思います。
現実の機械や電子部品などは、規格が決まっている為に、様々な会社が同じような部品を開発しても、同じように動作する事が出来ます。 プロトコル指向では、インターフェイスの規格を決めることが出来るので、コードの構造をある程度一貫性を決められる事が出来るため、メンテナンスしやすいです。 また、常に分かりやすいようにソースコードをリファクタリングしていれば、メンテナンスしやすいです。
最後に
だれか凄い人が、誰もが理解しやすいプログラム言語を作って欲しいです。色々妄想で考えるですが、妄想すら到れないです。
自分が欲しい機能のコードが勝手に出来上がる未来が欲しい。
関連記事
