忙しい人のためのClean Architecture

Transcript

1. #codepolaris Clean Architectureって何？っていうの を開発者たちが考えてみた
 yuriemori しの ねこさいん
2. #codepolaris Clean Architecture（本）の紹介
 Robert C. Martin 色んなソフトウェア設計原則を提唱したりアジャイル開発宣言の創設に 携わった人。通称Uncle Bob Clean Architecutureはボブおじさんのエンジニア人生で辿り着いた ”いい感じのアーキテクチャ”とはどういうものか、って話。
3. #codepolaris 今日は何を話すのか
 • Clean Architectureを読み終わって、本読んだり議論したり実際に実装したりしてみ ながらなんとなく「こういうもの」というのがわかったので要点をお話します（詳細は 次のAgendaのスライドに！）。 • 「そんなんクリーンアーキテクチャじゃない！解釈違いじゃ！」って意見も大歓迎で す（でもお手柔らかにお願いします）。
4. #codepolaris Agenda
 • チームメンバー紹介 • Clean Architectureって結局何なの？ • あるあるな誤解 ◦ Clean Architecture≠あのドーナツのアーキテクチャモデル ◦ Clean Architecture≠SOLID • Clean Architecture的に考える幸福度の高い実装 ◦ SOLIDの話 ◦ JavaのSpringフレームワークを使った SOLIDの実装（live coding）by しのさん • Agile/DevOpsから考えるClean Architecture ◦ DevOpsから考えるClean Architecture ◦ Agileとアーキテクチャ
5. #codepolaris チームメンバーの紹介

6. #codepolaris • Software Engineer@Avanade Jappan • C#, Azure, .Netなどなど • 今のPJではSitecoreというCMSを使った設計、開発をやってます • Agile/DevOps • Azure DevOpsを使ったスクラムの実践やチーム開発環境の構築 ・運用をテーマに登壇したりしてます 今までの登壇資料はコチラ 森　友梨映（Yurie Mori） @1115_lilium https://www.linkedin.com/in/yurie-mori-15392a1bb/
7. #codepolaris 自己紹介
 名前:しの • 金融系の会社でJavaエンジニア5年目 (Java大好き) • 結婚後に大学に入りなおしてエンジニアになる • 輪読会中に妊娠→育休→仕事復帰 • あまり頑張りすぎないをモットーに、 ゆるゆるエンジニアを楽しんでいます • 趣味はボードゲーム 輪読会中の様子 生Uncle Bob
8. #codepolaris 自己紹介
 名前：ねこさいん • 薬学生→エンジニア (予定) • 普段はPythonを使っている • 好物：お刺身とコーヒーと紅茶 • 趣味：最近スプラ3にハマっている • 一言：クリーンアーキテクチャどころか 　　「オブジェクト指向なにそれおいしいの」 　　　状態でしたが、 　　　居心地がよかったので居座りました。 ◦ 競技プログラミング (AtCoder) ◦ 研究 (薬のもとになる物質探し ) ◦ 学生ハッカソン、ISUCON等参加
9. #codepolaris Clean Architectureって結局何なの？

10. #codepolaris アーキテクチャ というかそもそもアーキテクチャって何
 クラス（ソースコードレベルでのモジュール）> < コンポーネント （デプロイの単位。.Netのdll, Javaの.jar） < アーキテクチャ コンポーネント クラス
11. #codepolaris アーキテクチャは何のために？
 アーキテクチャの形状の目的は、そこに含まれるソフトウェアの開発・デプロイ・運用・保守を容易にすることで ある。 アーキテクチャの主な目的は、システムのライフタイムをサポートすることである。優れたアーキテクチャがあれ ば、システムを容易に理解・開発・保守・デプロイできる。最終的な目的は、システムのライフタイムコストを最小 限に抑え、プログラマの生産性を最大にすることである。 （第13章 アーキテクチャとは？）
12. #codepolaris ソフトウェアの人生
 アーキテクチャの主な目的は、 システムのライフタイム をサポートすることである。 ライフタイム=寿命 ソフトウェアの人生： 開発（設計・実装）→テスト→デプロイ→リリース→運用・保守 いいアーキテクチャ =開発しやすい、テストしやすい、デプロイしやすい、運用・保守しやすい →ソフトウェア開発の全てのライフサイクルで幸せになれるようなアーキテクチャ
