विचारशील कोडिंग

कोड के बारे में बात कर रहे एक कोडर

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

जावास्क्रिप्ट के पिरामिड

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

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

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

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

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

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

मशीनिस्ट की मानसिकता

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

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

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

प्रक्रिया। बाहर निकलें ();

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

• Tom