蒼天

趣味でC++&DirectX12等でゲーム作ったり。
サムネは斬舞滅貴さん(@kiribu50mekki)に作成いただきました。

[蒼天 @deep_verdure]

【崩界】ドゥームズデイ(毒属性：魔法有効)の30秒切り撃破も達成！

29:85の超ギリギリ撃破。エッジが毒属性ではないがM神技を手に入れたので、それによって打開できた。やっぱり他個体よりもHPが高く感じる。

[蒼天 @deep_verdure]

【崩界】ドゥームズデイ(聖属性：物理有効)の30秒切り撃破達成！

クラウドが風のM神技だけでなく闇のM神技も入手できたので、そのお陰で打開できた。被ダメージが高く結構ヒヤヒヤさせられた。

[蒼天 @deep_verdure]

今回はここまで。次回はアーキテクトへの期待から。

[蒼天 @deep_verdure]

⇒例えば、サービス間通信の全ての条件、選択肢を網羅するアーキテクチャ決定を定めるのは不可能であるため、その代わりに設計指針として望ましいアプローチに関するガイドを提供する。

[蒼天 @deep_verdure]

システムをどのように構築すべきかのガイドラインを「設計指針」という。
　⇒アーキテクチャ決定とは異なり、強制力を持たない。

[蒼天 @deep_verdure]

⇒任意の基準やアーキテクチャ決定に対する特例を認めるプロセスを定めており、アーキテクチャ決定に対する例外は、ARB等によって分析され、その正当性やトレードオフに基づいて承認または否認される。

[蒼天 @deep_verdure]

何らかの条件や制約からアーキテクチャ決定をシステムの一部に実装できない場合には、その決定は「特例」によって破られる。
　⇒殆どの組���には、アーキテクチャを審査する「ARB(Architecture Review Board：アーキテクチャ審査委員会)」やチーフアーキテクトが使用する特例モデルが存在する。

[蒼天 @deep_verdure]

システムをどのように構築すべきかのルールを定めるものを「アーキテクチャ決定」という。
　⇒システムの制約を形作り、何が許されて何が許されないかに関する開発チームの指針となる。

[蒼天 @deep_verdure]

これで"モノリスからマイクロサービスへ"のまとめは終わり。

続けて、ソフトウェアアーキテクチャの基礎第1版のまとめ。技術の変遷を見るために敢えて第1版からまとめる。過去に他の本で触れた話題は割愛。

まずはソフトウェアアーキテクチャの基礎について。

[蒼天 @deep_verdure]

孤児サービスを新たに発見した場合は、他のサービスの管理方法と一致させることが重要である。
　⇒強���所有権を実践している場合は既存のチームに所有権を割り当て、共同所有を実践している場合はサービスを改善するための作業項目を挙げる。

[蒼天 @deep_verdure]

⇒例えば、以下のような事柄をチェックしてスコアを計算する。

- チームがレジストリに正しい情報を提供したかどうかを確認する。

- サービスに適切なヘルスチェックが行われることを確認する。

[蒼天 @deep_verdure]

サービスを運用しやすくするには、サービスとそのチームが実行すべき特定の事柄があるとし、それらをスコア化して修正が必要なサービスの有無を一目で確認できるようにする仕組みを「システム操作性スコア」という。

[蒼天 @deep_verdure]

孤児サービスの発生を防止するには以下のような方法がある。

- サービスの共同所有を実践する。

- シンプルな社内サービスレジストリを作成し、サービスに関するメタデ��タ照合ができるようにする。

[蒼天 @deep_verdure]

組織の誰も所有権や責任を負っていないマイクロサービスを「孤児サービス」という。
　⇒マイクロサービスを長期間にわたり使用してきた組織で、開発者の異動や退職等により発生する。
　⇒機能しなくなったり変更が必要になった場合、人々は何をすべきか分からず途方に暮れてしまうという問題がある。

[蒼天 @deep_verdure]

回復性は、必要に応じて仕事の仕方を進化させることもできる組織を構築することという、働き方全体に関わるものである。

[蒼天 @deep_verdure]

マイクロサービスの堅牢性と回復性に問題があるかどうかを確認するには、以下の質問に答えるのが良い。

- この呼出しがどのように失敗し得るかを分かっているか。

- 呼出しが失敗した場合、何をすべきかを分かっているか。

[蒼天 @deep_verdure]

受信側の処理が追いつかない場合などに、受信側から送信側に対してフロー制御を行えるようにする手法を「バックプレッシャー」という。
　⇒サーキットブレーカーによって、導入しなくても良いようにできる。

[蒼天 @deep_verdure]

チームに責任を渡せば渡すほど自律性が高まるというメリットがあるものの、問題解決の方法に一貫性が無くなるというトレードオフがある。
　⇒中央から物事を推進すればするほど、合意形成の必要性が高まり、それが開発ペースを落とすことになる。

[蒼天 @deep_verdure]

⇒各チームから少なくとも1人の技術リーダを技術横断グループの一員とし、CTO、チーフアーキテクト、または会社の全体的な技術的ビジョンの責任者がグループのリーダを務めると良い。

[蒼天 @deep_verdure]

以下を目的に、チーム横断的なグループを構築する���

- チームがより大きなフォーラムで議論したいと欲している局所的な問題を表面化させる。

- チーム横断的な問題を拾い上げる。