【プログラム開発】コード設計の原則を理解しよう!一歩進んだプログラマーになるために!

システムが動くプログラムは実装出来るんだけど、なんかコードがキレイじゃないんだよなぁ。。。

こんにちはJun(@JunNomad)です。

プログラマーとしての経験を重ねてくると、システムとしては動くんだけど、なんか実装がしっくりこないといった感情を持つ方も多いのではないでしょうか。

プログラマーとしてスキルアップするためには、ただ動くシステムを実装するのではなく、メンテナンス性や拡張性の高いコードを実装することが重要なポイントとなります。

本記事では、プログラムのコード設計に関しての基本的な考え方について、ご紹介していきたいと思います。

具体的なコードを掲載するわけではないため、概念的な部分を学びたい方向けの内容です。

プログラムにおけるコード設計の原則を理解しよう!


プログラムは顧客の要望通りに動くシステムが完成し、テストが全て完了してバグが無くなれば一つの完了ではありますよね。

ただ、それだけで果たしてプログラマーとして完璧な仕事をこなしていると思って良いのでしょうか?

システムはプログラマーが実装を完了した時点で終わりというわけではなく、実装完了後からこそ利用が始まり、機能改善や機能追加が行われることも少なくありません。

メンテナンス性

システムが動き始めた後も、不具合改修はもちろん、機能追加などにより様々なプログラマーがコードを触る機会が出てきます。

あなたが実装したコードは果たしてメンテナンス性の高いコードとなっているでしょうか。

システムを改修するプログラマー達が、プログラムを隅から隅まで読み込まないと理解出来ないようなコードではメンテナンス性に優れているとは言えません。

コード設計がおかしいために、改修した部分と全く関係ないところにバグが生まれるようなコードは、実装時点で埋め込んではいけません。

拡張性

実装したコードは拡張することも容易でしょうか。

あなたが実装した以降、どこに影響するのか分からない、誰も理解できないようなコードで実装していては、システム自体は動いていても優れたコード設計とは言えません。

誰が見ても分かりやすく、拡張しやすいコードで実装することがプログラマーとしてのスキルの見せ所でもあるでしょう。

コード設計の大原則とは


コード設計の大原則として「DRY」「YAGNI」「KISS」という3つの考え方が存在します。

DRY

DRYは「Don’t Repeat Yourself」の略称で、同じコードを色々なところに実装しないように心がける考え方です。

ファンクションやメソッドなどで再利用出来るようなコードを実装して、なるべくコード量を減らすことで再利用性の高いプログラムを実装します。

YAGNI

YAGNIは「You Ain’t Gonna Need It」の略称で、必要なコードだけを実装する考え方です。

当たり前と思うかもしれませんが、意外と不要なコードが紛れていたり、無駄な処理が組み込まれたシステムは多いものです。

KISS

KISSは「Keep It Simple, Stupid」の略称で、簡潔にコードを実装する考え方です。

DRYやYAGNIと同じように、シンプルなコードが分かりやすいという概念から、無駄なコードは実装するなという意味合いですね。

プログラムの規模が拡大する前に「SOLID」の原則を確認しよう


上述した3つの考え方はプログラム開発で必ず意識しておくべき原則ですが、システムが大きくなってくると更にプログラムが複雑になってきます。

複雑なシステムに対応するには、応用的な考え方である「SOLID」と呼ばれる原則についても理解しておきましょう。

SRP

SRPは「Single Responsibility Principle」の略称で、日本語訳では「単一責任の原則」と呼ばれています。

モジュール・クラス・関数といった機能がそれぞれカプセル化されており、単一の機能だけに責任を持てば良いようなコード設計を指します。

OCP

OCPは「Open Closed Principle」の略称で、「開放/閉鎖の原則」と呼ばれています。

既存のソースコードを変更することなく、振る舞いを変更出来るようなコード設計のことを指し、拡張には開放的でありながら、修正に対しては閉鎖的なコードを実装することを意味します。

LSP

LSPは「Liskov Substitution Principle」の略称で、「リスコフの置換原則」と呼ばれています。

派生元の型と派生先の型に成り立っていなければならない関係性について、1993年にリスコフ氏が発表した論文からこの名前がついています。

ISP

ISPは「Interface Segregation Principle」の略称で、「インターフェース分離の原則」と呼ばれています。

インターフェースの大きさを具体的な機能毎に細かく分割することを推奨する考え方で、ユーザーが使用しないメソッドに依存するようなインターフェースは実装すべきでないというコード設計手法です。

DIP

DIPは「Dependency Inversion Principle 」の略称で、「依存性逆転の原則」と呼ばれています。

モジュール単位を疎結合に保つことを目的としており、「上位モジュールと下位モジュールは相互に依存せず抽象モジュールに依存すべき」「抽象モジュールは詳細モジュールに依存せず、詳細モジュールが抽象モジュールに依存すべき」という考え方です。

さいごに:コード設計の概念を意識しながら実装を繰り返すことが大切


本記事では、プログラム開発におけるコード設計の基本についてご紹介してきました。

概念的な内容になるため、頭の片隅に入れながら、自分自身で実装したり、他のプログラマーが書いたコードをたくさん読むことで深い理解に繋がっていきます。

まずは基本となる今回の内容を把握した上で、実際のコードからどのような使い方がされているのか自分自身で確認してみてください。

タイトルとURLをコピーしました