क्या यह सामान्य है कि मैं अपने सिर में तीन से अधिक कीड़े नहीं रख सकता जो मुझे सौंपा गया है, न ही मैं स्पेगेटी कोड की एक हजार पंक्तियों को समझ सकता हूं?


19

मैं एक पुराने कोडबेस पर काम कर रहा हूं, जो ... सही नहीं है , ऐसे माहौल में जो या तो नहीं है। यह मेरे जीवन में सबसे बुरा कोडबेस नहीं है, लेकिन अभी भी बहुत सारे मुद्दे हैं: शून्य इकाई परीक्षण; कोड के हजार + लाइनों के साथ तरीके; मूल वस्तु उन्मुख सिद्धांतों की गलतफहमी; आदि।

यह कोड को बनाए रखने के लिए दर्द होता है।

  1. हर बार मुझे बुरी तरह से लिखी गई विधि की एक हज़ार लाइनों को चर के साथ फिर से उपयोग करना होगा, मैं पूरी तरह से खो गया हूं।
  2. कुछ संशोधन या रीफैक्टरिंग जो मैंने किए हैं, उन्होंने एप्लिकेशन के अन्य स्थानों में बग पेश किए हैं।
  3. किसी भी दस्तावेज, परीक्षण या एक अवलोकन योग्य वास्तुकला को कम करना और बुरी तरह से नामित विधियों के साथ संयुक्त, मुझे लगता है कि मैं अपनी सभी उपलब्ध स्मृति को भर देता हूं। मेरे द्वारा कोड को संशोधित करने के लिए अन्य सभी चीजों के लिए कोई जगह नहीं बची है जिसे मुझे याद रखना है।
  4. कार्यस्थल पर लगातार व्यवधान मुझे परेशान करते हैं और मुझे धीमा कर देते हैं।
  5. मैं बग ट्रैकिंग सिस्टम के बिना एक समय में दो या तीन से अधिक कार्यों को याद नहीं कर सकता, और मैं सप्ताहांत में उन सभी को भूल जाता हूं।

मेरे सहयोगियों को इस तरह के मुद्दे नहीं लगते हैं।

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

ऐसा क्यों होता है? लंबे समय तक बुरी तरह से लिखे गए कोड के साथ काम करने पर क्या यह एक विशेष कौशल डेवलपर्स का अधिग्रहण है? क्या खराब कोड के साथ मेरे अनुभव की कमी इन समस्याओं / भावनाओं में योगदान करती है? क्या मेरी स्मृति में कोई समस्या है?


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

1
यही कारण है कि इनकैप्सुलेशन मौजूद है।
रॉबर्ट हार्वे

जवाबों:


26

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

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

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

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

यूनिट टेस्ट के सेफ्टी नेट के बिना रिफैक्टरिंग करने से पैर में खुद की शूटिंग होती है। मत करो। बस नहीं है।

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


+1 के लिए "हां, संरचित लोगों के लिए असंरचित कोड / वातावरण से प्रभावित होना सामान्य है।"
एमडी महबूबुर रहमान

2

वहाँ 3 मुख्य बिंदु है कि मैं देख रहा हूँ:

अंक 1, 2 और 3 इस तथ्य से उपजे हैं कि आपके सहकर्मी कोडबेस के साथ अधिक अनुभवी हैं, जिसका अर्थ है कि वे इसकी विचित्रता जानते हैं। इसका अर्थ है कि वे डिबग प्रक्रिया के लिए अपनी दीर्घकालिक स्मृति का उपयोग करते हैं और याद रख सकते हैं कि doXYZ वास्तव में UVW करता है लेकिन ऐतिहासिक कारणों से इसका नाम नहीं बदला गया। हालाँकि उन्हें कभी भी इस पर कोडिंग करने से कुछ महीने लगने चाहिए, फिर वे आपके दर्द को महसूस करने लगेंगे।

बिंदु 4 के लिए रुकावटों का विरोध करें, गैर-जरूरी व्यवसाय को क्षेत्र से बाहर न जाने दें , एक व्यवधान के बाद इसे वापस आने में लंबा समय लगता है; कंपनी के IM को व्यस्त में सेट करें, बस कोडिंग के लंबे ब्लॉक (पूर्ण दोपहर) में शेड्यूल करने का प्रयास करें

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


