प्रोग्रामर निर्माण उद्योग से क्या सीख सकते हैं? [बन्द है]

Question

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

सीखने (या सिखाने) के सर्वोत्तम तरीकों में से एक एनालॉग्स के विश्लेषण के माध्यम से हैं - निर्माण से अन्य एनालॉग्स को क्या खींचा जा सकता है? (पहले से ही सॉफ्टवेयर में आम उपयोग में है या नहीं)।

कृपया प्रोग्रामिंग अवधारणा कैसे निर्माण अवधारणा के समान है, इसके बारे में विवरण या अपना व्यक्तिगत अनुभव प्रदान करें।

^{[ विचार के लिए कला और मानविकी से ली गई प्रोग्रामिंग अवधारणाओं का श्रेय ]}

Comments

आपको लगता है कि छह व्यक्तिपरक दिशानिर्देशों में से कौन सा आपके प्रश्न को पूरा करता है?

@ मर्क मैं कोई भी ऐसा नहीं देखता हूं जो स्पष्ट रूप से नहीं मिलता है ।

— निकोल

@ उत्तर - उत्तर की सूचियों के लिए प्रश्न पूछना रचनात्मक नहीं है और साइट के दिशानिर्देशों को पूरा नहीं करता है।

— वाल्टर

@Walter, मुझे सिर्फ एक शब्द में दिलचस्पी नहीं है, मैं अवधारणाओं के विवरणों में दिलचस्पी रखता हूं और वे कैसे संबंधित हैं। मैं इस पर अधिक स्पष्ट होने के लिए प्रश्न को संपादित करूंगा।

— निकोल

@Walter, @Mark Trapp - मुझे एहसास हुआ कि सवाल यह नहीं था कि मुझे क्या चाहिए, इसलिए मैंने शब्दों की एक सूची प्राप्त करने से बचने के लिए प्रश्न को संशोधित किया।

— निकोल

Answer 1

यह वह जगह है जहाँ डिजाइन पैटर्न से आया है।

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

अब भी व्याख्यान के दौरान और सॉफ्टवेयर विकास और वास्तुकला पुस्तकों में निर्माण दुनिया और सॉफ्टवेयर विकास दुनिया के बीच समानताएं प्रचलित हैं।

कुछ उपमाएं और संदर्भ जो मैं सोच सकता हूं या याद कर सकता हूं:

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

(अगर ज्यादा दिमाग में आए तो मैं उन्हें जोड़ दूंगा।)

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

Comments

+1 महान जवाब। दिलचस्प है कि en.wikipedia.org/wiki/Design_pattern वास्तव में प्रोग्रामिंग और आर्किटेक्चर दोनों में अवधारणा के लिए एक साझा लेख है। मैं उन लोगों को खोजने के लिए प्यार करता हूँ!

— निकोल

मैं आपके उत्तर को समय पर समायोजित करना चाहता हूं और बजट हमेशा गलत होते हैं ।

— पॉल नाथन

@PaNNathan Done

— dukeofgaming

महान जवाब +1 यह भी उल्लेख करने के लिए कि कुछ लोग सादृश्य को तोड़ने के लिए मानते हैं।

— किड्जीज

@dukeofgaming कृपया फ़ॉर्मेटिंग के दुरुपयोग से बचें। यदि सब कुछ पर जोर दिया जाता है, तो कुछ भी जोर नहीं दिया जाता है।

Answer 2

हमने निर्माण उद्योग से सॉफ्टवेयर विकास के इतिहास में बहुत सारे शब्द और विचार लिए हैं, और वास्तव में हमें शायद बहुतों के लिए लिया गया है, और मुझे नहीं लगता कि लेने के लिए कुछ बचा है।

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

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

सॉफ्टवेयर निर्माण जैसा नहीं है। और यही कारण है कि पूरे सॉफ्टवेयर उद्योग ने नवजात शिशुओं की शुरुआत में एक समय पर बदल दिया और चलने वाली परियोजनाओं की पूरी "झरना" प्रक्रिया को केवल दो साल में चुस्त प्रक्रियाओं के साथ बदल दिया गया।

जैसा कि शब्दों में कहा गया है कि निर्माण से बहुत कुछ लिया गया है, सही और गलत तरीके से।

फ्रेमवर्क सबसे स्पष्ट है जो पहले से नहीं लिया गया है। और पाइप हैं ।

Comments

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

— निकोल

@ रेनेसिस: हाँ, लेकिन अब कैट 5 को चीर कर उसकी जगह ठगना, जबकि एक साथ खिड़कियों को दीवारों में बनाना और जहाँ पर खिड़की थी वहाँ पर फायरप्लेस लगाना और फर्श को स्विमिंगपूल बनाना। आप सॉफ्टवेयर के साथ ऐसा कर सकते हैं।

