आईटी वर्ल्ड से उत्सुक विकृतियाँ

डेली डब्ल्यूटीएफ 14 वर्षों से आईटी दुनिया से अजीब, जंगली और / या दुखद कहानियों का संग्रह कर रहा है। मैंने कई कहानियों का अनुवाद किया जो मुझे दिलचस्प लगीं। सभी कंपनी के नाम और नाम बदल दिए गए हैं।

3,000 मील तक काम करने के लिए

हमारे लेखक स्नोफ़ल के व्यक्तिगत अनुभव से एक सच्ची कहानी। [मूल रूप]

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

कुछ महीने बाद, एक और समान अनुबंध उत्पन्न हुआ। कंपनी ने फिर से एक हजार लोगों को यह दिखाने के लिए काम पर रखा कि उसके पास स्टाफ है। कुछ महीने बाद, अनुबंध फिर से दूसरे ठेकेदार को स्थानांतरित कर दिया गया, और कंपनी ने फिर से पूरे हजार को खारिज कर दिया।


दो वर्षों के दौरान, यह कई बार दोहराया गया है।

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

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

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

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

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

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

खैर, वे सभी पश्चिमी तट पर पहुंचे, होटलों में जाँच की और कार्यालय चले गए।

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

लेकिन रुकिए, उनके पास परिवार के साथ इस पर चर्चा करने का अवसर नहीं है! माता-पिता में से एक के समय का 90% का अभाव बच्चों को कैसे प्रभावित करेगा? क्या वे दो साल तक होटल और एयरपोर्ट में रहना चाहते हैं? नर्क ने कैलिफोर्निया में स्थानीय स्तर पर कर्मचारियों को नौकरी क्यों नहीं दी, लेकिन न्यू जर्सी में?

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

आप यह नहीं कह सकते कि प्रबंधकों के लिए बाकी का काम कंपनी के लिए पीड़ितों की आवश्यकता पर रगड़ा गया था, और डेवलपर्स सोच रहे थे: "व्हाट द हेल?" गुरुवार की शाम अंतहीन कॉल घर के साथ व्यस्त था। शुक्रवार की सुबह, सभी कर्मचारी घर वापस जाने के लिए हवाई अड्डे की ओर रवाना हुए।

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

नतीजतन, ठेकेदार के साथ अनुबंध समाप्त कर दिया गया था, और नए को बदलने के लिए काम पर रखा गया था।

असफलता का मामला

[मूल रूप]


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

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

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

इनबॉक्स में पहले से ही मेल था: नए कर्मचारियों के लिए जानकारी के साथ कुछ स्वागत पत्र, साथ ही साथ उनके प्रबंधक का पहला कार्य। कम से कम कहने के लिए, कार्यों को असाइन करने की दक्षता से, उन्होंने अपने नए नेता से एक पत्र खोला।

पहला अक्षर कुछ इस तरह था:

नमस्ते सेबस्टियन, हमारे पूरी तरह से सम्मानित काम के माहौल में आपका स्वागत है। इसमें सब कुछ सही ढंग से किया गया है। प्रोजेक्ट दस्तावेज़ बनाते समय, आप बोन-वर्ड (आईबीएम के वेब-आधारित दस्तावेज़ अनुप्रयोग) के साथ काम करेंगे। अपने काम को अक्सर बचाने के लिए याद रखें! यदि बोन-वर्ड क्रैश हो जाता है, तो आपको इसे पुनः आरंभ करने के लिए आईटी विभाग को एक पत्र लिखना होगा।

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

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

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

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

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

"अगर उन्हें छह पृष्ठों की जरूरत है, तो उन्हें छह पृष्ठ मिलेंगे," सेबस्टियन ने सोचा।

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

अगली सुबह, ठीक 9:00 बजे, सेबेस्टियन अपने प्रबंधक के कार्यालय में था, कंपनी के अध्यक्ष से परियोजना के पहले सत्यापन का इंतजार कर रहा था, जिसने फोन करके बुलाया। सेबेस्टियन ने सीधे राष्ट्रपति के साथ बातचीत में असहज महसूस किया, यह देखते हुए कि कंपनी में साठ कर्मचारी थे, लेकिन उन्हें इसे सहना पड़ा।