आपके सुझावों के लिए धन्यवाद। नोट: बिंदु 5 के लिए, हमारे पास पहले से ही TFS है, एक उत्पाद जिसमें बग ट्रैकिंग सिस्टम शामिल है। मैं इसे आज का उपयोग कर रहा हूँ। मुझे कंपनी के प्रत्येक डेवलपर के बारे में नहीं पता है, लेकिन मुझे यकीन है कि कुछ लोगों के पास कोई बग सूची नहीं है, यहां तक ​​कि एक्सेल या एक साधारण पाठ दस्तावेज़ में भी नहीं।
आर्सेनी मूरज़ेंको

2

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

  1. हजार लाइन विधि - हर कोई उस पर खो जाने वाला है जब तक कि वे सिर्फ उस पर काम नहीं करते। वे इसे लेने या इसे वापस पाने में तेज हो सकते हैं। आप अनुभव के अलावा, और शायद तब भी नहीं बदल सकते हैं।

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

  3. आपको जो काम करना है वह बनाएं। यदि इसका मतलब है कि फ्लो चार्ट या कुछ अन्य दस्तावेज बनाना, तो ऐसा करें। उन्हें आपकी ज़रूरत है या नहीं, और आपके द्वारा बनाए जाने के बाद वे इसका उपयोग करते हैं या नहीं, यह अप्रासंगिक है।

  4. व्यवधान सभी को धीमा कर देता है। उस पर ध्यान केंद्रित करने से आप और अधिक धीमा हो जाएगा। इसे स्वीकार करें और जितनी जल्दी हो सके नाली में वापस जाने की कोशिश करें।

  5. दो या तीन बगों को ध्यान में रखते हुए बुरा नहीं है, तीन या चार बेहतर होंगे, लेकिन इसे सुधारने की कोशिश करने के बजाय, हार मान लें और लिख दें। कागज का टुकड़ा, व्हाइटबोर्ड, tfs, एक्सेल, शब्द या नोटपैड - बस इसे लिखें। मैं शर्त लगाता हूं कि आपके सहयोगी क्या कर रहे हैं। बेतरतीब ढंग से चीजों को या तो ठीक करना।

प्रोग्रामिंग एक आदर्श स्मृति के बारे में नहीं है, और यह ध्यान भटकाने में सक्षम होने के बारे में नहीं है - इस पर ध्यान केंद्रित करना केवल आपके द्वारा बनाए जा रहे विकर्षण हैं।


1

CAVEAT / UPDATE: नीचे दिए गए उत्तर को पढ़ने के बाद, मुझे लगा कि यह थोड़ा कठोर लग सकता है। मेरा इरादा नहीं है, आपके द्वारा वर्णित वातावरण भयानक है और यह अधिकांश लोगों को प्रभावित करेगा (शायद यहां तक ​​कि बेहतर प्रोग्रामर इसे पीड़ित हैं, लेकिन वे उसी वातावरण में दूसरों के साथ तुलना करके "बेहतर" हैं)। मेरा उत्तर आपके प्रश्नों में केवल एक बिंदु-दर-बिंदु प्रतिबिंब है, यह मानते हुए कि पर्यावरण नहीं बदलेगा (भले ही यह होना चाहिए)।

पूरी तरह से स्वीकार्य जवाब:

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

2) यह संख्या 1 से समान है, लेकिन एक अलग मीट्रिक का उपयोग कर रहा है। एक ही जवाब।

3) नोटबंदी और कलम। या एक शब्द / एक्सेल दस्तावेज़। जिसे हल करना मुश्किल नहीं है।

4) जो एकाग्रता का एक व्यक्तिगत मुद्दा है। सुनिश्चित नहीं है कि यह अपने आप से इसे सुधारने के लिए व्यवहार्य है, हालांकि।

5) एक टिकट प्रणाली का उपयोग करना या नहीं प्रोग्रामर द्वारा लेकिन परियोजना प्रबंधक द्वारा तय नहीं किया जाना चाहिए। उसकी राय पूछें / अपने अंक प्रस्तुत करें। अगर वह इसके खिलाफ है तो नोटबंदी और फिर से कलम।


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

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

0

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

इसलिए पहला कदम यह है कि जब आप अपने डेस्क पर हों तो उस सामान से अपने दिमाग को साफ करें।

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

अंत में अगर आप हल किए गए मुद्दों को लिखना चाहते हैं और / या अभी काम कर रहे हैं, तो शर्मिंदा महसूस न करें (यह एक परिष्कृत बग ट्रैकिंग सिस्टम होना जरूरी नहीं है) यह कुछ होने से बेहतर है क्योंकि आप इसे पढ़ते हैं आपके नोट्स इसे 100% निश्चित नहीं होने के साथ-साथ आपके सिर के ऊपर से बताते हैं

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