ウニ’s blog

勉強した結果を書いていきます

エクストリームプログラミング本を読む(1)

積んでたエクストリームプログラミング本。むずかしい。
翻訳のせいもあるかもしれないが、アジャイルサムライ本の気楽さが薄く、硬い感じ。
今はせめて、できるところ、気になったところだけでも実践していこう。

エクストリームプログラミング

エクストリームプログラミング

気になったところ

エクストリームプログラミングから引用

  • 気がついたらふりかえろう

    振り返りは「公式」の機械に限定すべきではない。配偶者や友人との会話、休暇、ソフトウェアとは関係のない読書や運動といったもの全てが、今どのように仕事をしているのか、なぜそのように仕事をしているのかを個人で考える機会となる。食事やお茶をともにすれば、非公式な場で一緒に振り返ることもできる。

そうする。

  • 品質については、出来る限りのことをやろう

    品質が心配だからといって、なにもしないことの言い訳にしてはいけない。きれいに実装する方法がわからなければ、出来る限りのことをすればいい。

そうする。

  • テストは2つの視点を持とう

    ダブルチェックの恩恵を完全に手に入れるために、XPには2セットのテストが用意されている。一つは、プログラマーの視点で書かれたテストだ。システムのコンポーネントを徹底的にテストするものである。もう一つは、顧客やユーザーの視点で書かれたテストだ。こちらはシステム全体の操作をテストするものである。

テスト書かないとなあ…

  • 常に設計しよう。実装後に分かることなんて沢山ある。

    前持った設計は必要だが、最初の実装ができるだけで十分である。それ以上の設計は実装後に設計の本当の制約が明らかになってから行えばよい。XPの戦略は「何も設計しない」ではなく「常に設計する」である。

これは素晴らしい。刃の切っ先のような考え方だ。

  • Once and Only Once

    私の知る強力な設計方法は「Once and Only Once」である。これは、データ、構造、ロジックなどは、システムの一つの場所に存在すべきであるというものだ。

これなにかで見たな、と思ったらPythonの思想だった。

  • 作り過ぎが最大のムダ

    TPSの精神的指導者である大野耐一氏は、最大のムダは「作り過ぎのムダ」だと言っている。何かを作り、それが売れないとなると、作った労力の行き場がない。

アジャイルサムライで言うところのスパルタ式リリースを目指していきたい。
一気にでかい結果を出そうとすると大抵、その前に力尽きてしまうので…。

参考

qiita.com

There should be one-- and preferably only one --obvious way to do it. たったひとつの冴えたやりかたがあるはずだ。

終わりに

ちょっと頭が良くなったら、見直します。