किसी और के कोड पर काम करना [बंद]


60

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


103
वास्तविक दुनिया में आपका स्वागत है जहां कोड हमेशा रहता है और प्रोग्रामर आते हैं और जाते हैं।

65
यह किसी और का कोड नहीं है। अब आपका कोड है।
बुहब

6
@ वागट फिर से ओपी को अनुभवहीनता और ज्ञान की कमी के कारण हो सकता है। अगर मैं किसी सहकर्मी के कार्य में गया, तो आवश्यक कोड की एक पंक्ति को हटा दिया, कहा कोड को लाइव कर दिया और इसे तोड़ दिया, यह मेरी लापरवाही के लिए नीचे है, न कि संरचनात्मक रूप से बिना कोड के कोड
rickyduck

19
@Bhhb: लेकिन, अब से 6 महीने बाद, जब आप इसे वापस आते हैं, तो यह किसी और का कोड होगा, यहां तक ​​कि आपके द्वारा लिखे गए भाग ;-)
Jörg W Mittag

6
खुश रहो। आप एक महत्वपूर्ण कौशल विकसित कर रहे हैं जो आपको कम अनुभव या अकादमिक-केवल अनुभव वाले लोगों से अलग करेगा। यह कठिन माना जाता है। इसलिए यह मूल्यवान है।
स्कॉट सी विल्सन

जवाबों:


59

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

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

ईगल76dk इस काम को करने के लिए अपने प्रबंधक को बोर्ड में लाने के बारे में एक महान बिंदु बनाता है - ईगलीनडेक के पोस्ट में अधिक विवरण।

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


12
इकाई परीक्षण लेखन किया जा सकता है तुलना में आसान है, हालांकि किया, कोड और उसके निर्भरता के आधार पर ... कहा
Svish

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

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

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

2
लेखन इकाई परीक्षण नीचे-ऊपर का दृष्टिकोण है और इसमें बहुत अधिक समय लगेगा और इस प्रकार यह अक्सर बड़ी परियोजनाओं में व्यावहारिक नहीं होता है। पूरे मामले को नए सिरे से लिखना इस मामले में तेज हो सकता है। आपको अच्छी तरह से मिल सकता है (और फिर समय तय करने के लिए) यूनिट बग्स जो महत्वपूर्ण नहीं हैं क्योंकि मामला एक कार्यात्मक संदर्भ में कभी नहीं होता है।
Alfe

46

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


11
वास्तव में अच्छी बात है, लेकिन मुझे लगता है कि किसी को भी अब एक दिन का उपयोग करते हैं (पढ़ें: का उपयोग करना चाहिए) संस्करण नियंत्रण ...
सरदारथिन

6
आप चौंक जाएंगे। मैंने कई कंपनियों में एक ठेकेदार के रूप में काम किया है, जहाँ केवल कोड की अंतिम कटौती की गई थी। ईमानदारी से।
5arx

4
5arx के बिंदु पर: यदि कंपनी संस्कृति केवल सही कोड प्रस्तुत करने के लिए है, तो कोई व्यक्ति अपना निजी Git या Mercurial रिपॉजिटरी रख सकता है। यह विशेष रूप से आसान है अगर कंपनी का "वास्तविक" संस्करण नियंत्रण SVN है।
डस्टिन रस्नर

2
5arx की टिप्पणी के लिए +1 और +1। मैंने वास्तव में बड़ी कंपनियों में एकीकरण का काम किया है जहाँ संस्करण नियंत्रण प्रणाली में तारीख, अपना नाम और फ़ाइल में एक टिप्पणी लिखना शामिल है। गिट के साथ काम करने के बाद इस्तेमाल किया जा रहा है, यह भयावह अक्षम और बग-प्रवण लगता है।
सिंह

1
@Sardathrion तुम्हें पता है क्या होता है जब आप "गधा आप मुझे" ...
WernerCD

32

मेरी राय में, किसी और के कोड को सीखने का सबसे तेज़ तरीका, (विशेषकर जब परिवर्तन अप्रत्याशित व्यवहार को ट्रिगर करता है जैसा कि आप वर्णन करते हैं) कोड का उपयोग करके डिबगर का उपयोग करना है

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

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

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

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

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


3
मुझे लगता है कि यह एकमात्र यथार्थवादी उत्तर है, एक विशाल ऐप के लिए यूनिट परीक्षण उनके गैर व्यावहारिक के बिना
कॉमनसेंसकोड

