Skip to content

Readingagilesamuraiinsapporo20120424

Jump to bottom Edit New page
irasally edited this page Apr 25, 2012 · 10 revisions

第19回読書会

第13章 リファクタリング：技術的負債の返済

13.1 どうしてこうなった

  • このコードは何のコードだろう？
    • ディーラーとプレイヤーの勝ち負けを判定するコードみたいだね
  • このコード、どこがよくないだろうか？
    • まず名前が良くない（連番とか困る）
    • ほとんど全部
    • コードは読めるけど何をしたいのかがわからないよ
  • どう修正するのが良いだろうか
    • 色々意見を出す -> このあと答え合わせできるね
  • 名前でわからないとここまで混乱するのかと実感・・・

13.2 技術的負債

  • アジャイル開発では、それを「リファクタリング」と呼んでいる
    • アジャイル開発じゃなくても「リファクタリング」と呼ぶよね
  • リファクタリングは"手法"？
    • プラクティス、テクニックならしっくりする
    • "手法"は原著でどう書かれているのだろう？
      • 250Pの「ソフトウェアの整合性を保ちながら、設計を少しずつ改善していける手法」は "We need a way of incrementallty...." となっているので "a way"と書かれているようです
      • 13.3 の冒頭は "Refactoring is the practice of continuously making small, ...." なのでリファクタリングのことはプラクティスである、と言っていますね
  • 常に何かしらの負債を抱えている
    • （負債が全くないということは新しいことや、これまでとは違うことに取り組もうとしていないってことだ）は言いすぎかなー
      • 常に負債がないように、負債を抱えないように開発することもできるはずじゃないかな
  • 「負債」として認識できるかできないかというのが実は一番の問題だよね
    • 「動いているからいいじゃん」問題
    • 「動いているからわざわざ手を入れなくていいじゃん」問題
    • 「動いているものに手を加えてはいけない」問題
  • 「負債」の考え方をチーム内に浸透させられるかどうかが重要になってくるね
  • 良いコードを書こうとしたら必然的にリファクタリングをすることになるよね
    • 常に良いコードを書こうとしていたら結果的にリファクタリングしていた、ということはよくある
  • アジャイル的な開発 -> 小さいものをだんだん大きくしていく -> リファクタリングをしないと大変なことになる
    • 共通化などをそのときそのときで常に考えて改善していく、はじめは小さく作る
    • 「コードを成長させていく」というキーワードをよく聞くね
  • コードを「ナマモノ」と考えるか「完成された製品」として捉えるかの違いがあるのかもしれないなあ
  • 会社の上の層にリファクタリングの必要性を理解してもらうにはどうすればいいだろうか？
    • 特に見積もりの時とかどうすればよいのだろう
    • 実装に「ユニットテスト、プログラミング、リファクタリング」を全て含めて考えれば良いんじゃないかなー
      • 項目の数字の見せ方によって印象が変わるところはある
  • 気がついた時にさっと直せない文化や環境は辛いよね

13.3 リファクタリングで技術的負債を返済する

  • 機能追加の帽子とリファクタリングの帽子は絶対に意識しなければいけないよね
  • 251Pの下段のコードのほうがわかりやすい、と思わない人がいる・・・
    • オブジェクト指向プログラミング云々以前の問題
    • 仕様書（詳細設計書）通りの順番でコードが書かれていないとわからないという人がいた
  • リファクタリングはユニットテストがあることが大前提なのは忘れてはいけないね
    • 245Pにも書いてあるね
    • この章の頭にも書いてくれていると良かったなあ
  • ユニットテストが書かれていないソースコードは変更してはいけないという気持ちを持たないといけないよ
    • テストがないソースコードを直すことはただのコーディングであり、リファクタリングではない
    • それが良い悪いは別としてリファクタリングをするのに大切なことは忘れてはいけないね
  • コードを書くことは、良い文章を書くことにとてもよく似ている、本当にそうだなーと実感することが多いです
    • 全体を捉えることができているか
    • 適切な言葉を選ぶことができているか
    • 人が見てわかりやすいと思えるか
    • コードがわかりにくい人は文章もわかりにくい
    • ソースコードレビューできちんと説明できている -> わかりやすいコードを書いている人が多い

リファクタリング―プログラムの体質改善テクニック の大事な部分をみんなで眺める

  • "堅実なテストはリファクタリングをする上で必要な前提条件です"
  • アジャイルサムライに書かれていること以外のリファクタリングの効用
    • バグを見つけやすい
    • 開発スピードが早くなる
  • リファクタリングのタイミング
    • 新しい機能を追加する時
    • バグを修正する時
    • コードレビューの時
    • 細かい部分は常に（<- アジャイルサムライ 253P の絵が示していることだね）

良い本を紹介しあう時間（休憩時間）

リファクタリングの様子を見ていこう

  • 254P - 意味が見えてきた
    • 名前を直すのが一番変化がわかるね
    • 状況によってはこの前にインデントの修正が必要なことがあるね
    • 254P下段 等号不等号のリファクタリング
      • 結構危ない、テスト必須だね
  • 255P - かなりすっきりしたね
    • 255P下段 ワンライナーにするかどうかは状況によりけりだね
      • ワンライナーにしない方がコードとしてわかりやすいこともあるよね
    • HandがgetValue()を持っている方が綺麗だよね（メソッドの移動）
      • Handに役割を持たせるように切り替える
    • 255P 上のメソッド抽出ができるようになるかどうかが最初のステップ
    • 更にHandにメソッドをもたせたほうが良い（メソッド移動）のでは？と気がつける（責務がどこにあるべきか）かが次のステップになるかな

256P からの話

  • リファクタリングの行き届いたコードは本当に修正しやすいね
    • バグ修正時やメンテナンス時に一番大変なのは（他人や昔の自分が書いた）ソースコードを読むこと
    • 読んで理解するまでに時間がかかる
    • 自分の昔書いたコードも理解することが難しいという体験をすると大切さに気がつくね
  • リファクタリングをやってもやってもコードが汚染されていく孤独な戦いをしたことがある
    • これは結構心が折れるね・・・
  • 大規模リファクタリングと日々のリファクタリングには違いがあるね
    • 大規模リファクタリングがストーリーになるのはわかる気がする
    • 普段からちょっとずつできることとそうではないことがあるね
  • リファクタリングはお客さんの価値を生み出してはいない
    • 変化に対応するために必要なことだけれど価値を直接生み出す行為ではないと言うことは意識したほうがよいね

マスターセンセイと熱心な弟子

  • リファクタリングを避ける時（リファクタリング―プログラムの体質改善テクニック より）
    • 納期が迫っている時（アジャイルサムライにも書いてある）
    • 変更するよりも最初から書きなおしたほうが早い時
      • 明らかに動かない時など限定的に（よっぽどひどい時）

次回は5/8（火）に19:30- 開催します！

Add a custom footer
Add a custom sidebar
Clone this wiki locally