12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
テスト駆動開発：実はそれは設計技術です
テスト駆動開発（TDD）は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか？失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは本当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演
なぜアーキテクチャ図を必要とするのか？
正しいドキュメントの適切なバランスを見つけるために、次のエクササイズをチームで試してみよう。まず各同僚に、技術ドキュメントに本当に必要なもの、そこに含めるべき図の種類について質問する。彼らの意見を集約して、ブレインストーミングを実施し、チームにとって本当に必要なものについて合意をとる。チームの外部に、追加の要求を持つ影響力のあるステークホルダーが1、2名いるかもしれない。彼らのニーズを考慮することもまた、アーキテクトの責務だ。以上に基づいて、ステークホルダーのニーズを満たす適切な量とレベルの技術ドキュメントを作成する。もし開発者がドキュメントの真の価値を理解し、その価値を保つことに関心を持てるなら、進んでドキュメントに貢献し、適切に保守してくれるだろう。最終的に、全員がハッピーになる。しかし、もしその必要性を理解しなかったり、気にしないのなら、それについてはほとんど忘れてしまって構わない。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
