Invalid Text■<%=sn number %> <%=flickr_left '3274768929' %>デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 つかれたのであとで書く。とりあえずスライド。最後までスライドめくれてよかった。 写真はtakaiのを借りてます。練習不足(というかスライド完成したのが10分前)でリモコンを見すぎてしまいました。情けないです。 The way to the timeless way of programmingView more presentations from Shintaro Kakutani. (tags: devsumi2009 xp) slideshare.net kakutani.com よくある質問と答え Q:動画はいつ公開されますか？ A:録画してません。 Q:予稿とかないの？ A:ありません。ひとえ
ソフトウェア開発の分野ではYAGNI(You Ain't Gonna Need It)という表現があります (人によっては「You Aren't Gonna Need It」と書いています)。 「こうなるかも知れない」をドンドン積み上げていって不要に時間を割くべきではないという考え方です。 wikipediaの項目によると不必要な冗長性には以下のような副作用があるそうです。 それによって、別の新しい機能を追加したりテストする時間が削られている 新しい機能にはテスト/デバッグ/ドキュメント/サポートが必要になる 「将来どのような機能が必要になるか」という予測の元に制作されるため、実際に必要な機能が発生したときに予測で作ったものが障害になる可能性がある 実際に必要になるまでは新しい機能を定義したりテストする事は難しい。そして、そのようなものは本当に必要になったときに動作しないことが多い コード
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
