河野佳

29.クリーン組込みアーキテクチャ
- ソフトウェアは消耗しないが、管理できていないファームウェアやハードウェアの依存関係により、ソフトウェアが内部から破壊される可能性がある。
- ファームウェアの定義は、格納される場所ではなく、それが何に依存しているのか、ハードウェアの進化に合わせてどれだけ変化しにくいかで決まる。ソフトウェアとファームウェアの境界線は、存在しないのではないかと思えるほどあいまいなことが多い。
- ファームウェアをあまり書かないようにして、寿命を長くする機会をコードに与える。
- プロセッサ抽象化レイヤーやOS抽象化レイヤーで、低レベル機能やOSからソフトウェアを分離する。

28.テスト境界
- テストはアーキテクチャの円の外側にある、テストシステムに独立してデプロイ可能な最も独立したコンポーネントである。
- テストの役割は、開発をサポートすること。
- テストAPIの目的は、UIからテストを切り離すことだけではなく、アプリケーションの構造からテストを切り離すこと。そして、アプリケーションの構造をテストから隠すことが役割。
- テストもうまく設計すべきシステムの一部。システムの一部として設定されていないテストは、脆弱で保守が難しくなる傾向がある。

27.サービス:あらゆる存在
- サービスはシステムのスケーラビリティや開発の利便性に対しては有用だが、アーキテクチャにおいては重要な要素ではない。アプリケーションの振る舞いに分離する、単なる関数呼び出しにすぎない。
- サービスはモノリシックである必要はなく、SOLIDの原則を使用してサービスを設計し、コンポーネントの構造を与えておけば、サービスに含まれる既存のコンポーネントを変更することなく新しいコンポーネントを追加できる。
- サービスはアーキテクチャの境界に囲まれたひとつのコンポーネント、もしくはアーキテクチャの境界に分割された複数のコンポーネントである。

26.メインコンポーネント
- メインコンポーネントとは、その他のコンポーネントを作成・調整・監督するコンポーネントのこと。
- 究極的な詳細(最下位レベルの方針)で、システムの最初のエントリーポイントになる。オペレーティングシステム以外に、このコンポーネントに依存しているものはない。
- 初期状態や構成を設定して、外部リソースを集めてアプリケーションの上位レベルの方針に制御を渡すプラグインと考えることもできる。例えば、開発用、テスト用、本番用、デプロイする国別、権限別、顧客別などの設定ごとのメインコンポーネントを持つこともできる。

25.レイヤーと境界
- アーキテクチャの境界はあらゆるところに存在する。境界を完全に構築しようとするとコストが高くつき、無視しようとするとレイヤーを追加するコストが非常に高くなる。
- 抽象化が必要になることを予測してはいけない(YAGNIの哲学)。アーバーエンジニアリングのほうが、アンダーエンジニアリングよりも悪質である。
- コストを評価し、アーキテクチャの境界がどこにあるか、完全に実装すべきなのか無視した方がいいのか判断する必要がある。これは1回限りではない。常に見張る必要がある。境界を実装するコストと無視するコストを比較検討し、その決定を常に見張り何度も評価する。

