12のソフトウェア・アーキテクチャの落とし穴とその避け方

これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す

[Keisuke69]

“ソフトウェア開発における本当のスキルは、コーディングでも、構文の知識でも、特定のフレームワーク群に精通していることでもなく、課題解決である”

[kiririmode]

アーキテクチャはトレードオフの集合体であり、標準化や模倣はQARの違いを理解しない限り大きなpitfallになる

[mak_in]

アーキテクチャは、多くの場合、ビジネス面の未来の変化とのトレードオフなんだよな。だから、ビジネス面をちゃんと考慮しないと、だいたい将来的につらくなる

[awkad]

いかにもコンサルがいうようなものいいの記事で「コンサルに委ねるな」は草。ようはこんな記事真にうけるな、ってことね

[Magicant]

12番目ww

[progrhyme]

"アーキテクチャを構築していない人は、アーキテクチャに関する決定を下すべきではない"

[TriQ]

「12のソフトウェア・アーキテクチャの落とし穴とその避け方」じゃなくて「ソフトウェア・アーキテクチャの12の落とし穴とその避け方」のお話でした。

[prograti]

ISO9126のソフトウェア品質特性をベースにして設計したりはしますが、お客様のコンテキストが欠けている感は否めないですね。自分の得意なパターンで済ませてしまうケースが多い...

[nakag0711]

なぜQARの定義がないのかわからん

[katsyoshi]

課題がはっきりしてる問題で「アーキテクチャ」という強い言葉を使ってごまかすのは一種の思考停止で嫌い。ソフトウエアにおけるアーキテクチャはなにかあるものじゃなくて思想だと思ってる。なお本文はまだ読んでい

[toro-chan]

んー、良いことは書いてあるだろうけど、結局アーキテクチャとはなんだろうと思ってしまう。曖昧すぎてどうとでも言えてしまい、意味がないような気がしてならない。

[chi-bd]

“ソフトウェア開発スキルはコモディティであるという信念に後押しされ、低コストのベンダーが何年も何十年も経験を積んだチームメンバーと同じスキルを提供できるという契約に誘惑されるかもしれない。”

[dekasasaki]

「HiPPO→hippopotamus→カバ→運用でカバー」まで一瞬で連想してしまった

[lenore]

“ 何がソフトウェアアーキテクチャの成功につながるかを明確に言うのは難しいが、何がそうでないかを言うのは簡単である” それをしっかり言語化していて助かる

[otihateten3510]

めっちゃ良いこと書いてる

[syuu256]

他の組織からアーキテクチャをコピーしてはならない