13. #codepolaris どうしたら幸せになれる？
 開発（設計・実装）→テスト→デプロイ→リリース→運用・保守 よい設計をするための指標 ・SOLID よい実装をするための指標： ・KISS(Keep It Short, Simple) ・ YAGNI(Your Ain’t Going to Need It) ・ DRY(Don’t Repeat Yourserf) ・ よい命名 etc. デプロイが容易な単位に コンポーネント化されている ・再利用・リリース等価の原則 ・閉鎖性共通の原則 ・全再利用の原則 etc. ・依存関係があんまりない ・デプロイ、リリース作業自体が 簡単 ・デプロイ、リリース作業後に事 故らない ・どこを直せばいいかすぐわかる ・修正する時に他への影響範囲が少 ない ・機能追加しやすい ・テストが簡単 ・テストの範囲はできるだけ狭い 方が嬉しい ・適切にモジュール分けされている
14. #codepolaris まとめ
 クリーンアーキテクチャ= ソフトウェアライフサイクルを通して幸福度高く開発、デプロイ、 保守、運用しやすいアーキテクチャ
15. #codepolaris ありそうな誤解

16. #codepolaris このドーナツの図 ≒ クリーンアーキテクチャ

17. #codepolaris • ソフトウェアを開発する上で一番重要な のはビジネスルール（Entity）で、DBとか UIとかデバイス、それとビジネスロジック とのインターフェイス はソフトウェアの 「外」の要素だから、それに依存してはい けない • Entityとそれより外部にある要素は制御 の流れと依存関係が適切に分離されて いるべき これはEntityとそれに関係ない外部の要素 を切り分けて依存関係を分離せよ、と言って いて、この図=クリーンアーキテクチャのモ デルそのものではない
18. #codepolaris 決定を遅らせる
 ソフトウェアアーキテクチャとは、境界線を引く技芸である。（中略）ソフトウェアの要素を分離し、お互 いのことがわからないように制限するというものである。 逆に、なかなか境界線を引かないこともある。初期に境界線を引くのは、 決定をできるだけ遅らせる ためである。決定によってビジネスロジックが汚染されないようにしているのだ。 アーキテクトの目的は、求められるシステムを構築・維持するために必要な人材を最小限に抑えるこ とである。こうした人々のパワーを奪うものは何か？そ れは結合である。それも早すぎる決定との結 合である。 早すぎる決定とはどのようなものか？それは、 システムのビジネス要件（ユースケース）と関係のない 決定である。たとえば、フレームワーク、データベース、ウェブサーバー、ユーティリティライブラリ、 DI などに関する決定が含まれる。
19. #codepolaris SOLID≒クリーンアーキテクチャ
 • SOLIDの前にアーキテクチャの構成を思い出してみよう • クラス（ソースコードレベルでのモジュール）< コンポーネント（デプロイの単位。.Net のdll, Javaの.jar）< アーキテクチャ • SOLIDはあくまでもシステムのクラスの設計でよい設計をサポートするもの
20. #codepolaris まとめ
 あのドーナツの図で言いたいこと=本質的な部分（ビジネスロジック）はそれ以外の要素 （フレームワーク, DB, UI）に依存するような設計をしてはいけない →DBとかフレームワークとかUIとかを先に決めると後々身動きができなくなる SOLIDはあくまでもクラスのレイヤーで考慮すべきもの。
21. #codepolaris SOLIDの基本

22. #codepolaris SOLIDとは
 
 ボブおじさんが考えたクリーンアーキテクチャの為のガイドライン これに沿って開発したらいい感じにクリーンアーキテクチャの思想に沿った開発ができる
23. #codepolaris SOLID原則
 
 項目 意味 英語 S 単一責任の原則 (SRP:Single Responsibility Principle) O オープン・クローズドの原則 (OCP:Open-Closed Principle) L リスコフの置換原則 (LSP:Liskov Substitution Principle) I インターフェイス分離の原則 (ISP:Interface Segregation Principle) D 依存関係逆転の原則 (DIP:Dependency Inversion Principle)
24. #codepolaris S:単一責任の原則
 (SRP:Single Responsibility Principle)
 There should never be more than one reason for a class to change. （→変更するための理由が、一つのクラスに対して一つ以上あってはならない） 一つのクラスは一つの機能のみを担当する
25. #codepolaris O:オープン・クローズドの原則 (OCP:Open-Closed Principle)
 software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. （→ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれている べきであり、修正に対して閉じていなければならない） ある機能の追加などがある場合、既存のコードを変更せずにその機能の追加(拡張)が 出来るように設計をするべし
