TDD [बंद] का उपयोग करने के लिए टीम के साथियों को कैसे मनाएं

Question

मैं अपनी टीम का एकमात्र व्यक्ति हूं जो TDD का उपयोग करता है। मैं इसका उपयोग करने के लिए उन्हें कैसे बनाऊं?

मुझे गुस्सा आ रहा है कि जब मैं खींचूंगा, तो किसी का कोड मेरे परीक्षण को तोड़ देगा और मैं वह हूं जिसे उन्हें ठीक करना है।

क्या गीथब, फोर्क और पुल अनुरोध का उपयोग करके इस समस्या को हल किया जाएगा, ताकि उन्हें खींचने से पहले परीक्षण पास करने की आवश्यकता हो?

मैं प्रोजेक्ट मैनेजर नहीं हूं और मैं उसे इसका इस्तेमाल करने के लिए राजी नहीं कर सकता।

Comments

"किसी का कोड मेरे परीक्षणों को तोड़ देगा" क्या आपने एक संभावना पर विचार किया है कि यह आपके डिजाइन को इंगित करता है और / या परीक्षण बहुत नाजुक हैं?

— gnat

बारीकी से संबंधित: प्रोग्रामर.स्टैकएक्सचेंज.

— com/questions/44145/…

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

— Jan_V

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

— Jan_V

इसके अलावा भी बहुत कुछ: programmers.stackexchange.com/q/141468/39178 ... और मैं अभी भी कुछ नए तर्क ढूंढ रहा हूं। समस्या यह है कि आप वास्तव में लोगों के दिमागों को बदल नहीं सकते हैं यदि वे बदलने के लिए खुले नहीं हैं या यदि उन्हें लगता है कि वे जो पहले से करते हैं वह उनके लिए काफी अच्छा है।

— रॉबिंस

Answer 1

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

जिस तरह से आप समस्या का वर्णन करते हैं, ऐसा लगता है कि यहाँ ऐसा नहीं है। देखो ...

... जब मैं खींचूंगा, तो किसी का कोड मेरे परीक्षण को तोड़ देगा और मैं वह हूं जिसे उन्हें ठीक करना है।

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

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

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

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

---

यह ध्यान देने योग्य है कि आपके द्वारा "प्रारंभिक" चरण में विकसित किए जाने वाले टेस्ट डिज़ाइन कौशल की सबसे अधिक आवश्यकता होगी, अगर (जब :) आप अंत में अपने साथियों को TDD का उपयोग करने के लिए मना लेंगे। इसके बारे में सोचो...

... क्या होगा जब परीक्षण संचालित विकास आपके अनुभवहीन सहयोगियों के लिए पेश किया जाता है?

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

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

Comments

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

— कीथ्स

Answer 2

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

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

हमने तब टीडीडी के कुछ बुनियादी सिद्धांतों पर चर्चा की, सभी ने भागीदारों को बदल दिया और एक ही काटा को दोहराया। हमने कोड को उत्पन्न करने पर जोर देने के लिए एक ही काटा दोहराया और इसके बजाय परीक्षण के मामलों और रेड / ग्रीन चक्र के नामकरण की प्रक्रिया पर लोगों को ध्यान केंद्रित किया।

फिर हमने काटा को फिर से दोहराया, लेकिन हर 10 मिनट में प्रत्येक समूह में एक व्यक्ति दूसरे समूह में चला जाता है, बल्कि उन तरल टीम के वातावरण का अनुकरण करता है जो हम अक्सर इन दिनों में पाते हैं।

अंतिम पुनरावृत्ति में, हम दोनों साझेदारों को हर 10 मिनट या अलग-अलग समूहों में बदलते थे। इससे पता चलता है कि टीडीडी के साथ, यहां तक ​​कि एक टीम से पूरी तरह से अलग एक को सौंपने की भी जरूरत नहीं है, बहुत दर्दनाक होने की जरूरत है, क्योंकि परियोजना को काम करने से केवल एक ही लाल / हरा चक्र होना चाहिए।

दिलचस्प बात यह थी कि कुछ लोग ऐसे थे, जिन्होंने सत्र से पहले कोई भी टीडीडी किया था, लेकिन काटा के माध्यम से अंतिम पुनरावृत्ति तक तेजी से टीटीडी ज्ञान फैल गया था, ज्यादातर लोग टीडीडी तरीके से सोच रहे थे या कम से कम इसकी सराहना कर सकते थे कि यह क्यों फायदेमंद हो सकता है।

लोगों ने आम तौर पर कहा कि दोपहर मज़ेदार और जानकारीपूर्ण थी और हम अब अपने कार्यस्थल पर साइबर-डोज़ो का उपयोग करने के अन्य तरीके देख रहे हैं।

---

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

