शिल्प प्रोग्रामर। सुनहरे नियम

यह पोस्ट पीटर गुडलिफ़ की उल्लेखनीय पुस्तक, द क्राफ्ट ऑफ़ अ प्रोग्रामर के "सुनहरे नियमों" का एक अंश है।

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

अध्याय 1. रक्षा पकड़ना

कोई धारणा मत बनाओ। औपचारिक रूप से निश्चित नहीं होने वाली मान्यताएँ अक्सर विफलताओं का कारण बनती हैं, विशेष रूप से बढ़ते कोड आकार के साथ।

जितनी अधिक भीड़, उतनी कम गति। हमेशा सोचें कि आप कीबोर्ड से क्या टाइप करने जा रहे हैं।

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

कंपाइलर चेतावनियों में एक टन गूंगी त्रुटियों को पहचानने में मदद मिलती है। हमेशा उनका आउटपुट शामिल करें। अपने कोड को चुपचाप संकलित रखें।

सभी सीमित संसाधनों को बचाएं। ध्यान से उनके कब्जे और रिहाई को व्यवस्थित करें।

अध्याय 2. सूक्ष्म गणना

समझें कि वास्तव में आपके स्रोत कोड को कौन पढ़ेगा: अन्य प्रोग्रामर। उन की अपेक्षा के साथ लिखें।

पता लगाएं कि आपकी चुनी हुई भाषा के लिए कौन से कोड मानक हैं, और उनमें से प्रत्येक को अभ्यास में मास्टर करें। प्रत्येक के फायदे और नुकसान का आकलन करें।

एक सही कोडिंग स्टाइल चुनें और हर समय उसके साथ रहें।

यदि आपके समूह ने एक निश्चित कोडिंग मानक अपनाया है, तो उससे चिपके रहें। अपना पसंदीदा स्टाइल छोड़ दें।

धार्मिक युद्धों को ना कहें। उनमें प्रवेश न करें। एक तरफ कदम।

अध्याय 3. मेरे नाम में क्या है?

वस्तुओं को पारदर्शी नाम देना सीखें - उन्हें स्पष्ट रूप से वर्णन करना चाहिए कि उनके पीछे क्या छिपा है।

एक अच्छे नाम के साथ आने के लिए, मुख्य बात यह स्पष्ट रूप से समझना है कि यह किसके लिए है। केवल इस मामले में नाम सार्थक हो सकता है। यदि आप ऑब्जेक्ट के लिए एक अच्छा नाम नहीं ले सकते हैं, तो इसका उद्देश्य स्पष्ट होने पर खुद से पूछें।

आपके साथ काम करने वाली भाषा में नामकरण के नियमों को जानें। इससे भी महत्वपूर्ण बात, इस भाषा के मुहावरों को जानें। क्या नाम बनाने के मानक तरीके हैं? इसलिए इनका उपयोग करें।

नाम की स्पष्टता अपनी संक्षिप्तता के लिए बेहतर है।

छोटे और लंबे नामों के सापेक्ष गुणों पर विचार किया जाना चाहिए, विशेष रूप से चर के दायरे पर निर्भर करता है।

एक नामकरण सम्मेलन जो चर नामों और प्रकार के नामों के बीच अंतर करता है, बेहतर होता है।

कार्यों को व्यक्त करने वाले वाक्यांशों के रूप में, बाह्य दृष्टि से कार्यों को नाम दें। एक तार्किक ऑपरेशन का वर्णन करें, इसे लागू करने का तरीका नहीं।

नामों में अनावश्यक शब्दों से बचें। विशेष रूप से, नाम में - वर्ग, डेटा, वस्तु और प्रकार जैसे शब्द।

ऐसे नामस्थान और पैकेज नाम दें जो तार्किक रूप से सामग्री से संबंधित हों।

C / C ++ में मैक्रोज़ को हमेशा अच्छी तरह से दिखाई देने के लिए कैपिटल किया जाता है, और संघर्षों से बचने के लिए उनके नाम सावधानी से चुने जाते हैं। अन्य वस्तुओं को कभी भी बड़ा न करें।

