2015年10月16日

「プログラミングルール」


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





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.ルールがすたれた理由


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

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


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

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

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





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

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

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



この記事へのコメント
牧野眞一 様

いつも楽しく読ませてもらっております。

「ルール」について改めて考え直す機会になりました。ありがとうございます。

世の中には、「理不尽なルール(約束)」が多くあると思います。

それでも「ルール」として存在するという事は必要である、という事ですね。

私の持論も込みですが、
理不尽に感じるルールがある場合は、それをひっくり返す「誰もが納得出来る新しいルール」の提案が必要と感じてます。

それが出来ずに「理不尽さを愚痴る」「諦めてしまう」という事はしたくないなぁと改めて感じました。

中川覚郎
Posted by 中川覚郎 at 2015年10月17日 00:36
中川覚郎様

訪問、ありがとうございます。

いつも、お読み頂き、ありがとうございます。

私も「ルール」について、考え直す機会になりました。

確かに「理不尽なルール(約束)」は、多くあると、私も思います。

理不尽をひっくり返す「誰もが納得出来る新しいルール」は、世の中を、より良く出来ると感じました。

ありがとうございました。
Posted by 牧野眞ー at 2015年10月17日 06:21
上の画像に書かれている文字を入力して下さい
 
<ご注意>
書き込まれた内容は公開され、ブログの持ち主だけが削除できます。