मेरे बॉस का "यहाँ न आने का बुरा हाल" है [बंद]


66

मेरा विभाग ग्राहक डेटा को हमारे डेटाबेस स्कीमा में बदलने में माहिर है ताकि वे हमारे सॉफ़्टवेयर का उपयोग कर सकें।

अभी, हमारे पास C # एप्लिकेशन हैं जो एक IDataReader(99% समय यह एक है SqlDataReader) लेते हैं , कुछ सफाई और मैपिंग करते हैं, इसे एक DataRowऑब्जेक्ट में सम्मिलित करते हैं , और फिर SqlBulkCopyइसे हमारे डेटाबेस में सम्मिलित करने के लिए उपयोग करते हैं ।

कभी-कभी (विशेषकर जब स्रोत डेटाबेस में varbinaryऑब्जेक्ट्स के रूप में चित्र होते हैं), तो यह प्रक्रिया वास्तव में सर्वर से ऐप में SQL ट्रांसफर के साथ बस फिर से दाईं ओर मुड़कर सर्वर पर वापस जा सकती है।

मुझे लगता है कि अगर हम SSIS पैकेज के रूप में कुछ रूपांतरणों को फिर से लिखते हैं तो यह चीजों को गति दे सकता है। हालाँकि, सबसे बड़ा पत्थर का टुकड़ा, जब मैं अपने बॉस के साथ, इनवेंटर्ड हियर फ़ैशन में नहीं होता , तो पीछे धकेल देता है और कहता है कि "क्या होगा अगर Microsoft SSIS के लिए समर्थन करता है? हमारे पास यह सब अप्रचलित कोड होगा और हम खराब हो जाएंगे।"

यह पहली बार नहीं है कि मैंने "क्या किया अगर वे उस सुविधा को हटा दें ..."? मेरे बॉस का जवाब। मेरे पास पुराने तरीके को बदलने के लिए समय नहीं है, स्वयं को SSIS सिखाएं, और लाभों को प्रदर्शित / परीक्षण करने के लिए यह नया तरीका भी लिखें। हममें से किसी ने भी SSIS का उपयोग नहीं किया है, इसलिए ऐसी अवधि होगी जहां हम करेंगे सीखना है कि इसका उपयोग कैसे करना है)।

इस परिस्थिति में मुझे क्या करना चाहिए? नई तकनीक पर जोर देना बंद करो? तब तक प्रतीक्षा करें जब तक वह विभाग नहीं छोड़ता (मैं उसके बाद विभाग का दूसरा सबसे वरिष्ठ व्यक्ति हूं, लेकिन इससे पहले कि वह इस्तीफा दे / सेवानिवृत्त हो सकता है)? 3rd पार्टी टूल्स से डरने के लिए उसे पाने का एक नया तरीका खोजें?


3
आपको NotInventedHere पर c2 चर्चा उपयोगी हो सकती है।

15
व्यावसायिक दृष्टिकोण से मेरा पहला प्रश्न है: Is it broken?- यह एक बूलियन प्रश्न है। "इसमें सुधार किया जा सकता था।" "नहीं" के बराबर है।
जोएल एथरटन

39
यकीन नहीं होता कि यह NIH है। मुझे लगता है कि आपके बॉस को एक वैध चिंता है, यह देखते हुए कि कैसे माइक्रोसॉफ्ट ने प्रौद्योगिकी के लिए समर्थन छोड़ने के लिए काफी रिकॉर्ड हासिल किया है जो डेवलपर्स के साथ गंभीर सॉफ्टवेयर का निर्माण कर रहे थे ...
मेसन व्हीलर

1
@JoelEtherton पूरी तरह से नहीं। प्रदर्शन एक बूलियन नहीं है, और धीमेपन के आधार पर अंतिम उपयोगकर्ताओं को प्रभावित कर सकता है। यह (भाग में) एक प्रदर्शन प्रश्न है।
इजाकाटा

9
@MasonWheeler अगर आप इस तरह से सोच रहे हैं, तो सब कुछ वास्तव में सिर्फ C या असेंबली में लिखा जाना चाहिए। मेरा मतलब है, क्या होगा अगर Microsoft ASP.Net के लिए समर्थन छोड़ देता है !?
अर्लज़

