アーキテクチャの天下統一は可能なのか？ってふと思った
過去から未来の全てのアーキテクチャの天下統一したアーキテクチャって実現可能なのかなぁ〜って思ったのでちょっと考えた
仮説-天下統一したアーキテクチャ
1. ある一つのアーキテクチャが存在する
2. そのアーキテクチャはあらゆる開発で利用可能
3. 他のアーキテクチャを選択する必要性は全くない
仮設-既存のアーキテクチャ
1. 既存のアーキテクチャはプロダクトのソフトウェア品質要求、コスト、流行で決まる
2. 既存のアーキテクチャで天下統一したものは無い
（参考リンク
ということは
天下統一したアーキテクチャはソフトウェアの品質要求がどんなレベルであろうと、プロダクト開発にかかるコストも要求レベルを実現出来ることになる
＝どんな品質要求でもかかる開発コストは同レベルになる
反論-1
数万ユーザ同時アクセスでms単位でレスポンスを返すことを要求されるプロダクトと
数ユーザ同時アクセスでs単位でレスポンスを返すことを要求されるプロダクトで
開発コストが同レベルになることは無い
反論-2
PoCに適したアーキテクチャと、本開発に適したアーキテクチャが同じになることは無い
（反論パターンは沢山作れるのでざくっと省略
以上の反論から
アーキテクチャの天下統一は無理がある
ただし、プロダクトの特性に合わせたある程度の最適解は同様なサービスのアーキテクチャ等から抽出可能な気がする
おまけ
Clean Architectureを読んで思った事
何を思ったのか、Clean Architectureを突然読み始めた
そして感じたこと
アーキテクトの人が読む本ってあんまり無かった気がするけど、これはまとまってて良いな〜
なるほど、これが有名な◎か...
アーキテクチャが開発工数とかに影響するんだから、かけれる開発コスト(と要求される開発速度)を天秤にかけるのもアーキテクトとしての大事な仕事では？
データベースはdetailかもしれないけど、データモデルは違うよなぁ〜まぁそれは別の人の仕事か...でも実装工数考えるとデータベース使う前提のシステム作るかどうかって先に決まる気がする
仮に工数とかが十分だったとしても個人的には◎は選ばないかもなぁ〜
でも、実装の設計レベルでは似たことをやってるｗ
自分的に新しい手法を見つけたときに見てるところ
こじんてきめも
どっからか新しい手法を見つけるところがスタート
ネット徘徊してたりすると意外と転がってる
見ても放置すること
適用した人の積極的コメント（たぶんこれがあるので目に入ってるので気にしない）
適用してない人の応援コメント（実は参考にならない）
いくつかの基準で分解する
元々どこに適用する為に作られてるのか
何の問題を改善しようとしてるのか
前提条件の有無
手法そのものの特徴
理論的背景
元々どこに適用する為に作られてるのか
元々の適用先がどこで、その適用先にはどんな特徴・特性があるのかをちゃんと把握する。これを大きく超えた適用は多分無理なので意外と大事
手法が2次以降の場合は可能な限りオリジナルまで辿っていく
何の問題を改善しようとしてるのか
大抵は類似の適用先に何らかの手法が存在してるはずなので、何の問題を改善したいのか・しようとしてるのかをちゃんと把握する
適用先＋改善内容によっては積極的に取り込んだ方が良いことがある
流行っててもこれがズレてると効果が出ない
前提条件の有無
その手法には前提条件があるのか、ないのか（たぶんある）
前提条件をしっかり把握する（スーパーエンジニアが必要とか）
手法そのものの特徴
その手法そのものの特徴とか他との違いはざっくり把握しておく
大抵はこの前段階でほぼ調査終わってるはずだけど抜けてる可能性はあるので...
理論的背景
その手法はどんな理論を背景に作られたのか、経験則から導き出したのかなどを調べる
ここで、理論的背景を抑えないと使おうとしても上手く使えないとかが発生するので、個人的にしらない理論だとその理論から抑えないとダメなのですごく時間がかかる
後付けで理論的背景が追加される事もあるけど、それもよし
経験則から導き出したものだと、その人・環境特有な物の可能性があるので要注意
ここまで詳細に調べておけば
新しい手法をプロジェクトに取込たいってなったときに、手法のマッチングが出来るようになるので、場合によっては手法を修正したりする
まぁ何が言いたいかというと、
使って当然的に言われてる手法の○○って本来と、現実の実現方法でだいぶ根本がズレてないか？って思うことがあるので気になってるｗ
アーキテクチャ考えるときに考えてる事
こじんてきめも
概略
アーキテクチャ = (プロダクトの特性 + チーム体制 + 個人的に死守すべしと考えるポイント + マネージャor要望者の優先課題 + チームのやりたいこと)
プロダクトの特性
たとえば、えんたーぷらいずなシステム構築なのか、BtoCなシステム構築なのか...
リクエスト数はどれくらいなのかとか、可用性は...とか
アーキテクチャを決める前段階で決まってる内容
チーム体制
長く一緒にやってる超優秀なエンジニアだけで構成されたチームなのか、このプロダクトのために緊急でかき集めたエンジニアなのか...など
アーキテクチャの立ち位置とかもこの辺に絡んでくる
個人的に死守すべしと考えるポイント
たぶん各自違うポイントがある（経験とか指向性とかで）
その中でも、これを守らないと絶対ダメだと考えるポイントのこと
過去の経験とかの積み上げとか、前回の反省とかが生きるところ
判断基準は、「これを守れないプロダクトなら作らない」と言えるレベルかどうか
マネージャor要望者の優先課題
優先度の高い課題があって、大抵はQCDのどれかの事が多いけどたまにそうじゃないものもある
その課題をちゃんと理解して認識しておくことが重要
チームのやりたいこと
たとえば、新しい技術を使いたいとか、新しい手法を使いたいとかそういうの
全く新規性の無いプロダクト開発はそれはそれでつまらないことも多いので
ただし、ここまでに出てきた物の中では優先度が低くなることが多いのと、判断をミスると基本的に大変な尻拭いも待ってる部分なので未経験なことを大量に入れるのは避けた方が賢明なことが多い
アーキテクチャの決め方
プロダクトの特性を大前提にして大枠の仕組みを決める
チーム体制を考慮して実装方法・サンプルの作成などで方向性を確定させる
（ここでチームのやりたいことも入れる
（代替があるので後回しにできるものは後から対応して行く
個人的に死守すべしと考えるポイントは全工程で守れるように気を配り続ける
割と早期にマネージャor要望者の優先課題が満たされているのかを判断する
判断した結果、満たされていない場合は調整 or アーキテクチャの見直しをする
大体出来た辺りで走り始めつつ
後回しにした物を色々追加していく
昔はアーキテクチャって言っても単純だったのに、どうしてこんなに増えたんだろうなぁ〜って思ってふと考えたら、プロダクトの特性が凄く多岐にわたることに気がついた
突然流入する100req/sの更新処理を多いと思うか少ないと思うか、準リアルタイムでのデータ同期がどれくらいあるか...という世界かなぁ〜
クラウドの前だったらサーバ費用がかかりすぎるって言って考えなくて済んだのにｗ
どうつくるか、どんな手法で作るか問題
どう作るか、どんな手法で作るかは、そのプロジェクト特性・企業文化・案件の前提条件を考慮して、各々が決定すればいい話で「唯一絶対の正解」なんてものは存在しないと思ってる。
比較的広範囲に適用可能な方法とかは存在していると思ってる。
それを否定的な人も居ることは知ってるし、それで良いと思ってる。
適切な決定方法を無視して「自分の思う絶対の正解」を利用したときに酷いことになるのも見てるので、色んな人の意見を見た方が良いと思ってる。
そして観測範囲外に「最も適切になる手法とか」が存在することもあると思ってる。
「そのプロジェクト特性・企業文化・案件の前提条件」を考慮せずに、その時の選択に否定的な意見を言う人も見たことがある。なので、アーキテクトの人は大変だなって思う
まぁ何が言いたいかというと、「makotanの短いソフトウェア開発の経験」程度では「銀の弾丸は探せてない」
2022年にあれこれ作るとしたら
高負荷とかホント嫌いなのに高負荷なサービスに関わる事が多いので、そういう環境を前提にぼーっと考えてた
（考えるきっかけはワクチンの時の待合室
DBはAurora Serverless
APIサーバはFargate
LBはALB
認証は...がんばって
ユーザ向けのサーバはAWSじゃなくて（ぇ？
Cloudflareで全部賄うとする
ユーザのリクエストはCloudflare Workersで受けて、処理する
CloudflareにDBとかS3互換のサービスとかあるので、その辺を上手に使いつつ
APIサーバのリクエストが必要なときだけAPIサーバを呼び出す
ちゃんとCloudflareでCDNも用意する
ここまでやって(AWSの)DBサーバが上限になるようなら待合室を使って待ち行列を作る
とすると...不要なタイミングでは安くて、でも高負荷にも耐えれるサービスが出来そうな気がした（気がするだけです
APIサーバをLambdaじゃなくてFargateにする理由とかはあるけど、ちょっと文字数制限で書けないｗ
コードジェネレータの分類2022
ぼーっとしてたら増えたので、前のをまるっとコピペして追記
A型(type-A)
Excel等のツールだけを使ってコード生成する
Excelの式とかmacroとかを駆使する
定義と生成の距離が短い
B型(type-B)
既存の何らかの定義を読み込んでコード生成する
DBのSchemaとか、ソースコードとかを入力として使う
一種類の定義からかなりの種類の出力が出来る様になる
C型(type-C)
専用の定義を使ってコード生成する
専用のエディタがあったり、yaml/jsonを入力として使う
定義した内容を使った定義が出来る
広範囲のコード生成が出来る
D型(type-D)
入力と出力を渡すとその間を埋めるコードを生成する
E型(type-E)
機械学習で実装を支援する
IDEに組み込まれて意図を理解しつつ実装を支援する形
1種(type-X1)
生成した物はプログラマには触らせない
専用ツール上で動作するためのコードを生成する
2種(type-X2)
生成したコードはプログラマ変更する前提
再生成は出来ない
3種(type-X3)
生成したコードは拡張ポイントを使ってプログラマが動作を変える
再生成も可能
たとえば・・・って書こうと思って例が懐かしすぎて止めたｗ
型A,B,C
種1,2,3
はそれぞれ組み合わせが自由なので
YYYってツールはtype-B2とかの表記が出来るよと
今のところ自分が認識してるコード生成ツールがこの分類でどれかに当てはまってる
そしてそんなことを考えてると言うことは・・・
