良いコードとは何か - エンジニア新卒研修 スライド公開

Transcript

1. 良いコードとは何か 2021年度 株式会社サイバーエージェント エンジニア 新卒研修 株式会社CyberZ 森 篤史

2. 森 篤史 2019年度 新卒⼊社 Androidアプリエンジニア 未踏スーパークリエータ @at_sushi_at Mori-Atsushi

3. リアーキテクチャプロジェクト 新卒1年⽬からAndroidアプリのアーキテクチャ移⾏を主導 Java → Kotlin MVC → MVVM + Clean

   Architecture 機能開発と並⾏した段階的リアーキテクチャ 現在も進⾏中 CA BASE CAMP セッション

4. プロジェクトを進⾏する上で感じたこと が何かを知らなければ、 たとえ書き直したとしても より 良いコード 良くならない

5. 🚀 今回のゴール 良いコードとは何かについて深く考える

6. .品質とスピードはトレードオフか .技術的負債の発⽣と解消 .凝集度と結合度 .Clean Architecture

7. 品質とスピードは トレードオフか

8. 👨🦳 今は急いでるので、 品質より速度優先で！

9. 疑問① 品質とスピードは トレードオフである？

10. その前に、品質とは？ • 外部品質 ユーザに⾒える 仕様通り動く、バグがない、⾼速に動作する • 内部品質 ユーザからは⾒えない 保守性や柔軟性、可読性、⼀貫性

11. その前に、品質とは？ • 外部品質 ユーザに⾒える 仕様通り動く、バグがない、⾼速に動作する • 内部品質 ユーザからは⾒えない 保守性や柔軟性、可読性、⼀貫性 往々にして

    犠牲になるのはこっち

12. 内部品質を⼀時的に下げると起きること 内部品質を犠牲に

13. 内部品質を⼀時的に下げると起きること その後 崩壊し続ける

14. 割れ窓理論 窓ガラスを割れたままにしておくと、 その建物は⼗分に管理されていないと思われ、 ごみが捨てられ、やがて地域の環境が悪化し、 凶悪な犯罪が多発するようになる、という犯罪理論 割れ窓理論とは - コトバンク https://kotobank.jp/word/%E %

    %B %E % % C%E %AA% %E % % %E %AB% -

15. 思考：後でキレイにしよう 内部品質を犠牲に

16. その後では来ない • 市場からのプレッシャーは⽌まらない • 競合他社に追い抜かれないためには、これからも⾛り続けるしかない • 崩壊が始まり、⽣産性はゼロに近づいていく Robert C.Martin (

    ), Clean Architecture 達⼈に学ぶソフトウェアの構造と設計, KADOKAWA

17. 品質とスピードはトレードオフである？ •ごく短期的にはスピードは上がるかもしれない •中期的には逆効果である •⻑期的には致命的になる

18. どれくらい短期なのか？ • 数週間（1ヶ⽉以内）と⾔う⼈もいる • 数⽇で違いが出ると⾔う⼈もいる • 個⼈的な 経験則から⾔えば、1週間で問題が発⽣する • 再びそのコードもしくは関連するコードに触れた際、直ちに問題になる

19. コードの品質を⾼く保つからこそ速い • 品質を上げることで コードの変更速度が上がる ⼿戻りが減る 学びのループが早くなる 市場での競争⼒が上がる 品質を上げる 速度が上がる

20. 疑問② 時間をかければ 良いコードが書けるのか？

21. 不要に時間をかけても品質は上がらない 品質とスピードはトレードオフではない 品質を下げても速度は上がらない 時間をかけても品質は上がらない = =

22. 品質を上げるために必要なのは知識、経験 • 知識、経験が品質を向上させる 習得するには時間がかかる 学び続ける必要がある 品質を上げる 速度が上がる 知識、経験

23. 技術的負債の発⽣と解消

24. 疑問③ 品質を上げるために必要な 知識‧経験とは？

25. 品質について考えるために 品質が下がっている状態 技術的負債が溜まっている状態 =

26. 技術的負債の発⽣理由 意図的な負債 ⚡ 変化による負債 🏃 学びによる負債 💡 技術知識の問題 持っている技術知識を 正しく使わなかった

    当初は存在しなかった 技術が登場した 使っていた技術が 古くなった 当初は知らなかった 技術を学んだ ドメイン知識の問題 ドメイン知識を 正しくコードに 反映しなかった 当初とはドメイン 知識が変わった 当初は知らなかった ドメイン知識を学んだ より良いドメイン表現を ⾒つけた

27. 意図的な負債 • 持っている技術知識を正しく使わなかった • ドメイン知識を正しくコードに反映しなかった • 「品質より速度優先」で発⽣する • 必ず避けられる •

    コードの品質を犠牲にするのではなく、 ターゲットを削るかリリース⽇を延⻑すべき ⚡

28. 変化による負債 • 当初は存在しなかった技術が登場した 使っていた技術が古くなった • 当初とはドメイン知識が変わった • 予測しにくい技術的負債 • 時流を読み、想像することは⼀種のスキル

    • 放置していくと、銀⾏の利息のように膨らんでいく • 早期に回収することが望まれる 🏃

29. 学びによる負債 • 当初は知らなかった技術を学んだ • 当初は知らなかったドメイン知識を学んだ、 より良いドメイン表現を⾒つけた • こういった負債が発⽣すること⾃体は良いことである • 変化による負債と同様に、早期に回収することが好ましい

    • 学ぶことで事前に防げる可能性はある 💡

30. Ward Cunningham(ウォード‧カニンガム) による説明 • たとえ理解が不完全だとしても、⽬の前の問題に対する現時点での理解を反 映するコードを書くことには賛成です。 • そのソフトウェアに現時点での理解を可能な限り反映させることが重要で す。 •

    そうしておけば、いざリファクタリングをするときが来たなら、コードには 当時何を考えていたかが明快に残っているので、現在の理解に合わせてリ ファクタリングするのも容易になります。 【翻訳】技術的負債という概念の⽣みの親 Ward Cunningham ⾃⾝による説明 - t-wadaのブログ, https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor Debt Metaphor - Youtube, , https://youtu.be/pqeJFYwnkjE

31. 当初は知らなかった技術を学んだ • ⾔語やライブラリの使い⽅を誤っていた、より良い使い⽅があった • より適切なツールがあることを知らなかった • より良いコードとは何か知らなかった ここについて深堀りします

32. 凝集度と結合度

33. 👨 このコードは こちらの書き⽅のほうが 好ましいと思います。

34. 疑問④ よりよいコードであるという 根拠は？

35. 凝集度という⼀つの指標 • 偶発的凝集 • 論理的凝集 • 時間的凝集 • ⼿順的凝集 •

    通信的凝集 • 逐次的凝集 • 機能的凝集 ⾼い - 良い 低い - 悪い • モジュール内の協調度を⽰す - パッケージ - クラス - メソッド • 凝集度の⾼いモジュールは、 堅牢性、信頼性、再利⽤性、 読みやすさなどの点で好ましい • 単⼀責任の原則（SOLID）

36. 偶発的凝集 • 適当（無作為）に集められたものがモジュールとなっている。 • モジュール内の各部分には特に関連性はない • 「とりあえず動く」みたいな状況

37. 論理的凝集 • 論理的に似たようなことをするものを集めたモジュール • 例えば：フラグによって動作を変える

38. 時間的凝集 • 時間的に近く動作するものを集めたモジュール • 実⾏順序を⼊れ替えても動作する • 例えば：初期化処理や、UIのフォアグラウンド時の処理など

39. ⼿続き的凝集 • 順番に実⾏する必要があるものを集めたモジュール • 共通したデータは使わない • 例えば：アクセス権を確認してファイルに書き込む

40. 通信的凝集 • 同じデータを扱う部分を集めたモジュール

41. 逐次的凝集 • ある部分の出⼒が別の部分の⼊⼒となるような部分を集めたモジュール • 例えば：ファイルを取得して変換して保存する

42. 機能的凝集 • 単⼀の定義されたタスクを実現するモジュール • 例えば：2点間の距離を計算する

43. 凝集度の使い分け • 偶発的凝集 • 論理的凝集 • 時間的凝集 • ⼿順的凝集 •

    通信的凝集 • 逐次的凝集 • 機能的凝集 必ず避けるべき 可能な限り避けるべき 理想的 可能な限り⼩さく保つ

44. 例えば：時間的凝集の関数 時 間 的 凝 集

45. 凝集度が低いモジュールを⼩さくする ⼿続き的凝集 時間的凝集 逐次的凝集 逐次的凝集 ⼿続き的凝集

46. 例えば：論理的凝集 論 理 的 凝 集

47. 共通化せず、分ける ⼿続き的凝集 ⼿続き的凝集 逐次的凝集

48. 関数は分ければ良いものではない • 関数を分けることで、凝集度を⾼めることができる • 関数が分かれると認知負荷は多少なりとも上がる • 意味のわかる単位で区切ることが重要 ▼ こっちのほうがわかりやすいかも…？

49. 結合度という指標 • 内部結合 • 共通結合 • 外部結合 • 制御結合 •

    スタンプ結合 • データ結合 • メッセージ結合 低い - 良い ⾼い - 悪い • モジュール間の相互依存性の程 度を⽰す - パッケージ - クラス - メソッド • 結合度が低いと可読性と保守性 が上がる • 凝集度と相関が強く、凝集度が ⾼くなれば結合度は低くなる

50. 内部結合 • あるモジュールが別のモジュールの内部動作によって変化したり依存したり する • 例えば：別のモジュールの内部データをリフレクション等で直接参照する

