मैं प्रोग्राम नहीं कर सकता क्योंकि मैं जिस कोड का उपयोग कर रहा हूं वह पुरानी कोडिंग शैलियों का उपयोग करता है। क्या यह प्रोग्रामर के लिए सामान्य है?


29

मेरे पास प्रोग्रामर के रूप में मेरी पहली वास्तविक नौकरी है, लेकिन मैं किसी भी समस्या को हल नहीं कर सकता क्योंकि कोडिंग शैली का उपयोग किया जाता है। यहाँ कोड:

  • टिप्पणी नहीं है
  • कार्यों (50, 100, 200, 300 या अधिक अनुक्रम में निष्पादित) नहीं है
  • ifबहुत सारे रास्तों के साथ कई बयानों का उपयोग करता है
  • चर है कि कोई मतलब नहीं है (जैसे .: cf_cfop, CF_Natop, lnom, r_procod)
  • एक पुरानी भाषा (2002 से Visual FoxPro 8) का उपयोग करता है, लेकिन 2007 से नई रिलीज़ हैं।

मुझे ऐसा लगता है कि मैं 1970 में वापस चला गया हूं। क्या यह ओओपी, क्लीन-कोड, डिज़ाइन पैटर्न आदि से परिचित एक प्रोग्रामर के लिए सामान्य है, जो इस पुराने-तरीके से कोडिंग से परेशान है?

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

पुराने कोड में हर बदलाव को कोड (यहां तक ​​कि संस्करण नियंत्रण के रूप में भी तोड़फोड़ के साथ) में रखा जाना चाहिए, प्लस मेटा जानकारी (तिथि, प्रोग्रामर, कार्य) उस परिवर्तन से संबंधित है (यह एक गड़बड़ हो गया, 3 इस्तेमाल की गई लाइनों और 50 के साथ कोड है पुरानी लाइनों पर टिप्पणी की गई)। मैं सोच रहा हूं कि न केवल एक कोड समस्या है, बल्कि सॉफ्टवेयर विकास समस्या का प्रबंधन है।


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

12
आप टिप्पणियों का उपयोग नहीं करके बहुत याद नहीं कर रहे हैं। अगर कुछ भी लोग उन्हें अधिक उपयोग करते हैं।

22
@JohnFx आपसे असहमत नहीं है, लेकिन कम से कम टिप्पणी रहित बकवास का सामना करना पड़ रहा है, मैं कहूंगा कि मैं बिना किसी टिप्पणी के अनावश्यक / अप्रचलित टिप्पणियों को पसंद करता हूं।
यानिस

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

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

जवाबों:


0

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

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

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

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


1
आप इसे काम करने की बुरी जगह कैसे कह सकते हैं? विरासत इनलाइन कोड में कुछ भी गलत नहीं है। विरासत कोड इस दुनिया में एक जगह है जहां विरासत कोड के बिना हमारे द्वारा उपयोग किए जाने वाले अनुप्रयोगों में नए कारनामे होंगे।
रामहुंड

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

1
@ रामहंस लिगेसी कोड ठीक है। आज विरासत कोड लिखना ठीक नहीं है।
रेनाटो दिनानी

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

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

35

यह कोडिंग शैली (यदि आप इसे किसी भी प्रकार की शैली कहना चाहते हैं) खराब कोडिंग शैली है।

सबसे आधुनिक भाषाओं में वर्णनात्मक चर नाम और साने प्रवाह नियंत्रण के साथ एक छोटा कार्य लिख सकता है (दृश्य फॉक्सप्रो आधुनिक है, हाँ)।

आपके पास जो समस्याएं हैं, वे खराब कोड आधार के साथ हैं, अधिक कुछ नहीं, कुछ भी कम नहीं।

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

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

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


33
अच्छे प्रोग्रामर किसी भी तरह की डरावनी कहानी को संभाल सकते हैं। यह मज़ेदार नहीं होगा, लेकिन इसीलिए वे इसे करने के लिए आपको पैसे देते हैं। काम को मज़ेदार और खेल नहीं माना जाता है।
tp1

9
@ tp1 - हां, लेकिन आपको यह स्वीकार करना होगा कि इस तरह के पहले कोडबेस से आपका सामना सिस्टम के लिए काफी झटका हो सकता है।
Oded

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

13
@ RenatoDinhaniConceição, मैं कभी भी एक डेवलपर को मूल डिजाइन करने के लिए काम पर रखने पर विचार नहीं करूँगा, जिसने रखरखाव में अपना या उसके समय का काम नहीं किया है, आप इस अनुभव के बिना एक अच्छे डिजाइनर नहीं हो सकते हैं (ऐसा करने में असफल होना खराब डिजाइनों के शीर्ष कारणों में से एक है। मेरा अनुभव)। आप एक अच्छे प्रोग्रामर नहीं हो सकते हैं और रखरखाव में खराब हो सकते हैं। आप इसे पसंद नहीं कर सकते हैं, लेकिन यह समझना आवश्यक है कि अच्छी तरह से कैसे डिजाइन किया जाए। और कठिन परिश्रम करने की क्षमता भी एक अच्छे प्रोग्रामर की विशेषता है। अगर यह आसान होता तो उन्हें हमारी जरूरत नहीं होती।
HLGEM

8
@ tp1 कार्य मजेदार और गेम माना जाता है, अन्यथा आप इसे गलत कर रहे हैं।
केविन मैककॉर्मिक

18

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

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

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

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


4
"अच्छे डिजाइन अभ्यास हमेशा लोकप्रिय नहीं थे" यह जरूरी नहीं कि लोकप्रियता के बारे में है। क्या अच्छा डिजाइन या सबसे अच्छा अभ्यास माना जाता है समय के साथ विकसित होता है। पुराने कोड को देखते समय यह ध्यान में रखना है।
बुरहान अली

@BurhanAli, abosiolutely, 2000 में एक अच्छा अभ्यास क्या था जब हमारे आवेदन को orginally डिज़ाइन किया गया था जरूरी नहीं कि यह अब एक अच्छा अभ्यास है। युवा डेवलपर्स को अक्सर इस बात का अंदाजा नहीं होता है कि कोड के लिखे जाने के समय वे सर्वोत्तम प्रथाओं के रूप में जो सिखाए गए थे, उनका अस्तित्व ही नहीं था या हो सकता है कि सॉफ्टवेयर उपयोग करने वाली पुरानी भाषा के साथ काम न करे।
HLGEM

2
मुझे नहीं लगता कि 500-पंक्ति वाले कार्यों को कभी भी "अच्छा" माना जाता था ... 80 के दशक में मैंने जिस प्राथमिक पुस्तक से विधानसभा सीखी थी, उसमें उल्लेख किया था कि आपको सबरूटीन्स में चीजों को तोड़ना चाहिए, जब वे अंत से शाखा के लिए बहुत बड़े होने लगे थे। शुरू करने के लिए। यह उस प्रोसेसर (6502) पर 40-120 लाइनों के बीच कहीं आता है।
mjfgates

11
  • टिप्पणी नहीं है - इसे ठीक करें जैसा कि आप इसे सीखते हैं
  • कार्य नहीं हैं (50, 100, 200, 300 या अधिक अनुक्रम में निष्पादित लाइनें)

यह शायद कोड के पिछले पुनरावृत्ति से मिलता है। इस बिंदु पर, मैं इसी तरह के प्रतीत होने वाले कोड ब्लॉक के बीच सूक्ष्म अंतर से सावधान रहूंगा जो "सुविधाएँ" बन गए हैं। लेकिन इस प्रकार की संरचना का विचार कितना बुरा है, यह समझना बहुत सरल है ... इसलिए मुझे यकीन नहीं है कि आप इसके साथ कहां परेशान होंगे।

  • बहुत सारे रास्तों वाले बयानों का उपयोग करता है - मैं वास्तव में निश्चित नहीं हूं कि आपका यहां क्या मतलब है
  • ऐसे चर हैं जिनका कोई अर्थ नहीं है (उदाहरण: cf_cfop, CF_Natop, lnom, r_profod) -

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

  • एक ऐसी भाषा का उपयोग करता है जिससे मैं अपरिचित हूं (2002 से विजुअल फॉक्सप्रो 8) - यह आपका मुद्दा है, कोड का नहीं

7
+1: यह आपका मुद्दा है, न कि कोड का :)
aleroot

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

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

3
@ RenatoDinhaniConceição, डेटाबेस प्रोडक्ट को अपग्रेड नहीं करना आम बात है, क्योंकि जो चीजें वर्तमान में काम करती हैं, उन्हें अपग्रेड करना और पुराने संस्करण को बनाए रखने के लिए आपको कोई बदलाव करने के लिए कोई पैसा या समय नहीं है। यह एक व्यवसायिक विकल्प है।
HLGEM

1
@renato, अधिकांश डेटाबेस अनुप्रयोग आसानी से पिछड़े संगत नहीं हैं।
HLGEM

11

यह मुझे एक अवसर की तरह लगता है ।

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

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

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

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


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

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

1
@deadalnix पहली नौकरी शायद ही कभी आपके साथ काम करने वाले लोगों को चुनने का अवसर प्रदान करती है। अक्सर आप यह नहीं जानते होंगे कि जब तक आपने उनके साथ काम नहीं किया, तब तक लोग कोड की गुणवत्ता का कितना ध्यान रखते हैं। मेरा जवाब ओपी को यह समझने में मदद करता है। रिफैक्टरिंग करने से पहले यूनिट परीक्षण में असमर्थता के बारे में आपका बयान गलत है। यूनिट परीक्षणों से पहले रिफ्लेक्टर की कोशिश करने से समग्र जोखिम बढ़ जाता है। परीक्षण के बिना कीड़े का पीछा करना अक्षम और थकाऊ है। जो लोग कोड गुणवत्ता के बारे में परवाह करते हैं वे परीक्षणों और स्वच्छ कोडिंग तकनीक पर बहुत अधिक ध्यान केंद्रित करते हैं। मुझे आपकी निहित आपत्ति नहीं है, इस ऑफ़लाइन के बारे में बात करने की खुशी है :-)
S.Robins

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

1
इसके लिए सामग्री एकत्र करने का भी अवसर है thedailywtf.com के
अरकह

8

जंगल में आपका स्वागत है !

दुर्भाग्य से, अक्सर एक कंपनी में काम करना शुरू करना मतलब इस तरह की स्थितियों का सामना करना शुरू करना है, जब तक कि आप एक संरचित और अच्छी तरह से संगठित कंपनी के लिए काम नहीं करते हैं, यह स्थिति काफी सामान्य है ...

मेरी सलाह है:

  1. सीखना शुरू करें और इससे परिचित हों: प्रोग्रामिंग भाषा का प्रयोग किया जाता है (क्लिपर / डीबेस) और पर्यावरण (विजुअल फॉक्सप्रो)

  2. कोड आधार को पढ़ें और उसका विश्लेषण करें और टिप्पणी करना शुरू करें

  3. कोड को व्यवस्थित करना / रिफैक्ट करना (अनुक्रम में निष्पादित कई लाइनों की समस्या को संबोधित करना)

एक समान कोडबेस के सामने समस्या होने के कारण यह सामान्य है, लेकिन कोड गुणवत्ता में सुधार करने और कोडबेस में सुधार करने वाले कार्यक्रम को "आपका स्पर्श" देने और शायद इसे एक बेहतर कार्यक्रम बनाने की एक बड़ी चुनौती बन सकती है ...


7

आपके प्रश्न का उत्तर देने के लिए: हाँ, लोग / कंपनियां हर जगह बुनियादी ढांचे का उपयोग करती हैं जो गंदे कोड पर बनाया जा सकता है। जब खुद को ऐसी स्थितियों में एकीकृत करना है, तो इससे निपटना बहुत कठिन हो सकता है।

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

हालांकि आप इसके बारे में क्या कर सकते हैं, हालांकि:

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

जैसा कि हर जगह होता है, जब तक कोड की बाहरी विशेषताएं ठीक से काम करती हैं, यह कोई फर्क नहीं पड़ता कि इंटर्न कैसे काम करते हैं।


