क्या मैं भी जूनियर देवों द्वारा पढ़ा जा सकने वाला 'चतुर' हूँ? मेरे जेएस में बहुत कार्यात्मक प्रोग्रामिंग? [बन्द है]

Question

मैं सीनियर फ्रंट-एंड देव हूं, बैबल ईएस 6 में कोडिंग करता हूं। हमारे ऐप का एक हिस्सा एपीआई कॉल करता है, और डेटा मॉडल के आधार पर हम एपीआई कॉल से वापस आ जाते हैं, कुछ फॉर्म भरने की आवश्यकता होती है।

उन प्रपत्रों को एक दोहरी-लिंक की गई सूची में संग्रहीत किया जाता है (यदि बैक-एंड का कहना है कि कुछ डेटा अमान्य है, तो हम उपयोगकर्ता को तुरंत उस एक पेज पर वापस ला सकते हैं, जिसे उन्होंने गड़बड़ कर दिया था और फिर उन्हें लक्ष्य पर वापस ले लिया, बस संशोधित करके सूची।)

वैसे भी, पृष्ठों को जोड़ने के लिए उपयोग किए जाने वाले फ़ंक्शंस का एक समूह है, और मैं सोच रहा हूं कि क्या मैं बहुत चालाक हूं। यह सिर्फ एक बुनियादी अवलोकन है - वास्तविक एल्गोरिथ्म बहुत अधिक जटिल है, विभिन्न पृष्ठों और पृष्ठ प्रकारों के टन के साथ, लेकिन यह आपको एक उदाहरण देगा।

यह है, मुझे लगता है, एक नौसिखिया प्रोग्रामर इसे संभाल लेंगे।

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;
}

अब, अधिक परीक्षण योग्य होने के लिए, मैंने उन सभी को लिया है यदि कथन और उन्हें अलग-अलग किया जाता है, अकेले कार्य करते हैं, और फिर मैं उन पर मैप करता हूं।

अब, परीक्षण करने योग्य एक चीज है, लेकिन इतना पठनीय है और मुझे आश्चर्य है कि अगर मैं चीजों को यहां कम पठनीय बना रहा हूं।

// 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

}

यहां मेरी चिंता है। करने के लिए मुझे नीचे अधिक संगठित है। कोड ही छोटे टुकड़ों में टूट गया है जो अलगाव में परीक्षण योग्य हैं। लेकिन मैं सोच रहा हूँ: अगर मुझे एक जूनियर डेवलपर के रूप में पढ़ना था, तो आइडेंटिटी फंक्शनलर्स, क्यूरिंग, या टर्नरी स्टेटमेंट्स का उपयोग करने जैसी अवधारणाओं के लिए अप्रयुक्त है, क्या मैं यह भी समझ पाऊंगा कि बाद वाला समाधान क्या कर रहा है? क्या कभी-कभी चीजों को "गलत, आसान" तरीके से करना बेहतर होता है?

Comments

किसी ऐसे व्यक्ति के रूप में, जिसके पास जेएस में केवल 10 साल की स्व-शिक्षा है, मैं अपने आप को एक जूनियर Babel ES6

— मानूंगा

OMG - 1999 से उद्योग में सक्रिय है और 1983 से कोडिंग कर रहा है, और आप डेवलपर के सबसे हानिकारक प्रकार हैं। आपको लगता है कि "चतुर" वास्तव में "महंगा" और "बनाए रखने के लिए कठिन" और "कीड़े का एक स्रोत" कहा जाता है और इसका कारोबारी माहौल में कोई स्थान नहीं है। पहला उदाहरण सरल है, समझने में आसान है और यह काम करता है जबकि दूसरा उदाहरण जटिल है, समझने में कठिन है, और सही रूप से सही नहीं है। कृपया इस तरह का काम करना बंद करें। यह बेहतर नहीं है, शायद कुछ शैक्षणिक अर्थों को छोड़कर जो वास्तविक दुनिया पर लागू नहीं होता है।

— user1068

मैं बस यहां ब्रायन केरिंगन को उद्धृत करना चाहता हूं: "हर कोई जानता है कि डिबगिंग पहले स्थान पर एक कार्यक्रम लिखने के रूप में दोगुना कठिन है। इसलिए यदि आप इसे लिखने के रूप में होशियार हो सकते हैं, तो आप इसे कैसे डिबग करेंगे? " - en.wikiquote.org/wiki/Brian_Kernighan / "द एलीमेंट्स ऑफ़ प्रोग्रामिंग स्टाइल", द्वितीय संस्करण, अध्याय 2

