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

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

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

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

प्रोजेक्ट का आकार

छोटे प्रोजेक्ट

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

मध्यम परियोजनाएँ

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

बड़ी परियोजनाएँ

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

परियोजना का समर्थन

बिना समर्थन के प्रोजेक्ट

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

समर्थित परियोजनाओं

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

परियोजना का पैमाना

आंतरिक परियोजनाएं

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

सार्वजनिक परियोजनाओं

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

बारीकियों वाले प्रोजेक्ट

हाई लोड प्रोजेक्ट्स

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

थर्ड-पार्टी लाइब्रेरी का उपयोग करने वाली परियोजनाएँ

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

नौसिखिया टीम प्रोजेक्ट

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

गैर-उत्पादन परियोजनाएं

प्रदर्शन परियोजनाओं

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

शैक्षणिक परियोजनाएँ

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

स्थानीय परियोजनाएं

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

प्रोटोटाइप परियोजनाएँ

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

मनोरंजन परियोजनाओं

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

सारांश

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