Tweet
Tweet

Slide 1

Slide 1 text

パンフ記事 「初めてのリファクタリング！」 に挑戦してみました (無印) Hideki Kinjyo GitHub: o0h / X: @o0h_ の裏話 WIP

Slide 2

Slide 2 text

これ！

Slide 3

Slide 3 text

どしたん？ • 技術記事の執筆、やってみたいな〜〜！って気がしていた • 文章を書くのは好き。苦じゃない • もっと色々なことができたら、おもしろいだろうな〜〜って気がする • 音声、動画、イベント、執筆、etc・・ • 何となく「採択されなかったネタはそのまま出さない」縛りをして 月刊PHPカンファレンスを楽しんでいるフシがあり、 • ・・・とはいえ、そのままお蔵入りはもったいないよな〜〜っていうのも • PHPerKaigi様サイコー、めっちゃ良いチャンスじゃん！！

Slide 4

Slide 4 text

PHPカンファレンス関西2024 レギュラートーク（40分）初心者向け https://fortee.jp/phpcon-kansai2024/proposal/a7cc7148-6d7d-450d-a0c1-6f9267badc23

Slide 5

Slide 5 text

どしたん？ • リファクタの話、多いけど「まだ必要じゃね？」って気がしていた • 「直したい課題」ありきで書かれたコードを綺麗に直す話 • 抽象的なレイヤーにしっかりアプローチをする話 • ↑これらだと、 「読んでみた！明日から自分もやってみよう！！」ってなれる・・？ • 「設計やきれいなコードに興味があって、勉強している！！」 AND 「リファクタリングはした事はないです…」と話す人(若手)とあった • 自分からすると、そこの断絶は想像していなかったので、ちょっと驚き

Slide 6

Slide 6 text

どしたん？ • 「リファクタリング(Fowler)とテスト駆動開発(Beck)を読め」で 動き出せない人に向けての何かが要りそう • 本当に「初学者向け」になると、 説明をシンプルにすべく「解くために用意されたコード」での一問一答が多い • そのアプローチは正しい • が、「基礎」で止まって「応用の仕方」に目を向けさせる刺激が足りないかも • 「生臭いコード」で「完璧じゃないけどやる」が 出来ないといけないのでは • 実際に面するのは、正解がない(中でもどうにかしないといけない)世界なので

Slide 7

Slide 7 text

どしたん？ • 本当に「リファクタリングをしたことがない」人が、 どうしたら一歩を踏み出して歩いていけるんだろう・・？ • 「覚える」「知る」よりも、「体験する」みたいな話があると良いかも • (座学的に学ぶよりかは、体力を使う前提で)

Slide 8

Slide 8 text

テーマ設定中のメモ(思考過程)

Slide 9

Slide 9 text

(ちなみに)作業ボード全景はこんな感じになったよ 話の要素が全て入っているものではなく、 「よし、この方針でいける！」となるまでのワークスペースとして

Slide 10

Slide 10 text

制作上の課題

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

感じていたこと、課題感 • 「ここに引数がゲロ多い関数があるじゃろ」をやりたくない • 「さぁ、この中にお宝が埋まっているかも知れません！！」的な • 実際に現場でリファクタリングを実行に移せる・・・ という状態に移せるようになるには？

Slide 13

Slide 13 text

感じていたこと、課題感 • どんなものでも「練習」が必要 • 「リファクタリングを知っている」「コードの原則を勉強中」の人は 何を練習するべき？ • 現場的な「リファクタリングしている人のジャーニー」を考えると、 最初に「有象無象の中から問題と目が合う」が必要なはず

Slide 14

Slide 14 text

感じていたこと、課題感 • 「きれいなコードベースを作る」という話の一方で、 「問題を定義する」「ドメインモデルと向き合う」の話にしたくない • 正直、「どこにどういう風に手をいれるべきか？」という話は 「上の世界、抽象概念」から扱ったほうがやりやすい • やりたいのは「ハードルを下げること」なので、 • 複雑な話に風呂敷を広げたり、トピックを増やしたくない • 小さくテクニックや視点を身に着けていけば、次に繋がる (まだ進みすぎなくて良い) • 「リデザイン」に対して表面的な書き換え、 本来の意味の「リファクタリング」をまずは体験できるようにしたい

Slide 15

Slide 15 text

