ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

イノウーの憂鬱 (23) 特訓

»

 休日の人気のないオフィス。
 どちらも独身の男女。
 手を伸ばせば触れられる距離。
 シチュエーションによっては、甘い何かが発火しても不思議ではないが、今、このときに限っていえば、その可能性はゼロに近いほど低かった。
 ぼくは苛立ちを隠せずにいたし、マリは半べそをかきながら必死でキーを叩いていた。
 「はい、ストップ」ぼくは冷たい声でマリの手を止めた。「ダブルイコールになってる。文字列の比較は何使うんだった?」
 「......equals メソッドです」
 「わかってるなら使って。もう100 回ぐらい同じミスやってるんだけどな」
 「JavaScript だとこれで......」
 「それ、意味ないよな。時間ないから、さっさと進めて」
 「はい」
 マリはBack Space キーで修正し、コーディングを再開した。ぼくは斜め後ろに座り、左手を慎重に動かしながら、マリの入力内容を追っている。左手首の痛みはかなり引いていて、そろそろブラインドタッチに戻しても支障がなさそうだ。
 「ストップストップ」数分後、ぼくはまたマリを止めた。「なんでそんなにif~else の階層を重ねるんだよ。最初の条件でcontinue すればいいだろ」
 マリは穴が開くほどモニタを注視した後、観念したようにぼくを見た。
 「すいません。意味がよく......」
 「ちょい待って」
 ぼくは椅子ごと床を滑らせて自席に戻ると、両手をキーボードのホームポジションに置いた。左手に注意しながら、Eclipse で新しいクラスを作成し、ゆっくりとサンプルコードを叩いた。

mari.png

