エッセイ一覧

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

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