犬も猫も空想も扱っておりません。(旧・エト記)この広告は、90日以上更新していないブログに表示しています。Architecture(原著)を読んだ。自分自身、実は「自称・アーキテクト」として10年以上、とあるソフトのアーキテクチャを請け負っているので、自分の中に言語化されていないノウハウがそれなりにあった。私にとってうれしかったのは、それらの言語化できていたかったノウハウが多少言語化されて整理されていたことと、この本自体が割と広く有難がられていることである。プログラムの設計を議論する場合、正論と正論が矛盾するという厄介なことがしばしば起こる。経験の浅い頃は、なぜそういうことが起こるのか分からず、結局最後までネチネチ煙に巻く人の意見が通ってしまい、後で苦労することになることがあった。正論を盾に責任を果たそうとしない口達者にも手を焼いた。経験を積んでからは「ごもっともだけど、それは今重要じゃない」と言えるようになった。原則のテンション・ダイアグラムを持ち出して、何をすべきかをより明確に説明できることだろう。何よりも、3つの原則がそもそも緊張関係にあることが前提なところから話が始められるようになったこと、また、アーキテクトの仕事が一つの完全な正解を導くのではなくて、与えられた境界条件から、開発効率を最大化するためにパラメータを調整することであることを、共通の言葉で説明できるようになったことが大きい。原則で外に括りだすことをお願いしたこともあった。そのような数々の技術的決断を、後から答え合わせする形で再定義できた。みたいな使い方ができて捗るかもしれない(しないけど)。(p.136)」と言い切ってくれたのも、この本が使える信用できると思った理由の一つだ。章まではちゃんと読んだが、以降は斜体で強調されているステートメントと結論以外は斜め読みした。良くないかは、それらのコンポーネント群が、結局一つの塊としてコンポーネントになってしまって管理コストが上がることは、子供のおもちゃを使ってもっと簡単に説明できると思った。言って仰々しくするとってつけたようなコンサルタント用語の類も、頭の片隅に入れておけば十分である。それらは言語化されているという点で便利な概念だけど、まだ本質を掠めている程度であるからだ。蛇足を承知で言うと、導入の章でソースコードの行数をもって生産性の指標にしているのは単純化しすぎと感じた。コーディング技術が向上したりプログラミング言語そのものがバージョンアップして改良されたりすることで行数が圧縮されるのは、生きているソフトウェアでは起こりうることだからだ。それはアーキテクチャとは関係がない。個人的には仕事柄この本はとても有益だった。一方で、この本を読んでポカンとして何も響かなくても、別にそれがダメとも思わないし、むしろ本書に出てくるキーワードでマウントをとるアーキテクトにならないようにしようと心に刻んだのだった。今まで業務で使用する自動化をRubyで書き溜めてきたものの...2008-02-16食あたり某ラーメン屋のタンメンに当たる。問題Archiveはてなブログをはじめよう!xoinuさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。