सबसे अच्छी बात यह है कि एक काटा करने के बाद आप भाग ले सकते हैं और भाग लेने वाले प्रत्येक समूह की लाल / हरी प्रगति (या शायद नहीं * 8 ') को देख सकते हैं। यह ट्रैफिक लाइट एक शानदार तरीका कैसे TDD प्रक्रिया काम करता है कल्पना करने के लिए कर रहे हैं।

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

Comments

साइबर-डोजो संदर्भ के लिए +1। पता नहीं था। बहुत दिलचस्प लग रहा है ।

— राडारबॉब

Answer 3

यदि वे टीडीडी का विरोध करते हैं, तो यह ठीक है। बहुत से लोग (अपने आप सहित) को पहले यूनिट टेस्ट लिखने में समस्या हो रही है।

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

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

यदि वह सुनने से इनकार करती है, तो आप उसके ऊपर किसी के पास जाने की कोशिश कर सकते हैं, लेकिन यह बहुत स्मार्ट नहीं हो सकता है यदि आपका बॉस इतना ज़िद्दी है।

Answer 4

अपनी आदतों को बदलने के लिए लोगों को समझाना वास्तव में कठिन है, लेकिन यहाँ कुछ चीजें हैं जिन्हें आप आज़मा सकते हैं:

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

यदि इनमें से कोई भी काम नहीं करता है, तो आप कहीं और काम करने पर विचार कर सकते हैं। ऐसी बहुत सी अन्य कंपनियाँ हैं जहाँ आपका जीवन काफी आसान होगा।

Comments

सिंगापुर एक छोटा देश है, ज्यादा विकल्प नहीं हैं।

— wizztjh

"यदि इनमें से कोई भी काम नहीं करता है, तो आप कहीं और काम करने पर विचार कर सकते हैं।" या, केवल रिकॉर्ड के लिए, आप TDD :) का उपयोग बंद करने पर विचार कर सकते हैं।

— लुकास स्टैस्कल

तीसरी गोली बिंदु के लिए +1। यही असली समस्या है।

— रिवलॉक

Answer 5

यहां 2 अलग-अलग मुद्दे हैं: लोगों को टीडीडी करना और अपने परीक्षणों को तोड़ना।

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

दूसरे मुद्दे पर, प्रोजेक्ट सेट करें ताकि यूनिट परीक्षण चेक-इन पर चलाए जा सकें, ताकि अन्य डेवलपर्स के पास कोई विकल्प न हो, लेकिन यह जानने के लिए कि उन्होंने एक परीक्षण तोड़ा है।

Comments

यह एक अच्छा बिंदु है, वे 2 अलग मुद्दे हैं। सबसे पहले, "वे मेरी परीक्षाएँ तोड़ें" मुद्दे को हल करें। फिर उन्हें टीडीडी करने के लिए काम करना।

— ozz

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

— बटंस Butt४०

Answer 6

जैसा कि कई अन्य में कहा गया है "मुझे वाई विधि / प्रौद्योगिकी का उपयोग करने के लिए एक्स को कैसे आश्वस्त करना चाहिए", मेरा जवाब हमेशा एक ही होता है: उदाहरण के लिए।

इसका उपयोग करें और बेहतर (mesurable) परिणाम हैं। फिर दूसरों को नोटिस करना सुनिश्चित करें।

Answer 7

किसी मौजूदा प्रोजेक्ट पर, आप नहीं। यह वैसा ही है जैसे आप जिस तरह से घुंघराले कोष्ठक को विरासत कोड में रखे जाने के कारण परिवर्तन कर रहे हैं क्योंकि आप इंडेंटेशन शैली को नापसंद करते हैं।

Comments

यह एक नई परियोजना है, मैंने इसे इस सप्ताह शुरू किया है।

— wizztjh

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

— wizztjh

Answer 8

अच्छी सलाह के बहुत सारे। और अब, थोड़ा और ...

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

डब्ल्यूएचडी अभियान में टीडीडी के लिए आपका निरंतर और निरंतर उत्साह और विमानन बहुत महत्वपूर्ण है।

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

कोडर-प्रेरित कीड़े को फंसाने के रूप में परीक्षण-ब्रेकिंग के अच्छे उदाहरण इकट्ठा करें । कोडर अप्रासंगिक कोड के लिए अनावश्यक परीक्षण के रूप में बदलते परीक्षणों को देखेंगे; उन्हें समझना चाहिए कि परीक्षणों ने सिर्फ उनके गधे को कवर किया।

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

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

चेतावनी: TDD एक इलाज नहीं है और खराब OO डिज़ाइन और कोडिंग को दूर नहीं कर सकता (लेकिन यह निश्चित रूप से इसे उजागर कर सकता है)। लुडिट्स को उनकी अक्षमता के लिए परीक्षण कोड प्रयास को दोष न दें।

Answer 9

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

आपको उसकी भाषा बोलनी होगी। प्रबंधक तकनीक से प्रभावित नहीं होते हैं, लेकिन वे व्यवसाय की भाषा समझते हैं:

• परीक्षण विकास के दौरान समय की बचत करेंगे, क्योंकि मैन्युअल परीक्षण के बजाय (स्थानीय रूप से बग को पुन: उत्पन्न करने की कोशिश कर रहे हैं, रेल कंसोल के साथ खेल रहे हैं ...) आप स्वचालित रूप से परीक्षण चला रहे होंगे।

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

• और आप अतिरिक्त समय के साथ क्या करेंगे? मोर का सामान बनाएँ और उन्हें पैसा दें :)

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

Answer 10

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

कचरा संग्रहण भीड़ प्यार क्यों नहीं करती, जानें और RAII क्यों जीते हैं? आप स्वत: मेमोरी प्रबंधन कैसे कर सकते हैं, लेकिन फाइलों, कनेक्शनों आदि जैसे सामान्य संसाधनों के लिए पुराने जमाने के प्रबंधन को पकड़ सकते हैं? क्योंकि RAII एक ऐसी तकनीक है जिसे वे नहीं जानते हैं, समझते हैं, और उपयोग करने का समय नहीं है जब उनके पास एक समय सीमा होती है जिसे काम करने की आवश्यकता होती है।

मुझे यकीन है कि आप RAII का उपयोग नहीं करते हैं और अपने वर्तमान प्रोजेक्ट के लिए इसे सीखने और समझने के लिए तैयार नहीं हैं। अपने सहकर्मी के रूप में ही जो टीडीडी सीखने और समझने के लिए तैयार नहीं है।