sample.png

 「こんな感じ」
 「あ、なるほど」
 「続けて」
 キャラじゃないなあ、と思いながら、ぼくは厳しい声で命じた。マリは素直に頷き、またキーを叩いた。
 マリの特訓を開始して2 日めだった。特訓の場所はシステム開発室だ。休日に出勤する場合は、部門長と人事の許可が必要だが、昨日と今日は勤務時間としてカウントしないため、斉木室長の裁量でPC を使用させてもらっている。
 特訓の言語にPython ではなくJava を選んだのは、構文がJavaScript に似ているので、マリが混乱しないだろうと考えたためだ。そのときは理にかなっていると思ったのだが、Python でもよかったかもしれない。マリは入門書などでPython を勉強していたようで、2 つの言語が頭の中で奇妙な具合にミックスされてしまっているらしかった。
 それでも自分で申し出ただけあって、マリはこの特訓に真剣に取り組んでいた。先週の平日、ぼくがm2A を仕上げている間に、マリはJava の基本的な言語構造を猛勉強していた。おかげで、クラスとは何か、のような初歩的な説明をスキップすることができて助かっていた。またキー入力が速いことも大きい。最近の20 代だと、フリック入力は異常に高速だが、キーボードのローマ字変換だと極端に遅くなる、という現象が見られるそうだが、マリはファンクションキーも含めて、完璧なブラインドタッチを身につけていた。ペアプロをやっていて、ドライバーの入力が遅いとナビゲータは苛立つが、マリにはその心配は無用のようだ。
 ただ、それらのプラス要素があっても、わずか数日で実戦レベルまでレベルアップすることが望めないことはわかっていた。マリは真面目だし、頭の回転も速いのだが、どうしても経験値を積み上げることでしか身につかないものはある。木名瀬さんはマリが褒められて伸びるタイプだと言っていたし、ぼくもできればその方法を採用したかったが、短期間での特訓には向いていない。厳しく叩き込む方法を選択せざるを得なかった。
 「おいおいおい」ぼくは大声で止めた。「何やってんの」
 「え?」マリはビクッと肩をふるわせた。「ユニットテストを作ろうかと......」
 「あのさ」うんざりした声は半分以上が本心から出たものだった。「テストを後から作ってどうすんの。ユニットテストって何のために作るかわかってる?」
 「動作確認のためです」
 「ちょっとどいて」
 ぼくはマリが空けた場所に椅子を移動させると、マウスで該当のメソッドを反転させた。
 「このメソッド、全部できてるよね」
 「はい」マリは意味がわからない、と言いたげに唇を尖らせた。「だからテストを......」
 「それじゃあ、テストが正しいかどうかがわからんだろ」ぼくは、マリが作りかけたユニットテストに切り替えた。「テストは先に作るんだよ。目的とする機能が動作するか評価できる内容のテストをね。この場合、評価したいのはcalcTax() メソッドの返り値だよな。そのテストをまず書く。calcTax() はスケルトンとして作る。つまり中身は空っぽで、null とかゼロとか、適当な値を返してコンパイルが通っているだけってこと。両方できたらテストを実行する」
 「あの、でも」マリの顔からは混乱が消えていない。「それじゃテストは失敗しますよね?」
 「当たり前。それを確認するのが目的なんだから。正しい値が返ってこないときに、確実に失敗してるってことがわかる。それは、つまりテストケースが正しくできてる証明になる。わかった?」
 「......はい」マリは頷き、付け加えた。「たぶん」
 「よかった」ぼくはエディタをcalcTax() メソッドがあるクラスに切り替えた。「じゃ、証明してもらおうか」
 ぼくはcalcTax() メソッドの全行を選択した。何をしようとしているのか悟ったらしいマリが小さく叫び声を上げたが、構わずDelete キーを叩いて中身を削除した。続いてCtrl + S でソースファイルを保存すると、椅子を滑らせてマリに場所を譲った。
 「ひどい」マリは茫然と空になったメソッドを見つめ、次にぼくに恨みがましい目を向けた。「もしかして、あたしのこと嫌いですか?」
 「そういう問題じゃない。ほら、口じゃなくて手を動かす」
 最初のうちはまだ遠慮があったため、冷たく厳しい命令口調は、努力して出していたのだが、今はそれほど演技する必要がなくなっていた。マリはJavaScript を書いたことがあるといっても、ネット上のサンプルに手を加えた程度で、自分で一からロジックを組み立てたことはないようだった。もちろん業務システムでビジネスロジックを記述したことなどない。そのため、ぼくからすると常識になっていることが、マリには実感できないようだ。
 「ちょい待ち。何、その計算式」
 「原価率出す式です」
 「それ、前にも書いたよな」ぼくは言った。「PageUp キー、2 回押して......ほら、そこ。同じ処理が2 回出てきたら、メソッドに切り出して」
 「こっちのはページクラスの値からですけど、今のはDB の値からなんで......」
 「計算ロジック自体は同じだろ。3 回目があったらどうする。また似たような式を書くんだ? それで、原価率の計算ロジックに変更があったら、3 箇所全部修正するの?」
 「......」
 「それにメソッドに切り出しとけば、ユニットテストにかけられるだろ。変更あってもチェックが簡単になるってことぐらいわかるよな」
 「すいません」
 「謝らなくていいから」
 「はい」マリは真剣な顔でモニタを睨んだ。
 ぼくは後ろめたい思いを感じながら椅子にもたれた。一つ間違えば罵声になりかねない言葉を浴びながらも、マリが残業代もつかない作業でせっかくの休日を潰しているのは、向上心などではなく、別の動機からであることはわかっている。その動機とは、つまり、ぼくへの好意だ。ぼくのどんなところをマリが好きになってくれたのかは、いまだによくわからないのだが。ある意味で、ぼくがやっているのは最低の行為だ。何の報酬を約束することもなく、マリの好意だけを利用しているからだ。
 「ストップ。そのtrue って引数は何?」
selectPayBefore.png 

 「小数点以下の切り上げするときがtrue で......」
 「その前のfalse は?」
 「支払方法が口座振り込みじゃないときです」
 「今はわかってるよね。作った直後なんだから。でも1 年後に見たとき、それ憶えてる自信ある? または笠掛さん以外の誰かが見たとき。Java はキーワードパラメータが使えないから、呼び出してるメソッドをいちいち参照しないと、引数の意味がわからないのは親切とは言えないよね。ちょっと貸して」
 ぼくはマリのキーボードを使って入力した。