एक सुसंगत नामकरण प्रणाली चुनें और इसे लगातार लागू करें।

नाम के लिए आवश्यक विस्तार की डिग्री इसके आवेदन के संदर्भ पर निर्भर करती है। नाम बनाते समय संदर्भ संबंधी जानकारी पर विचार करें।

अध्याय 4. साहित्यिक आलोचना

बाहरी दस्तावेज की आवश्यकता वाले कोड न लिखें। वह अविश्वसनीय है। कोड लिखें जो बिना किसी दस्तावेज़ीकरण के समझ में आता है।

एक कोड लिखें जो एक सामान्य व्यक्ति बिना तनाव के पढ़ सके। कंपाइलर किसी तरह सामना करेगा।

जादू नंबर से बचें। स्थिरांक का उपयोग करें।

कोड के महत्वपूर्ण खंडों को सामान्य पृष्ठभूमि के खिलाफ खड़ा होना चाहिए और पढ़ने में आसान होना चाहिए। उन सभी चीजों को छिपाएं जो ग्राहकों को रुचि नहीं लेनी चाहिए।

समूह से संबंधित जानकारी के लिए प्रयास करें। भाषा उपकरणों के साथ इस समूहीकरण दृश्य बनाएं।

व्यर्थ त्रुटि संदेश प्रदर्शित न करें। संदर्भ के आधार पर सबसे अधिक प्रासंगिक जानकारी प्रदान करें।

कोड में टिप्पणी तभी डालें जब अन्य तरीकों से इसकी समझ को सुविधाजनक बनाना संभव न हो।

स्वचालित रूप से अपने कोड के लिए प्रलेखन उत्पन्न करने के लिए सक्षम प्रलेखन उपकरणों का उपयोग करें।

अध्याय 5. मार्जिन नोट्स

अधिक से अधिक टिप्पणियाँ लिखना सीखें। मात्रा से अधिक गुणवत्ता को वरीयता दें।

यह सुनिश्चित करने के लिए समय निकालें कि आपके कोड को बहुत सारी टिप्पणियों के रूप में समर्थन की आवश्यकता नहीं है।

अच्छी टिप्पणियां बताती हैं कि क्यों, कैसे नहीं।

प्रत्येक तथ्य के लिए एक स्रोत। टिप्पणियों में कोड की नकल न करें।

अपने कोड का वर्णन करने, रुकने और सोचने के लिए अपने आप को क्रियात्मक टिप्पणियाँ लिखना क्या यह एक संकेत है कि उच्च क्रम की एक निश्चित समस्या है?

सोचें कि आप टिप्पणियों में क्या लिखते हैं; चाबियों पर विचारपूर्वक प्रेस न करें। कोड के संदर्भ में टिप्पणी फिर से पढ़ें। क्या इसमें जानकारी है?

टिप्पणियाँ कोड का हिस्सा हैं। उन्हें व्यवस्थित करें ताकि पढ़ने का क्रम स्वाभाविक हो।

टिप्पणी के रूप में एक प्रोलॉग के साथ प्रत्येक स्रोत कोड फ़ाइल प्रदान करें।

टिप्पणियाँ वर्तमान से संबंधित होनी चाहिए, न कि अतीत से। जो बदल गया है, उसका वर्णन न करें और जो पहले हुआ है, उसके बारे में बात न करें।

यदि आपने कोड बदल दिया है, तो इसके ठीक बाद आने वाली टिप्पणियों की जाँच करें।

अध्याय 6. लोग गलतियाँ करते हैं

त्रुटि से निपटने एक गंभीर मामला है। आपके कोड की स्थिरता इस पर निर्भर करती है।

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

आपको प्राप्त होने वाले त्रुटि संदेशों की उपेक्षा कभी न करें। यदि त्रुटि संदेशों के लिए एक चैनल है, तो इसके कारण हैं।

सभी त्रुटियों को सबसे अनुकूल संदर्भ में संभालें जब यह स्पष्ट हो जाता है कि इसके साथ सही तरीके से कैसे निपटें।

त्रुटियों को अनदेखा करने से आपका समय नहीं बचता है। आप एक गलत हैंडलर लिखने की आवश्यकता से अधिक समय गलत प्रोग्राम व्यवहार के कारणों का पता लगाने में बिताएंगे।

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