"मैंने अनुरोध के अनुसार, और सही मात्रा में किया। सबसे अधिक संभावना है, यह सिर्फ एक औपचारिकता है, जिसके बाद मुझे काम मिल सकता है। ”

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

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

"तो ठीक है," उसने खाली कार्यालय में ज़ोर से कहा। "इन पुस्तकालयों पर एक नज़र डालें।"

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

"क्या मैं अपना दिमाग खो रहा हूं?" सेबेस्टियन ने खुद से पूछा कि कार ने तीसरी बार कब रिबूट किया। "शायद कोड स्व-दस्तावेजीकरण है ..."

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

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

राष्ट्रपति ने स्पष्ट रूप से सच्चाई स्वीकार करने से इनकार कर दिया। उन्होंने दावा किया कि यह सेबस्टियन की गलती थी, क्योंकि उन्होंने उत्कृष्ट C ++ पुस्तकालयों का उपयोग नहीं किया था।

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

किसी कारण से, उन्हें संदेह था कि वह कंपनी को याद करेंगे।

आप इस तरह की स्वास्थ्य देखभाल से बीमार हो सकते हैं।

[मूल रूप]

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

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

सर्वश्रेष्ठ की उम्मीद नहीं , काम को आसान बनाने के लिए, हमने XML रैपर लाइब्रेरी के शीर्ष पर लिखा।

दुर्भाग्य से, वे कार्य के साथ सामना नहीं किया।


हेल्थकेयर उद्योग में, कुछ कोपेन-सोर्स लोगों ने (H) ealthcare (API) प्रोजेक्ट, या HAPI बनाया है , जो मूल रूप से हेल्थकेयर इंडस्ट्री के लिए ऑब्जेक्ट ओरिएंटेड टेक्स्ट मैसेजिंग पार्सर है। दुर्भाग्य से, वे "बंद करने के लिए पता नहीं है" सिंड्रोम से पीड़ित लग रहे थे।

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

यह लगभग 15 हजार मेथड कॉल्स वाला एपीआई है! ये डेवलपर्स क्या सोच रहे थे?

उदाहरण के लिए, वर्ग: EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO में शून्य या अधिक उत्पाद सेवा अनुभाग हो सकते हैं। तो मैं तुरंत किसी प्रकार की सरणी या सूची के बारे में सोचना शुरू कर देता हूं। इसलिए, इस तरह से कुछ के बजाय:

  EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO जानकारी = ...;
     सूची <EHC_E15_PRODUCT_SERVICE_SECTION> prodServices = info.getProductServices ();
     // iterate

... हमें इसमें से एक करने की आवश्यकता है:

  // सबस्ट्रक्चर प्राप्त करें
     EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO जानकारी = ...;
	
     // अंतर्निर्मित उत्पाद-सेवा प्राप्त करें

     // ... अगर हमें पता है कि उसके पास केवल एक संदेश है:
     EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION ();
	
     // ... अगर हमें पता नहीं है कि कितने होंगे:
     int n = infos.getPRODUCT_SERVICE_SECTIONReps ();
     for (int i = 0; मैं <n; i ++) {
         EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION (i);
         // इस का उपयोग करें
     }

     // ... या आप बस उन्हें और पुनरावृति पकड़ सकते हैं
     सूची <EHC_E15_PRODUCT_SERVICE_SECTION> allSvcs = info.getPRODUCT_SERVICE_SECTIONAll (); 

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

आप कह सकते हैं: "आओ, सब कुछ बुरा नहीं है" ; बस आप की जरूरत है क्या उपयोग करें। लेकिन फिर आपको पता चलता है कि इनमें से कुछ डेटा संरचनाएं दस या अधिक स्तरों पर एम्बेडेड हैं, प्रत्येक में दर्जनों उपग्रहों और / या फ़ील्ड हैं, और उन सभी में कई एक्सेस विधियां हैं। इसके अलावा, उन सभी के पास वास्तव में लंबे नाम हैं।और फिर आपको पता चलता है कि HAPI डेवलपर्स टाइपिंग से थक गए थे और संक्षिप्त नाम के लिए LA1, ILT और PCR जैसी डेटा संरचनाओं का उपयोग करना शुरू कर दिया था।

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

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

उसके बाद, एक नए क्षेत्र को जोड़ने में दस मिनट से अधिक नहीं लगे।