26. #codepolaris L:リスコフの置換原則 
 (LSP:Liskov Substitution Principle)
 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. （→ある親クラスへのポインタないし参照を扱っている関数群は、その子クラスのオブ ジェクトの詳細を知らなくても扱えるようにしなければならない） サブタイプ(S)とスーパータイプ(T)は「S is a T」の原則にのっとり、置換可能である
27. #codepolaris I:インターフェイス分離の原則
 (ISP:Interface Segregation Principle)
 Many client-specific interfaces are better than one general-purpose interface. （→汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェース がたくさんあった方がよい） クライアントが、自分の必要な要素だけを継承できるするようにするべき 一つのインターフェースに沢山の要素が入っていると、あるクライエントにとっては必要 のないものが継承されるということが起きるから
28. #codepolaris D:依存関係逆転の原則
 (DIP:Dependency Inversion Principle)
 High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces), [not] concretions. （→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方と も具象ではなく、抽象（インターフェースなど）に依存するべきである） 外側のクラスが内側のクラスに依存するようなことはしてはいけない (インターフェースを経由すると、依存関係を断ち切ることが出来るのでこの本で推奨さ れているが、アノテーションを使うことでも回避できる)
29. #codepolaris クリーンアーキテクチャ的に考える
 幸福度の高い実装

30. #codepolaris Javaのコードを介して実際に見てみよう
 Javaのannotationやデザインパターンを使ってクリーンアーキテクチャの思想に則った コードを実装してみる 
 使用するフレームワーク • Spring Framework • Lombok • JPA/Hibernate
31. #codepolaris 今回のテーマ
 1. アカウントの開設 ◦ 違うタイプのアカウントが開設できる 2. 預金 ◦ BankCode,BankBranch, AccountNumberでアカウントの特定をする ◦ 預金できるアカウントとできないアカウントがある ▪ BasicAccountとSavingAccountは預金ができる ▪ SuperSavingAccountは預金が出来ない オンライン銀行口座サイトを実装せよ！
32. #codepolaris annotation(アノテーション)ってそもそも何？
 処理系に伝達したい付加的な情報(メタデータ)を注記する 「ここはこういう役割」「こういう処理をしてね」ということをコンパイル中や実行中にコン ピューターに伝えることができる 基本、@....　という形でメタデータを使用したい場所にくっつけることで使える 例: @Controllerのアノテーションを付けると、そのクラスはWebサービスになり、外部と の接続が可能になる
33. #codepolaris どんなデザインパターンを使う？
 ❖ DTO (Data Transfer Object) とVO (Value Object) ➢ データ受け渡しの為のクラス ➢ DTOがエコバッグ的な存在、 VOが段ボールで蓋された荷物的な存在 ❖ Factory Pattern ➢ フレキシブルにインスタンスの生成をするためのデザインパターン ➢ インスタンスの生成をファクトリー (=工場)に任せる ❖ Builder Pattern ➢ インスタンスの生成をコンストラクターに頼らずに出来る ➢ 将来attributeが増えていっても、今あるインスタンス生成の為のコードは壊れずに使える
