ソフトウェアアーキテクトが知るべき 97 のこと

【01】システムの要件よりも履歴書の見栄えを優先させてはならない by ニティン・ボーワンカー
【02】本質的な複雑さは単純に、付随的な複雑さは取り除け by ニール・フォード
【03】最大の問題は、たぶん技術的なことではない by マーク・ラム
【04】まずコミュニケーション、そのための明快さとリーダーシップ by マーク・リチャーズ
【05】パフォーマンスの決め手はアーキテクチャー by ランディ・スタッフォード
【06】要求仕様の本当の意味を探れ by アイナー・ランドル
【07】立ち上がろう！ by ウディ・ダーハン
【08】すべてのものは、かならずエラーを起こす by マイケル・ナイガード
【09】それは交渉だということに気付け by マイケル・ナイガード
【10】定量化を求めよ by キース・ブレイウェスト
【11】500 行の仕様書より 1 行のコード by アリソン・ランダル
【12】フリーサイズのソリューションを求めるな by ランディ・スタッフォード
【13】パフォーマンスの検討に早過ぎるということはない by レベッカ・パーソンズ
【14】アーキテクチャーとはバランスを取ること by ランディ・スタッフォード
【15】犯罪的なコミットエンドランを防ぐには by ニクラス・ニルソン
【16】選択肢を 1 つに絞らないための現実的な方法 by キース・ブレイウェスト
【17】ビジネスサイドに主導権を渡せ by デーブ・ミュアヘッド
【18】一般性より単純性、再利用よりもまず最初に使えること by ケブリン・ヘニー
【19】アーキテクトは手を汚さなければならない by ジョン・デービーズ
【20】継続的にインテグレーションを実行せよ by デビッド・バートレット
【21】日程による失敗を避けるために by ノーマン・カーノベール
【22】アーキテクチャーではトレードオフは避けられない by マーク・リチャーズ
【23】要塞としてのデータベース by ダン・チャック
【24】不確定性が潜むという感覚を磨け by ケブリン・ヘニー
【25】鏡に映る問題は見かけよりも大きい by デーブ・クイック
【26】再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ by ジェレミー・メイヤー
【27】アーキテクチャーに I（自我）なし by デーブ・クイック
【28】地上 300m からの目 by エリック・ドーネンバーグ
【29】選ぶ前に試せ by エリック・ドーネンバーグ
【30】ビジネスドメインを理解せよ by マーク・リチャーズ
【31】プログラミングは製造ではなく設計だ by アイナー・ランドル
【32】デベロッパーに自己裁量を与えよ by フィリップ・ネルソン
【33】時間がすべてを変える by フィリップ・ネルソン
【34】「ソフトウェア・アーキテクト」の A は小文字だけ。それで満足せよ。 by バリー・ホーキンス
【35】大きなスコープは敵 by デーブ・クイック
【36】役者ではなく執事になれ by バリー・ホーキンス
【37】ソフトウェア・アーキテクチャーが倫理的な意味を持つことを考えよ by マイケル・ナイガード
【38】摩天楼はスケーラブルではない by マイケル・ナイガード
【39】未来はヘテロジニアスとともにある by エドワード・ガーソン
【40】パフォーマンスがまず大事 by クレイグ・ラッセル
【41】ダイアグラムの空白に注意せよ by マイケル・ナイガード
【42】デザインパターンに習熟せよ by マーク・リチャーズ
【43】状況がなによりも大切 by エドワード・ガーソン
【44】ドワーフ、エルフ、ウィザード、キングの 4 種類の人々 by エバン・コフスキー
【45】建物のアーキテクト（建築家）から学ぼう by キース・ブレイウェスト
【46】繰り返しと戦え by ニクラス・ニルソン
【47】現実の世界にようこそ by グレガー・ホープ
【48】支配せず、観察せよ by グレガー・ホープ
【49】アーキテクトは2つの顔を持つ by デビッド・バートレット
【50】アーキテクトは境界とインターフェイスに注意を注げ by アイナー・ランドル
【51】デベロッパーに力を by ティモシー・ハイ
【52】理由を書き留めよ by ティモシー・ハイ
【53】暗黙の仮定、特に自分自身ものを疑え by ティモシー・ハイ
【54】あなたの知識と経験を共有しよう by ポール・W・ホーマー
【55】パターンの病理学 by チャド・ラヴィーニュ
【56】たとえ話の使いすぎに注意 by デビッド・イング
【57】アプリケーションの保守に力を入れよ by ムセディシ・カスパー
【58】3 つから 2 つだけを選ぶ覚悟を決めよ by ビル・デオーラ
【59】趣味や個人的な意見ではなく、原理原則に従え by マイケル・ハーマー
【60】動くスケルトンから始めよう by クリント・シャンク
【61】データがすべて by ポール・W・ホーマー
【62】単純なものは単純に by チャド・ラヴィーニュ
【63】アーキテクトは何よりもまずデベロッパーであれ by マイク・ブラウン
【64】ROI 変数を意識せよ by ジョージ・マラミディス
【65】目の前にあるのはレガシーシステムだという前提で設計せよ by デーブ・アンダーソン
【66】解決策が 1 つしかない場合には、セカンドオピニオンを求めよ by ティモシー・ハイ
【67】変化の影響を把握せよ by ダグ・クロフォード
【68】ハードウェアの理解も必要 by カメル・ウィックラマナヤケ
【69】今の近道、後で大損 by スコット・マクフィー
【70】「完璧」は、「十分よい」の敵 by グレッグ・ナイバーグ
【71】「よいアイデア」を避けよ by グレッグ・ナイバーグ
【72】優れたコンテンツは優れたシステムを作る by ズービン・ワディア
【73】怒れるアーキテクトとしてビジネスと対立するな by チャド・ラヴィーニュ
【74】主要な指標の耐久性を試してどこで壊れるかを確かめよ by ステファン・ジョーンズ
【75】設計するならコーディングできなければならない by マイク・ブラウン
【76】他の名前でバラを呼べば、キャベツにしかならない by サム・ガーディナー
【77】しっかりとした問題には高品質のソリューションが与えられる by サム・ガーディナー
【78】勤勉さが必要 by ブライアン・ハート
【79】自分の判断に責任を持て by イ・ジュウ
【80】クレバーになるな by イーベン・ヒューイット
【81】武器は慎重に選べ、安易に手放すな by チャド・ラヴィーニュ
【82】本当の顧客は目の前の顧客ではない by イーベン・ヒューイット
【83】設計した通りにはならない by ピーター・ジラードモス
【84】フレームワークは相性で選べ by エリック・ホーソーン
【85】強力なビジネスケースを作れ by イ・ジュウ
【86】コードだけではなくデータをコントロールせよ by チャド・ラヴィーニュ
【87】技術上の借金は返済せよ by バークハート・ハフネーゲル
【88】問題を解こうとするな by イーベン・ヒューイット
【89】システムは用具的に作れ by キース・ブレイウェスト
【90】問題解決に情熱を注げるデベロッパーを探して手放すな by チャド・ラヴィーニュ
【91】ソフトウェアは実際には存在しない by チャド・ラヴィーニュ
【92】新しい言語を学べ by バークハート・ハフネーゲル
【93】未来永劫安泰なソリューションはない by リチャード・モンソンヘーフェル
【94】ユーザーの拒否感情の問題 by ノーマン・カーノベール
【95】コンソメの重要性 by イーベン・ヒューイット
【96】エンドユーザーの立場からはインターフェイスこそがシステム by ヴィナヤク・ヘッジ
【97】優れたソフトウェアは構築されるのではなく、成長する by ビル・デオーラ

日本人アーキテクトによる知っておくべき 11 のこと