「ベスト プラクティス」について少し衒学的になるのは簡単ですが、コードを書いていて、何かが正しくない、または何かを変更できる可能性があると直感的に感じたときは、よく知られているベスト プラクティスを調べて、私が書いているコードはそれらに準拠しています。SOLIDは、オブジェクト指向プログラミングの原則ですが、他のコンテキストで考えると役立ちます。この場合、関数が単一責任の原則に違反しているように思えます。
優れた設計の最も基本的な原則の 1 つは、次のとおりです。
同じ理由で変化するものを集め、異なる理由で変化するものを分離します。
この原則は、Single Responsibility Principle (SRP) として知られています。要するに、サブシステム、モジュール、クラス、または関数でさえも、変更する理由が 1 つ以上あってはならないということです。
(これはおそらく、この例の関心の分離または他の同様の原則と交換できますが、概念は同じです。)
この場合、関数には 2 つの役割があります。(1) ファイル名に関連付けられた現在の (またはデフォルトの) リストを取得することと、(2) そのリストにデータを追加することです。これらの懸念を分離するための最初のパスは、次のようになります。
function get_current_list(filename, callback) {
fs.exists(filename, function(exists) {
if (exists) {
fs.readFile(filename, function(err, data) {
if (err)
return callback(err);
callback(null, JSON.parse(data));
});
} else
callback(null, []);
});
}
function list_append(filename, doc) {
get_current_list(filename, function(err, list) {
if(err) throw err;
__list_append(filename, list, doc);
});
}
現在、ファイル (またはファイルがない場合は空の配列) 内の現在のリストを取得するget_current_list
ことのみを担当し、それに追加することのみ__list_append
を担当します (そうであると想定されます) 。は、これら 2 つの機能間の単純な統合ポイントになりました。関数はもう少し再利用可能で、より簡単にテストすることもできます (余談ですが、プログラミングへのテスト ファーストまたは TDD アプローチは、これらの種類のことを前もって認識するのに役立ちます)。さらに、inの繰り返しは の繰り返しよりもかなり一般的です。何か別のものに変更する必要がある場合は、1 つの場所でのみ呼び出されるようになりました。list_append
callback
get_current_list
__list_append
__list_append