"मदद के लिए पूछें" के लिए +1। एक टीम में काम करने से लागत बढ़ जाती है लेकिन लाभ भी होता है।

7

मैं कुछ टिप्पणियां करने जा रहा हूं जो यहां के कई उत्तरदाताओं से अलग हैं। मेरी कई टिप्पणियाँ आपके लिए स्पष्ट हो सकती हैं, लेकिन फिर भी कहने की ज़रूरत है।

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

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

उम्मीद है की यह मदद करेगा।


1
इसके अलावा: टेस्ट, बैकअप बनाएं, संस्करण नियंत्रण का उपयोग करें। यदि आप नए हैं, तो स्रोत में ऐसी चीजें चल रही हैं, जो आपको समझ में नहीं आएंगी, और एक सहज बदलाव की तरह दिखने वाले मुद्दे आपको परेशान नहीं कर सकते हैं।
स्कॉट सी विलसन

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

5

एक चीज जो चिपक जाती है वह है आपकी संपादित टिप्पणी

पुराने कोड में हर बदलाव को उस बदलाव से संबंधित कोड, मेटा जानकारी (दिनांक, प्रोग्रामर, कार्य) में टिप्पणी करनी चाहिए (यह एक गड़बड़ हो गई, 3 उपयोग की गई पंक्तियों के साथ कोड हैं और 50 पुरानी लाइनों पर टिप्पणी की गई है)। मैं सोच रहा हूं कि न केवल एक कोड समस्या है, बल्कि सॉफ्टवेयर विकास समस्या का प्रबंधन है।

मेरे पास एक परियोजना भी है जहां मुझे विरासत में फॉक्सप्रो कोड आधार विरासत में मिला है, जिसमें से कई मुद्दों का आप वर्णन करते हैं। परियोजना में पेश की गई पहली चीजों में से एक मैं एक अच्छा स्रोत कोड भंडार था। FoxPro SourceSafe के साथ एकीकृत हो सकता है, लेकिन यह उत्पाद उपयोग करने के लिए दर्दनाक है।

मैंने पॉल मैकनेट के scx टूल http://paulmcnett.com/scX.php की एक प्रति पकड़ी और अपने विकास चक्र में एकीकृत किया। यह बाइनरी फॉक्सप्रो कोड को एक टेक्स्ट फॉर्मेट में निकालने का एक बहुत अच्छा काम करता है जिसे फिर एक स्रोत रिपॉजिटरी में डाला जा सकता है, जैसे कि सबवर्सन, मर्क्यूरियल या यहां तक ​​कि गिट भी। (आप सबफ़ॉक्स प्रोजेक्ट को http://vfpx.codeplex.com पर देख सकते हैं उपयोगी ।

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


4

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

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

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

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

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

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

मेरे 20 वर्षों में, मुझे लगता है कि कई ऐस प्रोग्रामर को निकाल दिया गया है, मुख्यतः क्योंकि वे चीजों को अपने "सही" तरीके से करने की मांग करते हैं। जब तक आप कुछ बहुत, बहुत, बहुत ही अनोखे काम में नहीं लाते, आप बदली हैं। हो सकता है कि आप अपनी कक्षा में अव्वल रहे हों, लेकिन अगले साल, कोई और उनकी कक्षा में शीर्ष पर होगा, और नौकरी की तलाश करेगा।

मैं इसे आपकी प्राथमिक नौकरी के रूप में देखता हूं, जब तक आप नौकरी बदलने का फैसला नहीं करते, तब तक आपको अपनी नौकरी रखनी है। अपनी नौकरी रखने का मतलब है कि आपको खेल के मैदान में किसी और के लिए अच्छा खेलना होगा और उसके लिए भुगतान करना होगा।

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

पुरानी प्रणाली बदल सकती है, लेकिन इसमें समय लगता है। कुछ बदलने से जोखिम होता है, और व्यवसाय से घृणा का खतरा होता है, और आपको कंपनी को बदलाव के साथ सहज बनाने के लिए समय और काम करना होगा।

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