यदि आपको अभी किसी नई परियोजना से परिचित कराया गया है, तो पहली बात यह है कि आप यह कैसे देखते हैं कि यह कैसे काम करता है?
क्या आप पहले डिजाइन की तलाश करते हैं? यदि कोई डिजाइन है, तो आप उसमें क्या देखते हैं? वर्ग आरेख या तैनाती आरेख या अनुक्रम आरेख या कुछ और?
या आप सीधे कोड के लिए जाते हैं? यदि हां, तो आप यह कैसे समझते हैं कि विभिन्न परतें कैसे बातचीत करती हैं?
जवाबों:
मैं कोड के साथ शुरू करता हूं। यदि कोई हो, तो अलग-अलग डिज़ाइन के दस्तावेज़, गलत होने या गलत होने की संभावना नहीं है। तो, मैं कोड के माध्यम से कुछ सरल प्रवाह का पता लगाने की कोशिश कर रहा हूं; उदाहरण के लिए, यदि यह एक वेबप है, तो यह अनुरोध या अनुक्रम हो सकता है। एक बार जब मैंने ऐसा कर लिया है, तो मेरे पास अधिक समझ को लटका देने के लिए एक प्रकार का कंकाल है। फिर, मैं वापस जा सकता हूं और डिजाइन या अन्य दस्तावेज पढ़ सकता हूं, लेकिन उस समय, मेरे पास उनसे संबंधित और उन्हें मान्य करने के लिए कुछ ठोस है, इसलिए मैं डफ जानकारी का पता लगा सकता हूं। या मैं सिर्फ पढ़ने के कोड, या परीक्षण मामलों, आदि पर ले जा सकता है
मैं उच्च स्तर पर शुरू करूंगा। यदि कोई उपयोगकर्ता प्रलेखन का सामना कर रहा है - उपयोगकर्ता मैनुअल या गाइड। ऐसा करने में विफल रहने के बाद आवश्यकताओं की कल्पना करें ताकि आपको यह पता चल जाए कि सॉफ्टवेयर क्या करना है। मैं डिजाइन को देखना चाहता हूं और इसे कोड फ़ाइलों पर मैप करने का प्रयास करूंगा। उम्मीद है कि ये कुछ समझदार तरीके से फ़ोल्डर्स में संरचित हैं। मैं तब डिज़ाइन का हिस्सा चुनूंगा और फ़ाइलों में जाकर कोड के प्रवाह का पालन करने के लिए बिना बारीक बारीक बारीक बारीक बारीक फाइल किए।
मैं एक डेवलपर्स सिस्टम स्थापित करके शुरू करता हूं। मैं प्रलेखित प्रक्रिया का उपयोग करता हूं। इससे बिल्ली को बैग से बाहर निकलने की अनुमति मिलती है कि वास्तविकता के साथ प्रलेखन कितना है।
यह मुझे यह भी बताता है कि निर्भरताएं क्या हैं। यह मायने रखता है।
अब जब मुझे एक डेवलपर्स सेटअप मिल गया है, (और मैं सेटअप दस्तावेज़ को सुधार के साथ चिह्नित करता हूं क्योंकि मैं जाता हूं) मैं एक संस्करण बनाता हूं। मैं इस चरण के माध्यम से सभी से सवाल पूछना चाहता हूं।
अब यह बनाया गया है, मैं उपयोगकर्ता मैनुअल से परिचयात्मक व्यायाम करता हूं। यह मुझे मोटे तौर पर बताता है कि सिस्टम वास्तव में क्या करता है।
अब मेरे पास सिस्टम के बारे में एक आंशिक सुराग है, मैंने डिज़ाइन दस्तावेजों को पढ़ा, जो अब मैं इस अनुपात में मानता हूं कि अब तक के दस्तावेज़ कितने गलत हैं।
एक बार जब मैं वास्तविक व्यवहार दस्तावेज प्राप्त कर लेता हूं तो मैं कोड को देखना शुरू कर सकता हूं और यह देख सकता हूं कि वास्तव में क्या है। वे कभी लाइन नहीं लगाते, लेकिन मुझे अब पता है कि कितना विश्वास करना चाहिए।
फिर मैं "टूडू" और "फ़िक्मे" टिप्पणियों के लिए आईडीई आउटपुट को देखता हूं। "संस्करण 2.0 में ठीक" जैसी चीजें टिप-ऑफ भी हैं।
तो यह सब सीखने की सच्चाई है, और जैसा कि लोग बताते हैं, अलग-अलग डिज़ाइन दस्तावेज़ शायद ही कभी अद्यतित या सही होते हैं, लेकिन यह आपको बताता है कि लोग एक समय में क्या सोच रहे थे। और निश्चित रूप से, वे लोग पूछताछ करने के लिए आसपास नहीं हैं।
मेरी प्राथमिकता परियोजना के विवरण प्राप्त करने के लिए डिजाइन के साथ शुरू करना है और विवरण में ड्रिलिंग से पहले इसकी कुछ प्रमुख विशेषताओं और / या संरचना को समझने की कोशिश करना है।
हमेशा डिजाइन। कोड के साथ यह डेवलपर सेटअप चरणों से गुजरने लायक है (स्रोत की जांच करना, परियोजना का निर्माण करना, किसी भी कॉन्फ़िगरेशन परिवर्तन को आवश्यक बनाना), लेकिन इसके कोड से किसी एप्लिकेशन की संरचना को सीखने की कोशिश करने का कोई मतलब नहीं है। यह केवल आपको बताता है कि संरचना क्या है, इसलिए नहीं कि संरचना क्या है या अन्य डेवलपर्स क्या सोचते हैं हाइलाइट और खराब बिंदु वास्तुकला के हैं। जिन्हें आप व्हाइटबोर्ड आरेखों से सीखते हैं और डेवलपर्स के साथ चैट करते हैं।
सॉफ्टवेयर के एक जटिल टुकड़े के लिए मैं इसे लगभग उसी तरह से देखूंगा जैसे कि यह एक नई विकास परियोजना थी। बड़े विचारों के साथ शुरू करें- दृष्टि, संदर्भ, गुंजाइश, हितधारकों। कुछ उपयोगकर्ता प्रलेखन के माध्यम से पढ़ें और यह कैसे उपयोग किया जाता है इसका एक विचार प्राप्त करें। यदि संभव हो तो सॉफ़्टवेयर के साथ कुछ उपयोगकर्ता प्रशिक्षण प्राप्त करें (या लागू करें)। फिर एक उच्च स्तर पर कैसे काम करता है, इसका अंदाजा लगाने के लिए आवश्यकताओं और डिज़ाइन के दस्तावेज़ों को देखना शुरू करें। अगर वे अभी भी आसपास हैं तो डिजाइनरों से बात करें। विभिन्न दृष्टिकोणों में सिस्टम आर्किटेक्चर को देखें। वहां से, मुख्य कार्यक्षमता में खुदाई करना शुरू करें और कुछ कोड को देखें, आवश्यकताओं पर लौटें और आवश्यकतानुसार डिज़ाइन करें। जैसा कि आप कोड को देखते हैं, उसे कार्रवाई में देखने के लिए सॉफ़्टवेयर चलाएं। सभी समय, भविष्य के संदर्भ के लिए कुछ सारांश प्रलेखन संकलित करें- आप स्वयं क्लिफ नोट्स। बाहर शाखा जब तक आप एक बहुत अच्छा विचार है कि यह सब कैसे काम करता है और एक साथ फिट बैठता है, लेकिन उन हिस्सों पर ध्यान केंद्रित करें जिनके साथ आप काम करेंगे। अब तक आपको पूरे सिस्टम की ऊपरी-से-नीचे की समझ है, या कम से कम उन हिस्सों पर जो आपके लिए लागू हैं।
बेशक, वास्तविक दुनिया में आपके पास इस सब से गुजरने का समय नहीं हो सकता है, इससे पहले कि आपको अपने हाथों को गंदा करना शुरू करना होगा, खासकर बड़ी परियोजनाओं पर। लेकिन यह है कि अगर यह मेरे ऊपर था तो मैं इसे कैसे करूंगा।
आपको स्वयं और किसी भी डिज़ाइन दस्तावेज़ के बीच आगे और पीछे काम करना चाहिए।
आप कोड या डिज़ाइन पर शुरू कर सकते हैं, और यह वास्तव में मायने नहीं रखता है। जब तक आप अच्छी तरह से और वास्तव में भ्रमित न हों, तब तक कोड पढ़ें, फिर डिज़ाइन डॉक्स देखें। या, उच्च-स्तरीय चित्र प्राप्त करने के लिए डिज़ाइन डॉक्स पढ़ें फिर कोड को देखें कि वह कैसा दिखता है। जब तक आप कोड के साथ काम कर रहे हों तब तक लगभग अनिश्चित काल तक दोहराएं।
ध्यान रखें कि डिज़ाइन डॉक्स लगभग हमेशा पुराने हैं, और कई मायनों में गलत हैं। हालाँकि, जब तक आप इन बिंदुओं को ध्यान में रखते हैं, तब तक पुराने दस्तावेज़ अभी भी आपको अतीत के किसी बिंदु पर लेखक के मन को समझने में मदद करते हैं। उच्च-स्तरीय मुद्दों और चिंताओं में से कई अभी भी मान्य होंगे, और आप बहुत संभवत: यह समझने में अधिक सक्षम होंगे कि कोड कहां से मिला है, यदि आप एक दिनांकित चित्र जहां लेखक मूल रूप से सोचा था कि यह जा रहा था जाओ।
जैसा कि आप कोड और डिजाइन के माध्यम से काम करते हैं, अपने स्वयं के दस्तावेज बनाएं जो आज कोड की आपकी समझ का वर्णन करते हैं। शायद ये दस्तावेज़ एक साधारण स्केच या दो हैं, हो सकता है कि वे विकी में राइटअप हों, शायद वे कुछ और हों। उन्हें बहुत जटिल न बनाएं: कोई 30 पृष्ठ का शब्द डॉक्स नहीं। बस अपने विचारों को नीचे लाएं, जो आपकी अपनी सोच को बहुत स्पष्ट करेगा।
यह आवेदन के प्रकार पर निर्भर करता है। यदि इसका डेटा-केंद्रित ऐप है, तो मैं आमतौर पर डेटाबेस डिज़ाइन के साथ शुरू करता हूं। यदि इसके पास UI है तो आप चला सकते हैं (या अच्छे स्क्रीन डिज़ाइन) जो आपको एक अच्छा विचार दे सकते हैं कि ऐप बहुत जल्दी क्या करता है (मैं यहाँ कुछ घंटों में ही बात कर रहा हूँ)। उसके बाद मैं कोड में खुदाई शुरू करता हूं और यह अधिक समझ में आएगा क्योंकि मुझे पता है कि आवेदन क्या कर रहा है।
मैं डिजाइन प्रलेखन के साथ शुरू करता हूं। विशेष रूप से, विनिर्देश - जो उस चीज़ के इरादे को बताता है जिसे देखा जा रहा है।
यदि संभव हो, तो मैं डिजाइन नोट्स और प्रलेखन को देखता हूं कि यह कैसे किया गया है, इसका एक सामान्य स्वाद प्राप्त करने के लिए, विचार प्रक्रिया, संबंधित लोगों की शैली और प्रकृति।
यदि संभव हो तो मैं उन लोगों से बात करूं जिन्होंने इस पर काम किया है - यह क्या करता है? कैसे? क्यों? शव कहां दफनाए गए हैं?
डेवलपर्स के बीच कोड में छलांग लगाने की प्रवृत्ति है: "मुझे आपको यह कोड दिखाने दें"। यह उनके लिए ठीक है लेकिन मेरी जरूरतों को कम करने के लिए जाता है - जो उच्च स्तर को समझना है जो निम्न स्तर के सामान को संदर्भ देता है।
यह कोड के छोटे बिट्स को देखने के लिए, संपूर्ण संदर्भ से बाहर, और कुछ भी सार्थक समझने के लिए बड़ी मात्रा में मस्तिष्क की शक्ति का उपयोग करता है। यदि संभव हो तो, डेवलपर्स को PRINCIPLE, संरचना, इकाइयों, मॉड्यूल के बारे में बात करने के लिए, जो कुछ भी कार्य की सराहना की ओर जाता है।
तभी यह कोड में आने की कोशिश करने लायक है।
चीजों की बड़ी योजना में, कोड को देखना ० और १ के पूर्ण पृष्ठ को देखना है। अर्थ है लेकिन यह पता लगाने के लिए एक लंबा समय लगता है। कहाँ देखना है और कौन से भाग सार्थक हैं, इसका स्वाद प्राप्त करना खोज स्थान को संकीर्ण करने में मदद करता है।
सभी ने कहा - जब कोई डोको नहीं है, कोई लोग नहीं हैं, और केवल कोड है - तो इसके लिए कोड को देखने के अलावा कुछ भी नहीं है।
उस स्थिति में, मैं सामान्य रूप से धीमी गति से गहरी पढ़ने से इसे समझने और समझने की कोशिश नहीं करता, मैं एक त्वरित पास करता हूं, सब कुछ पढ़ने में। कभी-कभी यह सिर्फ खुली हुई फाइलें होती हैं और पृष्ठ-डाउन कुंजी दबाने के साथ बैठती हैं। ऐसा करने से आपको एक बड़ी तस्वीर की अद्भुत सराहना मिल सकती है। (और कुछ मामलों में मैं स्ट्रिंग-डंप निष्पादन योग्य फाइलें भी करता हूं और उन पर हस्ताक्षर करता हूं, हस्ताक्षर और पैटर्न की तलाश करता हूं। यह पिछले 20-वर्षों में आश्चर्यजनक रूप से फलदायी रहा है।)
मैं परीक्षणों से शुरू करता हूं। यदि यूनिट परीक्षण और एकीकरण परीक्षण अच्छी तरह से लिखे गए हैं, तो वे उपयोग के मामलों का वर्णन करते हैं। यदि वे अच्छी तरह से नहीं लिखे गए हैं, या बिल्कुल नहीं लिखे गए हैं (दुख की बात है, यह काफी हद तक मामला है), मैं कोड में प्रवेश बिंदुओं से शुरू करता हूं और उन लोगों के डिजाइन के साथ मेल खाता हूं।
फिर मैं प्रत्येक उपयोग के मामले के लिए परीक्षण लिखूंगा, जिस पेड़ को आप प्रविष्टि बिंदुओं की जांच करने के बाद पाएंगे, कोड की जांच करने और कोड कवरेज उपयोगिताओं का उपयोग करने के लिए कि मैं क्या याद कर रहा हूं। ये परीक्षण मुझे बताते हैं कि कोड कैसे काम करता है।
मैं हमेशा उस चीज़ के लिए मूल्य जोड़ने की कोशिश करता हूं जिसे मैं देखता हूं; लेखन परीक्षण, सफाई कोड, बड़े (20 + लाइनों) कार्यों refactoring।
मुझे लगता है कि अकेले प्रलेखन बनाने से कोड में कोई वास्तविक मूल्य नहीं जुड़ता है क्योंकि यह कोड के साथ कभी भी बातचीत नहीं करता है।
ठीक है, "डिजाइन" क्या है? एक README एक आरेख आरेख? आप एक डिज़ाइन डॉक्यूमेंट आधे रास्ते (और सबसे अधिक) कर सकते हैं, आप आधे रास्ते को कोड नहीं कर सकते
कोई भी डिजाइन बस एक राय होने जा रहा है , जबकि कोड तथ्य है
जब मैं कोड के तर्क को नहीं समझ पाऊंगा, तो मैं केवल माध्यमिक दस्तावेजों को संदर्भित करूंगा
एक डेवलपर के लिए रीडिंग कोड एक आवश्यक कौशल है। आप इसे अभी भी सीख सकते हैं, आपको अपने करियर के दौरान वैसे भी बहुत उपयोगी दस्तावेज देखने को नहीं मिलेंगे
फिर मैं डेवलपर की README, TODO और चांगेलॉग को देखता हूं। अगर मुझे समझ में नहीं आता है कि सॉफ्टवेयर क्यों लिखा गया, यह कैसे लिखा गया, और यह कहां जा रहा है ... मैं इसका उपयोग नहीं करता।
पहले डिजाइन, फिर कोड, ऊपर-नीचे यदि आप चाहें, तो मैं हर स्तर पर संदर्भ को समझता हूं जो मुझे काम करना है।
लेकिन अगर मुझे एक बहुत ही विशिष्ट परिवर्तन करना है, जैसे कि एक रिपोर्ट या एक गणना को ठीक करना, तो मैं सिर्फ कोड को देखता हूं।
विशेष रूप से, मेरा "डिजाइन पहले" दृष्टिकोण यह है:
अगर कोई एक है, तो मैं डी डोमेन मॉडल से शुरू करता हूं, अगर कोई नहीं है तो मैं कम से कम एक बुनियादी एक (एक अच्छा प्रारंभिक बिंदु डेटा मॉडल) हूं। यह आवेदन की "शब्दावली" और वस्तुओं (कक्षाओं) के बीच के संबंध को परिभाषित करता है।
यह "किन वस्तुओं को संभाला जाता है" चित्र पर निर्भर करता है।
फिर मैं एप्लिकेशन द्वारा "क्या प्रक्रियाएं करता हूं" यह पता लगाने के लिए उपयोग केस मॉडल की तलाश करता हूं, हालांकि मैं एक प्रक्रिया मानचित्र पसंद करता हूं यदि वह एक है, जो प्रक्रियाओं के अनुक्रम दिखाता है।
उसके बाद मेरे पास एप्लिकेशन की एक अच्छी तस्वीर होनी चाहिए और फिर मैं डिजाइन को बदलने के बारे में जा सकता हूं।
वैसे, उपरोक्त उत्तर व्यावसायिक अनुप्रयोगों के संदर्भ में है।
कोड झूठ नहीं है। निश्चित रूप से अच्छा विचार यह समझने के लिए कि यह क्या करता है पहले परियोजना का अवलोकन करें । हालाँकि, यदि आपका कार्य इस बारे में विस्तृत जानकारी प्राप्त करना है कि प्रोजेक्ट कैसे काम करता है, तो कोड को देख रहा है, कम से कम मेरे लिए, एक पहेली टुकड़े को देखने की तरह है, सिवाय इसके कि आप जिस प्रत्येक वर्ग को देखते हैं, उसके साथ आप एक और जोड़ रहे हैं पहेली का टुकड़ा। यदि कोड अच्छी तरह से संरचित है, तो आप कक्षाओं के नामों से एक पैटर्न बना सकते हैं, जिसमें यह जांचे बिना कि कक्षा क्या करती है। कई मामलों में, आप कोड से संकेत और सुराग प्राप्त कर सकते हैं जो आपको आगे सहायता करेगा।
अंत में, आपको वह मिलता है जो कार्यक्रम क्या करता है, यह एक पूरी पहेली है। प्रलेखन अधूरा या गलत हो सकता है, लेकिन कोड कभी भी झूठ नहीं होता है। यह सब आप एक व्यक्तिगत विधि क्या करता है पता लगाने के बिना कर सकते हैं। हर कोई इस तरह से एक परियोजना के बारे में नहीं जान सकता है, लेकिन अगर आप इसे अक्सर करते हैं, तो यह आपके लिए आसान हो जाता है, यह उल्लेख नहीं करने के लिए कि आप अध्ययन के एक दो घंटों में मध्यम आकार के आवेदन का सार प्राप्त कर सकते हैं। हालांकि मुझे लगता है कि यह सब वरीयता के लिए नीचे आता है।
जब मैं सबसे महत्वपूर्ण मॉड्यूल / बिंदु के कोड को देखता हूं: कोड को देखकर, मैं डिजाइन की अच्छाई को सत्यापित कर सकता हूं।
उदाहरण:
आपको वित्तीय रिपोर्टिंग के बारे में वेब-ऐप के एप्लिकेशन प्रबंधन में काम करना होगा।
जब मैं संदेश के बारे में कोड पढ़ता हूं, तो प्रारंभ और अंतिम अनुप्रयोग (db में संभावित लॉक के लिए), डेटा के निर्माण की मास्टर प्रक्रिया जो रिपोर्ट की जानी है आदि आदि (उदाहरण के लिए, गैस के भंडारण में मास्टर प्रक्रिया के बारे में है आपूर्ति और इंजेक्शन के साथ ग्राहकों के भंडारण क्षेत्र में गैस स्टॉक की गणना; माध्यमिक प्रक्रिया इस डेटा की पिछली गणना की गई है)
मैं पहले डिजाइन के साथ जाऊंगा फिर समवर्ती कोड। यह बहुत महत्वपूर्ण है क्योंकि हर परियोजना अलग है। इससे पहले कि आप समवर्ती कोड पर काम करना शुरू कर सकें, आपको ए से जेड तक की योजना और उच्च स्तरीय प्रक्रिया वर्कफ़्लो के साथ बाहर आना होगा। किए गए प्रत्येक निर्णय को अन्य टीमों (या अपने आप) को दस्तावेजित किया जाना चाहिए जो कोड विकसित कर रहे हैं / नवीनतम अपडेट को जानेंगे और पुष्टि की गई है।
यदि कोई उच्च स्तरीय डिज़ाइन दस्तावेज़ है, तो मैं उसका उपयोग करूँगा। इसे संक्षिप्त और अद्यतित किया जाना है। यदि यह बहुत अधिक क्रियात्मक है या पुराना है, तो मैं कोड के लिए जाऊंगा।
बेशक, यह परियोजना पर निर्भर करता है, है ना? एक अत्यंत जटिल या कई-मुखिया परियोजना शायद प्रलेखन के माध्यम से बेहतर तरीके से संपर्क की जाती है (यदि दस्तावेज पर्याप्त रूप से ठोस है।)
एक एकल सरल मॉड्यूल या सरल अनुप्रयोग, मेरी राय में, कोड स्तर पर लगभग हमेशा सबसे अच्छा होता है।
हर स्थिति के लिए कोई सही जवाब नहीं है!