2010-05-25 7 views
7

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

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

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

परिमाण का एक विचार: यह PHP, MySQL और jQuery का उपयोग करता है। इसमें लगभग 20-30 मुख्य (फ्रंटएंड) फ़ाइलें हैं, जिनमें लगभग 15 शामिल फ़ाइलें और कुछ संपत्तियों के कुछ फ़ोल्डर्स हैं - इसलिए कुल मिलाकर यह एक बहुत छोटा एप्लीकेशन है। यह 7 MySQL तालिकाओं के साथ इंटरफेस करता है, प्रत्येक एक अच्छी तरह से नामित है, इसलिए मुझे लगता है कि डेटाबेस अंत बहुत आत्म-स्पष्टीकरणपूर्ण है। एक config.inc.php फ़ाइल है जिसमें MySQL उपयोगकर्ता विवरण, कुछ ईमेल से, और यूआरएल जो PHP और ईमेल और पृष्ठों (सापेक्ष और पूर्ण पथ, मूल रूप से) में डालने के लिए उपयोग करते हैं, के आधार पर परिभाषाओं की परिभाषाओं के साथ है। JQuery के माध्यम से कुछ AJAX है।

वहाँ है अगर किसी भी अन्य जानकारी है कि आप मेरी मदद कर और मैं में संपादित करने में खुशी होगी मदद मिलेगी कृपया टिप्पणी।


डेवलपर शुक्रवार को छोड़ देता है। हालांकि वह इस दस्तावेज कार्य में अपने अधिकांश 24 शेष घंटे समर्पित कर सकता है। तो, हाँ, चीजें उदास हैं लेकिन 24 घंटे काफी थोड़ा है ... सही? : - \

+0

डेवलपर के साथ जाने से पहले आपके पास कितना समय होगा? – ddbeck

+0

शुक्रवार उनका आखिरी दिन है। 24 शेष कार्य घंटे। – Ricket

उत्तर

4

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

फिर, प्रत्येक बुलेट बिंदु के लिए, उस बुलेट बिंदु से जुड़े मुख्य आवश्यकताओं को लिखें।

प्रत्येक आवश्यकता के लिए, लिख:

  • कुछ भी है कि विशेष आवश्यकता
  • कहाँ कोड है कि आवश्यकता कार्यान्वित किया जाता है (जो php, इंक फ़ाइलें, टेबल)

इस में के बारे में विचित्र आपको एक ट्रेसिबिलिटी पदानुक्रम

फ़ीचर => आवश्यकता => कार्यान्वयन

यह यादों को झुकाव और गेटचा लिखने के लिए एक अच्छा ढांचा भी प्रदान करेगा।

फिर, प्रत्येक PHP और inc पृष्ठ पर टिप्पणी करें।

उस शीर्षलेख से प्रारंभ करें जो उद्देश्य को रेखांकित करता है और पिछली सूची से कौन सी आवश्यकताएं संतुष्ट हैं (कोड से आवश्यकता के विपरीत रिवर्सबिलिटी)।

प्रत्येक php/inc फ़ाइल के माध्यम से जाएं और प्रमुख कार्यों/निर्णयों/लूपों को टिप्पणी करें जो वे पूरा करने की कोशिश कर रहे हैं और किसी भी डिजाइन विचारों को मानते हैं (उदाहरण के लिए "इनपुट पिछले चरण में मान्य माना गया है") ।

स्रोत कोड पर टिप्पणी करते समय, आप PHPDoc जैसे टूल का उपयोग करना चाह सकते हैं ताकि आप टिप्पणियों से दस्तावेज़ीकरण उत्पन्न कर सकें।

4

मीटिंग्स पर हाथों की एक श्रृंखला की व्यवस्था करने के लिए एक दृष्टिकोण हो सकता है। इन में डेवलपर को प्रत्येक सेक्शन के लिए कोड समझा जाना होगा।

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

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

भले ही कुछ भी "छड़" न हो, फिर भी जब आप इसे बाद में फिर से देखेंगे तो साइट के साथ कुछ परिचितता होगी।

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

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