selectPayAfter.png
 

 「これで何を与えてるのかわかる。読む人の立場になってコーディングするってこと。OK?」
 「はい」
 一分後、ぼくは呻いた。
 「おーい、何やってる」
 「え」マリは手を止めて、おそるおそるぼくを見た。「商品区分マスタから原価を......」
 「なんで、そこで呼ぶんだよ。そこ、どこ?」
 「えーと......」
 「ループの中だろ。ループの中で、毎回、DB に接続して、select 文発行すんの? 冗談だろ」
 なぜぼくが怒っているのかわからない、という顔のマリに、データベースへの接続はコストが大きいから避けるべき、ということを説明した後、修正するように指示した。マリは少し悩んだ後、ループの中で商品区分マスタのキーをList に格納しておいて、ループから抜けた後にまとめて取得する、というコードを書いた。
 「うん、まあ、それでもいいね」ぼくは頷いた。「ちなみに商品区分マスタって、何件ぐらいだった?」
 「30 件ぐらいだと思います」
 「だったら、ループの前に全件取得して、Map にでもぶち込んでおいた方がスマートじゃないかな。1 万件なら笠掛さんのやり方がいいけどね。こういうパターンにはこういう方法、みたいに固定で憶えちゃうと、そこから先に進まなくなるから、常に、もっといい方法がないかを考える癖をつけないと」
 「そういうのがわからないんですよね」マリはこぼした。「あたし、脳が固いんですかね......」
 マリの頭が固いとは思わない。今まで使ったことのない思考回路が生まれつつあり、従来の回路とのギャップに苦しんでいるだけだ。
 「経験値が少ないだけで、別に固くないよ。むしろ柔軟な方だと思うけどね」
 そんな短い誉め言葉でさえ、マリの顔はパッと明るくなった。また胸の痛みを感じながら、ぼくはソースの別の部分を指した。
 「この変数、なんでこんな場所で宣言してる?」
 「え、あ」マリは困惑して変数宣言を見た。「間違ってますか?」
 「間違ってはいないけど、これ、実際に使うのは下の方だよね。この計算部分が終わった後。メソッド開始後に宣言してるのには、何か理由があるの?」
 「ないです。でも」マリは不満そうに訊き返した。「ここでも問題ないじゃないですか」
 そういえば、マリが書いたJavaScript では、変数が大抵、最初の方で宣言されていた。おそらく、最初に教えた人間のクセで、それが染みついてしまっているのだろう。
 「さっき別の人がメンテナンスするときのことを考えろ、って言ったよね。ソース読む人のことを考えてみなよ。ここに宣言してるってことは、この変数が計算部分までのどこかで使われているのかもしれない、ってことを頭に入れて読むよね。それなのに、100 行ぐらいスクロールして、ようやくこの変数が登場したら、どう思う? 膝が砕けそうなぐらいがっかりすると思わない?」
 「そんな風に考えたことはありませんでした」
 「昨日、言ったと思うけど、スコープは可能な限り狭くする。変数も同じ。宣言は使う直前で。これ、鉄則。続けて」
 「はい」マリはキーボードに手を戻したが、躊躇った表情を浮かべた。「あの、そろそろお腹空いてきませんか」
 時計を見ると正午まで15 分ほどだった。言われてみて、空腹感に気付いた。もう少し進めておきたかったが、空腹で気が散っても効率が悪くなる。ぼくは頷いた。
 「じゃあ12 時になったら......」
 「あれえ、二人とも何やってんの」
 突然響いた軽薄な声に、ぼくたちは驚いて顔を上げた。スターバックスのカップを手にした伊牟田課長が入ってきたところだった。日曜日の午後だというのに、この人は会社まで何しに来たんだ。
 「今日、仕事するなんて聞いトランプ大統領」
 伊牟田課長は爆笑したが、ぼくたちの呆気にとられた顔を見ると、「あれ、すべったか」と自分でフォローを入れた。
 「仕事ではなく、笠掛さんの勉強です」ぼくは説明した。「斉木さんには許可をもらってます」
 「あ、そう。麻生大臣。そんなに近い距離で勉強ね。世間じゃソーシャルディスタンスなんだけどな」
 指摘されても直す気もない鼻出しマスクの人に言われたくはない。
 「勉強って口実で、二人でラブラブしてたんじゃないの?」
 「「してません」」ぼくたちは声を揃えた。
 「ひゅーひゅー」伊牟田課長は両手の人差し指でぼくたちを指しながら、課長席に座った。「仲良しじゃねえか。イノウーと笠掛ちゃんがうまくいってないとか聞いたから心配してたんだよ。雨降って地固まるってとこか?」
 この無神経なアホ課長。ぼくは心の中で上司を罵った。せっかくマリが仕事モードだったのに意識してしまうだろうが。事実、マリの頬が微かに赤く染まっている。余計なさざ波が立ってしまったようだ。
 「マリ......笠掛さんは戦力になりたいと、真剣に勉強をするために来ているんです。そういう言い方はしないでもらえますか」
 「おいおい、なんだよ、ちょっとした冗談じゃねえか」伊牟田課長は笑いながら返した。「そういやあ、イノウーくんよ。もう足は治ったみたいだよな。ここまで来てるんだからな。火曜日の定例ミーティングはちゃんと出社しろよ」
 「話を逸らさないでもらえますか」
 「ああ、知らんがな、そんなの。俺はお前らが会社の設備を私用で使ってるんじゃないかって思っただけだわ」
 「さっきも言いましたが、斉木さんにも木名瀬さんにも許可はいただいています」
 「俺は聞いてねえからな」伊牟田課長の顔からは笑いが消えていた。「だいたい、なんで俺に訊かなかったんだよ」
 あんたに訊いたら、却下されたに決まってるからに決まってるだろうが。
 「お忙しいと思ったので」
 「お前らなあ、そうやって俺をハブにして楽しいか、あ?」
 「そんなつもりは......」
 「俺がわかってないと思ってたんだろ」
 「すいませんが」ぼくは顔を背けた。「勉強に戻りたいので、もういいですか」
 「木名瀬のやつだろ」
 伊牟田課長の低い声に、ぼくとマリは顔を見合わせた。
 「は?」
 「木名瀬がお前らを煽ったんだろ。俺をはばにしてやれって。そうやって人をバカにして楽しいのかよ、お?」
 この人も、こんな風に負の感情を表に出すことがあるのか。ぼくは少し意外に思った。てっきり、他人にどう思われているのかなど、全く気にしないマイペース人間なのだと思っていた。
 「あいつはそういう陰険な奴なんだよ」伊牟田課長は憎々しげな顔と声で、木名瀬さんの非難を続けた。「陰でこそこそやるんだ。何様のつもりだよ」
 「木名瀬さんはそんな人じゃありません」マリが耐えかねたように声を上げた。「誰かさんと違って、真面目に仕事をしているじゃないですか」
 ふへへへ、と伊牟田課長は奇妙な声で笑った。
 「真面目ねえ。笠掛ちゃん、何にも知らないんだな」
 ぼくたちは再び顔を見合わせた。
 「何のことですか」
 「さあねえ」伊牟田課長は楽しそうにさえずると立ち上がった。「あーあ。ちょっと仕事やろうと思ってたけど、やる気なくなっちまったぜ。まあいいか。じゃ、ラブラブだかジョブジョブだかしらんけど、せいぜいがんばってな。どうせムダになるってのにな」
 ムダ? どういうことだ。だが、ぼくが訊き返す前に、伊牟田課長は「ほな、ばいなら」と言い捨て、さっさとドアから出ていってしまった。
 「何のことですかね」しばらくしてマリが訊いた。
 「さあね」
 ぼくは肩をすくめて、マリに続きを指示しようとしたが、集中力がすっかり消失していることに気付いた。マリの顔を見ると、やはり気乗りしないようだ。ぼくは口の中で舌打ちした。
 「ああ、腹減ったな。何か買いに行こうか」
 「そうですね」
 マリは頷いてPC をロックしたが、その顔にはたくさんの疑問符が浮かんでいた。きっとぼくの顔も同じだったに違いない。

 (続)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術や製品の優位性などを主張するものではありません。

