Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'j...
Search
Maki Hayashi
December 22, 2024
Programming
7
1.8k
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
PHP Conference Japan 2024のLT登壇資料です。
Maki Hayashi
December 22, 2024
Tweet
Share
More Decks by Maki Hayashi
See All by Maki Hayashi
小さく段階的リリースすることで深夜メンテを回避する
mkmk884
2
120
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
9
3.5k
php.iniって何書いているの
mkmk884
2
490
1人プロ・ペアプロ・モブプロの効果的な使い分け
mkmk884
0
1.4k
テスト嫌いな自分の苦手意識がなくなった話
mkmk884
4
880
部内全員で理想の開発部を考え、それに向かって1年間継続して活動に取り組む環境をつくった話
mkmk884
0
190
Other Decks in Programming
See All in Programming
OUPC2024 Day 1 解説
kowerkoint
0
390
マルチアカウント環境での、そこまでがんばらない RI/SP 運用設計
wa6sn
0
330
Functional APIから再考するLangGraphを使う理由
os1ma
5
650
CTFのWebにおける⾼難易度問題について
hamayanhamayan
1
950
バックエンドNode.js × フロントエンドDeno で開発して得られた知見
ayame113
5
1.3k
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
1.1k
OpenTelemetryを活用したObservability入門 / Introduction to Observability with OpenTelemetry
seike460
PRO
0
240
Kubernetesで実現できるPlatform Engineering の現在地
nwiizo
2
1.7k
読もう! Android build ドキュメント
andpad
1
240
体得しよう!RSA暗号の原理と解読
laysakura
3
520
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
560
なぜselectはselectではないのか
taiyow
2
290
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1369
200k
4 Signs Your Business is Dying
shpigford
183
22k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Writing Fast Ruby
sferik
628
61k
We Have a Design System, Now What?
morganepeng
51
7.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.4k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
GitHub's CSS Performance
jonrohan
1030
460k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Typedesign – Prime Four
hannesfritz
41
2.6k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Fireside Chat
paigeccino
37
3.3k
Transcript
「とりあえず動く」コードはよい、 「読みやすい」コードはもっとよい まきまき 2024/12/22 PHPカンファレンス2024 1
まきまき @_mkmk884 愛媛 → 京都 → 小田原 NE株式会社 アプリケーションエンジニア
PHPカンファレンス小田原 コアスタッフ 2
新卒1〜2年目の頃…
最初は「とりあえず動く」コードを書いていた 4 🔰 ぴちぴちの私 実力がない 納期やばい 設計ワカラン ドメイン知識ない テスト…? 💦
チーム? 自分で手一杯だけど?
最初は「とりあえず動く」コードを書いていた 5 🔰 頼む… 💧 ぴちぴちの私 動いて くれ…
最初は「とりあえず動く」コードを書いていた 6 🙏 頼む… 💧 ぴちぴちの私 動いて くれ… 祈り駆動開発
「とりあえず動く」コード 7 • 要件通りに動いている • 開発者が”完全に理解”をしている • テストコードがなかったり、あっても見たいものを 正しくテストできていなかったりする
「とりあえず動く」コード 8 ユーザーに提供したい価値が届く • 要件通りに動いている よい✌
年月は経ち…
「読みやすい」コードに救われ、意識しはじめた 10 どこに追加すれば いいかわかる 大体どの辺りに 書いてありそうか わかる 意図がわかる !
「読みやすい」コード 11 • 誰が読んでも読む時間が短縮される • シンプル • 振る舞いの単位で処理がまとめられている • 適度にコメントがある
• 関数名・変数名で意図がわかる • IDEが認知しやすいコード (コードジャンプができる、Docコメントがある等) コードジャンプできない例:動的にインスタンス化を行っている
「読みやすい」コード 12 • 誰が読んでも読む時間が短縮される • シンプル • 振る舞いの単位で処理がまとめられている • 適度にコメントがある
• 関数名・変数名で意図がわかる • IDEが認知しやすいコード (コードジャンプができる、Docコメントがある等) コードジャンプできない例:動的にインスタンス化を行っている
(余談)コードジャンプができない例 32 <?php // ディレクトリからファイル一覧を取得 $files = scandir('classes'); // .phpを除外してクラス名リストを作成
$classNames = array_filter( array_map( function ( $file) { return preg_replace( '/\.php$/', '', $file); }, $files ), ); // クラスのインスタンス化 $instances = []; foreach ($classNames as $className) { if (!class_exists( $className)) { return; } $instances[] = new $className(); } インスタンス化するクラス名 を動的に作っている (たぶん昔はよくあった) 例
「読みやすい」コード 13 • 誰が読んでも読む時間が短縮される 変更箇所・影響範囲がパッとわかる 変更が早くでき、変更に強いものになる もっとよい✌
「とりあえず動く」コードと「読みやすい」コード 14 「とりあえず動く」コード 「読みやすい」コード 早く価値を増大できる 仕様変更があっても 価値を持続できる 価値を提供すること ができる
• コードを理解しやすくなる 「読みやすい」コードが他者に与える影響 15 → 工数が短縮される → バグに気づきやすくなる → 学習コストを削減できる
• 変更範囲や影響範囲を把握しやすくなり、 見積もりもしやすくなる
• コードを理解しやすくなる 「読みやすい」コードが他者に与える影響 16 → 工数が短縮される → バグに気づきやすくなる → 学習コストを削減できる
• 変更範囲や影響範囲を把握しやすくなり、 見積もりもしやすくなる 安 心
「とりあえず動く」→「読みやすい」 にすればもっともっとよい💪
リファクタリング やっていき!
知識・経験を積むごとに力がつき…
リファクタリングが楽しくなってきた 20 “完全に理解した” の私 はまっていく感じ パズルみたい めちゃくちゃ 勉強になる あの本に書いて あったことを
適用してみよう ♪
リファクタリングが自分に与える影響 21 • 仕様を把握することができる • バグの発生率が下がるため、安心して開発できる • 設計力やコーディングスキルが向上する → 向上する実感も得られる
リファクタリングが自分に与える影響 22 • 仕様を把握することができる • バグの発生率が下がるため、安心して開発できる • 設計力やコーディングスキルが向上する → 向上する実感も得られる
本や他者から学んだ 知識を自分も 実践できる…!
せっかくリファクタリングするなら コスパよく着実に変更していきたい!
リファクタリングをする場所 24 • 拡張することが確定しているところ ◦ チーム開発で別のメンバーが触る等 • コミットが多いところ ◦ つまり、変更・バグがよく発生するところ
◦ 逆にいうと「とりあえず動く」コードも長い期間変更 がなければ、そのままで十分 • テストがしっかり書けている・書かれているところ
リファクタリングをする場所 25 • 拡張することが確定しているところ ◦ チーム開発で別のメンバーが触る等 • コミットが多いところ ◦ つまり、変更・バグがよく発生するところ
◦ 逆にいうと「とりあえず動く」コードも長い期間変更 がなければ、そのままで十分 • テストがしっかり書けている・書かれているところ
リファクタリング自体も 安心して行いたい
不安の壁 27 正しく動くかどうかがわからないまま変更するのは不安 完成の状態(結果・仕様)がわからないと 何をしていけばいいのかもわからない ? 改善後も 正しく動いている から大丈夫だよ ↑
誰かに言ってほしいですよね? 👀
「意味のあるテストコード」が安心をもたらす 28 改善後も 正しく動いている から大丈夫だよ さまざまな制約が「きれいな」どころか「動作する」の前にも立ちふさがる。 私たちは、不安を抱えて考え込んでしまうのをやめにして、代わりに自動化 されたテストによって開発を推し進める。 テスト駆動開発 まえがき
「意味のあるテストコード」が安心をもたらす 29 ここでいう 意味のあるテストコード = 信頼ができるテストコード • エッジケースや異常系も カバーしている •
実装の細部に依存せずに、 振る舞いをテストしている
まとめ 30 • 「とりあえず動く」コードは、価値を提供できるため よい • その後も価値を増大、持続しようとしたときに 「読みやすい」コードが効果を発揮してくる • 変更箇所が多いところからリファクタリングをすると
コスパがいい • 安心してリファクタリングを行うために 意味のあるテストコードが必要
「読みやすい」コードにして 自分にも他者にも 安心を届けていきましょう🙌