技術の空洞化
自称Javaが出来る人でも設計書をまともに書けない。
先週は社内の諸事情からプログラミングをする機会を得た。
既にプロパーによってプログラム設計書は記載済で、製造工程以後を担当というもの。
早速プログラム設計書を見てみると…。
会員No登録チェックメソッド(引数int型で会員番号)：戻り値はなし
- try-catch宣言をする。
- try-catch宣言をする。
- try-catch宣言をする。
- Connection conn = new Connection();
- PreparedStatement pstm = new PreparedStatement();
- ResultSet rs = new ResultSet();
- DBに接続する。
- pstm = conn.prepareStatement(strSQL);
- pstm.setString(1, 会員番号);
- pstm.executeUpdate();
- conn.commit();
- 異常をcatchする。
- エラーメッセージを出す。
- rsがnull以外の場合、クローズする。
- pstmがnull以外の場合、クローズする。
- connがnull以外の場合、クローズする。
- 異常をcatchする。
- エラーメッセージを出す。
- rsがnull以外の場合、クローズする。
- pstmがnull以外の場合、クローズする。
- connがnull以外の場合、クローズする。
- 異常をcatchする。
- エラーメッセージを出す。
- rsがnull以外の場合、クローズする。
- pstmがnull以外の場合、クローズする。
- connがnull以外の場合、クローズする。
上記を見れば分かる通り、問題点が山盛りなものだった。
まず、変数宣言のスコープ位置の問題より、想定の動作を出来ない。
try-catch宣言する前にconn、pstm、rs変数は宣言する必要がある。
次に、記載レベルが統一されていない。
その為、strSQLにはどういった文字列を渡せばいいのかが不明。
そして、設計ミスがある。
Stringを設定するメソッドで、数字の会員番号は設定出来ない。
最後に、不要なロジックが多い。
finallyを使えば非常にスリムに記載出来る。
で、上記を設計者に伝えたのだが、「この設計書は既にレビューも通っているから、直せない。変なところは、文意を理解してコーディングして」という回答…。
仕方がないので、実行するSQLの内容を聞いて、以下の様にコーディングした。
public static void 会員登録(int 会員番号) {
Connection conn = new Connection();
PreparedStatement pstm = new PreparedStatement();
ResultSet rs = new ResultSet();
try {
conn = getConnection(DBに接続する);
conn.setAutoCommit(false);
pstm = con.prepareStatement(実行するSQL);
pstm.setInt(1, 会員番号);
rs = pstm.executeUpdate();
conn.commit();
} catch (Exception ex) {
con.rollback();
エラーメッセージを出す。
} finally {
if (rs != null) rs.close();
if (pstm != null) pstm.close();
if (conn != null) con.close();
}
}コーディング後、レビューしてもらったら、バグ15件と言われた。
理由はプログラム設計書と異なる実装をしている為とのこと。
プログラム設計書の通りに実装すると動かないと言っても「それはお前の技術の無さのせいだろ！」との回答。
本当にこれでJavaが出来るとは本当に呆れてしまう。
30分程かけて、何故動作しないのか、eclipseのエラーメッセ―ジも見せて、やっとプログラム設計書の間違いを認めたものの、何故かバグという指摘は撤回されないまま。
その結果、チーム内で最も低品質なプログラムを書く人間との謗りを受ける結果に…。
自動試験より手動試験の方が優れているという妄想を持っている。
Javaで作成するなら、JUnitで単体試験を自動化するというのは必須と言っても過言ではないのだが、JUnitを誰も使っていない。
もちろん一斉配布されているeclipse環境には、JUnitのjarが入っている状況でだ。
年配の人に言っても、「JUnit何それ？ 知らない」「自動で試験しようなんて手を抜くんじゃない！ どうやって品質担保するんだ」というありがたい回答をいただいたので、入社してまだ数年の面々に聞いてみると…。
「JUnit何ですか？ 知らないです」「うーん、自動で試験する方が手間じゃないですか？ コーディング量とか」「手で試験した方が確実ですから」という既視感が非常にある回答をいただく。
仕方がないので、1人だけでJUnitのテストケースを書いていた。
生産性向上する努力をする＝ズルをしているという認識を持っている。
JUnitで単体試験を作っているので、単体試験の消化はJUnitを使っていない人間よりも断然早くなる。
結果、定時であがろうとすると、呼び止められて「暇ならこの関数も作ってけ」と言われて担当するものの、結局JUnitを使うので、自動化出来る分再試験の手間が低いことから他の面子よりもやはり試験の消化が早くなる。
そんなことを繰り返しているとあれよあれよという内にいつの間にかいくつものメソッドを担当することに。
それでも定時であがりそうになると、他人の仕事を手伝えと仰る。
ブレイクポイントで1つ1つ止めていくのは非常にめんどくさいので、手伝う分もJUnitでやろうとすると「ズルしてんじゃねーよ！」という罵声が何故か飛んでくる。
生産性を向上させる為の努力がどうしてズルになるのか、非常に疑問だ。