जवाबों:


110

मैं एक प्रबंधकीय दृष्टिकोण से इस पर एक दरार लूंगा, लेकिन ध्यान रखें कि मुझे पता है कि मेरे पास सभी विवरण नहीं हैं। मैं संक्षेप में बताऊंगा कि मैं क्या देखता हूं:

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

इस दृष्टिकोण से, मैं देख रहा हूँ कि कंपनी की ओर से पैसे का एक बड़ा परिव्यय एक प्रक्रिया को बेहतर बनाने के लिए है जो टूटा नहीं है । एक तकनीकी दृष्टिकोण से मैं अपील देख सकता हूं, लेकिन जब आप इसके ठीक नीचे हो जाते हैं, तो यह इस बदलाव को बनाने के लिए व्यावसायिक समझदारी नहीं है। यदि आपके पास इस प्रक्रिया में बड़े पैमाने पर सुधार दिखाने के लिए SSIS और बेंचमार्क के साथ प्रलेखित अनुभव के साथ स्टाफ था (ध्यान रखें, बड़े पैमाने पर सुधार $ $ $ के बराबर होना चाहिए), तो परिणाम थोड़ा अलग हो सकता है। हालांकि यह अब खड़ा है, हालांकि, मुझे प्रबंधन से सहमत होना होगा (कहीं एक पेड़ सिर्फ मर गया)।

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

जैसा कि बेवकूफ लगता है, कभी-कभी "सबसे अच्छा" तरीका सबसे अच्छा तरीका नहीं होता है।

संपादित करें: प्रश्न के कुछ अपडेट के जवाब में, मैं अपने उत्तर में थोड़ा संशोधन करूंगा।

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


इस तर्क के साथ मुझे एक समस्या यह दिखती है कि डेवलपर्स की खुशी दांव पर है। यह इन व्यावसायिक निर्णयों में कभी भी तथ्य नहीं है। ऐसा लगता है कि यह हमेशा अनुभवी देवों को खोने के बाद व्यापार को समाप्त करता है।
जो फिलिप्स

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

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

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

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

37

ब्रेकिंग थिंग्स इज ए स्किल

मैंने बहुत से स्थानों पर काम किया है, जिन्होंने "अगर यह टूटा नहीं है" तो इस बात को तर्क दिया कि वे नवाचार करने में विफल रहते हैं, और जब वे अंततः सब कुछ बदलकर प्रतिक्रिया करने के लिए उन्हें नया करने के लिए मजबूर होते हैं । केवल इसलिए कि उनके पास चीजों को तोड़ने के अनुभव की कमी है

चीजों को तोड़ने के लिए परिपक्वता, कौशल और अनुभव होता है।

विकास टीमें जो हमेशा इसे सुरक्षित खेलती हैं, एक प्रतियोगी के लिए सबसे आसान है। केवल वे टीमें जो विफल रही हैं, गलतियाँ की हैं, और टूटी हुई चीजें सही मायने में ईमानदार जोखिम आकलन करने में सक्षम हैं।

स्थिति को बनाए रखना

हालांकि यह सही है कि मौजूदा प्रणाली मौजूदा व्यावसायिक आवश्यकताओं को पूरा करती है। यह उन आवश्यकताओं के लिए भविष्य के अप्रत्याशित परिवर्तनों के लिए सही नहीं है। जैसा कि पुरानी कहावत है "भाग्य तैयार पसंद करता है"।

इस प्रश्न का SQL या प्रदर्शन से कोई लेना-देना नहीं है। यह सवाल पूछने के बारे में है "क्या कोई बेहतर तरीका है?" और एक विकल्प की कोशिश करने से डरो नहीं।

आपका बॉस स्टेटस क्वो रखने के एक मामले से ग्रस्त है ।

मायन

कुछ भी सही मायने में पूरी तरह से काम नहीं कर रहा है।

मायाओं ने पहाड़ों के किनारे अपना भोजन उगाना जारी रखा। जब तक सभी पोषक तत्व धुल नहीं गए थे, और उनके पास अपने लोगों को खिलाने का कोई तरीका नहीं था। वे बहुत देर तक उसी तरह से काम करते रहे।