34. #codepolaris Spring とは
 Javaでよく使われる基本のWEBフレームワーク　(https://spring.io) MVCでの開発や、依存性注入(dependency injection)、セキュリティなど、ありとあらゆ る事が簡単に出来る
35. #codepolaris Lombokとは
 形式上省くことが難しいけどあると冗長になるコード(ボイラープレートコード)を省くことが できる • getter/setter • constructor • toString • builder etc…
36. #codepolaris Hibernate (JPA)とは
 オブジェクトとリレーショナルデータベース(RDB)の相互変換を行うマッパー オブジェクトとテーブルのマッピングを行ってくれる -> DAOの実装に関してのデータベースの種類への依存がなくなる
37. #codepolaris Controllerで使われるannotation
 Controllerは外部との接続を担当 リクエストを受け取って、レスポンスを返す (基本はクラスをJSONに変換したものが返さ れる) ❖ @Controller, @RestController ➢ そのクラスはWebサービスになり、外部との接続を行う ❖ @RequestMapping(“/bankAccount”) ➢ http://localhost:8080/bankAccount で接続が出来るようになる ❖ @PostMapping, @GetMapping, @PutMapping etc… ➢ RequestMappingの、http メソッドを指定
38. #codepolaris 各クラスの役割
 • BankAccount ◦ BasicAccount や SavingAccount の親クラス • BankAccountRepository (@Repository) ◦ DBへの接続 • BankAccountController (@Controller) ◦ 外部への接続 • BankAccountService (@Service) ◦ ビジネスロジック (仲介業者的な)
39. #codepolaris 今回のテーマ
 1. アカウントの開設 ◦ 違うタイプのアカウントが開設できる 2. 預金 ◦ BankCode,BankBranch, AccountNumberでアカウントの特定をする ◦ 預金できるアカウントとできないアカウントがある ▪ BasicAccountとSavingAccountは預金ができる ▪ SuperSavingAccountは預金が出来ない オンライン銀行口座サイトを実装せよ！
40. #codepolaris 復習
 ❖ BankAccount とBasicAccount, SavingAccountは置換可能である ➢ リスコフの置換原則 ❖ Repository, Controller, Service, Factory などでそれぞれ一つのことを担当 ➢ 単一責任の原則 ❖ Depositableを継承するのはdepositのメソッドが必要なクラスのみ ➢ インターフェース分離の原則 ❖ FactoryやBuilderのデザインパターン ➢ オープンクローズドの原則 ❖ @Autowiredを使って、上位モジュールでの直接のインスタンス生成を避ける ➢ 依存性逆転の原則
41. #codepolaris まとめ
 フレームワークの想定している使い方をすれば、自動的にSOLIDに対応される なのでそこまで難しく考えなくていい Spring のフレームワークはめっちゃ優秀なので、フレームワークの勉強はしっかりしま しょう フレームワークでカバーしきれない部分(リスコフの置換原則とかインターフェース分離 の原則とか)もあるので、SOLIDを意識しておくと、綺麗なコードになる
42. #codepolaris Agile/DevOpsから考える
 クリーンアーキテクチャ

43. #codepolaris DevOpsから考えるClean Architecture

44. #codepolaris ソフトウェアの人生とDevOps
 • 開発(Devs)と運用(Ops)がコラボして無駄のない(Lean)ソフトウェア開発をしようね というカルチャー、思想 • DevOps=開発、運用、品質保証の集合 開発（設計・実装）→テスト→デプロイ→リリース→運用・保守 この辺ぐらいがDevの領域 この辺ぐらいがOpsの領域
45. #codepolaris 思い出して、アーキテクチャとは？アーキテクチャの目的は？
 • アーキテクチャの主な目的は、 システムのライフタイムをサポートすること である。優れたアーキテクチャ があれば、システムを容易に理解・開発・保守・デプロイできる。 • 作ったら（開発が終わったら） デプロイして、リリースして、リリースした後もちゃんと動くようにしないといけ ない（保守）、必要であれば、機能を追加してアップデートしたり修正 しないといけない（運用） クラス（ソースコードレベルでのモジュール）< コンポーネント（デプロイの単位。.Netのdll, Javaの.jar）< アーキテクチャ ソフトウェアの人生：開発（設計・実装） →テスト→デプロイ→リリース→運用・保守 ・開発した後もデプロイ、リリース、運用、保守がしやすければソフトウェアの人生全体をサポートできる ・では、デプロイ、リリース、運用、保守のしやすさはどうやって達成できる？ →その鍵はコンポーネント（デプロイの単位）
46. #codepolaris SOLIDを超えて
 コンポーネントとは、デプロイの単位である。システムの一部としてデプロイできる。（第 12章　コンポーネント） SOLID原則がレンガを組み合わせて壁や部屋を作る方法を伝えている原理だとするな らば、コンポーネントの原則は部屋を組み合わせて建物を作る原則である。大規模建築 と同様に、大きなソフトウェアシステムは小さなコンポーネントを組み合わせて作られて いる。（第IV部　コンポーネントの原則） SOLIDは綺麗なクラス（プログラム）を作る、クラスを組み合わせるとコンポーネント（デプロイの単位）になる、コンポーネン トの組み合わせでソフトウェアシステムができる。 →ソフトウェアアーキテクチャは最適な部品分け、組み合わせのアート
47. #codepolaris デプロイ、リリース、運用、保守の苦しみ
 • デプロイ手順が複雑でデプロイのコストが高い • リリースしたいのはこれだけなのに依存関係の複雑さのせいであれもこれもデプロ イ資源にいれないといけない(´;ω;｀) • 修正したいのはここだけなのに依存関係の複雑さのせいでry) • 修正しないといけない場所、、、どこ、、、、？（ソースコードが汚いor適切にクラス分 けされてなくてbug fixに時間が掛かる） • テストコード、、、、Code Coverage、、、、
