फुर्तीली विकास के लिए गतिशील भाषाएं नुकसानदेह हैं?

12

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

ऐसा लगता है कि स्थैतिक रूप से टाइप की जाने वाली भाषाएं रिफैक्टिंग और रिवर्स इंजीनियरिंग को बहुत आसान बना देती हैं।

यदि गतिशील रूप से टाइप की गई भाषाओं में असंभव नहीं है, तो क्या रिफैक्टरिंग या (स्वचालित) रिवर्स इंजीनियरिंग कठिन है? वास्तविक दुनिया की परियोजनाएं फुर्तीली कार्यप्रणाली के लिए गतिशील रूप से टाइप की गई भाषाओं के उपयोग के बारे में क्या बताती हैं?

agile dynamic-typing static-typing

— Gerenuk
स्रोत

5

डायग्राम में रिवर्स इंजीनियरिंग कोड? आप एगाइल में ऐसा क्यों करेंगे?

— कैफीक सेप

7

Agile का अर्थ "कोड पहले, दस्तावेज़ बाद में" नहीं है।

— रोबोट

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

— गेरेनुक

1

मुझे लगता है कि इस प्रश्न के टैग और पाठ से दृढ़ता से टाइप किया जाना चाहिए। सवाल स्थिर बनाम गतिशील के बारे में लगता है कि मजबूत बनाम कमजोर नहीं है।

— विंस्टन एवर्ट

@WinstonEwert - अच्छा कॉल, मैं करने के लिए टैग को बदल दिया है dynamic-typingऔरstatic-typing

— Carson63000

11

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

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

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

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

— रेक्स केर
स्रोत

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

— गेरेनुक

1

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

— रेक्स केर

14

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

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

— विंस्टन इर्वर्ट
स्रोत

1

फिर रिवर्स इंजीनियरिंग का क्या? टाइपिंग के संबंध में क्या स्मॉलटॉक पायथन से अलग है? यह पायथन में सभी प्रकारों को कम करने के लिए एक कठिन समस्या लगती है और इस प्रकार यह निर्धारित करती है कि कौन सी विधि वास्तव में समान है और केवल एक ही नाम नहीं है।

— गेरिनुक

2

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

— जोर्ग डब्ल्यू मित्तग

@ गेरेनुक, स्मालटाक का टाइप कोई अलग नहीं है तो अजगर। अन्य तरीकों से, जैसे कि आत्मनिरीक्षण, स्मॉलटाक एक सुविधा प्रदान करता है जो रिफैक्टिंग के लिए अधिक अनुकूल है। अजगर में टाइपिंग के लिए काम की आवश्यकता होगी, लेकिन किया गया है, PyPy प्रोजेक्ट देखें।

— विंस्टन एवर्ट

1

