読者です 読者をやめる 読者になる 読者になる

めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

アジャイルプラクティス

読むきっかけ

名前だけ知っていながら、読んだことのないまま。 そうしたら、BookOFFで見つけまして、ひょひょいと買いました。

読んでみて

アジャイルサムライを読んで以来アジャイル開発についての本を読んでみたりしています。 開発方法は、いろいろとあり、アジャイル開発も、たくさんある開発方法の一つです。開発方法の説明や、考え方だけを聞いても、実際には組織の壁だったり、周りに理解者がいなかったり…色いろあると思うのです。そんなアジャイル開発を実際に行ううえでのプラクティスがまとめられています。

読書メモ

習慣

  • 時がきたら、習慣を捨てる
  • 新しきを学び、古きを捨てる
  • わかるまで質問する
    • なぜ?を問う

デプロイ

  • 早いうちにデプロイを自動化する
    • ちなみに某社では、「まく」。社内用語。

用語集

  • プロジェクト用語集を用意する
    • 用語集が欲しい時はある
    • 業界用語や、社内用語。困るのが、微妙に、意味が違うんじゃない?と思うとき

インクリメンタル

コスト

  • 建設プロジェクトのコストのやく30%は、ミスによるやり直し

テスト

  • コードよりも先にテストを書く
  • バランスが大事

フィードバック

  • ユーザーからのフィードバックが必要

明確

  • PIEの原則
  • 意図を明確に表現するコードを書く
  • コードで伝える
    • コメントに逃げない。
    • 変数名など、名前重要
      • CSSとかでも、class="pk"とか、あまりにも省略されると「?」と思い、理解に時間が...
      • 略語は危険
    • Rubyは、コードが雄弁
  • メソッドのコメント
    • 目的、メソッドの存在理由
    • 必要条件
    • 結果
    • 例外
  • コメントを短くするのに時間をとる

シンプルな設計

  • 「求めるな、命じよ」
  • Small talk では、メソッドの呼び出しではなく、メッセージの送信と呼ぶ

開発メモ

  • 問題が起きた日時
  • 問題の簡単な説明
  • 解決策の詳細な説明
  • 詳細情報や、関連記事
  • 解決の糸口になりそうなコードや、設定

コードの共有

  • バージョン管理をしないより、悪いことは何か?バージョン管理システムを間違って運用すること
    • タスクが完了したらチェックイン
    • コードを週単位、月単位でチェックインするのは好ましくない
      • だらしないのない習慣
    • 正しいことに取り組まず易しに流れている
    • 単純な技術的問題

この点に関しては、「単純な技術的問題」といわれても仕方ない

おすすめ

二人以上で開発することになれば、色々な開発手法が必要になると思います。 アジャイル開発が全てではないけれど、アジャイル開発の理解は、きちんとすべき。 アジャイル開発を実践すると、出てくる悪魔のささやきが、書かれており、それに対して、天使が答えているので、安心することが出来ます。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−