जब मौजूदा ढांचे का उपयोग करने की तुलना में अपने स्वयं के ढांचे का निर्माण करना अधिक उत्पादक होता है? [बन्द है]

Question

मैं जानना चाहूंगा कि आपने अपनी कंपनी में अपना ढांचा बनाने का फैसला क्यों किया।

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

तो आपने अपना ढांचा क्यों बनाया? आप उस व्यक्ति को कैसे सही ठहरा सकते हैं जो आपको नियुक्त करता है। क्या आपने इसके सकारात्मक और नकारात्मक प्रभाव को मापा है?

अपने अनुभवों के बारे में, क्या आपने देखा है कि किसी मामले में एक कंपनी के ढांचे ने वास्तविक लाभ पैदा किया, या दूसरी तरफ, विकास की बढ़ती लागत (सीखने की अवस्था, डिबगिंग, रखरखाव, ...)?

Comments

मैंने फैसला नहीं किया। यह खुद बनाया ...

— Mchl

इसे भी देखें: क्या सॉफ्टवेयर पुन

— Gnat

Answer 1

क्यों का जवाब:

• लाइसेंस जारी करता है
• कंपनी की विशिष्ट आवश्यकताएं जो वर्तमान रूपरेखाओं में मौजूद नहीं थीं
• कंपनी फ्रेमवर्क के समर्थन और रखरखाव पर नियंत्रण रखना चाहती है
• वास्तुकार बेहतर नहीं जानता था! वह / वह उस विशिष्ट ढांचे के बारे में नहीं जानता था, इसलिए उन्होंने पहिया को फिर से बनाने का फैसला किया।

अद्यतन करें:

उद्यम "छोटे" फ्रेमवर्क का उपयोग करने के बजाय पहिया को फिर से मजबूत करना पसंद करते हैं। छोटे से मैं उस रूपरेखा का उल्लेख करता हूं जिसमें अनिश्चित भविष्य हो सकता है। उदाहरण के लिए। .NET का ढांचा एक छोटे समुदाय द्वारा बनाए गए ढांचे की तुलना में उद्यमों के लिए अधिक सुरक्षित विकल्प है। उद्यमों को सुरक्षा की आवश्यकता है क्योंकि उनके कई अनुप्रयोग व्यवसायिक हैं और लंबे समय तक जीवित भी हैं। पहिया को सुदृढ़ करने की लागत कम शब्दों में अधिक हो सकती है। लेकिन लागत अधिक हो सकती है यदि कंपनी के आवेदन में उपयोग किए गए ढांचे को हटा दिया जाता है और अब समर्थित नहीं है, या लाइसेंस बदल दिए जाते हैं। यहां कंपनी को वर्तमान ढांचे को बाहर फेंकना पड़ सकता है और दूसरे में डाल दिया जा सकता है। Visual Basic एक ऐसी भाषा का एक अच्छा उदाहरण है जो अब Microsoft द्वारा समर्थित नहीं है। और यह लागत कंपनियों को अरबों की है क्योंकि उन्हें नए विकास के साथ शुरू करना है।

Answer 2

अपना खुद का निर्माण क्यों?

1. क्योंकि यह पहले कभी नहीं बनाया गया है (दुर्लभ, लेकिन फिर भी एक संभावना)
2. क्योंकि आप पूर्ण नियंत्रण चाहते हैं।
3. क्योंकि आपको केवल थोड़ी सी कार्यक्षमता की आवश्यकता है ताकि इसे स्वयं बनाना सस्ता हो

अपना खुद का निर्माण क्यों नहीं?

1. आपके पास ऐसा करने का समय नहीं है
2. यदि आप किसी मौजूदा ढांचे को खरीदते हैं तो यह संभवतः बहुत सस्ता है
3. आप बहुत समय बचाते हैं और बहुत तेजी से उत्पादक प्राप्त कर सकते हैं

Answer 3

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

Answer 4

पहिया को सुदृढ़ करने का एकमात्र वास्तविक कारण यदि यह एक व्यवसायिक महत्वपूर्ण अनुप्रयोग है। यदि आपकी कंपनी आने वाले कुछ समय के लिए उपयोग कर रही होगी। यदि यह आवेदन / ढांचा / आदि। संभावित रूप से मौजूदा वाणिज्यिक ढांचे से परे विकसित करने की पेशकश करनी होगी, फिर कंपनी कोडर्स होने से उनका कार्यान्वयन निश्चित रूप से स्वीकार्य है।

इसके विरुद्ध एकमात्र वास्तविक कारण हैं यदि:

1. मौजूदा ढांचा अच्छी तरह से बनाए रखा है, पूरी तरह से अपने काम के अनुरूप है, और भविष्य में अच्छी तरह से होगा।

2. यह In नॉट इंवेंटेड हियर ’सिंड्रोम का मामला है

3. आपका वर्तमान सेटअप उचित समय के लिए उचित मात्रा में इस ढांचे को सफलतापूर्वक बनाने में सक्षम नहीं होगा।

जोएल स्पोल्स्की ने इस मामले पर एक बहुत अच्छा लेख लिखा: इन डिफेंस ऑफ नॉट-इन्वेंटेड-हियर सिंड्रोम

Answer 5

मूल रूप से जब आप दूसरों के काम का उपयोग करते हैं, तो आप उन्हें अदृश्य नियोक्ता या "अतिरिक्त हाथ" के रूप में जोड़ते हैं।

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

कीवर्ड एक इंटरफ़ेस को कोड करके, फ्रेमवर्क को स्वैपेबल बनाने के लिए है। जावा दुनिया में सबसे कठोर इंटरफेस सन स्पेसिफिकेशन हैं, जो सर्वलेट एपीआई द्वारा सिद्ध किया गया है।

तब मैं किसी ढांचे का उपयोग न करने का कोई कारण नहीं मानूंगा।

Comments

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

— जोएरी सेबर्चेस

Answer 6

हमें जहां काम मिला है, वहां काफी परिपक्व ढांचा मिला है। यहाँ एक सारांश नींव रूपरेखा है

इसका उपयोग करने के प्रमुख कारणों में से एक स्थिरता है। हम Microsoft या किसी अन्य आपूर्तिकर्ता के लिए निहारना नहीं कर रहे हैं जो नई सुविधाओं और जटिलता वर्ष को जोड़ने के लिए प्रेरित हैं।

(मेरे अपने विचार, मेरे नियोक्ता आदि के नहीं आदि)

Answer 7

मैंने ऐसा कई बार किया था, मौजूदा रूपरेखाओं (तब तत्कालीन) द्वारा कवर की गई आवश्यकताओं को पूरा करने के लिए।

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

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