आप बड़ी परियोजनाओं का ट्रैक कैसे रखते हैं?


16

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

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

अब मैं अपने आप को एक ऐसी स्थिति में पाता हूँ जहाँ मुझे एक बड़े Zend फ्रेमवर्क PHP प्रोजेक्ट के साथ बातचीत करने की आवश्यकता है जो किसी और ने विकसित की है, और मैं कई फाइलों में फैले कोड को समझने की कोशिश कर रहा हूं।

किसी बड़े कोड के आधार को समझने के लिए आपको कौन सी तकनीक और प्रक्रिया उपयोगी लगी है जो किसी और ने विकसित की है? क्या कोई विशेष आरेख है जो आपको लगता है कि आपको बड़ी तस्वीर को समझने में मदद करता है?


संभवतः एक यूएमएल घटक आरेख?
maple_shaft

जवाबों:


7

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

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

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


आपकी जानकारी के लिए धन्यवाद: मैं grep के साथ vim w / ctags का उपयोग कर रहा हूं। अभी भी PHP के Xdebug की आदत है। मुझे लगता है कि आपका अंतिम पैराग्राफ, हालांकि, सबसे उपयोगी सलाह है।
१३:१३ पर linqq

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

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

"जितना बड़ा यह है, उतने अधिक प्रोग्रामर इस पर अनुभव के साथ हैं" वे जरूरी नहीं कि अभी भी वहां काम करते हैं, या वे इसे अच्छी तरह से याद नहीं कर सकते हैं (प्रबंधन)
user1821961

2

कोई शॉर्टकट नहीं है। इसका खामियाजा आपको ही भुगतना पड़ेगा।

कैसे चित्र प्राप्त करने के लिए के बारे में अपने सवाल का जवाब करने के लिए, Doxygen तुम क्या चाहते है। AFAIK यह PHP के साथ काम करता है।

आम तौर पर, मैं एक नए कोडबेस का सामना करते समय लगभग निम्न चरणों से गुजरता हूं:

  1. यह समझें कि यह उपयोगकर्ता के दृष्टिकोण से क्या करता है। वास्तव में एक पावर-उपयोगकर्ता की तरह एप्लिकेशन का उपयोग करने में सक्षम हो। समझें कि वास्तविक अंतिम उपयोगकर्ता इसके साथ कैसे काम करते हैं। यह उनके साथ बैठने की आवश्यकता हो सकती है जब तक कि आप क्या करते हैं इसकी ठोस समझ हासिल नहीं करते हैं।

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

  3. जो भी फ्रेमवर्क आप उपयोग कर रहे हैं उसके बारे में जानें। कम से कम, आपको उत्पादन अनुप्रयोग में गोता लगाने से पहले उस ढांचे के साथ "हैलो वर्ल्ड" या अन्य सरल एप्लिकेशन बनाने में सक्षम होना चाहिए।

  4. संपूर्ण परिनियोजन प्रक्रिया पर एक पकड़ प्राप्त करें (सबसे अच्छा जबकि मूल डेवलपर्स आपके हाथ पकड़ रहे हैं)। यदि आप वर्तमान कोडबेस को नहीं ले सकते हैं और इसे बना सकते हैं और इसे परीक्षण / सत्यापन / ठेस वातावरण के माध्यम से तैनात कर सकते हैं, तो आप टोस्ट हो सकते हैं। यहां तक ​​कि सबसे छोटे परिवर्तन को तैनाती के सभी हुप्स के माध्यम से कूदने की आवश्यकता होगी, इसलिए इस हिस्से को तुरंत नीचे क्यों नहीं मिला? ऐसा करने में, आपको ऐप द्वारा उपयोग किए जाने वाले सभी प्यारे सर्वर, डेटाबेस, सेवाओं और लिपियों से परिचित कराया जाएगा - आपको पता चल जाएगा कि "यह कहाँ रहता है"।

  5. कार्यात्मक परीक्षणों (यदि कोई हो) पर एक पकड़ प्राप्त करें। अगर आप ठीक से चल रहे हैं तो आपको कैसे पता चलेगा? आवेदन की देखभाल और खिलाने के लिए ऑपरेशन लोगों को क्या करना है?

  6. ऐप के लॉग्स को समझें। हालाँकि मैंने कभी भी PHP के साथ काम नहीं किया है, लेकिन मैं एक जंगली अनुमान लगाऊंगा और कहूंगा कि किसी भी गंभीर PHP एप्लिकेशन में किसी प्रकार की लॉगिंग होगी। यदि आप लॉग को समझते हैं, तो डिबगिंग समस्याओं के लिए समय आने पर आपके पास एक अच्छा प्रारंभिक बिंदु होगा।

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

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

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

  3. IDE बुकमार्क कोडबेस में हॉट-स्पॉट को टैग करने के लिए अमूल्य हैं। तेजी से उनके माध्यम से टॉगल करने में सक्षम होना समझ को बढ़ावा देगा।

  4. हाल की बग-रिपोर्ट और उनके प्रस्तावों को पढ़ना हॉट-स्पॉट को समझने के लिए भी मूल्यवान है और आपको कोडबेस के सबसे प्रासंगिक भागों पर गति करने में मदद करेगा।