良い(悪い)コードを作りたい • 「なぜ、悪いコードが生まれるか」の本質を捉えたい • ただの「知識不足」「技術不足」はもちろんとして • これは「原理原則を知る」「セオリーに触れる」という学習で補う • (・・・で、それはやっている人でも「踏み出せていない」が課題じゃない？ • スパゲティが生まれる力学を掴んで、 それをシミュレーションできたら天然風の養殖ができないかな・・？

Slide 16

Slide 16 text

目指せ！脱・養殖

Slide 17

Slide 17 text

リアルな奴らに何が起きているか？ • リアル現場でおきていること • 「最初から悪いコードを書こうとしている人はいない」 • 「昔のコード辛い」 • 逆に言えば • 「誰でも目の前の課題にベストを尽くしている」(それでも上手く行かない) • 「歴史の重力が掛かると歪さが生まれる」

Slide 18

Slide 18 text

コードの寿命を縮めるのは改修・変更 • 「機能が追加される」「要求が不安定」というのが難しさの厳選の1つ • 人間の視野やワーキングメモリに限界があり • 毎回が「ゼロから全体を作る」ものではない、 「全体の整合性を常に取り続ける」も出来ない • 今回はこの難しさに着目してみよう • 「最初から悪いものを作る」アプローチを取らない • 「要求によって開発者を揺さぶる」ような流れ。インクリメントに積み上げる

Slide 19

Slide 19 text

「わざとやる」から「わざとらしい」になる • 「キャリア10年の人の手抜き」と「始めたての人のコード」には どうしても違いが出てしまう • 知識やアンチパターンの体感を持っているので、「悪い例」は書ける • が、どうしても「本物」ではない。フィクションっぽさが拭えなそう • ChatGPTにやらせよう！ • 自分でコードを書かない、そうすれば自分の経験値の影響をゼロにできる • 「どうやってコードを進化させるか」を意識しない。 「どうやってプロダクトを進化させるか」を考える • それをAIさんに伝えて、ネタを出してもらう • (このアプローチに気付くまでに、「自作FWとアプリコード書いてみたけどやっぱりな んか違う」

Slide 20

Slide 20 text

他人にコードを書かせる • ChatGPTにやらせよう！ • 自分でコードを書かない、そうすれば自分の経験値の影響をゼロにできる • 「どうやってコードを進化させるか」を意識しない。 「どうやってプロダクトを進化させるか」を考える • それをAIさんに伝えて、ネタを出してもらう • 試行錯誤の末に気づいたこのアプローチで、完成まで進められた • ここに至るまでに、 「自作FWとアプリ書いてみたけどやっぱりなんか違う」→全破棄、とかを経た • 典型的な悪いコード、 やっぱり「真面目にやってる人が本当にこんな事を書く？」という雰囲気が出る

Slide 21

Slide 21 text

楽しいAi会話

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

要求を積み重ねていく • 「1つ何かをすると、汚くなる」 が実現できた • 「動くけど、バグに近い」 くらいのレベルのもポンポン出来上がる • 当初は自覚的でなかった点として 「普段からリファクタリングをしない環 境でのコードの進化」 という生々しさも得られたように感じる 制作していた原稿の1ページ (最終稿ではカット)

Slide 29

Slide 29 text

できたコード: https://github.com/o0h/iyaaaaa-na-code-example/tree/v1.0.0/Obento

Slide 30

Slide 30 text

使えそう？ • 率直に言えば「もうちょい綺麗でも良いな」とも • コードレビューされていたら通らなくない・・・？という、 ギリギリ(下側に)なものが出てきたな • 文法レベルのミスや古すぎる記法などは修正しつつ • とはいえ、「問題のあるコードの例」としてはまぁ • アンチパターンを踏もうとして書きました！みたいなモノではない • もっと無邪気で素朴な気持ちで書かれたコードに感じる

Slide 31

Slide 31 text

やってみたこと

Slide 32

Slide 32 text

素材が出てきた、どう調理するか？ • 具体的なコードを書く際の思考プロセス等が 自分の中にはない状態からスタート • 通常のコードレビューのように、 「客観的に何に納得できる/できないか」を観察し分析していける！

Slide 33

Slide 33 text

素材が出てきた、どう調理するか？ • 「改修後」の姿を考える: 使えるネタかの評価 • そもそも「現実的に綺麗にならん」だったら使えない • まずは直感的にやる • 「その改修のやり方は、使えそうか？」を考える: ステップの評価 • 書き換えのテクニックについての吟味 • その後に「その問題は、説明できるか？」を考える • (今回の想定読者レベルに合わせて、かつ限りある紙面上で) 説明できるか？の吟味 • 縛りプレイめいたもの: 業務でノリファクタとの違い • ベイビーステップで手習いできるか？ • リファクタよりも大きい問題(ドメインモデリングなど)になっていないか？

Slide 34

Slide 34 text

@todo? / とりあえずこの辺は触れら れるんじゃないの〜みたいな • 大上段のアプローチの検討 • 俯瞰から/歴史から/定量から • 「自分の足で歩みを進められるよう に」みたいなのも考えてさ〜ってや つ