そういえば最近本について書いてなかった(ﾟДﾟ)

本を読んでも、時間がたつと日記に書く気がなくなったりしてね(´д｀;)
っというわけで、最近読んだ本について、たまにはbookネタを書いてみる。

お題はコレ(・∀・)

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

感想というか、トピックに対して適当にコメント。

• 02 本質的な複雑さは単純に、付随的な複雑さは取り除け

そうそう「フレームワーク」とかね、個別の問題を解決する一方で「付随的な複雑さ」をまき散らすようなものもあるよね(´д｀;)
特に、一昔前のJavaフレームワークとかはその傾向があったりね…(´・ω・`)

• 03 最大の問題は、たぶん技術的なことではない

Yes。
だからこそ、技術的な問題で悩んだり失敗するようなのはもっとも愚かしいことだとも思う(´ω`)

• 04 まずコミュニケーション、そのための明快さととリーダーシップ

カジュアルなミーティングに関するノウハウ(?)みたいなものについて、もっと語られても良いと思うんですよ。
普段からそういうことについて考えていたりもするので(´ω`)

• 05 パフォーマンスの決め手はアーキテクチャー
• 13 パフォーマンスの検討に早過ぎるということはない
• 40 パフォーマンスがまず大事

アーキテクチャーを考慮せずに、後からパフォーマンスチューニングが出来ると思っている人が多いのはなんでだろうね(ﾟДﾟ)？
初期段階から基礎データ取って、アーキテクチャ考えて、繰り返しテストできる環境を作って、っとやらないと、満足行くパフォーマンスなんて出せないと思うんだけどさ。
ちゃんとしたモノを作ろうと思ったら、ネジ一本の選別からするでしょ、っとか。

• 11 500行の仕様書より1行のコード

仕様書 != 設計、コード == 設計 みたいな話はまあ良いとして。
形式的なものは重視するくせに、網羅的な一覧とか、概念に関するメモみたいなものを軽視する人は多いわな(・3・)

• 18 一般性より単純性、再利用よりもまず最初に使えること

既存のフレームワークを選択せず、我々フレームワークを選択する理由もこの辺だったり。

• 19 アーキテクトは手を汚さなければならない

手を汚さないで行動するアーキテクトなんているんすかね(・ω・)？
っというか、物事を判断するためには、手を汚して汗をかいてなんぼですよ(´д｀;)

• 24 不確定性が潜むという感覚を磨け

「効果的なアーキテクチャとは、設計上の判断が持つ意味を軽くできるアーキテクチャである。」

• 28 地上300mからの目

思うんだけどさ、本とかにある設計やアーキテクチャの説明って、説明の為に問題を単純化しているせいで、視点が1万フィートになっちゃっている事ってあるよね(´д｀;)
まあ、場合によっちゃ、かえって有害だよな(´・ω・`)

• 31 プログラミングは製造ではなく設計だ

よく言われる事で、これを都合良く使うつもりもないんだけど。
まあ、それ以前の認識の人達が多いってことかな…。

• 41 ダイアグラムの空白に注意せよ

あー。
ピタゴラスイッチみたいな基幹システムってあるよね〜(＾Д＾)

• 43 状況が何よりも大切

コンテキストは大事さ(・∀・)
課題Aに対して技術要素Xを選択して、課題Bには技術要素Yを選択した理由はなにかと言えば、課題Aと課題Bでコンテキストが違ったからだよと答える。

• 47 現実の世界にようこそ

「スターバックスは2フェーズコミットなどしません。」

• 60 動くスケルトンから始めよ

これもまあ常識だけど。
その必要が無いって事は、箱庭の中で働いていると言うことでもある(´ω`)

• 63 アーキテクトは何よりもまずデベロッパーであれ

あっはっは。
デベロッパーに信頼/支持されないアーキテクトなんて存在価値がないですよねー。

• 71 「よいアイデア」を避けよ

ここで言っているものって「よいアイデア」じゃなくて、むしろ「悪いアイディア」じゃね( ﾟдﾟ)？

• 80 クレバーになるな

愚直さというのも良いアーキテクトには必須の要素だと思うよ(´ω`)

• 86 コードだけではなくデータをコントロールせよ

データのマイグレーションというのも、まだ語る要素の多い領域だよね。
採用するプロセスやアーキテクチャによる部分もあるんで、唯一のベストな解みたいなものは無いと思っているけど(・ω・)

• 87 技術上の借金は返済せよ

システムのライフサイクルを考える必要があるのなら、技術的負債についてはちゃんと考えて。
マジで(ﾟДﾟ)
まあ、ライフサイクルを考えなくていいシステムなんてないけどな(ﾟ∀ﾟ)

• 97 優れたソフトウェアは構築されるのではなく、成長する

ビジネスの変化とスピードに対応しようと思ったら、システムは生き物としてとらえて成長させていく必要があるよね。
まあ、変化とスピードに対応しなくていいビジネスなんてないけどな(ﾟ∀ﾟ)

• JP06 手段的な技術と陳腐化しない本質的な技術

「クリティカルな難しい問題を解かなければいけない場面は、いつか訪れます。」
それは貴方が思っている以上に早く、貴方が思っている以上に多く(・∀・)ニヤニヤ

• JP08 システムではなく、コミュニケーションをデザインせよ

「書籍ユーザなんていない。いるのは、リーダーです。サーフボードユーザなんていない。いるのは、サーファーです。最終的なゴールは「ユーザ」と呼ばれる存在のいない、コミュニケーションの総体をデザインするべきなのです。」

素晴らしすぐる(＞▽＜)

まあ、(日本では特に？)アーキテクトって言葉も都合良く使われる言葉だったりするけどね(´д｀;)
狭義の意味でのソフトウエアアーキテクトっていうならまだしも、システムアーキテクト*1にビジネスアーキテクトとか。
そんなん言うなら何にでもアーキテクトってつけることが出来るというわけで、ネットワークアーキテクトにデータベースアーキテクト、ストレージアーキテクトなんつったりして(ﾟ∀ﾟ)

まあ、あまり格好ばかりつけていると、「アーキテクチャ設計」の重要性が逆に軽視される結果にもなりかねないわけですが(´д｀;)
自分もアーキテクチャ設計は重要だし面白いからやるけど、別にアーキテクトとかって呼ばれなくて良いかなとは思う。

*1:これも上流SE(笑)の意味で使うケースもあれば、アプリケーションアーキテクトとの対の意味でインフラのアーキテクトという意味で使うケースもあったりね(´д｀;)