यह मानते हुए कि आपके पास एक समस्या को ठीक करने का समय होगा जब समस्या स्वयं प्रस्तुत करती है एक गलती है।

यहाँ छवि विवरण दर्ज करें

क्या करें?

आपका बॉस कंडीशनिंग के एक मामले से पीड़ित है। जो लोग यथास्थिति को स्वीकार करते हैं वे अक्सर ऐसा करते हैं, क्योंकि उनके पास कठिन निर्णय लेने की क्षमता की कमी होती है। जब एक चुनौती का सामना करना पड़ता है, तो वे उस विकल्प को चुनने के लिए तैयार होंगे जो वे परिचित हैं।

उसके लिए डर एक बड़ी प्रेरणा है। अज्ञात या बदलती परिस्थितियों के डर से उसके दृष्टिकोण को हिला देता है कि यथास्थिति क्या है। वह जितनी जल्दी हो सके शर्तों को वापस करने और वापस करने की कोशिश करेगा।

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

बेबी स्टेप्स लें

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

इसमें समय लगता है

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

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


22

मुझे लगता है कि अगर हम SSIS पैकेज के रूप में कुछ रूपांतरणों को फिर से लिखते हैं तो यह चीजों को गति दे सकता है। हालाँकि, सबसे बड़ा पत्थर का टुकड़ा जो मैं चला रहा हूँ, जब मेरे बॉस ने Not Invented Here फैशन में, पीछे धकेल दिया और कहा "क्या होगा यदि Microsoft SSIS के लिए समर्थन छोड़ देता है? हमारे पास यह सब अप्रचलित कोड होगा और हम खराब हो जाएंगे।"

मेरी राय में, SSIS के बारे में संदेह वैध है।

  • अनुभवी डेवलपर्स ब्लैक बॉक्स से नफरत करते हैं, और बहुत सारा जादू है जो एसएसआईएस पैकेज के अंदर होता है।
  • SSIS पैकेज के लिए सोर्स कंट्रोल सपोर्ट की कमी है। यदि आपके dtsx संकुल पर्याप्त रूप से मॉड्यूलर नहीं हैं, तो SSIS dtsx फ़ाइलों को बनाना और विलय करना एक बुरा सपना हो सकता है
    • इसके विपरीत, C # कंसोल एप्लिकेशन बहुत पारदर्शी हैं। आप हमेशा पता लगा सकते हैं कि क्या गलत हो रहा है।

इसके अलावा, इस बात पर विचार करें कि आपका बॉस हुक पर है अगर कुछ भी गलत होता है।

  • इसलिए, वह इस मामले पर ओवरराइडिंग / केवल राय रखने का हकदार है।

मेरे पास पुराने तरीके को बदलने के लिए समय नहीं है, स्वयं को SSIS सिखाएं, और लाभों को प्रदर्शित / परीक्षण करने के लिए यह नया तरीका भी लिखें। हममें से किसी ने भी SSIS का उपयोग नहीं किया है, इसलिए ऐसी अवधि होगी जहां हम करेंगे सीखना है कि इसका उपयोग कैसे करना है)।

इस परिस्थिति में मुझे क्या करना चाहिए? नई तकनीक पर जोर देना बंद करो? तब तक प्रतीक्षा करें जब तक वह विभाग नहीं छोड़ता (मैं उसके बाद विभाग का दूसरा सबसे वरिष्ठ व्यक्ति हूं, लेकिन इससे पहले कि वह इस्तीफा दे / सेवानिवृत्त हो सकता है)? 3rd पार्टी टूल्स से डरने के लिए उसे पाने का एक नया तरीका खोजें?

मेरा सुझाव है कि आप SSIS को अच्छी तरह से सीखें ताकि आप इसके लाभों को प्रदर्शित कर सकें

और अगर, आपके स्व-अध्ययन के बाद, आप पाते हैं कि SSIS अधिक "पारंपरिक" दृष्टिकोण पर महत्वपूर्ण लाभ प्रदान करता है, और आप अभी भी अपने बॉस को पाठ्यक्रम बदलने के लिए नहीं मना सकते हैं, तो मैं आपको एक अलग नौकरी खोजने की सलाह देता हूं जिसमें आप कर सकते हैं SSIS का उपयोग करें।


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

