# refactoring リファクタリング

* 修正ではない 拡張でもない

* プログラムを外部視点で動作を変えず、内部構造を整理すること

* まだまだ発展途上な技術分野(ソフトウェアは全て発展途上とも言える)
t C
# 論よりコード

* 一度正常に動いたと思えるソースコードは二度と触るな->腫れ物を扱う

* これはバグが出ないようにする先人の知恵

* 数年単位のプロジェクトでは まぁ、なるほどと

* 日々変わる要件や技術が通常となっている状況じゃ意味のない言葉になりつつあるかも
# Code smell

* 臭うよ!危険なニオイがソースコードからするよ!
# 臭いのもとは?

* 重複したコード

* 長すぎるメソッド

* 巨大なクラス

* 他クラスのメソッドを過度に用いる

* 不適切な依存関係

* サブクラスのくせにスーパークラスを無視してないか?

* それ、オーバライドではなく、置き換えでは?

* 同一あるいは同様のメソッドが複数箇所に存在しないか?

* 簡潔な設計で十分なところに、過剰に複雑なデザインパターン

* 単純にわけわからん 1+2*3 と (1+2)*3 と 1+(2*3)
# How to の一例

* 細分化(Class / method)

長いコードはそれだけで大変 / でかいクラスは必ずいびつな形をしている

* 関連の一方向化

その参照は必要なのだろうか?オブジェクトは参照されている間生き続ける

* 条件分岐のポリモーフィズム化

継承や委譲で条件となる箇所を別に切り分ける

* 継承(is-a)を委譲(has-a/use-a)へ

可能であればやる

分岐と条件を切り分ける

静的型言語としての継承は結構制約が多い

* 疎結合と密結合

依存関係は出来る限り最小にしよう

(javaとかなら、非ジェネリックなimportの数とか、その延長の変数とか指標の一つになる)

* バリューオブジェクト

頻繁に見られる同じ引数パターンをまとめて名前をつけてあげる

* 名称変更

名前がイケてないの、変えようよ
t
# そもそも論

* リファクタリングは目に見えて作業進 しない、恐らくゼロ

* 塩漬け要件が出来ない->プログラム修正->スパゲッティでわかんないよ!

* コスト高くなるよ->わかりやすくしよう->リファクタリングしまーす

* リファクタリングにかけるコストは???

* お客さま曰く、「最初からちゃんとしてればそのコストいらないよね」(要件替えるくせに最初からって…要オトナの対応)

* 作業じゃないんだよ、空気なんだよ、そう思うのがプロだし、カイゼンってそういうことだよね
# test! test!! test!!!

* est! est!! est!!! はイタリア白ワインの銘柄の一つです

* 動作が変わっていない保証はテスト結果しかない

* 大胆な計画と慎重な行動

* とにかく少しずつユニットテスト前提で
i
# 不遇の時代

* 昔はそんなことをする必要があるコードを書くこと自体が悪

* 漸く冷遇されなくなった手法の一つ(必要性は結構感じられていた)

* ただ、動的実行で型がなく、ライブラリのコードを読むのが当たり前の世界だったSmalltalkとかだと、リファクタはふつうのコトだった(リファクタリングがプログラミング作業の半分みたいな感覚)

* 設計書をテスト駆動型TDDをベースとする方法で誤魔化すことでXP化が加速されてイイカンジかも

* 僕はビヘイビア駆動型BDD(テストコードのクラス名とか変数名とかに要求仕様を書くような意識=自然言語に近づく(英語だけど))が好きです
gm g
# 手法と手段

* 手段は色いろある(主な項目は前述のとおり、どこぞのアカデミックな偉い人は70通りも考えてくれてるから、遠慮なくネットで検索してそれを使いましょう、車輪の再発明はいらないです)

* 対象の絞りこみ方法は決まった、やり方もなんとなくあるって話だ、んじゃ、やれるか?
w C
w C
w C
# 予防線を張ります

* ここからは僕の想い(手法)の話です、異論は認めますが、まずは聞いてくれ

