バグが多いプログラマーの特徴やソースの書き方とは?

 

システム開発でも新規開発あれば、何もない状態からプログラムを組んで構築していくわけなので、楽ではあります。
が、途中からプロジェクトに入った場合は、誰かしらが作ったプログラムの修正、改修を行うことがありますよね。

 

人によって、プログラムの書き方が独特であったり、たまになんでこんなロジックにしたんだろう??

ってことがあります^^;

 

私ももちろん、これまでに、誰かが作ったプログラムを解読して改修を行ってきました

 

私は経験がないのですが、バグが多いプログラマーの人ってどんな特徴があるのでしょうか?

 

バグが多いプログラマーの特徴

 

私が思うにはバグが多いとは、そもそも設計書通りに作られていないもしくは、単体テストをしっかり行っていないということです(笑)

 

単体テストがしっかり出来ていなくても、その後の結合、システムテストで実データを使って検証すればたいがいは、障害となってわんさか出てくるはずです

 

と、同じ機能ばかりで障害ばかり発生すると、やはり作成した人が疑われますよね?^^;

 

ちゃんと、単体テストやったの!?

 

 

って感じで(笑)

 

 

ということで、バグが多いプログラマーの特徴は以下の点

 

 

1.ソースコードがそもそも見づらい

 

これ、自分はわかっても、後から修正などが入った場合、相手がこのプログラムでは何を処理しているのか?

わかるようにコーディングしなければなりませんが、構文はあっていても、コメント欄がなく、どこに○○の部分が記述してあるのか・・

 

 

探すのに一苦労。。という書き方は不親切です^^;

 

 

あとは、スペースを半角スペースでやってるのか、tabキーでやってるのかバラバラで統一性がなかったり、改行がへんてこりん^^;

 

あぁ、見づらい!!疲れるorz

 

ちゃんとした社内教育を受けていれば、こんなことはないのですが、ごく稀に、そんなプログラマーが書いたソースと出会うこともあるのです

 

 

ここからは、この人プログラマーとしてあんまり・・バグ多そうだなと思った特徴をもった人です

 

 

Sponsored Link

 

2.単体テストをおろそかにしている

 

単体テストだし、あとでバグが出たら、修正すりゃいいじゃんって軽いノリで仕事をしているプログラマーもそうですね

 

本当に、自分が作ったプログラムが仕様通りの作りになっているか

 

単独のテストではありますが、ここをしっかりしておかないとあとのテストで大変なことになります
バグが出れば、プログラムを見直し、修正してまた再テスト。

 

修正した部分以外の影響範囲テスト

 

 

新規作成した時の作業よりも作業が増えております

 

 

なので、バグが発生すると、修正した箇所以外にも、影響範囲のテストを行う必要があるのでバグは出したくないものですが、こうして、単体テストを甘くみていると、あとでこういった
痛い目に合うのです

 

 

これ、どこでわかるのかというと
テストが終わった時点で、
一度、確認して頂けますか?

 

レビューはしないのですか?

 

こういった一言があるだけで、
できる、できないってわかるのですよ^^;
※あくまで私の観点ですが。。

そして、3つめは

 

 

・設計書の内容、仕様を把握していない

 

 

顧客でも設計者でもいいのですが作った本人が、仕様を把握していない

どんな処理をするプログラムなのか人に説明できないようであればこれもまた要注意です

 

 

ですから、こういう人はそもそもプログラマーの仕事自体、理解しておらず、重要性がわかっていないのです

 

もし、一緒に仕事をしていてこんな方々がいましたら、要注意

 

ご自身がまず、こうならないようプログラマーの仕事をおろそかにせず、ひとつひとつの作業に責任をもって取り組みましょう

Sponsored Link

ABOUTこの記事をかいた人

私の最終学歴は、高卒(県立)です。 田舎から東京へ行き、フリーターを2年経験。 21歳の時、未経験で正社員のプログラマーに!! 正社員として2年半、その後転職して フリーランスとしてシステム開発の仕事を6年半。 合わせて9年間行ってきました。 要件定義~納品。運用保守まで担当。 主な言語は、PL/SQLです。 現在は、理由(ブログでご覧ください)があって サービス業に従事(薄給です泣) もし、現在の仕事で悩んでいることがあればお気軽にコメント、ご相談ください^^ 経験者として少しはお役に立てるかと思います。