मुझे खराब कोड लिखने के लिए मजबूर किया जाता है। मैं अपना चेहरा कैसे बचाऊं? [बन्द है]


69

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

उत्पाद पहले खुला स्रोत था और मुझे चिंता है कि यह भविष्य में खुला स्रोत हो सकता है। अगर किसी को (विशेष रूप से संभावित नियोक्ताओं) को कुछ परिवर्तनों के बाद मेरा नाम मिल सकता है तो मुझे शर्म आएगी। मैं अपने अच्छे नाम की रक्षा के लिए क्या कर सकता हूं?

मुझे यकीन नहीं है कि यह प्रासंगिक है, लेकिन मैं यह जोड़ूंगा कि न तो मेरे बॉस और न ही मेरे सहयोगी स्वीकार करना चाहते हैं कि कोड खराब है, लेकिन मुझे यकीन नहीं है कि मैं उन्हें इसके लिए दोषी ठहरा सकता हूं - उनमें से कई के लिए यह उनका है पहली नौकरी।


21
आपको खराब कोड लिखने के लिए कैसे मजबूर किया जाता है? आप क्यों नहीं खड़े हो सकते, अपना नाम खराब कोड में डालना बंद करें, और समस्या, समाधान, समय, प्रयास और धन के संदर्भ में लागत, और अपने वरिष्ठों को अब समस्याओं को ठीक करने के लाभों के बारे में बताएं?
थॉमस ओवेन्स

17
"त्वरित और गंदे हैक को प्रोत्साहित करना"? उत्साहजनक? जो भी बदतर है। आपका अभिमान (और नई नौकरी ढूंढना) या इस नौकरी से चिपके रहना। जो सही है उसके लिए खड़ा होना बुरा नहीं हो सकता। आपको क्या रोक रहा है? हिंसा की धमकी? ब्लैकमेल? आपराधिक कार्यवाही? गंभीरता से। आपको अच्छा कोड लिखने से क्या रोकता है? कृपया विशिष्ट रहें । और ईमानदार।
एस.लॉट

113
यदि यह कोई सांत्वना है, तो आज भी जो अच्छा कोड आप लिखते हैं, वह आपको पांच साल में बुरा लगेगा।
क्युरेलसा

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

7
क्षमा करें, लेकिन वहाँ रहे हैं सही और गलत तरीके कोड लिखने के लिए। सही तरीका मानक उद्योग प्रथाओं का उपयोग करता है; बुरा तरीका एक साथ काटता है और कहता है कि यह "काम करता है"।
वेन मोलिना

जवाबों:


132

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

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


2
+1। आपको इसे ठीक करने के लिए हर चीज का त्याग करने की जरूरत नहीं है।
tdammers

4
+1: सभी या कुछ नहीं के लिए - बहुत सही।
Umber Ferrule

3
गलत हाथों में बॉय स्काउट नियम वास्तव में समस्या का कारण बन सकता है, क्योंकि उसके सुपरियर के 'समझदार फ़ंक्शन नाम' की परिभाषा 'bolChkLst' हो सकती है (स्टाइलगाइड को पूरा करने के लिए आयु संकेतन, चेकलिस्ट के बजाय ChkLL के कारण) ')। यहाँ कुछ बॉय स्काउट नियम लागू किए गए हैं, जिनका मैंने विभिन्न नौकरियों में पालन ​​करने की कोशिश की , जिनका पालन ​​करने की मैंने कोशिश की : 'फ़ंक्शंस शामिल हों, जितना संभव हो उतना कम हो', '3 कॉल के माध्यम से तर्क न करें, इसके बजाय ग्लोबल्स का उपयोग करें', 'इनलाइन व्यूज़ में इनलाइन एसक्यूएल का उपयोग करें इसे जल्दी करो '
केप्पला

40
+1 के लिएEvery time you touch the code, leave it better than it was before.
क्वार्की

3
+1। यदि आपके पास बहुत सारे स्पष्ट सुधार हैं, तो कोई भी जो वास्तव में आपके योगदान को देखता है, आपको नहीं लगेगा कि आप एक भद्दा प्रोग्रामर हैं। संभावित नियोक्ता जो मानते हैं कि आप भद्दे हैं क्योंकि परियोजना भद्दा नहीं है वे लोग हैं जिनके लिए आप काम करना चाहते हैं।
मैथ्यू

59

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

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

तो ... बुरा कोड लिखें, ... इसके बहुत सारे ... कोड जो मुश्किल से काम करता है, और फिर ITERATE। हर पुनरावृत्ति एक छोटे से बेहतर है!

किसी ने भी पहली बार सही समाधान नहीं लिखा।

* यह, क्या यह कम होता है एक टिप्पणी होती।


1
+1 मैं इस उत्तर से दृढ़ता से सहमत हूं। मैंने आपको दो बार उकसाया।
वीटर पाय

