プリンシプルオブプログラミング ~3章(Unix除く)と7章~

2021/01のはじめてのIT勉強会のメイントーク資料です。
https://lets-go-study-meeting.connpass.com/event/199511/

1. The Principles of Programing
2. Speaker ERPパッケージの開発→モバイルオーダー Go / Java / AWS (SAA) GitHub : @Hiroya3 Name : Hiroya Terui
3. The Principles of Programing • 第1章 前提 ~プログラミングの変わらぬ真実~ • 第2章 原則 ~プログラミングのガイドライン~ • 第3章 思想 ~プログラミングのイデオロギー~ • 第4章 視点 ~プログラマの見る角度~ • 第5章 習慣 ~プログラマのルーティン~ • 第6章 手法 ~プログラマの道具箱~ • 第7章 法則 ~プログラミングのアンチパターン~
4. The Principles of Programing • 第1章 前提 ~プログラミングの変わらぬ真実~ • 第2章 原則 ~プログラミングのガイドライン~ • 第3章 思想 ~プログラミングのイデオロギー~ • 第4章 視点 ~プログラマの見る角度~ • 第5章 習慣 ~プログラマのルーティン~ • 第6章 手法 ~プログラマの道具箱~ • 第7章 法則 ~プログラミングのアンチパターン~
5. The Principles of Programing • 第1章 前提 ~プログラミングの変わらぬ真実~ • 第2章 原則 ~プログラミングのガイドライン~ • 第3章 思想 ~プログラミングのイデオロギー~ • 第4章 視点 ~プログラマの見る角度~ • 第5章 習慣 ~プログラマのルーティン~ • 第6章 手法 ~プログラマの道具箱~ • 第7章 法則 ~プログラミングのアンチパターン~
6. 4つのテーマを扱っています • プログラミングセオリー • アーキテクチャ根底技法 • アーキテクチャ非機能要件 • 7つの設計原則
7. プログラミングセオリー コードを書く人としては 「より良いコード」「最高のコード」を 書きたいもの
8. プログラミングセオリー 「より良いコード」「最高のコード」 とは
9. プログラミングセオリー 拡張方法が多く存在する 余分な要素が存在しない 読みやすい 理解しやすい
10. プログラミングセオリー そんなコードを書くために意識しすべき3つの価値がある
11. プログラミングセオリー 価値 コミュニケーション シンプル 柔軟性
12. プログラミングセオリー 価値 コードは コミュニケーション ツール シンプル 柔軟性
13. プログラミングセオリー 価値 コードは コミュニケーション ツール 何をしているコードか 分かりやすいように 柔軟性
14. プログラミングセオリー 価値 コードは コミュニケーション ツール 何をしているコードか 分かりやすいように コードは 変更されるもの →変更しやすいように
15. プログラミングセオリー 価値 コミュニケーション シンプル 柔軟性 ＞ ＞
16. プログラミングセオリー 「価値」って抽象的だよねってことで 「原則」も6つある
17. プログラミングセオリー 原則 結果の局所化 繰り返しの最小化 ロジックとデータの 一体化 対称性 宣言型の表現 変更頻度
18. プログラミングセオリー 原則 変更の影響を最小に →関連するコードをまとめる 繰り返しの最小化 ロジックとデータの 一体化 対称性 宣言型の表現 変更頻度
19. プログラミングセオリー 原則 変更の影響を最小に →関連するコードをまとめる 重複ロジックの排除 →コードの分割/関数化 ロジックとデータの 一体化 対称性 宣言型の表現 変更頻度
20. プログラミングセオリー 原則 変更の影響を最小に →関連するコードをまとめる 重複ロジックの排除 →コードの分割/関数化 ロジックと操作されるデータは 同じ関数やモジュールに 対称性 宣言型の表現 変更頻度
21. プログラミングセオリー 原則 変更の影響を最小に →関連するコードをまとめる 重複ロジックの排除 →コードの分割/関数化 ロジックと操作されるデータは 同じ関数やモジュールに 同質なものは コードのどの場所でも 同じ振る舞いをする 宣言型の表現 変更頻度
22. プログラミングセオリー 原則 変更の影響を最小に →関連するコードをまとめる 重複ロジックの排除 →コードの分割/関数化 ロジックと操作されるデータは 同じ関数やモジュールに 同質なものは コードのどの場所でも 同じ振る舞いをする データフローをなくし シンプルに表現する 変更頻度
23. プログラミングセオリー 原則 変更の影響を最小に →関連するコードをまとめる 重複ロジックの排除 →コードの分割/関数化 ロジックと操作されるデータは 同じ関数やモジュールに 同質なものは コードのどの場所でも 同じ振る舞いをする データフローをなくし シンプルに表現する 修正タイミングが近いものは まとめる
24. 価値や原則はここまで
25. 続きまして アーキテクチャ根底技法
26. アーキテクチャ根底技法 アーキテクチャ根底技法とは 「良いソフトウェア・アーキテクチャ構築のための基礎原理」
27. アーキテクチャ根底技法 • 抽象 • カプセル化 • 情報隠蔽 • パッケージ化 • 関心の分離 • 充足性、完全性、プリミティブ性 • ポリシーと実装の分離 • インターフェイスと実装の分離 • 参照の一点性 • 分割統治
28. アーキテクチャ根底技法 抽象化 低レベルアクセスへの入り口（ 1）：io.Writer(https://ascii.jp/elem/000/001/243/1243667/)
29. アーキテクチャ根底技法 情報隠蔽 / インターフェイスと実装の分離 必要のないものは見せない →シンプルな機能のみを公開
30. アーキテクチャ根底技法 カプセル化 / パッケージ化 / 関心の分離 ユーザー登録 ユーザー情報 更新 ユーザー情報 削除 モジュールB モジュールA パッケージ
31. アーキテクチャ根底技法 充足性、完全性、プリミティブ性
32. アーキテクチャ根底技法 コレクションであれば • 充足性 ◦ add() ◦ remove() • 完全性 ◦ size() • プリミティブ性（純粋性） ◦ add10()はいらない
33. アーキテクチャ根底技法 ポリシーと実装の分離
34. アーキテクチャ根底技法 ポリシー：ソフトウェアの前提に依存するビジネスロジック つまり可変である
35. アーキテクチャ根底技法 実装：ソフトウェアの前提に依存しない、独立したロジック 不変（≒再利用可能）である
36. アーキテクチャ根底技法 参照の一点性
37. アーキテクチャ根底技法 定義は一度きり&「単一代入」 →値の再代入を行わない
38. アーキテクチャ根底技法 https://play.golang.org/p/Gp5ThDwY7pb
39. アーキテクチャ根底技法 分割統治
40. アーキテクチャ根底技法 https://qiita.com/ken5scal/items/5f3e93ea9a2602d7cc0a
41. アーキテクチャ非機能要件 続いて アーキテクチャ非機能要件
42. アーキテクチャ非機能要件 アーキテクチャ非機能要件とは 「機能面以外全般についての要件」であり ソフトウェアが高品質でユーザーの役に立つためには必要不可欠であるもの
43. アーキテクチャ非機能要件 • 変更容易性 • 相互運用性効率性 • 効率性 • 信頼性 • テスト容易性 • 再利用性
44. アーキテクチャ非機能要件 変更容易性 F A機能 F B機能 B B機能 B A機能 がっちり密結合 F A機能 F B機能 B B機能 B A機能
45. アーキテクチャ非機能要件 プロトタイプからの製品化で 密結合が長らく鎮座してしまうことがある
46. アーキテクチャ非機能要件 相互運用性 APIエコノミーの現状と今後の期待 (https://www.slideshare.net/rasmusekman/api-54896752)
47. アーキテクチャ非機能要件 効率性 https://tatsu-zine.com/books/gcbook O(n)
48. アーキテクチャ非機能要件 信頼性 コードではないですが、、 Auto Acaling Load Balancing
49. アーキテクチャ非機能要件　　　　　　　　テスト容易性 質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition (https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=3) https://www.amazon.co.jp/%E3%83%86%E3%82%B9%E3%83%88% E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA-Kent-Beck/dp/4 274217884
50. アーキテクチャ非機能要件 再利用性
51. 7つの設計原則 続いて 7つの設計原則
52. 7つの設計原則 コードレビューの時にどこに着目していますか？
53. 7つの設計原則 • 単純原理 • 同型原理 • 対称原理 • 階層原理 • 線形原理 • 明証原理 • 安全原理
54. 7つの設計原則 単純原理 Simple is best
55. 7つの設計原則 同型原理 / 安全原理 https://play.golang.org/p/TZj4zGBxFgI
56. 7つの設計原則 対称原理 flg立っていない時は どうするか
57. 7つの設計原則 階層原理 同じものは同じ階層に配置する 処理は同階層で完結させる root - A - A’ - B A’でコネクションをはったら A’内でクローズしてあげる
58. 7つの設計原則 線形原理 分岐をなるべく挟まず 上から下に一直線に流れるコードが 単純明快 処 理 の 流 れ
59. 7つの設計原則 明証原理 results = Database.all_objects.filter(“year <= 2011”) year <= 2011 であるオブジェクト? でないオブジェクト? 出典：リーダブルコード 3章 誤解されない名前
60. The Principles of Programing • 第1章 前提 ~プログラミングの変わらぬ真実~ • 第2章 原則 ~プログラミングのガイドライン~ • 第3章 思想 ~プログラミングのイデオロギー~ • 第4章 視点 ~プログラマの見る角度~ • 第5章 習慣 ~プログラマのルーティン~ • 第6章 手法 ~プログラマの道具箱~ • 第7章 法則 ~プログラミングのアンチパターン~
61. 法則 ~プログラミングのアンチパターン~ いよいよ最後のパートです
62. 法則 ~プログラミングのアンチパターン~ • ブルックスの法則 • コンウェイの法則 • 割れた窓の法則 • エントロピーの法則 • 80-10-10の法則 • ジョシュアツリーの法則 • セカンドシステム症候群 • 車輪の再発明 • ヤクの毛刈り
63. 法則 ~プログラミングのアンチパターン~ ブルックスの法則 12人月のプロジェクト 2名で6ヶ月で開始（2✖6=12） 3ヶ月終了時点で納期が1ヶ月後に変更（残り6人月） じゃあ、4人追加して6人でやれば1ヶ月で終わる！
64. 法則 ~プログラミングのアンチパターン~ ブルックスの法則 「じゃあ」 ではないです オワンナイデス
65. 法則 ~プログラミングのアンチパターン~ コンウェイの法則
66. 法則 ~プログラミングのアンチパターン~ 壊れた窓の法則 / エントロピーの法則 エントロピーが「時を戻す悪魔」を倒すまでの 150年におよぶ戦い (https://gendai.ismedia.jp/articles/-/74427)
67. 法則 ~プログラミングのアンチパターン~ よくないコードが「放置される」と 周りのコードも悪くなっていく
68. 法則 ~プログラミングのアンチパターン~ よくないコード？？
69. • 硬さ • 脆さ • 移植性のなさ • 扱いにくさ • 複雑さ • 繰り返し • 不透明さ 法則 ~プログラミングのアンチパターン~
70. 80-10-10の法則 法則 ~プログラミングのアンチパターン~
71. 1つの高性能なツールで開発したとすると 0~80% : 驚くべきほど早く到達する 80~90% : なんとか頑張れば到達できる 90~100%: 100%到達はほど不可能 法則 ~プログラミングのアンチパターン~
72. ユーザーの要求に100%答えられる 万能なツール（万能薬）は存在しない 法則 ~プログラミングのアンチパターン~
73. ジョシュアツリーの法則 法則 ~プログラミングのアンチパターン~
74. 名前がないものは認識できない 法則 ~プログラミングのアンチパターン~
75. 形式知に変換する 法則 ~プログラミングのアンチパターン~
76. 法則 ~プログラミングのアンチパターン~ www.amazon.co.jp/dp/4798046140 www.amazon.co.jp/dp/4873115655
77. セカンドシステム症候群 法則 ~プログラミングのアンチパターン~
78. 法則 ~プログラミングのアンチパターン~ First Release Second Release 必要な リリース内容
79. 車輪の再発明 法則 ~プログラミングのアンチパターン~
80. 法則 ~プログラミングのアンチパターン~
81. 法則 ~プログラミングのアンチパターン~
82. io.Copyが良い感じにやってくれることもある 法則 ~プログラミングのアンチパターン~
83. ヤクの毛刈り 法則 ~プログラミングのアンチパターン~
84. 「タスクを自動化しよう」 「webサーバーで動作するツールにしよう」 「webサーバーをまずダウンロードしよう」 「ファイルが大きくてダウンロードできない」 「ダウンロードツールを入れよう」 「ダウンロードツールが前提モジュールがなくて動かない」 「前提モジュール取得のためにユーザー登録が必要だ」 「ブラウザのバージョンが古くてユーザー登録ができない」 法則 ~プログラミングのアンチパターン~
85. やりたいことからズレている コスパが悪すぎる 作業切り上げの合図 法則 ~プログラミングのアンチパターン~
86. Thank you