ऐसा हुआ है कि पिछले कुछ वर्षों में मैं फ्रेंकस्टीन को सिलाई कर रहा हूं, और चरवाहों और चिमनी झाडू के प्यारा चीनी मिट्टी के बरतन मूर्तियों को नहीं उकेर रहा हूं। मैं Magento 2 पर आधारित समाधान बनाता हूं। इसका मतलब है कि मेरे लिए स्रोत सामग्री किसी भी पुरातत्वविद् का सपना है। विभिन्न "युग" और "सभ्यताओं" के निशान के साथ सांस्कृतिक परत। इसका उपयोग पिछले एक दशक में PHP / JS समुदायों में सोचा गया प्रोग्रामर के विकास का अध्ययन करने के लिए किया जा सकता है।

और यह केवल आधार है, और ऐड-इन तीसरे पक्ष के मॉड्यूल हैं जिन्हें अंदर एकीकृत करने की आवश्यकता है। यहां पर पहले से ही अलौकिक बुद्धि की अभिव्यक्तियों का सामना करना संभव है। कुछ मॉड्यूल विकसित प्राणियों द्वारा बनाए जाते हैं, जो आधार के रचनाकारों के लिए बहुत समान हैं, लेकिन आप उन पर आते हैं जो आप लेखक को कंधे से पकड़ना चाहते हैं, उसकी आँखों में गहराई से देखें और दोस्ताना तरीके से पूछें: " आप किस ग्रह से हैं, मूल निवासी? "

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

ओबसफिकेशन और कोड एन्क्रिप्शन

यह प्रतियोगिता से बाहर है। मुझे मॉड्यूल के साथ कुछ समय के लिए आया था जिसमें काम करने के लिए आयनक्यूब की आवश्यकता होती है, और मैं कह सकता हूं कि मैं जो आखिरी चीज करूंगा वह मेरी परियोजना में एक समान मॉड्यूल डाल देगा। मैं जेएस कोड के मिनिमाइजेशन का पूरी तरह से समर्थन करता हूं, खासकर जब सामान्य स्रोत पास होता है, लेकिन ऑब्सफिकेशन और एन्क्रिप्शन एक डिस्टिल्ड, केंद्रित बुराई है। मैं आपको इसे एक इंटीग्रेटर के रूप में बता रहा हूं।

चतुर्थ। सिंगल लाइन कोड

कोड की लाइनों पर सहेजना मेरी सूची में सबसे हानिरहित है:

if ($cond) aaa(); else bbb(); 

कार्यक्रम के चरण-दर-चरण निष्पादन (स्थिति की गणना, true या false शाखा का निष्पादन) के दौरान इस रेखा पर दो कदम लटकाए जाते हैं। यह ठीक है, आपको बस यह ध्यान रखने की आवश्यकता है कि आपने कितनी बार इस लाइन पर एक स्टेप-ओवर किया, और चर सूची में $cond के मूल्य को ट्रैक किया। समय के साथ, स्वचालितता विकसित हुई है।

थोड़ा बुरा यह है कि आप true या false शाखा पर बिना शर्त ब्रेकपॉइंट सेट नहीं कर सकते। आईडीई में एक क्लिक के बजाय, आपको सशर्त ब्रेकपॉइंट जोड़कर माउस / कीबोर्ड के साथ थोड़ी देर काम करना होगा।

आदर्श विकल्प तब होता है जब प्रत्येक निष्पादन योग्य चरण (स्थिति, true प्रकाश, false प्रकाश) अपनी ही रेखा पर होता है:

 if ($cond) aaa(); else bbb(); 

तृतीय। अभिव्यक्ति का परिणाम

शर्तों में अभिव्यक्तियों का उपयोग करना:

 if (exp()) ... 

चक्र:

 foreach (exp() as $item) ... 

मापदंडों के रूप में:

 foo(exp(), ...) 

और वापसी परिणाम:

 return exp(); 

न केवल कोड "सघन" बनाता है, यह समझना आसान बनाता है, बल्कि डिबगिंग को और अधिक कठिन बनाता है - आप केवल डीबगर चर की सूची में अभिव्यक्तियों के निष्पादन मूल्यों को नहीं देखते हैं। मुझे घड़ियों को जोड़ना होगा (एक दिलचस्प सवाल, और यदि आप घड़ियों के माध्यम से जनरेटर की निगरानी करते हैं, तो क्या यह कार्यक्रम के निष्पादन को प्रभावित करेगा? )।