@InstonEwert "लेकिन आप मैन्युअल रूप से रिफ्लेक्टर कर सकते हैं, और गतिशील भाषाएं वास्तव में इसे काफी आसान बनाती हैं" - नहीं, मैनुअल रिफ्लेक्टर स्केल नहीं करता है। रिफैक्टरिंग के लिए टूल सपोर्ट सब कुछ बदल देता है, भले ही रिफैक्टरिंग 100% ऑटोमैटिक न हो (नीचे केस स्टडी स्निपेट देखें - प्रोग्रामर.स्टैकएक्सचेंज.

— com

1

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

— रेक्स केर

8

रिफैक्टिंग का आविष्कार गतिशील भाषाओं में किया गया था। ऑटोमैटिक रिफैक्टिंग टूल्स का आविष्कार गतिशील भाषाओं में किया गया था। आईडीई का आविष्कार गतिशील भाषाओं में किया गया था। गतिशील भाषाओं में कई चुस्त तरीके का आविष्कार किया गया था।

मैं वास्तव में कोई समस्या नहीं देख रहा हूँ।

— जॉर्ग डब्ल्यू मित्तग
स्रोत

"स्मॉलटाक टाइपिंग के संबंध में पायथन से बहुत अलग नहीं है। हालांकि, यह टूलिंग के संबंध में काफी भिन्न है।" - शायद यह बदलना शुरू हो रहा है, देखें jetbrains.com/pycharm/features/index.html

— igouy

3

ऐसा न हो कि हम भूल जाते हैं कि काम करने का "फुर्तीला" तरीका जिसे एक्सट्रीम प्रोग्रामिंग (एक्सपी) के रूप में जाना जाता है, एक स्मॉलटॉक प्रोजेक्ट पर बनाया गया था (और स्मॉलटाक निश्चित रूप से "डायनेमिक" भाषा के रूप में गिना जाता है)।

यहां गतिशील रूप से टाइप की गई भाषा के साथ प्रदान किए गए एक रिफैक्टरिंग टूल के औद्योगिक उपयोग का एक केस अध्ययन किया गया है:

कारगिल में एक बहुत बड़ा स्मालटाक एप्लिकेशन विकसित किया गया था ताकि अनाज लिफ्ट और संबंधित कमोडिटी ट्रेडिंग गतिविधियों के संचालन का समर्थन किया जा सके। स्मॉलटाक क्लाइंट एप्लिकेशन में 385 विंडो और 5,000 से अधिक कक्षाएं हैं। इस एप्लिकेशन में लगभग 2,000 वर्गों ने एक प्रारंभिक (लगभग 1993) डेटा एक्सेस फ्रेमवर्क के साथ बातचीत की। फ्रेमवर्क ने डेटा टेबल कॉलम में गतिशील रूप से ऑब्जेक्ट विशेषताओं का मानचित्रण किया।

विश्लेषण से पता चला कि हालांकि डायनेमिक लुक ने ग्राहक निष्पादन के 40% समय का उपभोग किया, यह अनावश्यक था।

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

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

17,100 परिवर्तनों में 35 से कम कीड़े पाए गए। सभी कीड़े जल्दी से तीन सप्ताह की अवधि में हल हो गए थे।

यदि परिवर्तन मैन्युअल रूप से किए गए थे, तो हम अनुमान लगाते हैं कि परिवर्तन नियमों को विकसित करने के लिए 235 घंटों की तुलना में 8,500 घंटे लगेंगे।

पुनर्लेखन नियमों का उपयोग करके कार्य को अपेक्षित समय के 3% में पूरा किया गया था। यह 36 के एक कारक द्वारा सुधार है।

"एक एप्लिकेशन डेटा परत के परिवर्तन" से लू-ब्लॉसर OOPSLA 2002 होगा

इसके अलावा - "असंभव परिवर्तन करने के लिए उपकरण - बड़े स्मालटाक कार्यक्रमों को बदलने के लिए एक उपकरण के साथ अनुभव"

— igouy
स्रोत

1

आपके सिद्धांतों ने मुझे सही लगता है ।

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

वास्तविक दुनिया की परियोजनाएं फुर्तीली कार्यप्रणाली के लिए गतिशील रूप से टाइप की गई भाषाओं के उपयोग के बारे में क्या बताती हैं?

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

इस प्रकार, चुस्त कार्यप्रणाली एक बार सांख्यिकीय रूप से टाइप की गई भाषाओं या गतिशील को लाभ प्रदान नहीं करती है। यह जो प्रदान करता है वह एक ठोस अनुप्रयोग बनाने के लिए एक पुनरावृत्त दृष्टिकोण है।

— Yusubov
स्रोत

4

डायनामिक भाषाओं ने C # से भी काफी पहले ऑटोमैटिक रिफैक्टरिंग टूल्स को अस्तित्व में लिया था और जब नोटपैड अभी भी सबसे शक्तिशाली जावा आईडीई था।

— जोर्ग डब्ल्यू मित्तग

4

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

— डेविड थॉर्नले

1

आप ऐसा क्यों सोच रहे हैं, उदाहरण के लिए जावास्क्रिप्ट एक गतिशील भाषा है, लेकिन री-शार्पर वैसा ही काम नहीं करता जैसा कि C # करता है। दूसरे, मैंने यह नहीं कहा कि "गतिशील भाषाएं काम करने के लिए धीमी हैं"।

— युसुबोव

जिन लोगों ने आपको IntelliJ IDEA - PyCharm लाया है - "रीनेम रीफैक्टरिंग वैश्विक कोड को सुरक्षित और तुरंत सुरक्षित रूप से प्रदर्शन करने की अनुमति देता है। एक फ़ाइल के भीतर स्थानीय परिवर्तन इन-प्लेस किए जाते हैं। सादे पाइथन और Django प्रोजेक्ट्स में रिफैक्टरिंग कार्य का उपयोग करते हैं / परिचय चर का उपयोग करें /। एक विधि के भीतर कोड संरचना में सुधार के लिए फ़ील्ड / कॉन्स्टेंट और इनलाइन स्थानीय, लंबी विधियों को तोड़ने के लिए एक्स्ट्रेक्ट विधि, सुपरक्लास, पुश अप, पुल डाउन और विधियों और वर्गों को स्थानांतरित करने के लिए निकालें। " jetbrains.com/pycharm/features/index.html

— igouy

@igouy, मैं अपने उत्तर में Resharper और JustCode का उल्लेख कर रहा हूं। इस प्रकार, यह उस संदर्भ के लिए सही है जिसे यह संदर्भित किया गया है।

— यूसुबोव