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

更新日:

  1. システムの要件よりも履歴書の見栄えを優先させてはならない
    • ニティン・ボーワンカー
  2. 本質的な複雑さは単純に、付随的な複雑さは取り除け
    • ニール・フォード
  3. 最大の問題は、たぶん技術的なことではない
    • マーク・ラム
  4. まずコミュニケーション、そのための明快さととリーダーシップ
    • マーク・リチャーズ
  5. パフォーマンスの決め手はアーキテクチャー
    • ランディ・スタッフォード
  6. 要求仕様の本当の意味を探れ
    • アイナー・ランドル
  7. 立ち上がろう!
    • ウディ・ダーハン
  8. すべてのものは、かならずエラーを起こす
    • マイケル・ナイガード
  9. それは交渉だということに気付け
    • マイケル・ナイガード
  10. 定量化を求めよ
    • キース・ブレイスウェイト
  11. 11行の仕様書より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. 58つから2つだけを選ぶ覚悟を決めよ
    • ビル・デオーラ
  59. 趣味や個人的な意見ではなく、原理原則に従え
    • マイケル・ハーマー
  60. 動くスケルトンから始めよ
    • クリント・シャンク
  61. データがすべて
    • ポール・W・ホーマー
  62. 単純なものは単純に
    • チャド・ラヴィーニュ
  63. アーキテクトは何よりもまずデベロッパーであれ
    • マイク・ブラウン
  64. ROI変数を意識せよ
    • ジョージ・マラミディス
  65. 目の前にあるのはレガシーシステムだという前提で設計せよ
    • デーブ・アンダーソン
  66. 解決策が1つしかない場合には、セカンドオピニオンを求めよ
    • ティモシー・ハイ
  67. 変化の影響を把握せよ
    • ダグ・クロフォード
  68. 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のこと

  1. アーキテクチャは縦と横の基本構造を持つ
    • 萩原正義
  2. ビジネス・アーキテクトを目指せ
    • 萩本順三
  3. 問題にフォーカスせよ
    • 榊原彰
  4. 問題にとらわれるな
    • 榊原彰
  5. 煩雑なことを非属人化し、創造性を高める
    • 萩原正義
  6. 手段的な技術と陳腐化しない本質的な技術
    • 伊藤直也
  7. 開発スタイルをデザインする
    • 小野和俊
  8. システムではなく、コミュニケーションをデザインせよ
    • 鈴木雄介
  9. 移り気な利用者を捉える
    • 牧野友紀
  10. 受動的アーキテクトと能動的アーキテクト
    • 江島健太郎
  11. 説明責任を果たす
    • 萩本順三

参考

picture978-4-87311-429-3.gif

  • Richard Monson-Haefel 編、鈴木 雄介 監修、長尾 高弘 訳
  • 2009年10月03日 発売予定
  • 246ページ
  • 定価1,995円
  • ISBN978-4-87311-429-3
  • 原書: 97 Things Every Software Architect Should Know

購入は下記から。
http://www.oreilly.co.jp/books/9784873114293/

-Blog

Copyright© fullvirtue.com プロダクトオーナー支援スペシャリストのBlog , 2024 All Rights Reserved.