calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
categories
archives

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

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

追っ手から逃れるシステム(きしだのはてな)を見て。過去に、それらの逃げ手の手口にことごとくハマった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 の場合の処理)
}
}
}
}
}


見にくすぎる。ツッコミ所を挙げるとすると
‐魴錚舛半魴錚造糧縦蠅魏寝鵑笋辰討鵑里茵
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でした。いや、むしろ辞めたい。



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


今日の変数名

今日、職場で見つけた変数名。
int buyMoney; // 買金額
int saleMoney; // 売金額
は中学生からやり直したまえ。

普通こっちでしょ。

すばらしきソースコード

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

日雇いPG

ここ一週間ほど、外勤先でなく、本社での勤務のsugarballです。しかも残業ナシ。まさにヘヴンだね、オーイェッ。

ところがどっこい、これには素直に喜べない事情がありまして。

年末、年始のsugarの作業時間が300h/monthペースだったこともあってかどうかわからないけど…外勤先の大企業(の子会社)さん、この年度末の決済で「お金が無い」とか言い始めたんですよ。

それで、不足分を休暇にして下さいとかいう対処方法で、sugarは外勤先を一週間ほど休みになりました。つまり、その期間中は『仕事が無くなった』わけです。

sugarの勤める本社に事情を説明すると、「外勤先が休暇になった期間は本社で働いて下さい」とのこと。おかげで、仕事にあぶれるという最悪の事態にはならずに済んだわけですが…。


以下、かなり感情的に言いたいを書いたので、読んでて気分悪くなるかも。罵詈雑言だらけなので、見たくない方はこちらから別ページへどうぞ。


3連休。。。

あー、疲れた。25日中、24日出勤してたsugarballです。しかもデフォルト終電のおまけつき。

とまぁ、そんな感じでもうボロボロなsugarballですが、ようやくまともに3連休を休めそうです。だって、外勤先からの出勤要請を断りましたので。

え?「そんな事をしていいのか」って?だって、「3連休のうち、どれか1日出勤してくれ」って言われてもねぇ。この疲労困憊な状態で1日出勤したところで、工程が進むかどうかなんて疑問符だし、月曜日が重要なマイルストーンってわけでもないんですよ。先は長いので。。

さて、久々にゆっくり寝ることができそうです。さぁ、携帯の電源を切って寝るとするか。。

勤務時間 Burn up(適当)

過負荷で頭がモヤモヤなsugarballです。結局、先週の勤務時間85時間だったんですけど。このペースで1ヶ月働いたら 85×4 で 340h/month …。倒れるかなー。いや、倒れる前に家庭が破綻するかなー。

あぁ、いかんいかん、暗い話ばっかりだ!!事実を書くのはいいとして、話が暗い方向に持っていくのはダメだ!


えと、気をとりなおして。sugarは外勤先で働いておりますが、そこでは360°の周囲から『もっと作業しろ、生産性あげろ、急いでやれ…』というプレッシャーがかけられるわけなんですよ。

でも、今回のブログの冒頭でも書いたように、85h/week の作業時間をこなしても、逆に効率下がって余計に時間を消費すると思うんだけど。。。明らかに、過負荷です。今の外勤先は人間の体調と作業効率なんて頭に無さそうだし。何時間働いても効率が落ちないロボットが働いてるのではなくて、人が働いているってことが念頭に置いてない。。ひょっとして、『コキ使えるだけ使っとけ』みたいに奴隷のように考えてるんじゃないの。。

あぁ、ダメだ、また話が暗い方向に…なんか最近人格暗くなってきた気がする。。これも勤務時間どっさりの影響なんですかねぇ。なんか、人間としてものすごい損をしている気がするぞ。

・・・これに関して思うところを書くとA4用紙を10枚でも20枚でも書けそうなので、今日はこの辺で。眠いし。まあ、近いうちに書きますよ。

ちなみに、作業時間と効率に関する情報はデマルコ師匠(*)の本を読んでみてはいかがでしょうか。この業界ではヒヨコ同然のsugarですが、この本はぜひともPMやPLの方たちに読んでいただきたいです。っていうか読め。。そう言いたひ。

明日も仕事なんで、今日はこの辺で。。

(*)「師匠」って呼んでるのはFujiharaさんの影響ですね。。

すぱげってぃ・こーど その後1

あー、今週すでに60時間以上働いている…ブルー入りまくりのsugarballです。今週終わる頃には労働時間が80h/week になっていそうです。これ以上がんばりたくないんですけど。。

例のスパゲッティ・コードをいただいてから、ちょうど一週間経ちました。忙しすぎです。いくら案件が佳境に入っているとはいえ、この負荷はちょっとヤバめです。なんとかしないといけないのですが、なんともできないのが悲しいところです。

こんなに忙しい原因のひとつとして、例のソースが挙げられるのですが…リファクタリングというか、Cプログラミング診断室の格好の例題(言語はJavaですが)という感じです。もし読者投稿できるなら、即掲載されそうなソースです。

せっかくここまでひっぱっているので、近日中にブログでソースを晒してプログラミングのお勉強をしたいと思います。だって、苦しめられた腹いせに何かしたいじゃないですか。それが人のサガってもんです。人間小さいとかいうツッコミは勘弁して下さい。

それに曲りなりにもプログラマが書いているブログなので、一度くらいはそれらしいことをしときましょう。

あー、眠くなってきた…というわけで寝ます。

すぱげってぃ・こーど。

最近愚痴ばっかりのsugarballです。人間小さくなってきた気がしますが、まだまだ続けます。

sugarballは外勤先で働いておりますが、そこは魑魅魍魎の世界です(言いすぎか)。

午後8時に「これ今日中にやっといて」とかゆー不条理な命令なんて日常茶飯事です。いぇい。

え?まだ普通ですか。それじゃ「できるまで帰ってはダメです」ってオプションが付けばどうでしょう。

うーん、まだよく聞く話だ。いや、でも見積もって、仕様確認して、設計して、実装して、試験すると普通に終電無くなるんですが…。


まぁいいです。普通の状況ならいいです。仕事だからsugarはがんばります。問題はそんときにスパゲッティ・コードを渡された場合はどうすんねん、ってコトです。

それも「コレ、こういう風に動くようにして、○○の機能も追加しててね。そうそう、元のソースの流れは変更しないようにね」という指令も追加されます。

依頼の前に何も知らされないコトが多いので、sugarは何も知らないままク○プログラムを受け取って、解析から始めるのですが

なんじゃこりゃ

この○ソったれコードの流れを変更しないでそのまま追加しろと?

このスパゲッティ・コードの流れを変更しない意味なんてあんのか…?しかもご丁寧に改定履歴まで振ってある…。元々ソースを書いた人は、sugarの外勤先の大企業の社員さんなんですが、正直、何もしないで居て欲しいです


今回は、その社員さんに見積もりした時間(どう考えても今日中なんて無理)を伝えて…あんまりわかってないようだったので説得して…それでも食い下がるからタスクの1つひとつの見積もり時間を説明して…「でも、今日が期限です」と抜かしやがるから…その仕事の出所に見積もり工数の根拠を説明して…ようやく帰りました。

ただ、そのときの仕事で何が一番工数がかかるかというと、その社員さんが書いたスパゲッティコードをリファクタリングすることだったりするのですが。

| 1/2PAGES | >>