2010-04-14 14 views
15

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

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

  • // WHY IS THIS NOT WORKING
  • // I know this is bad but were going for working stuff right now...
  • // This is a PHP code outputing Javascript code outputting HTML...do not go further
  • // Not userful

मैं सबसे अच्छा सलाह मैं यहाँ प्राप्त कर सकते हैं के लिए देख रहा हूँ। यदि आप मेरी स्थिति में थे तो आप क्या करेंगे?

संपादित करें: आपकी सभी त्वरित और सहायक सलाह के लिए, सभी को धन्यवाद!

+3

+1 बहुत मनोरंजक लिखा –

उत्तर

19

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

अपने प्रबंधक को अपना काम करने दें - प्रतिस्थापन परियोजना पर आरओआई की गणना करें - और निर्णय लें।

+2

और यदि वह मना कर देता है, तो एक नया गिग ढूंढें ... :) – xandercoded

5

वास्तव में यह आपके द्वारा देखे जा रहे आकार और दायरे पर निर्भर करता है।

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

उपरोक्त कोड कोड को देखते हुए, ऐसा लगता है कि यह आपके कोड स्निपेट को thedailywtf.com पर सबमिट करने योग्य भी हो सकता है। ;)

+0

अच्छा विचार ... मैं देखूंगा कि मुझे वहां पोस्ट करने के लिए एक रसदार स्निपेट नहीं मिल रहा है! –

1

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

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

0

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

2

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

2

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

3

प्रत्येक व्यक्ति समय-समय पर खराब कोड प्राप्त करता है।

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

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

संबंधित मुद्दे