काश मैं एक से अधिक बार उत्थान कर पाता।
user949300

30

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

जितना संभव हो मौजूदा स्टाइल को अपनाने की कोशिश करें - अन्यथा आपके बाद के आदमी के पास दो बार करने के लिए बहुत कुछ होगा।

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


21

दूसरे आदमी के कोड बदबू को मानने की जल्दी मत करो।

लेकिन हमेशा संदिग्ध रहें।

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

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


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

1
मैं कहूंगा कि मैं गलत तरीके से कई बार साल में कई बार गलत जानकारी देता हूं। बस आज यह किया और मुझे लगा कि 5 वस्तुओं में से हर एक को मैंने एक समस्या के लिए समस्याग्रस्त किया था। वह / वे उन्हें और अधिक स्पष्ट रूप से चिह्नित कर सकते थे, लेकिन मैं यह मानते हुए कम समय बर्बाद कर सकता था / वे अच्छे कारण के लिए वहां नहीं गए थे।
एरिक रिपेन

14

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

हालाँकि, पहली चीज़ जो आप सीखेंगे वह यह है कि हम एक आदर्श दुनिया में नहीं रहते हैं!

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

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

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

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

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

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


13

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

जो मैं कहने की कोशिश कर रहा हूं, वह यह है कि यह सामान्य है कि आप इसे पहली बार पढ़ने पर कोड को नहीं समझते हैं (जैसे यह सामान्य है कि आप पहली बार सही कोड नहीं लिखते हैं)। यदि आप स्वीकार करते हैं कि विदेशी कोड प्राप्त करने में समय लगता है, तो आपको अतिरिक्त प्रयास में कोई दिक्कत नहीं होगी। एक छोटा सारांश:

  • इकाई परीक्षण आदर्श होंगे, लेकिन हमेशा यथार्थवादी नहीं; खासकर यदि आप भारी नौकरशाही के साथ एक बड़े संगठन में काम करते हैं।

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

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

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

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


11

अनजाने में सामान तोड़ने के साथ आपकी समस्याओं को देखते हुए, मैं यह मानने जा रहा हूं कि कोड स्वचालित परीक्षणों द्वारा कवर नहीं किया गया है। चरण # 0 तुरंत ऑर्डर करना होगा और माइकल फेदर द्वारा लिगेसी कोड के साथ कार्य करना प्रभावी ढंग से पढ़ा जाएगा । यह बस अमूल्य है।

मेरे द्वारा सुझाए गए मूल चरण:

  • वर्तमान कार्यक्षमता को कवर करने वाले परीक्षणों के साथ कोड को कवर करें।
  • समझने योग्य तक रिफ्लेक्टर।
  • नई या संशोधित कार्यक्षमता के लिए एक परीक्षण लिखें।
  • नई कार्यक्षमता को लागू करें।
  • संतुष्टि तक रिफ्लेक्टर।

मैं जानबूझकर परीक्षणों (इकाई, एकीकरण, ...) के स्वाद को निर्दिष्ट करता हूं - बस किसी प्रकार का स्वचालित परीक्षण कवरेज प्राप्त करें।

(और, हाँ, लेआउट और नामकरण के संदर्भ में कोडिंग शैली का पालन करें)


10

जैसा कि पहले उल्लेख किया गया है: वास्तविक दुनिया में आपका स्वागत है। मैं केवल पहले के उत्तर से सहमत हो सकता हूं। मैं केवल समय के अनुमान के बारे में अपने कार्य अनुभव के साथ उत्तर का विस्तार करना चाहता हूं।

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

यदि आप भाग्यशाली हैं, तो हाथ में काम का विश्लेषण करना होगा और प्रलेखन को समझने से आपको बहुत मदद मिलेगी (लेकिन यह अक्सर ऐसा नहीं होता है)।

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

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

लेकिन अपने बॉस को बताने में संकोच न करें, यदि आप कुछ ऐसा देखते हैं जो आपको लगता है कि अलग होना चाहिए (यह सिर्फ आपको दिखाता है कि आप सोच सकते हैं)।

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


5

इसे ऐसे समझें जैसे किसी व्यक्ति पर ऑपरेशन करना।

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

आश्चर्यजनक रूप से आपका रोगी लगभग तुरंत मर जाता है।

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

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

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


