アジャイルサムライ読書会 in 廣島道場（第十二回）

記録

---

今回はサッカー代表戦の試合と時間帯も重なり、サムライつながりとはいえ、参加者が少ない状態での開催でした。タリーズさんごめんなさい、５名になっていなかったのに３階を使用してしまいました。次回は５名越えると思いますので・・・。で、前段の話は私のＰＭシンポジューム参加の件、その中でソニックガーデンの倉貫義人さんの講演を聴いて、サインを貰ったことなどを共有しました。「誰ですか？」という人にはちゃんと説明しましたよｗ。その中のビジネスモデルについて、一人のプログラマが顧問としてお客様につくと言うと「それはしんどいなあ」「一人では見えなくなることもあるしなあ」との意見がありました、確かにそのとうりですが、何か別の方法があるのでしょう。それは、いずれまた

• 帰り道、ひむひむさんが今週末の勉強会で２連続で講演するとこのと、頑張ってください！（大阪出張で参加出来ませんゴメンm(__)m）

---

• ふりかえり（約10分）
• Reading Time（約xx分）

13 リファクタリング:技術的負債の返済 p247

• 買った時が一番価値が高くて、だんだんと下っていく（経済学の現在価値NPV）

13.1 どうしてこうなった p247

• コピペして同じロジックが冗長的になった場合、元に戻すのは検証が難しい
• コピペコードはそれはそれで壊れにくい。共有化してないため、他に影響が出ない。
• リファクタリングに対する、モチベーションって何？　かなり難しいと思う。
• ソースコードレビューを頻繁に行う文化が必要（ソニックガーデンの話）

13.2 技術的負債 p249

• 負債とはマイナス試算である、負の資産、なので捨ててしまったほうが利益が出る。
• 壊すことを恐れてはいけない、壊れたほうがバグがわかって良い。
• しかし、動いている限りは捨てることが出来ない、厄介なしろものである。
• ＨＩＰＯという設計書、ＰＡＤチャート、YACチャートなんかもあった。
• 負債は指数的に伸びていく。こわい。
• 技術的な負債は常に存在する。手に負えなくなる前に返済を。

技術的負債はコードだけじゃない p250

• データファイルやビルドファイル、設定ファイルにも技術的負債は見受けられる。
• →あるある、妙に凝ったものになって複雑になってしまう。　例）三次元テーブル
• （ドキュメントが無い場合もだが）ドキュメントにも当てはまるのではないか。
• ソース至上主義はどうなんだろう（ソースにコメント入れてドキュメントなし）
• コレクションのコレクションのコレクション

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

• リファクタリングとは、外部からみたソフトウェア全体の振る舞いを変えることなく、少しずつ継続的に設計を改善していく手順の総称だ。（名言だ）
• 少しずつと言うのが味噌、継続的に手を入れることで、影響を最小にし、かつソースとオブジェクトの非同期をなくす。

どんどんリファクタリングする----そしてそれを続ける p252

• アジャイル開発の原則
• 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。（名言）
• 不断の注意→英訳？原文を調べてみよう。
• 新機能の追加とリファクタリングを明確に分けないで開発を行うと、実際の進捗は大丈夫？
• 優先順位は新機能追加にあるのではないか（納期のことを考えると）
• 進捗が遅れたらどう言い訳するのかな
• 綺麗なコードは開発を加速させる。
• 変更しにくいのであればどこかに問題がある。
• 名前がわかりにくくないか考える。名前重要。悩みすぎるのもどうなんだろうか。

リファクタリングに汚名が着せられるとき p257

• セキュリティに関して、新しいモデルに移行するのも、リファクタリングなのか
• 汚名を着せられる場合は、進捗が進捗が進捗が進捗が進捗が
• プロジェクトの終盤では、リファクタリングは避けるべき
• →出荷前でも修正すべきところがあったら修正させるぞ、と豪語したことはある

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

• 　enumの話とか、だれか書いてください～

link

アジャイルサムライ読書会 in 廣島道場