技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。

[Keisuke69]

イケてる技術 ≠ 正しい技術。イケてる技術の採用にはチームとしての合意形成と覚悟も必要。自分もここがわかっていない時代がありました

[raimon49]

ライブラリとフレームワークの整理が腑に落ちる言語化でとてもよい

[p1ass]

この例え面白いな"これらはビジネスの不確実性の波をフーリエ変換するようなものです。"

[otihateten3510]

プロジェクトレベルの成否と、個人の成否が一致してない社会的問題がある。イケイケ難解な設計をした人の方がその後評価されてしまう。

[Xibalba]

“「失敗」というのは技術者にとって最大の福利厚生であるから、リスクを低く小さく失敗できるように、技術的な意思決定におけるリスク評価を正しくできるようにあるべきだし、その意思決定の経験を正しく学びに繋げ

[simomm]

オニオンモデル、ペースレイヤリング、抽象依存の原則、安定依存の原則、トレードオフスライダー、誰がなんのためにどのくらいどこを変更するか

[digo]

年末年始にコタツに入りながら読もう^^

[nekoruri]

よいまとめ。

[t09]

ムダに長い

[prograti]

そう言えば最近エンタープライズ・アーキテクチャってあんまり聞かなくなったな。EAフレームワークも今の時代に合わせてアップデートされてるんだろうか？

[YassLab]

"注意すべき点はプロトタイピング時のソースコードを基本的には破棄することです。プロトタイピングは課題の洗い出し、リスクの暴露が目的なので、そのまま実運用に耐えるコードである必要はない"

[minoton]

わかるが、これらのすべてに質の高い結論を出していたら先に進まぬ…クライテリアとするか、あくまで考え方（必要なとこだけつまむ）とするか？

[deokisikun]

まとめすげぇ

[kninok_d261007]

#技術書 #勉強、参考書 #開発マニュアル

[koogawa]

これは大作

[versatile]

筆者は超信頼できるんだけど、qiita というプラットフォームをもうあまり信用してないので、ちょっと残念

[hiroaki256]

アーキテクチャの再設計が必要なタイミングに、転換を実現する十分なリソースが存在しないのであれば、本当の失敗に向かってシステムが動くことになります

[hikalin8686]

この分量は広木大地氏だとおもったら当たった

[for-my-internet-demo]

よい。よいよ

[keint]

想像以上に読み応えがあった

[iwasiman]

広木大地さんの記事。技術とアーキテクチャを決めていく中でのあれこれを、様々な書籍の図と共に解説しています。確かにこういう話ってまとまった本でも読みたいですね。

[nkgr]

失敗できる環境大事。