P.27 選んだ道が正しくても、座り込んでたら轢かれちまうぜ俳優ウィル・ロジャース
常に状況に気を配り，変化に敏感になれってことかな。それを言うための警句がこれってのが格好いいね。
P.33 みんなが自分より凄いって？ 素晴らしいじゃないか！ 伝説のジャズギタリスト、パット・メセニー曰く「どんなバンドで演奏するときも、一番下手なプレイヤーでいろ。もし自分が一番上手いんだとしたら、それは別のバンドに移るときだ。同じことは世の中のほとんどのことに当てはまると思う」 どういう意味だろう？ 自分がチームで一番うまいとなれば、それ以上の努力を続ける動機が無くなってしまう。一方、周りのメンバー全員が自分より優れていたら、何としてでも追いつこうという強い動機付けになる。これを続けていけば、きっとずっとうまくなれる。
周りのすごい人から貪欲に学んでいけ。周りに気圧されるんじゃなくて逆に利用するぐらいの強かさを持てって感じかな？ これは実際の仕事で実感することですね。チームで最底辺のメンバのときこそ爪を研ぐチャンス！って考えるべき。
P.53 設計は指針であって、指図ではない 優れた設計は地図です。少しずつ発展させるのです。 設計は、正しい方向を示す道しるべではありますが、土地そのものではありません。具体的な道順を事細かに指定すべきものでもありません。設計（または設計者）に囚われてはいけません。
ソフトウェアの設計について地図の比喩は分かりやすかった。常に変更されることが前提の設計書ってなんか矛盾した存在だよなーと日ごろ思っていたので。
P.６５ 最初からアプリケーションのデプロイを自動化しましょう 自動化されたデプロイの仕組みを用意して、さまざまな構成のマシンへアプリケーションをインストールし、アプリケーションの依存関係をテストしなさい。QAはアプリケーションだけでなくデプロイもテスト対象にするのです。
「デプロイもテスト対象」ってのはなかった発想でした。なるほど自動化すれば即テスト対象になって品質もあがる，と。
P.111 クラス内の各メソッドには次のようなコメントを入れておくと良い ・目的：なぜこのメソッドが存在するのか ・必要条件（事前条件）：メソッドの呼び出しに必要とされる引数はどういうものか。呼び出し時にオブジェクトはどのような状態であるべきか。 ・結果（事後条件）：メソッドが正常に完了した際にオブジェクトはどのような状態になるか。戻り値には何を返すか。 ・例外：以上が起きた場合にはどんな例外が送出されるか。
これは大体やってるけど，改めて覚えておこう。Javaの場合はEclipseのコメント挿入機能に助けられている面も大きいし。
P.120 シンプルは安直のことではない シンプルであることは誤解されている。プログラミングでもそうだし、世間一般でもそうだ。シンプルであることは、安直だとか未熟だとか、不足しているといったことを意味しない。むしろ、全く反対だ。シンプルさは、やたらと複雑で後先を考えない解放よりも、はるかに実現が難しい。 プログラミングや文章のシンプルさは、シェフが丹念に煮込んだソースに似ている。大量のワインとブイヨンとスパイスが濃縮されたエッセンスになるまで丁寧に煮詰めていく。優れたコードには上質なソースにも似た趣がある。鍋一杯のオートミールではなく、芳醇で洗練されたソースの味わいというわけだ。
この本で一番読みたかったところ。「シェフの煮込んだソース」という比喩にしっくりきた。『シンプル』については「シンプリシティの法則」という本を読んで勉強してます。シンプルってのは考えれば考えるほど難しいよ。
P.122 設計の品質を評価する最善の方法のひとつは、直感に従うことだ。直感なんて理性的な基準とは思えないかもしれないが、直感を呼び起こすのはあなたの経験とスキルだ。設計を評価するときは、自分の直感を信じるんだ。何か引っかかるものを感じたら、それは「どこかが間違っているからだ」と考えるんだ。良い設計は、見ていて気持ちが安らぐものだ。
おぉ，ここで「直感」押しですか。うーむ，個人としては良いけどチームメンバと設計で議論になったときに「俺の直感が正しいといっている！」では困るからなぁ。それは別の章で書いてあったっけ？ 個人的にはこの内容には同意。良い設計は心和みます。
P.158 新システムの設計者 新しい分野のシステムを担当する設計者は、実装にも全面的に関わらねばならない。ドナルド・E・クヌース
アーキテクトがコーディングに参加すべき，という章で。クヌースが言ってるから間違いない（クヌース論法）。実際のところ，本でも比喩で出てきたが，前線の状況を知らずに指揮は取れないってことだよね。あと「新しい分野の」ってのを先頭につけてるのにも注意。但し今の時代で新しくない分野のシステムにはほとんど価値がない。
P.158 マーティン・ファウラーは、「Who Needs An Architect?」という記事で、（中略）「私が思うに、アーキテクトの最も重要な任務の一つは、ソフトウェア設計から不可逆性を排除する方法を見つけることによって、アーキテクチャを取り除くこと」だとも述べている。可逆性を育てることは、現実に即したアプローチとして重要な要素だ。
設定ファイルをちょちょいですぐに直せるようにしとけってことかな？ 変更に対して強い設計にしておくのは重要だと思います。
全体的な感想としては，この本を読んで無条件に「だよねー」と同意し合える人たちと一緒に仕事したいなぁってことでした。 私が勤務している会社では大規模開発（≒ウォーターフォール型開発）もやるんですが，個々のフェイズでは実態としてアジャイルに開発をしているところがあります。なので部分的には本書のプラクティスを取り入れたりしてるんですが，大元のウォーターフォールに引きずられて徹底できていない部分も多いです。
しかしそれで諦めるのではなく，上手くウォーターフォールとアジャイルをプラグイン！するような感じで開発が行えないかなーと思いました。他の人はウォーターフォールに慣れた開発者が多いので，自分のやりたい開発の仕方を伝えるのに，本書のプラクティスを紹介するのが早道で便利だと思いました。
ウォーターフォール，ウォーターフォールって言っても実際はアジャイル開発の出来損ないみたいな開発プロセスになっちゃうんだよ結局！ だったら最初からアジャイルを真正面から取り入れましょうぜ！ みたいな大見得を切りたい！！
それはそれとして，アジャイルプラクティスを趣味プロジェクトに当てはめて考えてみると・・・
- Diptych開発
- 設計のシンプルさには自信あり。
- デプロイは自動化されてません・・・。
- デプロイスクリプトを書くこと＞自分
- 一人プロジェクトなので，これ以上ないってぐらいアジャイルなはず
- アーキテクト＝プログラマー＝ユーザー＝自分
- モチベーションを維持するため，定期的なミーティングを開くべき
- 脳内会議でも良いけど，議事録は残したい
- アクィナス･キャプチャー使えば良いのでは？
- Diptych自体を使用すれば，「Eat your own dog food」にもなる
- ユニットテストについては要調査。
最後に，先ほどGoogle App Engineのアカウントの招待メールが来ました。招待メールが来るまでにPythonを覚えておこうと思ったのに，ぜんぜん勉強してねーよｗ
ということでPythonの勉強ついでに，GAE版のDiptychも作ろうかなーと思ってます。
【参考リンク】 かくたにのWiki - 『アジャイルプラクティス』サポートページ 第20回XPJUGユーザ会のプレゼンテーション録画をニコニコ動画で公開しました - 角谷HTML化計画 (2008-03-08) 監訳者の熱い思いが伝わってくるプレゼン。震えるぞハート，燃え尽きるほどヒート！しましたｗ
0 件のコメント:
コメントを投稿