Comment(53)

コメント

匿名

毎日毎日このサイトや小説サイトで時間つぶしして毎日を過ごしてるアンタ。
小説サイトではファンタジー物や冒険物なんか見て一日中現実逃避してるみたいだけどいい加減仕事しろよ。
メカケの子供だから特別扱いされているんだろうけど、はっきり言って迷惑。

匿名

プログラムの書き方は宗教戦争並みに荒れる(確信)

匿名

木名瀬がお前らを煽ったんだろ。俺をはばにしてやれって。
→木名瀬がお前らを煽ったんだろ。俺をハブにしてやれって。
でしょうか。

のり&はる

これは削除案件

yupika

>匿名
これなんかのコピペなの?w
一日中働いて何が楽しいんだよ。人生ハックして楽に過ごしていけ。
あとメカケの子ども部分はマジで意味がわからない。
メカケの子どもだから特別扱いされないんじゃないの?
本妻の子どもだから特別扱いされるんじゃないの?
ま、俺が迷惑かけてるのは認めるけどな。未読メール420件。月曜の朝一番最初に開くサイトはここ。決めてるんだ。

ちゃとらん

if( i>60 && i System.out.println( i + "dummy" );
}

でいいんじゃない?


それなら、
for( int i=61; i System.out.println( i + "dummy" );
}

でいいんじゃない?


つまり、10,90,60 は変数なので『指定の条件』であれば変な加工をするのはどうかと思います。


