経験が浅いエンジニアの作ったシステムのテストをしていると、やはり品質が悪いなと感じることがあります。
本人からしてみれば出来ましたって感覚なんでしょうけど、少し異常系のテストをしてみるとバグが顕著化したりして、まともに動くのはごくごく一般的なケースでのテストしか通らなかったりもします。
本人の頭の中にはとりあえず動くものが出来たからOKだろうという考えで、ちゃんとテストをしろよとか思ったりもするんですが、経験の違いで生まれる品質の差は作る作業そのものの視点の違いのような気もします。
やった動いた！の感動が打ち消す視点
それはどのエンジニアにもあることだと思いますが、作ったコードが動いたときの感動や快感ってあるわけですよ。
私も一応動くコードが書けたときは口癖のように「完璧！」と唱えたりして、後からぼろぼろ出てきたバグを潰しては同じように「完璧！」って口走ってたりもしました。
まずは、動くものが見たいって感覚に駆られますし、最初は動くものを見ないとなかなか作っているという感覚を得られなかったり、どの辺を作っているのかというマイルストンが頭の中で定まらなかったりもします。
ただそれが強くなりすぎると動いたというところで満足感が得られてしまって、その他のところに気を配れていなかったりもするわけです。
元々、”動かそう”と考えてコード書いているわけなんで、”これやったら動かないだろうな”って視点は頭に無かったりします。
いつの間にか仕様書や設計書の要求を忘れ、自分の中で組み立てた動くシステムそのものが仕様に成り代わってしまったりするわけで。
いや、頭にあってもあまり気にせずにまずは動くものをという視点が先に来てしまいます。
解消しないバグが出てイライラするよりは、すっきり動くものを見たいという方が頭にあるのは当然かもしれません。
ただ、その視点にとらわれることでシステムの正常形だけを見て、くさい物に蓋をするように異常系の観点を見落とすということは多い気がします。
脱初心者エンジニアのための品質管理の視点
品質を上げるにはテストを重点的にするってことはありますけど、やっぱりそれはつまらないものだったりもします。
テストケースやテストプログラムを書くことって、動くものを作るというところからかけ離れている気がしますし、自分の頭の中にはそんなものが無くても正しいコードがかけるって変な自負があったりもしますし、まずは動くものを作ってみてみたいという衝動はそんな地味な作業をすることの感覚を超えてしまうことも多々あります。
よくテストケースやプログラムを先に作らせようとすると、技術的にどうすればよいかわからないのでとりあえずプログラムを書いてみましたって言う人がいますけど、視点がまったく逆転してしまっていたりします。
そもそも、どうやって動くコードを書くかや何が正しいかをしっかりと検証するためにテストケースを作ったりしているのに、先に頭の中にある曖昧なコードを書いてしまっているわけです。
テストケースやプログラムは仕様を正しく理解していないと作れませんが、その効能を忘れてひたすらに自分の頭の中で正しいと思われるコードを書き続けているわけですから、仕様漏れや正しいコードがかけていないというは当然出てきたりもします。
あと、バグなんて出たときに直せばいいという考えの人もいるかもしれませんが、実際に運用開始後に出たバグの修正ってリリース前に作業するよりも格段に面倒なステップを踏まないといけなかったりもしますし、バグが出たときにというのはバグが出ないことを願っているという不確かな願望が込められてたりもしています。
明らかに設計ミスであるのに「そんな使い方しないでください」って逆ギレしているエンジニアを見たこともありますけど、こうなってくると全くあべこべで、自分の頭の中で考えた動くシステムそのものが仕様になっちゃってたりするわけです。
コードを書くって行為も、コードが動いたって感動も、正常に処理できるシステムを作った場合も、異常な処理に対して例外処理を正しく返すように作るって行為も、システムを構築するって行為の中の1つの要素であり、1つのタスクではあります。
ただ、作る楽しさは目に見えて動く（しかもよりユーザー視点に近いところ）にとらわれがちになりますし、利用者の立場からブラックボックスになるところって、エンジニア視点でも曖昧にとどめておくようになってしまいます。
それがシステム全体のパフォーマンスに影響したりセキュリティなどより重要な要素に影響したりはするんですが、そういったところを考える楽しさというものは最初の方はあまり気にしません。
システムそのものを動かすって視点とレイヤーの違いにより、その品質そのものに関連する意識も大きく異なってくると感じます。
[PR]
[PR]