Closure Library の提供する機能は膨大です。
この作業によって後の作業を省略することができるかもしれません。
ここに時間をかける価値は十分にあります。
ここに時間をかけずに泣きを見た人は 車輪の再発明やっちゃった！ まで事例をお寄せください。
Closure おじさんが慰めてくれます。
機能を調べる場合には逆引き機能検索・クックブックが役に立つでしょう。
調査結果とその対応は以下のようになります。
求めている機能そのままのモジュールが Closure Library に存在するか
コーディング・デバッグの必要なし
求めている機能の一部を Closure Library のモジュールによって実現できるか
クラスであれば継承を考える
クラスでなければ部分適用を考える
求めている機能がない
求めている機能に近い部分の設計・作法を気に留めておく
あなたが必要だと思った機能が既に存在する可能性は少なくありません（とくに MVC パターンのモデル（コレクション）に相当するものはたいてい揃っています）。
もし必要な機能が Closure Library によって提供されている場合、必ずテスト用の HTML が付属しています。
したがって、あなたがコーディングする必要もなければテストをする必要もありません。
また、部分的にあてはまるのであれば継承・部分適用によってコーディング・デバッグの手間は大幅に短縮されます（この場合はテストが必要なくなるわけではありません）。
もし完全にあてはまらないにしても、調べた箇所の設計・コーディング作法を気に留めておくと Closure Library と相性のよいコーディングに自然となっていきます。
Closure Library の慣例では、モジュールごとに名前空間とフォルダ（とテストコード）を分けます。
つまり設計段階でモジュールの名前・所属するメンバを決めておく必要があります。
設計フェーズで検討したディレクトリ構造を構築します。
プロジェクト名が Foo で、モジュール名が Bar であれば名前空間は、 foo.bar とします。
このとき、ディレクトリ構成は foo / bar / any_class.js ... というようにします。
ファイルの切り分けは 1 クラス=1 ファイルです。
ファイル名はクラス名をすべて小文字にして、単語の区切りを _ （アンダーバー）とするのが慣例です。
テスト駆動開発の場合は、まずテストを書きます。
テスト駆動開発でない場合は次に進んでください。
テスト駆動開発の詳細なワークフローはこちら。
コードを書きます。
このとき、コードと同時にドキュメントも書くことが推奨されています（必須ではありません）。
戻り値・引数の型や継承元の指定を書けば Closure Linter や Closure Compiler がミスを発見できるようになるからです。
ドキュメントは下のようにコードの直前にコメントで書きます。
/** * 配列が空かどうかを判定する。 * @param {goog.array.ArrayLike} arr 判定したい配列。 * @return {boolean} 空であれば true 。 */ goog.array.isEmpty = function(arr) { return arr.length == 0; };
このコメントは Closure Linter や Closure Compiler でエラーチェックに使えるほかに、JsDoc などのツールを使って自動的に API ドキュメントを生成することができるようになります。
このドキュメントの書き方はこちらから。
Closure Library の構文チェックツール Closure Linter を使ってコードのエラーチェックをおこないます。
strict モードではドキュメントの記述形式のチェックもおこないます。
JsDoc を使ってドキュメントを生成します。
実際にコードを動かすためには、依存関係解決用のスクリプトが必要になります。
このスクリプトは depsWriter.py で自動的に生成することができます。
依存関係の解決の仕方の詳細はこちらから。
テストが通るかどうかをチェックします。