3
मैं सहमत हूँ। यह "विश्लेषण पक्षाघात" के माध्यम से काटने का एक शानदार तरीका है, जो किसी समस्या के "सही" समाधान तक पहुंचने का प्रयास करते हुए पकड़ सकता है। मैंने StackOverflow पर कुछ ऐसा ही लिखा ।
:

4
+1। मैंने इसे पहले से ही प्रोग्रामर पर पढ़ा है (लेकिन स्रोत नहीं जानता): दो समूहों को एक निश्चित समय सीमा के भीतर मिट्टी के बर्तन बनाने का काम सौंपा गया था। एक सर्वोत्तम संभव गुणवत्ता का आइटम बनाने के लिए और एक संभव के रूप में कई आइटम बनाने के लिए। अंत में, बाद के समूह ने बेहतर गुणवत्ता के आइटम प्रदान किए, क्योंकि पुनरावृत्ति महारत हासिल करने का मार्ग है। अकेले होने से आपको कहीं नहीं मिलेगा। अंत में, हम सब करके सीखते हैं और कुछ गलत करने का हमारा डर जो हमें वापस कोशिश में रखता है, संभवतः असफल होता है, लेकिन निश्चित रूप से हमारी गलतियों से सीखता है।
Back2dos

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

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

40

कोड टिप्पणियाँ यहाँ आपके मित्र हैं

जब भी आपको ऐसा लगे कि आपको दबाव के कारण कुछ सस्ते हैक लिखने हैं, तो बस कुछ ऐसा बोलें, "यह कोड समय की कमी के कारण एक्स करता है। आदर्श रूप से, मैं इसके बजाय वाई करूंगा। - शर्मिंदा एक, 5 जुलाई 2011"

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


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

ठीक है, आप किसी के बारे में कुछ बता सकते हैं जिसकी टिप्पणी "तय", "किया", "ब्लाहबल्लाह" :) है
gbjbaanb

+1 मैंने कई बार किया है और सहकर्मी डेवलपर्स के मामले में यह सिर्फ काम करता है।
जसक प्रूशिया

7
मैं आमतौर पर इस तरह की टिप्पणियों को हटाता हूं जब भी मैं उनके पार जाता हूं। TODO या FUTURE-ENHANCEMENT के रूप में चिह्नित टिप्पणी रहने के लायक हो सकती है, लेकिन माफी केवल कचरा है।
क्रिस्टोफर जॉनसन जूल

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

10

यह इस बात पर निर्भर करता है कि वे आपको कैसे मजबूर करते हैं।

मेरे अनुभव में, दो संभावनाएँ हैं:

आप एक तंग अनुसूची, विरासत कोड, आदि द्वारा मजबूर महसूस करते हैं।

इस मामले में, जैसा कि अधिकांश अन्य उत्तर पहले से ही कहते हैं, यह आपके लिए 'शीतलता के लिए अनुकूलन' पर निर्भर है। आपके पास एमवीसी को कोडबेस को फिर से लिखने का समय नहीं हो सकता है, लेकिन पहले चरण के रूप में, उदाहरण के लिए, आप अपने एसक्यूएल को हाथ से बंद कर सकते हैं और इसके बजाय एक अच्छा लिख ​​सकते हैं execute_sql($query, $params), जैसे कि अमूर्त जैसे नींव को fetch_customer($filter_params)याद करते हैं , आदि, सभी को याद रखें। प्रैक्टिस अंततः वहां होती है कि आपके बॉस को पहले एक उत्पाद मिलता है, इसलिए भविष्य में अब बनाम में निवेश करने के लिए कितना समय है, इस बारे में केवल एक संघर्ष है।

जब आप सही संदर्भ सेट करते हैं ('6 महीने के भीतर, अतिरिक्त समय न पाकर, मैंने एमवीसी के लिए अखंड संहिता का खंडन किया') तो आपको अपना नाम कोड पर छोड़ देना चाहिए, और एक चिकित्सक की तरह गर्व करने की कोशिश करनी चाहिए, जो एक स्ट्रोक पीड़ित को सिखाता है। " फिर से एकल शब्द बोलें।

आपको स्पष्ट रूप से इसे लागू करने का आदेश दिया गया है जिस तरह से आप अनफिट हैं

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

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

उल्टा यह है कि इस परिदृश्य में, आपका नाम वैसे भी प्रकाशित होने की संभावना नहीं है, क्योंकि टीम लीडर सभी सफलता का श्रेय लेता है।


8

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