— लेन्नर्ट रेगेब्रॉन

मैं यह पर्याप्त + नहीं + कर सकता।

— कैफीक

Answer 3

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

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

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

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

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

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

अब ज्यादातर लोग मूर्ख नहीं हैं कि निर्माण की दुनिया में यह कोशिश करें, लेकिन यह सॉफ़्टवेयर की दुनिया में हर समय होता है, क्योंकि लोग इसे नहीं जानते हैं:

1. एक व्यक्ति जो वास्तव में अच्छा गार्डन शेड बनाने के लिए योग्य है, जरूरी नहीं कि वह घर बनाने के लिए योग्य हो।

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

3. बहुत सारे मामलों में, एक चरण से दूसरे चरण में अपग्रेड करने में बहुत सारे काम शामिल हैं जो पहले किए गए थे, जिससे यह अधिक महंगा हो जाता है, जैसा लगता है कि यह होना चाहिए।

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

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

Comments

+1 वाह यह एक बेहतरीन उपमा है। मैं बेशर्मी से इसे चोरी करने की योजना बना रहा हूं। :-)

— रेशनलगीक

Answer 4

मामले समाप्त काम और ट्रिम दिमाग में आते हैं।

यह विचार कि जब प्रमुख संरचनात्मक निर्णय पूरे होते हैं, तो कुछ सौंदर्य विकल्पों को समाप्त करना ठीक है।

Answer 5

एक पुरानी कहावत: दो बार मापें और एक बार काटें।

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

Comments

मैंने इसे काट दिया और इसे काट दिया और यह अभी भी बहुत छोटा है!

— MIA

Answer 6

निर्माण और प्रोग्रामिंग दोनों में सीमाएं मौजूद हैं ।

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

Answer 7

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

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

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

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

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

बेशक दोनों क्षेत्रों में, एक वास्तुकार कुछ आकर्षित कर सकता है जिसे लागू नहीं किया जा सकता है।

Comments

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

— स्कॉट व्हिटलॉक

Answer 8

मचान , "इमारतों और अन्य बड़ी संरचनाओं के निर्माण या मरम्मत में लोगों और सामग्री का समर्थन करने के लिए इस्तेमाल किया जाने वाला एक अस्थायी ढांचा।" ^{[विकिपीडिया से परिभाषा]}

यह अवधारणा काम करती है क्योंकि प्रोग्रामिंग में एक मचान तेजी से बनाया जा सकता है और वास्तविक संरचना होने तक अस्थायी कार्यक्षमता प्रदान करता है।

Answer 9

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

लेकिन मुझे नहीं लगता कि प्रोग्रामर या कंसल्टिंग एजेंसियों ने उन प्रथाओं से कुछ भी सीखा है।

Comments

नहीं? आपको लगता है कि यह स्वतंत्र आविष्कार था?

— बीटा

मैं व्यंग्यात्मक था, लेकिन वास्तव में, यहां तक ​​कि निर्माण कंपनियों को भी उस व्यवहार का आविष्कार करने की आवश्यकता नहीं थी। यदि आप मानव हैं, तो आप सक्षम हैं।

— बर्नार्ड डाय

Answer 10

कीड़े अंत में नरक के रूप में महंगा हो सकता है, या लोगों को भी मार सकता है?

Answer 11

किसी भी विषय की जटिल इंजीनियरिंग परियोजनाओं के लिए बुनियादी दिशानिर्देश हैं:

1. नियोजन, ब्लू-प्रिंट, डिजाइन इत्यादि का महत्व
2. अंतर्निहित गणित का महत्व
3. अन्य समान परियोजनाओं से विचारों / सीखने का पुन: उपयोग
4. किसी और के द्वारा तैयार किए गए बिल्डिंग ब्लॉक्स / घटकों का उपयोग करना
5. जीवन चक्र
   आदि में समस्याओं को बहुत जल्दी ठीक करना , आदि।

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

Answer 12

अधिक समय तक

लेकिन निर्माण उद्योग में, श्रमिकों को उनके ओवरटाइम का भुगतान मिलता है।

Comments

... वे यह भी नहीं जानते कि एक एरॉन कुर्सी क्या है।

— davidhaskins

Answer 13

मानकों, सम्मेलनों और पूर्व-निर्मित घटकों का उपयोग। आप इस तरह की समस्या में भाग लेने की संभावना नहीं है।

मुझे बाजार में ऐसा कुछ नहीं मिला, जो हमारे कस्टम निर्मित सॉकेट के अनुकूल हो।

Answer 14

जब आपके पास एक हथौड़ा है, तो सब कुछ एक नाखून की तरह दिखता है। :)

Answer 15

बार - बार मोच लगना

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