1

जैसा कि अनुरोध किया गया है, यहाँ एक उत्तर के रूप में मेरी टिप्पणी है।

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

यदि कोडबेस में परीक्षण (एकीकरण या इकाई) होते हैं, तो वे कभी-कभी जांचने लायक भी होते हैं।


1

मैं वास्तव में इस सप्ताह के दौरान ऐसा करना शुरू करने जा रहा हूं जहां एक नए ग्राहक को किसी अन्य डेवलपर द्वारा छोड़े गए उत्पाद के लिए एन्हांसमेंट की आवश्यकता होती है। नीचे दिए गए चरणों का पालन किया जा रहा है:

a) उपयोग किए गए प्रोग्रामिंग ढांचे की पहचान करें, जो यह जानने में मदद करता है कि आवेदन कैसे बहता है।

ख) सामान्य सेवाओं की पहचान करें - लॉगिंग, अपवाद हैंडलिंग, एमवीसी, डेटाबेस कनेक्शन, ऑडिटिंग, व्यू (पेज जनरेशन) क्योंकि ये ऐसे हिस्से हैं जहां हम सबसे ज्यादा इस्तेमाल करेंगे।

ग) सामान्य उपयोगकर्ता प्रवाह (एप्लिकेशन में) के माध्यम से चलाएं फिर उन्हें संरेखित करने का प्रयास करें कि कोड कैसे रखा गया है

d) कुछ बदलाव करने की कोशिश करें और देखें कि वे कैसे बाहर आते हैं। यह सबसे बड़ा कदम है क्योंकि जब तक आप बदलाव करना शुरू नहीं करते तब तक कोड एक ब्लैक बॉक्स है ...।

मैं आपको बताऊंगा कि अगले दो सप्ताह में मुझे और कौन से विचार आएंगे


0

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


कोड पर टिप्पणी की जाती है और अन्यथा अनैच्छिक रूप से टिप्पणी की जाती है। यह खेदजनक है, लेकिन ऐसा कुछ भी नहीं है जो मैं इसे स्वयं दस्तावेजीकरण करने में कमी कर सकूं।
linqq

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

0

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

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


0

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

मुझे जो मिलता है, वह एक बड़ा एकल मॉडल है, जो कई उप-मॉडलों द्वारा तैयार किया गया है, जो संकुल द्वारा बनाए गए हैं, जो कि क्लासिफायर आदि द्वारा रचे गए हैं। .... मल्टी प्रोजेक्ट स्तर पर काम करने से मुझे प्रत्येक क्लासिफायरियर और मैथोड कॉल को मल्टीप्रोजेक्ट स्तर पर ट्रेस करने की सुविधा मिलती है। मेरा मतलब है कि एक ही विधि प्रोजेक्ट ए में एक क्लासिफायरियर और प्रोजेक्ट बी में एक अन्य क्लासिफायरियर कह सकती है। प्रोजेक्ट की पूरी संरचना को देखने का एकमात्र तरीका दोनों को एक ही समय में रिवर्स करना है। मेरे पास घटक आरेख बनाने का समय नहीं है और जानकारी वास्तव में सटीक नहीं है। मैं कंप्यूटर को मेरे लिए पूर्ण परियोजना को उलटने के लिए कहना पसंद करता हूं। मैं टीम के साथ प्रत्येक पुनरावृत्ति पर एक रिवर्स करता हूं और मेरे सभी आरेख तुरंत अपडेट किए जाते हैं। रिवर्स इंजीनियरिंग वृद्धिशील है और जावा से यूएमएल आईडीएस मैपिंग का उपयोग करता है। मेरा मतलब है कि प्रत्येक जावा तत्व को एकल और अद्वितीय MOF तत्व के लिए मैप किया जाता है, जो कि सभी प्रोजेक्ट जीवन के दौरान समान रहता है, भले ही रिफैक्ट किया गया हो। ऐसा करना जो यूएमएल मॉडलिंग को कोई अधिक सीमा नहीं देता है और बहुत बड़े और जटिल प्रोजेक्ट मॉडलिंग की अनुमति देता है। आपकी जानकारी के लिए मैं OOP कोड की 5 000 000 से अधिक लाइनों वाली परियोजना के साथ काम करता हूं। मेरी सभी परियोजनाएं ठीक से उलट हैं और चित्रमय नेविगेशन संभव है

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

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