先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト

ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13

なんもわからん @babie TDDは論理実証主義的な面が強調されすぎたために、BDDなどという言い換えが行われた。反証主義的に、エラーを積極的に起こそうとするテストを書くべき。 2010-02-21 13:45:09

先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、

2009年10月19日 何故日本企業のソフトウエア・オフショアは失敗するのか　- for under-ground 4：Blind sight - カテゴリ：何故日本のオフショアは失敗するのか 要件を"まとめ"、"break-down"するのは、あくまでも受注側のengineerでなければならない。 色々な視点で客先要件や、社内の現状、移行を事前に調査し、 検討違いの主観を入れない為に、結果を要件実装のための基礎資料としてそのまま投下する、 これができることが社内SEの能力で、発注側のSE能力だと思うが、違うか？ だが、日本人は発注側の主観で要件をまとめてしまう。 最悪なのは、要件を"日本語"の数語にまとめ、 そのまとめた語を英語に直訳して、悦にいっている勘違い野郎が多い。 おいらがleaderやっていたら、漏れなく昼間っから マ○かくなら、自宅でやんな！ボケ と罵られるpatternだが

ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの

第3回「The Secrets of Consulting」Gerald M. Weinberg：翻訳エッセイ編（3）―お金についての質問 Gerald M. Weinberg（ジェラルド・M・ワインバーグ） ［著］，青木靖［訳］ 2009-10-27 第3回「The Secrets of Consulting」Gerald M. Weinberg：翻訳エッセイ編（2）―なぜ我々は会議を愛する／嫌うのか Gerald M. Weinberg（ジェラルド・M・ワインバーグ） ［著］，青木靖［訳］ 2009-10-26 第3回「The Secrets of Consulting」Gerald M. Weinberg：翻訳エッセイ編（1）―コンサルティングを悲惨なものにしないための仕事条件 Gerald M. Weinberg（ジェラルド・M・ワインバーグ） ［著］，青木靖［訳］ 2009-10

「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

いざプログラムを作ろうというときに。 ・データの流れがおかしい。 ・データの扱い方がおかしい。 こんなことに直面する。 調べてみると、データベースの構造がおかしい。 なぜか。 ・前任者の遺物を有効活用した。 ・画面からマスタテーブルを作成した。 ・あの場合も、この場合もとデータをうまいこと使いまわすことを思いついてしまった。 どれか一つは当てはまるような気もする。 さて直そうという気持ちが芽生えたときに障害になるもの。 ・ドキュメントの影響範囲調査 ・ドキュメントの修正 ・ドキュメントの整合性チェック 同時に対比材料に上るもの ・あるべき姿に修正した後の修正時間の気楽さ ・現在のままで作り上げた場合の修正時間の気重さ や ・あるべき姿に修正した後の推進力 ・ドキュメントの修正時間 ってなこと。 今回は、こうなった 「ここだけデータのカタチが綺麗になっても全体がひどい。だから目を瞑るか」 ゴ

http://alfalfa.livedoor.biz/archives/51466352.html だいたい出尽くしてるかな． なんでプログラミングやった事の無いやつがＳＥなれるんだろうな。不思議。 パッケージの購入とかになるとこれでもかと買い叩きまくるのに、自分たちのために一から作ったソフトウェアということになると、くだらない機能のバグだらけのソフトでもバンバン大金を払う。 ベンダー側の立場から見てどっちが儲かるかは一目瞭然なので、普通のパッケージソフトはどこも作りたがらない 労働条件が酷いから優秀な人材がビックリするほど集まらない。 日本のIT企業は雑用をやってるだけの感じ。プロフェッショナルな企業が少ない。もっとグローバル戦略持たないと、web屋も日本での受注ぐらいしかしないだろ 回すものが「物体」ならいいが「人間」を売買して、「弊社はシステム開発業です」とかいうのは酷いと思うんだ

「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス

たまたま見かけたのですが、とても示唆に富む記事だったので頑張って和訳してみました。延べ2週間近くかかった・・・。 ITを武器にする企業は、ベンダーやユーザーに関わらず｢program manager｣と呼べる人たちが必要だと思っています。37Signalsの｢Getting Real｣に近しいことをJoel自身も語ってくれていますし、今後僕らがどのようなキャリアを積んでいけばいいのか、技術力を梃子にしていく組織を作るのにはどうしたらいいのか、そういうヒントが込められています。 Joelの英語は、同じような意味の言葉を複数の言葉を使い分けて言っていたり、ぐるっと回り込んでから要点を記述することが多いので、正確な意味を伝え切れていないかもしれませんが、大きく意味が外れないように留意したつもりです。 原文はHow to be a program manager - Joel on Softwar

ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが