उपयुक्त टीके, बहुत कम

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

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

क्लाइंट की ओर से एक ही बात: मैं इस बटन पर क्लिक करता हूं, और मुझे कहां जाना चाहिए? और फिर क्या? हाँ, यह समझ में आता है, विवरण के विपरीत "हमें पेस्टल रंगों में एक आधुनिक सुपर-आधुनिक-प्रणाली की आवश्यकता होती है और कार्यक्षमता के साथ जो प्रबंधकों की जरूरतों को यथासंभव पूरा करती है। $ 500 के लिए, और नहीं। "

आम तौर पर वर्णित
1. जो प्रवेश द्वार पर होगा, और जो बाहर निकलने पर बदल जाएगा
यह सभी टीके का आधार है। ग्राहक की जरूरतों का स्पष्टीकरण, खुद के लिए और उसके लिए। विकास के अंत में असहमति के मामले में तर्क। यह परियोजना से पहले किया जाता है। यदि इस भाग का वर्णन नहीं किया गया है, या यह करना असंभव है, तो राजनीति और भ्रम शामिल हैं। इस तरह की परियोजना शुरू करना अधिक महंगा है। आप नकारात्मक जाएंगे या असफल भी होंगे।

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

विवरण सामान्य रूप में, स्वतंत्र रूप में हो सकता है। अक्सर यह फुटनोट्स (एल्गोरिदम के लिए) के साथ आरेख के रूप में, या नमूना स्क्रीनशॉट (साइट के मामले में) के रूप में प्राप्त किया जाता है। खैर, अगर यह एक आधिकारिक दस्तावेज है, तो यह सब शब्दों में विस्तार से वर्णित है।
यहां संक्षेप में न्यूनतम टीके और प्रलेखन का वर्णन करना संभव है। सामान्य तौर पर - 90% मामलों में पर्याप्त है।

UPD : वे पूछते हैं, यह सब क्यों लिखा गया है?
हां, विकास के क्षेत्र में जटिल और बड़ी परियोजनाएं हैं, जिनके लिए टीके और प्रलेखन के संकलन पर बहुत बड़ी किताबें लिखी गई हैं, और वहां यह आवश्यक हो सकता है। हजारों पत्रक में प्रलेखन, सैकड़ों पृष्ठों में टी.के.
लेकिन अभी भी बहुत बड़ी परियोजनाओं का एक विशाल द्रव्यमान नहीं है, खासकर वेब विकास के माहौल में, जहां इस बड़े और जटिल टीके और प्रलेखन को लिखने में कोई समझदारी नहीं है। लेकिन इसके बिना भी, यह भी बुरा है, minuses ज्ञात और संकेतित हैं। यह नोट आपका अपना अनुभव है, एक तरफ जो न्यूनतम आवश्यक है, अपने आप को और ग्राहक को जोखिमों से बचाएं और स्थिति को स्पष्ट करें, कुछ ऐसा लिखें जो दूसरे डेवलपर का समर्थन कर सके, दूसरी ओर, इस पर उचित समय और प्रयास खर्च करें। ।

हे, कर्म के साथ इस साइट पर दिलचस्प बकवास। इस समय पोस्ट में 47 को पसंदीदा, 11 + और 12 से जोड़ा गया - कुल "कर्म" -1, मैं वोट नहीं कर सकता और टिप्पणी नहीं लिख सकता।
और ये -12 कौन स्पष्ट नहीं है - कोई टिप्पणी नहीं। महान गुमनाम? सामान्य तौर पर, इस तरह की चीज़ के साथ, ऐसा लगता है, मुझे इस वेबसाइट पर और कुछ नहीं लिखना है - सिस्टम नहीं करता है। और इसे जारी रखना संभव होगा।