🤶🏼 🏖️ 👨‍👦‍👦 एक विकास मानक के रूप में कोड शैली 🛐 🍛 ✴️

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

रुचि रखते हैं? बिल्ली के लिए आपका स्वागत है।

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

हमारा मस्तिष्क एक तंत्रिका नेटवर्क है

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

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

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

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

कैसे एक प्रोग्रामर कोड पढ़ता है

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

यह महत्वपूर्ण क्यों है? क्योंकि उनका अधिकांश समय, एक प्रोग्रामर कोड पढ़ता है। कुछ प्रत्यक्ष सहसंबंध नहीं पाया गया, अधिकांश भाग के लिए यह योग्यता पर निर्भर करता है, भाषा (उदाहरण के लिए, पायथन इंडेंट है, और गलत तरीके से संरचित कोड बस काम नहीं करेगा), कोड की गुणवत्ता, आदि। लेकिन उस समय के 50% से अपना और किसी और का कोड पढ़ने में समय लगता है। यदि कोड जटिल है, तो संकेतक 75% तक पहुंच सकता है, और यदि कोड वास्तव में खराब है, तो 95% समय पढ़ने और खर्च करने की कोशिश कर सकता है जहां किसी तरह की खामियों को ठीक करने के लिए एक पंक्ति को जोड़ने की कोशिश की जा सकती है। और अब सवाल। यदि आप देखते हैं कि आपका कोड डिस्क को पढ़ने या दोगुनी लिंक की गई मेमोरी को आवंटित करने में अपना 75% समय खर्च करता है, तो आप क्या करेंगे? प्रोग्रामर इस प्रक्रिया को अनुकूलित करने की कोशिश करेगा, एल्गोरिथ्म को बदलने की कोशिश करेगा, एक अधिक कुशल भंडारण संरचना लागू करेगा, आदि। तदनुसार, जब समय व्यतीत हो गया, तो मैंने इस प्रक्रिया का निरीक्षण करना शुरू किया। और कोई भी कह सकता है, ठीक है, यह मस्तिष्क है, यह किसी भी कंप्यूटर की तुलना में अधिक शक्तिशाली है और डेटा की एक पेटाबाइट के बारे में संग्रहीत कर सकता है। लेकिन, कोड के साथ काम करने के लिए मेरे मानसिक ढांचे को विकसित करने की प्रक्रिया में (कोड पढ़ने की आदतों की एक छिपी हुई प्रक्रिया), मुझे अध्ययनों में पता चला जिसमें सेंसर शुरुआती और अनुभवी प्रोग्रामर की आंखों की गतिविधियों पर नजर रखते थे। यह इस तरह दिखता है:
शुरुआत

अनुभवी

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

वीडियो 2012 से काफी पुराना है, और रिकॉर्डिंग का उद्देश्य एक प्रोग्रामर के मस्तिष्क की प्रक्रियाओं का अध्ययन करना था। आप यहाँ और यहाँ थोड़ा और पढ़ सकते हैं।

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

कोड पढ़ने की गति बढ़ाने के 2 तरीके हैं:

कोड कैसे दिख सकता है, इस आधार पर डेवलपर के ज्ञान के आधार का लगातार निर्माण करें। इसका मतलब है आजीवन सीखना, जो लगातार नेटवर्क की शक्ति का विस्तार कर रहा है।
सभी कोड को एक मानक पर लाएं, समान कोड शैली सेट करें

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

पियानो ट्यूनर्स की संख्या

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

हमारा दिमाग आलसी है

