कोड क्वालिटी कैसे सुधारे

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

लेकिन अपने जीवन को बेहतर कैसे बनाएं? कोड गुणवत्ता स्तर को कैसे विकसित किया जाए। मुझे इस विषय पर अपने स्वयं के प्रतिबिंब के कुछ नियम बताए।

1. किए गए कार्यों के बारे में पूरी जानकारी।

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

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

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

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

2. अनुमेय बुराई की एक स्पष्ट रूपरेखा की उपस्थिति।

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

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

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

3. फ्रैंक।

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

स्वाभाविक रूप से, मान्यता के लिए दंड नहीं होना चाहिए।

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

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

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