51. 共通結合 • 複数のモジュールが同じグローバルデータにアクセスできる状態 • 変更が加えられると、予期しない副作⽤が発⽣する可能性がある

52. 外部結合 • 標準化されたインタフェースをもつグローバルな状態を共有する • 外部ツールや外部デバイスへの通信で発⽣する可能性がある • ⽂献により解釈が⼀部異なる

53. 制御結合 • あるモジュールに何をすべきかについての情報を渡すことで、 別のモジュール処理の流れを制御する。 • 論理的凝集が発⽣する

54. スタンプ結合 • 構造体やクラス等の受け渡しで結合されている • 不必要にデータを渡す可能性がある

55. データ結合 • 単純な引数のやりとり • 必要最⼩限のデータを渡す

56. メッセージ結合 • 引数のないやりとり • データのやり取りは存在しない

57. 結合度の使い分け • 内部結合 • 共通結合 • 外部結合 • 制御結合 •

    スタンプ結合 • データ結合 • メッセージ結合 必ず避けるべき 可能な限り避けるべき 理想的 ⼀部ケースで注意が必要

58. Clean Architecture

59. より良いコードとは • より良いモジュール   凝集度 • より良いモジュール間の関係   結合度 • より良いモジュール群   ？

60. Clean Architecture Robert C.Martin ( ), Clean Architecture 達⼈に学ぶソフトウェアの構造と設計, KADOKAWA

    The Clean Architecture, https://blog.cleancoder.com/uncle-bob/ / / /the-clean-architecture.html

61. Q. どれがClean Architectureに準拠している？ Clean Architecture Hexagonal Architecture MVVM Architecture

62. A. 全部 Clean Architecture Hexagonal Architecture MVVM Architecture

63. 4つの円はあくまで例にすぎない • Clean Architectureで主張されているルールは以下の2つだけである ① レイヤーに分離することで、関⼼事の分離を⾏う ② 依存性は内側だけに向かっていなければいけない

64. 内側/外側とは？ • 外側 UI データベース 外部システム フレームワーク • 内側 ビジネスロジック

    エンティティ 内側に近づくにつれ、ソフトウェアは抽象化され、 ⼀般的なものになる必要がある

65. これらのルールに従うことで • フレームワーク⾮依存 • テスト可能 • UI⾮依存 • データベース⾮依存 •

    外部エージェント⾮依存 ⾼い保守性を実現することができる

66. 境界線を超える⽅法① • 外側から内側へのアクセスは、常に可能 doSomething() UI UseCase

67. 境界線を超える⽅法② • ストリームを使って内側から外側にイベントを流す data.observe UI UseCase

68. 境界線を超える⽅法③ • 依存関係逆転の原則（DIP）を使って内側から外側を呼び出す UI UseCase UIProtocol Implement update

69. 境界線を超えるデータ • 単純なデータ構造が好ましい 結合度を低くする • 円の内側が外側について知るようなデータを渡してはいけない 常に内側の知識のみで構成される

70. 🚀 まとめ • 品質とスピードはトレードオフではない • 品質を上げるためには、知識/経験が必要 • 凝集度/結合度の指標により、モジュールの評価をすることが可能 • 関⼼を分離し、正しく依存⽅向を制御することで、

    クリーンなアーキテクチャを実現できる

71. 品質を向上させるための知識は膨⼤ • 命名 • コメント • コードレビュー • オブジェクト指向 •

    ⼿続き型プログラミング • 宣⾔的UI • ⾃動テスト • SOLIDの原則 • デザインパターン • YAGNI • KISSの原則 • 継承より移譲 • Dependency Injection • Mutable / Imutable • Null安全

72. 最後に • 今回の話にあんまりピンと来てない⼈もいるかもしれません • 学習と経験を繰り返すことで、初めて⾝についたスキルになります • 数年後、より深い理解に到達することを期待しています 学習 経験

73. 参考⽂献 • 質とスピード（2020秋100分拡⼤版） / Quality and Speed Autumn Edition, https://

    speakerdeck.com/twada/quality-and-speed- -autumn-edition • Robert C.Martin ( ), Clean Architecture 達⼈に学ぶソフトウェアの構造と設計, KADOKAWA • オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling, https://speakerdeck.com/sonatard/ coheision-coupling • 【翻訳】技術的負債という概念の⽣みの親 Ward Cunningham ⾃⾝による説明 - t-wadaのブログ, https://t- wada.hatenablog.jp/entry/ward-explains-debt-metaphor • The Clean Architecture, https://blog.cleancoder.com/uncle-bob/ / / /the-clean- architecture.html • 世界⼀わかりやすいClean Architecture, https://www.slideshare.net/AtsushiNakamura /clean- architecture-release • Code readability, https://speakerdeck.com/munetoshi/code-readability