48. #codepolaris デプロイ、運用、保守のためにアーキテクチャはどうあるべき？
 • デプロイ デプロイのコストが高ければ、その分だけシステムの有用性は低下する。ソフトウェアアーキテクチャの目的は、システムを単一のア クションで簡単にできるようにすることである。 • 運用 システムの運用ニーズを伝えるというものだ。アーキテクチャが優れていれば、システムの運用方法は開発者が見ればすぐにわか る（中略）つまり、アーキテクチャが運用方法を明らかにするのである。 • 保守 保守の主なコストは、洞窟探検とリスクだ。システムを安定したインターフェイスを持つ独立したコンポーネントに分離しておけば、将 来の機能の道筋が照らされ、意図せずに壊してしまうリスクを大幅に軽減できるだろう。 第15章　アーキテクチャ
49. #codepolaris コンポーネントはどうあるべき？
 • デプロイ手順が複雑でデプロイのコストが高い →Pipeline作ってCI/CD環境を整える • リリースしたいのはこれだけなのに依存関係の複雑さのせいであれもこれもデプロ イ資源にいれないといけない(´;ω;｀) • 修正したいのはここだけなのに依存関係の複雑さのせいでry) • 修正しないといけない場所 is どこ、、、、？（ソースコードが汚いor適切にクラス分 けされてなくてbug fixに時間が掛かる） →コンポーネント（デプロイの単位）の切り分けが適切ではないのかも？
50. #codepolaris 再利用・リリース等価の原則(REP)
 • 再利用の単位と、リリースの単位は等価になる。 • ひとつのコンポーネントを形成するクラスやモジュールは、まとめてリリース可能で なければならない。 第13章　コンポーネントの凝集性
51. #codepolaris 閉鎖性共通の原則（CCP）
 • 同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更 の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。 • SOLIDの単一責任の原則(SRP)をコンポーネント向けに言い換えたもの。SRPは 「クラスを変更する理由が複数あるべきでない」という原則だったが、CCPは「コン ポーネントを変更する理由が複数あるべきではない」と説いている。 第13章　コンポーネントの凝集性
52. #codepolaris 全再利用の原則(CRP)
 • コンポーネントがユーザーに対して、実際には使わないものへの依存を強要しては いけない。 • CRPはインターフェイス分離の原則(ISP)を一般化したもの。ISPは使っていないメ ソッドを持つクラスに依存しないように伝えている。 • CRPは、使っていないクラスを持つコンポーネントに依存しないように伝えている。 • 不要なものには依存しないこと。 第13章　コンポーネントの凝集性
53. #codepolaris まとめ
 • 開発した後もデプロイ、リリース、運用、保守がしやすければソフトウェアの人生全体をサポート できる • DevOps的に幸福度高いアーキテクチャにするためにはコンポーネント（デプロイの単位）の分 け方が鍵 • SOLIDは綺麗なクラス（プログラム）を作る、クラスを組み合わせるとコンポーネント（デプロイの 単位）になる、コンポーネントの組み合わせでソフトウェアシステムができる。
54. #codepolaris Agileとアーキテクチャ

55. #codepolaris アジャイルって設計フェーズっ てないよね？ 設計ってどうすんの？ アジャイルだと短いスパンで継続的 にリリースしていかなきゃいけない。 そんな短い期間でいいアーキテク チャってどう作ればいいの？ 1sprint(1 week- 1 month)で ちゃんとしたアーキテクチャつく るの無理ゲーでは？
56. #codepolaris クリーンではない（腐敗した）アーキテクチャ(1/2)
 硬さ 変更しにくい。1つ変更するとあっちもこっちも変えないといけない。 もろさ ここを変えるとあっちもこっちも（変更箇所と関係ない所）壊れる、、、、 移植性のなさ ここって他でも流用できるんじゃない？って所があるのに、オリジナルの場所から切り離すことに大きなリスクがある。
57. #codepolaris クリーンではない（腐敗した）アーキテクチャ(2/2)
 
 扱いにくさ 正しいやり方よりも誤ったやり方でやる方が簡単（ソフトウェア、開発環境両方とも） 不必要な複雑さ これ意味ある？って感じの構造を内包している。（クラスの中に複数のクラス、メソッドの中に複数のよくわらかないメソッド） 不必要なくり返し コードのコピペ、、、、 不透明さ 読みにくい。わかりにくい。（スパゲティコード） アジャイルソフトウェア開発の奥義　　第 2章　アジャイル設計
