リファクタリング 目的・パターン・思考 / reprotech

Transcript

1. リファクタリング 目的・パターン・思考 Repro inc. @joker1007
2. はじめに この話におけるリファクタリングの定義について ユーザーの体験を変えずにコードベースを改善すること として話をします。
3. 長く続いたソフトウェアは複雑化する 特に一度顧客が付くと簡単に止められなくなる 機能や動きを維持しつつ開発しなければならない 複雑さも相俟ってどんどん開発が遅くなる
4. 開発速度が遅くなる要因 ある機能に影響するコード量が多く理解しきれない 自信をもって変更できない テスト範囲が膨大になり時間がかかる 機能同士が密結合している ある機能を改修する時に芋蔓式に修正箇所が増大する
5. リファクタリングが目指すもの 読み易さの向上 疎結合化 不要なコード( 複雑さ) の削除 これらを達成することで開発速度を回復させ、キャッチアップ速 度の向上やバグの低減を目指す。
6. 危険シグナル 読み辛くて訳が分からん なんでこのメソッドがここにあるんだ？ 他のオブジェクトのメソッド呼び過ぎ このメタプロ必要か？ やりたい事に比してこんな複雑な訳がない 作業見積りから乖離があり過ぎ なんかイラつく ( 最後は直感)
7. いつやるのか イラついた時 すぐ終わりそうなら もしくは我慢ならなくなったら フィーチャ開発時に作業見積りに混ぜる 締切がシビアだと厳しい 見積り時にヤバそうな箇所を知っておく必要がある まとめて注力する期間を用意 経営判断が必要 でかくて明確な目的とマッチする 破綻寸前 時間の説得はしやすいが、ほぼ手遅れ 息を吸う様に日常に入ってるのが理想。
8. リファクタリング手法 ここからはリファクタリングとして、普段どういうことをやって いるかを紹介していきます。
9. メソッド分割 一つの長大なメソッドを段落ごとに名前を付けて別メソッドに抽 出する 効果: 読み易さの向上 モックポイントの挿入 ただし、本質的な複雑さには変化が無い。 処理の粒度を揃えることが重要。リーダブルコードを読むべし。
10. 完全コンストラクタ 不要なパラメータ渡しの無駄を避けて、オブジェクト生成時に用 意できるものを全て揃える。 効果: オブジェクトを不変にしやすい 一度作ったら呼び出し元がオブジェクトの細かい挙動を知ら なくて良くなる シンプルなことだが、既存のコードに乗って書いてると気付かな い事もしばしば。 次の「責任範囲の適正化」と連携しやすい。
11. 責任範囲の適正化 デメテルの法則や、尋ねるな命じろ、の原則に反するコードを適 切な場所に配置しなおす。 大体のケースでは、呼び出し元から呼び出し先にロジックを移動 することになる。 効果: 不要なパブリックメソッドの削減 テスタビリティ向上 メソッドチェインが減って、あるオブジェクトが元々知っている 情報だけで処理が進む様になる。 トランザクション管理と実際の処理の境界を意識すると見通し良 くなる場合がある。
12. クラス分割 責任が多過ぎるクラスをサブクラスに分割する。 オブジェクトの生成が複雑過ぎるなら専用のクラスを用意するな ど。 効果: 名付けができる テスタビリティの向上 機能追加の際の影響範囲の限定 Ruby にはパッケージスコープの仕組みが無いので、作ったサブク ラスが他の箇所から使われない様にコメントに書く か、 p r i v a t e _ c o n s t a n t にする等の注意をすること。
13. パラメータオブジェクト 検索条件等、パラメータが大量かつデフォルト値があったり無か ったりする場合に、パラメータをハンドリングするStruct を用意す る。 効果: メインロジックから瑣末な値の調整を分離できる デフォルト値の扱いだけを簡単にテストできる
14. ストラテジーパターン/ ステートオブジェ クト オブジェクトのタイプや状態によって、処理内容が変わる場合に 処理を専用のオブジェクトに移譲する。 効果: 状況に応じて変化する処理の影響範囲が明確になる Cyclomatic complexity が減少する Ruby なら動的ディスパッチと規約で同様のことができるが、ちゃ んとクラスを作った方が呼び出しが明確になるし安全になる。
15. gem 化 汎用化できそうな処理をgem として分離する。社内でのredis の扱 い方とか、認証パターンとか、AWS のAPI クライアントラッパーな ど。 効果: アプリケーション本体と独自に変更可能 テスト境界が自明になるので、網羅的なテストが書き易い OSS 化のチャンス 汎用化の分設計コストがかかる。単機能のgem にしておかないと 逆に大変になる可能性がある。
16. ミドルウェアに頼る fluentd 等のミドルウェアとクライアントライブラリやラッパーラ イブラリを組み合わせて機能を代替する。 効果: gem 化と同様に責任を外部システムに移せる パフォーマンス向上に繋がる メンテ対象が別途増える。運用コストとのバランスを取る必要が ある。
17. DB スキーマ修正 DB の制約やデータの持ち方を修正することで、余計なvalidation や データの引き直しを削減する。 効果: データ整合性が保証され、変更に対して安全になる パフォーマンス向上 ActiveRecord の表現力向上 データが増えてくるとマイグレーションが死ぬ程大変になる。 しかし元が狂ってる場合、歪みがコード側にあることが多いの で、どこかで着手する必要がある。
18. 仕様変更 ユーザの体験を損ねない範囲で制約を緩和する様に仕様変更し、 コードを簡易化する。 結果整合性で十分な場合に厳密なフロー制御を止めて処理を独立 させる等。 効果: 根本から複雑さに対処できる パフォーマンス向上に繋がることも多い 開発チームだけでは話が終わらない。 話の早いProduct Manager が居ると楽。 提案するにも、ドメイン知識とユーザーに与えている価値の本質 を知っておく必要がある。 しかし、効果はかなり大きい。
19. 機能削除 価値の低い機能をそもそも廃止する。 効果: コード群を完全に消せる 最強 とにかく話を通すのが大変。営業方法や経営判断に影響する場合 もある。 しかし数ヶ月分の工数に影響する場合もある。
20. 実例 ( 会場限定)
21. リファクタリングに必要な思考 コードの良し悪しについての指針を持つ 何が無くせれば、何ができるかを考える 既存のコードを信用するな 全てのコードはもっと上手く書ける 仕様は絶対ではない
22. 非常に大事なことは 顧客に提供している価値が何なのかを知 ること 既存の機能が本当に必要なのかを常に考 えること より良い価値の提供のためには引き算も 必要
23. まとめ 凝集度や責任範囲等コードの良し悪しにはちゃんと指針がある。 そして、改善内容にちゃんと説明を付けられないと駄目。 プログラミングだけでなくドメイン知識に無頓着では本質的な改 善提案ができない。 仕様もコードも常に疑いを持って改善の余地を探しながら仕事し ていきましょう。