保守性に関する世界観です。
プログラミングにおいて、保守性は重要です。
保守性を高めるということは、「機能やコードの一部分が変わったとしても全体に影響がでないようにする」ということと、「あとあと別の人が見ても分かりやすく保守しやすいコードにする」ということだと思います。
まず、悪しき慣習を避けることが重要です。たとえば、gotoを使わないで関数を使う、グローバル変数を使わないでオブジェクト指向を使う、グローバルな名前空間を汚染しない、0や1といったマジックナンバーを使わずEnum型を使う、などといった、あとあと誰かが見ても分かりやすいコードを書くことに努めることがまず大切です。
また、変数名は適切な英単語を使い、コメントをきちんと書き、ドキュメント化をきちんとすることも大切です。
繰り返しはなるべく避けましょう。ユーザー名やパスワードを設定する箇所はひとつだけにし、設定ファイルの解析を行う部分もひとつだけにします。定数やテンプレート文字列も、繰り返し同じものを使ったり何度も代入したりしないようにします。
また、コードの保守性を高めるためには、再利用性を高めることが効果的です。
すべてをmain()関数に書くのではなく、役割ごとに関数やファイルを分け、再利用可能なクラスやコンポーネントにプログラムを分割し、共通のインターフェースから汎用的にモジュールを使えるようにします。
また、ロジックとデータを分離します。MVCモデルでいうならば、ユーザーに表示するHTMLのビューと、データを格納するデータベーステーブルをまずそれぞれ分割し、それら「データ」と「ロジック」を分離し、ロジックはデータを書き換えなくても書き換えることができるようにします。
また、オブジェクト指向においては、適度にカプセル化して、外部に見えてはならないものをできるだけ見せないようにし、そのアクセスはあらかじめ決められたメソッドからしかアクセスできないようにします。
また、巨大なクラスや巨大なインスタンスで全体の処理を行うのではなく、小さなクラスや小さなインスタンスの関わり合いでプログラムが成り立つようにします。
システムの保守性を高める上で、再利用性は重要です。たとえば、MySQLだけに依存するのではなく、ほかのRDBMSにも取り換えられるような設計にすることで、もしほかのRDBMSが必要となった際にそのコードを再利用してRDBMSの部分だけを変更できます。このように、「全体を変更するのではなく、一部分だけを変更して、ほかの部分には影響がでないようにすること」が、システムの再利用性と保守性を高めます。
オブジェクト指向のAPIにおいても、全体のプログラムを書き直す必要がないように、同じインターフェースのままで実装だけを変更できるようにします。そのようにすることで、もしプログラムの機能が変更されるとしても、その変更を一部分だけに抑え込み、書き直す部分を最小化することができます。
Webフレームワークも参照のこと。
オブジェクト指向のオブジェクトと同様、システム全体も小さなモジュールの集合体として作りましょう。
なぜ、小さなモジュールの集合体として作るのか、それはテストや実験がやりやすくなるからです。
それぞれを小さなマイクロサービスとして実現し、小さなそれぞれの単体サービスをテストすれば、全体としてのサービスも正しく動くことが保証され、実験やプロトタイプ開発が容易であるため開発もしやすくなります。どこに問題があるのかを特定することも簡単になります。
Kubernetesも参照のこと。
実際のところ、保守性の高いプログラムを書ける人間が、よいプログラマであると言えます。
保守性が高いということは、バグが入りにくいということであり、バグが入りにくいということは、セキュリティも高く、安定した、きちんと稼働するシステムを作ることができるということを意味します。
保守性が高いからこそバグが入らないということが言え、バグが入らないからこそさらに保守性が高くなると言えます。
保守性を高めるためにできるもっとも簡単な方法は、「シンプルにする」ことです。複雑なプログラムや複雑なシステムは、それだけで保守性を低くします。シンプルかつ単純なプログラムは、そうでないプログラムに比べて「安定して稼働する」ことが多いです。
なので、プログラムを作る際には、最初からあれこれと考えず、シンプルで単純なプログラムを開発するようにしましょう。保守性が高いということは、拡張性も高いということを意味します。最初のプロトタイプが単機能なものであっても、拡張していけば多機能なものになります。そのように、「拡張可能なソフトウェア」を書くことは、保守性を高める上でよい考えでしょう。
仕事をする上で、再利用性はとても重要です。
なぜなら、あらかじめ再利用可能なコンポーネントを書いておくことで、どんな仕事が来ても、そのコンポーネントを再利用することで、即座にゼロコストで対応することができます。
これは、IT技術やプログラミングだけではなく、デザインにおいても言えることです。あらかじめ作られたアートワークが存在すれば、どんな仕事が来ても、その既存のアートワークを再利用することで、既に作っておいたストックを組み合わせることでデザインを行うことができます。
ですので、仕事が入らない、何もすることがない時は、遊ぶのではなく、再利用性の高いコンポーネントやストックを作りましょう。そうすることで、いつ難しい仕事が来ても、それらの再利用によってその仕事を片付けることができます。
システムを開発する上で、「保守」や「メンテナンス」の言葉が意味するのは、自分で作ったシステムをほかのエンジニアに「引き継ぐ」ということです。
自分で作ったシステムについて、自分が保守をしている段階では、自分の作ったシステムであるため、そのシステムがどのように動くのか、どのように作られているのか、ということがきちんと分かります。
ですが、これを他人に引き継いだ時、その他人のエンジニアがそのシステムをきちんと深く理解して保守できるようになるところまで、考えられるでしょうか。
実際のシステム開発では、このような「引き継ぎ」という問題を、どんなに難しくても考えなければなりません。
なので、できるだけコメントを多く書き、コードだけではなくドキュメント化し、ルールを社内で裁定し、きちんとシステムの動き方や作り方を説明し、それをいつでも参照できるように残しておくことが必要となります。
オブジェクト指向を参照のこと。
オブジェクト指向モデリングを参照のこと。
アスペクト指向を参照のこと。
関数を参照のこと。