आवश्यक डेवलपर कौशल जो आपके कोड को बेहतर बनाएगा

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

अनावश्यक कोड को ना कहें. आपको बस तीन अक्षर एक साथ रखना है और शब्द बोलना है। आइए इसे एक साथ करने का प्रयास करें: "नहीं!"

पर रुको। हम यह क्यों कर रहे हैं? आख़िरकार, एक प्रोग्रामर का मुख्य कार्य कोड लिखना है। लेकिन क्या आपको कोई कोड लिखने की ज़रूरत है जो आपसे पूछा जाए? नहीं! "कोड कब नहीं लिखना है यह समझना एक प्रोग्रामर के लिए संभवतः सबसे महत्वपूर्ण कौशल है।" पठनीय कोड की कला.

अनुस्मारक: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रचार कोड का उपयोग करके किसी भी स्किलबॉक्स पाठ्यक्रम में नामांकन करते समय 10 रूबल की छूट।

स्किलबॉक्स अनुशंसा करता है: व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो".

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

प्रोग्रामर किस चीज़ से आँखें मूँद लेते हैं?

आपके द्वारा लिखा गया सभी कोड अन्य डेवलपर्स के लिए समझने योग्य होना चाहिए, और उसका परीक्षण और डीबग किया जाना चाहिए।

लेकिन एक समस्या है: आप जो कुछ भी लिखेंगे, वह आपके सॉफ़्टवेयर को जटिल बना देगा और संभवतः भविष्य में बग उत्पन्न कर देगा।

रिच स्क्रेंट के अनुसार, कोड हमारा दुश्मन है। यहाँ वह लिखते हैं:

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

आपको कैसे पता चलेगा कि कोड कब नहीं लिखना है?

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

आपको स्पष्ट रूप से समझना चाहिए कि आपके प्रोजेक्ट को क्या चाहिए और क्या नहीं।

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

आपको उन सुविधाओं को जोड़ने के प्रस्तावों को दृढ़ता से "नहीं" कहना होगा जो एप्लिकेशन के मुख्य कार्य से संबंधित नहीं हैं। यही वह क्षण है जब यह स्पष्ट हो जाता है कि अतिरिक्त कोड की आवश्यकता नहीं है।

अपने एप्लिकेशन का फोकस कभी न खोएं।

हमेशा अपने आप से पूछें:

— अब कौन सा कार्य लागू किया जाना चाहिए?
— मुझे कौन सा कोड लिखना चाहिए?

मन में आने वाले विचारों पर सवाल उठाएं और बाहर से आने वाले सुझावों का मूल्यांकन करें। अन्यथा, अतिरिक्त कोड प्रोजेक्ट को ख़त्म कर सकता है।

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

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

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

परियोजना अंततः बहुत बड़ी हो जाती है, और प्रत्येक नई सुविधा को जोड़ने के लिए अधिक से अधिक प्रयास की आवश्यकता होती है। यहां तक ​​कि किसी बेहद मामूली सी चीज के लिए भी आपको कई घंटे खर्च करने पड़ते हैं। मौजूदा त्रुटियों को ठीक करने से नई त्रुटियाँ सामने आती हैं, और आवेदन जारी करने की समय सीमा चूक जाती है।

अब हमें परियोजना के जीवन के लिए लड़ना होगा। क्यों?

तथ्य यह है कि आपको बस यह समझ में नहीं आया कि आपको अतिरिक्त कोड कब नहीं जोड़ना चाहिए, और हर सुझाव और विचार का उत्तर "हां" में दिया। आप अंधे थे, नई चीजें बनाने की चाहत ने आपको महत्वपूर्ण तथ्यों को नजरअंदाज करवा दिया।

यह किसी डरावनी फिल्म की स्क्रिप्ट जैसी लगती है, है ना?

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

"मेरे सबसे उत्पादक दिनों में से एक वह था जब मैंने कोड की 1000 पंक्तियाँ हटा दीं।"
- केन थॉम्पसन.

कोड कब नहीं लिखना है यह सीखना कठिन है। लेकिन यह जरूरी है.

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

बनाते रहें, लेकिन जानें कि कब ना कहना है।

स्किलबॉक्स अनुशंसा करता है:

• ऑनलाइन पाठ्यक्रम लागू किया "पायथन डेटा विश्लेषक".
• ऑनलाइन पाठ्यक्रम "प्रोफेशन फ्रंटएंड डेवलपर".
• व्यावहारिक वर्ष पाठ्यक्रम "PHP डेवलपर 0 से PRO तक".

स्रोत: www.habr.com