अध्याय 7. प्रोग्रामर का टूलकिट

अपने मानक उपकरण दूर-दूर तक जानें। जिस समय आप उन्हें सीखने में खर्च करेंगे, तुरंत भुगतान कर देंगे।

व्यावहारिक रूप से प्रोग्रामिंग टूल का इलाज करें; उनका उपयोग केवल तभी करें जब वे आपके जीवन को आसान बनाते हैं।

पता करें कि किस प्रकार के उपकरण मौजूद हैं। पता करें कि आप उन्हें कहाँ प्राप्त कर सकते हैं, भले ही आपको इस समय उनकी आवश्यकता न हो।

प्रत्येक कार्य का अपना उपकरण होता है। स्लेजहेमर के साथ नट्स पर क्लिक न करें।

अपने टूल के नवीनतम संस्करणों के लिए बने रहें, लेकिन अपडेट करते समय सावधान रहें।

कोड संपादक चुनना महत्वपूर्ण है; यह आप कोड लिखने पर एक बड़ा प्रभाव है।

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

अध्याय 8. परीक्षण का समय

परीक्षण केवल त्रुटियों की उपस्थिति को प्रकट कर सकता है। यह दोषों की अनुपस्थिति को साबित नहीं कर सकता है। यदि कोड कई अपर्याप्त परीक्षणों से गुजरा हो, तो शांत भाव से न दें।

आपके द्वारा लिखे गए कोड के प्रत्येक टुकड़े का परीक्षण करें। किसी और से यह अपेक्षा न करें कि वह आपके लिए ऐसा करेगा।

परीक्षण को प्रभावी बनाने के लिए, इसे पहले से शुरू करने की आवश्यकता होती है जब पता चला त्रुटियां अभी तक बहुत नुकसान नहीं कर सकती हैं। टेस्ट कोड काम करने से पहले लिखा जा सकता है!

पहचान की गई सभी त्रुटियों के लिए परीक्षण लिखें।

जितनी बार संभव हो अपने परीक्षण चलाएं।

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

परीक्षणों का एक पूरा सेट लिखें, जिनमें से प्रत्येक कोड के एक विशिष्ट पहलू का परीक्षण करेगा। पंद्रह परीक्षण जो एक ही त्रुटि दिखाते हैं वे 15 परीक्षणों की तुलना में कम उपयोगी होते हैं जो 15 अलग-अलग त्रुटियां दिखाते हैं।

कोड आर्किटेक्चर को परीक्षण करना आसान बनाना चाहिए।

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

निर्माण प्रक्रिया के दौरान स्वचालित रूप से परीक्षण करें।

अध्याय 9. समस्या निवारण

जब संकलक सभी चेतावनी संदेश प्रदर्शित करता है तो कोड संकलित करें। इस प्रकार, आप उन्हें वास्तविकता में सामना करने से पहले संभावित समस्याओं की खोज करेंगे।

डीबगिंग के सुनहरे नियम का पालन करें: अपने सिर के साथ सोचें।

"सिस्टमेटिक" डीबगिंग के लिए एक उचित समय सीमा निर्धारित करें, और यदि यह असफल है, तो अधिक व्यवस्थित विधि पर स्विच करें।

डीबग किए गए कोड की जांच करें - यह उस कोड की त्रुटियों को खोजना कठिन है जिसे आप नहीं समझते हैं।

जब आप गलती ढूंढते हैं, तो किसी पर भी अविश्वास करें। तुरंत खारिज करने के बजाय, सबसे अविश्वसनीय कारणों की जांच करें। कुछ भी मत लो।

यदि उत्पाद का निर्माण विफल हो गया है, तो पहले संकलक त्रुटि को देखें। इसके बाद के पोस्ट बहुत कम विश्वसनीय हैं।

डिबगिंग एक व्यवस्थित कार्य है, धीरे-धीरे त्रुटि के स्थान के चारों ओर रिंग को संकीर्ण करता है। आपको उसे एक कैडी के खेल की तरह नहीं मानना ​​चाहिए।

