私はバベルES6でコーディングしている上級フロントエンド開発者です。アプリの一部はAPI呼び出しを行い、API呼び出しから返されるデータモデルに基づいて、特定のフォームに入力する必要があります。
これらのフォームは二重リンクリストに格納されます（バックエンドがデータの一部が無効であると言った場合、ユーザーを混乱させた1ページにすばやく戻し、ターゲットを元に戻すことができます。リスト。）
とにかく、ページを追加するために使用される関数の束があり、私はあまりにも賢いのだろうかと思っています。これは基本的な概要にすぎません-実際のアルゴリズムは非常に複雑で、さまざまなページやページタイプがありますが、例を挙げて説明します。
これが、初心者のプログラマーが処理する方法です。
export const addPages = (apiData) => {
let pagesList = new PagesList();
if(apiData.pages.foo){
pagesList.add('foo', apiData.pages.foo){
}
if (apiData.pages.arrayOfBars){
let bars = apiData.pages.arrayOfBars;
bars.forEach((bar) => {
pagesList.add(bar.name, bar.data);
})
}
if (apiData.pages.customBazes) {
let bazes = apiData.pages.customBazes;
bazes.forEach((baz) => {
pagesList.add(customBazParser(baz));
})
}
return pagesList;
}さて、よりテストしやすくするために、これらのifステートメントをすべて取り、それらを分離し、スタンドアロンの機能にした後、それらをマップします。
さて、テスト可能というのは一つのことですが、読みやすいので、ここでは読みにくくしているのでしょうか。
// file: '../util/functor.js'
export const Identity = (x) => ({
value: x,
map: (f) => Identity(f(x)),
})
// file 'addPages.js'
import { Identity } from '../util/functor';
export const parseFoo = (data) => (list) => {
list.add('foo', data);
}
export const parseBar = (data) => (list) => {
data.forEach((bar) => {
list.add(bar.name, bar.data)
});
return list;
}
export const parseBaz = (data) => (list) => {
data.forEach((baz) => {
list.add(customBazParser(baz));
})
return list;
}
export const addPages = (apiData) => {
let pagesList = new PagesList();
let { foo, arrayOfBars: bars, customBazes: bazes } = apiData.pages;
let pages = Identity(pagesList);
return pages.map(foo ? parseFoo(foo) : x => x)
.map(bars ? parseBar(bars) : x => x)
.map(bazes ? parseBaz(bazes) : x => x)
.value
}ここに私の懸念があります。私の一番下には、より組織です。コード自体は、単独でテスト可能な小さなチャンクに分割されます。しかし、私が考えているのは、Identityファンクターの使用、カリー化、または3項ステートメントなどの概念に未使用のジュニア開発者としてそれを読む必要があった場合、後者のソリューションが何をしているのかを理解することさえできますか？時々「間違った、より簡単な」方法で物事を行う方が良いでしょうか？
OMG-1999年から業界で活動し、1983年からコーディングを行っています。あなたは最も有害な開発者です。「賢い」と思うのは、実際には「高価」で「保守が難しい」、「バグの原因」と呼ばれ、ビジネス環境には場所がありません。最初の例はシンプルで理解しやすく、動作しますが、2番目の例は複雑で理解しにくく、証明できるほど正確ではありません。このようなことをやめてください。現実の世界には当てはまらない学術的な意味を除けば、それはましです。
—
user1068
ブライアン・カーニングハンをここで引用したい。「誰もがデバッグは、最初にプログラムを書くよりも2倍難しいことを知っている。だから、あなたがそれを書くときにできる限り賢いなら、どのようにそれをデバッグするだろうか？ 」- en.wikiquote.org/wiki/Brian_Kernighan、第2版、第2章/「プログラミングスタイルの要素」
—
MarkusSchaber
@Logister Coolnessは、単純さほど主要な目的ではありません。ここでの異議は、コードの推論を難しくし、予期しないコーナーケースを含む可能性が高いため、正当性の敵（確実に最大の懸念）である不必要な複雑さです。実際にテストする方が簡単であるという以前の主張に対する懐疑論を考えると、このスタイルに対する説得力のある議論は見ていません。セキュリティに関する最小限の特権のルールと同様に、おそらく、強力な言語機能を使用して簡単なことを行うことに注意する必要があるという経験則があるかもしれません。
—
-sdenham
コードはジュニアコードのように見えます。先輩が最初の例を書くことを期待しています。
—
sed
Babel ES6