अच्छे पदों के लिए "चेतना की धारा के डंप" और "माइक्रो रीफैक्टरिंग" की शैली में कोड , जिसे हम अक्सर भूल जाते हैं ।

• अधिकांश प्रोग्रामर किसी और के कोड को क्यों नहीं पढ़ना चाहते?
• क्यों रीफैक्टरिंग और बदलाव एक गंभीर समस्या है?
• ऐसा अक्सर क्यों होता है कि खरोंच को फिर से लिखना आसान है?
• कुछ प्रोग्रामर दूसरों को अच्छे या बुरे शब्द क्यों कहते हैं?

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

• नूडल्स
• सार संक्षेप
• ढीली कपल वास्तुकला
• मेरे सिर से बाहर कोड?

नूडल्स

एक बहुत ही लगातार मामला तब होता है जब आपके और मेरे पास एक उत्कृष्ट कार्यक्रम होता है, जो एक बार में लिखा जाता है, और पहले से ही काम करने और जो आवश्यक है उसे करने में अच्छा है।

ऐसा लगता है कि आप आनन्दित हो सकते हैं, लेकिन कठोर वास्तविक जीवन से कुछ परिस्थितियां हैं, गुलाबी चश्मे के पीछे दिखाई नहीं दे रही हैं।
1. किसी भी कार्यक्रम में त्रुटियाँ हैं। इसलिए, यह साथ होना चाहिए।
2. जल्द या बाद में, किसी भी कार्यक्रम को बदलने की आवश्यकता है। इसलिए, यह साथ होना चाहिए।
3. कोई भी प्रोग्राम या उसके हिस्से दूसरे प्रोग्राम के घटक बन सकते हैं। और मूल समाधानों के साथ चलना होगा।

यह समझ में आता है कि प्रत्येक कार्यक्रम को इस तथ्य को ध्यान में रखते हुए लिखना है कि कोई उसके साथ होगा। अन्य प्रोग्रामर आपके कोड को पढ़ेंगे, और केवल आपके कोड से वे आपके नैतिक चरित्र के बारे में निष्कर्ष निकालेंगे। और बहुत बार यह "अन्य प्रोग्रामर" आप स्वयं होंगे। Axiom, है ना?

क्या सभी को अपने अपने कोड का विश्लेषण करने के लिए वापस जाना होगा?

एक विशिष्ट उदाहरण पर विचार करें - एक शांत कार्यक्रम, जहां सभी कोड को एक ढेर में डंप किया जाता है।



ऐसा तब होता है जब एक घटक एक ही समय में होता है:
- अंतिम निष्कर्ष और डेटा की प्राप्ति;
- स्पष्ट रूप से अलग प्रकृति के डेटा प्रसंस्करण;
- नेस्टेड स्थितियों के निकायों में विस्तृत एल्गोरिदम।

वास्तव में, ऐसा प्रतीत होता है, एक अलग विधि (फ़ंक्शन) में कुछ लाइनों में कोड क्यों रखा जाता है? किसी के लिए यह आश्चर्य की बात होगी, लेकिन यह समझ में आता है।

सार संक्षेप

प्रोग्रामिंग की सबसे मजबूत विधि अमूर्त है - कार्यक्रम और उसके सभी घटकों को भागों में अलग करना।

• आवेदन की व्यावसायिक तर्क विषय प्रणाली, कार्यक्षमता, चरणों और संसाधित-प्रेषित सूचना (एमवीसी) के प्रकारों के आधार पर, वर्ग प्रणाली के अनुसार वितरित किया जाता है।
• आवेदन में कई व्यावहारिक रूप से असंबंधित घटक होते हैं। अक्सर उन्हें विभिन्न भाषाओं में भी लिखा जाता है, और एपीआई के माध्यम से बातचीत होती है। उदाहरण के लिए, एक मोटे खिलौने के लिए - बीएल परत, भौतिकी, ध्वनि, रैस्टराइज़र। भौतिकी और ग्राफिक्स - O ++ में C ++, Business Logic, GUI और Sound - Lua या Python। एक वेबसाइट के लिए - एक वेब सर्वर के अलग घटकों, दुभाषिया, एक व्याख्या की भाषा में सीएमएस, छवि और वीडियो प्रसंस्करण के लिए अलग-अलग कार्यक्रम, एक ड्राइवर और एक डेटाबेस इंजन।
• एक वर्ग के भीतर, क्रियाओं का विभाजन विभिन्न विशेषताओं (कार्यों) में कार्यात्मक विशेषता द्वारा होता है। निजी तरीकों को अलग किया जाता है, कम से कम डेटा प्रोसेसिंग को नामित करने के लिए जो केवल कक्षा के आंतरिक उद्देश्यों के लिए प्रासंगिक है, और वर्ग के उपयोगकर्ता के लिए महत्व और मूल्य की जानकारी।

ढीली कपल वास्तुकला

प्रोग्रामिंग में ढीली युग्मित वास्तुकला एक सहन शक्ति है। उसके लिए धन्यवाद, उदाहरण के लिए, CodeIgniter, YII, jQuery, Chomium, Half Life, Counter Strike जैसी अच्छी चीजें पैदा हुईं - सूची बहुत बड़ी है।

शिथिल युग्मित वास्तुकला का विचार यह है कि विभिन्न स्तरों पर कार्यक्रम घटकों में एक दूसरे पर बहुत कम या कोई निर्भरता नहीं होती है।

उदाहरण के लिए, एक या कई, जानबूझकर छोटी संख्या में "प्रेषण" फ़ंक्शन एक वर्ग में आवंटित किए जाते हैं जो कार्यों को करने के लिए कक्षा के निजी तरीकों सहित अन्य तरीकों को कॉल करते हैं।

उच्च-स्तरीय उदाहरण चौखटे के सभी उपयोगकर्ताओं के लिए जाने जाते हैं - ऐसे घटकों के सेट होते हैं जिनका आप वास्तविक जरूरतों के आधार पर उपयोग कर सकते हैं या लागू नहीं कर सकते हैं।

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



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

एक अच्छा समाधान विभिन्न अनुप्रयोग स्तरों पर शिथिल युग्मित वास्तुकला का उपयोग करना है। तब भी सबसे जटिल डेटा फ्लो आरेख को पढ़ना आसान होगा।

मेरे सिर से बाहर कोड?

हमेशा नीचे बैठने का एक प्रलोभन होता है और एक निर्णय झपट्टा में लिखकर आपके सिर से बाहर हो जाता है। खुद अक्सर पाप करते हैं।

लेखन कोड के चरण में, ज्यादातर मामलों में कोई समस्या नहीं होती है। समस्याएं बाद में उत्पन्न होती हैं, जो लेख की शुरुआत में उजागर की जाती हैं।

सभी समस्याओं का मुख्य अप्रिय परिणाम समय का नुकसान है। अक्सर ये समय नुकसान उनके परिणामों में बहुत बड़ा और घातक होता है। और उन्हें रोकने और कम करने के लिए इतना मुश्किल नहीं है।

यह वाक्यांश "प्रोग्राम डिज़ाइन" वाक्यांश को Google में रोकने और टाइप करने के लिए समझ में आता है। सभी पाए गए तरीके ग्राफिक, सरल और समझ और उपयोग के लिए सुलभ होंगे।



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

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