एक त्रुटि की जगह स्थापित करने में पहला कदम यह निर्धारित करना है कि इसे आत्मविश्वास से कैसे पुन: पेश किया जाए।

एक ज्ञात स्थान से शुरू करें, उदाहरण के लिए, एक कार्यक्रम की असामान्य समाप्ति के बिंदु से। फिर विफलता के कारण की ओर पीछे हटें।

यदि आपको यह लगता है कि आपने त्रुटि का कारण पाया है, तो अच्छी तरह से जांच करें और सुनिश्चित करें कि आपने गलती नहीं की है। बहुत पहले परिकल्पना को लापरवाही से स्वीकार न करें।

डिबगिंग केवल तभी समाप्त होती है जब आप साबित करते हैं कि त्रुटि हल हो गई है और समस्या हमेशा के लिए हल हो गई है।

त्रुटियों को ठीक करते समय अत्यधिक सावधानी बरतें। सुनिश्चित करें कि आपका संशोधन किसी और चीज़ को अपंग न करे।

त्रुटि को ठीक करना, जांचें कि क्या यह कोड के करीबी वर्गों में खुद को दोहराता है। एक बार और सभी के लिए त्रुटि को हटा दें: इसके सभी डुप्लिकेट को तुरंत सही करें।

प्रत्येक सही त्रुटि से, निष्कर्ष निकालें। क्या इसे टाला जा सकता था? क्या इसका तेजी से पता लगाया जा सकता है?

उन व्यवहारों से सामना करना होगा जिन्हें आप समझा नहीं सकते हैं, डीबगर्स का मामूली रूप से उपयोग करें। अपने कोड को कैसे काम करता है, यह जानने की कोशिश किए बिना तुरंत उन पर दौड़ने की आदत न डालें।

अध्याय 10. कोड जैक निर्मित

स्रोत पेड़ के हिस्से के रूप में निर्माण प्रणाली पर विचार करें और उन्हें एक साथ रखें। वे निकट से संबंधित हैं।

परियोजना में शामिल सभी प्रोग्रामर को एकल बिल्ड सिस्टम का उपयोग करना चाहिए। अन्यथा, वे सभी अलग-अलग सॉफ़्टवेयर पैकेज संकलित करेंगे।

सही बिल्ड सिस्टम आपको बार-बार शारीरिक रूप से समान बाइनरी फ़ाइलों को बनाने की अनुमति देता है।

आपको तीन साल पहले स्रोत का पेड़ प्राप्त करने में सक्षम होना चाहिए और इसे फिर से इकट्ठा करना चाहिए।

सही प्रणाली एक ऑपरेशन की तरह दिखती है। यह एक बटन दबाने या एक कमांड निष्पादित करने के लिए पर्याप्त है।

प्रत्येक विधानसभा नियम के लिए, एक उपयुक्त सफाई नियम लिखें जो पूरे ऑपरेशन को रद्द करता है।

अपने सॉफ़्टवेयर उत्पाद के लिए एक स्वचालित निर्माण प्रक्रिया व्यवस्थित करें। अपने कोड के संचालन की मदद से इसकी जाँच करें।

फाइनल बिल्ड हमेशा साफ स्रोत कोड से किया जाता है। सुनिश्चित करें कि बाद में आप हमेशा एक संग्रह या संस्करण नियंत्रण प्रणाली से इस स्वच्छ स्रोत कोड प्राप्त कर सकते हैं।

अपने आवेदन के अंतिम विन्यास का परीक्षण करें, न केवल काम करने वाली विधानसभाओं, उनके बीच छोटे अंतर कोड व्यवहार को प्रतिकूल रूप से प्रभावित कर सकते हैं।

अध्याय 11. गति की प्यास

आपको शुरू से ही कार्यक्रम की प्रभावशीलता के बारे में सोचने की ज़रूरत है - यह उम्मीद न करें कि विकास के अंत में आप इसे छोटे परिवर्तनों की कीमत पर बढ़ा पाएंगे।

कोड की शुद्धता उसकी गति से बहुत अधिक महत्वपूर्ण है। गलत होने पर परिणाम प्राप्त करने का क्या फायदा!

अनुकूलन के विकल्पों पर विचार करें; क्या आप अन्य तरीकों से कार्यक्रम की प्रभावशीलता में सुधार कर पाएंगे?

पता लगाएँ कि क्या वास्तव में कोड को अनुकूलित करने की आवश्यकता है, लेकिन शुरुआत से ही प्रभावी, उच्च-गुणवत्ता वाला कोड लिखना बेहतर है।

किसी अन्य कार्य से अलग कोड का अनुकूलन करें ताकि एक कार्य के परिणाम दूसरे को प्रभावित न करें।

कार्यक्रम के अंतिम संस्करणों का अनुकूलन करें, न कि मध्यवर्ती बिल्ड।

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

कार्यक्रम की प्रभावशीलता की कमी के कारणों की खोज करते समय अपने आप को प्रोफाइलर तक सीमित न करें; वे और गहरे हो सकते हैं।

अनुकूलन से पहले और बाद में माप लेना सुनिश्चित करें।

मौजूदा एल्गोरिदम के कार्यान्वयन को बेहतर बनाने की कोशिश करने की तुलना में एक धीमी गति से एल्गोरिथ्म को तेजी से बदलना बेहतर है।

अध्याय 12. असुरक्षा परिसर

ध्यान रखें कि आपके पास क्या महत्वपूर्ण संसाधन हैं। क्या आपके पास विशेष रूप से संवेदनशील जानकारी या विशेष विशेषताएं हैं जिनके लिए आप शिकार कर सकते हैं? उनकी रक्षा करो।

कंप्यूटर सिस्टम जितना जटिल होता है, उतनी ही अधिक संभावना है कि इसकी सुरक्षा प्रणाली में अंतराल होते हैं। इसलिए, जितना संभव हो उतना सरल सॉफ्टवेयर लिखें!

कमजोरियों से न गुजरें और खुद को अजेय न समझें। कहीं न कहीं कोई है जो आपके कोड पर एक शोषण लागू करने की कोशिश कर रहा है।

अपने कंप्यूटर पर विश्वसनीय स्रोतों से केवल प्रोग्राम चलाएं। स्रोतों की विश्वसनीयता निर्धारित करने के लिए एक स्पष्ट नीति स्थापित करें।

सुरक्षा किसी भी सॉफ्टवेयर उत्पाद का एक महत्वपूर्ण वास्तुकला पहलू है। विकास के शुरुआती दौर में इसकी देखभाल नहीं करना एक गलती होगी।

प्रोग्राम डिजाइन करते समय, केवल प्रसिद्ध, सुरक्षित तृतीय-पक्ष घटकों पर भरोसा करें।

अपने सिस्टम पर हमला करने के लिए तैयार हो जाइए, और इसके सभी हिस्सों को इस बात को ध्यान में रखकर डिजाइन कीजिए।

अध्याय 13. डिजाइन का महत्व

प्रोग्रामिंग डिजाइन का काम है। यह एक रचनात्मक और कलात्मक कार्य है, न कि यांत्रिक कोडिंग।

कुंजियों पर दस्तक देने से पहले सोचें; एक समझने योग्य परियोजना बनाओ। अन्यथा, आपको अराजकता मिलेगी, कोड नहीं।

कम, बेहतर। आपका लक्ष्य एक साधारण कोड होना चाहिए जो छोटे आकार के साथ बड़ी समस्याओं को हल करता है।

एक साधारण बात करना मुश्किल है। यदि कोड की संरचना स्पष्ट लगती है, तो यह मत सोचो कि यह आसान था।

डिज़ाइन मॉड्यूल जो आंतरिक रूप से जुड़े हुए हैं और न्यूनतम रूप से परस्पर जुड़े हुए हैं। अपघटन कार्य के सही विभाजन को भागों में प्रतिबिंबित करना चाहिए।

एक ऐसी रेखा खींचें जिसे कोई भी पार नहीं करना चाहिए: स्पष्ट एपीआई और इंटरफेस को परिभाषित करें।

