2008-09-24 31 views
8

हां, डरावना 'एम' शब्द।सॉफ्टवेयर रखरखाव इंजीनियरिंग के लिए सर्वोत्तम उपकरण

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

आप क्या करने जा रहे हैं?

{पसंदीदा संपादक} और जीआरपी आपको कोड बेस के ग्रेनिंग गट्स के माध्यम से अपने स्पेलंकिंग पर शुरू कर देगा, लेकिन रखरखाव इंजीनियरों टूलबॉक्स में अन्य टूल्स क्या होना चाहिए?

गेंद-रोलिंग शुरू करने के लिए; मुझे नहीं लगता कि मैं सी/सी ++ स्पेलंकिंग के लिए source-insight के बिना रह सकता हूं। (अस्वीकरण: मैं 'em के लिए काम नहीं करता)।

+0

वोदका, टकीला, या स्कॉच अच्छी तरह से काम करते हैं – Danimal

+0

ओह, मैन! अधिक सहमत नहीं हो सकता है। –

+0

एमएच, यह कुछ ओपनसोर्स परियोजनाओं के साथ वास्तव में एक सामान्य स्थिति है - लेखन दस्तावेज़ प्रोग्रामर का पसंदीदा कार्य नहीं है। मैं आमतौर पर अपना संपादक लेता हूं और कोड को पीछे तक पढ़ना शुरू करता हूं जब तक कि मुझे पता न हो कि मामले में यह क्या करता है, जो मुझे अपेक्षित नहीं करता है। मुझे आमतौर पर उम्मीद है कि यह पूरी तरह से काम करता है। ;) – unexist

उत्तर

3

.Net स्पेस में सबसे अच्छे टूल में से एक ReSharper है। इस टूल ने मुझे विकास जीवन चक्र के सभी पहलुओं में समय बचाया है। उन्होंने अनियंत्रित परियोजना/समाधान में शामिल होने पर मुझे जीवित रहने में भी मदद की है।

  • कोड रीफैक्टरिंग
  • कोड नेविगेशन
  • कोड विश्लेषण

इन जो एक समय लेने वाली कार्य करने में मदद कई सुविधाओं में से कुछ कर रहे हैं।

0

हाँ, सिर पर कील मारा। एक यूनिक्स खोल और आसान नोटपैड ++ वह है जो मैंने उपयोग किया था जब मैंने कोल्डफ्यूजन, PHP, पर्ल इत्यादि में रखरखाव का काम किया था। संपादकों को स्विच करने के लिए अच्छा नहीं है, और किसी नाम/param/variable के सभी संदर्भों को ट्रैक करना अच्छा है।

अब मैं सिर्फ विजुअल स्टूडियो में 'सभी संदर्भ ढूंढें' पर क्लिक करके हिट करता हूं, जो कि ईमानदार होने के लिए धोखा देने जैसा लगता है। PHP लोग बेहद ईर्ष्यापूर्ण हैं, क्योंकि उन्हें संपादन के लिए vi का उपयोग करने के लिए मजबूर होना पड़ता है। ;)

1

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

1

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

0

महत्वपूर्ण टूल ऐसा कुछ होगा जो आपको अपनी समझ में मदद के लिए कोड बेस पर नेविगेट (और संपादित) करने की अनुमति देता है।

क्लास रिलेशनशिप प्रदर्शित करने में कुछ ऐसा होना बहुत उपयोगी है (यदि ओओ भाषा का उपयोग करना है)। जब आप एक बदलाव के प्रभाव को गेज करना चाहते हैं तो प्रदर्शित करने के लिए (स्थैतिक) कॉल पेड़ प्रदर्शित करने की क्षमता भी बहुत उपयोगी होती है।

आप स्रोत-अंतर्दृष्टि का उल्लेख करते हैं। एक लंबी चल रही ओपन सोर्स प्रोजेक्ट source navigator है। ऐसा लगता है कि थोड़ी देर के लिए स्थिर होने के बाद विकास फिर से शुरू हो गया है।

4

प्रयोग करेंगे बस हाथी खाने - एक समय में एक काटने :)

कभी कभी बड़ी तस्वीर एक असली Demotivator हो सकता है, और आप एक लेने के लिए की जरूरत है स्पॉट और टुकड़े से टुकड़ा टुकड़ा।

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

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

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

मनोबल के एक जोड़े। -boosting किताबें:

शुभकामनाएं :)

1

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

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

एक लिखित लॉग भी सहायक है, ताकि आप सिस्टम के साथ-साथ दस्तावेज़ को दस्तावेज कर सकें।

0

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

0

आपको पर कोड करने के लिए पर नेविगेट करने की आवश्यकता है। यदि आपका पसंदीदा आईडीई इस परमिट करता है, तो आप Understand for C++ (पहले से उद्धृत), lxr, या OpenGrok जैसे इंडेक्सर का उपयोग कर सकते हैं।

जल्दी में, आप grep(1s) या बेहतर - Ack पर भरोसा कर सकते हैं।

2

कोड सर्च इंजन आपको एक विशाल स्रोत बेस के आसपास रास्ता खोजने में मदद कर सकते हैं।

एक लैंगेज-संवेदनशील स्रोत कोड खोज इंजन SD Source Code Search Engine पर पाया जा सकता है। यह एक ही समय में कई भाषाओं को संभाल सकता है। खोज विशिष्ट लैंगेज, या भाषाओं में पैटर्न (जैसे "टैक्स से जुड़े पहचानकर्ता ढूंढें") में पैटर्न के लिए किया जा सकता है। लैंगेज टोकन से संवेदनशील होने के कारण, उपयोगकर्ता के लिए बचत समय बचत समय कम हो गया है। यह सी, सी ++, सी #, कोबोल, जावा, ईसीएमएस्क्रिप्ट, जावा, एक्सएमएल, वेरिलोग, वीएचडीएल, और कई अन्य भाषाओं को समझता है।

(मैं टूल आर्किटेक्ट हूं)। मैं एक हूँ टूल डेवलपर

के शब्दों में Scott Hanselman that wrote once on his blog: "NDepend मुझे मेरे अनुप्रयोगों है कि मैं हेवन 'में अंतर्दृष्टि दे रहा है

0

NDepend re-engineer legacy code के लिए समर्पित एक उपकरण, विशेष रूप से बड़े उलझ विरासत कोड ठिकानों अस्वीकरण है टी पहले था (...) एक बार जब मैं उस जानकारी की गहराई और चौड़ाई महसूस कर रहा था, तो मैं इसे देख रहा था, "मैं एक कैंडी की दुकान में एक बच्चे की तरह था।"

पुन: इंजीनियरिंग के लिए उपयोगी कुछ एनडॉन्ड्स की विशेषताएं हैं:

  • Dependency Matrix/Dependency Graph, कोड की संरचना को समझने के लिए।
  • Code Rule over LINQ Query (CQLinq) कोड बेस से मुझे अपना सर्वश्रेष्ठ रहस्य देने के लिए कहने के लिए। डिफ़ॉल्ट रूप से 200 code rules से अधिक प्रस्तावित हैं।
  • Diff on code base, यह देखने के लिए कि कोड के किसी भी 2 संस्करणों के बीच क्या जोड़ा/refactored/हटा दिया गया है।
संबंधित मुद्दे