24.部分的な境界
- YAGNI(You aren't Going to Need It:あとで必要になることはない)
- 問題に直面している時、「違反しているが、あとで必要になることもある」と考えて、部分的な境界を設定することがある。
- 独立してコンパイルやデプロイが可能なコンポーネントを準備し、それらを同じコンポーネントにまとめる。
- Strategyパターン(完全な境界にする余地を残した、片方だけの構造)
- Facadeパターン(シンプルな境界)
- これらにはそれぞれコストとメリットがある。完全な境界に至るまでの代理として適切な場合もあるが、うまく設定できなければ劣化していく。

23.プレゼンターとHumble Object
- プレゼンターはHumble Objectパターンの一種であり、アーキテクチャの境界の特定と保護に役立つ。
- Humble Objectパターンは、テストしにくい振る舞い(View)とテストしやすい振る舞い(Presenter)を分離するために生み出されたデザインパターン。
- Presenterはアプリケーションからデータを受け取り、適切にフォーマットし、Viewが画面に移動できるようにする。
- アーキテクチャの境界でこのパターンを使用すると、システム全体のテスト容易性が大幅に向上する。

22.クリーンアーキテクチャ
- ヘキサゴナルアーキテクチャ、DCIアーキテクチャ、BCEはいずれも「関心事の分離」という同じ目的を持っている。ソフトウェアをレイヤーに分割することで、実現している。
- ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない。円の内側は外側について何も知らない。
- 制御の流れがどのような方向であっても、依存性のルールに違反しないように動的なポリモーフィズムを活用して、例えばユースケースから円の内側にあるプレゼンターのインターフェイスを呼び出すようにして制御の流れとは反対のソースコードの依存関係を生みだす。

スクラムをうまく回すために受け入れ基準をきちんと書く - SmartHR Tech Blog はじめに こんにちは。12月1日より、プロダクト開発のディレクションを担当している三好と申します。スクラムの役割定義で言うと、プロダクトオーナー（以下PO）がしっくりくるかと思います。 みなさんの開発現場では、スクラムがきちんと機能していますか？ POとスクラムマスター、エンジニアがきちんとコミュニケーションをとって開発を進められていますか？ 今回は、「受け入れ基準をきちんと書くこと」をテーマに本記事を書きます。 背景 弊社は、昨年9月11日に開催したSmartHR Next 2018で、「SmartHR」のプラットフォーム化構想を発表しました。 これに伴い、雇用契約機能や年末調整機能、店舗向

スクラムをうまく回すために受け入れ基準をきちんと書く - SmartHR Tech Blog
tech.smarthr.jp/entry/2019/0…
読んだ

21.叫ぶアーキテクチャ
- 建物の設計図を見ると、どんな建物であるかが見て分かる。つまり、叫んでいる。
- ソフトウェアアプリケーションのアーキテクチャもシステムのユースケースについて叫ぶべきである。
- 優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、ツール、環境に依存することなく、ユースケースをサポートする構造を問題なく説明できる。
- ウェブは提供の仕組み（IOデバイス）であり、アーキテクチャもそのように扱うべき。システム構造を支配するものではない。
- アーキテクチャはフレームワークから距離を置いたものにし、そのままの状態でテスト可能でなければいけない。

20.ビジネスルール
- ビジネスルールはビジネスマネーを生み出したり節約したりするルールや手続きのこと。ビジネスに欠かせないものを最重要ビジネスルールと呼び、これに必要なデータを最重要ビジネスデータと呼ぶ。
- エンティティとはコンピュータシステムのオブジェクトであり、インターフェイスはそうした最重要ビジネスルールを実装した関数を含む。
- ユースケースとは自動化されたシステムを利用する方法を記述したもの。エンティティとは異なり、アプリケーション固有のビジネスルールを含む。システムの入出力に近い。
- ユースケースはエンティティの最重要ビジネスルールをいつ、どのように呼び出すかを規定する。

19.方針とレベル
- ソフトウェアシステムは方針を示したもの。コンピュータプログラムは入力を出力に変換する方針を記述したもので、方針はさらに小さく分割される。
- 同じ理由や時期に変更する方針は同じレベルのコンポーネントにまとめ、下位レベルのコンポーネントが上位レベルに依存するように設計する。
- 「レベル」とは入出力との距離。入出力を管理する方針は最下位レベルになり、そこから離れていればレベルが高くなる。
- 上位レベルの方針は、下位レベルより変更の頻度が低く、変更の理由が重要になる。下位レベルに重要ではないが、緊急の変更があったとしても、上位レベルにはほとんどあるいは全く影響を与えない。

18.境界の解剖学
- 境界の向こう側にある関数呼び出しやデータの受け渡しで、適切に境界を越えるにはソースコードの依存関係を管理する必要がある。
- 下位レベルのクライアントから上位レベルのサービスに対して関数呼出しする。上位レベルのクライアントが下位レベルのサービスを呼び出す場合、制御の流れの依存性の逆転させる。
- アーキテクチャの目標は、下位レベルのプロセスまたはサービスを上位レベルのプロセスまたはサービスのプラグインにすること。
- 境界戦略にはモノリス、デプロイコンポーネント、スレッド、ローカルプロセス、サービスがある。モノリス以外のほとんどのシステムで、複数の境界戦略を使用する。

17.バウンダリー:境界線を引く
- 初期に境界線を引くのは、決定を遅くし、それによりビジネスロジックが汚染されないようにするため。この決定とは、システムのビジネス要件（ユースケース）と関係のないフレームワークやDB、ウェブサーバーなどを指す。
- 境界線は「重要なもの」と「重要ではないもの」の間、変更の軸のあるところに引く。GUIはビジネスルールと異なる時間や頻度で変更され、ビジネスルールはDIフレームワークと異なる時間や理由で変更される。
- UIやDBをプラグインとして扱えば、異なるユーザーインターフェースや異なるDBに置き換えることが可能になる。

16.独立性
- 最も重要なことは、アーキテクチャレベルでシステムの意図が分かるように振る舞いを明らかにすること。
- 単一責任の原則や閉鎖性共通の原則を使用して、異なる理由で変更されるものを分離し、同じ理由で変更されるものをまとめることができる。
- システムをコンポーネントに適切に分割すれば、システムの運用ニーズの変化に合わせて比較的簡単に移行することができる。
- 優れたアーキテクチャは、ソースコードを変更から保護してくれる。切り離し方式を選択肢として残すことで、大規模なデプロイと小規模なデプロイで使用する方式を変えることができる。

15.アーキテクチャとは
- ソフトウェアシステムのアーキテクチャとは、システムに与えた「形状」。形状の目的はソフトウェアシステムの開発・デプロイ・運用・保守を容易にし、プログラマの生産性を最大にすること。
- チームの構成が異なれば、アーキテクチャの決定は異なる。
- ソフトウェアが開発されたのは、マシンの振る舞いをすばやく変更するため。
- アーキテクトは方針と詳細を区別し、方針をシステムの最も重要と認識するシステムの形状にデザインし、詳細の選択肢をできるだけ多く残す。選択肢を残せる期間が長ければ、実験できることが増え、決定しなければいけない時点までに入手できる情報も増える。

思いの外いい記事だった もっといいねされるべき

『テストについての話をしよう』 (Daniel North, 2021)の抄訳

『テストについての話をしよう』 (Daniel North, 2021)の抄訳
zenn.dev/tnzk/article…
読んでる

React Tokyo ミートアップ #2 (2025/02/14 19:00〜) # はじめに ## このイベントの趣旨は？ React Tokyo コミュニティが主催する、交流会（ミートアップイベント）です。 リアル（オフライン）での交流を、Discord（オンライン）上の議論や知識共有の土壌づくりとして活かす事を目的とします。 実際に会って言葉をかわし、面識を深めることによって更にオンライン交流を持続可能でより良い物にすることを目指します。 第一回はこちら ## React Tokyoコミュニティとは 東京を中心に、オンラインとオフラインの両方で活動するReactコミュニティです。 公式HPはこちら オンラインでは、Discordを通じた情報交換...

react-tokyo.connpas...
React Tokyo ミートアップ #2 (2025/02/14 19:00〜)

- React Tokyoミートアップ#2が2025年2月14日に開催。
- メタのReact利用事例のトークやグループワークあり。
- 場所は六本木グランドタワー、要Discord参加。

Web API: The Good Parts Web APIの設計、開発、運用についての解説書。APIは設計次第で使いづらいものになってしまうだけでなく公開後の保守運用も難しくなってしまいます。そのためAPIを美しく設計することがとても重要です。本書では「設計の美しいAPIは、使いやすい、変更しやすい、頑強である、恥ずかしくない」という考えのもと、APIをどのように設計し運用すればより効果的なのか、ありがちな罠や落とし穴を避けるにはどういう点に気をつけなければいけないのかを明らかにします。ターゲットは、URIにアクセスするとXMLやJSONなどのデータが返ってくるシンプルなタイプ――XML over HTTP方式やJSON over HT

Web API: The Good Parts - O'Reilly Japan
oreilly.co.jp//books/97848…
読み終えたら、クリーンアーキテクチャに戻ってきた

14.コンポーネントの結合
- 非循環依存関係の原則(ADP)…コンポーネントの依存グラフに循環依存があってはいけない。循環依存があると、コンポーネントを切り離すのが難しくなる。
- 依存構造はシステムの論理設計に合わせて育てていく。
- 安定依存の原則(SDP)…安定度の高い方向に依存すること。安定度が高い=多数のコンポーネントから依存されている。少し変更するだけで多数のコンポーネントに影響を与える。
- 安定度・抽象度等価の原則(SAP)…コンポーネントの抽象度は、その安定度と同程度でなければならない。安定度が高い→抽象度も高くあるべき。安定度が低い→具体的なものであるべき。

初リリース作業立ち会っていただけたの一生感謝してます！🥹
とはいえ立場が変わると考える必要のあることも増えますしね 私もそうならないように心掛けしとこう

実はわりとこれで限界を感じてチーム異動しました😢

無自覚にメンバーの心理的安全性を奪っていた経験から得た学び 2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips

無自覚にメンバーの心理的安全性を奪っていた経験から得た学び - Speaker Deck
speakerdeck.com/lighttiger25…
良いスライドだけど、読んでて苦しくなってきた

13.コンポーネントの凝集性
- 再利用・リリース等価の原則(REP)…テーマや目的があり、それを共有するモジュールを集めよという原則。
- 閉鎖性共通の原則(CCP)…変更の理由やタイミングで変更されるクラスをまとめよ、逆に異なるクラスは分けよという原則。単一責任の原則をコンポーネント向けに言い換えたもの。
- 全再利用の原則(CRP)…一緒に用いられることが多いクラスやモジュールはまとめよという原則。密結合していないクラスをまとめるべきではない。
- これらには相反するところがある。利便性と再利用性のトレードオフを考慮しバランスをとる必要がある。
- 最適な落としどころは常に変わり続ける。

12.コンポーネント
- コンポーネントとは、jarファイルやgemファイルなどのシステムの一部としてデプロイできる、最小限のまとまりのこと。
- 昔はプログラムをメモリ上のどこに配置するかを決める必要があった。プログラムはリロケータブル（再配置可能）ではなかったので、肥大化によりアプリケーションと関数ライブラリはメモリ上で断片化した。
- スマートローダーやリンクローダのおかげでメモリ上の再配置や個別にコンパイルやロードができるセグメントに分割できるようになった。
- 複数のjarファイルや共有ライブラリを秒単位でリンクして、実行できるようになった。→コンポーネントプラグインアーキテクチャ

11.依存関係逆転の原則（DIP: Dependency Injection Principle）
- ソースコードの依存関係が、システム内の変化しにくい抽象インターフェイスだけを参照する。 変化しやすい具象実装を参照しない。
- 新しい機能を実装するときも、できる限りインターフェイスの変更なしで済ませられるようにする。
- 依存性は具象側から抽象側へ向かう。ソースコードの依存性と処理の流れは逆向きになる。
- DIP違反を完全に取り除くことはできない。
- ほとんどのシステムにはDIPを満たさない具象実装が少なくとも一つ、main関数を含むmainコンポーネントがある。

そんななのでTSKaigiKansaiは追っかけられないな

クリーンアーキテクチャいまいち馴染まない…… がクリーンアーキテクチャなGoを書き始めることでやっとこれのことを言ってるんだな！になって雲を掴むような感じで少し分かり始めた

10.インターフェイス分離の原則（ISP: Interface Segregation Principle）
- 必要としないモジュールに依存して、再コンパイルや再デプロイを強制されるのは有害。
- 静的型付け言語では、importやuse, includeといった宣言を強制して依存性を作り出している。そのため、import元で使用していない機能が変更された場合に再コンパイルが必要になる。
- 動的型付け言語では、こうした宣言はソースコードに依存せず実行時に推論するため再コンパイルを強制しない。
- 必要としない依存を抱えないために、インターフェイスを分離する。