— मार्कसचैबर

@ लॉजिस्टर शीतलता सादगी से अधिक एक प्राथमिक उद्देश्य नहीं है। आपत्ति यहाँ है नि: शुल्क जटिलता है, जो शुद्धता के दुश्मन (निश्चित रूप से एक प्राथमिक चिंता का विषय) है, क्योंकि इसके बारे में तर्क करने कोड कठिन और अधिक अप्रत्याशित कोने मामलों शामिल होने की संभावना बनाता है। दावों के बारे में मेरे पूर्व-संशयवाद को देखते हुए कि यह वास्तव में परीक्षण करना आसान है, मैंने इस शैली के लिए कोई ठोस तर्क नहीं देखा है। कम से कम विशेषाधिकार सुरक्षा के नियम के साथ समानता में, शायद अंगूठे का एक नियम हो सकता है जो कहता है कि साधारण चीजों को करने के लिए शक्तिशाली भाषा सुविधाओं का उपयोग करने से सावधान रहना चाहिए।

— श्रीधाम

आपका कोड जूनियर कोड जैसा दिखता है। मैं एक वरिष्ठ से पहला उदाहरण लिखने की अपेक्षा करूंगा।

— sed

Answer 1

आपके कोड में, आपने कई परिवर्तन किए हैं:

• खेतों तक पहुंचने के लिए विनाशकारी असाइनमेंट pagesएक अच्छा बदलाव है।
• parseFoo()कार्यों आदि को निकालना संभवतः एक अच्छा बदलाव है।
• एक फ़नकार पेश करना ... बहुत भ्रामक है।

सबसे भ्रामक भागों में से एक यहाँ है कि आप कैसे कार्यात्मक और अनिवार्य प्रोग्रामिंग का मिश्रण कर रहे हैं। अपने फ़ंक्टर के साथ आप वास्तव में डेटा नहीं बदल रहे हैं, आप इसका उपयोग विभिन्न कार्यों के माध्यम से एक परिवर्तनशील सूची को पारित करने के लिए कर रहे हैं । यह बहुत उपयोगी अमूर्त की तरह नहीं लगता है, हमारे पास इसके लिए पहले से ही चर हैं। वह चीज़ जो संभवतः अमूर्त होनी चाहिए थी - यदि वह मौजूद है तो केवल उस वस्तु को पार्स करना - अभी भी आपके कोड में स्पष्ट रूप से मौजूद है, लेकिन अब हमें कोने के आसपास सोचना होगा। उदाहरण के लिए, यह कुछ हद तक गैर-स्पष्ट है जो parseFoo(foo)एक फ़ंक्शन लौटाएगा। जावास्क्रिप्ट आपके पास यह सूचित करने के लिए एक स्थिर प्रकार की प्रणाली नहीं है कि क्या यह कानूनी है, इसलिए इस तरह का कोड वास्तव में एक बेहतर नाम ( makeFooParser(foo)) के बिना त्रुटि प्रवण है । मुझे इस आक्षेप में कोई लाभ नहीं दिखाई दे रहा है।

मैं इसके बजाय क्या देखने की उम्मीद करूंगा:

if (foo) parseFoo(pages, foo);
if (bars) parseBar(pages, bars);
if (bazes) parseBaz(pages, bazes);
return pages;

लेकिन यह आदर्श भी नहीं है, क्योंकि कॉल साइट से यह स्पष्ट नहीं है कि आइटम को पेज सूची में जोड़ा जाएगा। यदि इसके बजाय पार्सिंग कार्य शुद्ध हैं और एक (संभवतया खाली) सूची लौटाते हैं, जिसे हम स्पष्ट रूप से पृष्ठों में जोड़ सकते हैं, तो यह हो सकता है:

pages.addAll(parseFoo(foo));
pages.addAll(parseBar(bars));
pages.addAll(parseBaz(bazes));
return pages;

जोड़ा गया लाभ: आइटम खाली होने पर क्या करना है इसके बारे में तर्क अब व्यक्तिगत पार्सिंग कार्यों में ले जाया गया है। यदि यह उचित नहीं है, तो आप अभी भी सशर्त परिचय कर सकते हैं। pagesसूची की परिवर्तनशीलता अब एक से अधिक फ़ंक्शन में एक साथ खींची जाती है, बजाय इसे कई कॉल में फैलाने के। गैर-स्थानीय म्यूटेशन से बचना फंक्शनल नामों जैसे अमूर्तताओं की तुलना में कार्यात्मक प्रोग्रामिंग का एक बड़ा हिस्सा है Monad।

