अनुवादक की प्रस्तावना: इस लेख को पढ़ने के बाद, आप आश्चर्यचकित हो सकते हैं या क्रोधित भी हो सकते हैं। हां, हम भी आश्चर्यचकित थे: लेखक ने कथित तौर पर टीम में पदानुक्रम के बारे में कभी नहीं सुना, स्थिति के साथ कार्यों की स्थापना के बारे में "इसे जल्दी और बिना तर्क के करें"। हाँ, यह बात है, यह थोड़ा अजीब पाठ है। दरअसल, लेखक प्रोग्रामर को सिस्टम आर्किटेक्ट की भूमिका निभाने की पेशकश करता है - फिर आपको आर्किटेक्ट की आवश्यकता क्यों है? लेकिन इन सभी आपत्तियों को आपको मुख्य बात से नहीं छिपाना चाहिए - फिर भी हमने इस पाठ को क्यों लिया और अनुवाद किया। वह भूमिकाओं के बारे में नहीं है। यह पाठ पेशेवर दृष्टिकोण और जागरूकता के बारे में है। सच्चाई यह है कि जब आप सिर्फ अपने कार्यों के अर्थ के बारे में सोचने के बिना "वे क्या कहते हैं" करते हैं, तो आप कभी भी एक महान प्रोग्रामर नहीं बनेंगे।अतिरिक्त कोड के लिए नहीं कहो। आपको बस तीन अक्षरों को एक साथ रखना है और शब्द कहना है। आइए इसे एक साथ करने की कोशिश करें: "नू!"
लेकिन हे। हम ऐसा क्यों कर रहे हैं? आखिरकार, प्रोग्रामर का मुख्य कार्य कोड लिखना है। लेकिन क्या आपके लिए आवश्यक किसी भी कोड को लिखना आवश्यक है? नहीं! "समझना जब आपको कोड नहीं लिखना चाहिए तो प्रोग्रामर के लिए सबसे महत्वपूर्ण कौशल है।"
पठनीय संहिता की कला ।
हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।
स्किलबॉक्स अनुशंसा करता है: व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो" ।
प्रोग्रामिंग समस्या समाधान की कला है। और आप इस कला के स्वामी हैं।
कभी-कभी, जितनी जल्दी हो सके शुरू करने की कोशिश करते हुए, हम कार्य को पूरा करने के अलावा और किसी चीज के बारे में नहीं सोचते हैं। और यह और भी गंभीर समस्या पैदा कर सकता है।
प्रोग्रामर किससे मुंह मोड़ लेते हैं?
आपके द्वारा लिखे गए सभी कोड को अन्य डेवलपर्स द्वारा समझा जाना चाहिए, साथ ही परीक्षण और डीबग किया जाना चाहिए।
लेकिन एक समस्या है: आप जो भी लिखते हैं, वह आपके सॉफ़्टवेयर को जटिल करेगा और संभवतः भविष्य में बग को जोड़ देगा।
रिच स्केटर के अनुसार,
कोड हमारा दुश्मन है । यहाँ वह लिखते हैं:
“कोड खराब है क्योंकि यह सड़ना शुरू कर देता है और निरंतर रखरखाव की आवश्यकता होती है। नई सुविधाओं को जोड़ने के लिए अक्सर पुराने कोड के संशोधन की आवश्यकता होती है। यह जितना बड़ा होता है, त्रुटि होने की संभावना उतनी ही अधिक होती है और संकलन में अधिक समय लगता है। एक और डेवलपर को यह पता लगाने के लिए और समय चाहिए। और अगर आपको रिफैक्टिंग की आवश्यकता है, तो निश्चित रूप से ऐसे टुकड़े हैं जो बदलने के लायक हैं। बल्क कोड का अर्थ अक्सर किसी परियोजना के लचीलेपन और कार्यक्षमता को कम करना होता है। एक सरल और सुरुचिपूर्ण समाधान जटिल कोड की तुलना में तेज़ है। "
जब आपको कोड नहीं लिखना चाहिए तो कैसे पता करें?
समस्या यह है कि प्रोग्रामर अक्सर उन कार्यों की संख्या को अतिरंजित करते हैं जो उनके आवेदन की आवश्यकता है। नतीजतन, कोड के कई खंड अपूर्ण रहते हैं या कोई भी उपयोग नहीं करता है, लेकिन वे आवेदन को जटिल करते हैं।
आपको स्पष्ट रूप से पता होना चाहिए कि आपके प्रोजेक्ट को क्या चाहिए और क्या नहीं।एक उदाहरण एक एप्लिकेशन है जो केवल एक कार्य को हल करता है - यह ई-मेल का प्रबंधन करता है। इसके लिए दो कार्य शुरू किए गए हैं - पत्र भेजना और प्राप्त करना। आपको यह उम्मीद नहीं करनी चाहिए कि मेल मैनेजर एक साथ एक कार्य प्रबंधक बन जाएगा।
आपको उन कार्यों को जोड़ने के लिए सुझाव के बिना दृढ़ता से कहने की आवश्यकता है जो आवेदन के मुख्य कार्य से संबंधित नहीं हैं। यह ठीक क्षण है जब यह स्पष्ट हो जाता है कि अतिरिक्त कोड की आवश्यकता नहीं है।
कभी भी अपने एप्लिकेशन पर ध्यान केंद्रित न करें।हमेशा अपने आप से पूछें:
- अब किस समारोह को लागू किया जाना चाहिए?
- क्या कोड लिखने लायक है?
उन विचारों पर सवाल करें जो दिमाग में आते हैं और बाहर से सुझावों का मूल्यांकन करते हैं। अन्यथा, अतिरिक्त कोड सिर्फ परियोजना को मार सकता है।
यह जानने के बाद कि आपको बहुत अधिक नहीं जोड़ना चाहिए, कोड आधार को कड़े नियंत्रण में रखेगा।
पथ की शुरुआत में, प्रोग्रामर के पास केवल दो या तीन स्रोत फाइलें होती हैं। सब कुछ सरल है। आवेदन को संकलित करने और चलाने के लिए कम से कम समय की आवश्यकता होती है; यह हमेशा स्पष्ट होता है कि कहां और क्या देखना है।
जैसे ही एप्लिकेशन का विस्तार होता है, अधिक से अधिक कोड फाइलें दिखाई देती हैं। वे निर्देशिका को भरते हैं, प्रत्येक सैकड़ों लाइनों के साथ। यह सब सही ढंग से व्यवस्थित करने के लिए, आपको अतिरिक्त निर्देशिकाएं बनानी होंगी। एक ही समय में, यह याद रखना मुश्किल हो जाता है कि कौन से कार्य किस कारण से और किन कार्यों के लिए जिम्मेदार हैं; कीड़े को पकड़ने में भी अधिक समय लगता है। परियोजना प्रबंधन अधिक जटिल होता जा रहा है, न केवल एक, बल्कि कई डेवलपर्स को सब कुछ का ट्रैक रखने की आवश्यकता होती है। तदनुसार, लागत, दोनों मौद्रिक और अस्थायी, बढ़ रहे हैं, और विकास प्रक्रिया बाधित है।
परियोजना अंततः विशाल हो जाती है, प्रत्येक नए फ़ंक्शन को जोड़ना बड़ी और बड़ी कठिनाई के साथ दिया जाता है। यहां तक कि कुछ बहुत ही तुच्छ के लिए आपको कई घंटे बिताने होंगे। मौजूदा त्रुटियों के सुधार से नए लोगों का उदय होता है, आवेदन की रिलीज की तारीखें बाधित होती हैं।
अब हमें परियोजना के जीवन के लिए लड़ना होगा। क्यों?
तथ्य यह है कि आप बस यह नहीं समझ पाए कि आपको अतिरिक्त कोड जोड़ने की आवश्यकता नहीं है, और उन्होंने हर वाक्य और विचार के लिए "हां" उत्तर दिया। आप अंधे थे, कुछ नया बनाने की इच्छा ने आपको महत्वपूर्ण तथ्यों की अनदेखी कर दी।
एक हॉरर फिल्म की स्क्रिप्ट की तरह लगता है, है ना?
यदि आप हां कहना जारी रखते हैं तो वास्तव में यही होगा। समझने की कोशिश करें कि कोड कब जोड़ने लायक नहीं है। प्रोजेक्ट से अनावश्यक हटा दें - यह आपके जीवन को बहुत सुविधाजनक बना देगा और एप्लिकेशन के अस्तित्व को बढ़ा देगा।
"मेरे सबसे उत्पादक दिनों में से एक था जब मैंने कोड की 1000 लाइनें हटा दी थीं।"
- केन थॉम्पसन।
समझने के लिए सीखना जब आपको कोड लिखने की आवश्यकता नहीं होती है। लेकिन यह आवश्यक है।
हां, मुझे पता है कि आपने सिर्फ एक डेवलपर के रास्ते पर काम किया है और कोड लिखना चाहते हैं। यह अच्छा है, इस पहले प्रभाव को न खोएं, लेकिन उत्साह के कारण महत्वपूर्ण कारकों की दृष्टि न खोएं। हमने परीक्षण और त्रुटि के माध्यम से सब कुछ महसूस किया। आप भी गलतियाँ करेंगे और उनसे सीखेंगे। लेकिन अगर आप ऊपर से सबक सीख सकते हैं, तो आपका काम और अधिक सचेत हो जाएगा।
बनाते रहो, लेकिन पता है कि कब नहीं कहना है।
स्किलबॉक्स अनुशंसा करता है: