अच्छा कोड लिखना कितना महत्वपूर्ण है।

मुझे बहुत सारे कोड पढ़ने हैं। यह खुला स्रोत है, और सभी प्रकार के चौखटे, और उद्यम अनुप्रयोग कोड। यह बाद की बात है कि मैं आज बात करना चाहूंगा।

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

लेकिन बकवास लिखने वाले लोग हैरान हैं। ये लोग, काफी अनुभव के साथ, कई भाषाओं को जानते हैं, कई किताबें पढ़ते हैं, OOP, SOLID, रीफैक्टरिंग, पैटर्न और अन्य अस्पष्ट शब्दों को जानते हैं। यही है, आप में से कई इस पोस्ट को पढ़ रहे हैं।

टूटी हुई विंडोज का सिद्धांत

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

बाद में, वैज्ञानिकों ने इस घटना को "ब्रोकन विंडोज का सिद्धांत" कहा। सिद्धांत के अनुसार, विकार या मानदंडों के उल्लंघन की कोई भी अभिव्यक्ति लोगों को नियमों के बारे में भूल जाने के लिए उकसाती है। सिद्धांत ने कई प्रयोगात्मक पुष्टि प्राप्त की और इसे काफी विश्वसनीय माना जा सकता है।

इसका विपरीत प्रभाव भी है। आदेश बनाए रखने से दूसरों को व्यवस्था बनाए रखने में मदद मिलती है।

यह कोड को कैसे प्रभावित करता है?

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

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

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

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

लोगों के लिए कोड लिखा है

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

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

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

गुणवत्ता के प्रति प्रतिबद्धता

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

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

स्पष्ट रूप से अपने कोड में अपने इरादे व्यक्त करें, गैर-स्पष्ट निहित पहलुओं को कम करें। कोड को यथासंभव संक्षिप्त बनाने का प्रयास न करें, इसे यथासंभव स्पष्ट करने का प्रयास करें।

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

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

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

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

अपना कोड रीयर करें। लिखते समय लगातार रिफलेक्टर। याद रखें कि "बाद में" refactoring कभी नहीं होती है।

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

कोड गुणवत्ता अर्थशास्त्र

हर कोई त्रुटि लागत वक्र से परिचित है:


कोडिंग चरण में पाया और समाप्त की गई त्रुटि परीक्षण के दौरान मिली त्रुटि से 10 गुना सस्ती है और उत्पादन में मिली त्रुटि से 100 गुना सस्ती है। इतिहास में त्रुटियों के वास्तविक उदाहरण हैं, जिनमें से सुधार ने हजारों डॉलर खर्च किए।

इसलिए, विकास के स्तर पर त्रुटियों को समाप्त करना बहुत महत्वपूर्ण है, और स्वयं डेवलपर्स के प्रयासों से।

अंत में

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