एक बदसूरत बत्तख का बच्चा से एक हंस तक, या एक घुमावदार हाथ वाले कोड को कैसे ठीक किया जाए

यह किस बारे में है?

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

मान लीजिए कि हमारे पास टाइपिंग, प्रश्नों, बैसाखी के साथ प्रवेश द्वार पर एक कठिन कोड है, कभी-कभी बिना पढ़े भी।

यह कैसे मदद करता है

रीफैक्टरिंग के परिणामस्वरूप सिस्टम को क्या लाभ होगा?
- संरचित और मॉड्यूलर कोड।
- UI और तर्क का पृथक्करण।
- UNIT टेस्ट लिखने की क्षमता।
- एपीआई में अधिकृत अनुप्रयोगों के लिए केवल एपीआई लिखने की क्षमता।
- किसी अन्य डेटाबेस में स्थानांतरित करने के लिए एक सरल दृष्टिकोण।

मामले का एक विशेष उदाहरण 'यह कैसे करना है और कहां शुरू करना है?'। मैं क्रमिक रूप से इस तरह के सुधार से निपटने का प्रस्ताव करता हूं, और एक ही समय में, दूसरे चरण को पूरा किए बिना, तीसरे पर लेना शुरू नहीं करता हूं। हम कार्य प्रणाली में कोड को सही कर देंगे, यह समझने के लिए कार्यात्मक परीक्षण लिखना बेहतर है कि सब कुछ उसी तरह काम करता है जैसा कि इसे करना चाहिए।

चरणों

1. एल्गोरिदम दृष्टिकोण ।
आइए हमारे भयानक लेआउट कोड पर एक नज़र डालें जिसे परीक्षण नहीं किया जा सकता है (और शायद अन्य स्थानों पर दोहराया गया है)। सरल और सीधा, लेकिन इस तरह के कोड का क्रम - ज्ञात परेशानियों का एक समूह बनाता है।

index.php

<h1></h1> <? $DB = new DBConnector; $DB->query('SELECT * FROM users LIMIT 10'); if($DB->get_num_rows()){ while($user = $DB->fetch_row()){ echo '<p>'.$user['name'].'</p>'; } } ?> 

2. प्रक्रियात्मक दृष्टिकोण ।
क्यों नहीं एक समारोह लिखें और इसे इस प्रणाली में कहीं और कॉल करें? प्रक्रियात्मक प्रोग्रामिंग के लिए संक्रमण कोड को कम करने में मदद करेगा, हालांकि 1 कॉल के उदाहरण का उपयोग करते हुए, यह बदतर दिखता है।

functions.php

 $DB = new DBConnector function GetUsers(){ global $DB; $DB->query('SELECT * FROM users LIMIT 10'); if($DB->get_num_rows()){ while($user[] = $DB->fetch_row()); return $users; } else { return array(); } } ?> 

index.php

 <h1></h1> <? include 'functions.php'; $users = GetUsers(); foreach($users as $u) { echo '<p>'.$u.'</p>'; } ?> 

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

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

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

BaseClass.php

 abstract class BaseClass{ protected $dataBase; protected $moduleName; function __construct(){ $this->dataBase = new DBConnector; } //        function Get($limit=10){ $DB->query('SELECT * FROM '.$this->moduleName.' LIMIT '.$limit); if($DB->get_num_rows()){ while($user[] = $DB->fetch_row()); return $users; } else { return array(); } } } 

UserClass.php

 include 'BaseClass.php' class UserClass extend BaseClass{ function __construct (){ parent::construct('users'); } } 

index.php

 <h1></h1> <? include 'UserClass.php'; $users = new UserClass; $users = $users->get(); //  foreach($users as $u) { echo '<p>'.$u.'</p>'; } ?> 

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

नमक

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

इस स्थिति में, 3 चरण दिए गए हैं, जिसके परिणामस्वरूप, सिस्टम को एप्लिकेशन लॉजिक से UI का पृथक्करण प्राप्त होगा। यह आपके सिस्टम को तैयार करेगा, यूनिट कोड को लिखने की संभावना के लिए, टेढ़े-मेढ़े कोड के साथ ओवरलोडेड, एक RESTfull API लिखने और किए गए कार्य के लिए आत्म-संतुष्टि की भावना। कई लोगों के लिए - यह, ज़ाहिर है, स्पष्ट हो सकता है, लेकिन जब किसी तीसरे पक्ष के आवेदन को लिखने या एपीआई प्रदान करने के लिए कहा जाता है, तो कभी-कभी आपको ब्लश करना पड़ता है।

पुनश्च: मुझे किसी भी टिप्पणी पर खुशी होगी और संभवतः, एक समान प्रकृति की समस्याओं के अन्य तरीकों और समाधानों के लिए लिंक।