डिजाइन बाद के विस्तार को ध्यान में रखते हुए, लेकिन इसे ज़्यादा मत करो, अन्यथा आप एक कार्यक्रम नहीं लिखेंगे, लेकिन एक ओएस।

एक बार करें। अच्छा करो। दोहराव से बचें।

डिज़ाइन किए गए चरण में कोड पोर्टेबिलिटी के मुद्दों को हल करें, बजाय अपने समाप्त कोड को फिर से काम करने के।

डिज़ाइन टूल और कार्यप्रणाली के बारे में व्यावहारिक रहें: जब यह वास्तव में उपयोगी हो, तो उनका उपयोग करें, लेकिन वे उनके दास नहीं बनते।

अध्याय 14. सॉफ्टवेयर आर्किटेक्चर

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

सिस्टम आर्किटेक्चर का वर्णन ऐसी जगह पर रखें जहाँ यह सभी के लिए सुलभ हो, जिन्हें इसकी आवश्यकता हो सकती है: रखरखाव और स्थापना, प्रबंधकों और संभवतः ग्राहकों के लिए जिम्मेदार प्रोग्रामर।

आर्किटेक्चर विनिर्देश आपके सिस्टम की स्थिति की रिपोर्ट करने के लिए एक महत्वपूर्ण उपकरण है। सुनिश्चित करें कि यह सॉफ़्टवेयर की स्थिति से मेल खाता है।

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

अच्छा सिस्टम आर्किटेक्चर सरल होना चाहिए। एक पैरा और एक साधारण आरेख से मिलकर एक विवरण पर्याप्त है।

वास्तुकला प्रणाली के सबसे महत्वपूर्ण घटकों और उनकी बातचीत को परिभाषित करता है। वह उनके उपकरण का वर्णन नहीं करता है।

अच्छी वास्तुकला पैंतरेबाज़ी, विस्तार, संशोधन के लिए जगह छोड़ती है। लेकिन उसका समुदाय उचित सीमाओं को पार नहीं करता है।

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

अध्याय 15. सॉफ्टवेयर - विकास या क्रांति?

याद रखें कि कैसे आसानी से परिवर्तनीय कोड घटता है। संशोधनों से बचें जिसके बाद सिस्टम बदतर स्थिति में है।

टूटे हुए कोड का पता लगाना सीखें। इसके लक्षणों की जांच करें और अत्यधिक सावधानी के साथ विघटित कोड को संभालें।

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

भविष्य में इसे संशोधित करने के लिए संभावित आवश्यकता को ध्यान में रखते हुए एक नया कोड लिखें। इसे स्पष्ट, विस्तार और सरल बनाएं।

संशोधन करते समय सावधानी बरतें। इस बात से अवगत रहें कि कोई पास कोड को संशोधित कर रहा है या नहीं।

खतरनाक परिवर्तनों के बारे में बात करें, खासकर जब एक नया संस्करण जारी करने की तैयारी हो। यहां तक ​​कि सबसे सरल संशोधन अन्य कोड के संचालन को बाधित कर सकते हैं।

बिना सोचे समझे कोड को स्मैक न दें। रुकें और सोचें कि आप क्या कर रहे हैं।

अपने सभी संशोधनों का पूरी तरह से परीक्षण करें, चाहे वे कितने भी सरल हों। बेवकूफ की गलती को याद करना बहुत आसान है।

अध्याय 16. एनकोडर

पता करें कि आप किस प्रकार के प्रोग्रामर हैं। निर्धारित करें कि आप अपने अच्छे गुणों का उपयोग कैसे कर सकते हैं और बुरे लोगों के लिए क्षतिपूर्ति कर सकते हैं।

अध्याय 17. साथ में हम शक्ति हैं

एक टीम में काम करने की क्षमता एक उच्च योग्य सॉफ़्टवेयर डेवलपर का एक महत्वपूर्ण गुण है।

परिणामी कोड टीम के भीतर संबंधों और बाहरी संपर्कों द्वारा दोनों से प्रभावित होता है। देखें कि वे आपके काम को कैसे प्रभावित करते हैं।

अपनी टीम को उस कोड के अनुसार व्यवस्थित करें जिसे आप बनाने जा रहे हैं, और इसके विपरीत नहीं - मौजूदा टीम के अनुसार कोड।

