古いプロジェクトに目覚めた
5527 ワード
古いプロジェクトに目覚めた
0 x 01
6月のその時、Thought Worksに入ったばかりで、仕事の上でも多くのことがありません.そして無邪気に騒々しいリズムはずっとこのようなものだと思っています.だから、次の数ヶ月に小さい目標を決めました.中には整理githubにコードを提出しました.しかし、次のいくつかのプロジェクトと北京Nodejsコミュニティのことを思い付かなかったので、私はほとんどこれらの小さい目標をする時間がありませんでした.
先日、ちょうど先端の入門クラスの友達が私にお経を取りに来ました.私は私のrepoの中で走れる彼に似合うプロジェクトを探しました.このプロジェクトを彼にあげましたが、このようなプロジェクトを持ち出したら顔が赤くなりますので、改造が始まりました.
0 x 02
まず、READMEを追加しました.READMEの基本的な機能は来訪者にこのプロジェクトが何をしたかと教えてくれます.もちろん、より完璧なREADMEは、通常以下の部分を含みます.
Installation Example/Usage/Quickstart/Getting Startd Feature FAQ API References/Docs/Community Tests contributing contributors License ほとんどこれだけです.そして残りは主にこのプロジェクトだけの部分です.
gitignore
READMEがあったら、このプロジェクトはまだです.gitignore!gitignoreはプロジェクトの清潔を保証する利器です.すぐに追加しました.gitignoreはどう使いますか?もう一つの文章を書きました.大体紹介しました.興味があれば見てください.ここで、もう一回言ってみます.プロジェクトの中では、普通何かがプッシュされるべきではないです.中心思想とは、プロジェクトの外部依存ライブラリは、プッシュしてrepositoryに行くべきではないということです.なぜですか?このような外部依存ライブラリはすべて私達のプロジェクトとは関係のない独立したライブラリですので、それらをツールバンクの中のツールと見なしてもいいです.私達のプロジェクトはこのツールを使っただけです.しかし、このツールのソースコードは私達のプロジェクトのソースコードと同じコード倉庫にあるべきではありません.ちょうど、私が今回再構築したプロジェクトはいい例です.このプロジェクトの中のdistフォルダにはBootstrapとjQueryのソースコードがあります.ここに提出されるべきです.じゃ私達はどうすればいいですか?方法が多いです.ここで二つ紹介します.最初に、私たちはnpmライブラリが強くなりました.基本的にあるべきものは全部あります.BootstrapとjQueryは全部あります.npmでそれらをインストールして、必要なところで引用します.第二に、npmを使いたくないです.もちろん、bowerというツールでダウンロードすることもできます.これは主にWeb端末のパッケージ管理ツールです.componentsフォルダの下にはもちろん.borcファイルを通してインストールディレクトリを指定することもできます.しかし、npmが天下を支配する今日では、bowerが使うシーンが少なくなりました.ok、どのファイルがgitignoreの常連ですか?
node_modules これは多く説明をしません.中は外部依存ライブラリです.
dist/build これは主に包装した後のリソースフォルダです.フロントエンドのプロジェクトにとって、このフォルダ内のものは直接にNFNGIXに落として代理されます.
coverage これは通常、プロジェクトを実行してカバー率をテストする時に作成されたフォルダです.中にはプロジェクト全体と各ファイルのテストカバー率が見えます.
log/*.log ここは通常、プロジェクト実行時に記録されたログファイルです.
typings このフォルダは私たちがtypescriptを使う時に必要な様々なタイプの声明のところです.
0 x 03
次はソースコードです.コードは、利用可能な前提の下でまず綺麗にするべきです.そうすると、自分の書いたものを気楽にして、他人に見てもらうことができます.だから、私は注釈コードと無効なファイルとdebugのconsoneを整理しました.次にコードの品質です.もう二年近く経ちました.当時のものを見ると、どこも問題だらけだと思います.
まずコードを見てみます.
問題が多いです.一つずつ見ます.
関数名
まず、この関数の名前はjudge_です.exist_barch odeでは、戻り値がBoolean値であることを見て、この方法の主な機能は、着信パラメータを判断するbarcodeが他のオブジェクトで見つけられるかどうかを判断することができます.関数の戻り値や変数の値のタイプがBooleanの場合、私たちは普通is、has、shoultなどの単語で始まる傾向があります.このように、より表意を表します.例えば、ここのjudgeをhasに置き換えればいいです.最後に関数の機能によって新しい名前をつけます.プロモーションbarcodeさん、この名前は素晴らしいですか?
論理
ここのコードロジックは簡単です.一目で何をしているか分かります.まず、promoteは反復可能なオブジェクトで、underscoreのeach方法を使用してpromoteを巡回して、各サブオブジェクトのbarcordesで、パラメータオブジェクトitemのbarcodeと同じ値があるかどうかを調べます.あれば、予め定義されている識別judge(u)を与えます.bar賦課さて、この機能を一言でまとめてみますと、itemの対象となっているbarcodeがpromoteのサブオブジェクトのbarceodesに登場しているかどうかを調べます.ロジックが分かりましたら、コードを見たら、このjudge_が分かります.bar変数名には必ず問題があります.次にeachとfind方法を見てみると、初心者としてundersscore/lodashに提供するインターフェースがよく分かりません.
ps:だから、ここで私はこの工具庫に接触したばかりの友達は先に彼らの文書を素早く、完全に閲覧することができます.どれらのツール方法が提供されているかを知ることができます.このように仕事で出会っても、文書を早く調べて使うことができます.ここではLodashをオススメしますが、なぜですか?lodashはある程度より優れた性能を持っていますので、より多くのツールとより速い更新を提供します.もっと知りたいなら、自分で試してみてもいいです.
一つの値が他のオブジェクトに存在するかどうかを調べます.someまたはincludies、前者は反復可能なオブジェクトのサブオブジェクトに対してマッチングチェックを行います.オブジェクトなどのマッチングやkey値チェックに使用して、identity functionをサポートします.後者もまた、反復可能なオブジェクトのサブ要素を検証し、identityをサポートせず、value値チェックに使用する.加えて、私たちはcontextの理解を、元のコードを再構成することができます.
まず、行数の縮小は最も直観的な感じであり、その次に、意味的には損失がなく、本文を読むように分かりやすい.じゃ、再構築はここで終わりますか?
0 x 04
再構成はまだ始まったばかりです.正しい再構成方式は、既存のコードにテストを加えるべきです.これでやっと安心して再構成できます.自分の再構成によってコードの挙動が以前の状況と一致しないことを心配する必要はありません.だから、前述のTDDは捕まえられるじゃないですか?
ps:新年新気象[Yeah!]
0 x 01
6月のその時、Thought Worksに入ったばかりで、仕事の上でも多くのことがありません.そして無邪気に騒々しいリズムはずっとこのようなものだと思っています.だから、次の数ヶ月に小さい目標を決めました.中には整理githubにコードを提出しました.しかし、次のいくつかのプロジェクトと北京Nodejsコミュニティのことを思い付かなかったので、私はほとんどこれらの小さい目標をする時間がありませんでした.
先日、ちょうど先端の入門クラスの友達が私にお経を取りに来ました.私は私のrepoの中で走れる彼に似合うプロジェクトを探しました.このプロジェクトを彼にあげましたが、このようなプロジェクトを持ち出したら顔が赤くなりますので、改造が始まりました.
0 x 02
まず、READMEを追加しました.READMEの基本的な機能は来訪者にこのプロジェクトが何をしたかと教えてくれます.もちろん、より完璧なREADMEは、通常以下の部分を含みます.
Installation Example/Usage/Quickstart/Getting Startd Feature FAQ API References/Docs/Community Tests contributing contributors License ほとんどこれだけです.そして残りは主にこのプロジェクトだけの部分です.
gitignore
READMEがあったら、このプロジェクトはまだです.gitignore!gitignoreはプロジェクトの清潔を保証する利器です.すぐに追加しました.gitignoreはどう使いますか?もう一つの文章を書きました.大体紹介しました.興味があれば見てください.ここで、もう一回言ってみます.プロジェクトの中では、普通何かがプッシュされるべきではないです.中心思想とは、プロジェクトの外部依存ライブラリは、プッシュしてrepositoryに行くべきではないということです.なぜですか?このような外部依存ライブラリはすべて私達のプロジェクトとは関係のない独立したライブラリですので、それらをツールバンクの中のツールと見なしてもいいです.私達のプロジェクトはこのツールを使っただけです.しかし、このツールのソースコードは私達のプロジェクトのソースコードと同じコード倉庫にあるべきではありません.ちょうど、私が今回再構築したプロジェクトはいい例です.このプロジェクトの中のdistフォルダにはBootstrapとjQueryのソースコードがあります.ここに提出されるべきです.じゃ私達はどうすればいいですか?方法が多いです.ここで二つ紹介します.最初に、私たちはnpmライブラリが強くなりました.基本的にあるべきものは全部あります.BootstrapとjQueryは全部あります.npmでそれらをインストールして、必要なところで引用します.第二に、npmを使いたくないです.もちろん、bowerというツールでダウンロードすることもできます.これは主にWeb端末のパッケージ管理ツールです.componentsフォルダの下にはもちろん.borcファイルを通してインストールディレクトリを指定することもできます.しかし、npmが天下を支配する今日では、bowerが使うシーンが少なくなりました.ok、どのファイルがgitignoreの常連ですか?
node_modules これは多く説明をしません.中は外部依存ライブラリです.
dist/build これは主に包装した後のリソースフォルダです.フロントエンドのプロジェクトにとって、このフォルダ内のものは直接にNFNGIXに落として代理されます.
coverage これは通常、プロジェクトを実行してカバー率をテストする時に作成されたフォルダです.中にはプロジェクト全体と各ファイルのテストカバー率が見えます.
log/*.log ここは通常、プロジェクト実行時に記録されたログファイルです.
typings このフォルダは私たちがtypescriptを使う時に必要な様々なタイプの声明のところです.
0 x 03
次はソースコードです.コードは、利用可能な前提の下でまず綺麗にするべきです.そうすると、自分の書いたものを気楽にして、他人に見てもらうことができます.だから、私は注釈コードと無効なファイルとdebugのconsoneを整理しました.次にコードの品質です.もう二年近く経ちました.当時のものを見ると、どこも問題だらけだと思います.
まずコードを見てみます.
1 function judge_exist_barcode(item, promote) {
2 var judge_bar;
3 _.each(promote, function (pro) {
4 judge_bar = _.find(pro.barcodes, function (p) {
5 if (p == item.barcode) {
6 return p;
7 }
8 });
9 });
10 return judge_bar != undefined
11 }問題が多いです.一つずつ見ます.
関数名
まず、この関数の名前はjudge_です.exist_barch odeでは、戻り値がBoolean値であることを見て、この方法の主な機能は、着信パラメータを判断するbarcodeが他のオブジェクトで見つけられるかどうかを判断することができます.関数の戻り値や変数の値のタイプがBooleanの場合、私たちは普通is、has、shoultなどの単語で始まる傾向があります.このように、より表意を表します.例えば、ここのjudgeをhasに置き換えればいいです.最後に関数の機能によって新しい名前をつけます.プロモーションbarcodeさん、この名前は素晴らしいですか?
論理
ここのコードロジックは簡単です.一目で何をしているか分かります.まず、promoteは反復可能なオブジェクトで、underscoreのeach方法を使用してpromoteを巡回して、各サブオブジェクトのbarcordesで、パラメータオブジェクトitemのbarcodeと同じ値があるかどうかを調べます.あれば、予め定義されている識別judge(u)を与えます.bar賦課さて、この機能を一言でまとめてみますと、itemの対象となっているbarcodeがpromoteのサブオブジェクトのbarceodesに登場しているかどうかを調べます.ロジックが分かりましたら、コードを見たら、このjudge_が分かります.bar変数名には必ず問題があります.次にeachとfind方法を見てみると、初心者としてundersscore/lodashに提供するインターフェースがよく分かりません.
ps:だから、ここで私はこの工具庫に接触したばかりの友達は先に彼らの文書を素早く、完全に閲覧することができます.どれらのツール方法が提供されているかを知ることができます.このように仕事で出会っても、文書を早く調べて使うことができます.ここではLodashをオススメしますが、なぜですか?lodashはある程度より優れた性能を持っていますので、より多くのツールとより速い更新を提供します.もっと知りたいなら、自分で試してみてもいいです.
一つの値が他のオブジェクトに存在するかどうかを調べます.someまたはincludies、前者は反復可能なオブジェクトのサブオブジェクトに対してマッチングチェックを行います.オブジェクトなどのマッチングやkey値チェックに使用して、identity functionをサポートします.後者もまた、反復可能なオブジェクトのサブ要素を検証し、identityをサポートせず、value値チェックに使用する.加えて、私たちはcontextの理解を、元のコードを再構成することができます.
1 function has_promotional_barcode(item, promotions) {
2 return _.some(promotions, function (promotion) {
3 return _.include(promotion.barcodes, item.barcode);
4 });
5 }まず、行数の縮小は最も直観的な感じであり、その次に、意味的には損失がなく、本文を読むように分かりやすい.じゃ、再構築はここで終わりますか?
0 x 04
再構成はまだ始まったばかりです.正しい再構成方式は、既存のコードにテストを加えるべきです.これでやっと安心して再構成できます.自分の再構成によってコードの挙動が以前の状況と一致しないことを心配する必要はありません.だから、前述のTDDは捕まえられるじゃないですか?
ps:新年新気象[Yeah!]