  |
はてなキーワード: 結合テストとは
SIerのときはウォーターフォール型開発の二次受けのテスト要員でした。
残業は月当たり平均でだいたい40〜60時間くらい、最大100時間。
多いといえば多いし、デスマかと言われればデスマではありません。
とはいえ身の回りの自動化、スクリプト書きやらVBAでツール作ったり程度でしたが。
そうして仕事になれ、うまくこなせるようになり、
高度の情報処理技術者試験なんかも受かって、社内での評価もそこそこ良かったと思います。
開発の案件がやりたいと3年位言っていた気がするけど、
結局テストばかりでした。
そしてあるときふと考えました。
これは何の価値があるんだろう。
顧客の無茶なスケジュールを飲んで、それを頑張って残業して休日出勤して間に合わせて、
また無茶なスケジュールを受けざるを得ない状況を生んでいるんじゃないだろうか。
この状況は変えうるんだろうか。
いや、これはピラミッド型の業界構造が抱える問題とリンクしているから、
そこから外れない限り変わらない。
負の方向のスパイラルに居続けることは、
耐え難いことでした。
ようやく言葉になった。1年半かかりました。
すこしだけすっきりしました。
お目汚し失礼致しました。
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
汎用品なら、設計が使い回しできるけど 専用品の場合、設計が使い回しできず
小規模のものなら、部品間の整合性を取らなくてもいいけど（結合テスト） 大規模品だと部品間の整合性を取る必要性が合って
整合性が取れなかった場合、（その部分が）設計からやり直しになる。 設計が使い回しできる場合このコストは製造側で請け負うけど、使い回しできない場合はお客様都合なのでお客様負担。
したがって、専用品の場合は、汎用品と比べて単価は高くなりますし、やり直ししないで済んだとしても、それは運良くやり直しをしていないのではなく、
弊社のノウハウとしてやり直しをしていないのであって、技術料という事になります。
そうでない場合、残業などで対応となるので、その分の経費が含まれることになります。
たとえば、人月８０万円の人を雇って１００万円で売っているのは、２０万円分の設計のアシストを会社がしているからであって、妥当。
言い方を変えれば、お客様が人月８０万円の人を直接雇って、作業させてもノウハウがないから結果出来上がらないでしょ？ 単価が高くなる文は会社が提供する技術料。
会社がノウハウを労働者に提供して、高付加価値化しているので、その分は高くなる。
結論として、設計が要らないくらい単純な品であるか、技術力がなくても設計ができるぐらい汎用的なもの、さもなければ、設計が使い回しできる品であれば単価を下げることはありますが、専用品の場合は高くなります。
といったところでは？
興味深い研究ですね。
大規模化していくと、（複雑すぎて）設計図通りに出来ない奴が増える。
これは別に大規模にしようがしまいが、設計図の請け負うべき部分の大きさによるでしょ。
むしろ、大きな全体の小さなモジュール1つであれば、それ自体の中で確実にメモリ作業を閉じる様な設計にしておけば
良いわけで、
勿論、それが全体の設計と合わせて大変な事は分かるけど、
大規模化していくには必要な事で、その辺は上の設計の腕の見せ所でもあるでしょう。
ん〜、って言っても、フルスクラッチったってさ、全てが全て、"新しい"わけじゃないでしょ？
結局今までにある何らかのシステムのコピー的な部分は絶対にあるわけで、
逆に今までにある資産を一切使わずに作る、ってのは単なる趣味で仕事としては効率悪すぎるわけで。
これは単に納期や見積もりが甘いだけなんだから、かっこつけて文句いうところじゃないでしょ？
勿論、現場の人間が期限決めてるわけじゃないからそれに合わせてやってる俺らは凄い、って言いたいのは分かるけど、
つまりはそういった体力勝負でやってる、ってことは、これまで土方で体力だけで仕事もらってきた人間と何も変わらない、ってことだよ。
むしろ、土方のあんちゃんとかは、欝になりました、辞めます、なんて簡単に言わないからよっぽどちゃんとしてると思うけどね。
単に回すだけの資金が無いだけなのに、そういうこと言わないの。
使う側からすると、徹夜しなければ作れないレベルの会社に出すことがデスマーチの原因だ。 検品するコストや結合テストをするコストは０じゃない。
大規模化していくと、（複雑すぎて）設計図通りに出来ない奴が増える。
バグをバグで直しておいて（つまりたまたま通っているだけで、条件を変えるとまたバグる）治りました。という人が異常に多い。
とくにメモリ破壊エラーとかは、通常のやつに作れても、治せない。
ようするに、作ってるんじゃなくて、破壊してる奴が多い。
メンテナンスならともかく、フルスクラッチに近い仕事は少数精鋭で作るしか無い。
それを経験すると、そもそも、（難しい部品の）設計図を回さないって事が始まる。
昔は、それでも、子会社を喰わせるために、簡単な部品の設計図だけを下請けに回してたけど、
今後はそういうのは無くなっていくだろ。
使う側からすると、徹夜しなければ作れないレベルの会社に出すことがデスマーチの原因だ。 検品するコストや結合テストをするコストは０じゃない。
http://d.hatena.ne.jp/iad_otomamay/20130318/1363596244
この記事。本当に腹が立ちました。
まず質問自体が酷いのが多い。
省略したのは知らないと障害の危険があるので知っとくべきってことで同意なんですが、
これは使うときにググれば良い話。暗記しておくメリットがわからない。
結合テスト中のシステムで、OutOfMemoryErrorが発生しました。UT後ソースコードの変更はしていません。ヒープメモリは足りているようです。原因として何が考えられますか？（筆記解答）
「UT後ソースコードの変更はしていません」という一文が意図不明。単体テスト終わった後にソースコード変更したら、再度単体テスト必要だと思うのですが？この一文は何のヒントにも制限にもなっていないです。
なぜNGなのかというのは「文字列連結演算子(+)では速度が遅いから」であり、StringBufferかStringBuilderのような結合用クラスのappend()を使うことでパフォーマンスは向上する、というところまでが質問の狙いなのかと思いました。もう一歩踏み込むならば、+をしたときにコンパイラでどのようになるかを知っているかどうか、みたいな。しかし結合用クラスにはデメリットもありまして、append()は冗長過ぎて可読性が酷く低下するデメリットがあります。文字列の連結時にクラスをnewするタイミングを調節したほうが速くなることもあります。近年ではマシンのスペックもあがってますので、そんなに気にする部分ではないと思います。そもそも、このStringBufferの仕組みは絶望的に救いがないJava言語の汚点と言ってもよい部分です。なんで文字列の連結方法に複数のやり方を速度だけの理由で取捨選択させるというバッドノウハウなので、早くコンパイラが最適化して一元化くれることを望む部分です。
StringBufferかStringBuilderと書いていて、そういやスレッドに関しての質問がないのはどういうことなのかと感じました。JavaのWeb系ってスレッド重要だと思うのですが。
JavaScriptでHTML要素をid属性の指定により取得するメソッドは何ですか？（筆記解答）
もうjQueryやDojoも使われるようになってきたからこれも知らなくてもいいんじゃないかと。id指定で取れるということとを知っておけば答えにはたどり着けるはず。バッドノウハウです。どうしてJavascriptが最近になって流行ってきたかを思い出して欲しいです。
プログラマーはバッドノウハウの塊でなくてはならない、というのが見えてくる質問内容ですが、最近は覚えなければならないことが多く、技術の更新スピードも早いので、あの質問のような重箱の隅まで暗記するようなことをしていては、重要な部分が抜け落ちているし、暗記の苦手な人は辛いと思います。書籍もネットのような情報の蓄積と抽出する部分は充実してきたので、概念は知っておいて、実装手段はその都度調べるほうが効率的であるかと思います。質問は、応用の効く根本的な部分を問う方がよかったです。
「現実は、もっと凄惨な世界を経て時代が進んでいくようだ。」などと締めくくっていますが、この人は凄惨な世界が嫌なのでしょうか？不安を煽るだけで対策も講じていません。まず、質問の回答を書くだけでも、読んだ人の知識の底上げに貢献できると思うのが普通です。「これは基礎教育をやってれば当たり前」とか言ってドヤ顔して、できない人間を馬鹿にしているだけに見えます。本心では凄惨な世界を望んでいるのでは？としか思えてなりません。
この記事を読んだことで、またSI業界から優秀な人が遠のくことでしょう。こんな人間が居る業界には居たくないと。
どうして悲しみを減らす方向に動いてくれないのかと…
※追記
頭沸騰しててスルーしてしまったのですが「淘汰」って書いてあったので、業界の底上げは望んでないんだなあと、見当はずれなこと書いてしまったなあ、と、後悔した。
http://anond.hatelabo.jp/20120407162253 に便乗して。
それなりに大きなとある会社のプログラマだけど、うちの会社のビルドシステムがおかしい気がする
あまりにも原始的なので違和感を感じるんだけど、自分にビルドシステムに対する知識が圧倒的に不足しているので、今やってる作業に本当に意味があるのかよく分からない。詳しい人に教えてもらいたい。
手動でコピーするからよく事故が発生するし、同じファイルが複数箇所にあるので全然履歴が追えない。
あと、中間ファイルや実行ファイル(.o とか .so とか) も含めてごちゃまぜにチェックインされているので、もっと訳がわからなくなってる。
「ビルドは成功しないのが当たり前」とかいう人ばかりで、正直発狂しそうになる
フォルダツリーがわかりづらいと思うので図を書くと
/ Main/ -- 共通ファイルディレクトリ foo/ bar.c driver/ common.c ProductA/ foo/ bar.c -- ProductA 用の変更が入ってる baz.c -- ProductA 専用ファイル driver/ common.c ProductA_Orig/ -- ProductA/ 内の ProductA用ファイルが丸々入ってる foo/ bar.c baz.c ProductB/ foo/ bar.c -- Main と全く同じ driver/ common.c ProductC/ foo/ bar.c driver/hoge.c ProductC_Orig/ driver/hoge.c
こんな感じになっていて、共通部分は Main/ の中とそれぞれの ProductA, ProductB, ... ディレクトリの中にすべてコピーされている。
チェックインするときはすべてのファイル、例えば bar.c を更新したら Main, ProductA, ProductB, ProductC の bar.c を手動で更新する必要がある。
ビルドするときは Main/ のファイルを ProductA/ にコピーして、 ProductA_Orig/ の中の機種依存ファイルをさらに ProductA/ にコピーする。これは、同名のファイルが Main にもあって、 ProductA のファイルが上書きされるかららしい。
ビルドできないので、最後の最後まで結合テストが出来ずに、みんなローカルPCで開発してる。誰かのPCが吹っ飛ぶとその人が開発していた差分が消失する。
「ツリーを共通部分と依存部分きちんと分けて、ビルド自動化しましょうよ」って上長に提案したら「この会社はこれでやってる。むしろバイナリが入っているのでビルドできなくてもテストできる」という感じであまり真面目に取り合ってもらえなかった。
前の会社（部署）は開発を中流？から下流まで中国の開発に支えてもらっている。
支えてもらえているのは以下。
１．プログラミング
２．単体、結合テスト
３．基本設計
これ以外にも、ブリッチに来た人に新人に対し、システム開発を教えている。といった話も聞いている。
中国の方へ。日本のシステム開発案件を奪って下さい。手始めは、汎用性が高い財務だとか会計などの社内システム当たりがいいと思います。
ただ、今はまだ調整役として、日本人を付けて下さい。
そして、出来ればその時、御社で上流工程をやりたい優秀な方を付けて下さい。
日本人は上流で勝負すればいい。上流へ行こう！
それは逃げですよね？日本人が下から上へ登れるなら、他国の人だって
登れますよね？まさか、日本人は頭がいいから追いつかれないとでも？
後発の方が茨の道じゃない分、速そうだ。
木曜の時点で月曜に結合テストしてくださいってお願いしてたのに、朝から始まる予定が始まったのが夕方。
で、ダラダラなかなか終わらず１８時過ぎ。
その時点でこっちは出向で１８時以降残りたくないのに、その日中に結合テストが無事終わるのを確認する必要があったんで待たされる。
で、ようやく始まったかと思ったら、別の不具合見つけて「確認して～」指摘してきて、結合テストを放置。
この時点で優先度考えてないバカっぷりにイライラ。今日中にテスト終わらす気あるん？こっちは待っとるんやぞ？終わるの。
で、調べたけどデータがおかしいし、再現性ないし、しょーもない現象見つけますね。
「それは今関係ないんでテスト進めてください」って言ったら「なんで逃げるん？」って。
そっちの問題は今優先度高くないやろがっ！問題が見つかるたびにテスト中断しとったら今日中におわらんやろがっ！考えろや！
で、まだテストは終わらず、別の作業して待ってたら話かけてきたから「早く結合終わるのを待ってます」って言ったら「でもやることあるやろ？」って。
あほか。やることあったらなんぼでも残業させるんか。残業代でない社員ならまだしもこっちは出向やぞ、金銭感覚無いんか？
んで、ようやく終わりそうってことで「iphone対応した？こんなひねくれた見方すんなって？（笑）」って。
あきれるわ。
ひねくれたもなにも、それが仕様なんやろが！ひねくれもくそもあるかぁっ！
そうゆう漏れがないか確認するために、テストやろうが！！というかそもそも、設計レビューもしてテスト仕様書も確認してって言うて漏れとるやんけボケがぁ！さっさと指摘せんかいや！２２時過ぎて「今から修正できる？」とかふざけんなボケが。
スケジューリングできない
金銭感覚が無い
リスクヘッジができない
イライラさせる
そら下が続かんわ。
いやあ、プログラマだからこそ、コンピュータのサポートの限界くらい知るべきだ。計算力も、普段から勉強しておき様々な知識を記憶しておく重要性もね。
俺らは常にバカで、コンピュータを前にしてもバカな使い方しかできないもんなんだ。
そんで無知な奴ほど「よっしゃコンピュータに任せればカンペキ！」と慢心しやがる。そんで、頭で計算した奴からツッコミ入れられて涙目ｗｗｗ
誤差の処理にバグがあるままマクロで金勘定をやる奴がいてさ。でもちょっと頭で検算すりゃ、奇妙な差が出てるのくらい分かるんだよ。上に報告する前に見つかったから「マクロにバグがあんだよｗ直せ直せｗ」で済んだけどさ。
「ちょっとこれ計算しといて」と言われて急遽書かれた、全くのイレギュラーな作業での、完全に使い捨てられるべきコードだったから、大したテストもやってなかったんだろうけどさ。いや将来も使いまわされるべきとしても、その時点では要求抽出設計開発単体テスト結合テストとかやってられるわけないしさ。
ほんと、こういう奴って困るんだよね。
俺なんだけどさ。
元増田って
http://anond.hatelabo.jp/20091010180917
でいいですよね？
違ったら以下は無視してね。
内部設計書は書いてますよ。
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切？というのがあるから。
適切の基準が曖昧でプロジェクトによってことなるのもその通りです。
エンジニア的には正しくても、会社的に正しくないことがあり元増田のおっしゃる通りだと思います。
王道が共通化というのは訂正します。
ただエンジニア的には共通化は正しく、
エンジニア上がり人は取り締まりに役になってもこんな事言ってたりします。
http://d.hatena.ne.jp/iad_otomamay/20090413/1239632703
内部設計の段階で、内部設計書書いて(or担当者に書かせて)してはどうでしょうか？
そして、そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間と
レビュー実施するようにすべきだと思います。
実装されているか(共通化を含む)項目つくるものだと思うのですが、
内部設計書は作ってないのですか？
担当者のせいばかりにしていても解決しない問題と思っています。
