すばらしきソースコード

現在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万円引かれるかどうかという緊張感を持って仕事できていなかったのも事実でした。とにかく、こんな失敗はもう犯さないよう、肝に銘じておきます。今回のは、未然に防げた可能性が非常に高いので…


はてな。

はてなの方のブログに色々書き込んでみる。

以前、プログラミングに関する話題だけを扱おうとしたが、無料ユーザはアフィリエイト不可だから断念したやつです。で、それが下のURL。
http://d.hatena.ne.jp/sugarmemo/

はてなの方にはsugarballのメモとか、sugarのアンテナにひっかかった事柄とか日常の事を書く予定です。思った事をダーっと書いてあるだけなので、内容は薄いですが…

というわけで、気が向いたら読んでやって下さい。

あ、当然こちらのブログは続けますんで。


ありがとう

いきなりですが、sugarは話下手です。克服しようと、些細なことから実践していたりします。

それは、コンビニなどで買い物をした後、レジのおねーちゃんに「ありがとう」とお礼を言うことです。

レジのおねーちゃんがかわいかったりすると(別にかわいくなくても男の店員でもいいのですが)、やる気120%アップな感じで普通に「ありがとう」と言えます。

でも上手く「ありがとう」と言えない。

sugarがやると、どうも「ボソッ」と暗い感じの挨拶になってしまう。
レシートとお釣りを受け取りながら、しかも視点がそのレシートとお釣りなので、うつむき加減になってしまう。これではただの暗いオッサンです。

これでは、言われたレジのおねーちゃんもあまり嬉しくなかろう。

わざわざ声のトーンを上げて言うのも気恥ずかしいし、何かいい方法は無いだろうか、としばらく考えていました。

で、なぜそんな「ありがとう」になってしまうか考えていて、『言葉と行動が伴っていない』ことが原因という結論にたどり着きました。

sugarの場合、口では「ありがとう」と言いつつも、態度が落ち着かない。極端な話、恥ずかしがってモジモジしている小学生みたいなモンです。本当に小学生ならいいのですが、いい年こいた25の男がレジで「ありがとう」一つ言うのに苦戦するのもどうかと思いますが…

そんな態度では店員が『ありがとうって言われた~』的な気分になるわけがないですね。

それならば、どうやって「行動を伴う挨拶を言うか」ですが、、、

まず、相手の顔(目)を見て、次にスマイル。スマイルは最重要項目です。多少恥ずかしいですが、笑顔全開でスマイルする必要はありません。少々、機嫌が良い程度の顔でいいのです。

そうすることによって、なんと声のトーンまで自然に高くなって、相手にプレッシャーを与えなくなるという2次効果が発生します。

これによって、『あなたから買い物できて嬉しいよ~』的な気分を店員さんに伝えることができます。

これで売った側も買った側も、ちょっとハッピーな気分になれてメデタシメデタシ。

で、ふと思ったのですが、同僚(時には上司)と仕事を進めるとき、言葉だけでなく、このようなボディランゲージも交えた方が円滑に進むのかなぁ、と。

別にスマイルまでしなくてもいいと思いますが、こういう小技がもたらす効果は結構あなどれないような気がします。


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




本文中広告