20220227 可読性って大事

Transcript

1. 「きれいなコード」って大事 2022 / 2 / 27 クマ
2. 自己紹介 • 実務入って半年 • PHP(Laravel)、JavaScript(Vue)を書いてます。 • 仕事もマッチングアプリも伸び悩み中。。。 • 好き↓ • タガが外れたように満腹まで食べる • ラーメンハシゴ、次郎マシマシ…etc • 甘いもの • ミスド食べ放題15個の実績（尚、ぼっち参戦） • スイパラ行くのが直近目標（もちろん、ぼっち参戦） P-01
3. 目次 • 話すこと • 話さないこと • 本LTのゴール • 動機 • なんで「きれいなコード」は大事か • どうやって「きれいなコード」を実現するか • 俺的ピックアップ • おわりに P-01
4. 話すこと P-01
5. 話す事 • 「きれいなコード」って大事だよねって話 • 朴訥（ぼくとつ）とした、当たり前な記述ルール P-01
6. 話さないこと P-01
7. 話さない事 • 「～」を使ったら爆速開発できた的な話 • 「～」で「***」を作ってみた話 ↓ 業務に直接影響しないかもしれません。スイマセン。。。 （いづれできるように精進します！） P-01
8. 本LTのゴール P-01
9. 本LTのゴール • 「きれいなコード」の重要性再認識 • リファクタリングへの意識微増 • 「ウチでは～」とか「～もあるよね」みたいな情報共 有（これが一番したい） P-01
10. はじめに P-01
11. はじめに ちょっとだけ、業務に慣れてきた感がある。 しかし、最近ちょこちょこ受ける指摘が。。。 P-01
12. はじめに 「この変数名イケてないね」 「(if文で早々にreturnすれば)ここのelse文て消せるよ ね？」 ⇒おうふ。 P-01
13. はじめに タスク進捗を優先で「コードのきれいさ」がないがしろに ↓ レビューで指摘受け、修正工数増 これは改めて見直すいい機会だと P-01
14. なんで「きれいなコード」が大事か P-01
15. なんで「きれいなコード」が大事か 言わずもがなですが • 改修時のメンテナンス性 • バグの早期発見 P-01 “「他の人が理解できるって誰が得するんだよ」 …「他の人」というのは…6か月後の「君自身」かもしれない” （「リーダブルコード」より）
16. どうやって「きれいなコード」を実現するか P-01
17. どうやってきれいなコードを実現するか 当たり前ですが２点 1, ポイントを抑える 2, 実務で実践＋フィードバック ↓ 今回は1, の意識が薄れてきたなあ、と実感 P-01
18. どうやってきれいなコードを実現するか 上述の通りこちらでインプット ⇒個人的ポイントをピックアップ P-01
19. 俺的ピックアップ8選 ※” ”(引用符)は参考書籍から引用 P-01
20. 1, 【変数】明確な単語を選ぶ P-01
21. 1, 【変数】明確な単語を選ぶ “「空虚な」単語は避けるべき” Ex, ‘get’ P-01 // pageをどこからとってくる？ローカルキャッシュ？データベース？ def GetPage(url): … Ex, ‘Stop’ // どんな操作を指す？取り消しができないならKill、あとから再実行できるならPause()のがいい class Thread { void Stop(); … } ※プログラミングでよく使う英単語のまとめ【随時更新】 https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923
22. 2, 【変数】値の単位 P-01
23. 2, 【変数】値の単位 “計測できるものであれば変数名に単位を入れる…” Ex. ‘getTime()’ P-01 // getTime()はミリ秒を返すので、start_ms, elapsed_ms…のがいい var start = (new Date()).getTime(); … var elapsed = (new Date()).getTime() – start; Document.writeIn(“読み込み時間: ” + elapsed + “秒”);
24. 3, 【変数】重要な属性を追加する P-01
25. 3, 【変数】重要な属性を追加する “危険や注意を喚起する情報も追加した方がいい” Ex. ‘password’ P-01 // 暗号化前であることを明示的にする password ⇒ plaintext_password Ex. ‘comment’ // エスケープ処理されてないことを明示 comment ⇒ unescaped_comment
26. 4, 【変数】不要な単語を投げ捨てる P-01
27. 4, 【変数】不要な単語を投げ捨てる “含まれる単語を削除しても情報が全く損なわれないこと もある。” Ex. ‘ConvertToString’ P-01 // 「文字列に変換ね」ってなる ConvertToString ⇒ ToString Ex. ‘DoServeLoop’ // 「ループに入る（※）のね」ってなる ※日本語訳が正直不明…ゴメンナサイ… DoServeLoop ⇒ ServeLoop
28. 5, 【変数】 スコープが小さければ短い名前でもいい P-01
29. 5, 【変数】スコープが小さければ短い名前でもいい “識別子の「スコープ」が小さければ、多くの情報を詰め 込む必要はない” P-01 if (debug) { map<string, int> m; // 引数mはすぐ近くにあるmap<string, int>だとわかる Print(m); } // 個人的にはやりすぎ（省略しすぎ）感あるけど… ※個人的主観：今はこれが主流では？ ⇒これまで話した1~4のルールは発行時期的にグローバルスコープへの定義 とかやってた時代を考慮してのルールかと思う
30. 6, 【コメント】 入出力のコーナーケースに実例を使う P-01
31. 6, 【コメント】入出力のコーナーケースに実例を使う “慎重に選んだ入出力の実例をコメントに書いておけば、 それは千の言葉に等しい” P-01 // ‘src’の先頭や末尾にある’chars’を除去する // 実例 ： Strip(“abba/a/ba”, “ab”)は”/a/”を返す String Strip(String src, String chars) { … }
32. 7, 【制御文】関数から早く返す P-01
33. 7, 【制御文】関数から早く返す “関数で複数のreturn文を使ってはいけないと思っている 人がいる。あほくさ。関数から早く返すことはいいことだ。” P-01 public boolean Contains(String str, String substr) { if (str == null || substr == null) return false; // 早々にreturnする if (substr .equals(“”)) return true; // ここでもreturnする … } ※個人的にはelseを書かなくて済むから好きな書き方です。
34. 以上。 P-01
35. おわりに P-01
36. おわりに～その１～ • ここまで書いたものの、既存プロジェクトのコーディン グルール（暗黙のルール含む）等との兼ね合いもあり、 インプットした通りにならないことも多いことも実感 • 純粋にリーダブルコードの内容がそのまま反映できる とは限らない • 「命名は長くていい」とか「getとか曖昧な単語を使う な」とか… ⇒土台（基本知識）としてのインプット、と捉える P-01
37. おわりに～その２～ • かつ、「きれいなコード」を作るのに工数を割くのも良 しとされないことも会社によってはある • PHP Conference Japan 2021: 20年モノの巨大 Webサービスの開発… (https://youtu.be/ZJHX7o1mYJE) • 意見交換しましょう P-01
38. ご清聴ありがとうございました。 P-01