この記事は「道路を練習プログラマは」第二章では、いくつかの原則をまとめたもので、我々は非常に重要な意義を持っているため、効率的なプログラマーの共通の開発モデルは、遵守する必要が指摘されています。私たちは、すべてのプログラマは、これらの原則を学び、習得しなければならないことをお勧めします。あなたがこの記事の貴重なシリーズを考えるならば、我々は元から学ぶことを奨励、ポンプ活動の本を整理することができます。
DRY原則
ソフトウェア開発プロセスは、プロジェクトが重複したコードの多くを持つことになり、当社の保守作業は、多くの問題を引き起こした場合、維持するために、すべての回で付属しています。たとえば、次のように様々な場所でのコードの一部は、私たちはどこかには変更は、いくつかの不要なミスを引き起こす可能性が忘れてしまった場合は、同時に複数の場所を変更するために、一度変更する必要があります。そこで、著者らは提案 DRY原則- （自分を繰り返さない）自分を繰り返さないでください。
我々は通常、繰り返しシーンの多くを持っているだけでなく、複製ソリューション、以下のいくつかの例を避けるために。
- コード注：私たちはしばしば、コードリガのコメントを説きます。コメントはできません。しかし、我々は、コメントを交換するためのコードでは比較的低レベルの手順については、シニア債の説明を残す必要があります。そうでない場合は、コードの各時刻の注意を修正変更する考え知識の繰り返しは、あります
- コードとドキュメント：ドキュメントを更新することを忘れ更新ドキュメントは、常にコードに遅れをとっているが、コードは頻繁に更新されます。我々はいくつかの支援技術やなどの自己開発技術、使用することができます：APIドキュメント、Javaのドキュメントのようなツール、コードの更新を、ドキュメントがで更新されます
- デザインリピート：私たちは、開始と終了のポイントに基づいて距離を計算することができるので、クラスが始まる座標であるとし少し繰り返し財産上の2点間の距離と組み合わせると、二つの性質の座標を終了
- 一時的なリピート：時々、私たちはプロジェクトのいくつかの一時的なニーズは、コードの一部に使用してもよい行い、我々は一般的に直接コピー使用し、この時間が反復されます。より徹底したアプローチは、我々は、コードをコピーすることなく、必要なときに、自分のキット、直接参照を形成し、より一般的に使用される計算ロジック抽象化されたインタフェースのいくつかを置くことができるということです。たとえば、次のように処理ロジックのループのために必要なほとんどの値のようないくつかの一般的な合計は、軽減機能を抽象化することができません
- 開発者は、繰り返しの間に2つのグループのプロジェクトを開発する二部材の小グループで同じロジックを引き起こす可能性がある一方では、繰り返しを避けるために非常に良いではありません独自の実装を、持っている場合、これは、より一般的な繰り返しです。しかし、私たちは、私たちはより良い部品の一部を開放するためのプラットフォームを整理することができ、チーム間のコミュニケーションを向上させることができます。私はしなかった場合、多くの場合、私はデータの開発を行う際に、データを処理するために使用されるいくつかのUDF、現在のプロジェクトは、私は一般的には準備ができてUDFを見つけることができ、適切なキーワードを検索するために、同社の共通プラットフォームに行くだろう。私はもちろん、前提は、機密コードを必要としない、チーム内の異なるオープンソースプロジェクトのコードを比較することをお勧めします。すべての伝聞がtrueの後、私はしばしば、第二に、上流のデータ処理は、どのようなロジックの後、一方でそれを行う方法の開発に学生を尋ねる通信のコストを増大させ、そして。だから私は、多くの場合、ロジックを見てする必要があります将来的には、上流のコンパイルされたコードに反する多くの時間を節約直接コードを見て、他の誰かに依頼する必要はありません。もちろん、オープンソースはまた、我々は他の人のコード優れた場所から学ぶことができるという利点があります。
直交原則
直交性には相互依存関係やデカップリングではありません。変更は、2つの以上のものを発生し、他のものに影響を与えていない場合は、これらのものは直交しています。プログラミングに対応して、私たちはしばしばあると言う高い凝集および低カップリング。システムの利点は、非常に直交、直交システムは、リスク、低減することができるシステムを変更するコンポーネントは、限りの外部インターフェイスは同じままであるように、構成要素が自由に変更することができ、システム全体が影響を受けません。システムコンポーネントが切り離されているため、直交系の生産性は、独立しているので、個々の成分、並行開発を向上させることができます。バックエンドの学生は、多くの場合、フロントページ、フロントとリアエンドクラスメートコードが相互に依存し絡み合って設定しますいくつかのコードを記述する必要があります前に、例えば、近年では、分離技術の終了前後のより多くの火災がよく、表されます。しかし、分離の終了前後に、ちょうど良い一致を決定する必要があり、フロントとリアのサイド・テクノロジーは、学生が並行開発を開発し、生産性を向上させることができ、切り離すことができます。直交性は維持され、次のいくつかのリストです。
- デザイン：私たちは、階層化アーキテクチャコンポーネントベースのシステムを設計することができます。各層は、そのレベルの抽象化との間の各プロトコルは/以下に提供することを除いて、抽象化を提供する層でスケーラブルなインタフェースが安定して、上部透明の下部アセンブリを変更します
- コード：コードの解体を保つために、我々は他のコンポーネントによって参照されていない、あなたはそれらのアクセス権を制御することができ、ロジックを開く必要はありません、「恥ずかしがり屋」のコードを開発することができます。グローバルデータの使用を避ける、グローバルデータは、カップリングアセンブリのより高度になり、同時に更新された消費者の複数に関する。書き込み機能を避けるために、同様に、同様の機能は、コードを複製することが多い持って、同時に複数の更新するようにコードを変更
- テスト：ユニットテスト中に、ユニットは、ユニットの残りの部分とより大きなシステムの結合は、学生の開発に注意を引き付ける必要があることを示す、システムの残りの大部分を含んだ場合
取消原則
撤回の原則は、システムの特定の部分を変更する必要があるとき、私たちはよく、既存のコードを撤回し、新しい変化に適応する柔軟なことができないということです。需要は、すべての時間を変更されているので、その可逆性がありました。栗のために：私たちは、直接書き込みJDBCコードを検索し変更するには、地元の追加および削除のすべてのニーズを階層設計をしない場合、我々は、データベースの可視化ソフトウェアを開発したと、は、MySQLの初めのニーズに基づいています。私たちのJDBCコードは、ほぼ元に戻すことはできません、この時間はシステムにのみ書き換えることができ、プロジェクトの各モジュールのコードで配布されるので、しかし、ある日、私たちは、行う方法のMongoDBをサポートするために、データの基礎となります。私たちは、抽象の構成要素として、データアクセス層の最初に設計された場合は、単にデータベースを操作するための上位抽象インタフェースを呼び出します。あなたが他のデータベースをサポートする必要がある場合、このことの利点は、データベースにアクセスするための抽象インタフェースコードを準備する当社のデータベースに対してのみサポートされ、そのシステムは、取消可能な性質を持つことになります。実際には、我々は、頻繁に使用するWebプロジェクトのORMフレームワークはまた、取消の原理に基づいて、ORMは、上部透明の下部をチェックするために、オブジェクト、追加、削除するデータベーステーブルをマッピングすることができ、その柔軟性は、基礎となるデータベースを調整します。
トレーサーとプロトタイプ
多くの場合、軍事目標トレーサーに対抗する必要性、それは銃と地元のヒットの間に花火のような証跡を残し、そしてシューター軌道修正を支援するために目標軌道を示すために、暗い場合に使用。実際には、暗い目標我々は、未知システムの顔に開発します。その後、未知のシステムの顔、私たちは多くのドキュメントを作成する場合は、それらをあらゆるニーズを一覧表示、すべての未知の要因を決定しようとするターゲットは、事前に計算されている場合、それは未知であり、暗闇での撮影の多くは、このような状況は、コンピューティングパワーを大量に消費する必要があることは明らかで、目標を達成することはできません。実用的なプログラマは、多くの場合、トレーサー弾を使用することを好みます。トレーサーの強みフィードバックがタイムリーです。例えば：私たちは、複数のRPCシリアライズ形式をサポートするフレームワークは、我々は、システムが起動して実行することができましょう、最初にシステム全体を構築するための単純なシステムのデフォルトのシリアライズフレームワークを開始することができます最高のスタートではありません開発したいです。実行した後、我々はタイムリーなフィードバックの消費者を得ることができ、問題が継続的に反復改善にシリアライズフレームワークの様々な増加、修復されました。
プロトタイプの話に来トレーサー上に導入、私は大学のプロトタイプ開発に接触して、「ソフトウェア工学」を学んで覚えています。より多くのプロトタイプのデモのように、実装コードに焦点を当てていませんが、すぐにできるようなもので、製品の需要を決定することができます。例えば：私たちは、UIシステムのニーズを判断する必要がある、我々はそのコードが標準化を必要としないプロトタイプが実際に高い確率に従っていないので、インタラクティブなインターフェースは、あまりにも美しい必要としない、デモを開発し、最速の開発言語を使用することができますプロジェクトの実施に使用します。
その後、簡単に開発の2つのモードの違いをまとめたもの。トレーサーは、明確な要求の後、私たちは小さいながらも完全に形成されるが、すぐに私たちにさらなる反復を導くためにフィードバックを得るためのシステムを開発することができることを強調しました。トレーサー開発モデルでは、その後のコードに依存初版のコードです。プロトタイプは、この段階の特定のニーズに、より集中され、デモの急速な発展、目的は、プロトタイプシステムに基づいて要件を決定することができることです。基本的なプロトタイプのコードは、実際のシステム開発では使用されませんので、コードは気にしないものをこの段階では、システム、堅牢性と精度の整合性を気にしないでください。
言語とフィールドを見積もります
这节内容我觉得平时应用不多，理解的不深刻，因此就简单总结。领域语言我的理解就是使用（创造）一门规范的伪代码，为什么是伪代码呢？假设我们与产品沟通需求，我们可以使用文字，但我们都知道中华文字博大精深，别人表达的意思跟我们的理解可能不一致，否则的话我们也不需要这么苦逼的加班，当然直接用编程语言沟通更不可行。那么就需要一个中间层的伪代码，既能清晰的表达出需求，又能让产品或者使用不同编程语言的程序员都能看懂。
对于估算这一节，作者介绍了一些常见的预估问题（估算项目时间、流量）的一些指导性意见，但感觉比较偏理论，实操性不强。但给我印象最深的一句话是：在咖啡机旁给出的估算将像咖啡一样回来纠缠你。也就是说估算不等于不假思索的回答，我们可以用 “这个问题我现在答复不了，我回去想下” 之类的话术先应付一下，后续再详细地思考。
小结
本章主要介绍了三个原则中，这三个原则如果在开发中加以总结和利用将对我们高效地开发非常有帮助。DRY 原则避免重复劳动，正交原则避免改动一个组件时牵扯整个系统的维护，可撤销原则避免更换系统某个组件时导致系统崩溃。最后，介绍了曳光弹和原型开发两种快速开发模式，尤其是曳光弹，我比较喜欢用，先小规模、小成本搭建骨架并跑起来，后续再不断地丰富骨肉，希望以上介绍的内容对你日后开发有帮助。
欢迎关注公众号「渡码」，我将分享更多优秀书籍的内容，组织定期抽书活动