58. #codepolaris アジャイルにおけるクリーンなアーキテクチャの作り方
 • どうしてアジャイルでは設計フェーズがないの？ →どうせ変わるから。 • じゃあどうやってシステムの設計をクリーンに保つの？ →DoD(完成の定義)、Acceptance Criteria（受け入れ条件）を明確に決めて、必要であ ればアップデートする。頻繁にUT（単体テスト）やAT（受け入れテスト）をやる。（最初に DoDやAcceptance Criteriaを満たすテストを設計して、それを満たすように開発する （TDD））
59. #codepolaris アジャイルにおけるクリーンなアーキテクチャの作り方
 
 • 先を見越して複雑なことを考えない。DoDやAcceptance Criteriaを満たす最もシン プルな方法で実装。 • SOLIDやコンポーネントの原則（やるべき事を最小の単位で分離して、不必要な依 存が発生しないようにする）に沿って考えると、先の難しいことは考えず、オブジェク ト単位でシンプルに実装できる。難しい設計とかは部品になるモジュールやコン ポーネントができてから考えればいい。
60. #codepolaris Agileの経験主義と創発的アーキテクチャ
 • Waterfall：最初にしっかり分析して計画したから後はこれを計画通りにやればヨ シ！（理性主義） • Agile: 人間そんな先のことまでわからないから、見通しが立てられそうな小さい単 位に分割してやってみて、やってみて改善が必要だったら対応していこう（経験主 義） ・Sprint単位での目標設定、計画、開発 ・SOLIDに沿ったクラス単位での開発（まずはアーキテクチャを構成する最小の部品をちゃんと 作る）→コンポーネントに結合 →アーキテクチャの創発 (Emergent Architecture)
61. #codepolaris まとめ
 • 見通しができる小さい単位に分割して、DoDやAcceptance Criteriaを満たすように 作っていく。 • 最初はアーキテクチャの構成の最小の単位（クラス・モジュール）をSOLIDの原則 に沿うように作る（最小の部品をちゃんと作る） • 作ったものは継続的にテストをして、常にリリース可能な状態にする • 最小の部品（クラス）を作る→それを組み合わせてコンポーネントを作る　という流 れをsprintを重ねて作っていく • それを繰り返すとアーキテクチャが”現れる”（Emergent Architecture :創発的アー キテクチャ)
62. #codepolaris さいごに

63. #codepolaris アーキテクチャとアーキテクトは何の為に？
 • アーキテクトの目的は、求められるシステムを構築・維持するために必要な人材を最小限に抑える こ とである。 • ソフトウェアアーキテクチャとは、 境界線を引く技芸 である。ソフトウェアの要素を分離し、お互いのこ とがわからないように制限する というものである。 • アーキテクチャの形状の目的は、そこに含まれるソフトウェアの開発・デプロイ・運用・保守を容易に することである。
64. #codepolaris メンバーによる輪読会やってみての感想
 ・クリーンアーキテクチャの概念が知れてよかった。 　現役エンジニアとお話しして、働くイメージをつかめた。（by ねこさいん） ・他社のエンジニアと実際の業務でエンカウントしがちな設計の問題についてディスカッ ションできた（byしの） ・自分が見てきた運用しにくい&バグが出てきそうな設計をどう改善すればいいかイメー ジが持てた。コードがそこそこ書ける→保守・運用も想定したいい設計のイメージが持て て若干エンジニアとして視座が高まった気がする(by yurie)
65. #codepolaris References
 • Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://amzn.asia/d/fPVihGj • プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 P13. よい実装をするための指標 (KISS, YAGNI, DRYについて書かれてる） https://amzn.asia/d/7hydTCq • DevOpsとアジャイルの比較 P35. ソフトウェアの人生と DevOps https://azure.microsoft.com/ja-jp/overview/devops-vs-agile/ • アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技 P44- Agileとアーキテクチャ　https://amzn.asia/d/cudAF5n • Emergent Architecture: Architecture in the Age of Agile P50. アジャイルの経験主義と創発的アーキテクチャ　 https://medium.com/@steve.cornish/emergent-architecture-architecture-in-the-age-of-agile-9f21ba654845