11

प्रतिक्रिया जो आप लगभग हमेशा सबसे प्रबंधक-प्रकारों से जा रहे हैं, वह कुछ इस प्रकार है:

"यह इसके लायक नहीं है, यह अब काम करता है, और इसे बदलने के लिए समय लगेगा।"

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

आपको यह निर्धारित करने की आवश्यकता है कि क्या नहीं आविष्कार किया गया है वास्तव में यह तय करने से पहले हो रहा है कि क्या करना है। आंतरिक तकनीक को एक कारण के लिए लिखा जा सकता है ।

संकेत है कि टेक एक कारण के लिए फिर से लिखा है:

  • आपके द्वारा बेची जा रही तकनीक भी उत्पाद है । यदि आप एक डेटाबेस विक्रेता हैं, तो MySQL कोड का उपयोग करते हुए, चाहे वह कितना भी समय बचा ले, कई कारणों से एक खतरनाक विचार है।
  • आंतरिक तकनीक अच्छी तरह से बनाए रखी जाती है और प्रभावी रूप से ऑफ-द-शेल्फ समाधान की कमियों को संबोधित करती है, जबकि अभी भी तुलनीय आधार कार्यक्षमता प्रदान करती है।
  • तकनीक संपूर्ण विकास टीम की उत्पादकता में सुधार करती है , और नए डेवलपर्स आसानी से बेच दिए जाते हैं कि यह क्यों उपयोग में है।
  • ऐसे अन्य उदाहरण हैं जहां कंपनी ने अन्य बाहरी तकनीकों को सफलतापूर्वक अपनाया है
  • यदि ओटीएस समाधान बंद या टूट गया, तो आपका व्यवसाय तुरंत और गंभीरता से प्रभावित होगा।
  • व्यवसाय इतना बड़ा है कि इसमें कम लागत पर उच्च-गुणवत्ता वाले उपकरण लिखने के संसाधन हैं (उदाहरण के लिए, Google एक डेटाबेस लिखने में सक्षम हो सकता है जिसकी लागत $ 1000 / सीट MS SQL लाइसेंस से कम हो)

दूसरे शब्दों में, टीम पहले से ही हल की गई समस्याओं को फिर से हल करने की कमियों को समझती है, लेकिन विवेकपूर्ण रूप से अपवाद हैं जहां यह एक व्यापारिक दृष्टिकोण से समझ में आता है।

"यहाँ आविष्कार नहीं" के संकेत:

  • ऐसा लगता है कि सब कुछ आंतरिक है , और हर चीज के लिए बहाने हैं: "उह, यह बहुत धीमा था", "उह, यह माइक्रोसॉफ्ट है, हम माइक्रोसॉफ्ट से नफरत करते हैं", "उह, यह वास्तव में उपयोग करने में कठिन लगता है", आदि।
  • ऐसे मामलों के लिए जहां बाहरी तकनीक का उपयोग किया जा रहा है, आप सुनते हैं "हाँ, अच्छी तरह से यह बदबू आ रही है और हम अपने स्वयं के लेखन पर योजना बनाते हैं "।
  • उन घटकों के मालिकों के पास अन्य काम नहीं होते हैं जो वे काम करने में सक्षम होते हैं।
  • आप अधिकांश नए डेवलपर्स को व्यापक रूप से स्वीकार किए गए कौशल-सेट के साथ आते हैं, लेकिन आंतरिक प्रशिक्षण के लिए उन्हें रैंप-अप करने में काफी समय लगता है
  • सावधानीपूर्वक विश्लेषण के बाद, यह स्पष्ट हो जाता है कि ओटीएस समाधान से एक कस्टम या अन्य ओटीएस समाधान में स्विच करना "क्या होगा अगर बंद कर दिया गया है!" परिदृश्य का कम से कम व्यावसायिक प्रभाव होगा । उदाहरण के लिए, यदि String.Join().NET फ्रेमवर्क से हटा दिया गया था , तो एक कस्टम StringJoin()विधि को फिर से लागू करना तुच्छ होगा।

