क्या सॉफ्टवेयर को पढ़ना और इसे खरोंच से समझना आसान है? [बन्द है]

Question

मैं और मेरा एक दोस्त कल एक बड़ी सी ++ सॉफ्टवेयर लिखने और इसे एक नई भर्ती के रूप में समझने के बीच अंतर के बारे में चर्चा कर रहे थे।

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

यह पहली बार में अजीब लग रहा है लेकिन बाद में हमें लगा कि यह उचित है

Comments

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

— यानि

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

— गुरू

Answer 1

अपने अनुभव के आधार पर, मैं सबसे आसान से लेकर कठिनतम कार्य करने के लिए निम्नलिखित गतिविधियों को रैंक करूंगा।

1. अच्छा कोड पढ़ना
2. खराब कोड लिखना
3. अच्छा कोड लिखना
4. खराब कोड पढ़ना

उपरोक्त रैंकिंग 2 निष्कर्ष की ओर ले जाती है

1. जबकि खराब कोड को पढ़ने की तुलना में कोड लिखना आसान है, लेकिन अपने स्वयं के कोड को लिखने की तुलना में अच्छे कोड को पढ़ना आसान है
2. बुरा कोड लिखना अच्छे कोड लिखने की तुलना में आसान है, लेकिन बुरा कोड लिखना आपको बुरा कोड पढ़ने के लिए सेट करता है, जो कि सबसे मुश्किल काम है। खासतौर पर चूंकि खराब कोड को जितना लिखा जाता है, उससे अधिक पढ़ा जाता है।

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

Comments

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

— बेन डीमोट

इसके अलावा, अच्छा कोड कैसे लिखें: cdn.thenextweb.com/files/2011/01/65987_700b.jpg

— CurtisHx

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

— मौविसील

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

— कज़

@mouviciel बहुत चालाक प्रोग्रामर द्वारा लिखे गए बुरे कोड को पढ़ना जो बुरा कोड नहीं लिखना चाहिए, कठिन हो सकता है। भोले प्रोग्रामर द्वारा लिखे गए बुरे कोड को पढ़ना आसान है। बस अपने "भोले टोपी" पर रखो और यह स्पष्ट हो जाता है कि कोड पूरा करने की कोशिश में क्या विफल हो रहा है। :)

— कज़

Answer 2

यह प्रश्न एक गलत सहमति के लिए अपील करता है। http://en.wikipedia.org/wiki/False-consensus_effect

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

Comments

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

— रॉबी डी

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

— मवॉस्को

Answer 3

एक बड़े C ++ सॉफ्टवेयर को लिखने और एक नई भर्ती के रूप में समझने के बीच अंतर

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

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

"नई भर्ती" के रूप में, आमतौर पर किसी मौजूदा परियोजना पर विशेष रूप से काम करना बेहतर होता है क्योंकि यह आपको उन सभी चीजों को सीखने में मदद करता है जो आप नहीं जानते हैं: व्यवसाय कैसे काम करता है, कैसे विभिन्न परियोजनाएं एक साथ काम करती हैं, मानकों और प्रथाओं को कोडिंग करती हैं, और यहां तक ​​कि (विशेषकर) क्या सुधार किया जा सकता है।

Comments

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

— गुरू

एक 'प्रोटोटाइप' या एक 'टूटा हुआ खिलौना' (ज्ञात कमियों के साथ और केवल विकल्पों का पता लगाने के लिए) का निर्माण करने से ऊपर के प्रश्नों के बारे में सोचने के लिए अपने आप को "मजबूर" करने में मदद मिलेगी। घटकों को जोड़ना और रिफैक्टिंग के बाद सुविधाओं को जोड़ना हाथ और उम्मीदवार समाधान (मंच खोज शायद) के माध्यम से मुद्दों के लिए एक "महसूस" प्राप्त करने में मदद करेगा।

— गुरू

Answer 4

यह एक दिलचस्प सवाल है, लेकिन मैं इसे पढ़ने और समझने की तुलना में इसे बनाने के लिए आसान होने के पक्ष की ओर झुकाव होगा।

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

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

लेकिन उन दोनों मामलों में, कोड को पढ़ना और वहां से जाना आसान होने जा रहा है, क्योंकि इसे खरोंच से पूरी तरह से लिखना है।

Answer 5

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

हालाँकि, यह पेड़ों का दृश्य है। वन दृश्य यह है कि इसे स्क्रैच से लिखने की तुलना में कोड को पढ़ना बहुत आसान है। उदाहरण के लिए, क्या स्क्रैच से एक नया वर्ड प्रोसेसर लिखना आसान है, या किसी मौजूदा कोड बेस को सुधारने के लिए पर्याप्त सीखना है?

जब आप कोड पढ़ना शुरू करते हैं, तो आप एक bazillion तरीके के बारे में सोच सकते हैं जिससे कोड को पढ़ने के लिए खुद को आसान बनाया जा सके। आप पहले कोड खर्च करते हुए चारों ओर कोडिंग करते हैं, कभी-कभी एक वास्तुकला में पूरी तरह से अनात्मता का पता लगाने की कोशिश करते हुए, आप इसे कैसे करना चाहते हैं। लेकिन यहां तक ​​कि वास्तव में बड़े कोड के आधारों में, आप शायद 40-80 घंटे अपने पहियों को काटते हुए बिताएंगे, उस एप्लिकेशन को बनाने में पहले से ही निवेश किए गए हजारों-हजारों आदमी घंटों की तुलना में।

Comments

क्या आप कोड लिख सकते हैं और इसे नहीं समझ सकते हैं? शायद कॉपी करें।

— जेएफओ

@ जेफ़ो हर समय - lol ...

— Robbie Dee

Answer 6

सॉफ्टवेयर के टुकड़े को लिखने वाले व्यक्ति को लगभग हमेशा कार्यक्रम की सबसे अच्छी समझ होगी बस इसे लिखते समय तर्क और उसकी सोच प्रक्रिया को जानने के कारण।

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

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

Answer 7

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

यह प्रश्न की ओर जाता है: क्या यह मामला है?

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

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

Answer 8

मैं StMotorSpark के उत्तर में हूँ, बस जोड़ना:
यह बहुत सारे कारकों पर निर्भर करता है, उदाहरण के लिए यह एक हाँ या कोई प्रश्न नहीं हो सकता है:

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

Comments

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

— सेंटमोटरस्पार्क

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

— जोसटाइकेरा