はじめに
前回に引き続き、PHPカンファレンス関西2025で参加したセッション「コードは育つ、僕も育つ。 PHPと歩んだ設計物語」に参加した際の学びをまとめました。
セッション概要
過去の失敗事例の紹介と改善策とそこから得られた知見についてのセッションでした。
過去の失敗事例について
Fatなクラス
Userに関係あるからと言って、Userモデルに色々盛り込んだ結果、コードの量が非常に多くなってしまった。
とりあえずファイルを切り出す
Userモデルのでの失敗を活かすために、機能ごとにファイルを切り分けていく対策を実行。
新たなファイルに分割したが、結果として認知負荷の高いファイル群ができあがってしまい、なんのために存在するファイルなのかわかりにくくなってしまう問題が新たに発生した。
責務を分割できていない
「単一責務の原則」について知見がなかったため、同じトランザクション内に、「データベースの保存」と「メールの送信」を行う処理があり、メールの送信が失敗したら、ロールバックするコードを書いてしまうことがあった。
改善策
テストコードを書いてみる
自分のコードのどこがおかしいかを見つけるために結合テストを書いてみることで効果があった。
責務がきちんと分かれていないコードはテストをうまく書くことができず、それによって逆説的に正しいコードの書き方を学ぶことができ、正しいコードを書くために必要な知識を得ることができた。
具体的なコメントを書く
自分だけわかるようなコメントを避け、コメントを読んだ第三者が何をしたいのか具体的に理解できるようなコメントを残す。もしくはチケットを発行し詳細を書いておく。
※フロント側のファイルに、コメントをいれるのだけは避けたほうがいい。ミスで出てきてしまうことがあるので。
ボーイスカウトルールを意識する
「来たときよりも美しく」の精神で既存コードの修正を行うときはできるだけ、周辺のコードをより良いコードに書き換えていく意識を持つこと。ただし、過剰にこのルールを適用しようとすると、全く関係のない修正まで手を広げてしまうことがあるので、やりすぎには注意する必要がある。（変更とは関係ないけど目についたところを修正するとかは避ける。）
開発の状況をドキュメントに残しておく
ADR（アーキテクトデシジョンレコード）のようなイメージでドキュメントかしておくと後々助かることがある。
（ある程度の大きさのプロジェクトで新規の実装が行われるとき等はドキュメントに残すのがおすすめ。）
・ なぜこの時に行なったのか
・ なぜこの実装を行ったのか
・ プロジェクトメンバーのスキルセットはどうだったか...etc
最初から良くない実装を行おうとしているわけではなく、あとになってだめだと気づくので。
設計について学ぶ
・オブジェクト思考
・デザインパターン
・レイヤードアーキテクチャ
・システムアーキテクチャ
・ドメイン駆動設計
・クリーンアーキテクチャ
など設計について学ぶことで改善のモチベーションがあがる。
「なぜこのように作られているのか」という設計思想を意識することで、プログラム理解を深めることができる。
スモールステップでの改善
学ぶとすぐに使いたくなってしまいますが、いきなり全部に適用していくことが難しければスモールステップで実装するのがおすすめ。
調べて学んだことを実装すると、開発モチベーションにつなげることができたり、
時間が経った時に、その時の手法で他のコードも同様に改善できることがある。
まとめ
- 過去のミスは改善できる
- 改善継続の仕組みを整える
- 学び続けてスモールステップで導入する
セッション最後の
"I have not failed, I've just found 10,000 ways that Won't work"
（私は失敗したことはない。うまくいかない方法を10,000通り見つけただけだ。）
はとても印象的なことばでした。