तो हाँ, आपका कोड बहुत चालाक था। कृपया अपनी चालाकी को चतुर कोड न लिखने के लिए लागू करें, लेकिन चतुर चतुरता की आवश्यकता से बचने के लिए चतुर तरीके खोजने के लिए। सबसे अच्छे डिजाइन फैंसी नहीं दिखते हैं , लेकिन जो भी उन्हें देखता है उसे स्पष्ट दिखाई देता है। और अच्छा अमूर्तता प्रोग्रामिंग को सरल बनाने के लिए होती है, न कि अतिरिक्त परतों को जोड़ने के लिए जिन्हें मुझे अपने दिमाग में पहले से खोलना पड़ता है (यहाँ, यह पता लगाना कि फ़नकार एक चर के बराबर है, और प्रभावी ढंग से elided किया जा सकता है)।

करें: संदेह में हैं, तो आपके कोड सरल और बेवकूफ (KISS सिद्धांत) रहते हैं।

Comments

एक समरूपता के दृष्टिकोण से, क्या let pages = Identity(pagesList)अलग है parseFoo(foo)? कि यह देखते हुए, मैं शायद होता ... {Identity(pagesList), parseFoo(foo), parseBar(bar)}.flatMap(x -> x)।

— ArTs

यह समझाने के लिए धन्यवाद कि मैप की गई सूची (मेरी अप्रशिक्षित आंख के लिए) जमा करने के लिए तीन नेस्टेड लैम्ब्डा एक्सप्रेशन होना थोड़ा बहुत चालाक हो सकता है ।

— थोरबजोरन रेव एंडरसन

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— यानि

शायद एक धाराप्रवाह शैली आपके दूसरे उदाहरण में अच्छा काम करेगी?

— user1068

Answer 2

यदि आप संदेह में हैं, तो यह शायद बहुत चालाक है! दूसरा उदाहरण भावों के साथ आकस्मिक जटिलता का परिचय देता है foo ? parseFoo(foo) : x => x, और कुल मिलाकर कोड अधिक जटिल है जिसका मतलब है कि इसका पालन करना कठिन है।

कथित लाभ, कि आप व्यक्तिगत रूप से विखंडन का परीक्षण कर सकते हैं, बस अलग-अलग कार्यों में आसानी से प्राप्त किया जा सकता है। और दूसरे उदाहरण में आप अलग-अलग पुनरावृत्तियों को जोड़ते हैं, इसलिए आपको वास्तव में कम अलगाव मिलता है।

सामान्य रूप से कार्यात्मक शैली के बारे में आपकी भावनाएं, यह स्पष्ट रूप से एक उदाहरण है जहां यह कोड को अधिक जटिल बनाता है।

मुझे एक चेतावनी का संकेत मिलता है जिसमें आप "नौसिखिया डेवलपर्स" के साथ सरल और सीधा कोड जोड़ते हैं। यह एक खतरनाक मानसिकता है। मेरे अनुभव में यह विपरीत है: नौसिखिया डेवलपर्स अत्यधिक जटिल और चतुर कोड के लिए प्रवण हैं, क्योंकि इसे सबसे सरल और स्पष्ट समाधान देखने में सक्षम होने के लिए अधिक अनुभव की आवश्यकता होती है।

"चतुर कोड" के खिलाफ सलाह वास्तव में इस बारे में नहीं है कि क्या कोड उन्नत अवधारणाओं का उपयोग करता है या नहीं जो एक नौसिखिया समझ नहीं सकता है। बल्कि यह कोड लिखने के बारे में है जो आवश्यकता से अधिक जटिल या जटिल है । यह कोड को सभी के लिए अनुसरण करने के लिए कठिन बनाता है , नौसिखियों और विशेषज्ञों को समान रूप से, और शायद कुछ महीनों के लिए लाइन के नीचे भी।

Comments

"नौसिखिया डेवलपर्स अत्यधिक जटिल और चतुर कोड के लिए प्रवण होते हैं, क्योंकि इसे सरलतम और स्पष्ट समाधान देखने में सक्षम होने के लिए अधिक अनुभव की आवश्यकता होती है" आप के साथ अधिक सहमत नहीं हो सकते। विलक्षण उत्तर!

— बोनीफेसियो

ओवरली कॉम्प्लेक्स कोड भी काफी निष्क्रिय-आक्रामक है। आप जानबूझकर ऐसा कोड तैयार कर रहे हैं जिसे कुछ अन्य लोग आसानी से पढ़ सकते हैं या डिबग कर सकते हैं ... जिसका अर्थ है आपके लिए नौकरी की सुरक्षा, और आपकी अनुपस्थिति में बाकी सभी के लिए नरक। आप पूरी तरह से लैटिन में अपने तकनीकी दस्तावेज भी लिख सकते हैं।

— इवान

मुझे नहीं लगता कि चालाक कोड हमेशा एक दिखावा है। कभी-कभी यह स्वाभाविक लगता है, और केवल एक दूसरे निरीक्षण पर हास्यास्पद लगता है।

मैंने "दिखावा" के बारे में वाक्यांश को हटा दिया है क्योंकि यह इरादा से अधिक न्यायपूर्ण लग रहा था।

— जैक्सबी

@ बेली - मुझे लगता है कि कोड समीक्षा के महत्व पर जोर दिया गया है; कोडर के लिए स्वाभाविक और सीधा महसूस होता है, खासकर जब धीरे-धीरे उस तरह से विकसित होता है, तो एक समीक्षक को आसानी से समझा जा सकता है। कोड तब तक समीक्षा पारित नहीं करता है जब तक कि दोषी को हटाने के लिए फिर से शुरू / फिर से लिखा नहीं जाता है।

— मायल्स

Answer 3

मेरा यह जवाब थोड़ा देर से आता है, लेकिन मैं अभी भी इसमें झंकार करना चाहता हूं। सिर्फ इसलिए कि आप नवीनतम ES6 तकनीकों का उपयोग कर रहे हैं या सबसे लोकप्रिय प्रोग्रामिंग प्रतिमान का उपयोग करने का मतलब यह नहीं है कि आपका कोड अधिक सही है, या उस जूनियर का कोड गलत है। कार्यात्मक प्रोग्रामिंग (या किसी अन्य तकनीक) का उपयोग तब किया जाना चाहिए जब वास्तव में इसकी आवश्यकता हो। यदि आप हर समस्या में नवीनतम प्रोग्रामिंग तकनीकों को रटने के लिए सबसे कठिन मौका खोजने की कोशिश करते हैं, तो आप हमेशा एक अधिक इंजीनियर समाधान के साथ समाप्त होंगे।

एक कदम पीछे हटें, और उस समस्या को मौखिक रूप से बताने का प्रयास करें जिसे आप एक दूसरे के लिए हल करने का प्रयास कर रहे हैं। संक्षेप में, आप बस एक फ़ंक्शन addPagesको apiDataकुंजी-मूल्य जोड़े के एक सेट में अलग-अलग हिस्सों में बदलना चाहते हैं , फिर उन सभी को जोड़ दें PagesList।

और अगर यह सब वहां है , तो इनपुट पार्सिंग के identity functionसाथ ternary operatorया उपयोग करने के functorलिए परेशान क्यों है ? इसके अलावा, आपको भी क्यों लगता है कि यह एक उचित दृष्टिकोण है functional programmingजो दुष्प्रभाव का कारण बनता है (सूची को बदलकर)? क्यों उन सभी चीजों, जब आप की जरूरत है बस यह है:

const processFooPages = (foo) => foo ? [['foo', foo]] : [];
const processBarPages = (bar) => bar ? bar.map(page => [page.name, page.data]) : [];
const processBazPages = (baz) => baz ? baz.map(page => [page.id, page.content]) : [];

const addPages = (apiData) => {
  const list = new PagesList();
  const pages = [].concat(
    processFooPages(apiData.pages.foo),
    processBarPages(apiData.pages.arrayOfBars),
    processBazPages(apiData.pages.customBazes)
  );
  pages.forEach(([pageName, pageContent]) => list.addPage(pageName, pageContent));

  return list;
}

(एक runnable jsfiddle यहाँ )

जैसा कि आप देख सकते हैं, यह दृष्टिकोण अभी भी उपयोग करता है functional programming, लेकिन मॉडरेशन में। यह भी ध्यान दें कि चूंकि सभी 3 परिवर्तन कार्यों में कोई दुष्प्रभाव नहीं होता है, इसलिए वे परीक्षण के लिए आसान नहीं हैं। कोड addPagesभी तुच्छ और निराधार है कि नौसिखिया या विशेषज्ञ केवल एक नज़र से समझ सकते हैं।

अब, इस कोड की तुलना ऊपर के साथ जो आप कर रहे हैं, क्या आप अंतर देखते हैं? निस्संदेह, functional programmingऔर ईएस 6 वाक्यविन्यास शक्तिशाली हैं, लेकिन यदि आप इन तकनीकों के साथ समस्या को गलत तरीके से काटते हैं, तो आप भी गड़बड़ कोड के साथ समाप्त हो जाएंगे।

यदि आप समस्या में नहीं भागते हैं, और सही तकनीकों को सही स्थानों पर लागू करते हैं, तो आपके पास ऐसा कोड हो सकता है जो प्रकृति में कार्यात्मक हो, जबकि अभी भी सभी टीम के सदस्यों द्वारा बहुत व्यवस्थित और बनाए रखा गया है। ये विशेषताएँ परस्पर-अनन्य नहीं हैं।

Comments

इस व्यापक प्रसार वाले रवैये को इंगित करने के लिए +1 (जरूरी नहीं कि ओपी पर लागू हो): "सिर्फ इसलिए कि आप नवीनतम ES6 तकनीकों का उपयोग कर रहे हैं या सबसे लोकप्रिय प्रोग्रामिंग प्रतिमान का उपयोग करने के लिए जरूरी नहीं है कि आपका कोड अधिक सही हो, या कि जूनियर का कोड गलत है। "

— जियोर्जियो

+1। बस एक छोटी सी पांडित्यपूर्ण टिप्पणी, आप उस निर्भरता को दूर करने के लिए _.concat के बजाय प्रसार (...) ऑपरेटर का उपयोग कर सकते हैं।

— योतेंगो यूएनएलसीडी

@YoTengoUnLCD आह, अच्छी पकड़। अब आप जानते हैं कि मैं और मेरी टीम अभी भी हमारे कुछ lodashउपयोग को रद्द करने की यात्रा पर हैं। उस कोड का उपयोग कर सकते हैं spread operator, या यहां तक ​​कि [].concat()अगर कोई कोड के आकार को बरकरार रखना चाहता है।

— b0nyb0y

क्षमा करें, लेकिन ओपी के पोस्ट में मूल "जूनियर कोड" की तुलना में यह कोड सूची अभी भी मेरे लिए बहुत कम स्पष्ट है। मूल रूप से: यदि आप इससे बच सकते हैं तो टर्नरी ऑपरेटर का उपयोग कभी न करें। यह बहुत तनावपूर्ण है। एक "वास्तविक" कार्यात्मक भाषा में, अगर-स्टेटमेंट एक्सप्रेशन होंगे न कि स्टेटमेंट्स, और इसलिए अधिक पठनीय।

— ओलले हर्स्टेड्ट

@ OlleHärstedt उम्म, यह एक दिलचस्प दावा है। बात यह है कि, कार्यात्मक प्रोग्रामिंग प्रतिमान, या किसी भी प्रतिमान, वहाँ कभी भी किसी विशेष "वास्तविक" कार्यात्मक भाषा से बंधा नहीं है, इसकी वाक्य रचना बहुत कम है। इस प्रकार, क्या सशर्त निर्माण होना चाहिए या "कभी नहीं" का उपयोग करना तय करना बस कोई मतलब नहीं है। A ternary operatorएक नियमित ifविवरण के रूप में मान्य है , चाहे आप इसे पसंद करें या नहीं। if-elseऔर ?:शिविर के बीच पठनीयता की बहस कभी खत्म नहीं होती है, इसलिए मैं इसमें नहीं जाऊंगा। मैं बस इतना ही कहूंगा कि प्रशिक्षित आंखों के साथ, इस तरह की लाइनें "बहुत तनावपूर्ण" हैं।

— b0nyb0y

Answer 4

दूसरा स्निपेट पहले की तुलना में अधिक परीक्षण योग्य नहीं है । यह दो स्निपेट में से किसी एक के लिए सभी आवश्यक परीक्षणों को स्थापित करने के लिए उचित रूप से सरल होगा।

दो स्निपेट के बीच वास्तविक अंतर समझदारी है। मैं पहले स्निपेट को काफी जल्दी पढ़ सकता हूं और समझ सकता हूं कि क्या चल रहा है। दूसरा स्निपेट, इतना नहीं। यह बहुत कम सहज है, साथ ही साथ लंबे समय तक।

यह पहला स्निपेट बनाए रखना आसान बनाता है, जो कोड का एक मूल्यवान गुण है। मुझे दूसरे स्निपेट में बहुत कम मूल्य मिलते हैं।

Answer 5

टीडी, डॉ

1. क्या आप 10 मिनट या उससे कम समय में अपने कोड को जूनियर डेवलपर को समझा सकते हैं?
2. अब से दो महीने बाद, क्या आप अपना कोड समझ सकते हैं?

विस्तृत विश्लेषण

स्पष्टता और पठनीयता

मूल कोड प्रोग्रामर के किसी भी स्तर के लिए प्रभावशाली रूप से स्पष्ट और समझने में आसान है। यह हर किसी के लिए परिचित शैली में है ।

पठनीयता काफी हद तक परिचितता पर आधारित है, न कि कुछ गणितीय गणना टोकन की । IMO, समय पर इस स्तर पर, आपके पास अपने पुन: लेखन में बहुत अधिक ES6 है। शायद कुछ वर्षों में मैं अपने उत्तर के इस हिस्से को बदल दूंगा। :-) BTW, मैं भी एक उचित और स्पष्ट समझौते के रूप में @ b0nyb0y उत्तर पसंद करता हूं।

testability

if(apiData.pages.foo){
   pagesList.add('foo', apiData.pages.foo){
}

यह मानते हुए कि PagesList.add () के पास परीक्षण हैं, जो इसे होना चाहिए, यह पूरी तरह से सीधा कोड है और इस अनुभाग के लिए विशेष अलग परीक्षण की आवश्यकता के लिए कोई स्पष्ट कारण नहीं है।

if (apiData.pages.arrayOfBars){
      let bars = apiData.pages.arrayOfBars;
      bars.forEach((bar) => {
         pagesList.add(bar.name, bar.data);
      })
   }

फिर से, मुझे इस खंड के किसी विशेष अलग परीक्षण की तत्काल आवश्यकता नहीं है। जब तक PagesList.add () में अशक्त या डुप्लिकेट या अन्य इनपुट के साथ असामान्य समस्याएं हैं।

if (apiData.pages.customBazes) {
      let bazes = apiData.pages.customBazes;
      bazes.forEach((baz) => {
         pagesList.add(customBazParser(baz)); 
      })
   } 

यह कोड भी बहुत सीधा है। माना जाता है कि customBazParserपरीक्षण किया गया है और बहुत सारे "विशेष" परिणाम नहीं लौटाते हैं। इसलिए फिर से, जब तक `PagesList.add () के साथ मुश्किल परिस्थितियां नहीं होती हैं, (जो वहां हो सकता है जैसा कि मैं आपके डोमेन से परिचित नहीं हूं) मैं यह नहीं देखता कि इस खंड को विशेष परीक्षण की आवश्यकता क्यों है।

सामान्य तौर पर, पूरे कार्य का परीक्षण ठीक काम करना चाहिए।

अस्वीकरण : यदि तीन if()बयानों की सभी 8 संभावनाओं का परीक्षण करने के लिए विशेष कारण हैं , तो हाँ, परीक्षणों को विभाजित करें। या, यदि PagesList.add()संवेदनशील है, हाँ, परीक्षणों को विभाजित करें।

संरचना: क्या यह तीन भागों (जैसे गॉल) में टूटने लायक है

यहां आपके पास सबसे अच्छा तर्क है। व्यक्तिगत रूप से, मुझे नहीं लगता कि मूल कोड "बहुत लंबा है" (मैं एसआरपी कट्टरपंथी नहीं हूं)। लेकिन, अगर कुछ और if (apiData.pages.blah)खंड थे, तो SRP ने कहा कि यह बदसूरत सिर है और यह विभाजन के लायक होगा। खासकर यदि DRY लागू होता है और फ़ंक्शन कोड के अन्य स्थानों में उपयोग किया जा सकता है।

मेरा एक सुझाव

YMMV। कोड की एक लाइन और कुछ लॉजिक को बचाने के लिए, मैं if को संयोजित कर सकता हूं और एक लाइन में जाने देता हूं : उदा

let bars = apiData.pages.arrayOfBars || [];
bars.forEach((bar) => {
   pagesList.add(bar.name, bar.data);
})

यह विफल हो जाएगा यदि apiData.pages.arrayOfBars एक नंबर या स्ट्रिंग है, लेकिन मूल कोड होगा। और मेरे लिए यह स्पष्ट है (और एक अति प्रयोग किया हुआ मुहावरा)।