एक सॉफ्टवेयर इंजीनियर के रूप में, दूसरे के कोड को पढ़ना कितना महत्वपूर्ण है?

Question

मैं एक नवोदित सॉफ्टवेयर इंजीनियर (अब सीएसओ में प्रमुख) हूं, और मैं वास्तव में अन्य लोगों के कार्यक्रमों को समझने के लिए संघर्ष करता हूं। मैं जानना चाहता हूं कि क्या यह कौशल (या इसकी कमी) मेरे लिए एक बाधा हो सकती है, और यदि हां, तो मैं इसे कैसे विकसित कर सकता हूं?

Comments

क्या आपको लगता है कि आपको कोड समझ में आया है जब आपको यह समझाया गया है या आप सिर्फ परीक्षण और त्रुटि से सीख रहे हैं?

— जेएफओ

इसे 'कोडिंग स्टाइल' क्यों कहा जाता है? क्या कारण है कि आपको कोड पढ़ने में समस्या हो रही है क्योंकि यह खराब स्वरूपित है? कोड को पढ़ने की क्षमता का मतलब यह नहीं है कि आपको बहुत खराब स्वरूपित या अस्पष्ट कोड को समझने की क्षमता की आवश्यकता है। यदि यह मदद करता है तो पहले एक फ़ॉर्मेटिंग टूल के माध्यम से कोड चलाएँ।

— ब्रैंडिन

बस आज सुबह एक लेख पढ़ा जिसने मुझे इस प्रश्न की याद दिला दी। क्यों क्रोम पर काम करने से मुझे

— एरिक किंग

यह एक बड़ा सवाल है! मेरा एक अनुवर्ती प्रश्न था: यदि आप मुख्य रूप से अपने स्वयं के कोड पर काम करते हैं (जैसे कि एक छोटी परियोजना पर वैज्ञानिक प्रोग्रामर के रूप में), तो आपको पढ़ने के लिए अच्छा कोड कैसे मिलेगा? इससे पहले पूछा गया है: softwareengineering.stackexchange.com/questions/69892/…

— गौरव

आपके प्रोग्रामिंग कौशल को बेहतर बनाने के लिए आपने जो सबसे प्रभावी काम किया है, उसकी

Answer 1

यह आवश्यक है।

जिस तरह से आप इसे विकसित करते हैं वह आपके अपने कोड (बहुत सारे) को लिखकर है, और हां, अन्य लोगों के कोड को पढ़ने के माध्यम से संघर्ष कर रहा है।

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

यह इस प्रकार है कि आपको अच्छा कोड पढ़ना चाहिए ।

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

आपको एल्गोरिदम और डेटा संरचनाओं का भी अध्ययन करना चाहिए।

कोरोलरी: आपको हमेशा ऐसा कोड लिखने का प्रयास करना चाहिए जिसे अन्य डेवलपर्स आसानी से समझ सकें।

Comments

कोरोलरी: कोड लिखने का प्रयास करके सरल शुरुआत करें जिसे आप आसानी से समझ सकते हैं :-)

— gnasher729

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

— डेविड अरनो

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

— ब्रैंडिन

Answer 2

यह बहुत महत्वपूर्ण है।

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

यह एक ऐसा कौशल है जो अभ्यास और धैर्य के माध्यम से हासिल किया जाता है, और कई मामलों में, यह एक ऐसा कौशल है, जो कई लोगों को वास्तव में स्नातक होने के बाद काम करने और उस पहली नौकरी को प्राप्त करने का अधिक अवसर नहीं मिलता है। आराम करें!

(हालाँकि यदि आपके स्कूल में एक सह-ऑप कार्यक्रम है, जो आपको बड़ी परियोजनाओं पर काम करने के लिए पूर्व-स्नातक अनुभव देगा, जो कि ज्यादातर अन्य लोगों द्वारा लिखे गए हैं और यह आपको अकादमिक क्रेडिट देता है! कुछ देखने के लिए, यदि यह उपलब्ध है)

Answer 3

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

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

Comments

इसके अलावा, आपके द्वारा उपयोग किए जाने वाले एक ओपन सोर्स प्रोजेक्ट को जानने के लिए और यह समझने की कोशिश करें कि आंतरिक कोड कैसे काम कर सकता है

— RMalke

Answer 4

पढ़ने और लिखने दोनों कोड में अलग-अलग कौशल हैं।

• एक वाक्य रचना है। यह जानने के लिए कि विधि घोषणा क्या दिखती है।
• दूसरा इरादा है। यह जानना कि विधि क्यों है और यह किस उद्देश्य से कार्य करता है।

बनाम पढ़ने लिखने के लिए। हां पढ़ना जरूरी है।
कुछ अधिकतम जो हमारे साथ कई मदद करते हैं:

• कोड हर एक बार लिखे जाने के लिए 10 बार (कम से कम) पढ़ा जाता है।
• किसी और के कोड को पढ़ना अक्सर होता है ... मुझे भविष्य में कोड पढ़ना है।
• मैं 1 वर्ष से अधिक समय से अपनी कोड शैली का बचाव नहीं करूंगा, तब से इसमें सुधार हुआ है।

ठीक है। तो यह सब बहुत अच्छा है। अब नीचे जो आप अनुभव कर रहे हैं।

OMG, स्रोत कोड की लाइनों और कक्षाओं कि लंबे समय से पागल निर्भरता और हर बार के साथ लाइनों के सैकड़ों रहे हैं दसियों हजार के साथ इस गुस्सा विशाल codebase मैं कुछ मैं अपने सिर में 10 के स्तर को बनाए रखने के लिए है, आदि, आदि पालन करने की कोशिश
ध्वनि परिचित ? हाँ। गहरी सांस। आराम करें। यह आम है। यह उत्पादन प्रणालियों से बना है। इन प्रतीत होने वाली अकल्पनीय स्थितियों में लोग जीवित रहते हैं (और फूल जाते हैं):

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

Comments

और अंत में, अच्छा प्रोग्रामर स्रोत संस्करण नियंत्रण प्रणालियों में परिवर्तन करते समय सार्थक प्रतिबद्ध संदेश लिखते हैं। (जवाब देने के लिए स्वतंत्र महसूस करें)

— rwong

Answer 5

इनमें से अधिकांश उत्तर स्व-सुधार के लिए कोड रीडिंग के महत्व पर केंद्रित हैं। मैं तहे दिल से इससे सहमत हूं और इसका समर्थन करता हूं।

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

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

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

Answer 6

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

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

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

आशा है कि यह मदद, निराश नहीं है यह पूरी तरह से सामान्य है। कोड के साथ अधिक समय बिताएं और आप अंततः इसे प्राप्त करेंगे।

Answer 7

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

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