टेम्पलेट साइटों के लिए TK बनाने के लिए मेरा दृष्टिकोण

एक एपिग्राफ के बजाय।

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

शुभ दोपहर, महान और शक्तिशाली Habr।
कुछ समय पहले, तकनीकी कार्यों ( एक साधारण (टेम्पलेट) साइट के लिए एक कार्य कैसे निर्धारित करें , हम टीके की रचना क्यों करते हैं और बदले में क्या है? तकनीकी कार्य की शर्तें ), जो मैं जारी रखना चाहूंगा और टीके लिखने के लिए अपने दृष्टिकोण के बारे में बताना चाहता हूं। टेम्पलेट साइटें।

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

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

हमारी प्रक्रिया इस तरह दिखती है:

1. हमने एक ग्राहक पाया, बात की, एक आम समझ में आया कि हम साइट पर क्या करेंगे, और कीमतों के पैमाने की घोषणा की।
2. डिजाइन और प्रोग्रामिंग का काम दो समानांतर शाखाओं में गिरता है - डिजाइन और प्रोग्रामिंग। टीके का डिज़ाइन नहीं लिखा है। मैं व्यक्तिगत रूप से कल्पना नहीं कर सकता कि टीके को कैसे लिखा जा सकता है। नहीं, हम कह सकते हैं कि वे तीन कॉलम कहते हैं, शीर्ष पर एक बैनर और एक हरे रंग का लोगो, लेकिन केवल इस तरह के विवरण में डिजाइन और पूर्ण बेकार दोनों की एक उत्कृष्ट कृति शामिल हो सकती है और तदनुसार, ग्राहक को परेशान करती है। यानी ऐसे टीके यह गारंटी नहीं दे सकते कि सॉफ्टवेयर भाग के लिए टीके के विपरीत, आउटपुट कुछ भी अच्छा होगा, जहां टीके गारंटी दे सकता है कि हमें वह मिलेगा जो हमने आदेश दिया था (कम से कम सैद्धांतिक रूप से)। डिजाइन के लिए टीके करना मेलोडी के लिए टीके की तरह है: "एक नोट 8 बार से अधिक नहीं, ड्रम, और यह मजेदार होगा" - बकवास।
3. कार्य की दूसरी शाखा सॉफ्टवेयर भाग है, इसमें प्रोग्रामिंग, लेआउट और संबंधित कार्य शामिल हैं। एक नियम के रूप में, यह प्रक्रिया डिजाइन की तुलना में थोड़ी देर बाद शुरू होती है, जब पहले लेआउट पहले से ही होते हैं।
4. हम सब कुछ एक साथ जोड़ते हैं और परिणाम को होस्टिंग पर डालते हैं।

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

टीके को लिखने का मेरा पहला प्रयास अजीब था, अक्सर मुझे एक टीके मिला, एक आधा लिखित दस्तावेज जो कभी किसी को नहीं दिखाया गया था, लेकिन इस दस्तावेज के साथ मैंने हर बार इस तरह एक साइट आरेख तैयार करना शुरू किया:



इस तरह की योजना बनाने के लिए सरलता और समय लेने वाले समय के बावजूद, यह टीके के विकल्प के रूप में बहुत उपयोगी है।

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

इसके अलावा, इस योजना ने एक और समाधान करना संभव बना दिया, इस बार आंतरिक समस्या। हमारे पास अक्सर इतना होता था कि डिज़ाइनर समन्वय और अनुमोदन के बाद साइट के प्रमुख पृष्ठों का पता लगा लेते थे, लेकिन कुछ माध्यमिक के बारे में भूल गए। यह क्षण अनियंत्रित हो गया, डिज़ाइन कट गए, और फिर प्रोग्रामर को जिन्होंने रिपोर्ट की:
"404 पेज की कटौती कहाँ है?"
- लेकिन नहीं। भूल गए ...

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



तो अभी यह स्पष्ट है कि क्या खींचा गया था और क्या नहीं था, कौन से डिजाइन थे और कौन से नहीं थे।

इस प्रकार, साइट लेआउट के निम्नलिखित फायदे हैं:

• केवल
• जल्दी से
• साइट पर पृष्ठों के सेट को स्पष्ट रूप से सेट करता है, सभी विशलिस्ट को काट देता है, जिससे पृष्ठों की संरचना में बदलाव हो सकता है, और यह विशलिस्ट का एक बहुत बड़ा वर्ग है

योजना का नुकसान:

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

होटलोक की ऐसी श्रेणी साइट पर मौजूद संस्थाओं के विवरण से कट जाती है। उदाहरण के लिए, "समाचार" है:

• नाम - 255 वर्ण तक लंबा स्ट्रिंग
• घोषणा - समाचार की घोषणा के साथ पाठ, 200 अक्षरों तक की लंबाई
• पाठ - समाचार पाठ, अधिकतम 5000 वर्ण
• प्रकाशन दिनांक

संक्षेप में, यह डेटाबेस फ़ील्ड के वर्णन के बराबर है, केवल मानव भाषा में।
और अगर ग्राहक कहता है कि "मुझे विभिन्न प्रकार के समाचारों के लिए आइकन चाहिए", तो हम समाचार के स्वीकृत विवरण को खोलते हैं और पढ़ते हैं कि वहां क्या लिखा गया है।