दूसरे शब्दों में, NIH उन मामलों में उद्देश्यपूर्ण और यथार्थवादी बने रहने में विफल रहने का पैटर्न है, जहां किसी के स्वयं के कोड के बजाय बाहरी तकनीक का उपयोग किया जा रहा है।

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

समझें कि आपके अनुभव को देखते हुए, वे आपके नंबरों से सहमत नहीं हो सकते हैं, लेकिन परवाह किए बिना, उन्हें कम से कम आपको सुनना चाहिए। सम्मान पाने में समय लग सकता है।

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

(साइड नोट: ज्यादातर कंपनियों में, हमेशा NIH का एक तत्व होता है, लेकिन यह एक सहनीय स्तर पर होता है, और जब तक वे नियमित रूप से अपने कोड और प्रथाओं की समीक्षा करते हैं। लंबे समय में हम सभी इसके लिए एक हद तक दोषी हैं, लेकिन यह कभी मुद्दा नहीं बनता।)


4

खैर, इसकी लागत / लाभ विश्लेषण के बारे में सब कुछ।

SSIS को फिर से लिखने से आपको क्या लाभ होगा? स्पीड? फर्क पड़ता है क्या? यदि इसकी एक प्रक्रिया जो एक जीयूआई में निष्पादित हो जाती है और हर किसी को समय बर्बाद करती है, तो हाँ, शायद इसे गति देने के लिए एक अच्छा विचार है, क्योंकि इसे बदलने में खर्च किए गए धन को अधिक खुश ग्राहक या आंतरिक कर्मचारी द्वारा अपना काम करने के बजाय वापस प्राप्त किया जाएगा। सॉफ्टवेयर की प्रतीक्षा कर रहा है। लेकिन अगर इसका एक रात का बैच 12 बजे शुरू होता है और यह 6 बजे के बजाय 1 बजे खत्म हो जाएगा ... तो कोई बात नहीं है। हाँ इसके 6 समय तेजी से लेकिन किसी को भी फर्क महसूस नहीं होगा।

और आपके बॉस के पास एक अच्छी बात है। Microsoft अपनी कुछ तकनीकों का परित्याग करते हैं। VB6, Linq-to-SQL, ASP क्लासिक, COM + ... यह किसी भी गैर-ओपन सोर्स सॉफ़्टवेयर (और ओपन-सोर्स सॉफ़्टवेयर के साथ एक जोखिम है जो आपके संगठन को अपडेट की कमी के मामले में बनाए रखने के लिए बहुत बड़ा होगा)। यदि आपके आवेदन के लिए इसका केंद्र है, तो आपको इस पर एक सख्त नियंत्रण होना चाहिए।

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


2
VB6 "कैसे छोड़ दिया गया"? यह 10 वर्षों के लिए समर्थित था, जिनमें से कई अगली भाषा के लिए अपग्रेड पथ उपलब्ध थे। क्या विंडोज 3.1 को भी छोड़ दिया?
क्रिस पिटमैन

1
@ChrisPitman - एक बता सकता है कि VB6 एप्लिकेशन अभी भी विंडोज 8 में काम करते हैं। अब अगर हम एक डेटाबेस को एक्सेस करने की कोशिश कर रहे विंडोज 8 64-बिट पर VB6 एप्लिकेशन के बारे में बात कर रहे हैं तो आपको अन्य कारणों से समस्या हो सकती है।
रामहुंड

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

3

एक POC (प्रूफ ऑफ कॉन्सेप्ट) विकसित करें और फिर इसे अपने श्रेष्ठ में प्रदर्शित करें। पीओसी आपको उस तकनीक से कोई वास्तविक लाभ निर्धारित करने में मदद करनी चाहिए जिसे आप प्रस्तावित कर रहे हैं। तब आप और आपके बेहतर तकनीक के बारे में बात कर सकते हैं और इसे लागू करने के लिए पेशेवरों और विपक्षों को विकसित कर सकते हैं।

POC विकसित करने के लिए आपको सामान्य कार्य समय के बाहर कुछ अतिरिक्त समय बिताना होगा।

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

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