また、
if( i>10 ) {
if( i if( i>60 ) {
System.out.println( i + "first" );
}
}
System.out.println( i + "second" );
}

の場合、continue でどのように表しますか?


イノウーくん厳しすぎ。マリちゃんがかわいそう…
・・・けど小説の方は盛り上がってきましたね。

暁 紫電

イノウーくん教えるの向いてないなぁ……

あと、自分はネストを減らす事をも億滴としてelse省略は禁止、
分岐しているなら分岐している事が判りやすいようにちゃんとネストする、
分岐条件の見直し(&&を使うとか)で分岐自体を減らしてネストを減らす派なので
受け入れがたい部分がある。

匿名

「はば」って使わないかな。方言だった?

匿名

軽く調べたら愛知とか関西の一部くらいで使われるっぽい>はば

匿名

前回といい今回といいイノウー君のキャラが完全に崩壊していってるw

匿名

私も、研修などでプログラムを教えていますが、
その際は、さらに下の変化まで教えます。

private void sample() {
for(int i = 0; i

if(i continue;
}

if(i >= 90) {
continue;
}

if(i continue;
}

System.out.println(i + "dummy");
}
}




private void sample() {
for(int i = 0; i

if(isContinueValue(i)) {
continue;
}

System.out.println(i + "dummy");
}
}

private bool isContinueValue(int i) {
if(i return true;
}

if(i >= 90) {
return true;
}

if(i return true;
}

return false;
}

ちゃとらん

10:55 匿名さん。


『<』がタグになってしまいますね。 ・・・私の最初のもおかしな文法になってしまった。


それはそうと、return true; がメソッドの途中にあると、出口が複数になるため、推奨していません。


08:56 匿名さん
> プログラムの書き方は宗教戦争並みに荒れる(確信)

やばい・・・先読みされてた。

確かに色々ありますもんね。
『}』を行末に付けるか、改行して付けるかだけでも揉めます。

匿名

このイノウーの態度、マリちゃんの希望による演技でしょ?
マリちゃんは厳しい方が燃える(萌える?)んだよね。
M入ってるよね。
イノウーの方は既に演技じゃなくなりかけているようだが・・・

匿名

ちゃとらんさん

10:55の投稿者です。

どんな書き方をしても一長一短があるものです。
なので、よりベターな書き方をするように推奨しています。

この小説でも出てきていますが、ポイントは「読みやすさ」です。
出口が複数になり読みづらくなるのであれば、出口は一つでよいと思います。
出口が複数でも読みやすいのであれば、出口は複数あってよいと思います。
(つまり、どちらでも良い。どちらが読み手にとって読みやすいかがポイントです。)

匿名

このイノウーの態度、マリちゃんの希望による演技でしょ?
マリちゃんは厳しい方が燃える(萌える?)んだよね。
M入ってるよね。
イノウーの方は既に演技じゃなくなりかけているようだが・・・

匿名

returnは1個しか書いちゃダメだよ派
continueも使っちゃダメだよ派
適切な理由があればgotoでも使っていいんだよ派
とりあえず全メソッドにstatic付けちゃおうぜ派

匿名

規約に従う
かなぁ…

でも規約なんて見直さないとこがほとんどだから
古くさぁい読みにくぅいソースを書かされることがしばしば…

匿名

管理人様(ここに書いて大丈夫かな・・・)

10/26、11:51の匿名です。
意図せず重複投稿となってしまいましたので、
お手数ですが、本投稿とともに、11:51の投稿を
削除してくださいますようお願いします。

お手数、お目汚し申し訳ないです。

ちゃとらん

10:55の投稿者さん。

> ポイントは「読みやすさ」です。
これに異論はありません。

が、よきに計らえ、とも教えることもできないので、(12:52 匿名さん)の『規約に従う』をベースにしています。


が、
> 古くさぁい読みにくぅいソースを書かされることがしばしば…
とか、出口一つにこだわって、逆に読みにくくなったりするんですよね。


12:01 匿名さん
> とりあえず全メソッドにstatic付けちゃおうぜ派
上3つは「うんうん」って見てましたが、最後に吹き出してしまいました。
# static論争・・・またしたいですね。

SQL

エンジニアになってしばらく経つが、
完全に独学の自分としては、
一度ちゃんと誰かに教えてもらいたいと未だに思っている・・・

リーベルG

すでに調べていただいた方の言うとおり「はばにして」というのは、東海地方などで使われる方言(?)です。仲間はずれにする、みたいな意味ですね。