3

एक बात जो मैंने सच में यहाँ नहीं देखी थी - एक द्वीप पर काम नहीं करती।

जब तक आप अपने संगठन में एकमात्र प्रोग्रामर नहीं होते हैं, तब तक कोईकोई ऐसा व्यक्ति होता है जिसके पास आपसे अधिक अनुभव होता है, और संभवतः बहुत से लोग हैं जिन पर आप झुक सकते हैं।

सवाल पूछो। बहुत से।

किसी और (कारण के भीतर) को "परेशान" करने की चिंता न करें - मैं बाद में किसी को एक सामान्य विकास चक्र के दौरान एक प्रश्न या दो के लिए बाधित करता हूं, बाद में उत्पादन वातावरण में आग लगाने की तुलना में।

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

याद रखें - आप केवल सिस्टम को नहीं सीख रहे हैं क्योंकि किसी भी नए कर्मचारी को करने की आवश्यकता होगी, लेकिन आप यह भी सीख रहे हैं कि प्रोग्रामर कैसे बनें।

और पांच साल के बाद, अगले न्यू गाइ को आपको एक संरक्षक के रूप में उपयोग करने के लिए प्रोत्साहित करें।


2

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

  • यह कोड कैसे काम करता है, यह जानने के लिए मैं अभी पर्याप्त स्मार्ट नहीं हूं

  • इस कोड को लिखने वाले को पता नहीं था कि वह क्या कर रहा है

  • जादू शामिल है: बहुत काला जादू

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


1

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

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

मैं एक परीक्षण प्रणाली और परीक्षण मंच की सलाह देता हूं, जहां आप उत्पादन को तोड़े बिना इस कोड को संशोधित और परीक्षण कर सकते हैं।

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

समय के साथ, एक बार जब आप तर्क को समझ जाते हैं, तो आप फिर से लिख सकते हैं और परीक्षण कर सकते हैं।

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


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

1
@ dj18 सहमत हैं, और पुरानी टिप्पणियों की सफाई कोड लिखने का हिस्सा है। मैं प्रारूप रखने के लिए कह रहा हूं - यदि संभव हो - एकरूपता के लिए, लेकिन टिप्पणी करना कोई बुरी बात नहीं है।
ऑक्टोपसग्राबस

1

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


1

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

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

यदि कोई एक वर्ष में 10,000 लाइनों का कोड लिखता है, और एक आवेदन में दस वर्ष का 'जीवन' होता है, तो किसी और के काम को लेने के लिए जिम्मेदार एक प्रोग्रामर को कोड की 100,000 लाइनों को समझना पड़ सकता है। इसे प्रति पृष्ठ 50 लाइनों से विभाजित करके 2000 पृष्ठ है। यदि प्रोग्राम एक डिज़ाइन पैटर्न में लिखा गया है, तो प्रोग्रामर यह पाएगा कि एक 'ब्लॉक' की समझ कम से कम बाकी के अधिकांश लोगों की सामान्य समझ की ओर ले जाती है। यदि नहीं, तो हर अंतिम लानत रेखा को पढ़ना आवश्यक है।

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


0

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

जब आप SomethingFactoryमौजूदा कोड में एक मुठभेड़ करते हैं, तो यह बहुत भ्रमित हो सकता है , जो वास्तव में कारखाने के पैटर्न का पालन नहीं करता है । लेकिन जितना आपकी टीम और ढांचा अनुमति देता है, ऐसे मामलों को न्यूनतम रखना फायदेमंद हो सकता है।

निम्नलिखित डिजाइन पैटर्न (जहां व्यवसाय की आवश्यकताएं इसे अनुमति देती हैं) भी कोड दोहराव को काफी कम कर सकती हैं जो भविष्य के संशोधनों पर बग को कम करता है।

डिजाइन पैटर्न पर कुछ अच्छे स्रोत हैं

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

और निश्चित रूप से पुस्तक

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612


0

व्यापार तर्क के मानसिक मानचित्र को विकसित करने में विधियों के बीच नियंत्रण के प्रवाह को ट्रेस करना बहुत महत्वपूर्ण है।

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

वर्कफ़्लो डेटा मॉडल बनाना सभी कोड रास्तों का विश्लेषण करने का सबसे अच्छा तरीका है:

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

और कार्यप्रवाह कल्पना आदर्श है:

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

संदर्भ


-1

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

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