🕖 👨🏼‍🔧 🕴🏾 आधुनिक आईडीई। निश्चित रूप से डी, कुछ हद तक ई, और निश्चित रूप से मैं नहीं 👌🏾 🙉 👦🏻

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

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

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

ए

यह एक खोज नहीं होगी कि पर्यावरण विभिन्न परियोजनाओं के लिए अलग है। भले ही वे एक स्टैक पर काम करते हों। इस्तेमाल किया जा सकता है:

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

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

एकीकृत?

उपरोक्त को देखते हुए, यह "एकीकृत" पर विचार करने के लिए समझ में नहीं आता है, लेकिन "पूर्णांक" वातावरण।
फिर, उपयोगकर्ता के दृष्टिकोण से, एक अच्छा एकीकरण उपकरण है जब:

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

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

एक और गैर-स्पष्ट बिंदु: इंटरफ़ेस समान नहीं हो सकता है।
सबसे आम उदाहरण एक परियोजना में GUI और CLI दोनों का उपयोग कर रहा है।
मैंने एक परियोजना पर एक ही वातावरण में काम करने पर कई संपादकों के उपयोग के बारे में बात की।

विकास

अब हम सीधे टूल पर सीधे आगे बढ़ सकते हैं।

रिएक्टर ब्राउजर

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

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

रनटाइम डेटा ट्री विश्लेषण।

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

सूचना और ज्ञान

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

प्रलेखन।
रिसेप्शन \ विकास उत्तराधिकार।

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

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

निष्कर्ष

तो, सारांश:

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

आधुनिक आईडीई। निश्चित रूप से डी, कुछ हद तक ई, और निश्चित रूप से मैं नहीं