उच्च प्रदर्शन प्रोग्रामर की 7 आदतें

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



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

1. किसी और का कोड पढ़ना सीखें

आपके अलावा हर कोई भयानक कोड लिखता है। इसीलिए प्रोग्रामर की किसी और के कोड के साथ काम करने की क्षमता एक मूल्यवान कौशल है। यह हुनर ​​वही देता है जिसके पास बहुत कुछ होता है।

प्रोग्रामर को किसी और के कोड को समझने में सक्षम होना चाहिए। आखिरकार, यह उसका काम है। इससे कोई फर्क नहीं पड़ता कि इस तरह का कोड कितना भ्रामक है या कितना खराब लिखा गया है। वैसे, "किसी और का कोड" वही हो सकता है जो प्रोग्रामर ने खुद लिखा हो, एक साल पहले।

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

यदि आप किसी और का कोड पढ़ते हैं और उसमें कुछ ऐसा पाते हैं जो आपको पसंद नहीं है, तो इसके बारे में चुप रहने की कोशिश करें। इससे सहकर्मियों की नज़र में आपकी विश्वसनीयता बढ़ेगी।

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

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

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

किसी और के कोड को समझने की क्षमता प्रोग्रामर के मूल्य को बढ़ाती है क्योंकि वह समझ सकता है कि कैसे परिष्कृत सिस्टम भी व्यवस्थित किए जाते हैं, जैसे कि जब आप उन्हें देखते हैं, तो कोई और बस छोड़ देगा।

2. असफल परियोजनाओं के लिए एक स्वभाव विकसित करना

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

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

इसके अलावा, कुछ परियोजनाएँ किसी विशेष समस्या को हल करने के बजाय अत्यधिक प्रौद्योगिकी-उन्मुख हो सकती हैं। यह कभी-कभी, काम की शुरुआत में भी, हमें यह समझने की अनुमति देता है कि इस तरह की परियोजना के पूरा होने से बहुत लाभ नहीं होगा।

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

3. बैठकों से बचें

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

बैठकों में जाने वाला सबसे आम समय प्रबंधन तरीका हर दिन दो घंटे का ब्लॉक आवंटित करना है, जो एक निरंतर बैठक में बदल जाता है। कई लोग उस समय के लिए आवर्ती बैठकें करते हैं जो वे सबसे उपयुक्त मानते हैं। इन बैठकों का उपयोग काम के मुद्दों पर चर्चा करने के लिए किया जाता है।

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

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

4. मास्टर गिटहब

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

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

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

यदि आपको GitHub पर "धोखा शीट" की आवश्यकता है - तो करें।

GitHub के साथ उत्पादक तरीके से काम करना सीखें। इस मामले में, इससे कोई फर्क नहीं पड़ता कि आप इसे कैसे हासिल करते हैं।

5. सरल कोड लिखें जिसे बनाए रखना आसान है

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

अत्यधिक जटिल परियोजना संरचनाओं और सरल कोड के बीच एक संतुलन है। डिजाइन पैटर्न और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को बड़े पैमाने पर परियोजनाओं में कोड को सरल बनाने के लिए डिज़ाइन किया गया है। हालाँकि, हम जितना अधिक अमूर्त और इनकैप्सुलेशन का सहारा लेते हैं, उतने अधिक ब्लैक बॉक्स हमारे समाधानों में होते हैं, ऐसे समाधानों के लिए कोड को डीबग करना जितना मुश्किल होता है।

6. न कहना और प्राथमिकता देना सीखें

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

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

हम जो बात कर रहे हैं, उसे सीखना कठिन हो सकता है, क्योंकि लोग अक्सर हर उस समस्या को हल करने का प्रयास करते हैं, जो वे निर्धारित करते हैं। यह उन लोगों के लिए विशेष रूप से सच है, जिन्होंने अभी तक अनजान हैं और अपनी पहली नौकरी प्राप्त की है। पहले, उनके अध्ययन में, उन्हें ऐसे कार्य दिए गए जिनके साथ उन्होंने अच्छी तरह से सामना किया। अब, काम पर, वे एक ही उम्मीद करते हैं और किसी को निराश नहीं करने का प्रयास करते हैं।

यहां आपको यह समझने की आवश्यकता है कि बड़ी कंपनियों में अनंत प्रकार के कार्य होते हैं। सबसे महत्वपूर्ण बात केवल उन कार्यों को लेना है जिन्हें हल किया जा सकता है।

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

7. इस बारे में सोचना सीखें कि आपके विकास का उपयोग कैसे किया जाएगा।

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

दरअसल, यह "लैंडस्केप थिंकिंग" केवल "मूर्ख से सुरक्षा" के लिए नरम नाम है।

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

इस कौशल में सीमावर्ती स्थितियों को खोजने और विश्लेषण करने की क्षमता भी शामिल है जो सिस्टम के साथ काम करते समय उत्पन्न हो सकती है। इसमें डिज़ाइन स्तर पर उच्च-स्तरीय निर्णय योजना को समझने की क्षमता भी शामिल है।

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

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

परिणाम

इस लेख में, हमने आपको 7 कौशल के अवलोकन के साथ प्रस्तुत किया है जो उच्च-प्रदर्शन प्रोग्रामर के लिए सामान्य हैं। हम आशा करते हैं कि आपने उनमें से उन लोगों को ढूंढ लिया है जिन्हें आप स्वयं विकसित करना चाहते हैं।

प्रिय पाठकों! प्रोग्रामिंग में व्यावसायिकता के लिए प्रयास करने वाले व्यक्ति के लिए आप क्या सलाह देंगे?