सौंदर्य और संहिता पर विचार

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

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

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

अच्छी और बुरी प्रथाएँ

"... और बच्चे से पूछा: - क्या अच्छा है और क्या बुरा है?" - मायाकोवस्की वी.वी.

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

• क्लीन कोड - रॉबर्ट सी। मार्टिन
• बिल्कुल सही कोड। मास्टर क्लास - स्टीव मैककोनेल
• ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के रिसेप्शन। डिज़ाइन पैटर्न - गैंग ऑफ़ फोर
• व्यावहारिक प्रोग्रामर। अपरेंटिस से मास्टर तक की यात्रा - एंड्रयू हंट, डेविड थॉमस

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

विचारों के लिए आवश्यक शर्तें

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




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

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

शैली की सुंदरता और सद्भाव और अनुग्रह और अच्छी लय सादगी पर निर्भर करती है - प्लेटो

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

सौंदर्य क्या है?

तो, हम कोड की सुंदरता के बहुत सवाल पर आते हैं। यथासंभव उद्देश्य को समझने के लिए कि क्या सुंदरता हमारे प्रश्न में सरलता का पर्याय है, हमें एक मूल अवधारणा के साथ शुरू करना चाहिए। परिभाषा के लिए विकिपीडिया की ओर मुड़ें:

सौंदर्य एक सौंदर्यवादी श्रेणी है जो पूर्णता को दर्शाती है, किसी वस्तु के पहलुओं का एक सामंजस्यपूर्ण संयोजन है जिसमें बाद वाला पर्यवेक्षक में सौंदर्य का आनंद उठाता है।

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

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

सुंदर कोड क्यों महत्वपूर्ण है?

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

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

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

मस्तिष्क का सबसे अच्छा काम क्या है?

इंटरनेट पर, आप अनगिनत लेख पा सकते हैं कि जानकारी को पहचानने में मस्तिष्क कैसे काम करता है। उदाहरण के लिए, आप इस लेख का संदर्भ ले सकते हैं।

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

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

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

रेज़ुलाट्टस के अनुसार, एक unquirtiset का इलिसोवैडनी ओगोंगो खुला नहीं है, कोकून में सॉल्व में कद्दू तुरंत भुना जाता है। गालवोन, कटिंग और थप्पड़ मारना bkvuy blyu on msete। अतीत में, bkuvs को पूरी तरह से bosom में सील किया जा सकता है, सभी-फाड़ा पाठ बिना बरम के पढ़ता है। Pichriony Egoto, यह इसलिए है क्योंकि हम हर एक कद्दू को अलग से नहीं बनाते हैं, लेकिन यह सब ठोस है।

और यह एक और प्रमाण है कि मस्तिष्क पैटर्न के साथ काम करता है। मस्तिष्क से हमें प्राप्त होने वाली सभी नई जानकारी भी मौजूदा टेम्प्लेट के माध्यम से ड्राइव करने की कोशिश कर रही है, जो 3 मूल सिद्धांतों का सहारा ले रही है:

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

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

इसके विपरीत से

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

मोटापे के तरीकों के रूप में, आप इस सेट को ला सकते हैं:

• चरों, वर्गों, विधियों और कार्यों के लंबे और अर्थहीन नाम। न केवल पढ़ने के लिए लंबे शब्द कठिन हैं, लेकिन आपने अपने जीवन में अक्षरों और संख्याओं के ऐसे संयोजन कभी नहीं देखे हैं।
• , . , , . , . , . , . - , « ».
• , . . , , . . , .

यह पता चला है कि सुंदर कोड सरल निरर्थक दोहराव से बनाया जाना चाहिए । इस विषय पर एक प्रसिद्ध परिचित DRY भी है - अपने आप को दोहराएं नहीं। हालांकि, क्या यह हमेशा सच है यदि आप दुनिया को व्यापक रूप से देखते हैं?

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

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

यदि सरल गैर-अनावश्यक पैटर्न दृष्टिकोण की अक्षमता का एक उदाहरण है, तो क्या यह दृष्टिकोण हमेशा कोड के लिए काम करना चाहिए?

सरल ओओपी कोड कैसे प्राप्त करें और क्या मदद कर सकता है?

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

क्या डिजाइन पैटर्न हमेशा अच्छे होते हैं?

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

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

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

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

यह ठीक वही जगह है जहाँ सब कुछ सबसे जटिल हो जाता है:

• यदि आप इस या उस दृष्टिकोण से परिचित नहीं हैं, तो इसका विचार स्पष्ट, समझ से बाहर और नकारात्मक संदर्भ या सकारात्मक में नहीं हो सकता है। ऐसा मामला सबसे अप्रत्याशित है।
• आप दृष्टिकोण से परिचित हो सकते हैं और इसे नकारात्मक रूप से ले सकते हैं, उदाहरण के लिए, विरोधी पैटर्न।
• आप दृष्टिकोण से परिचित हो सकते हैं और इसे सकारात्मक रूप से ले सकते हैं।

पिछले दो मामलों में, आपके लिए निष्कर्ष निकालना और कोड और उसकी सुंदरता के बारे में अपने विचार व्यक्त करना बहुत आसान होगा।

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

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

एपीआई लेखन शैली

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

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

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

इसमें, निर्भरता बाँधने को एक द्रव शैली में लिखा जाता है:

Container.Bind<Foo>().AsSingle().NonLazy().FromInstance(FooInstance"); 

स्विफ्ट से एक तरल इंटरफ़ेस का एक बहुत प्रसिद्ध उदाहरण लोकप्रिय अल्मोफ़ायर फ्रेमवर्क है।
इसमें आप अक्सर ऐसे डिज़ाइन देख सकते हैं:

 Alamofire.request( .GET, "http:foo.com", parameters: ["include_docs": "true"],encoding: .URL).validate().responseJSON { (response) -> Void in... } 

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

भाषा सौंदर्य उत्पाद

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

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

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

निर्देश #region #endregion आपको कोड के ब्लॉक निर्दिष्ट करने की अनुमति देता है जिन्हें IDE में ढहाया जा सकता है। यह सबसे विवादास्पद साधनों में से एक है। कुछ टीमों में, इस निर्देश का उपयोग पूरी तरह से निषिद्ध है, दूसरों में इसे एक अनिवार्य आधार पर सलाह दी जाती है। इस निर्देश का उपयोग नहीं करने का एक तर्क यह है कि यह कोड को शब्दार्थ रूप से बेकार आवेषण के साथ पतला करता है जो आपको कोड पर ध्यान केंद्रित करने से रोकता है। एक तर्क "के लिए" के रूप में, एक प्रैक्टिस का हवाला दे सकता है जहां कक्षा विधियों को क्षेत्र द्वारा इस तरह से समूहीकृत किया जाता है कि आप आसानी से और कोड को संपादित किए बिना अपने आंतरिक कार्यान्वयन, या बाहरी एपीआई या एक या किसी अन्य पैटर्न के कार्यान्वयन को देख सकते हैं (जो अक्सर टेम्पलेट और कर सकते हैं) इसे क्षेत्र में हटा दिया जाता है ताकि आंखें कॉलस न करें)। संक्षेप में, हम कह सकते हैं कि उपकरण विवादास्पद से अधिक है।

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

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

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

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

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

ऊपर दिए गए बिंदुओं को देखते हुए, यह तर्क दिया जा सकता है कि सिंटैक्टिक शुगर भी एक विवादास्पद उपकरण है जो कोड को कम और सुंदर बना सकता है।

सॉफ्टवेयर साइड जो हमारी मदद कर सकता है

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

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

कोड सौंदर्य के संदर्भ में, आधुनिक IDE भी मदद करने की कोशिश करते हैं। उदाहरण के लिए, आप JetBrains - Rider से एक काफी युवा IDE ले सकते हैं। यहां, तार्किक स्थितियों का सरलीकरण, और एक चर नाम, टिप्पणियों और वर्तनी नामों की जाँच, स्वचालित संरेखण और बहुत अधिक बचाव में आने में मदद करता है।

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

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

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

संक्षेप में: विकास उपकरण का कोड की सुंदरता पर बहुत सकारात्मक प्रभाव पड़ता है। इसके अलावा, विषय का कारक इन उपकरणों की उपयोगिता को प्रभावित नहीं करता है।

एक सॉफ्टवेयर साइड जो सब कुछ बर्बाद कर सकता है।

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

समयपूर्व अनुकूलन सभी बुराई की जड़ है। -डॉनाल्ड नॉट

यह कथन सही है या नहीं, इस बारे में बहस कोड की सुंदरता की चिंता नहीं करती है और वर्तमान तर्क के दायरे से परे है।

लेकिन अनुकूलन कोड की सुंदरता पर प्रतिकूल प्रभाव डाल सकता है। यह हमेशा नहीं होता है, लेकिन कुछ प्रथाएं हैं जो सबसे अधिक पठनीय कोड से सबसे अधिक संभावना व्यक्त की जा सकती हैं। इस तरह के अनुकूलन के उदाहरण:

• स्मृति में डेटा / चर का संरेखण
• डेटा ओरिएंटेड डिज़ाइन (DOD) का उपयोग करना
• अतुल्यकालिक या बहुआयामी कार्यों का कार्यान्वयन

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

मैं सलाह के लिए किससे संपर्क कर सकता हूं?

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

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

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

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

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

1. अजगर - PEP8
2. सी # - स्टाइलकॉप
3. स्विफ्ट - आधिकारिक रेवेंडरलाइच.कॉम स्विफ्ट स्टाइल गाइड
4. उद्देश्य-सी - आधिकारिक raywenderlich.com उद्देश्य-सी शैली गाइड

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

निष्कर्ष के बिना निष्कर्ष

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