टीम के सामान्य काम के लिए प्रभावी संचार के लिए चैनलों की उपस्थिति महत्वपूर्ण है। ऐसे चैनलों को संगठित और बनाए रखने की जरूरत है। एक अच्छा प्रोग्रामर अच्छी तरह से संवाद करने में सक्षम होना चाहिए।

प्रोग्रामर में से कोई भी कोड के किसी भी हिस्से का मालिक नहीं है। प्रतिभागियों में से प्रत्येक के पास पूरे कोड तक पहुंच है और आवश्यकतानुसार इसे संशोधित कर सकते हैं।

सफल टीमों का विकास और उद्देश्यपूर्ण तरीके से काम करना; उनकी घटना को मौके के लिए जिम्मेदार नहीं ठहराया जा सकता है।

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

अध्याय 18. स्रोत कोड की रक्षा करना

कोड में मान है। उसके साथ सम्मान और देखभाल करें।

संस्करण नियंत्रण प्रणाली एक महत्वपूर्ण सॉफ्टवेयर विकास उपकरण है। यह विश्वसनीय टीम के काम के लिए आवश्यक है।

भंडार पर ध्यान दें। सावधान रहें कि निष्क्रिय कोड न लिखें जो अन्य डेवलपर्स को काम करने की अनुमति नहीं देगा।

अपने डेटा का बैकअप लें। आपदा से उबरने के लिए इंतजार किए बिना वसूली की रणनीति विकसित करें।

अध्याय 19. विनिर्देशों

सॉफ्टवेयर विकास प्रक्रिया को न केवल विनिर्देशों की आवश्यकता है, बल्कि उनकी उच्च गुणवत्ता है।

सॉफ्टवेयर डेवलपर्स के बीच विनिर्देशों एक महत्वपूर्ण संचार तंत्र हैं। वे ऐसी जानकारी दर्ज करने की सेवा करते हैं, जिसे खोना या भूलना नहीं चाहिए।

सॉफ़्टवेयर आवश्यकताओं को पहले से सेट किया जाना चाहिए ताकि अनुचित अपेक्षाएं उत्पन्न न हों, कार्यक्षमता के विस्तार को बाधित करने और डेवलपर की चिंता को कम करने के लिए।

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

तकनीकी प्रलेखन को संकलित करने के लिए सक्षम प्रोग्रामिंग टूल का उपयोग करें। एक पाठ संपादक में एक दस्तावेज न लिखें जो जल्दी से अप्रचलित हो जाता है।

विनिर्देशन संकलित करते समय, इसकी सामग्री पर विचार करें। एक ऐसी संरचना और शब्दावली चुनें, जो दर्शकों के लिए समझ में आए, और सुनिश्चित करें कि दस्तावेज़ सही है, पूर्ण है और इसका अपना विवरण है।

स्पेसिफिकेशन से बचना खतरनाक और अनप्रोफेशनल है। यदि आपके पास विनिर्देशों को लिखने के लिए पर्याप्त समय नहीं है, तो शायद कोड लिखना भी पर्याप्त नहीं है।

अध्याय 20. शूटिंग की समीक्षा

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

एक सिस्टम बनाते समय, पता करें कि क्या आपको समीक्षा करने की आवश्यकता है, और यदि हां, तो क्या कोड।

ध्यान से समीक्षा के लिए कोड का चयन करें। यदि आप पूरे कोड की समीक्षा नहीं कर सकते हैं, तो एक सूचित विकल्प बनाएं। यादृच्छिक और बेकार कीमती समय पर लेने की जरूरत नहीं है।

जो भी कोड लिखा गया है, वह सहकर्मियों द्वारा सहकर्मी की समीक्षा और सावधानीपूर्वक अध्ययन के अधीन है। अपने कोड की समीक्षा करें।

समीक्षा की सफलता लेखक और समीक्षकों की सकारात्मक स्थिति पर अत्यधिक निर्भर है। समीक्षा का उद्देश्य संयुक्त रूप से कोड में सुधार करना है, न कि अपराधियों को नियुक्त करना या कार्यान्वयन के दौरान किए गए निर्णयों को सही ठहराना है।

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

