एकाधिक डिपेंडेंट फ्रंट एंड्स के साथ एक सॉफ्टवेयर लाइफ साइकिल रणनीति चुनना

सॉफ्टवेयर जीवन चक्र अधिकांश आधुनिक प्रोग्रामर के लिए जाना जाता है।

यहां तक ​​कि एक स्कूली छात्र भी अपना पहला कार्यक्रम लिख रहा था

<?php echo "Hello, !  " ?> 

या

 fprintf( '   !\n'); 

प्रक्रिया को समझता है।

1. कार्य पर विचार - विचार का चरण
2. वह कार्य पर सोचते हैं और इसे किस तरह से लागू करने की आवश्यकता है - विश्लेषण और आवश्यकताओं का विस्तार,
   एक सॉफ्टवेयर मॉडल और कार्यान्वयन योजना बनाना। संक्षेप में, वास्तु चरण।
3. प्रोग्रामिंग।
4. परीक्षण। "वहाँ क्या हुआ"
5. ऑपरेशन।

1-5 चरणों के बीच, हम लगातार बातचीत प्रक्रियाएं करते हैं।

इसके लिए, सभी प्रकार के झरने, स्क्रैम आदि हैं।

तो बात यह है, जब आपकी परियोजना कई प्रकार के सीमांतों को बढ़ावा देती है,
जैसा कि आधुनिक आईटी की दुनिया में आवश्यकता है, ग्राहक अपने लाभ को अधिकतम करने के लिए दर्शकों को अधिकतम करना चाहता है।

और इस कारण से, हम सभी परियोजनाओं की एक बहुतायत का निरीक्षण करते हैं जिसमें कई प्रकार के सीमांत होते हैं जो एपीआई के माध्यम से एक केंद्रीय बैकएंड के साथ बातचीत करते हैं।

सामान्यतया, "मानक मजबूत परियोजना" में तीन प्रकार के मोर्च होते हैं:

1. वेबसाइट
2. Android पर मोबाइल एप्लिकेशन
3. आईओएस मोबाइल ऐप

REST के माध्यम से डेटा के आदान-प्रदान के लिए एकल विकसित एपीआई के साथ।

एक अच्छा उदाहरण है जिस पर मैं भरोसा करूंगा सोशल मीडिया (YouTube vidos पर आधारित अपने खुद के खिलाड़ी के बारे में मेरा पिछला लेख देखें)

एक बड़ी परियोजना के लिए लाभ या कोई मानदंड बनाने के लिए तीन विकल्प हैं
सशर्त रूप से वेब, सेब और Android।

यह प्रोग्रामर के लिए केंद्रीकृत बैकएंड आर्किटेक्चर के साथ बातचीत करने और उनके व्यक्तिगत मोर्चे पर ध्यान केंद्रित करने के लिए सुविधाजनक है, जिसे वे विकसित कर रहे हैं।

और यहाँ लेख का मुख्य आकर्षण दिखाई देता है।

तथ्य यह है कि वरिष्ठों के बीच निर्णय लेने के शीर्ष स्तर पर है
एक नई सुविधा बनती है, जो पीछे तक जाती है। लेकिन चूंकि "बॉस" एक अपूर्ण व्यक्ति है,
फिर उसे अपनी शक्तियों को निचले स्तरों तक कम करना होगा।

इसलिए, हमारे मामले में, एक नियम के रूप में, प्रत्येक मोर्चे के ऊपर भी पदानुक्रमित या औपचारिक आधार के अनुसार उनके "निम्न-स्तरीय" प्रमुख दिखाई देते हैं। कुछ
सादगी के लिए टाइमलाइड्स का प्रकार।

और एक बड़े प्रोजेक्ट को "विकास जीवन चक्र" के रूप में विकसित करने का कार्य
और सॉफ्टवेयर ऑपरेशन को इसके जीवन चक्रों में विभाजित किया गया है।

और सवाल "मिनी" जीवन चक्र की प्रक्रियाओं को सिंक्रनाइज़ करने में उठता है, क्योंकि यदि आप आगे हैं, उदाहरण के लिए, एक नई सुविधा के एक वेब डेवलपर, आपको एक मोबाइल डेवलपर के लिए इंतजार करना होगा।

अन्यथा, इस तरह के नए फीचर का अर्थ प्राथमिकता में खो जाता है, क्योंकि हम सभी अब वेब पर और स्मार्टफोन से मोबाइल एप्लिकेशन में हैं।

आइए ऐसी स्थिति में मानव संसाधनों को कम करने के लिए नई सुविधाओं की शुरूआत का मूल्यांकन करने के बारे में सोचें।

यहाँ मैं थिसिस की आवाज़ दूंगा:

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

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

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

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

मेरा विचार एक ऐसा विचार है - मुख्य प्रकार के जीवन चक्र को बनाए रखने और स्वतंत्र मोर्चों के इस मामले में उपप्रकार होने के दौरान, आपको एक प्राथमिकता को ध्यान में रखना होगा
सामने का प्रकार (धन के लिए, ऐतिहासिक कारण या अन्यथा), लेकिन उन्हें उच्च-स्तरीय प्रकार के चक्र के नीचे एक इकाई होना चाहिए।

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