こんにちは。篠原です。
最近はプロジェクトの引継ぎなどで、他の方が書いたプログラムを改修しながら執務に当たることが多いです。
他の方が書いたソースコードを見ていると、自分には思いつかなかったスマートなアプローチで処理を行っていたり、知らなかった書き方があったりと、大変勉強になっています。
その一方で、これは…と一言言いたくなってしまうコーディングを見かけることも多いです。
私自身こだわりも強い方なので、あーだこーだと細かいところが気になってしまう性分なもので…。
ところで、「よいプログラム」とは一体何なんでしょう？
さまざまな答えがあると思いますが、私が思うよいプログラムとは、構造化されたプログラムであるということです。
「構造化されている」とは
ということだと考えています。
業務システムに関わる身としては、
といった要求がたびたび起こります。
これらは共通処理として適切にサブルーチン化を図ることで、影響範囲を大きく狭めることができます。
同じ処理を行うロジックが、まるっとコピーされてさまざまな箇所に散在していると、こうした処理を行っている箇所を全て洗い上げ、修正をしなければなりません。
この辺りの構造化に関しては、経験則的な「あるある」ネタであったり、変更の入りやすさといったリスク予測のもと、適切な粒度が決まっていきます。
現場に合わせて上司や現場責任者にアドバイスいただくのが良いと思います。
プログラムと密接に関わるインフラ構成情報や、プログラムの動作に必要な認証情報は、プログラムにベタ書きをせず、設定値として外出しを行い、ソースコード自体の改変をせず一極集中的に変更ができるようにコーディングすべきです。
前述した共通処理についても、とある画面だけはこんな処理を追加で行いたい、というケースがあります。
その場合も、クラスの継承関係を利用したりすることで、共通処理に+αを記述できる拡張性を残します。
使用されている変数が必要以上にグローバルなスコープに設定されていることがあります。
これは意図しない変更の可能性を高め、ソースコードを難読化する原因になります。
基本的に変数のスコープは狭くなるようにコーディングしましょう。
例えば、JavaScriptにおいてES6が使用できる要件であれば、 var ではなく let, const を積極的に使用したいものです。
またJava使用者の方は、クラス・フィールドのアクセス修飾子 public, private を深く考えず決まり文句のように設定していたりはいないでしょうか。
クラスの継承関係とprotectedや、パッケージ階層と修飾子なしのクラスなど、指定の仕方次第で設計思想や要件を反映したアクセス制限をコンパイラーレベルでかけることが可能です。
これにより、クラスの役割分担を明確化し、モジュール間が疎に保たれ、自然とソースコードもわかりやすく整理整頓されるので、おすすめです。
これは最近、Javaで特定処理のライブラリを製造する案件で生きることとなりました。
細かい例は挙げたらキリがありませんが、今回は「よいプログラムとは何か」ということを私の認識で記載しました。
次回はそうした構造化プログラムを行う助けになるテクニックやツール使用法を記載したいと思います。
入会申込
ログイン
