Readingagilesamuraiinhiroshima20151118 - agile-samurai-ja/support GitHub Wiki
アジャイルサムライ読書会 in 廣島道場 ２回目（第13回）
記録
２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。 今日はＮさん参加で、リファクタリングについて色々とお話ししました。開発している環境によって「リファクタリングなんてありえない」という環境や「暗黙的に認知されている」環境まで、とどのつまり「ハードごと納品だと無理」と「一括請負だと無理」ですよね。 私がPMAJのSkype会議（主にヒアリング）と同時進行だったために、ご迷惑おかけしたかもしれません。次回も同時進行なのですが、アジャイルサムライの方をしっかり準備して、迷惑にならないようにします。終わったら、２１時近く、外ではえびす講で賑わっていました。「お土産を買って帰ります。」というＮさん流石です。家庭を大事にすることはチームを大事にする精神にもつながります、私の同じくらいの時だったら、「よーし一杯飲むか」って感じだったと思います（反省）。 次回は、１2月02日にしたいと思います。
第5部 アジャイルなプログラミング 233
第13章 リファクタリング：技術的負債の返済 247
13.1 どうしてこうなった......................... 247
プロジェクトに変化はつきものです、仕様に変化もつきものです。ドウシテコウナッタと嘆くよりも、全力で顧客と向き合い精査してやるべきことをやるしかないのですよ。あ、全力でプログラムソースと向き合うが正しいかもw
13.2 技術的負債.......................... 249
図で技術的負債が常に増えている。コードを書けば、自然と負債が発生するということか。 負債をゼロにするっということはコードを書く限りできないことだと感じた。 「技術的負債はコードだけではない。」実際のデータも負債になる気がする。 データ構造の問題かもしれないが、すでに入っているデータを考慮して対応方法を考えることがある。 データ量が増えるほど、対応がしづらくなる。 技術的負債という言葉に関して、負債というからには借金であり相手はどこに？、価値のあるプログラムを提供して対価をいただく、そこに隠れた不純物が混じっている、ほっておけばだんだんとそれが大きくなる（負債に利息が付く）ような感じである。
13.3 リファクタリングで技術的負債を返済する.......................... 251
簡単と言われているけど、名前の変更リファクタリングも難しいと思う。 こっちもあっちも変えたくなってくる。 コード例は、このような会に参加する人は下が好きな人が多いと思うが、実際の仕事では、上を好む人もたくさんいると思う。それもリファクタリングの難しさの気がする。 リファクタリングで何をするかというと「保守性を上げる」ことに他ならない、可読性及び重複記述の排除など一定の共通価値観によるものは「当然やるべきもの」なのだが、過去のマイナス資産に手を入れるというのは、楽しくないし怖いのでやりたくない、責任も掛かってくるので中途半端にはできないという気持ちもあるし
もっと学ぶには ............................... 258
読んでいないが、マーチンファウラーのリファクタリングは良書らしい、安全にリファクタリングする技術が記載されているとのこと。
マスター先生と熱心な弟子 ............................... 259
大掛かりなリファクタリングと聞いて、先日参加したルビーワールドカンファレンスのまつもとさんの「セカンドシステムシンドローム」を思い出した、いつでも技術者は「作り直したくなる」ものだ。
次回予告 ............................... 259
テスト駆動開発
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。