लंबी अवधि के लिए, अपने बॉस से बात करें। बताएं कि 15 मिनट यहां निवेश करने से वहां घंटों की बचत की जा सकती है। सुनिश्चित करें कि आपके पास ठोस उदाहरण हैं - न कि "अगर मैंने ऐसा किया है और यहाँ पर, मेरी आशा है कि मैं अगले साल यह काम कर पाऊंगा", बल्कि, "देखो, यहाँ मैंने यह बात की, और क्योंकि उस समस्या को खोजने में मुझे तीन घंटे का समय लगा; अगर मैंने इसे और इस तरह से किया होता, तो बग स्पष्ट रूप से स्पष्ट हो जाता "। यहां एक चेतावनी: जबकि सुरुचिपूर्ण और बनाए रखने योग्य कोड बहुत बेहतर और अधिक कुशल लगता है, कभी-कभी ऐसा नहीं होता है। ऐसी परिस्थितियां हैं जहां एक मैला त्वरित-निर्धारण पूरी तरह से उचित है: कभी-कभी आप एकल-उपयोग कोड लिख रहे हैं, कभी-कभी आप कबाड़ के एक पुराने टुकड़े को जीवित रख रहे हैं, असली चीज़ का इंतजार कर रहे हैं; कभी-कभी, उचित समाधान का लाभ नहीं मिलता है '

यदि अन्य सभी विफल हो जाते हैं, तो दूसरी नौकरी ढूंढें।


3

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

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


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

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

1
आदर्श श्रेष्ठ आंकड़े जो आप वास्तव में काम नहीं करते हैं वे महान हैं, लेकिन जो व्यक्ति आपकी तनख्वाह पर हस्ताक्षर करता है वह वही है जिसे आपको खुश करना है। बिल कलेक्टर्स के पास हर घंटे कॉल करना जब आप काम से बाहर हो, वास्तव में बेकार हो।
बॉब मर्फी

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

1
मैं लगभग एक बड़े सिस्टम के बड़े पैमाने पर पुनर्लेखन की वकालत कभी नहीं करूंगा, लेकिन इसका मतलब यह नहीं है कि भविष्य में आपके द्वारा लिखा गया कोड भयानक होना चाहिए।
पीटरअलेनवेब

3

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

दुनिया में सबसे अच्छा कोड जारी होने से पहले अप्रचलित होने से कोई फर्क नहीं पड़ता।

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

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

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

पर्याप्त समय के बाद अधिकांश कोड में विशिष्ट स्थितियों के लिए हैक शामिल होंगे जो एक सामान्य ढांचे में रिफ्लेक्टर करने के लिए बहुत महंगा थे।


2

मैं यह जोड़ना चाहूंगा कि आपको बस ऐसे ही जारी रखना चाहिए जैसे आप अभी कर रहे हैं, कुछ भी नहीं कह रहे हैं और सिर्फ हैकिंग और हैकिंग कर रहे हैं।

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

मुझे यकीन है कि php कोड विश्लेषण के लिए उपयोग करने के लिए मुफ्त में कई उपकरण उपलब्ध हैं। http://en.wikipedia.org/wiki/Codeanananysis

इसके अलावा, बेशक यह http://en.wikipedia.org/wiki/Code_smell है

इसे पढ़ें, योग करें जो आप अपने आवेदन में पा सकते हैं, और पाठ्यक्रम सूची विकल्प । बिना किसी विकल्प (अधिमानतः) को बेहतर तरीके से प्रस्तुत करने के लिए इसका बुरा अभ्यास सिर्फ खड़े होना और "मैं न यह कैसे किया जाता है" चिल्लाओ।

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

hth


0

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

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

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

आपको मेरा एक उदाहरण देने के लिए, मैं एक बार एक पर्ल / CGI एप्लिकेशन के साथ एक प्रोजेक्ट के बीच में पहुंचा, जहां सभी HTML कोड में थे। संपूर्ण ऐप एकल फ़ाइल में था जिसमें कोई स्पष्ट संरचना नहीं थी। कुछ भी संस्करण नहीं था। मैंने CVS रेपो (उस समय कोई SVN उपलब्ध नहीं) को कॉन्फ़िगर करके शुरू किया, ग्राहक के लिए इस पर एक वेब इंटरफ़ेस रखा। सबसे पहले, मैं अपने सहयोगियों से स्वयं कमिट संभाल रहा था। फिर, मैंने सभी तरीकों को अलग-अलग मॉड्यूल (फाइलों) में विभाजित किया। उस समय, सहयोगियों ने सीवीएस को अपनाना शुरू कर दिया। फिर, मैंने HTML को कोड से बाहर कर दिया। फिर, हर बार मुझे कोड के कुछ हिस्से में एक बदलाव करना पड़ा, मुझे इसमें से कुछ को रिफ्लेक्टर करने में थोड़ा समय लगा। अंत में, विकास का वेग इतना बढ़ गया था कि ग्राहक बेहद खुश था। वे एक कॉस्मेटिक बदलाव का अनुरोध करेंगे और हमारे बजाय उन्हें "यह 2 दिन लगेंगे" बता रहे हैं:

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

एक आखिरी बात, एक पूर्ण पुनर्लेखन कभी-कभी एकमात्र समाधान होता है, लेकिन आमतौर पर प्रबंधन को इसकी लागत का औचित्य साबित करना बहुत कठिन होता है।


0

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

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