अधिक अनुभवी डेवलपर्स की अनुपस्थिति में, मैं वास्तविक परियोजनाओं पर काम करते हुए अपने कौशल को कैसे सुधार सकता हूं? [बन्द है]


15

मैं C # और ASP.Net के साथ काम करते हुए एक छोटी कंपनी में मुख्य डेवलपर हूं। हमारी टीम छोटी है, 2-3 लोग, विकास और डिजाइन में बहुत अनुभव के बिना। मेरे पास अधिक वरिष्ठ डेवलपर्स से सीखने का अवसर नहीं है, मेरी टीम में कोई ऐसा नहीं है जो मेरा मार्गदर्शन कर सके और मुझे सर्वश्रेष्ठ दृष्टिकोणों को चुनने में मदद कर सके, क्योंकि मैं खुद अधिकांश परियोजनाओं का ध्यान रखता हूं।

अधिक अनुभवी डेवलपर्स की अनुपस्थिति में, वास्तविक परियोजनाओं पर काम करते हुए मैं अपने सॉफ्टवेयर विकास कौशल में सुधार कैसे कर सकता हूं?


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

टिप्पणी करने के लिए धन्यवाद .... मैं ज्यादातर समय बहुत से ब्लॉगों से गुजरता था और मैं वास्तव में खुद को कोडिंग के दौर में प्रभावित कर रहा था, लेकिन जब विकास की रणनीति (जैसे टीडीडी, डीडीडी, इत्यादि) को लागू करने का समय आ गया और डिजाइन पैटर (SOLID,) DRY, आदि), मैं उन्हें लागू करने से डरता हूं क्योंकि सिस्टम के विकास में समय की कमी है और आखिर में, मैं अपनी खुद की शैली का चयन करता हूं जो मुझे लगता है कि सर्वोत्तम तरीके से लागू नहीं किया गया है ....
आकाश केसी

1
@ लॉकरोडर मैं समझ सकता हूं कि कुछ लोग एक सीमित विकास समय के मुद्दे के लिए टीडीडी को अस्वीकार कर सकते हैं (हालांकि टीडीडी वास्तव में बाद में समय बचाता है), लेकिन मुझे समझ में नहीं आता है कि कैसे SOLID या DRY लगाने से समय की कमी प्रभावित हो सकती है?
सोंगो

1
@ यानिस रिज़ोस: प्रश्न के संपादन के लिए धन्यवाद ... अब, यह वास्तव में अच्छा लगता है ... प्रश्न का विषय वही रहता है .... एक बार फिर, आपका धन्यवाद ....
आकाश केसी

1
@LolCoder वास्तव में मुझे इसी तरह की समस्या थी जो मैंने कुछ समय पहले यहां पूछी थी।
सोंगो

जवाबों:


12

अधिक अनुभवी सहकर्मियों से सीखने के लिए बहुत सारे स्रोत हैं: किताबें, कुशल डेवलपर्स के ब्लॉग, स्टैक एक्सचेंज, व्याख्यान / सम्मेलन, आदि। कोड समीक्षाएं भी महत्वपूर्ण हैं, और CodeReview.SE एक अनमोल संसाधन है।

आइए देखें कि यह एक उदाहरण पर कैसे काम कर सकता है।

उदाहरण

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

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

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

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

जब आपके पास अपनी कंपनी में एक बनाने का अवसर होता है, तो आप इसे बनाना शुरू कर देते हैं। आपके पास कुछ मुद्दे हैं। कुछ कोड से संबंधित हैं; आप ढेर अतिप्रवाह पर सवाल पोस्ट करते हैं । अन्य डेटाबेस से संबंधित हैं; आप DBA.SE पर प्रश्न पूछते हैं

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

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

चीजों की खोज

IMHO, कठिन हिस्सा, जब आपके पास संरक्षक या अधिक अनुभवी सहकर्मी नहीं है, तो चीजों की खोज करना है, और खोज से मेरा मतलब है कि राज्य से पास "मैंने इस चीज के बारे में कभी नहीं सुना है" से "मैं" इसके बारे में सुना है लेकिन यह बहुत अच्छी तरह से नहीं जानता कि यह क्या है ”।

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

अगर कोई मुझे शैली के बारे में नहीं बताता है, तो मुझे कैसे पता चलेगा कि ऐसी कोई चीज मौजूद है?

जहाँ ब्लॉग या स्टैक एक्सचेंज जैसे संसाधन काम में आते हैं। विकिपीडिया मदद नहीं करेगा (जब तक कि आप प्रोग्रामिंग के बारे में यादृच्छिक पन्नों को मारने के दिन नहीं बिताते हैं), और किताबें शायद ही कभी उन चीजों के बारे में बात करती हैं।

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

एक बार जब आप एक नया शब्द खोज लेते हैं , तो इसके बारे में सीखना बहुत आसान होता है। यदि आपने एक नया शब्द "कोड कॉन्ट्रैक्ट्स" दिया है और आप एक सी # डेवलपर हैं, तो आप आसानी से MSDN (या बेहतर, जॉन स्कीट की पुस्तक में) पर खुद को पर्याप्त जानकारी पा सकते हैं।

जिज्ञासा मदद करती है

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

यहां तक ​​कि जब उनके पास कोई संरक्षक नहीं होता है, तब भी वे उन सभी चीजों को सीखते हैं जो कॉलेज में नहीं बताए जाते हैं।


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

@ लोलकोडर: आईएमओ, उन सर्वोत्तम दृष्टिकोणों को एक संरक्षक के साथ सीखना आसान है, लेकिन अभी भी मुझे अपने जवाब में सूचीबद्ध संसाधनों की मदद से उन्हें सीखना संभव है।
बजे आर्सेनी मूरज़ेंको

इस तरह के एक महान समझाया जवाब के लिए बहुत बहुत धन्यवाद ..... बहुत से धन्यवाद के साथ जवाब स्वीकार करने का समय ......
आकाश केसी

4

मैं एक समान स्थिति में हूं: हम एक छोटी सी टीम हैं और हमारा मुख्य विकास उत्पाद काम कोड के आधार पर ज्यादातर वृद्धिशील परिवर्तन है जो कुछ साल पुराना है।

कुछ तकनीकों का उपयोग मैं अप-टू-डेट रहने और अपने कौशल में सुधार करने के लिए कर रहा हूं।

काम पर:

  • पढ़ें: किताबें, ब्लॉग, पीआर सामग्री। मैं आरएसएस के कई फीड फॉलो करता हूं। जब दिन का ओ'रेली सौदा एक ऐसी तकनीक पर होता है, जिसके बारे में मैंने नहीं सुना, तो मैंने पुस्तक के विवरण के माध्यम से पढ़ा। यदि प्रौद्योगिकी का मेरे द्वारा काम की किसी भी चीज से बहुत अधिक संबंध है, तो मैं मेनमा के उत्तर के समान थोड़ी अधिक गहराई में शोध करते हुए पांच या दस मिनट बिताता हूं। मैं इसे कुछ अलग आरएसएस फ़ीड्स के साथ दोहराता हूं।
  • अपने प्रबंधन के साथ एक प्रशिक्षण योजना बनाएं जो कंपनी संसाधनों (समय और / या धन) के साथ समर्थित हो सकती है
  • अधिकांश प्रोग्रामर की प्रवृत्ति के विपरीत, परिवर्तन और नए डिजाइन विकल्पों को अपनाने की कोशिश करें। बदलाव के लिए बदलाव अच्छा नहीं है , लेकिन मेरा मानना ​​है कि अक्सर डेवलपर्स बदलाव के कारण नए डिजाइन या ढांचे का उपयोग करने से बचते हैं। यह चलने के लिए एक ठीक रेखा है, और बाध्यकारी निर्णय लेने में जल्दबाजी न करें, लेकिन चीजों को करने के नए तरीकों पर नज़र रखें। कुछ बदलावों से अप्रत्याशित लाभ हो सकता है: डीवीसीएस में जाने से मुझे हमारे कोड बेस पर अधिक आसानी से प्रयोग करने और नई तकनीकों को आज़माने में मदद मिलेगी।
  • कुछ लोगों को सम्मेलन पसंद हैं; मैंने पाया है कि निवेश किए गए समय के लिए भुगतान छोटा है।

काम के बाहर:

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

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

और एसओ या प्रोग्रामर पर जाना न भूलें। अक्सर।


जवाब के लिए बहुत बहुत धन्यवाद .... कोड शिविर का विचार वास्तव में अच्छा है लेकिन दुर्भाग्य से, मेरी जगह पर ऐसी कोई बात नहीं है .... अब, मैं निश्चित रूप से ओपन सोर्स प्रोजेक्ट में शामिल होगा ....
आकाश केसी

3

यहां उत्तर संभवतः बहुत मदद करेंगे, लेकिन मैं कुछ तनाव देना चाहूंगा: कुछ भी आपके साथ काम करने की जगह को बेहतर नहीं ले सकता है (मनमानी के लिए, और व्यक्तिगत, बेहतर की परिभाषाएं) दिन में 8 घंटे, सप्ताह में 5 दिन। इतना तय है।

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

जब आप उस कंपनी को ढूंढते हैं जो आपके लिए सही है, तो आप पाएंगे कि आप इसके भीतर विकसित होना जारी रख सकते हैं, इसके बाहर बढ़ने की तुलना में।


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

1

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

याद रखें कि अभ्यास स्थायी बनाता है, इसलिए यदि आप लगातार बेहतर तकनीक और ज्ञान की ओर काम नहीं कर रहे हैं, यदि आप किसी आलोचक या रोल मॉडल के साथ अलगाव में काम करते हैं, तो आप पा सकते हैं कि आपके कौशल में वृद्धि नहीं हुई है।

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


1

इससे पहले कि मैं किसी भी सुझाव पर पहुँचूँ, मुझे कहना होगा कि मैं एक साल पहले एक ही तरह की स्थिति में था।

यदि आप परियोजनाओं को पूरा कर रहे हैं, लेकिन आपको लगता है कि इसमें सुधार करने के लिए बहुत सी जगह है, तो यह अच्छी बात है।

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

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

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

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

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

जैसा कि मैंने अपने मूल उत्तर में कहा है, यह रात को नहीं होगा। मैं अब कुछ वर्षों से ऐसा कर रहा हूं और लगभग हर दिन मुझे पता चलता है कि मैं इसे गलत कर रहा हूं।

सौभाग्य!


1

समस्याओं को हल करने का अभ्यास करें। दूसरों के कोड को समझने और पढ़ने के लिए काम करें (github इसके लिए एक महान संसाधन है) और इसमें सुधार प्रस्तुत करें। परामर्श कार्य करना वास्तव में आपके कौशल सेट को व्यापक बनाने में आपकी सहायता कर सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.