खोपड़ी में हमारे केंद्रीय प्रोसेसर का एक और दिलचस्प प्रभाव नई जानकारी की अत्यंत नकारात्मक धारणा है। हमारा दिमाग बहुत आलसी है। शरीर के कुल वजन का लगभग 1.5-2% द्रव्यमान के साथ, मस्तिष्क शरीर की सभी ऊर्जा का 25% खपत करता है। मस्तिष्क के लिए सबसे अधिक संसाधन-गहन सर्जरी थी, ध्यान की एकाग्रता है। आप अधिकतम एकाग्रता को 20-25 मिनट (हाय पोमोडोरो तकनीक) के लिए रख सकते हैं, और इस समय के दौरान मस्तिष्क ग्लूकोज की तरह गोल-मटोल हो जाएगा, क्योंकि यह व्यक्तिपरक आराम के पूरे दिन तक बना रहेगा। नया डेटा संसाधित करना एक अत्यंत संसाधन-गहन प्रक्रिया है। और मस्तिष्क का एक मुख्य लक्ष्य इन्हीं संसाधनों को बचाना है। यह हमारे मानसिक मॉडल के काम के कारण है। एक प्रकार का मनोवैज्ञानिक अवरोधक। यह कुछ इस तरह दिखता है। आप कुछ नया सीखना शुरू करते हैं। कुछ नया देना मुश्किल है और प्रगति की मूर्त गतिशीलता की कमी के कारण, पृष्ठभूमि के चारों ओर तैरते हुए सोचा "मैं बेवकूफ हूँ!" हमारे मानस को इस तरह से व्यवस्थित किया गया है कि पूरा दृष्टिकोण आत्मसम्मान पर निर्भर करता है, और हमारे दृष्टिकोण पर, समाज में हमारी सफलता पर निर्भर करता है। और अनुकूली निर्भरताओं पर बुनियादी सामाजिक उन्नयन को तोड़ने के लिए नहीं, हमारे मस्तिष्क में आत्म-सम्मान को कम करने वाली गतिविधियों का विरोध करना शुरू हो जाता है। नतीजतन, आप एक टीवी श्रृंखला देखना चाहते हैं, एक हबल पढ़ते हैं, एक कॉफी लेते हैं, एक सामाजिक बैठक में बैठते हैं। नेटवर्क आदि। कुछ भी, बस लंडौ क्षेत्र के सिद्धांत को जानने के लिए नहीं। या एक कठिन-से-प्रजनन बग को ठीक करें। या ... निम्न-गुणवत्ता वाला कोड पढ़ें जो यह पता लगाना कठिन हो। इस क्षेत्र में प्रतिबंधों के अनुसार मस्तिष्क कैसे व्यवहार करता है, इसका एक बड़ा उदाहरण लगभग 70-80 साल के लोग हैं, जो रिक्त स्थान को इंगित करना चाहते हैं, वे रोबोट वैक्यूम क्लीनर पर स्मार्टफोन या 2 बटन सीखना नहीं चाहते हैं। संसाधन बाहर चल रहे हैं। मस्तिष्क सीखने की प्रक्रिया को सख्त कर देता है और अंगूठे पर कार्य करता है। युवा होते हुए भी इनमें से बहुत सारे संसाधन हैं। समय बीतने और बड़े होने के साथ, वे कम और कम होते जाते हैं। यह काफी रैखिक रूप से काम करता है। सौभाग्य से, यह हमारे तंत्रिका नेटवर्क की बढ़ती शक्ति से ऑफसेट है। जब तक हम सीधे लक्षित गिरावट के बारे में बात कर रहे हैं, निश्चित रूप से।

कुछ रूढ़ियाँ

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

एक सुपर-कुशल प्रोग्रामर जो प्रारूपण और मानकीकरण के बिना लिखता है, वास्तव में 2 चीजों में सुपर-कुशल है:

सुपर कुशलतापूर्वक डिजाइन और शैली में जाने के बिना करीबी कार्य।
सभी को धीमा करने के लिए यह सुपर-कुशल है, क्योंकि इसके परिवर्धन के बाद, लोग लंबे समय से यह समझने की कोशिश कर रहे हैं कि यहां क्या हुआ था।

क्यों कोड शैली की जरूरत है

हालांकि यह पहले से ही स्पष्ट होना चाहिए, मुख्य बिंदुओं पर किसी तरह जोर देना आवश्यक है।
कोड शैली:

1. परियोजना का एक रैखिक विकास प्रदान करता है और कोड आधार की मात्रा को प्रभावित नहीं करता है। यदि आपने समझने योग्य कोड का ऐतिहासिक लेखन प्रदान किया है, तो कोई फर्क नहीं पड़ता कि कितने डेवलपर्स आते हैं और जाते हैं, आपके पास हमेशा समान कोड गुणवत्ता होती है, जो परियोजना को उसके आकार की परवाह किए बिना गतिशील रूप से बढ़ने की अनुमति देती है।

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

3. विशेष पर निर्भरता को हटाता है। आपको किसी और की मौलिकता और विशिष्ट डिजाइन पर लगातार ठोकर खाने की आवश्यकता नहीं होगी।

4. नया कोड सीखने पर मानसिक अवरोधक के प्रभाव को कम करता है। आपका मस्तिष्क कम प्रतिरोधी है क्योंकि किसी और की शैली में तल्लीन करने की आवश्यकता नहीं है। स्पष्ट कोड पढ़ने के लिए मानसिक संसाधनों की बहुत कम आवश्यकता होती है।

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

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

बिल्कुल सही कोड

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

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

कोड अनाम है
कोड एक किताब की तरह पढ़ता है

अनाम कोड

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

पुस्तक स्तर की पठनीयता

2 मुख्य प्रोग्रामिंग समस्याओं को याद करें? कैश का अमान्य होना और चरों का नामकरण। हम कैश प्रक्रियाओं के अंधेरे अतीत को दरकिनार करेंगे और सीधे हमारे दर्द पर जाएंगे। नामकरण चर, वर्ग, ऑब्जेक्ट, फ़ाइलें, विधियाँ, स्थिरांक इत्यादि। इस समस्या के 2 चरम हैं। नाम बहुत छोटा और बहुत लंबा। सामान्य ज्ञान हमें बताता है कि तर्क कहीं न कहीं, मध्य के पास है। यहां सुपर-कुशल प्रोग्रामर हमारे दरवाजे पर दस्तक देते हैं और हमें बताते हैं कि वे परवाह नहीं करते हैं। लेकिन हमें इस बारे में क्यों सोचना चाहिए? मुझे बताएं कि यह कोड क्या करता है?

और यह एक?

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

डिजाइन पैटर्न

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

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

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

ठोस

SOLID वस्तु-उन्मुख प्रोग्रामिंग के पांच सिद्धांतों का एक संक्षिप्त रूप है। नोट: 5 सिद्धांत वस्तु उन्मुख। प्रोग्रामिंग। यह एक अभ्यास नहीं है। यह कोई सिफारिश नहीं है। यह युवा लोगों को पढ़ाने के लिए कुछ पुराने प्रोग्रामर की इच्छा नहीं है। , SOLID — . SOLID, 6 , , SOLID — . , , . — . , , : , , . . , .

? ? . , . code style, , SOLID. . . . — -. यानी , , , , , , . , .

, code style community . , , , , . , . , . , . , .

code style? ! . , . , . . - open-source based . , PSR , - . symfony2 code style, PSR . , , PHP. , , .

?

, , ? — , , CodeStyle , . , PHPStorm , phpcs codestyle — . , . , , , .

, (), . , ? . . , . 2 Google Sheets . 23% . , 7 , , 20 . . , 20 . 21% . , , .

, , , , 90% , . ? Middle PHP Developer . onboarding , 3-. … - . . onboarding -, , . , 1- Junior PHP Developer. « » . success story.

, , , 25%, onboarding' ⅔. « » , . , . , , , phpstorm Sonar Light.

— , Senior , , . , , . Senior QA Engineer .

, 21-27%. , , - . , 5%, 5 ( , ), 5 69 . , 14 840 – 40 /. phpcs phpstorm? , 50 .

PS: , , ManyChat, .

एक विकास मानक के रूप में कोड शैली