ほげ

言ってる内容はさておき、書いてる時に横からわーわー言うのは、俺だったら「うざってえなこいつ」ってなるかな。一通り書いたあとにコードレビューしたほうがいいでしょ。指摘箇所が残るんだから。
わーわー言われて直したって、後まで覚えてないと意味ないわけじゃん。

つーか、メソッド切り出しは正論かもしれんが「2回目を書いてる最中に」いうなや、とは思う。

匿名D

まるっきりいじめそのものですね。
教えるというよりも、事前になんの情報提示もせずに、
自分と同じようにやれ、なんて、無理筋もいいところです。
マリの行為を利用していることよりも、
まずは自分のスタンスを恥じるべきだろう。


テストをあとになってから作るな?
だったら最初の1行目を入力しようとした時点で指摘するべきだ。
いじめもとい特訓を開始して、すでに何日もたってから言い出すことこそ、
後出しジャンケンそのものじゃないか。
これを特訓だなんて、それこそ偽善だ。


まあ、壁にぶち当たってそれをなんとか乗り越える、
というのは物語に必要な要件ですから、
現在はその仕込みと思って眺めることにしてます。


これまでのところ、イノウー君は人のせいにばかりしていますね。
これも物語において彼に課せられたハードルなんでしょうか。


伊無田口氏がうざいですが、
独自仕様の暗号化技術なんてものを通すような会社じゃ、
さもありなんとしか言いようがないです。

匿名

「あー、私無宗教なんでー」っていっちゃいたいね。


〇〇は悪、ってのはじゃあなんで言語仕様上できるようになってるのか、を考えた方がいい。
つまり、場合によってはやるときもある、ってことで、完全に画一的なルールを作るのは無理(というか無意味)しょうね。
"あくまでもガイドライン"ならまだしも。
(少なくともIDEにそれなりの機能がある昨今では)それを統率する労力に効果が見合わない。


そもそも言語によっても、どうあるべきか、は変わるだろうし。

匿名D

テストファースト言われているのは知ってるし、
テストユニットの有効性も理解していますが、
いちいちスケルトンなメソッドと作ってエラーになるのを確認て、
どのくらい実践、重要視されているんでしょう。
エビデンスにも残らないのに。
というか、こんなモノまでエビデンスに残しているの?
スケルトン状態のメソッドをテストする段階で
SVNにリポジトリを上げていれば可能か。
アジャイル開発とは相性悪そうですね。


あとあからいつでも
「このテストは本体よりも先に書かれて
スケルトンメソッドでエラーになるのを確認した」
と、客観的にその事実を確認できないことには、
宗教的な儀式の域を超えないと思うんですけど。

匿名

匿名Dさん

短期間で集中的に教えるなら、こんなやり方の方が効果的ですよ。
初めに失敗させて、正しいやり方を教えた方が、記憶にのこる。

たらたらやって「あ、間違えちゃった」「しょうがないなあ」だと、成長はしないんじゃないかな、と思いますね。

匿名

みなさん議論に夢中になっているのか、
誰も伊牟田課長と木名瀬さんの過去についてとか
「ムダ」とは何がムダなんだろうかについて触れないんですね。

匿名

ほんとここのコメント欄て文句ばっかりで呆れますね。

匿名D

>短期間で集中的に教えるなら、こんなやり方の方が効果的ですよ。


ある程度のスキルの持ち主に、ワンランクアップを促す場合なら、
有効な場合があるかもしれません。
が、マリちゃんみたいなレベルには、はっきり言って不適切ですよ。


>触れないんですね。


触れてどうするんですか?
個人的にこねくり回すのは、一人でやればいいし。
現時点では、他の人とやりとりするようなことはないと考えます。

匿名

イノウーは大卒後にサードアイに就職したので職歴はサードアイのみで、
サードアイではろくな研修はなくOJT中心の育成だったとのことなので、
イノウーのスキルはほぼ東海林さんらからの直伝という事になりますよね。

コーディング流儀やテストファーストの考え方は東海林さんの受け売りで、
それ以上の意味は無いのでは。
まだ29歳ですし、伸びしろも妥協も変節もまだまだこれからでしょう。

匿名

無責任な立場で自分ならもっとうまくやると論評するだけなら誰でもできる
匿名Dさんは、どんなやり方なら適切だと仰るんですかね

匿名D

自分ならもっと上手くやる?
私、そんなこと書いてませんよ。どなたかと間違えてません?


