আমি কি জুনিয়র দেবগণের দ্বারা পড়ার মতো 'চালাক'? আমার জেএসে খুব বেশি ফাংশনাল প্রোগ্রামিং? [বন্ধ]

Question

বাবেল ES6 এ কোডিং করে আমি একটি সিনিয়র ফ্রন্ট-এন্ড দেব। আমাদের অ্যাপ্লিকেশনটির একটি অংশ একটি এপিআই কল করে এবং ডেটা মডেলের উপর ভিত্তি করে আমরা এপিআই কল থেকে ফিরে আসি, নির্দিষ্ট ফর্মগুলি পূরণ করা দরকার।

এই ফর্মগুলি দ্বিগুণ-সংযুক্ত তালিকায় সঞ্চিত হয় (যদি পিছনের শেষের অংশটি কিছু ডেটা অবৈধ বলে মনে হয় তবে আমরা ব্যবহারকারীকে দ্রুত যে পৃষ্ঠায় ফেলেছিলাম তার একটি পৃষ্ঠায় ফিরে যেতে পারি এবং তারপরে কেবলমাত্র সংশোধন করে তা আবার লক্ষ্যবস্তুতে ফিরে পেতে পারি) তালিকা।)

যাইহোক, পৃষ্ঠাগুলি যুক্ত করার জন্য একটি গুচ্ছ ফাংশন ব্যবহার করা হচ্ছে এবং আমি ভাবছি আমি খুব চালাক হয়ে যাচ্ছি কিনা। এটি কেবলমাত্র একটি প্রাথমিক ওভারভিউ - প্রকৃত অ্যালগরিদম অনেক বেশি জটিল, বিভিন্ন পৃষ্ঠা এবং পৃষ্ঠার ধরণের সংখ্যার সাথে, তবে এটি আপনাকে একটি উদাহরণ দেবে।

আমার মনে হয়, একজন নবজাতক প্রোগ্রামার এটি পরিচালনা করবে।

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

যার মত Babel ES6

— জেএসে

ওএমজি - ১৯৯৩ সাল থেকে শিল্পে সক্রিয় এবং 1983 সাল থেকে কোডিং, এবং আপনি সেখানে সবচেয়ে ক্ষতিকারক ধরণের বিকাশকারী। আপনি যেটিকে "চালাক" বলে মনে করেন তাকে সত্যই "ব্যয়বহুল" এবং "বজায় রাখা শক্ত" এবং "বাগের উত্স" বলা হয় এবং ব্যবসায়ের পরিবেশে এর কোনও স্থান নেই। প্রথম উদাহরণটি সহজ, সহজে বোঝা যায় এবং এটি কাজ করে যখন দ্বিতীয় উদাহরণটি জটিল, বোঝা শক্ত, এবং যথাযথভাবে সঠিক নয়। দয়া করে এই ধরণের কাজ করা বন্ধ করুন। এটি আরও ভাল নয়, সম্ভবত কিছু একাডেমিক অর্থে যা বাস্তব বিশ্বের ক্ষেত্রে প্রযোজ্য না।

— ব্যবহারকারী 1068

আমি এখানে ব্রায়ান ক্যারিংহানকে উদ্ধৃত করতে চাই: "প্রত্যেকে জানে যে ডিবাগিং প্রথমবারের মতো একটি প্রোগ্রাম লেখার চেয়ে দ্বিগুণ শক্ত। সুতরাং আপনি যখন এটি লেখার সময় যতটা চালাক হন ততক্ষণ আপনি কীভাবে এটি ডিবাগ করবেন? " - en.wikiquote.org/wiki/Brian_Kernighan / "প্রোগ্রামিং স্টাইলের উপাদানসমূহ", ২ য় সংস্করণ, অধ্যায় 2

— মার্কাসচ্যাবার

@ লোগিটার শীতলতা আর সরলতার চেয়ে প্রাথমিক লক্ষ্য নয়। এখানে আপত্তিটি হ'ল অহেতুক জটিলতা, যা সঠিকতার শত্রু (অবশ্যই একটি প্রাথমিক উদ্বেগ) কারণ এটি কোডটিকে যুক্তিযুক্ত করে তুলনাকে আরও শক্ত করে তোলে এবং অপ্রত্যাশিত কোণার কেস থাকতে পারে। আমার দাবী সম্পর্কে সন্দেহ প্রকাশের আগে যে এটি পরীক্ষা করা আসলে আরও সহজ, আমি এই শৈলীর জন্য কোনও বিশ্বাসযোগ্য যুক্তি দেখিনি। অন্ততপক্ষে প্রাইভেট রাইটিং সুরক্ষার নিয়মের সাথে সাদৃশ্যতে, সম্ভবত একটি থাম্বের নিয়ম থাকতে পারে যা বলে যে সাধারণ জিনিসগুলি করার জন্য শক্তিশালী ভাষার বৈশিষ্ট্যগুলি ব্যবহার করা সম্পর্কে সতর্ক হওয়া উচিত।

— sdenham

আপনার কোডটি জুনিয়র কোডের মতো দেখাচ্ছে। আমি প্রত্যাশা করব একজন প্রবীণ প্রথম উদাহরণটি লিখবেন।

— 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।

হ্যাঁ, আপনার কোডটি খুব চালাক ছিল। চতুর কোডটি না লিখতে আপনার বুদ্ধি প্রয়োগ করুন, তবে নির্লজ্জ চালাকির প্রয়োজনীয়তা এড়াতে চতুর উপায়গুলি সন্ধান করতে। সেরা ডিজাইনগুলি অভিনব দেখায় না , তবে যে কেউ এগুলি দেখায় তাদের কাছে স্পষ্ট দেখায়। এবং ভাল বিমূর্ততা প্রোগ্রামিংকে সহজ করার জন্য রয়েছে, আমার মনে প্রথমে অতিরিক্ত স্তরগুলি যুক্ত করা উচিত নয় যা আমাকে মনে করতে হবে (এখানে, এটি নির্ধারণ করুন যে ফান্টারের একটি পরিবর্তনশীলের সমতুল্য, এবং কার্যকরভাবে আলাদা করা যেতে পারে)।

দয়া করে: সন্দেহ হলে আপনার কোডটি সহজ এবং বোকা রাখুন (KISS নীতি)।

Comments

একটি প্রতিসামগ্রী দৃষ্টিকোণ থেকে, এর let pages = Identity(pagesList)থেকে আলাদা কি আছে parseFoo(foo)? যে দেওয়া, আমি সম্ভবত ... ছিল {Identity(pagesList), parseFoo(foo), parseBar(bar)}.flatMap(x -> x)।

— আরটিস

ব্যাখ্যা করলেন যে (আমার আনকোরা চোখ থেকে) একটি ম্যাপ তালিকা সংগ্রহের জন্য তিন নেস্টেড ল্যামডা এক্সপ্রেশন থাকার একটু হতে পারে জন্য আপনাকে ধন্যবাদ খুব চালাক।

— থরবজর্ন রাভন অ্যান্ডারসান

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— ইয়ানিস

সম্ভবত একটি সাবলীল শৈলী আপনার দ্বিতীয় উদাহরণে ভাল কাজ করবে?

— ব্যবহারকারী 1068

Answer 2

আপনার যদি সন্দেহ হয় তবে সম্ভবত এটি খুব চালাক! দ্বিতীয় উদাহরণটি দুর্ঘটনাজনিত জটিলতার মতো অভিব্যক্তির সাথে পরিচয় করিয়ে দেয় foo ? parseFoo(foo) : x => xএবং সামগ্রিকভাবে কোডটি আরও জটিল যার অর্থ এটি অনুসরণ করা আরও শক্ত।

উদ্দেশ্যযুক্ত সুবিধা, আপনি পৃথকভাবে খণ্ডগুলি পরীক্ষা করতে পারেন, কেবল স্বতন্ত্র ফাংশনগুলি ভেঙে একটি সহজ উপায়ে অর্জন করা যেতে পারে। এবং দ্বিতীয় উদাহরণে আপনি পৃথক পৃথক পুনরাবৃত্তিগুলি দম্পতি করেন, যাতে আপনি আসলে কম বিচ্ছিন্নতা পান।

সাধারণভাবে কার্যকরী শৈলী সম্পর্কে আপনার অনুভূতি যাই হোক না কেন, এটি স্পষ্টভাবে একটি উদাহরণ যেখানে এটি কোডটিকে আরও জটিল করে তুলেছে।

আমি কিছুটা সতর্কতা সংকেত পেয়েছি যাতে আপনি সরল এবং সোজা কোডটি "নবাগত বিকাশকারী" এর সাথে যুক্ত করেন। এটি একটি বিপজ্জনক মানসিকতা। আমার অভিজ্ঞতাতে এটি বিপরীত: নবীন বিকাশকারীরা অত্যধিক জটিল এবং চতুর কোডের ঝুঁকিতে থাকে, কারণ এর সহজতম এবং পরিষ্কার সমাধানটি দেখার জন্য আরও অভিজ্ঞতার প্রয়োজন হয়।

"চতুর কোড" এর বিপরীতে পরামর্শটি কোডটি উন্নত ধারণাটি ব্যবহার করে কিনা তা সম্পর্কে আসলেই নয় যা একটি নবাগত সম্ভবত বুঝতে পারে না। বরং এটি লিখিত কোড সম্পর্কিত যা প্রয়োজনের চেয়ে জটিল বা জটিল । এই কোডটি প্রত্যেকের জন্য , novices এবং বিশেষজ্ঞদের জন্য, এবং সম্ভবত নিজের জন্য কয়েক মাস লাইন থেকে অনুসরণ করা আরও শক্ত করে তোলে ।

Comments

"নবীন বিকাশকারীরা অত্যধিক জটিল এবং চতুর কোডের ঝুঁকিতে থাকে, কারণ এর সহজতম এবং পরিষ্কার সমাধান দেখতে সক্ষম হওয়ার জন্য আরও অভিজ্ঞতার প্রয়োজন হয়" আপনার সাথে আরও একমত হতে পারে না। অসাধারণ উত্তর!

— বোনিফেসিও

অতিরিক্ত জটিল কোডও বেশ প্যাসিভ-আগ্রাসী। আপনি ইচ্ছাকৃতভাবে এমন কোড তৈরি করছেন যা অন্য কয়েকজন সহজেই পড়তে বা ডিবাগ করতে পারে ... যার অর্থ আপনার জন্য চাকরির সুরক্ষা এবং আপনার অনুপস্থিতিতে অন্য সবার জন্য একেবারে নরক। আপনি পাশাপাশি ল্যাটিন ভাষায় আপনার প্রযুক্তিগত ডকুমেন্টেশন লিখতে পারেন।

— ইভান

আমি মনে করি না যে চতুর কোডটি সর্বদা শো-অফ জিনিস। কখনও কখনও এটি প্রাকৃতিক অনুভূত হয় এবং কেবলমাত্র দ্বিতীয় পরিদর্শনে হাস্যকর লাগে।

উদ্দেশ্যটির চেয়ে বেশি বিচার্য শোনার কারণে আমি "প্রদর্শন" সম্পর্কে শব্দবন্ধগুলি সরিয়ে ফেলেছি।

— জ্যাকবিবি

@ বেইলিএস - আমি মনে করি যে কোড পর্যালোচনার গুরুত্বকে জোর দেয়; কোডারের কাছে যা প্রাকৃতিক এবং সোজা মনে হয়, বিশেষত ধীরে ধীরে যখন সেভাবে বিকাশ ঘটে তখন সহজেই কোনও পর্যালোচকের কাছে সংশ্লেষিত মনে হয়। কোডটি তখন কনফিউশনটি অপসারণ করতে রিফ্যাক্টর / পুনরায় লেখা না হওয়া পর্যন্ত পর্যালোচনা পাস করে না।

— মাইলস

Answer 3

আমার এই উত্তরটি কিছুটা দেরিতে এসেছে তবে আমি এখনও চিম ইন করতে চাই Just কারণ আপনি সর্বশেষতম ES6 কৌশল ব্যবহার করছেন বা সর্বাধিক জনপ্রিয় প্রোগ্রামিং দৃষ্টান্তটি ব্যবহার করছেন এটির প্রয়োজনটি এই নয় যে আপনার কোডটি আরও সঠিক, বা সেই জুনিয়রের কোড is ভূল. ফাংশনাল প্রোগ্রামিং (বা অন্য কোনও কৌশল) ব্যবহার করা উচিত যখন এটির প্রয়োজন হয়। আপনি যদি প্রতিটি সমস্যার জন্য সর্বশেষ প্রোগ্রামিং কৌশলগুলি ছড়িয়ে দেওয়ার ক্ষুদ্রতম সুযোগটি সন্ধান করার চেষ্টা করেন, আপনি সর্বদা একটি ওভার ইঞ্জিনিয়ারড সমাধান দিয়ে শেষ করবেন।

এক ধাপ পিছনে যান এবং আপনি যে সমস্যাটি এক সেকেন্ডের জন্য সমাধান করার চেষ্টা করছেন তা ভার্বালাইজ করার চেষ্টা করুন। সংক্ষেপে, আপনি কেবল একটি ফাংশন চান যা 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;
}

( এখানে একটি চলমান jsfiddle )

আপনি দেখতে পাচ্ছেন, এই পদ্ধতিরটি এখনও ব্যবহার করে functional programmingতবে সংযম করে। আরও মনে রাখবেন যে সমস্ত 3 রূপান্তর ফাংশন যে কোনও কারণে কোনও পার্শ্ব প্রতিক্রিয়া সৃষ্টি করে না, সেগুলি পরীক্ষা করা সহজ are কোডে addPagesএছাড়াও তুচ্ছ ও কোমল স্বভাব যে অনভিজ্ঞ বা বিশেষজ্ঞদের শুধু একটি নিছক নজরে দ্বারা বুঝতে পারে না।

এখন, এই কোডটি আপনি উপরে যেটি নিয়ে এসেছেন তার সাথে তুলনা করুন, আপনি কি পার্থক্যটি দেখছেন? নিঃসন্দেহে functional programmingএবং ES6 সিনট্যাক্সগুলি শক্তিশালী, তবে আপনি যদি এই কৌশলগুলি দিয়ে সমস্যাটিকে ভুল উপায়ে টুকরো টুকরো করেন তবে আপনি এমনকি বার্তাবহ কোড দিয়ে শেষ করতে পারেন।

আপনি যদি সমস্যাটিতে তাড়াহুড়া না করে এবং সঠিক জায়গাগুলিতে সঠিক কৌশল প্রয়োগ করে থাকেন তবে আপনার কোডটি প্রকৃতিগতভাবে কার্যকর রয়েছে, যদিও এখনও সমস্ত দলের সদস্যদের দ্বারা খুব সুসংহত এবং রক্ষণাবেক্ষণযোগ্য। এই বৈশিষ্ট্যগুলি পারস্পরিক একচেটিয়া নয়।

Comments

এই বিস্তৃত মনোভাবের দিকে নির্দেশ করার জন্য +1 (অপরিহার্যভাবে ওপিতে প্রয়োগ করা হয় না): "আপনি সর্বশেষতম ES6 কৌশল ব্যবহার করছেন বা সর্বাধিক জনপ্রিয় প্রোগ্রামিং দৃষ্টান্তটি ব্যবহার করছেন না কেন অবশ্যই আপনার কোডটি আরও সঠিক বলে বোঝায় না, বা সেই জুনিয়র কোডটি ভুল।

— জর্জিও

+1 টি। কেবলমাত্র একটি ছোট পেডেন্টিক মন্তব্য, আপনি সেই নির্ভরতা অপসারণ করতে _ কনক্যাটের পরিবর্তে স্প্রেড (...) অপারেটরটি ব্যবহার করতে পারেন।

— YoTengoUnLCD

@ YoTengoUnLCD আহ, ভাল ধরা catch এখন আপনি জানেন যে আমি এবং আমার দল এখনও আমাদের কিছু lodashব্যবহার উন্মুক্ত করার পথে যাত্রা করছি । এই কোডটি ব্যবহার করতে পারে spread operator, অথবা [].concat()কেউ কোডের আকারটি অক্ষত রাখতে চাইলেও।

— b0nyb0y

দুঃখিত, তবে এই কোড তালিকাটি আমার কাছে এখনও ওপির পোস্টে মূল "জুনিয়র কোড" এর চেয়ে কম স্পষ্ট। মূলত: আপনি যদি এড়াতে পারেন তবে কখনই টার্নারি অপারেটর ব্যবহার করবেন না। এটা খুব উত্তেজনাপূর্ণ। একটি "আসল" কার্যকরী ভাষায়, যদি-বিবৃতিগুলি হ'ল বক্তব্য নয় এবং বিবৃতি নয় এবং তাই আরও পাঠযোগ্য।

— ওলে হার্স্টেট

@ ওলেহর্স্টেট উম, এটি আপনার দ্বারা করা একটি আকর্ষণীয় দাবি। জিনিসটি হ'ল, ফাংশনাল প্রোগ্রামিং দৃষ্টান্ত বা সেখানে কোনও দৃষ্টান্ত কোনও বিশেষ "আসল" কার্যকরী ভাষার সাথে কখনই আবদ্ধ হয় না, এর বাক্য গঠনটি কম। সুতরাং, শর্তাধীন কন্সট্রাক্টসগুলি কী হতে হবে বা "কখনই" ব্যবহার করা উচিত নয় তা নির্দেশ করে কোনও অর্থ হয় না। আপনার ternary operatorনিয়মিত ifবিবৃতি হিসাবে এ বৈধ , আপনার এটি পছন্দ হোক বা না হোক। if-elseএবং ?:শিবিরের মধ্যে পঠনযোগ্যতার বিতর্কটি কখনই শেষ হয় না, তাই আমি এতে প্রবেশ করব না। আমি কেবল এতটাই বলব, প্রশিক্ষিত চোখের সাথে এগুলির মতো রেখাগুলি খুব বেশি "খুব উত্তেজনাপূর্ণ" হয় না।

— বি0nyb0y

Answer 4

দ্বিতীয় স্নিপেট প্রথমটির চেয়ে বেশি পরীক্ষামূলক নয় । দুটি স্নিপেটের যে কোনও একটির জন্য প্রয়োজনীয় সমস্ত পরীক্ষাগুলি সেট আপ করা যুক্তিসঙ্গতভাবে সোজা হবে।

দুটি স্নিপেটের মধ্যে আসল পার্থক্যটি বোধগম্যতা। আমি প্রথম স্নিপেটটি মোটামুটি দ্রুত পড়তে পারি এবং বুঝতে পারি কী চলছে। দ্বিতীয় স্নিপেট, এত বেশি নয়। এটি অনেক কম স্বজ্ঞাত, পাশাপাশি যথেষ্ট দীর্ঘ।

এটি প্রথম স্নিপেটকে বজায় রাখা সহজ করে তোলে যা কোডের একটি মূল্যবান গুণ। আমি দ্বিতীয় স্নিপেটে খুব কম মান খুঁজে পাই।

Answer 5

: TD; ডিআর

1. আপনি কি 10 মিনিট বা তারও কম সময়ে জুনিয়র বিকাশকারীকে আপনার কোডটি ব্যাখ্যা করতে পারেন?
2. এখন থেকে দুই মাস পরে, আপনি কি আপনার কোড বুঝতে পারবেন?

বিশদ বিশ্লেষণ

স্পষ্টতা এবং পাঠযোগ্যতা

মূল কোডটি প্রোগ্রামারের কোনও স্তরের জন্য চিত্তাকর্ষকভাবে পরিষ্কার এবং সহজেই বোঝা যায়। এটি প্রত্যেকের সাথে পরিচিত একটি স্টাইলে ।

পাঠযোগ্যতা মূলত পরিচিতির উপর ভিত্তি করে, টোকেনগুলির কিছু গাণিতিক গণনা নয় । আইএমও, সময়মতো এই পর্যায়ে আপনার পুনরায় লেখায় আপনার খুব বেশি ES6 রয়েছে। হয়তো কয়েক বছর পরে আমি আমার উত্তরের এই অংশটি পরিবর্তন করব। :-) বিটিডাব্লু, আমি @ b0nyb0y উত্তরটিও যুক্তিসঙ্গত এবং স্পষ্ট সমঝোতার হিসাবে পছন্দ করি।

Testability

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

এই কোডটিও খুব সোজা। ধরে নিলাম যে customBazParserএটি পরীক্ষা করা হয়েছে এবং খুব বেশি "বিশেষ" ফলাফলগুলি দেয় না। সুতরাং আবার, unless পেজলিস্ট.এডডি () এর সাথে কৃপণ পরিস্থিতি না থাকলে (যা আপনার ডোমেনের সাথে আমি পরিচিত নই) এই বিভাগটি কেন বিশেষ পরীক্ষার প্রয়োজন তা আমি দেখতে পাচ্ছি না।

সাধারণভাবে, পুরো ফাংশনটি পরীক্ষা করে ঠিক মতো কাজ করা উচিত।

অস্বীকৃতি : যদি তিনটি if()বিবৃতিতে সমস্ত 8 সম্ভাবনার পরীক্ষা করার জন্য বিশেষ কারণ থাকে তবে হ্যাঁ, পরীক্ষাগুলি বিভক্ত করুন। বা, PagesList.add()সংবেদনশীল হলে হ্যাঁ, পরীক্ষাগুলি ভাগ করুন।

কাঠামো: এটি কি তিন ভাগে বিভক্ত করার মতো (গলের মতো)

এখানে আপনার সেরা যুক্তি আছে। ব্যক্তিগতভাবে, আমি মনে করি না যে মূল কোডটি "খুব দীর্ঘ" (আমি কোনও এসআরপি ধর্মান্ধ নয়)। তবে, যদি আরও কয়েকটি if (apiData.pages.blah)বিভাগ থাকে, তবে এসআরপি এটি কুরুচিপূর্ণ করে তোলে এবং এটি বিভাজনযোগ্য। বিশেষত যদি DRY প্রযোজ্য হয় এবং ফাংশনগুলি কোডের অন্যান্য জায়গায় ব্যবহার করা যেতে পারে।

আমার একটি পরামর্শ

YMMV। কোড একটি লাইন এবং কিছু লজিক সংরক্ষণ করতে, আমি একত্রিত পারে যদি এবং দিন এক লাইন মধ্যে: যেমন

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

এটি ব্যর্থ হবে যদি apiData.pages.arrayOfBars নম্বর বা স্ট্রিং হয় তবে মূল কোডটিও তাই হবে। এবং আমার কাছে এটি পরিষ্কার (এবং একটি অতিরিক্ত ব্যবহৃত আইডিয়াম)।