Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

パンフ記事
「初めてのリファクタリング!」
の裏側 #phperkaigi

パンフ記事
「初めてのリファクタリング!」
の裏側 #phperkaigi

※ WIPです。内容は唐突に変更されます

PHPerKaigi 2024の「パンフ記事」として寄稿した、
「初めてのリファクタリング! 〜今あるコードを読みやすく書き直してみよう!〜」の制作にあたっての裏側です。

作りながら、「やってみて面白かったこと」「こういう課題が実はあると思わない?(を共有出来たら楽しそう)」と感じたことが多かったので、記してみようと思いました。

https://fortee.jp/phperkaigi-2024/proposal/f3f85d61-28bd-40b9-8d8c-ee8f7f8cf785

hideki kinjyo

March 10, 2024
Tweet

Resources

題材としたコード

https://github.com/o0h/iyaaaaa-na-code-example/tree/v1.0.0/Obento

AIに書かせた「要リファクタ」なコードです。

More Decks by hideki kinjyo

Other Decks in Programming

Transcript

  1. どしたん? • 技術記事の執筆、やってみたいな〜〜!って気がしていた • 文章を書くのは好き。苦じゃない • もっと色々なことができたら、おもしろいだろうな〜〜って気がする • 音声、動画、イベント、執筆、etc・・ •

    何となく「採択されなかったネタはそのまま出さない」縛りをして 月刊PHPカンファレンスを楽しんでいるフシがあり、 • ・・・とはいえ、そのままお蔵入りはもったいないよな〜〜っていうのも • PHPerKaigi様サイコー、めっちゃ良いチャンスじゃん!!
  2. どしたん? • リファクタの話、多いけど「まだ必要じゃね?」って気がしていた • 「直したい課題」ありきで書かれたコードを綺麗に直す話 • 抽象的なレイヤーにしっかりアプローチをする話 • ↑これらだと、 「読んでみた!明日から自分もやってみよう!!」ってなれる・・?

    • 「設計やきれいなコードに興味があって、勉強している!!」 AND 「リファクタリングはした事はないです…」と話す人(若手)とあった • 自分からすると、そこの断絶は想像していなかったので、ちょっと驚き
  3. どしたん? • 「リファクタリング(Fowler)とテスト駆動開発(Beck)を読め」で 動き出せない人に向けての何かが要りそう • 本当に「初学者向け」になると、 説明をシンプルにすべく「解くために用意されたコード」での一問一答が多い • そのアプローチは正しい •

    が、「基礎」で止まって「応用の仕方」に目を向けさせる刺激が足りないかも • 「生臭いコード」で「完璧じゃないけどやる」が 出来ないといけないのでは • 実際に面するのは、正解がない(中でもどうにかしないといけない)世界なので
  4. 感じていたこと、課題感 • 「きれいなコードベースを作る」という話の一方で、 「問題を定義する」「ドメインモデルと向き合う」の話にしたくない • 正直、「どこにどういう風に手をいれるべきか?」という話は 「上の世界、抽象概念」から扱ったほうがやりやすい • やりたいのは「ハードルを下げること」なので、 •

    複雑な話に風呂敷を広げたり、トピックを増やしたくない • 小さくテクニックや視点を身に着けていけば、次に繋がる (まだ進みすぎなくて良い) • 「リデザイン」に対して表面的な書き換え、 本来の意味の「リファクタリング」をまずは体験できるようにしたい
  5. リアルな奴らに何が起きているか? • リアル現場でおきていること • 「最初から悪いコードを書こうとしている人はいない」 • 「昔のコード辛い」 • 逆に言えば •

    「誰でも目の前の課題にベストを尽くしている」(それでも上手く行かない) • 「歴史の重力が掛かると歪さが生まれる」
  6. 「わざとやる」から「わざとらしい」になる • 「キャリア10年の人の手抜き」と「始めたての人のコード」には どうしても違いが出てしまう • 知識やアンチパターンの体感を持っているので、「悪い例」は書ける • が、どうしても「本物」ではない。フィクションっぽさが拭えなそう • ChatGPTにやらせよう!

    • 自分でコードを書かない、そうすれば自分の経験値の影響をゼロにできる • 「どうやってコードを進化させるか」を意識しない。 「どうやってプロダクトを進化させるか」を考える • それをAIさんに伝えて、ネタを出してもらう • (このアプローチに気付くまでに、「自作FWとアプリコード書いてみたけどやっぱりな んか違う」
  7. 他人にコードを書かせる • ChatGPTにやらせよう! • 自分でコードを書かない、そうすれば自分の経験値の影響をゼロにできる • 「どうやってコードを進化させるか」を意識しない。 「どうやってプロダクトを進化させるか」を考える • それをAIさんに伝えて、ネタを出してもらう

    • 試行錯誤の末に気づいたこのアプローチで、完成まで進められた • ここに至るまでに、 「自作FWとアプリ書いてみたけどやっぱりなんか違う」→全破棄、とかを経た • 典型的な悪いコード、 やっぱり「真面目にやってる人が本当にこんな事を書く?」という雰囲気が出る
  8. 素材が出てきた、どう調理するか? • 「改修後」の姿を考える: 使えるネタかの評価 • そもそも「現実的に綺麗にならん」だったら使えない • まずは直感的にやる • 「その改修のやり方は、使えそうか?」を考える:

    ステップの評価 • 書き換えのテクニックについての吟味 • その後に「その問題は、説明できるか?」を考える • (今回の想定読者レベルに合わせて、かつ限りある紙面上で) 説明できるか?の吟味 • 縛りプレイめいたもの: 業務でノリファクタとの違い • ベイビーステップで手習いできるか? • リファクタよりも大きい問題(ドメインモデリングなど)になっていないか?