-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinsapporo20120424
irasally edited this page Apr 24, 2012
·
10 revisions
- http://atnd.org/events/27956
- 2012年04月24日 19:30-21:00
- エスプランニング開発室
- 参加者 6人
- 第13章
- このコードは何のコードだろう？
- ディーラーの勝ち負けを判定するコード
- 何がよくないだろうか？
- 名前が良くない（連番とか困る）
- 全部
- コードは読めるけど何をしたいのかがわからないよ
- どう修正するのが良いだろうか
- このあと答え合わせできるね
- 名前でわからないとここまで混乱するのか・・・
- アジャイル開発では、それを「リファクタリング」と呼んでいる
- アジャイル開発じゃなくても「リファクタリング」と呼ぶよね
- リファクタリングは"手法"？
- プラクティス、テクニックならしっくりする
- "手法"は原著でどう書かれているのだろう？ => [TODO]
- 常に何かしらの負債を抱えている
- （負債が全くないということは新しいことや・・・）は言いすぎかなー
- 常に負債がないように開発することもできるはず
- （負債が全くないということは新しいことや・・・）は言いすぎかなー
- 「負債」として認識できるかできないかというのが実は一番の問題
- 「動いているからいいじゃん」問題
- 「動いているからわざわざ手を入れなくていいじゃん」問題
- 「負債」の考え方をチーム内に浸透させられるかどうか
- 良いコードを書こうとしたら必然的にリファクタリングをすることになる
- 常に良いコードを書こうとしていたらリファクタリングになる
- アジャイル的な開発 -> 小さいものをだんだん大きくしていく -> リファクタリングをしないと大変なことになる
- 共通化などを常に考えて「コードを成長させていく」
- コードを「ナマモノ」と考えるか「完成された製品」として捉えるか
- 上の層にリファクタリングの必要性を理解してもらうにはどうすれば？
- 見積もりの時とかどうすればよいのだろう
- 実装に「ユニットテスト、プログラミング、リファクタリング」を全て含めて考えれば良いんじゃないかなー
- 項目の数字の出し方によって気持ちが変わる
- 気がついた時にさっと直せないところは辛いよね
- 機能追加の帽子とリファクタリングの帽子は絶対に意識しなければいけないよね
- リファクタリング―プログラムの体質改善テクニック（http://www.amazon.co.jp/dp/4894712288）にも書かれてある
- 「下の方のコードのほうがわかりやすい」と思わない人がいる・・・
- オブジェクト指向プログラミング云々以前の問題
- 仕様書（詳細設計書）通りの順番でコードが書かれていないとわからないという人がいた
- リファクタリングはユニットテストがあることが大前提
- 245Pにも書いてあるね
- この章の頭にも書いてくれていると良かったなあ
- ユニットテストが書かれていないソースコードは変更してはいけないという気持ちを持たないといけないよ
- テストがないソースコードを直すことはただのコーディングでありリファクタリングではない
- 堅実なテストはリファクタリングをする上で必要な前提条件です
- ここに書かれていること以外のリファクタリングの効用（リファクタリング―プログラムの体質改善テクニック より）
- バグを見つけやすい
- 早くなる
- リファクタリングのタイミング
- 新しい機能を追加する時
- バグを修正する時
- コードレビューの時
- 細かい部分は常に（<-253P の絵が示している）
- コードを書くことは、良い文章を書くことにとてもよく似ている
- 全体を捉えることができているか
- 適切な言葉を選ぶことができているか
- 人が見てわかりやすいと思えるか
- コードがわかりにくい人は文章もわかりにくい
- ソースコードレビューできちんと説明できている -> わかりやすいコードを書いている人が多い
- 良い本を紹介しあう時間（休憩時間）
- http://www.amazon.co.jp/dp/0321503627
- ふりかえり
- 見積もり
- デベロップメント
- アジャイルプラクティス
- アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス
- RSpec本
- レガシーコード改善ガイド
- パターン指向リファクタリング入門
- リファクタリングの様子を見ていこう
- 254 - 意味が見えてきた
- 名前を直すのが一番
- 状況によってはその前にインデントの修正が必要なことがあるね
- 等号不等号のリファクタリング254下
- 結構危ない、テスト必須だね
- 名前を直すのが一番
- 255 - すっきりした
- 255下ワンライナーにするかどうかは状況によりけり
- HandがgetValue()を持っている方が綺麗だよね（メソッドの移動）
- Handに役割を持たせるように切り替える
- 255上の抽出ができるようになるかどうかが最初のステップ
- 更にHandにメソッドをもたせたほうが良いのでは？と気がつける（責務がどこにあるべきか）かが次のステップ
- リファクタリングの行き届いたコードは本当に修正しやすいね
- 一番大変なのはソースコードを読むこと
- 読んで理解するまでに時間がかかる
- 自分の昔書いたコードも理解することが難しいという体験をすると大切さに気がつくね
- リファクタリングをやってもやってもコードが汚染されていく孤独な戦い
- これは結構心が折れる
- 大規模リファクタリングと日々のリファクタリングには違いがあるね
- 大規模リファクタリングがストーリーになるのはわかる気がする
- 普段からちょっとずつできることとそうではないことがあるね
- リファクタリングはお客さんの価値を生み出してはいない
- 変化に対応するために必要なことだけれど価値を直接生み出す行為ではないと言うことは意識したほうがよいね
- リファクタリングを避ける時
- 納期が迫っている時（アジャイルサムライに書いてある）
- 変更するよりも最初から書きなおしたほうが早い時
- 明らかに動かない時など限定的に（よっぽどひどい時）
次回は5/8（火）