時間が無い時でも必ず行いたい事


怪しいプログラムが出来上がった時には、怪しいものであるという認識を持ち続け、怪しいソースのどの箇所が怪しいか、その範囲を覚えておく。


プログラムの全てを知っている人はいないと思います。

勉強はもちろんするのでしょう。

しかしそれで全て何とかなるほどプログラムの世界は狭くありません。

ほとんどの人はいくら勉強してもプログラムの勉強に終わりが無いと認識しているでしょう。

そして大概新しいプロジェクトに関わる度に新しい何かに挑戦しなければならない事が出てくるものです。

もし出てこなければそれはたまたまラッキーだったか、あるいはそうなるようにマネージャーが仕組んだのかもしれません。


ここでさらに納期までの制限時間が加わると、どうしても怪しいプログラムが出来上がる事があります。

制限時間の件についてはここでは何らかの理由により伸ばせないものとします。


怪しいプログラムが出来上がるのは仕方がありません。

毎回挑戦が待っている以上100%納得がいくものができるはずがないからです。

初挑戦のもので最適なコードが書ける人は見たことがありません。

おっと、あくまで私の見た範囲の話なので鵜呑みにはしないでください。

才能のある人はいると思いますので。


さて怪しいものが出来上がるのは仕方がないとして、それを納得してはいけません。

必ず怪しい箇所を大体の範囲でいいので把握し、そして怪しいものがあったという認識を持ち続けましょう。


言うまでもありませんが後で役に立ちます。

険しい顔をしたお客様が文句を言いに来た時に素早く対応しなければなりませんね。

ここでもし、どこが原因か分からないなどという事態になったらお客様との縁の切れ目が待っているかも知れません。

怪しいと把握している範囲を真っ先に調べましょう。


なぜこんな事を書くかというと、私も含めて怪しいものを納品したら厄介払いでもしたかのように努めて忘れようとする人がいるからです。

気持は分かります。

分かりますが、そこはぐっと堪えましょう。

問題が出た時に何が問題なのかさっぱり分からず、泣きを見るのは避けたいですね。

 メモ書き程度の内容を。

 あとで書き直すかもしれない。


 初心者さんがプログラムを作り、ひとしきりバグに悩んだ後にこういうのを教えてあげると

喜びます。


 バグの少ないコードの書き方があるよ。


 実際教えてあげると困った顔されちゃうんですけれどもね。

 教えてあげているのは以下。


 ソースコードをきれいに書く。


 これだけです。

 実際どうやってきれいに書くのかは後ほど紹介するとしてなぜコードをきれいに書くと

バグが少なくなるのか、なんていうのは当たり前過ぎて突っ込みを入れられそうですが

とりあえず書いてみると以下になります。


 コード上で何が行われているのか分かり易い


 これに尽きます。

 当然と言えば当然ですが、コードが汚ければ何が行われているのか分かりづらい訳です。

 となればバグが潜んでいても分かりづらく書いた本人にしてみればよく分からない不具合

が発生し易い訳です。


 では私が行っているきれいなソースの書き方を紹介したいと思います。

 カーニハン先生の作法も取り込んでいたりしますが基本的には個人的に考えたものなの

で使う場合には自己責任でお願いします。


・コメントから書く

・識別子の名前をちゃんと意味を考えて付ける。グローバルは長い名前、ローカルは短い名前。

・ソースコードの横幅は横スクロールさせない程度の幅にする。長ければ適度に改行させる。

・条件分岐やループなどは3重や4重などの深い階層になるべくしない。

 これらは階層が深くなった途端に処理の把握がし辛くなる。したがって処理が間違っている

可能性が上がっている。

 この状態になったら一度ソースを見直し、単純化できないか考えなおす。

 分岐は別々の分岐にしたり2つの分岐を1つにまとめられないかなど。

 もちろんどうしても必要な場合というのもあるのでその場合には慎重にソースを書くこと。

・構造をしっかり考える。これは構造化プログラミングやオブジェクト指向を学ぶ必要があるので

 すぐに始められるものではないが頑張れば見返りが大きいので価値は高い。


 とりあえずこれを基本的に行っています。

 先にあげたカーニハン先生の作法はこの本を参考にさせてもらいました。


http://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E4%BD%9C%E6%B3%95-%E3%83%96%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3-%E3%82%AB%E3%83%BC%E3%83%8B%E3%83%8F%E3%83%B3/dp/4756136494/ref=sr_1_2?ie=UTF8&s=books&qid=1228328756&sr=1-2


 1章が参考になります。

 先生ありがとう。

 今日もなんとかプログラマをやっています。

プログラムにおけるコピペと言っても数行コピーするものから1つのファイルを丸ごとコピーするまで範囲は色々ですが、今回はファイルを丸ごとコピーする場合の弊害について一言。

 といっても1人のしがないプログラマが色々な現場を見て回ったという個人的な範囲内なので世間的にはもっとまし、だったりするんですかね。


 プログラムのコピペは本来は面倒なものだったりします。
 プログラムを作るにはそこで何が起こっているのか理解しなければなりません。
 当然コピペの元になっているソースは基本的に全部読んで何が起こっているか理解しなければなりません。


 例外的なものはもちろんあったりして、それらはコピーされる事を前提に作られたテンプレートだったりします。
 テンプレートは基本的には中身を知らなくても構わない作りになっている事がほとんどですし、使い方の説明が付いていたりもします。
 いちいち解析するぐらいならテンプレートなんて使うより自分で作った方が早い場合がありますもんね。

 ですがテンプレートでないものはそういう訳にはいきません。

 もし一部分だけ読みそこだけ修正、残りはまったく読まずにコピー元からそのまま持ってきて貼り付けただけだったりしたらどうなるでしょうか。
 作った人の思い込みはともかく、誰にも結果は予測できません。
 プログラムは1行何か追加されただけで結果が変わる可能性があるものです。
 上記で書いた修正が、コピペされた残りの部分に影響しないと言えるでしょうか。
 また逆に、コピペした部分が修正箇所に影響を与えていないかとも言えます。
 私の見た現場では、ソースファイルを丸ごとコピペして部分的に修正した結果、書いた本人にしてみれば原因のわからないエラーがよく出ているという有様でした。



 コピペ元のソースを読まないのは楽をしようとしているのでしょう。
 何となく言葉の端々や雰囲気からはそんな感じがうかがえます。
 「そのソースコピーしてちょっと直せばいいよ」なんて感じで。
 でも残念ながらプログラムとは面倒で楽をさせないようにできています。
 機械言語やアセンブラから高級言語に移りさらに統合された開発環境が提供されてなお人にとってプログラムを作るのは大変な作業です。
 テンプレートは無いが参考にするソースがあるような場合、正しく(少なくともプログラマの考えた通り)動作させなおかつ楽をしたければ以下のようにするのがせいぜいだと思えますがどうでしょうか?


・1ファイル丸ごとコピーしない。ソースファイルを作るのはあくまで自分。
・基本的には自分で書き、必要な個所だけ部分的にコピーさせてもらう。ただし、コピーするものについてはきちんと解析し自分の血と肉にしてからコピーする事。


 私はJavaではEclipseを使っていますが、ソース解析のためだけにプロジェクトを一つ作って動作確認しています。
 余計な処理を含めずに書けるので正しく理解し易いですし、ついでに動かした時の動作が速いので動作確認を早く終わらせる事ができますしね。


 つらつらと書きましたが私が現場で見たコピペの弊害はこんなところです。