外勤先バトル一覧

追いたくなくとも追わねばなるまい

今回はソースコードを記述しているので、プログラミングと関係の無い方にはわからないと思いますが、ご容赦を。

追っ手から逃れるシステム(きしだのはてな)を見て。過去に、それらの逃げ手の手口にことごとくハマったsugarballですが、今回はsugarが遭遇した逃げ手の手口を紹介します。

■参考リンク
http://d.hatena.ne.jp/nowokay/20050702#1120324360
http://d.hatena.ne.jp/nowokay/20050706#1120597321
http://arton.no-ip.info/diary/20050703.html#p01

インデックスiとjで二重ループをまわし、要素jについて0~8まで別々の処理をしているだけなのだが…

for (int i = 0; i < dataNum; i++) {
if(i == 0) continue;
for(int j = 0;j < 8; j++){
try{
(絶対catch句に行くような
データが入ることがある処理)
}catch(NumberFormatException nfe){
if(j == 0){
(j == 0 の場合の処理)
}
if(j == 6 || j == 7){
if(条件A?){
if(j == 6){
(j == 6 の場合の処理)
}else if(j == 7){
(j == 7 の場合の処理)
}
}else if(条件B?){
if(j == 6){
(j == 6 の場合の処理)
}else if(j == 7){
(j == 7 の場合の処理)
}
}
}
continue;
}catch(Exception ee){
System.out.println("例外です!!:" +
オブジェクトをtoString);
continue;
}
if(i > 7) continue;
if(j == 2 || j == 3){
if(条件A?){
if(j == 2){
(j == 2 の場合の処理)
}else if(j == 3){
(j == 3 の場合の処理)
}
}else if(条件B?){
if(j == 2){
(j == 2 の場合の処理)
}else if(j == 3){
(j == 3 の場合の処理)
}
}
}else if(j == 4 || j == 5){
if(条件A?){
if(j == 4){
(j == 4 の場合の処理)
}else if(j == 5){
(j == 5 の場合の処理)
}
}else if(条件B?){
if(j == 4){
(j == 4 の場合の処理)
}else if(j == 5){
(j == 5 の場合の処理)
}
}
}else if(j == 6 || j == 7){
if(条件A?){
if(j == 6){
(j == 6 の場合の処理)
}else if(j == 7){
(j == 7 の場合の処理)
}
}else if(条件B?){
if(j == 6){
(j == 6 の場合の処理)
}else if(j == 7){
(j == 7 の場合の処理)
}
}
}
}
}

見にくすぎる。ツッコミ所を挙げるとすると
①条件Aと条件Bの判定を何回やってんのよ?
②catch句の中で普通に処理すんなよ
③とゆーか、catch句に入るのが前提ってソレは…
④なんか似たような判定ばっかだ。まとめなさい。
⑤とにかく見にくい。というより醜い。

その後日、このロジック内で不具合が発生したので、偶然(というか必然)、sugarがこのコードを修正することになりました。まぁ、仕事でなければこんなコードはドブにでも捨てた方が世のためになるし、見るのも触るのも本気で嫌だったのですが、仕事だから直すしかないわけで。あぁ、サラリーマンはツライね。というわけで、修正したコードが下のやつ。

if(条件A?){
processA();
}else if(条件B?){
processB();
}





////////////////////////////////////////
// 条件Aのメソッド
private void processA(){
for (int i = 0; i < dataNum; i++) {
int j = 0;
///////////////////////////////////
// j = 0 の場合
(j = 0 の場合の処理);j++;
///////////////////////////////////
// j = 1 の場合
(j = 1 の場合の処理);j++;
///////////////////////////////////
// j = 2 の場合
(j = 2 の場合の処理);j++;
・・・ j = 3~7 も同様 ・・・
///////////////////////////////////
// j = 8 の場合
(j = 8 の場合の処理);
}
}
////////////////////////////////////////
// 条件Bのメソッドも同様に…
private void processB(){

}

まず条件Aと条件Bで関数分けして、if…else…で分岐していた処理をインデックスのインクリメントで対応しました。わー、面白いほどスッキリ。

やはりこの前者のコードを書いたのもこのときの彼だったりします。で、sugarが後者のコードに修正すると彼は

「sugarさん、凝ったことしてますねぇ」

いや、シンプルにしただけなんで。

sugarが勤める外勤先ではその彼はJavaのスペシャリストとして他の会社に出向したことがあるらしく…この職場、大丈夫か?と思うsugarでした。いや、むしろ辞めたい。

