リファクタリングの難しさ
- 直接は顧客に価値を届けない
- 何を持って完了とするのか曖昧
できること
普段からの共有
- 難しいと思っていること、躓いたポイント、解決したポイントは普段からPOに共有する
- これが多いほど、シンパシーが生まれる
- 「いろいろ大変なんだね」と思わせる
- 後から違う話をしている最中に、「そういえばこんなこともあった」というような伝え方は心証がよくない
違う物事に例える
- 例えば、机の上の整理整頓ができていないと、仕事の効率が悪い
- 同様にファイルの行数が多いだけで、効率は落ちる
- あるべきものがあるべきところにないだけで、効率は落ちる
- 色んな機能が一つのクラスにあると、効率は落ちる
- 関数の行数が多いと、読みにくく、新しく入った人の理解が遅れる
- コードを見れば、拡張する際にどこに何を置けばいいかわかるようなコードが理想
- ChatworkからSlackに移ったのは、ぶっちゃけオシャレだからでしょう？
- コードも見た目が良くないと開発する気が失せる
- 単に、今後、こういうことをする際に毎回やらなくて済む、と具体的に伝えることも必要。その上で上記のような説得をすると効果が大きいかも
他の権威を利用する
- 例えば、フレームワーク導入など、自分で調べて説得することももちろん重要だが、ネットの記事などを見せると納得してくれる場合もある
- こういうやり方があるから、私達も導入してみましょう、のような紹介の仕方
- もちろん記事を理解した上でやる
- 記事を理解した上で、さらに私達の場合は〜なので、少し修正して〜のようにやればいいかもしれない、など、理解したアピールも重要
根回し
- 少なくとも開発者同士は結託しておきましょう
完了条件を明確にする
- 難しいときもある
- 小分けにできることはあるので、一度に一箇所だけやるようにする
- やってるうちにスコープを広げたくなるけど我慢
やってみせる
- 実際にやってみせる
- POが開発に詳しくて、簡単に例示できる場合に使える
- きれいなコードに共感してもらえるかもしれない
本当に必要なのか
- 本当に意味のあるリファクタリングなのか、考える
- もしかしたら本当に無意味かも