ソフトウェアアーキテクチャ チートシート
このブログ記事の内容がよかったので、翻訳してみた。
原文はこちら http://gorban.org/post/32873465932/software-architecture-cheat-sheet
あまり英語はうまくないので誤訳御免。
============================================
ここ数週間ソフトウェアアーキテクチャにどのようにアプローチしたらよいかを考えてた。いくつかアプリ開発を経験したけど、将来のプロジェクトで良い仕事をするために、もっともっと勉強したくなった。
このトピックについていくつか記事や本を読んだ。要点を抽出し、最重要事項を一枚のシートにまとめることが目標だ。それを壁に貼っておいて、チラッと見て確認できるようにしたかったんだ。そのシートはソフトウェアをデザインする際の重要事項をコミットする前に、自分自身でよく考えることを強制するんだ。
今日、ついに完成したから印刷して壁に貼っておいたよ！
PDFでダウンロードできるように用意したから、好きなようにしていいよ！
PDFはこちら
それは "良いアイディア" か？
「Avoid "Good Ideas"」からの引用だよ。
"良いアイディア" というのは潜在的に本当に "いいもの" だ。誰しも "悪いもの" を認識しリジェクトすることができる。良いものは、ビジネスに不要なトラブルを引き起こしたり、複雑だったり、悪い影響を与えない。
言い換えれば、これは本当に必要か考えよう、そうしないと徐々に悪化していくぞ、ということ。ソフトウェアの複雑さは指数的に増加する。2つの機能を有すれば、そのコードは2倍以上複雑になる。
DRY. Don't Repeat Yourself
DRY はよく知られたソフトウェアデザインの原則だ。「Pragmatic Programmers」にもこの説明があって、"システムにおいてすべてのナレッジのかけらは単一であり、明白であり、信頼できる表現であるべきである" としている。
ボクはすでにDRYについては本能的に習慣づけてたよ。だけどすごく良い情熱的なアイディアなので、忘れないようにしたいね。
直交性か？（※どうやら独立性をもったアーキテクチャのことらしい？こちらの記事が参考になった2007-03-22）
言い換えれば、どうやってシステムからモジュールやブロックを独立させようか？ということだ。ソフトウェアにおいてモジュール性は重要だ。後の人生を楽にするし、可読性が高まる。
テスト可能か？
システムにおいてどうやってテストするか考えよう。テストが簡単になるようなデザインになってる？テスタビリティはモジュール性、複雑さ、コードスタイルに依存するよ。テストすることは重要だ。マニュアルテストは良いことだ。自動テストはもっといい。
他に方法はあるか？
これはまた「Pragmatic Programmers」から。この本は各チャプターにいいことが書かれてる。Emil-Augste Chartier が "アイディアがひとつしかないことよりも危険なことはない" と言っている。
問題を解決する時に別解があるとハッピーだ。不幸なことに、はじめの解決法はベストじゃないこともしばしばだ。もう一度考えよう、クリエイティブに、違うアプローチをためそう。新しいアイディアが浮かんだ時、次のアイディアは多少よくなって、多分最初のアイディアは急ぎすぎだったと思うんじゃないかな。
あとで修正するときのコストはどれくらい？
決定を採用する前に考慮しよう。プロジェクトの後のフェイズで何が修正のコストになる？この決定は従える？もしその決定が明確じゃなければ、後に修正するとき、それを破壊しないまたは不要な仕事を増やさないでデザインすることができるかい？
もし問題がなかったら？
これは「Don't Be a Problem Solver」からの引用だ。
設計者はすぐさま問題解決しなきゃいけないときがある。その問題はすでに忘れていたことだったり、学んだことがないことだったりする。だから我々は望遠鏡のようにズームイン/アウトしながら問題の骨組みを明らかにして学ばなければいけない。単に与えられたことを受け入れるだけじゃダメだ。
現在起こっている問題にすぐとりかかるまえに、その問題自体を変更できないか考えよう。設計がどうなっているか、自分自身に問題がなかったかを考えよう。そうすることで、エレガントで恒久的な解決法を導くことができるはずだ。
何が事実で何が前提？根拠をドキュメント化しよう。
最後の二つは「Challenge assumptions - especially your own」から。
それぞれの決定において、どのようなトレードオフがあるか（パフォーマンス vs メンテナンス性、コスト vs 開発期間 などなど...）などの根拠を記すことは、ソフトウェアアーキテクチャのベストプラクティスだ。
このプラクティスは各要因をリスト化し、設計デザインにおける決定に影響する前提を目立たせる助けになる。（※訳難しい・・・）時々これらの前提は "歴史的背景"、意見、開発者の言い伝え、FUD（〜かもしれない、と根拠のない恐れを言うこと）が根拠になることがある...
言い換えれば、ソフトウェア設計をデザインしているときには、なぜその決定を下したかの事実と前提を書きだそう、ということだ。前提をチェックしようね。
事実と前提はソフトウェアの柱になる。いずれにせよ基礎はしっかりしよう。
なにか意見や質問があれば、連絡してね！※ただし、英語。
=======================================================
内容について意見があればこちら
http://gorban.org/post/32873465932/software-architecture-cheat-sheet
ここのページの下の方でコメントしたり、筆者のツイッターも公開してるので、そちらで連絡してください。
翻訳についての意見があれば、私に連絡ください。
一応本人の許可とりました。
https://twitter.com/katsuren/status/254081573165621248
https://twitter.com/apparentsoft/status/254093703185051650