अध्याय 21. रस्सी कब तक है?

एक सॉफ्टवेयर उत्पाद विकास की अवधि का अनुमान लगाना एक तथ्यात्मक अनुमान है। प्रत्येक मूल्यांकन के लिए, इसमें आपके आत्मविश्वास का कुछ माप होता है।

सॉफ्टवेयर विकास के समय का अनुमान लगाना वास्तव में मुश्किल काम है। काम की मात्रा को कम करके आंकने से बचें। एक गलत मूल्यांकन के संभावित परिणामों पर विचार करें।

हर कोई (आप सहित) शॉर्टहैंड शेड्यूल चाहता है। आपके लिए आवंटित समय में वास्तव में क्या किया जा सकता है, इसके बारे में मूर्ख मत बनो। प्रसव के लिए तैयार कोड प्रदान करने की आवश्यकता होने पर अवास्तविक वादे न करें।

समय के अनुमानों को छोटे कार्यों पर लागू करने की आवश्यकता होती है जिनके कार्यभार को समझना आसान है। माप की इकाई मानव-घंटे या मानव-दिन होनी चाहिए।

भेद जिसका काम आप समय के संदर्भ में मूल्यांकन कर रहे हैं: आपका अपना (ऐसी प्रणाली पर जिसे आप अच्छी तरह से समझते हैं) या किसी और का (किसी को जिसे सिस्टम का अध्ययन करने की आवश्यकता हो सकती है)।

अकेले मूल्यांकन न करें। अपनी रेटिंग स्पष्ट करने के लिए अन्य लोगों की राय जानें।

अपने काम को शेड्यूल करें ताकि आपके पास अपने कोड को साफ करने का समय हो। तकनीकी ऋण वापस करने की योजना।

योजना के साथ अपनी प्रगति की लगातार जाँच करें। तब अचानक पता चला अंतराल नहीं होगा।

अध्याय 22. कार्यक्रम के लिए नुस्खा

अच्छे प्रोग्रामर प्रोग्राम करना जानते हैं - वे काम के तरीके और तकनीक जानते हैं।

हमारी सॉफ़्टवेयर परियोजनाएं उन शैलियों और प्रक्रियाओं द्वारा निर्धारित की जाती हैं जो हम लागू करते हैं। वे कोड के रूप और गुणवत्ता को अनिवार्य रूप से प्रभावित करते हैं।

विकास प्रक्रिया के बिना, टीम अराजकता की स्थिति में है। कार्यक्रम भाग्य के कारण दिखाई देते हैं, न कि लक्षित कार्यों के परिणामस्वरूप।

पर्चे कार्यक्रम का विकल्प कई कारणों से निर्धारित किया जा सकता है, जो अच्छा होना चाहिए। आपकी पसंद के लिए प्रेरणा बहुत कुछ कहती है कि आपका संगठन कितना परिपक्व है।

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

एक प्रक्रिया चुनना महत्वपूर्ण है। ज्यादातर मामलों में असफल परियोजनाएं तकनीकी कारणों से नहीं हैं। लगभग हमेशा, मुख्य कारणों में से एक प्रक्रिया का खराब संगठन है।

अध्याय 23. संभव से परे

विभिन्न विषय क्षेत्रों में विभिन्न प्रकार की प्रोग्रामिंग होती है। प्रत्येक क्षेत्र की अपनी विशेष समस्याएं हैं और विशिष्ट कौशल और अनुभव की आवश्यकता है।

अपने प्रोग्रामिंग क्षेत्र को जानें। जानें इसकी बारीकियां। महान कार्यक्रमों को लिखना सीखें जो उसकी आवश्यकताओं के अनुरूप हों।

अध्याय 24. आगे क्या?

एक अच्छा प्रोग्रामर बनने के लिए, आपको सही स्थिति चुनने की आवश्यकता है - जिस कोण से सॉफ़्टवेयर का निर्माण माना जाता है।

अपने कौशल में सुधार करें। प्रोग्रामिंग के प्यार और उस पर एक मास्टर होने की इच्छा न खोएं।