1
उसे POC करने के लिए अपने बॉस से अनुमति लेनी चाहिए, और ऐसा लगता है जैसे उसे नहीं मिलेगा। यदि यह अनुमति के बिना करता है, तो वह यह बताने की कोशिश कर रहा है कि यदि पीओसी स्वीकार नहीं करता है तो उसने अपना समय कैसे बिताया।
अभिकेन्द्र

@ मैथ्यू - अच्छा बिंदु, शायद एक सप्ताहांत हैक-ए-थॉन अगर वह बिना अनुमोदन के ऐसा करने के लिए इच्छुक है।
जॉन रेन्नोर

1

अच्छा जवाब। यदि यह टूटा नहीं है, तो इसे ठीक न करें। मैं केवल जोड़ूंगा

  • हालांकि प्रदर्शन की चिंताएं वास्तव में सच हो सकती हैं, लेकिन यह शब्द "हो सकता है" एक लाल झंडा है। मैं पहले प्रदर्शन निदान करूंगा, इसलिए मेरे पास इस बात का सबूत होगा कि किसी भी संसाधन को संबोधित करने से पहले प्रदर्शन समस्या क्या थी।

  • Microsoft से नवीनतम "समाधान" पर विचार करते समय, किसी को यह विचार करना चाहिए कि एमएस को एक बार टैप करके लेकिन बाद में हटाए गए और फिर डी-समर्थित द्वारा बहुत से लोगों को जला दिया गया है। अगर आप चाहते हैं कि सॉफ्टवेयर बिना बड़ी रिकॉडिंग के 10 या 20 साल तक चले, तो आपको इससे सावधान रहना चाहिए। हमारी कंपनी उस तरह से बुरी तरह आहत हुई है।


1

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


1

आप अपने बॉस को इंगित कर सकते हैं कि वास्तव में, SSIS .NET फ्रेमवर्क की तुलना में एक पुरानी तकनीक की परत है, यदि आप SQL 7.0 के "डेटा परिवर्तन फ्रेमवर्क" के रूप में इसकी जड़ों में वापस जाते हैं।

जहां आपके बॉस के पास एक बिंदु हो सकता है कि एसएसआईएस माइक्रोसॉफ्ट स्क्ल सर्वर के मानक और उद्यम संस्करणों का एक हिस्सा है; आपके क्लाइंट के लिए परिवर्तन का यह एक बड़ा हिस्सा है, जब आपके आवेदन, एक छोटे व्यवसाय परिदृश्य में, उस मामले के लिए Sql Express (या MySQL) के साथ पूरी तरह से ठीक हो सकता है, जो ADO.NET के साथ काम करता है, लेकिन नहीं कर सकता SSIS एकीकरण का उपयोग करें)।

अब, मुझे पूरी तरह से स्पष्ट होने दें; IMO, NIH सॉफ्टवेयर डेवलपमेंट हाउस के लिए लगभग अच्छी बात नहीं है। यह आपको बहुत शक्तिशाली उपकरणों और सेवाओं से बाहर कर देता है। यह अपने चेहरे पर पाखंडी भी है; क्या आपकी कंपनी ने Visual Studio लिखा है? .NET फ्रेमवर्क के बारे में कैसे? एस क्यू एल सर्वर? खिड़कियाँ? नहीं। आप अपने सॉफ़्टवेयर का निर्माण उन उपकरणों और प्लेटफार्मों के ऊपर करते हैं जो आपके पास पहले से हैं (और इसलिए अपने ग्राहक करते हैं)। इसलिए, यदि आप एक उपकरण देखते हैं जो सामान्य स्वीकृति प्राप्त कर रहा है, और जो आपके मुख्य व्यवसाय को करने में उपयोगी हो सकता है, तो आप इसे अपनाते हैं, और आप जोखिम के साथ जीना सीखते हैं जिसे आपको नवीनतम के साथ बनाए रखने के लिए अपने कार्यान्वयन को बनाए रखना होगा। उन उपकरणों के संस्करण, या यहां तक ​​कि उन्हें बदल सकते हैं। मैं शर्त लगाता हूं कि आपके बॉस ने सबसे पहले विंडोज 95/98 या थैरेआउट पर चलने के लिए सॉफ्टवेयर विकसित किया है (यदि लंबे समय तक नहींइससे पहले, जैसे 3.0 / 3.1)। यदि ऐसा है, तो उसे विंडोज़ वर्कस्टेशन OS के आधा दर्जन संस्करण दिखाई देते हैं और आते हैं, और नए प्लेटफॉर्म पर चलने के लिए उसे अपने सॉफ़्टवेयर को अपडेट करना पड़ता है, और वह आधिकारिक तौर पर XP के साथ एक और सामना कर रहा है। जबकि वह शिकायत कर सकता है, बस व्यवसाय करने की लागत है।

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