* 異論は認めるが、今日議論をふっかけるのはやめてくれ

* できれば議論は来世で…

* 因みに結論はありません、聞いて欲しいだけです
# バックグラウンド

* 例えば、ソースコードを見るとメンバーの誰が書いたのか、60%位の確率で判るんじゃないか?

* 40%はスケジュールに追われているとかイラッとしてるとか( `д´) ケッ!とかおもってるとか

* 60%?ソレは何故?担当者のバックグラウンドが出ている

* 毛穴からにじみ出る汁みたいに

* それは、ボキャブラリ、嗜好、受けた教育、その他モロモロ
o
o
# 静的構造と動的構造

* 宗教と静的構造、動的構造の関係って見方がある

* 宗教論をするつもりではなく、構造の話です

* そもそもツリー構造はどちらかと言うと唯一神キリスト教、ピラミッド構造

* 神オブジェクト(なんでも持ってる)の実在は結構ある

* アリストテレスのイデア論って知ってますか?

* 八百万の神々とか和をもって尊しとなすとか日本文化チック

八百万の神々を一つにして神オブジェクトをやるととんでもないことになるw

* 仏教曼荼羅も仏様いっぱいいる

* どうも、西洋と東洋の差があるみたい(継承と委譲)

* 最近の作業を振り返って、クラスの構造関係とか動作時のオブジェクト関係とかどう?
rn la
# 表現と比喩

* 日本語って、表現方法が凄まじい

* 例えば、雨

** 霧雨、小糠(こぬか)雨、小雨: 雨の水滴の形状を指した言葉

** 時雨(ふったりやんだり)、にわか雨(すぐにやむ): 雨の状況(降り方)を指した言葉

** 春雨、五月雨、梅雨、秋雨、夕立: 時間や季節を含み持つことになった言葉

* で、例えば、五月雨

** 梅雨時期の雨のこと

** バラバラと断続的なこと

** 日本海軍駆逐艦、艦これの艦名なのは勝手に議論してください
# レトリック

* 直喩: 鬼のように強い(鬼の知り合い居ないけど、何となく分かる)(鬼みたいな人の知り合いは結構いる)

類似性を持つ何かに例える

* 隠喩: (ムスカ)見ろ!人がゴミのようだ(生ごみとか言っているのではなく、ゴミクズのように大量で捨てられているような感じ(たしか、実際は落ちていた))

メタファーというのはコレのこと、直喩を更に簡潔にした感じ

* 換喩: 赤ずきんちゃん(少女が赤い頭巾を被っているのであり、赤い頭巾に似ているのではない、因みに白雪姫(雪のように白い肌のお姫様)は隠喩

* 提喩: セロテープ(あるものを更に一般的な言い方で言い換える)

* 法政大学 理工学部 創生科学科 教授 玉井哲雄 氏

* 京都産業大学 コンピュータ理工学部 コンピュータサイエンス学科 教授 青木淳 氏
la
H
# 比喩とオブジェクト指向

* オブジェクト指向に言い換えると、

** 換喩=集約=has-a(part-of)=抽象データ型

** 提喩=一般化=is-a(kind-of)=インヘリタンス

** 隠喩=ポリモーフィズム
H o
c
# オブジェクト指向的に心がけるコトとか

* カプセル化(定義は色々あるけど、データ隠 で)

* 美味しいハンバーグのお店

* 年季の入ったコックさんの技

* 実はレトルトパックだったりして

* 美味しいハンバーグという要求には応えている

* きれいなおねーさんの居るお店

* 実は旦那子持ち->問題ない、嘘ではない

* 実は男->おねーさんの定義をもう一度

* 美形が居る->男女別は持ち出していないのでセーフだが、コンテキストが問題

* コンテキストって?

* まぁ、文脈。ラーメン食った後に、A店も美味しいから今度行こうと言われたA店がハンバーグ屋だったら、それは違うだろ
o
c
# コンテキスト的に心がけるコトとか

* 実家の近所では下の名前で通る、苗字を名乗る必要はほぼない

* 実家圏内(2km?)から出ると通用しない

* 更には社名とか肩書とか

* 更には国とか

* ある領域範囲では命名は短くて問題ない

* 本当に?

* publicじゃなければ…

* privateメソッドの中のローカル変数なんてなんでもいいじゃん

* でも、そのメソッド、1000近いステップ数

* privateメソッドのローカル変数の定義に追加するものが出てくる

* 適切な名称を付けるべき vs 長いのがそもそも変だろ
f! ds
e:
# 雑感:必要だと思っているコト

* 読書: 技術書でも新聞でも小説でもマンガでも何でもいい、とにかくボキャブラリを増やせ

* 映画とかでも良い、表現力も増やそう

* 技術原書を読んだことありますか?開発方法論の文書内でシェイクスピアで例えられて理解できますか?

* 英語だからわからないと当たり前のように言うな、俺だってわかんないから辞書引いてるよ

* 因みに、スペルミスは恥ずかしいから注意せよ

* ほんとうの意味での多国籍チームの開発を早く経験しよう、メンバー間の考え方の格差に呆然

* できれば、数学の知識があると面白くなると思う、論理的な考察を強いられるから

* たまに案件では必要なことも(金融とか)、実際、僕はとある案件でMD5ハッシュ暗号化処理をjavaで書いたときに、java.lang.mathとか使いました(たしか、三角関数?、sinだったかと)

* ハウツー本には頼るな、答えのみならず、答えの探し方も必要なコトです

* マネジメントには「ハイ」と返事しろ。反論しても自分の時間が削られるだけだ

* 自己主張と反発は違う

* 説明はするべきだが、アホな質問には「ググれ」で十分。無知は罪。つか、相手、この業界の人だよね?

* 考え方の反転: 人間原理宇宙論って知ってますか?

* 衣食住足りて礼節を知る、あと、睡眠もかな

* 所 、この世は酒と金

Refactoring

  • 1.
    # refactoring リファクタリング *修正ではない 拡張でもない * プログラムを外部視点で動作を変えず、内部構造を整理すること * まだまだ発展途上な技術分野(ソフトウェアは全て発展途上とも言える)
  • 2.
    t C # 論よりコード *一度正常に動いたと思えるソースコードは二度と触るな->腫れ物を扱う * これはバグが出ないようにする先人の知恵 * 数年単位のプロジェクトでは まぁ、なるほどと * 日々変わる要件や技術が通常となっている状況じゃ意味のない言葉になりつつあるかも
  • 3.
    # Code smell *臭うよ!危険なニオイがソースコードからするよ!
  • 4.
    # 臭いのもとは? * 重複したコード *長すぎるメソッド * 巨大なクラス * 他クラスのメソッドを過度に用いる * 不適切な依存関係 * サブクラスのくせにスーパークラスを無視してないか? * それ、オーバライドではなく、置き換えでは? * 同一あるいは同様のメソッドが複数箇所に存在しないか? * 簡潔な設計で十分なところに、過剰に複雑なデザインパターン * 単純にわけわからん 1+2*3 と (1+2)*3 と 1+(2*3)
  • 5.
    # How toの一例 * 細分化(Class / method) 長いコードはそれだけで大変 / でかいクラスは必ずいびつな形をしている * 関連の一方向化 その参照は必要なのだろうか?オブジェクトは参照されている間生き続ける * 条件分岐のポリモーフィズム化 継承や委譲で条件となる箇所を別に切り分ける * 継承(is-a)を委譲(has-a/use-a)へ 可能であればやる 分岐と条件を切り分ける 静的型言語としての継承は結構制約が多い * 疎結合と密結合 依存関係は出来る限り最小にしよう (javaとかなら、非ジェネリックなimportの数とか、その延長の変数とか指標の一つになる) * バリューオブジェクト 頻繁に見られる同じ引数パターンをまとめて名前をつけてあげる * 名称変更 名前がイケてないの、変えようよ
  • 6.
    t # そもそも論 * リファクタリングは目に見えて作業進しない、恐らくゼロ * 塩漬け要件が出来ない->プログラム修正->スパゲッティでわかんないよ! * コスト高くなるよ->わかりやすくしよう->リファクタリングしまーす * リファクタリングにかけるコストは??? * お客さま曰く、「最初からちゃんとしてればそのコストいらないよね」(要件替えるくせに最初からって…要オトナの対応) * 作業じゃないんだよ、空気なんだよ、そう思うのがプロだし、カイゼンってそういうことだよね
  • 7.
    # test! test!!test!!! * est! est!! est!!! はイタリア白ワインの銘柄の一つです * 動作が変わっていない保証はテスト結果しかない * 大胆な計画と慎重な行動 * とにかく少しずつユニットテスト前提で
  • 8.
    i # 不遇の時代 * 昔はそんなことをする必要があるコードを書くこと自体が悪 *漸く冷遇されなくなった手法の一つ(必要性は結構感じられていた) * ただ、動的実行で型がなく、ライブラリのコードを読むのが当たり前の世界だったSmalltalkとかだと、リファクタはふつうのコトだった(リファクタリングがプログラミング作業の半分みたいな感覚) * 設計書をテスト駆動型TDDをベースとする方法で誤魔化すことでXP化が加速されてイイカンジかも * 僕はビヘイビア駆動型BDD(テストコードのクラス名とか変数名とかに要求仕様を書くような意識=自然言語に近づく(英語だけど))が好きです
  • 9.
    gm g # 手法と手段 *手段は色いろある(主な項目は前述のとおり、どこぞのアカデミックな偉い人は70通りも考えてくれてるから、遠慮なくネットで検索してそれを使いましょう、車輪の再発明はいらないです) * 対象の絞りこみ方法は決まった、やり方もなんとなくあるって話だ、んじゃ、やれるか?
  • 10.
    w C w C wC # 予防線を張ります * ここからは僕の想い(手法)の話です、異論は認めますが、まずは聞いてくれ * 異論は認めるが、今日議論をふっかけるのはやめてくれ * できれば議論は来世で… * 因みに結論はありません、聞いて欲しいだけです
  • 11.
    # バックグラウンド * 例えば、ソースコードを見るとメンバーの誰が書いたのか、60%位の確率で判るんじゃないか? *40%はスケジュールに追われているとかイラッとしてるとか( `д´) ケッ!とかおもってるとか * 60%?ソレは何故?担当者のバックグラウンドが出ている * 毛穴からにじみ出る汁みたいに * それは、ボキャブラリ、嗜好、受けた教育、その他モロモロ
  • 12.
    o o # 静的構造と動的構造 * 宗教と静的構造、動的構造の関係って見方がある *宗教論をするつもりではなく、構造の話です * そもそもツリー構造はどちらかと言うと唯一神キリスト教、ピラミッド構造 * 神オブジェクト(なんでも持ってる)の実在は結構ある * アリストテレスのイデア論って知ってますか? * 八百万の神々とか和をもって尊しとなすとか日本文化チック 八百万の神々を一つにして神オブジェクトをやるととんでもないことになるw * 仏教曼荼羅も仏様いっぱいいる * どうも、西洋と東洋の差があるみたい(継承と委譲) * 最近の作業を振り返って、クラスの構造関係とか動作時のオブジェクト関係とかどう?
  • 13.
    rn la # 表現と比喩 *日本語って、表現方法が凄まじい * 例えば、雨 ** 霧雨、小糠(こぬか)雨、小雨: 雨の水滴の形状を指した言葉 ** 時雨(ふったりやんだり)、にわか雨(すぐにやむ): 雨の状況(降り方)を指した言葉 ** 春雨、五月雨、梅雨、秋雨、夕立: 時間や季節を含み持つことになった言葉 * で、例えば、五月雨 ** 梅雨時期の雨のこと ** バラバラと断続的なこと ** 日本海軍駆逐艦、艦これの艦名なのは勝手に議論してください
  • 14.
    # レトリック * 直喩:鬼のように強い(鬼の知り合い居ないけど、何となく分かる)(鬼みたいな人の知り合いは結構いる) 類似性を持つ何かに例える * 隠喩: (ムスカ)見ろ!人がゴミのようだ(生ごみとか言っているのではなく、ゴミクズのように大量で捨てられているような感じ(たしか、実際は落ちていた)) メタファーというのはコレのこと、直喩を更に簡潔にした感じ * 換喩: 赤ずきんちゃん(少女が赤い頭巾を被っているのであり、赤い頭巾に似ているのではない、因みに白雪姫(雪のように白い肌のお姫様)は隠喩 * 提喩: セロテープ(あるものを更に一般的な言い方で言い換える) * 法政大学 理工学部 創生科学科 教授 玉井哲雄 氏 * 京都産業大学 コンピュータ理工学部 コンピュータサイエンス学科 教授 青木淳 氏
  • 15.
    la H # 比喩とオブジェクト指向 * オブジェクト指向に言い換えると、 **換喩=集約=has-a(part-of)=抽象データ型 ** 提喩=一般化=is-a(kind-of)=インヘリタンス ** 隠喩=ポリモーフィズム
  • 16.
    H o c # オブジェクト指向的に心がけるコトとか *カプセル化(定義は色々あるけど、データ隠 で) * 美味しいハンバーグのお店 * 年季の入ったコックさんの技 * 実はレトルトパックだったりして * 美味しいハンバーグという要求には応えている * きれいなおねーさんの居るお店 * 実は旦那子持ち->問題ない、嘘ではない * 実は男->おねーさんの定義をもう一度 * 美形が居る->男女別は持ち出していないのでセーフだが、コンテキストが問題 * コンテキストって? * まぁ、文脈。ラーメン食った後に、A店も美味しいから今度行こうと言われたA店がハンバーグ屋だったら、それは違うだろ
  • 17.
    o c # コンテキスト的に心がけるコトとか * 実家の近所では下の名前で通る、苗字を名乗る必要はほぼない *実家圏内(2km?)から出ると通用しない * 更には社名とか肩書とか * 更には国とか * ある領域範囲では命名は短くて問題ない * 本当に? * publicじゃなければ… * privateメソッドの中のローカル変数なんてなんでもいいじゃん * でも、そのメソッド、1000近いステップ数 * privateメソッドのローカル変数の定義に追加するものが出てくる * 適切な名称を付けるべき vs 長いのがそもそも変だろ
  • 18.
    f! ds e: # 雑感:必要だと思っているコト *読書: 技術書でも新聞でも小説でもマンガでも何でもいい、とにかくボキャブラリを増やせ * 映画とかでも良い、表現力も増やそう * 技術原書を読んだことありますか?開発方法論の文書内でシェイクスピアで例えられて理解できますか? * 英語だからわからないと当たり前のように言うな、俺だってわかんないから辞書引いてるよ * 因みに、スペルミスは恥ずかしいから注意せよ * ほんとうの意味での多国籍チームの開発を早く経験しよう、メンバー間の考え方の格差に呆然 * できれば、数学の知識があると面白くなると思う、論理的な考察を強いられるから * たまに案件では必要なことも(金融とか)、実際、僕はとある案件でMD5ハッシュ暗号化処理をjavaで書いたときに、java.lang.mathとか使いました(たしか、三角関数?、sinだったかと) * ハウツー本には頼るな、答えのみならず、答えの探し方も必要なコトです * マネジメントには「ハイ」と返事しろ。反論しても自分の時間が削られるだけだ * 自己主張と反発は違う * 説明はするべきだが、アホな質問には「ググれ」で十分。無知は罪。つか、相手、この業界の人だよね? * 考え方の反転: 人間原理宇宙論って知ってますか? * 衣食住足りて礼節を知る、あと、睡眠もかな * 所 、この世は酒と金