हालांकि, इस तरह के विवरण के साथ, सामान्य टीके के बिना, एक योजना के साथ तिरस्कृत नहीं किया जा सकता है और इसे लिखने के लिए किसी को बैठना होगा।

जैसा कि मैंने टीके में ऊपर कहा था, हमने डिजाइनर को यह देते हुए उपस्थिति के बारे में एक शब्द नहीं बनाया। केवल साइट का तकनीकी हिस्सा TK में था। मैं यह नहीं कहूंगा कि हमारा टीके GOST के अनुसार बनाया गया था, लेकिन यह कुछ रचनात्मक प्रसंस्करण और पुनर्विचार के बाद GOST 19.201-78 पर आधारित था।

ऐसी TK की सामग्री लगभग इस प्रकार थी:

सामग्री
1. परिचय
2. विकास का आधार
3. विकास का उद्देश्य
3.1। कार्यात्मक उद्देश्य
3.2। संचालन का उद्देश्य
4. एक कार्यक्रम या सॉफ्टवेयर उत्पाद के लिए आवश्यकताएँ
4.1। साइट के सार्वजनिक भाग की कार्यात्मक विशेषताओं के लिए आवश्यकताएं
4.1.1 सामान्य
4.1.2 साइट पृष्ठ
4.1.2.1 अनुभाग "होम"
4.1.2.3 अनुभाग "निष्कर्ष और टिप्पणियों के साथ पृष्ठ"
4.1.2.4 अनुभाग "परियोजना अवधारणा का विकास", "परामर्श और परियोजनाओं का समर्थन", "विपणन लेखा परीक्षा", "बाजार पर वस्तु का संवर्धन", "कंपनी द्वारा बिक्री", "बिक्री प्रबंधन"
साइट के निजी भाग की कार्यात्मक विशेषताओं के लिए 4.2 आवश्यकताएँ (व्यवस्थापक)
४.२.१ सामान्य
4.2.2 सामान्य सेटिंग्स प्रबंधन पृष्ठ
4.2.3 "होम" अनुभाग के प्रबंधन के लिए पेज
4.2.4 "संपर्क पृष्ठ" अनुभाग के प्रबंधन के लिए पृष्ठ
4.2.5 अनुभाग "टिप्पणियों के साथ पृष्ठ" के प्रबंधन के लिए पृष्ठ
4.2.5 "परियोजना अवधारणा का विकास", "परियोजनाओं का परामर्श और समर्थन", "विपणन लेखा परीक्षा", "बाजार पर एक वस्तु का संवर्धन", "एक कंपनी द्वारा बिक्री", "बिक्री प्रबंधन" अनुभागों के प्रबंधन के लिए पेज।
4.2.6 "निष्कर्ष" खंड का प्रबंधन पृष्ठ
4.4। संचालन की स्थिति
4.5। हार्डवेयर और सॉफ्टवेयर की संरचना और मापदंडों के लिए आवश्यकताएं
4.6। लेबलिंग और पैकेजिंग आवश्यकताएँ
4.7। परिवहन और भंडारण आवश्यकताएँ
5. साइट भरना
6. नियंत्रण और स्वीकृति के लिए प्रक्रिया

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

हालांकि, यह पता चला कि टीके के साथ एक और समस्या है। टीके लिखना एक उबाऊ सबक है जो ताजा हवा में कठिन शारीरिक श्रम की तरह, एक व्यक्ति को मवेशी बना देगा।

व्यक्तिगत रूप से, टीके लिखना वास्तव में मुझे परेशान करता है। सबसे पहले, यह एक उबाऊ सूखा पाठ है। दूसरे - सभी टीके एक दूसरे के समान हैं और एक नियम के रूप में आपके लिए इतने सारे मतभेद नहीं हैं, कोई रचनात्मकता नहीं है। लेकिन ये मतभेद, बुराई के रूप में, विभिन्न परियोजनाओं में एक ही कार्य के उपयोग की अनुमति नहीं देते हैं। तीसरा, TK तब लिखा जाता है जब आप पहले से ही अपने लिए भविष्य की साइट के बारे में सब कुछ समझ जाते हैं, और जब आप सब कुछ समझ जाते हैं, तो किसी कारण से आप वास्तव में इसे लिखना नहीं चाहते हैं।

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

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

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

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

स्वाभाविक रूप से मैं कुछ चाहता था जिसके लिए सब कुछ शुरू किया गया था - एक तकनीकी कार्य।

मुझे और भी बहुत कुछ चाहिए था ...

शब्दों में समझाने की अपेक्षा मैंने जो दिखाना आसान कर दिया है।
यहां एक तीन मिनट का वीडियो है जो मैंने जो कुछ किया था, उसे संक्षेप में प्रदर्शित करता है।



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

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

मुझे आशा है कि आप मेरे अनुभव और मेरी सेवा दोनों से लाभान्वित होंगे।

युपीडी। यदि आप एक हब्र उपयोगकर्ता नहीं हैं, और एक निमंत्रण चाहते हैं, तो साइट पर एक फीडबैक फॉर्म है।
UPD2। सेवा से सीधा लिंक। azalo.net