中堅どころの人材にランクアップを促すための教育と、
素人に毛が生えた程度の人材に施す教育に、
同じものが適用できる、とおっしゃるのであれば、
私からは、これ以上は何も申し上げることはありません。

ほげ

5chじゃあるまいに、匿名どうしで空中戦するのやめてくれねー?
喧嘩したいならここでだけでも適当にコールサインを付けろ。

匿名

それもさることながら、マギがいつ馬脚を露すか、気が気でなりません…

匿名

もう露わになってる…

匿名

なぜダメなのかをちゃんと説明して納得させないと、何度でも同じことやるよ。だって、なんでこれやっちゃダメなのかって思うもん。

匿名D

木名瀬さんに
「どんだけ独りよがりなんですか。伊牟田グチさんと大して変わりませんよ」と
指摘されて悶絶するシーン、なんてのがあるのかもしれませんね。

匿名

ユニットテストってエビデンス云々以前の話では…?

匿名

エビデンス云々以前の話とは?

匿名D

エビデンスなんて書いているのは私だけだから、私に対するツッコミかな?


ユニットテストの「なにが」エビデンス云々以前の話、なのかな?


「なにが」が明確にされていないと、エビデンスにもならんよ。

匿名

・テストを行えば、テスト結果がエビデンスとして残る。
・プログラミングの前にテストケースを作成したか
 プログラミングの後にテストケースを作成したかは、エビデンスが残らない。
たったこれだけの事でしょう。ちゃんと読めてないのかな?

個人的には、プログラミングの前に関数仕様ばっちし決めちゃう事よりも
プログラミングしながら引数変えたり分割単位変えたりして揉む事が多いので、
「プログラミングの前にテストケースを作成」だと無駄が多く、
「プログラミングの後にテストケースを作成」派ですね。

ちゃとらん

「スケルトンメソッドでエラーになるのを確認した」をエビデンスとして残さないなら、テストしたかどうかわからないので、重要な作業じゃないという事ですよね。ー>匿名Dさん


また、エビデンスで残してる…っていうなら、…ほんまかいな? というかやり過ぎでしょ。
# 通勤途中に出会う人すべてに立ち止まって「おはようございます」を実践してるような事と同じレベル!?


ここまでくると特訓とか教育とかいうレベルではなく、独りよがりの自慢しーでしょ。


> マリちゃんみたいなレベルには、はっきり言って不適切ですよ。

私もそう思います。


※ キャラ的に、イノウー君暴走してる。
マリちゃんの好意がなければ、うざいだけの伊牟田課長の方が、ずっとマシに見える。

匿名

まずはスケルトン作ってエラーになることを確認する
ってのは、
テストメソッドの正確さを確認する
ってより
プログラムを書いたあとにコンパイルしてコンパイルエラーが出ないことを確認する
みたいな最低限の確認じゃないかな。

でテストメソッドの正確さはレビューで確認するものかと…

#テストプログラムまでちゃんと読める人間がいない…
#コメントしか読まないガバガバレビュー勘弁して…

匿名D

>ちゃとらん氏
>重要な作業じゃないという事ですよね。


そもそも本当に最初に作ったのか、空メソッドのエラーを確認したのか、
後から証明のしようが無いから、成果物にはなり得ない、
なので評価のしようが無い、評価の対象にならないものなどどうでもいい、
というのが、私の主張です。
軽重の度合いについては主観に左右されてしまうので、
私はあくまでも「繰り返し検証可能かどうか」にこだわりたい。


># 通勤途中に出会う人すべてに立ち止まって


私は、森の奥で木が倒れた。
倒れたときの音は誰も耳にしていないが、音がしたことは事実だ!
てな話を思い浮かべました。
だったらどうした、って。ねえ。(-.-)


今回、イノウー君は猛烈な身勝手ぶりを発揮しています。
頭の中にどんなカリキュラムがあるのやら。
自分がやるのと同じようにやっているかどうかでしか判断せず、
しかも後追いで後ろから撃っているようにしか見えません。
はっきり言って卑怯です。
もし上記以上のものが出てこないのなら、
〇〇〇ー〇ー〇ョ〇んは一人でこっそりやっとれ、とかましてやるところです。


一方、マリちゃんも身勝手であることを忘れてはなりません。
基本も身についていない輩がアレンジだなんて身の程知らずというものです。
客観的な評価を受けて、冷静に受け止められるんでしょうかね?