とにかく、キレイなソースコードを書くことは大事なのです。そんでもって、ソースコードを整理するための指標としても使えるのがこの本。オススメです。ちょっと高いけど、値段に見合った価値はあります。



すばらしきソースコード

現在sugarballは関わっている案件で、不具合修正を依頼されております。

言語はjavaなんですが、ソースコードを見て愕然としました。

ファイル全体の行数は3000行ほど。その中で、700行を超えるメソッドが2つ

こんなのメンテできません。てか、ファイルのヘッダに改定履歴とか製作者が書かれてるのですが、どうやらこのときの彼が作ったソースコードでした。「またお前か!」って思ってしまいました…。

ちなみに、その彼、この時記事の人と同一人物です。

頼むからリファクタリングを読んでくれ。こんな不吉な匂いがプンプン漂うコードを書かれたらメンテする人は大変なんだー、と。

しかも、どう見たってコピペしたとしか思えないような重複コードがあったので、彼に関数分けを勧めても「この方がシンプルでいいんです」とか言い出す始末。シンプルの意味が分からないです。

ならば「コードが長くなるから可読性が低くなって、バグが入りやすくなりますよ」と諭せば「関数分けなんかしたらバグが入り込むじゃないですか。信用できないですよ」とか言い出しやがります。

一瞬、ものすごく殴りたい気分になりました。そんな彼はjava歴3年over。3年間何をしていたのか小一時間問い詰めたくなりました。

PL殿、お願いですから彼を再教育してあげて下さい。もしくは、プロジェクトから外してください。

※すべて実話です。紛れも無く(泣


ふぐあい、じゃなかった。

前回のエントリで書いた、sugarが作りこんだ不具合が微妙な展開になったので、今日はその話を。

その機能追加したシステムを仮に「フットサルコート予約管理システム」とでもしておきます。

JSPによって管理される(この言い方は微妙だが)、いわゆるWebシステムってやつで、ユーザがブラウザからフットサルコートを予約できるシステムです。

まぁ現地につっこんでブラウザで表示するとバグっちゃってた訳ですが。

そんなわかりやすーい不具合なので、不具合が見つからないまま単体試験、結合試験をパスするはずがない…と思いきや、なんと結合試験の後にソースを変更して試験ナシで現地に導入していたことが発覚。なんじゃそりゃ

どれほど入念に試験を行っても、その後で変更してたら試験の意味が無いのですが。

試験後にソースを更新した…なんて情報を不具合発覚後に始めて聞いたという事はプロジェクトメンバー間で情報共有ができてない証拠です。そのようなプロジェクトが運営されている時点ですでにアウトでしょう。

まぁこのプロジェクトのPMさん、PLさんたちはPMBOKを10回熟読してくださいってこった。


ふぐあい。

やっちゃいました。

sugarはあるシステムの機能追加をしていました。

そのシステムが、ゴールデンウィーク中に客先に納品、運用開始されるのですが、客先で不具合発生。sugarが実装した部分です。モロです。

sugarはGW中、妻の祖父母の家に妻と同行していました。まぁ田舎に帰省ってやつです。
本来なら緊急招集されるのですが、sugarは外勤だということで、別の社員がGW中に召集されたようです。出勤してくれた社員さん、ゴメンナサイ

幸い、その社員の手助けもあって不具合は現地で1日程度で改修できた模様。現在も、無事稼動中だそうで。

ここまではいい(良くないんだけど)。

今回、sugarが出した損害は…社員1人日あたり5万円のコストとすると、

・社員の休日出勤          5万
・現地社員の現地対応期間延長  5万×3人
・客先への損害賠償         0万
  ※導入に複数日かかるシステムということもあり、
   想定した期間内に導入は完了した。
sugarが失った信用      priceless

計:20万円+αの損害?
合ってるのか?この計算…

sugarは単体試験のみ行い、結合試験の試験仕様、テストデータ作成などは別の人が行ってたのですが…今回の不具合は結合試験もスルーしちゃってました。

もし結合試験もsugar一人で行っていたとすると、一人で20万円の損害を出していたわけで…次の賞与から20万円引かれちゃったりするのでしょうか。

今回はたまたま機能追加だけで完結しましたが、これが反復型のプロジェクトだったりするとデスマーチに加担することになっていたわけで…

自分のことだけ考えるなら、賞与で20万円引かれるかどうかという緊張感を持って仕事できていなかったのも事実でした。とにかく、こんな失敗はもう犯さないよう、肝に銘じておきます。今回のは、未然に防げた可能性が非常に高いので…


スポンサーリンク
本文中広告




本文中広告