आदर्श विकल्प एक अस्थायी चर है:

 $exp = exp(); if ($exp) ... 

द्वितीय। कई निकास बिंदु

कई बार मैं समारोह से केवल एक निकास बिंदु रखने की सिफारिश पर आया था और कई बार मैं इस सिफारिश (एक आविष्कारित उदाहरण, लेकिन एक विशिष्ट एक) का उल्लंघन करके आया था:

 public function onEvent($event) { if($event == 'entrance') { return 'entranceRoute'; } else if($event == 'exit') { return 'exitRoute'; } return 'defaultRoute'; } 

यहाँ एक अधिक सही विकल्प है:

 public function onEvent($event) { $result = 'defaultRoute'; if($event == 'entrance') { $result = 'entranceRoute'; } else if($event == 'exit') { $result = 'exitRoute'; } return $result; } 

यही है, मुझे प्रत्येक return पर ब्रेकपॉइंट्स को बिखेरने की जरूरत नहीं है या पहली पंक्ति से एक चरण-आउट करना है (यदि कॉलिंग कोड मुझे एक अलग चर में परिणाम देखने का अवसर देता है) यह समझने के लिए कि निष्पादन कैसे समाप्त हुआ। 120 लाइनों और 22 रिटर्न के साथ एक फ़ंक्शन की कल्पना करें? और मैंने इस पर खुद ही विचार किया और मुझे संदेह है कि यह सीमा नहीं है।

I. कैस्केडिंग विधि कॉल

मेरा पसंदीदा तरीका कैस्केडिंग है :

 $collection ->addFilterByProduct(...) ->addShowInStoresFilter(...) ->addPublicFilter(...) ->addApprovedStatusFilter(...) ->addCreatedAtLessThanNowFilter(...); 

अगर मुझे addApprovedStatusFilter() विधि के अंदर जाने की आवश्यकता है, जो इंटरफ़ेस-आधारित है और कई अलग-अलग वर्गों (एक विशिष्ट वर्ग रनटाइम पर निर्धारित की जाती है) में लागू की जाती है, तो सबसे सरल बात $collection पर एक ब्रेकपॉइंट सेट करना और बारी-बारी से सब कुछ जाना है ( addFilterByProduct , addShowInStoresFilter , addPublicFilter ) सही जगह तक। यदि आप मापदंडों और लौटे परिणामों में अभिव्यक्ति का उपयोग करके इसे जोड़ते हैं, तो पथ पूरी तरह से बंद नहीं हो जाता है। मूल में, यह कोड इस तरह दिखता है:

 $collection ->addFilterByProduct($this->getProduct()) ->addShowInStoresFilter($this->_storeManager->getStore()->getId()) ->addPublicFilter() ->addApprovedStatusFilter() ->addCreatedAtLessThanNowFilter(); 

हां, कैस्केडिंग विधियों के साथ, कोड अधिक पठनीय हो जाता है, लेकिन यह बहस करना अधिक कठिन हो जाता है। मेरे पास सेट कैस्केड के खिलाफ कुछ भी नहीं है (मैं, एक नियम के रूप में, पहली बार बसने वाला नहीं हूं)

 $answerModel ->setAuthorName(...) ->setStatus(...) ->setCreatedAt(...) ->setAuthorEmail(...) ->setCustomerId(...) ->setHelpfulness(...) 

लेकिन जिस कोड में तर्क है, जिस पर बहस की जा सकती है, या शायद खुद से भी, " पुराने स्कूल " (मैं इसे खुद करता हूं) लिखना बेहतर है:

 $collection->addFilterByProduct(...); $collection->addShowInStoresFilter(...); $collection->addPublicFilter(...); $collection->addApprovedStatusFilter(...); $collection->addCreatedAtLessThanNowFilter(...); 

क्या यह महसूस करना बहुत मुश्किल हो गया है?

या यहाँ एक अच्छी प्रोग्रामिंग शैली के लिए सिफारिशें दी गई हैं:

 ladder.up().up().down().up().down().showStep(); 

इसे एक इंटीग्रेटर के दृष्टिकोण से देखें, जिसे दूसरे down अंदर प्राप्त करना चाहिए।

सारांश

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

त्याग

पूर्वगामी व्यक्तिगत पेशेवर विकृति का परिणाम है और अन्य पेशेवर विकृति के आधार पर राय से भिन्न हो सकता है।