はじめてのIT勉強会 プリンシプルオブプログラミングPart.3

Transcript

1. The Principles of Programing Part.3 2021.09.22　はじめてのIT勉強会
2. 自己紹介 名前 : うにすけ 所属 : 東北大学工学部電気情報物理工学科4年 出身 : 埼玉県 twitter : @uniuni_8282
3. プリンシプルオブプログラミング プログラマが３年目までに身に付けたい 一生役立つ101の原理原則
4. どんな人のための本？
5. コードは書けるけど 「よいコード」にならない人
6. 「よいコード」にならない はどんな状況？
7. 「よいコード」にならない • 書いたコードがリリースされると頻繁に障害が発生する • 書いたコードがリリースされると動作が遅い、すぐに落ちるなどのクレームがくる • 書いたコードを見てもらうとわかりにくい、シンプルでない、美しくないと指摘を うける • 書いたコードを見返した時読みにくいと感じる • 書いたコードを修正すると途端に動かなくなる • 書いたコードを修正すると予想外の箇所に影響が出る • 書いたコードに機能を追加しようとしてもうまくいかない • 書いたコードに仕様変更が入るとその部分全てが書き直しになる
8. なぜ「よいコード」が書ける プログラマに成長するのが困難か？
9. 成長したいが 方法・指針がわからない
10. よいコードを書くための 「プリンシプル」を紹介
11. 「プリンシプル」とは？
12. プログラミングの指針となる 前提・原則・思想・習慣・視点 手法・法則
13. なぜ「プリンシプル」を学ぶべきか？
14. 「プリンシプル」の価値 今ある技術はプリンシプルの目的「コードを書きやすく・読みやすく・バグを生じにくく・修正しや すくする」の具現化 • 技術がなぜ必要かを理解できるために習得が早く・深くなる • 技術の目的に沿った形で適用できるために技術の使い方がうまくなる • 普遍的な情報であるために陳腐化しない
15. プログラマとしての成長の 「正しい道」かつ「近道」になる
16. 目次 第１章　前提〜プログラミングの変わらぬ真実〜 第２章　原則〜プログラミングのガイドライン〜 第３章　思想〜プログラミングのイデオロギー〜 第４章　視点〜プログラマの見る角度〜 第５章　習慣〜プログラマのルーティーン〜 第６章　手法〜プログラマの道具箱〜 第７章　法則〜プログラミングのアンチパターン〜
17. 目次 第１章　前提〜プログラミングの変わらぬ真実〜 第２章　原則〜プログラミングのガイドライン〜 第３章　思想〜プログラミングのイデオロギー〜 第４章　視点〜プログラマの見る角度〜 第５章　習慣〜プログラマのルーティーン〜 第６章　手法〜プログラマの道具箱〜 第７章　法則〜プログラミングのアンチパターン〜
18. 目次 第１章　前提〜プログラミングの変わらぬ真実〜 第２章　原則〜プログラミングのガイドライン〜 第３章　思想〜プログラミングのイデオロギー〜 第４章　視点〜プログラマの見る角度〜 第５章　習慣〜プログラマのルーティーン〜 第６章　手法〜プログラマの道具箱〜 第７章　法則〜プログラミングのアンチパターン〜
19. 第３章　思想〜プログラミングのイデオロギー〜 目的 : 成功したソフトウェアを支えた文化・哲学・価値観といった思想を学びプログラミングの設計 方針に生かす • プログラミングセオリー • アーキテクチャ根底技法 • アーキテクチャ非機能要件 • 7つの設計原理
20. プログラミングセオリー プログラミングを導く価値観 プログラミングの最大の関心ごとは「最高のコードを作り上げること」 最高のコード : 拡張方法が多く存在し、余分な要素が存在せず、読みやすく理解しやすいコード • コミュニケーション • シンプル • 柔軟性 価値観を技術の選択基準に プログラミングにおける問題解決に用いる技術の選択には適応理由「なんでこんなことしなくちゃい けないの？」が必要→「価値」が個別の技術の選択理由になる What 最高のコードの実現のために「セオリー」を支える3つの価値 Why
21. 価値観は原則を通じてコードに適用 プログラミングセオリーの「価値」を基準として利用して技術や手法の適用/不適応を判断する →「価値」はプログラミングに利用するには抽象的すぎるために実戦につなげる橋渡しの概念が必 要。それが6つの原則 プログラミングセオリー How • 結果の局所化 • 繰り返しの最小化 • ロジックとデータの一体化 • 対称性 • 宣言型の表現 • 変更頻度 価値とプログラミングの架け橋となる6つの原則
22. プログラミングセオリーを支える3つの価値 - コードは「文書」であるので 本質は「コミュニケーション ツール」 - コミュニケーションが良好で あるとはコードを読んだ人が コードの理解・修正・使用がで きること - 良好なコミュニケーションの ために読む人のことを考えるべ き コミュニケーション - コードの変更の容易さのこと - 保守作業を円滑に進めるのに 役立つ - 拡張しやすく拡張が他に波及 しないような設計を目指すべき - 柔軟性を言い訳にした複雑な コード/設計は許容できない。 余計な柔軟性は結局使われず複 雑さを増すコードになる可能性 が高い 柔軟性 - コードがシンプルであるとは 「余分な複雑性」が取り除かれ た状態 - 「余分な複雑性」の除去は コードの理解を容易にし、障害 の入り込む確率も下げる。良好 なコミュニケーションにも繋が ることが多い - シンプルにしすぎてコミュニ ケーションが損なわれる場合に はコミュニケーションを優先 シンプル
23. プログラミングセオリーを実現する6つの原則 変更の影響が局所に留まるよう にコードを構成する →関係性の高いコードを集約し てモジュール化する 結果の局所化 ロジックと操作されるデータは 同じ関数やモジュールに ロジックとデータの一体化 重複ロジックの排除 →コードの分割/関数化 繰り返しの最小化 同質なものはコードのどの場所 でも同じ振る舞いをする 対称性 修正タイミングが近いものは まとめる 更新頻度 データフローをなくし シンプルに表現する 宣言型の表現
24. よいコードの基礎原理 よいソフトウェア・アーキテクチャ構築のための基礎原理 • コミュニケーション • シンプル • 柔軟性 アーキテクチャ根底技法 • 抽象 • カプセル化 • 情報隠蔽 • パッケージ化 • 関心の分離 • 充足性、完全性、プリミティブ性 • ポリシーと実装の分離 • インターフェイスと実装の分離 • 参照の一点性 • 分割統治 What 10の根底技法
25. 「機能以外の機能」の観点 「機能面以外全般についての要件」でありソフトウェアが高品質でユーザーの役に立つためには必要 不可欠であるもの • コミュニケーション • シンプル • 柔軟性 アーキテクチャ非機能要件 • 変更容易性 • 相互運用性効率性 • 効率性 • 信頼性 • テスト容易性 • 再利用性 What 10の根底技法
26. コード妥当性レビュー観点 障害を作り込まないように考慮すべきコードの構造上の7つの核心観点のこと。コードビューの時に チェック観点として使用できる。 • コミュニケーション • シンプル • 柔軟性 7つの設計原理 • 単純原理 • 同型原理 • 対称原理 • 階層原理 • 線形原理 • 明証原理 • 安全原理 What 7つの設計原理
27. 目次 第１章　前提〜プログラミングの変わらぬ真実〜 第２章　原則〜プログラミングのガイドライン〜 第３章　思想〜プログラミングのイデオロギー〜 第４章　視点〜プログラマの見る角度〜 第５章　習慣〜プログラマのルーティーン〜 第６章　手法〜プログラマの道具箱〜 第７章　法則〜プログラミングのアンチパターン〜
28. 第７章　法則〜プログラミングのアンチパターン〜 ソフトウェア開発において陥りやすい「罠」に関するプリンシプル。ソフトウェア開発の歴史のなか で導き出された否定的な結果を持つ経験則で、アンチパターンと呼ばれる。 • ブルックスの法則 • コンウェイの法則 • 割れた窓の法則 • エントロピーの法則 • 80-10-10の法則 • ジョシュアツリーの法則 • セカンドシステム症候群 • 車輪の再発明 • ヤクの毛刈り
29. ブルックスの法則
30. コンウェイの法則
31. 割れた窓の法則
32. エントロピーの法則
33. コードの腐敗の兆候 • 硬さ • 脆さ • 移植性のなさ • 扱いにくさ • 複雑さ • 繰り返し • 不透明さ
34. 80-10-10の法則
35. ジョシュアツリーの法則
36. セカンドシステム症候群
37. 車輪の再発明
38. ヤクの毛刈り
39. ご清聴ありがとうございました