”真実一路”の牧野眞一です！！

今日は、いつも楽しく読ませて頂いているメルマガから【「プログラミングルール」】を紹介致します。





1．ルールのでき方


世の中にはたくさんのルールがあります。
道交法から、ちょっとしたマナーまで。

会社内にも、評価制度や就業規則、掃除当番なんかもルールに入るでしょうか。


どのルールにも共通するのは、ルールが存在する理由があることじゃないかと思います。

その理由の中で上位に入るのは、過去のトラブル対策じゃないかな？
お心当たりありませんか？



2．プログラミングルール


以前働いていたIT企業でもいろんなルールがありました。

システム開発現場にもプログラミングルールというのがありまして、プログラムを書くときの規則が決められていました。


プログラミングルールは、何故できたのか？


実は、私も知りません。
入社時にすでにルールがありましたが、形骸化していましたので。


実務を振りかえって推測すると、
(1) プログラミングの最低品質を担保するため
(2) 保守の効率を上げるため
ではなかったかと思います。

書くと長くなったので、ここでは(2)の保守効率についてだけ書きます。

(1)が気になる方はブログに書きましたので、良かったらこちらを。
Http://gc-llc.jimdo.com/2015/08/25/%E3%83%A1%E3%83%AB%E3%83%9E%E3%82%AC%E4%B8%8B%E6%9B%B8%E3%81%8D/



3．保守の効率を上げるため


たいていのプログラムは販売後または納品後、お客様のところで不具合が発生して、プログラムを直さなければなりません。

機能の追加や改善のために、プログラムを変更することもあります。


その時、開発者が社内にいるとは限らないのです。
定着率の低い業界でしたので、退職や異動などの理由です。

長くご利用いただいているシステムでは、開発者が定年退職していたなんてことも。


こんな場合に、プログラムの変更を容易にするため。
つまりは、他人が見ても理解できるプログラムを書くため、プログラミングルールが存在したんじゃないかと思います。


自分が過去に作ったプログラムでさえ、解読に苦労することがあるぐらいです。
人が作ったプログラムはなかなか読みたいものではありません。



4．ルールがすたれた理由


私の過去の職場では、プログラミングルールは形骸化していました。

だからかどうかわかりませんが、保守効率の問題は、私が在籍中にも何度か発生していました。


自社で作ったルールでも、ルールを作った理由を受け継がなければそんなもんです。

他社からコピーしたルールだったら、よほどの理由がないとあっという間にすたれそうです。

ルールを守ることが目的に変わってしまうんだと思います。





※『ルールは、なぜあるのか』という根本を、考えさせてくれる内容だと思います。

一度作られたルールは、なかなか無くなることは無いように思います。

そうすると今後、雪だるま式にルールが増えていくとしたら・・そんなふうに考えてしまいました。