नलसाजी सिंड्रोम: परीक्षण के लिए विरासत कोड नियम

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

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

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

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

सशक्‍त बुद्धि

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

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

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

क्या करें?

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

2. अनुभवहीन । कभी-कभी ऐसे बयान व्यक्ति के विषय क्षेत्र में खुद की योग्यता की कमी का संकेत देते हैं: वह परियोजना के इतिहास को नहीं जानता है, और, उदाहरण के लिए, कि यह "भयानक" (उनकी राय में) निर्माण विकास प्रक्रिया में बाहरी बगों पर ठोकर खाने वाले लोगों का परिणाम था। सिस्टम और उनके चारों ओर जाना शुरू कर दिया। नतीजतन, इन बगों के लिए परस्पर पैच और बैसाखी से एक प्रकार की स्पेगेटी थी। बाहर से मनुष्यों में सभी मौजूदा नुकसानों का ऐसा ज्ञान सिद्धांत रूप में नहीं हो सकता है।

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

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

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

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

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

एक बड़ी परियोजना के दीर्घकालिक कोड को न छूना बेहतर क्यों है

आप अपने प्रोजेक्ट को मार भी सकते हैं
गारंटी कहां है कि आप फिर से कुछ लिखेंगे और यह सही तरीके से काम करेगा? आखिरकार, यह अभी तक नहीं है। व्यावसायिक दृष्टिकोण से, आपको वर्तमान समय में रहने और राजस्व सृजन की निरंतरता सुनिश्चित करने की आवश्यकता है।

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

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

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

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

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

क्या करें जब निर्णय को फिर से न करने का निर्णय स्पष्ट है, और व्यक्ति "एक विचार से जल रहा है"?

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

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

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

जब आपको अभी भी फिर से करना होगा

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

नलसाजी सिंड्रोम ने काम किया: रिमॉडलिंग चरण

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

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

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

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

या यह विकल्प: इंटरफ़ेस तय हो गया है, कार्यान्वयन किया जाता है, और फिर इंटरफ़ेस पुनरावृत्तियों को बदलना शुरू कर देता है।

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

एक निष्कर्ष के बजाय

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