"सुपर" साइटों के लिए और उनके खिलाफ क्या विचार दिए जाने चाहिए?


9

मेरी कंपनी अपने सभी टियर -1 (यानी शीर्ष अंत उत्पादन) अनुप्रयोगों और साइटों को एक सभी में शामिल कोड आधार को समेकित करने पर विचार कर रही है।

सिद्धांत यह है कि उनकी अनुमतियाँ, डिज़ाइन और समग्र कार्यक्षमता को समरूप और केंद्रित रूप से प्रबंधित किया जा सकता है।

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

संपादित करें :

वर्तमान परिवेश में तीन ASP.Net 1.1 साइटें हैं, जिनमें पहली बार लिखे जाने के बाद से मुश्किल से कोई वास्तविक प्रेम देखा गया है (मुख्यतः कंपनी में अनुभवी डेवलपर्स की अनुपस्थिति के कारण) और एक MVC2 एप्लिकेशन जो कि ASP.Net 1.1 साइट होने से पहले भी था पिछले साल अपग्रेड किया गया। हम विशेष रूप से C # में लिखते हैं।

कंपनी लगभग 50 कर्मचारियों के साथ एक काफी छोटी है; जिनमें से तीन वास्तविक डेवलपर हैं। प्रबंधन (यहां तक ​​कि आईटी प्रबंधन) के पास आईटी परियोजनाओं के परियोजना प्रबंधन (और इसलिए शब्दावली और व्यावसायिक प्रभावों के कुछ गुजर ज्ञान) के अलावा कोई भी आईटी पृष्ठभूमि या अनुभव नहीं है।

कंपनी द्वारा बेचे जाने वाले उत्पादों का समर्थन करने के लिए आवेदन मुख्य रूप से ऑनलाइन सेवाएं हैं। कंपनी किसी भी सॉफ्टवेयर को सीधे नहीं बेचती है।

इसलिए इस पूरी स्थिति को यथोचित रूप से विशिष्ट और उत्तर देने योग्य प्रश्न के रूप में उद्धृत करना: आपके सभी सिस्टमों को एक साथ एक ओवर-आर्चिंग सॉल्यूशन में खींचने की कोशिश करने के खिलाफ और उसके खिलाफ कुछ सम्मोहक कारण क्या हैं? )?


4
यहाँ प्रस्तुत प्रश्न अत्यंत खुला हुआ और व्यापक रूप से विस्तृत है। यदि आप इसे कम कर सकते हैं तो यह बेहतर प्रश्न हो सकता है।
ChrisF

@ क्रिस - मैं कोशिश करूँगा। क्या आप सुझाव दे सकते हैं कि आप किस प्रकार की बारीकियों को देखना पसंद करेंगे?
फिल.हेलर

@ आप ओपी हैं, आप क्या देख रहे हैं?
जॉर्ज स्टॉकर

@ आप जिस तरह से भाषा पर कुछ बारीकियों को देना चाहते हैं, क्योंकि कई उपकरण हैं जो अनुप्रयोगों के प्रबंधन (जैसे सुरक्षा, लॉगिंग, कॉन्फ़िगरेशन, डीबी कनेक्शन आदि) को बाहरी करते हैं
गैरी रोवे

1
इस तरह से वे मिट्टी के 3 - 4 छोटे गेंदों के बजाय मिट्टी की एक बड़ी गेंद की उपेक्षा कर सकते हैं, इस तरह से अधिक कुशल!

जवाबों:


10

बुरा विचार

यह प्रतिक्रिया निम्नलिखित मान्यताओं पर आधारित है:

  1. काफी हद तक असमान अनुप्रयोगों का एक बहुत ही उपयोग किया जा रहा है
  2. विभिन्न अनुप्रयोगों पर कई टीमें काम कर रही हैं
  3. अनुप्रयोगों का सक्रिय प्रबंधन करने वाला कोई भी सम्मानित और आधिकारिक सॉफ्टवेयर आर्किटेक्ट नहीं है

आगे चलकर क्या होगा

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

यदि यह दबाता है तो कुछ प्रकार के केंद्रीकृत रिपॉजिटरी जिसमें कॉन्फ़िगरेशन डेटा (जैसे सुरक्षा पहुंच, लॉगिंग स्तर आदि) की आवश्यकता होगी, जिस पर कोई व्यक्ति स्पष्ट रूप से इंगित करेगा और कहेगा

"अरे, हम पुराने अनुप्रयोगों के लिए इस बाहरी विन्यास दृष्टिकोण को वापस क्यों नहीं लेते हैं, यह बहुत जल्दी हो जाएगा?"

और एक पल बाद कोई और साथ जाएगा

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

अंतिम होने तक

"ओह, और यहां बहुत सारे समान कोड हैं, इसलिए कुछ आसानी से साझा किए गए पुस्तकालयों को एक साथ नहीं रखा गया है। हमें हर रात नियमित अंतराल पर कुछ प्रकार के एकीकरण बिल्ड रन की आवश्यकता होगी।"

जिस बिंदु पर हर कोई राहत की सांस लेता है कि एक विशाल मोनोलिथ का निर्माण नहीं किया गया था।


(+1) सिर्फ (1) के लिए, शेष विवरण भी मान्य है ...
umlcat

3

हम अपनी कंपनी में इस पर काम कर रहे हैं। मुझे लगता है कि यह संभव है और स्पष्ट लाभ हैं (आपने उनका उल्लेख किया है), हालांकि, यह संभवतः एक न्यूनतम न्यूनतम पर 5 से 7 वर्ष की परियोजना होगी, और मूल रूप से सब कुछ फिर से लिखना होगा। यदि आप ऐसा कुछ करने के लिए साइन अप कर सकते हैं, तो मैं कहूंगा कि इसके लिए जाएं। यदि नहीं, तो एक बुरे मौत के लिए तैयार हो जाओ मार्च।


3

Google ऐसा करता है, इसलिए यह निश्चित रूप से संभव है

यह लिंक बीटीडब्ल्यू एक गोगलर की एक दिलचस्प प्रस्तुति है कि वे अपने कोड आधार, निरंतर एकीकरण, परीक्षण आदि का प्रबंधन कैसे करते हैं।

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

यहाँ महत्वपूर्ण सवाल यह है कि क्यों ? वरिष्ठ प्रबंधन ऐसा क्यों करना चाहता है? क्या बचत, लाभ या अन्य लाभ वे हासिल करने की उम्मीद करते हैं?

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


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

InfoQ को वहाँ कुछ बहुत अच्छी प्रस्तुतियाँ मिलती हैं; वे मेरी RSS सूची में एक शीर्ष साइट हैं।
sdg

2

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

जब हमने पहली बार नए उत्पाद पर काम शुरू किया, तो पुरानी टीम ने उस 5% पर प्रतिकूल प्रभाव डालने वाले बदलाव किए, क्योंकि वे नए उत्पाद को समझ नहीं पाए। इसलिए हमने उस 5% कोड को पूरी तरह से छोड़ दिया, जिसने हमें समय पर पहली रिलीज को पूरा करने में सक्षम बनाया।

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

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


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

2

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

उस ने कहा, आपके सभी एप्लिकेशन एक ही कोड रिपॉजिटरी में होने में कुछ भी गलत नहीं है , जहां प्रत्येक एप्लिकेशन का अलग क्षेत्र है। यह आपको उदाहरण के लिए किसी भी ऑनलाइन दस्तावेज़ को एक ही, सुसंगत दृश्य में उत्पन्न करने की अनुमति देता है, जो आम तौर पर एक अच्छी बात है जितना आप चाहते हैं उतना दृश्यता प्राप्त करें।

जो लोग यह तय करते हैं, उन्हें दृढ़ता से विचार करना चाहिए कि वे इसे क्यों करना चाहते हैं, और विचार करें कि वे वहां कितना काम करना चाहते हैं।


2

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

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

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


1

मेरी पहली सोच यह है कि यह रिलीज के लिए कुल PITA होगा।

यदि प्रबंधन और अनुमोदन की सभी परतों से बचना है, तो कार्यक्षमता की प्रबंधनीय विखंडू में विभाजन अधिक समझदार है।

घटकों / सेवाओं में आम सामान को तोड़ना और उस तरह से मानकीकरण करना आईएमएचओ के लिए बहुत आसान होगा।


0

आप एक अलग तकनीक का उपयोग करके इसे अलग-अलग तरीके से कर सकते हैं, जैसे कि आपके सभी वेब एप्लिकेशन को समान रूप से वितरित करना। मूल रूप से, प्रत्येक एप्लिकेशन अभी भी अलग है; वितरण XSLT नियमों का उपयोग करता है जो आपके द्वारा डिज़ाइन किए गए एक स्थिर HTML टेम्पलेट में उनके उत्पादन को बढ़ाता है। यह अपेक्षाकृत सरल स्थिर HTML / CSS विषय को कम से कम विक के साथ अनुप्रयोगों के एक पूरे सूट पर लागू करने की अनुमति देता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.