0

मेरे पास पुराने तरीके को बदलने के लिए समय नहीं है, स्वयं को SSIS सिखाएं, और लाभों को प्रदर्शित / परीक्षण करने के लिए यह नया तरीका भी लिखें। हममें से किसी ने भी SSIS का उपयोग नहीं किया है, इसलिए ऐसी अवधि होगी जहां हम करेंगे सीखना है कि इसका उपयोग कैसे करना है)।

यह समस्या की तरह है, है ना? आप अपने विचार पर अन्य लोगों को अपनी उत्पादकता को जोखिम में डालने के लिए कह रहे हैं, और आप इसे इसके लायक दिखाने के लिए एक अंग पर बाहर जाने के लिए तैयार नहीं हैं। तकनीकी नेतृत्व को अपनी प्रतिष्ठा को खतरे में डालने के लिए या आपके खाली समय को दिखाने की आवश्यकता है कि आपके विचार होने लायक हैं।


-1

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

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


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

-1

जबकि "जो टूटा नहीं है उसे ठीक नहीं करना" योग्यता है और मैं स्वीकृत उत्तर से असहमत हूं।

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

जब तक यह कंपनी की मुख्य योग्यता नहीं है, सी # में डेटा परिवर्तनों को लिखने और बनाए रखने के लिए बहुत कम कारण है। होमग्रोन समाधान धीमा होगा, गलतियों (यानी भ्रष्ट डेटा) होगा, किनारे के मामले होंगे, ईटीएल कक्षाओं के बीच थोड़ा पुन: उपयोग होगा, और यह नाजुक होगा। ईमानदारी से, क्या डेवलपर अपने # लेखन और ईटीएल को सी # में बनाए रखना चाहता है? मेंने यह किया है। यह बकवास का भार है। यह रचनात्मक कार्य से उतना ही दूर है जितना कि कोई व्यक्ति प्राप्त कर सकता है।

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

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


-3

मैंने SSIS को पहले सरल कार्य करने की कोशिश की है।

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

साइड की समस्या: तो, गति बढ़ाने के लिए, मेरा सुझाव है कि आपकी छवि के लिए लेनदेन का आकार कम करें। कहते हैं, हर 800 के बजाय 5000 रेकॉर्डर। यह उस लेनदेन का समर्थन करने के लिए आवश्यक I / O के आकार को कम कर सकता है।


1
5000 की जगह 800 भेजना चीजों को बदतर बना देगा; आपको अभी भी वास्तविक डेटा की सटीक समान मात्रा भेजनी है, लेकिन अब आपके पास अधिक नेटवर्क कॉल हैं, जिसका अर्थ है अधिक पैकेट हेडर, इत्यादि
एंडी

I / O सामान्य रूप से नेटवर्क की तुलना में बहुत अधिक खर्च करता है। यहां तक ​​कि बल्क कॉपी का उपयोग करते समय, वहाँ चीजें हैं जो लॉग हो जाती हैं। एक ही समय में बहुत सारे I / O cpu को कम उपयोग में लाएंगे और I / O होने तक सर्वर को लटकाएंगे। बेशक, यह निर्भर करता है कि उन डेटाबेस सर्वर का I / O सबसिस्टम कितना शक्तिशाली है।
फैब्रिकियो आराजू

अपनी परीक्षा स्वयं करें; आप देखेंगे कि प्रत्येक स्टेटमेंट को अलग-अलग भेजने से बैचिंग तेज़ है।
एंडी

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