それなりの期間SEをやっていれば一度や二度、毎日でもSE向いてないなぁと思うことがあるでしょう。
どんな時にSEに向いてないと思うでしょうか？
わたしがSEに向いてないなと思う瞬間の1つに、プログラミングでバグを埋め込んでしまった時にSE向いてないなぁと思うことがあります。
テストをしていてバグを発見する。調査をして原因がわかると、本当につまらないミスだったりします。
バグを発見する段階にもよりますが、なぜバグを埋め込んだのか？上司やプロジェクトメンバーに通知しなければならない時があります。
あまりにもつまらないミスで言い訳すら思いつかないこともある。そんなミスをやらかすとSE向いてないと思ってしまいます。
プログラミング・コーディングでバグを埋め込んでしまうSEは向いてない？
プログラミングで埋め込むバグは2種類ある
SEの主なお仕事はプログラミングでソフトウェア製品を作ることです。
実際にプログラミングをする作業のことを『コーディング』と呼ぶこともあります。
『プログラミング』も『コーディング』も、どちらも同じ意味です。
しかし、プログラミング工程におけるバグには2種類あるんです。
- プログラミングミス
- コーディングミス
同じように見えて実は違います。
プログラミングミス
プログラミングミスはロジックの組み立て間違いのことを指します。
この手のパターンは論理思考が苦手な人がやってしまいがちなミスです。
論理思考に自信がないという人はむずかしいことは考えないようにプログラミングをしてみてください。最初から効率の良いプログラムを書くのではなく、べた書きで一度書きます。それを何度も見直して効率よくなるように書き直すことです。
コーディングミス
コーディングミスは誤字脱字のことを指します。
これは誰にでも起こるパターンです。単純な誤字脱字程度でバグになるようなソースコードにならないように注意しましょう。たとえば、変数名を命名するときに似たような名前を使わないようにする、など。
『あわてんぼうさん』がやってしまいガチなミスです。
プログラミングで埋め込むバグの問題
プログラミング工程で埋め込んでしまうバグというのはだいたいのパターンで大きな問題にはならないことが多いです。
以前は考慮漏れがあると規模の大きい修正が必要になるということを書かせていただきました。
プログラミング工程におけるバグというのはロジックの組み立て間違いやソースコード上の誤字脱字だったりで、修正が小規模であるケースがほとんどです。
だからといって油断は禁物です。なぜなら、簡単な間違いだけども現象としては致命的かもしれませんし、テストでバグが発見できないということもあります。
また、前工程のバグ、つまり設計段階で入ってしまったバグがプログラミング工程で発見されるということもあります。こういう場合は大規模な修正になることがあります。
あくまでも修正規模が小さいという傾向があるだけで、人・会社へのリスクとしては大きいか小さいか、蓋を開けてみなければわかりません。
なぜプログラミング工程でバグは埋め込まれるのか？
なぜプログラミング工程においてバグが入ってしまうのか？その理由は、
- ロジックを組み立てるのが苦手。
- 単純ミスをやってしまいがち。
- ソースコードレビューで誰も間違いに気づかない。
本人は正しいと思って作っています。問題は意識の外にありますので、何度ソースコードを見直したところでバグは見つけることはできません。
第三者によるレビューに期待したいところですが、ソースコードレビューだと話が細かすぎてなかなか指摘しづらいです。あきらかに間違っている部分は見つけられますが、誤字脱字程度だと見抜けません。
プログラミング工程においてもバグが埋め込まれてしまうのはある程度は仕方がないことなのです。
プログラミング工程でバグを埋め込まないためには？
プログラミング工程でバグを埋め込まないようにするためにはどうすればいいのか？
ソースコードをしてもらうというのはもちろんのことですが、ソースコードの書き方にこだわりを持つことです。
- むずかしいソースコードを簡単にして書く。
- 制御文のネスト(入れ子)を少なくする。
- 1つの関数で1つの役割とする。
- 関数は1画面に収まるように書く。
などなど。こういったことは何度も何度もプログラミングを実践で経験して培っていくしかないでしょう。
その中でもわたしが強く推奨したいのが、『制御文のネスト(入れ子)を少なくする』ことです。
プログラミング工程におけるバグというのはだいたい『条件式が間違っていた』というのが多いです。
たとえば下記のソースコード。
if( A == B && ( C == D || E == F ) ){
処理X
}
こういう場合は下記のように書きます。
if( isG( A, B, C, D, E, F ) == true ){
処理X
}
制御文の中身を関数化させてしまいます。そうすることで制御文だけを切り出してテストすることが可能になります。
ソースコードを細かく切り離してテストして、パーツ単位で品質を確保していきます。品質の確保できたもの同士を組み合わせていくことで、割りと品質の高いソフトウェアが組み上がっていきます。
こういったことは書籍では学べない、実践でしか学べないことです。とにかくひたすらプログラミングする！これが一番です。人によってはプログラミングの作業を割り当てられない人もいるかもしれませんが、もしやる気があるならランサーズやクラウドワークスで仕事を請け負って武者修行してみるのも良いでしょう。活きたプログラミングは実践の中でしか学べません。
完全回避は不可能
プログラミング工程におけるバグの埋め込みというのは少なくすることはできますが完全にゼロにすることはできません。あきらめましょう。
問題が大きくならないようにテストで除去できるようにすることです。そこで見つけられないと…納品後にバグが出て会社の信頼失墜になります。ものによっては会社の経営を傾けることもあります。
SEという仕事をしている以上、不具合とか欠陥とかバグはどうがんばっても切り離せない問題です。どんなにやらかしたくなくてもやらかしてしまう。
出てしまったものはすぐに修正できるようにしておくことです。上司、お客さん、先輩、同期…いろんな人から責められることもありますが、あとはもう耐えるしかない。
元も子もないような話ですがこれが事実です。わたしはミスをしないSEなんて見たことがありません。逆に言えば、特級SEがちょっとしたミスでうつ病を発症し辞めたというのも見たことがあります。SEというかIT業界というのはそういう世界です。
まとめ
- プログラミング工程で埋め込んだバグは単純なミスであり修正規模は小さい傾向にある。
- しかし、目に見える現象としては影響が大きくなることもある。
- テストでも気づかないと後に大きな損失になることもある。
- ソースコードをきれいに書く、簡単にして書くなど、バグを埋め込まない工夫をするしかない。
- それでもバグの完全回避は不可能。あとはストレス耐性を鍛えるしかない。
わたしは新規開発の場合はプログラミング工程でバグを埋め込むことはあまりありません。やらかしてしまいがちなのは誰かが作ったソースコードの改造ですね。
なぜでしょう。みんな1つの関数にすべての処理をつっこみ過ぎなんです。上述したように、1つの関数で1つの役割とさせるべきです。あとは関数を順に呼び出す関数がある、というイメージ。
1つの関数にすべての処理を詰め込むと、役割を切り出してテストすることができなくなってしまいます。すると、テストが不足してしまいバグが大量に発生してしまう。
汚いソースコードはあとから付け足しても汚いソースコードにしかなりません。ですがキレイなソースコードに汚いソースコードを付け足すと汚いソースコードになります。不思議ですね。
郷に入っては郷に従え。プログラミングというのは自分の流儀を反映させたくてもぐっと我慢する作業だったりします。SEは本当にストレスの溜まる現場で働いていると思います。
