Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
Martin Fowler's Bliki in Japanese - フィーチャーブランチ
@@ -1,25 +1,29 @@ http://martinfowler.com/bliki/FeatureBranch.html -gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフューチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 +gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
プロダクトバックログの項目は「優先付け」するんじゃなくて「並び替える」 - capsctrldays(2011-08-02)
プロダクトバックログの項目は「優先付け」するんじゃなくて「並び替える」現在、新しい『Scrum Guide』を訳しています（現在レビュー待ち）。今回の変更で気になったのが、プロダクトバックログの項目を「優先付け（Prioritized）」するんじゃなくて、単に「並び替える（Ordered）」という点です。 詳しくは、世界の破壊者 Jim Cope による「Ordered Not Prioritized」に譲りますが、端的に言えば「優先順で並べることが、必ずしもROIや価値を最大化するわけではない」ということです。先の例を借りれば、どんなに優先度が高くてもサンタの画像は冬に表示することに価値があり、どんなに家の屋根が気になっていても最初から屋根を作れるわけはない、ということです。 プロダクトバックログは時間軸を伴う有機的な存在です。全体最適を考えて、柔軟に「並び替える」ことが成功の鍵となりま
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
Martin Fowler's Bliki in Japanese - GroovyかJRubyか
http://martinfowler.com/bliki/GroovyOrJRuby.html 2007/11/27 現在、Java仮想マシン（JVM）上で動くスクリプト言語として、GroovyとJRubyはどちらが優勢なのかという議論が巻き起こっている。 この言語戦争の勝者はどちらなのか！？ 知りたいよねー。知りたいでしょ。 みんなは「プロジェクトに使うのはどっちだ？」とか「今から学習するならどっちだ？」とか気になっていると思う。 まず最初に押さえなきゃいけないのは、このレースの出走馬が2頭だけだと考えるのは公平じゃないってことだ。 JVM上のスクリプト言語の歴史は古く、Jython（JavaによるPython実装）なんてずっと昔から存在している。 他にもいろいろありすぎてよく分からない状況なので、ここではあえて列挙することはしない。「XXXがないじゃないか！」と怒られても困るしね。
Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby
以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。 ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。
Martin Fowler's Bliki in Japanese - ヘロヘロScrum
@@ -0,0 +1,79 @@ +http://martinfowler.com/bliki/FlaccidScrum.html + +2009/1/29 + +//There's a mess I've heard about with quite a few projects recently. It works out like this: + +多くのプロジェクトで混乱が起こっているようだ。 +次のようなことになっているらしい。 + +// * They want to use an agile process, and pick Scrum +// * They adopt the Scrum practices, and maybe even the principles +// * After a while progress is
Martin Fowler's Bliki in Japanese - モデル駆動ソフトウェア開発
http://martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html 2008/7/14 モデル駆動ソフトウェア開発（MDSD）は、 伝統的なプログラミング方式の代替であると謳うソフトウェア開発手法のことです。 この手法は、ソフトウェアシステムのモデルの構築に主眼を置いています。 通常、こうしたモデルは、図を用いた設計記法によって表されます――たとえばUMLが選択肢の1つとなります。 これらの図を使い、 捉えたシステムをモデリングツールに描画して、 伝統的なプログラミング言語のコードを生成する というのが、基本的な考えになります。 MDSDの構想は、図を用いた設計記法とCASEツールから生まれました。 これらの技術の提唱者たちは、図を用いた設計記法をプログラミング言語よりも抽象度を高めるための方法であると考えており、開発の生産性
Martin Fowler's Bliki in Japanese - 優れたほうが安い説
http://martinfowler.com/bliki/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる
Martin Fowler's Bliki in Japanese - ポストモダンプログラミング
http://martinfowler.com/bliki/PostModernProgramming.html James NobleとRobert Biddleにより提唱されたプログラミングの考え方。 その肝となるのは（少なくとも私にとっては）以下のようなことである。 ソフトウェア開発におけるモダンな見解では、ソフトウェアシステムは画一的かつシンプルな方法で構成された同型のコンポーネントから成り立つものとされている。 （SmalltalkやLispはその良い例である。） 一方、ポストモダンな見解では、ソフトウェアは様々なものを、様々な方法で貼りあわせたものとされる。 （PerlやUnixがそうだ。） このソフトウェアスタイル（接着剤の大きなバケツ）は、悪いものではない。 さらに詳しく知るには、Notes on Postmodern Programmingを参照のこと。 ただし、これはポ
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
Martin Fowler's Bliki in Japanese - 生産性は計測不能
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Refactorings - FrontPage : リファクタリング・カタログ