今回のテーマは「身勝手」なんでしょうか。
小説ですから、いずれ自身の身勝手ぶりに直面する。
それをどうやって克服するのか、今から楽しみにしています。


長くなってすみません。m(_ _)m

なんなんし

テストファーストの考え方が間違ってるかな

最初に機能要件よもれを確認するために
テストコード書いてほしい
ゴール理解しないで書き始めて
あれがないこれがないと言い出さないようにね

PGの人とやり取りして誤解されてるところがこのへん
エビデンスは求めてないから
先にゴール確認しようね的に運用してます

ちゃとらん

匿名Dさん

> 軽重の度合いについては主観に左右されてしまうので、
> 私はあくまでも「繰り返し検証可能かどうか」にこだわりたい。
おっしゃる通りですね。失礼しました。

なんなんし さん

> テストファーストの考え方が間違ってるかな
間違ってる…とまでは言いませんが、正しく運用されているのか? という所は疑問ですね。
まず、機能要件があり、それを確認するためのテストコードがあり、それに合格するようにコーディングする…だけなら、テストプログラムの作成工数を、きっちりコーディングやコードレビューに向けるべきかと思います。


そのテストプログラムを、将来的な保守の改修時(リファクタリングも含む)にも使用するというなら、まだ有用性があると思いますが、そのテストプログラムが正しいかどうかをテストするプログラムも必要になり…永遠に終わりがないように思います。


なので、
> 先にゴール確認しようね的に運用してます
というのが、落としどころなのではないかと思っています。

匿名

>「ひどい」マリは茫然と空になったメソッドを見つめ、次にぼくに恨みがましい目を向けた。「もしかして、あたしのこと嫌いですか?」

この女、ノリノリである。

匿名

来週は大竹専務のお出ましか…

なんなんし

〉ちゃとらんさん
まぁ間違ってるは言葉足らずで言いすぎでしたね
品質基盤作ってる立場としては
テストで品質は上がらないため
開発効率上げる目的を忘れて
テストファーストを型に嵌めて語られるのは
やめてほしいかなと思った次第

個人的にはPGの人がテストやろうがやらなかろうが
別に気にしてなかったり(´・ω・`)
設計なり実装なりで品質担保できるなら
むしろテストしないようにしてほしいのだ
開発手法を正しく理解して有効ならや

匿名D

>なんなんし氏
>テストファーストの考え方が間違ってるかな


テストファーストそのものが間違っているわけではありません。
一方で、


>「それじゃあ、テストが正しいかどうかがわからんだろ」


ここの部分の意味が理解できません。
最初にテストを書くことが、どうやってテストが正しいことの証明になるのでしょうか?
最初にテストを書く「だけ」で
テストの中でisTrue()とisFalse()を取り違えるのを防止できるんでしょうか。


よく挙げられるテストファーストの、利点というよりも目的は、
テストを作成するということが、設計の役割を持つということです。


作品中にもメソッドを切り出す記述がありますが、
内部で複雑に分岐してすべてを処理するため、
何百行にもなるような巨大なメソッドに対して真偽のチェックを行うだけなんて、
はっきり言って、テストとしては無意味です。


処理の流れの要所でテストを行わなければならないとしたら、
メソッドが巨大になること抑制するでしょう。
どのようなテストが必要なのかを考えることは、
システムの構造を考えることと同値なのです。
そして、最初にテストを書けば、あとからのリファクタリングを抑制し、
最初から正しい依存関係を備えたオブジェクト群が手に入ります。
私は、これが正しいテストファーストだと認識しています。
重要なことは「テストが正しいかどうか」ではないのです。


イノウーくんが作品中で触れているテストファーストは、
私に言わせれば、ドグマに囚われた曲解そのものです。
使用頻度の高いロジックを切り出すのに、
いちいち目くじらを立てるようなものではありません。
すでに出来上がっているコードを消去するなんて論外ですよ。

匿名D

>最初のうちはまだ遠慮があったため、冷たく厳しい命令口調は、努力して出していたのだが、今はそれほど演技する必要がなくなっていた。


馬脚を現しつつあるのは、イノウー君の方ですよね。

なんなんし

〉匿名Dさん

タイムスタンプ的に入れ代わりだとおもうけど
方向性は同じはずだとおもうけどね(´・ω・`)

匿名D

>なんなんし氏


はい。
私も「『テストを最初に書く』ことそのもの」に意義を見いだしていません。
私の思うところを書いただけなのですが、
批判のように読めてしまったら申し訳ありませんでした。

コメントを投稿する