一般社団法人 全国個人事業主支援協会

COLUMN コラム

こんにちは。篠原です。

最近はプロジェクトの引継ぎなどで、他の方が書いたプログラムを改修しながら執務に当たることが多いです。
他の方が書いたソースコードを見ていると、自分には思いつかなかったスマートなアプローチで処理を行っていたり、知らなかった書き方があったりと、大変勉強になっています。

その一方で、これは…と一言言いたくなってしまうコーディングを見かけることも多いです。
私自身こだわりも強い方なので、あーだこーだと細かいところが気になってしまう性分なもので…。

構造化のススメ

ところで、「よいプログラム」とは一体何なんでしょう?

さまざまな答えがあると思いますが、私が思うよいプログラムとは、構造化されたプログラムであるということです。
「構造化されている」とは

  • 要件上統一すべき処理が1箇所にまとめられている
  • 変更が発生しうる箇所は、相応の拡張を行う余地がある
  • 処理のスコープが明確になっている

ということだと考えています。

要件上統一すべき処理が1箇所にまとめられている

業務システムに関わる身としては、

  • ある画面ではこうした入力ができるのに、他の画面では入力できずにエラーとなるのはなぜ?
  • 対向システムの仕様が変わったので、修正をお願いしたい

といった要求がたびたび起こります。
これらは共通処理として適切にサブルーチン化を図ることで、影響範囲を大きく狭めることができます。
同じ処理を行うロジックが、まるっとコピーされてさまざまな箇所に散在していると、こうした処理を行っている箇所を全て洗い上げ、修正をしなければなりません。

この辺りの構造化に関しては、経験則的な「あるある」ネタであったり、変更の入りやすさといったリスク予測のもと、適切な粒度が決まっていきます。
現場に合わせて上司や現場責任者にアドバイスいただくのが良いと思います。

変更が発生しうる箇所は、相応の拡張を行う余地がある

プログラムと密接に関わるインフラ構成情報や、プログラムの動作に必要な認証情報は、プログラムにベタ書きをせず、設定値として外出しを行い、ソースコード自体の改変をせず一極集中的に変更ができるようにコーディングすべきです。

前述した共通処理についても、とある画面だけはこんな処理を追加で行いたい、というケースがあります。
その場合も、クラスの継承関係を利用したりすることで、共通処理に+αを記述できる拡張性を残します。

処理のスコープが明確になっている

使用されている変数が必要以上にグローバルなスコープに設定されていることがあります。
これは意図しない変更の可能性を高め、ソースコードを難読化する原因になります。
基本的に変数のスコープは狭くなるようにコーディングしましょう。
例えば、JavaScriptにおいてES6が使用できる要件であれば、 var ではなく let, const を積極的に使用したいものです。

またJava使用者の方は、クラス・フィールドのアクセス修飾子 public, private を深く考えず決まり文句のように設定していたりはいないでしょうか。
クラスの継承関係とprotectedや、パッケージ階層と修飾子なしのクラスなど、指定の仕方次第で設計思想や要件を反映したアクセス制限をコンパイラーレベルでかけることが可能です。
これにより、クラスの役割分担を明確化し、モジュール間が疎に保たれ、自然とソースコードもわかりやすく整理整頓されるので、おすすめです。
これは最近、Javaで特定処理のライブラリを製造する案件で生きることとなりました。

まとめ

細かい例は挙げたらキリがありませんが、今回は「よいプログラムとは何か」ということを私の認識で記載しました。
次回はそうした構造化プログラムを行う助けになるテクニックやツール使用法を記載したいと思います。

The following two tabs change content below.

篠原 透

2015年より企業SEとして勤務し、Javaを中心とした業務系Webアプリケーションの設計・開発・運用を経験。2019年2月に独立し、個人事業主となる。

最新記事 by 篠原 透 (全て見る)

この記事をシェアする

  • Twitterでシェア
  • Facebookでシェア
  • LINEでシェア