テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
レガシーコード改善ガイド読書会 2010-04-03 - 未来のいつか/hyoshiokの日記
先日、会社でレガシーコード改善ガイド読書会を行った。1回しかやっていないので、今後どんな感じになるのか正直わからないが、1回目の振り返りを記してみる。 〆会、テスト勉強会（社内）などで有志を募ったところ、なんやかんやで10数名が名乗りを上げてくれた。どんなペースでやるかとか運営をどうするかとかを相談するために、参加希望者で集まった。週1回（木曜日、19時開始）、担当の章などを決めた。第1章〜第5章までは各自で読んで、読書会への参加の動機などを含めて簡単なポジションペーパーとしてまとめることにした。 わたしが、読書会の世話役として、会議室の確保（空き会議室を見つけて予約しただけ）、開催のアナウンスなどを行った。資料置き場の共有ディレクトリ、社内Wikiなどを立ち上げた。*1 テストがないコードはレガシーコードだ！ 「テストがないコードはレガシーコードだ」という強烈なフレーズが表紙に書いてある
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか - 未来のいつか/hyoshiokの日記
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース（OSS）を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
2009-08-22
セキュリティ＆プログラミングキャンプ2009のわたしの講義で、「オープンソースにすると企業は損をするんじゃないですか」という本質をとらえた質問がでて、講師陣が、いきなりいろいろ議論を始めた。 企業の行動原理は、利益の追求だから、利益を生まないアクティビティは原則として行わない。オープンソースも例外ではない。 利益＝売上-経費 なので売上が増えるか、経費が減るかという観点から投資判断をする。当たり前ですな。 例えばマイクロソフトが自社の製品をオープンソースにすると、売上が伸びるか、あるいは経費が減るかというと、どちらもそうとは言えないので、マイクロソフトが自社製品をオープンソース化することは考えられない。先日マイクロソフトがHyper-V向けのLinuxドライバをGPLで公開したことが話題になったが、Linuxドライバを公開する事が自社のHyper-Vの魅力を増し、売上向上を期待して公開した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
