  |
はてなキーワード: 単体テストとは
書くより読むほうが上達する。
社内の上手い奴が書いているコードを読め。
社内の下手な奴が書いているコードを読め。
上達しないって言ってる連中はコードのパターン、イディオムを知らない。
最終系のコードのイメージが無いからコードに方向付けが出来ないし、その場その場で取っ散らかった実装になる。
デザインパターンだけ知ってたって使ってる言語で実現する方法を知らなきゃ活用できない。
単体テストは単体テストを書きやすいコード、書きやすくするための工夫を知らないと書けない。
適切なエラーハンドリングをするなら例外とは何か、ライブラリではどういう例外をどういうときに投げているか知らなければ正しくハンドルできない。
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
private メソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
プログラミングはセンスです。センスの無い人がプログラマになると、他のすべての人に迷惑がかかります。だから、センスの無い人は絶対にプログラマにならないで下さい。
プログラミングのセンスが無い人や、プログラミングをやったことの無い人は、知識を得たり経験を積んだりすれば、誰でも「良いプログラマ」になれると思っているようですが、無理です。
というのも、センスの無いプログラマの問題は、知識や経験の不足ではないからです。センスの無いプログラマの救いようの無い問題は「頭がおかしいこと」なのです。
題材は何でもいいのですが、具体的なコードを見た方がイメージがつきやすいと思いますので、とりあえず以下の問題を考えます。
住民のリストが与えられるので、背の低い順に男女ペアにしたリストを作って下さい。ただし、男女の数は同数であるとします。
const makePair = (persons) => { const males = persons.filter(person => person.sex === MALE) const females = persons.filter(person => person.sex === FEMALE) const compareHeight = (a, b) => a.height - b.height males.sort(compareHeight) females.sort(compareHeight) return males.map((male, idx) => [male, females[idx]]) // 男女の数は同数 }
この例はJavaScriptなので高階関数を使っていますが、仮にそういう機能が無かったとしても、
一方、センスの無いゴミプログラマは、以下のような名状しがたきコードを書いてきます。
function pair(psns) {
var i = -1;
var cnt = 0;
var flg = psns[0] && psns[0].sex;
var j = -1;
var tmp = null;
for(i = 0; i < psns.length; i++) {
//console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
//console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
if(psns[i].sex == flg) {
//console.log('cnt: ' + cnt + '->' + (cnt+1));
cnt++;
} else {
j = i - cnt + 1;
//console.log('swap ' + i + '<-->' + j);
tmp = psns[j];
psns[j] = psns[i];
psns[i] = tmp;
i = j - 1; // <- 理由は分からないが、i = jだと上手くいかない（by XXXX）。
cnt = 0;
flg = flg == MALE ? FEMALE : MALE;
while(j > 1) {
if(psns[j].height < psns[j-2].height) {
//console.log('swap ' + j + '<-->' + (j-2));
tmp = psns[j-2];
psns[j-2] = psns[j];
psns[j] = tmp;
}
j -= 2;
}
}
//console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
//console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
//console.log('')
}
for(i = 0; i < psns.length; i++) {
//console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
j = Math.floor(i / 2);
//console.log(psns, 'i=' + i, 'j=' + j);
tmp = psns[i];
if(!(i % 2)) {
psns[j] = [null, null];
}
if(tmp.sex == MALE) {
psns[j][0] = tmp;
psns[j][1] = psns[i+1];
} else {
psns[j][0] = psns[i+1];
psns[j][1] = tmp;
}
i++;
//console.log(psns, 'i=' + i, 'j=' + j);
//console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
}
psns.splice(psns.length / 2, psns.length);
}
こんなコードのメンテナンスは御免被りたいです。一見して配列の要素を入れ替えていることが分かるだけで、実装を全て読まなければ（いや読んでも）処理の意図が全く分かりません。また、たとえば「i = j - 1」が間違って「i = j」などと書かれていてバグを起こしたとしても、原因を突き止めるのは困難を極めます。
さて、このコードは具体的に何がいけないのでしょうか。長すぎることがいけないのしょうか。変数名が分かりにくいのがいけないのでしょうか。引数を破壊的に変更しているのがいけないのでしょうか。不要なコメントが残っているのがいけないのでしょうか。よく見ると、ソート処理で車輪の再発明をしていたり、「j」や「tmp」などが場所によって意味が違うカメレオン変数になっていたりしますが、それがいけないのでしょうか。どれも正しいですが、それらを逐一直したところで、本質的な解決にはならないでしょう。
後者のコードはもはや「ここを直したら良くなる」とかいうレベルを超えています。たしかに、問題を具体的に挙げることはできます。このコードの致命的な問題が、凝集度の低さと、単一責任の原則(SRP)違反にあるのは間違いありません。しかし、後者のコードを書いてくる人に、
「住民リストを男女に分ける処理や、リストをソートをする処理、2つのリストをまとめる処理は、この問題とは独立して意味のある操作だから、別の関数として抽出しましょう。その方がコードの見通しがよくなるし、一部の処理を修正したときの影響も小さくなるし、単体テストも書きやすくなります」
なんて言ったって聞く耳を持たないでしょう。
そもそも、こういうコードを書く人は、この処理自体を「pair」なんて関数に抽出すらしません。まだこの問題では入出力のフォーマットが明確に定義されているので、他人が1から書き直せますが、実際のプロダクトでは、無数の副作用を起こす数千行のコードの迷路を彼の脳内フォーマットのデータが通るわけです。もちろん、テストコードなんてありません。
つまり、指摘をしても絶対に直らないのです。いくら言語の優れた機能やベストプラクティスを紹介しても、馬の耳に念仏。それらの利点を理解できるだけの脳みそが足りていないのです。
どうして、同じ処理を実装するのに、ここまでの違いが生じるのでしょうか。
これは、プログラミングの技術の問題ではありません。既に述べた通り、ふつうの人なら、特定の機能の有無とか知識の程度にかかわらず、ふつうのコードを書くのです。なぜなら、ふつうの人にはそちらの方が楽だからです。つまり、前者のコードは別に何か卓越した技術を身につけた結果書けるようになるものではなく、まともな感覚さえ持っていれば、プログラミング初心者にとっても前者のコードの方が書きやすいのです。
つまり、後者のようなコードを書いてくる奴というのは、現実世界の捉え方が常人とは著しくずれているのです。要するに、「頭がおかしい」のです。この病気はもう直りません。だから、センスの無い人は絶対にプログラマにはならないで下さい。
バブルソート、バケツソートであってもN=1,Bigの時には異なる数値を出すことがある。
ましていわんやその他のソート。
当然何でこれだけの数のソートアルゴリズムがあるか？といえば条件に応じて変えるため
あるいみ、バケツソートで書かれていましたN=Bigでないとして
そりゃ、標準ライブラリにあるようなソートには変えてくることは予想ができる。
しかし、デバッグ時にはバケツソートになっていることもある。簡単だしデータ少なく入れるから。
これもバケツソートの使い方。いわゆる単体テストじゃないけど、テスト中はバグが出にくいものにかえてあることがある。
これは現場で知っておくべきこと。標準的なライブラリにあるものがわざわざコードが書いてある。
そりゃなんかのいみがある。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
441あとで/2227users 未経験でも1カ月で即戦力クラスの知識が身に付く『webデザインドリル』公開 | knowledge / baigie
319あとで/2886users 賃貸住宅の退去費用として13万円請求された時の対応方法をまとめます｜犬笛｜note
305あとで/1662users 非デザイナーの僕がデザインぽいことをする時に使う便利なツール18選｜かずたか@プログラミング独学して起業した人｜note
260あとで/2214users 【朗報】Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしまう・・・これには金融マンも真っ青 | ライフハックちゃんねる弐式
228あとで/1529users 研修資料まとめ.md · GitHub
214あとで/1017users 技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog
191あとで/1517users 社会人の不幸の8割は合意のない期待から｜田中邦裕｜note
185あとで/1788users この法律が日本を｢生産性が低すぎる国｣にした | 国内経済 | 東洋経済オンライン | 経済ニュースの新基準
182あとで/1222users 科学的で現代的な「人を動かす」──『事実はなぜ人の意見を変えられないのか-説得力と影響力の科学』 - 基本読書
180あとで/970users 3年かけてたどり着いた英語記事を読むための方法 - Qiita
172あとで/796users 文系大学生が機械学習を０から始めて９か月でKaggle銀メダルを獲得するまで - Qiita
170あとで/669users いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす - エンジニアHub｜若手Webエンジニアのキャリアを考える！
170あとで/1344users 機械の立体図をフリーハンドでとんでもなく上手に描く人が製図のテクニックを解説「恐ろしいレベル」「弊社に欲しい」 - Togetter
169あとで/2472users 食べログ3.8問題を検証 - クイックノート
168あとで/1146users 質問が出ないのは話し手の責任が8割。だから「質問が出る」ようにルールを決めたら、大成功した話。 | Books&Apps
166あとで/898users 貧困を減らす実験アプローチ｜安田 洋祐｜note
165あとで/679users 社内勉強会で作ったDocker/Kubernetes入門の資料を公開しました - inductor's blog
164あとで/695users データサイエンス・機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball
157あとで/1090users 20年の営業マン生活でわかってきた「仕事の本質」を全部話す。 - Everything you've ever Dreamed
154あとで/953users 【インスタ、エアビー、Slack等】人気サービスの初期ユーザー獲得方法
153あとで/1292users 【四川料理のスゴい人】家庭のキッチンの火力で「プロ並みのチャーハン」をつくる方法 - メシ通 | ホットペッパーグルメ
151あとで/1150users ０から100万円貯める、節約サバイバルガイド
149あとで/1972users 巨乳の炎上に見る進化と文化のミスマッチ - 本しゃぶり
148あとで/637users WebサービスのA/Bテストや機械学習でよく使う「確率分布」18種を解説 - paiza開発日誌
147あとで/1149users フライドポテト、チェーン店別徹底比較 :: デイリーポータルZ
143あとで/598users プログラミングの命名規則ガイドラインを規定するオープンソースプロジェクト「NamingC - エンジニア・プログラマのソーシャルITメディア
143あとで/661users ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化 | The Official Slack Blog
142あとで/564users 「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
140あとで/1334users 13歳から43年間野宿していた「洞窟オジさん」はかつての住処でナニを食べていたのか？【極限メシ】 - メシ通 | ホットペッパーグルメ
138あとで/963users 自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita
職業プログラマでシステムの開発保守をやってるんだけど、色んな人が競技プログラミングにハマっているのをみてatcoderを始めてみて一ヶ月が経った。未だにF問題が解けなくて実力の無さを痛感してるけど、これ、たしかにめっちゃ面白い。アルゴリズムを考える力もつくし、これからも続けようと思う。
それと同時に、やはり競プロは業務では使えないって思いが強くなった。「アプリを作るのが好きで、趣味で競プロもやってます」って人であれば面接で速攻でとると思う。問題となるのは「競プロで青色なので、プログラミングは得意です」という言い方をする人。その時点で俺なら落とす。
普段、仕事でプログラムを書いていると可読性とか保守をどうするとか、ほとんどの時間はそういうことを考えてコードを書いている。幸いそのお陰で、自分の関わるシステムは5年以上開発を続けても苦もなく保守できる状態が保たれている。しかし、atcoderに参加してみて、競プロ中は普段と全く関係のない知識を使っていることに気がついた。いや、使っているではない、使わざるを得ないのだ。
例えば、普段の開発では単体テストを必ず書くが、atcoderでは提出時間が早いほうが有利なため、簡単な問題では単体テストが完全に無駄だという思いが脳裏に浮かんだ。システムを作るときには絶対にあってはいけない発想だ。回答を通す、という目的だけがはっきりしているのも問題だ。参加中は可読性を上げるために変数名をつける、読みやすいようにリファクタリングする、などの行為がすべて無駄と感じられてしまった。回答を通すためだけに、 ad-hoc な if 文がどんどん付け足されていく。そして、回答が通った時点ですごく達成感が出てしまい、完成したコードにはまったく興味がなくなってしまった。atcoderに参加しただけで、普段システム開発をしている自分の頭がそのような発想に至ることがあるなんて全く想像していなかったので、恐ろしくもあり、競プロのマインドはシステム開発とは全く違うと痛感させられる経験だった。
こんなマインドでプログラミングを覚えた人間は、絶対にまともな開発はできない。ひどい手癖が染み込んでいる上に、そこに自信を持ってしまっているのが非常に恐ろしい。ずぶの初心者よりももっと悪いと思う。
エンジニアをしているが、
テスト仕様書を書きますねって言ってくれるディレクターがいる。
インフラからアプリケーションまで一人でやっているからか、自分の仕事を奪われたようでちょっと悔しくなった。
これではシステム屋ではなくて、ただのプログラマーでは無いか…。
そこまで手が回らないって情けなくなってしまう。
ただ、
ディレクターがやってくれるのはあくまで総合テストの事であって、
それに、時間がないから「実際に使ってみて変な所があったら教えて？」
って言うつもりだったのを前もって準備してくれるのだから想定どおりでありがたいこと。
自分だって、ディレクターをした時は、エンジニアの為に色々補助や書類周りの作成してたっけ…。
素直にありがとうって言ってもいいよね。
追記 0号相当は単体テスト用非動作機だったりメーカー通し(〇〇社試作第10031など)だったりして確かに現実には少ないかもしれない。
試行錯誤で出来た原型機がある場合は0になり得るが、ない場合には上に書いたような1番始まりの試作シリアルと量産シリアル体系がそれぞれ用意されるケースもある。
例えばボーイング787は試作機がMSN 40690/LN 1(ZA001)からMSN 40695/LN 6(ZA006)まであって、次の量産機が巻き戻ってMSN 34485/LN 7, MSN 34488/LN 8らしい。MSNとLNというのはボーイング通しの製造業者製造番号と787のラインナンバーだそうだ。
このケースでは試作と量産は同じシリアル体系のうち40kと34kという範囲違いだな。
F-15の場合は米空軍シリアル71-0280から71-0291が試作機として存在している。0280は0号機と言えるかもしれない。空自F-15DJの一号機二号機は02-8801と02-8802で、次の8機が飛んで12-8803から22-8810らしい。このNN-NNNNという体系は米空軍では共通のもの。頭二桁は初年度の会計年度かな。
ブコメで言われてる心神がX-2だかX-3だかいうのは米のXプレーンを真似たもので、F-15やC-135などと同じように「X-2」までが機種名になる。
メーカー系SIer（仮にF社とする）のプロジェクトのもとで単体テスト工程に参画しているんだけど、非常につらいものがある。
この状況でテストする身にもなってくれよ...。
もう疲れた。
例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。
「コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「２１００年に２月２９日はあるか」という処理までチェックするものです。」
リソースが無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。
極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。
ライブラリの単体テストでは、「２１００年に２月２９日はあるか」というテストを行うかもしれない。
しかし、結合テスト、システムテストとテスト局面が進むたびに、いちいち「２１００年に２月２９日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。
「２１００年に２月２９日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。
ここもちろぐ
生産性志向のSEが、IT業界での奮闘記や仕事や生活で学んだことをはきだします。
2018-05-15
gizeh-2272008_640
こんにちは。もちです。本日は、みずほ銀行のプロジェクトで2か月限定支援に行った時のことを話したいと思います。
あの頃は、ちょうどポケモンGOがリリースされた時期でした。 プロジェクトのお昼休みに、わくわくしながらアプリを立ち上げて、メンバーの方と遊んだものです。
そんな次期システムが、いよいよ、2018年6月9日から徐々に移行開始されるそうです。
みずほ銀、9日からシステム移行 「世界最大級のプロジェクト」 ATMやネットバンクに臨時休止日 (1/2)
みずほ銀行とみずほ信託銀行は、入出金や口座管理などを担う勘定系システムを統合した次期システムへの移行作業を9日から始める。4000億円超の資金を投じて進めてきた世界最大級のプロジェクトが、最後のヤマ場を迎える。
www.itmedia.co.jp www.itmedia.co.jp
移行が発表されてから、「あの頃が懐かしい」と感じたため、せっかく浮かんだいろいろな想いを残そうと思って記事にしました。
ここもちろぐ
ここもちろぐ
みずほ銀行のプロジェクトで2か月限定支援に行った時の話、まなび編です。 ▼前記事の問題編はコチラ www.cocoamocchi.com 古参メンバーの仕事を奪う デキる古参メンバーはとにかく忙しいです！！ 新規参入者でもやり方さえ一度知れば、できそうな仕事もありそうだということで、積極的に仕事を奪いにいきました。 たとえば…
2018-05-17 22:53
www.cocoamocchi.com
毎朝エレベータに長蛇の列
人気アトラクションかな？と思わせるほどの大行列でタイミングが悪いと10分以上待たされました。
テストフェーズがちょうど一個上の段階に進んだためか、チーム内のスマホは鍵付きロッカーでしっかりと管理されるようになりました。
インターネットが使えない
security-265130_640 これが一番厄介でした！！！
新入社員であれば、まずはググり力を鍛えろ！と先輩に教わるも方もいるのではないでしょうか。
わたしみたいなIT業界で働く方々は特にインターネットで調べまくる生き物です！
なのに使えないので厄介でした。
・・・とはいっても、わたしの場合は、こっそり休憩スペースにスマホを持ち出して調べてました。
他には、書籍にもお世話になりました。
ここで 「ネットが当たり前だと思うな、腕を磨こう」という教訓を得ました。
印刷用紙が真っ赤で読みづらすぎ
持ち出し抑止のために、プリンタ用紙が赤くなっておりました。
(特に持ち物チェックがあるわけではないので、悪意のある人なら持ち出せたかと思います。)
印刷してみるとまあ～わかりづらい。 気持ち的にもなんか落ち着かない。
でも一定の効果はきっとあったのだろう。。
ただでさえ生産性の低い環境なのに、働き方もやっぱり残業ばかりされている方だらけでした。
特に既存メンバーの古参者は大量に仕事を抱えているので、いつもヘトヘトです。
他の人へのレビューも、当然荒い。
また最終退館者名簿を見ると、お客さまサイドも負けずと毎日23時台まで残っているようでした。
※ちなみに
ごめんなさい、わたしは最長でも21時には帰りました！寝不足すぎると生産性がダダ下がり逆効果なので苦笑。
単体開発 バグ改修
私の場合、残念ながら新規開発部分は残ってなく、仕様取り込みやバグ改修をちょこっとやったくらいです。
開発ではなく、ほとんど仕様整理やJP1いじっている時間が多かったです。
命名規則がつらい
短い単語をアルファベット1文字で表現する文化があったため、それらをつなげて作成されるDBのテーブル名やカラム名が新規参入者にとってはしぬほど分かり辛かったです。
1箇所の修正で5個もケースはないし、誰も見ないのではないかなというくらい、ゆるふわなテスト結果が置いてあったりと、とてもじゃないけどもお金を扱うシステムだとは思いませんでした。
これ、結合テスト以降、バグ爆発するのでは？という印象だった。
the-1865639_640
階層がとにかく深く、無秩序に置かれた何千のフォルダ群はまさにジャングル。
既存の古参メンバーであったとしても、過去の単体テスト仕様書の在り処を探すだけで10分以上かかっていました。
IDEなど開発に使用するツールも、各チーム持っている情報が異なっていて、結局、既存メンバーの持っているものを丸ごとコピーして使ってました。
個々の期限がタイトにも関わらず、申請日時を厳守しなければならないのはつらかったです。
この申請は、数チームで1つのエクセルファイルにまとめて申請します。
プログラムファイル１つ１つのパスを記載していくのですが、 誰かが1ファイル既述を誤るだけで、
どこぞやのチームのせいで2連続申請ミスされたこともあり、こちらとしてはたまったものではありませんでした。
もしかしたら、誰かが休みたいがために、わざとミスしてるのではと疑いたくなるくらい大変でした。
まあ、とはいっても緊急リリースみたいな１～2日でできる裏技も時に使うことができたため、そこまでではなかったのかもしれません。
プロジェクトマネジメント
child-waving-goodbye-595429_640
うちの会社だけかもしれないけど、メンバーの離脱が、作業指示を出しているチームリーダーまでなかなか届かない印象でした。
「来週からこの作業お願いするね」と言っていた矢先に、彼らがいなくなることを知らされる。
これは、どこの炎上プロジェクトもですが、各タスクの期限だけ決まっていて、工数は考慮されていない事案です。
この事案は仕方ない場面もありますので、メンバー側がリーダーやプロマネに少々寄り添って、自分で仕事を考えていればOKです。
親切なプロジェクトじゃないのは分かっていることなので、他責にせず、ざっくりと工数を伝え、助けていきましょう。
新規参入者の実力が怪しい
少し言語知っている程度(for、if文はできるけど・・)で意思疎通の難しいプログラマーが国籍問わず、たくさんおりました。
猫の手も借りたいくらい忙しいプロジェクトだったので、自分で主体的に仕事を考え、動き、古参メンバーを助ける必要があります。
しかし、
進捗が良くないことをごまかす
など、この中のどれか1つ該当ではなく、複数持ちのプロジェクトキラーが何人かいました。
他の人も急に想定外の残業フォローをしなければならなくなるし、本人は無駄に悩み続ける時間増えるし、誰も幸せにならない感じでした。
まとめ
特に銀行のプロジェクトは、生産性の低い現場やずたぼろな構成管理など、環境的問題も多いことがわかりました。
同時に他責にせず、主体的に行動すれば、新規参入者でもそれなりに活躍できることもわかりました。
しかし、わたしの場合、２か月限定が配属前から決まっていたこともあり、
心までしんどくならずになんとか戦えたことが大きいかもしれません。
もし炎上案件に出会っても、 心や身体をやられるようなことがあれば即刻辞退をおすすめします。
残業による残業という負のスパイラルが、もし嫌なら、早く抜け出すほうがこれからの人生豊かです！
断言できます！！
数年前に開発会社から全く別業界のシステム部門に入り、受注者から発注者に立場が変わったので良い発注者になろうと頑張ってきたつもりなんだけど
先日中途で入ってきた同僚が、長く付き合いのある開発会社に「改修案件の見積もりの根拠が分からないので改修対象のステップ数とソース数を出せ」とか言い出して、それを止めようとした自分と喧嘩になった、しかも「改修見積もりをしたのならステップ数は当然すぐに出せるはずだ」と言いながら
そいつは以前にも「単体テストの結果も全て説明付きの画面キャプチャをエビデンスとしてつけろ。これは当然の事で、テストをしたのなら作っているはず。だから追加工数も払わない」と言い出してこれも喧嘩になった
残念ながらうちのシステム部門は専門の人材がいない為、こいつの言うことのおかしさを理解してもらえない
「規模を知るためにソース数を貰うのは当然の事です」とか言い出して、それをまわりが真に受けてしまう
いくら自分が反論しても1対1の話なので「やり方は色々あるからね」と窘められてしまう