क्या सॉफ्टवेयर पुन: उपयोग प्रक्रिया को फिर से शुरू करने से रोकता है


25

कोड पुन: उपयोग एक समस्या के रूप में

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

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


कुछ तुलना अन्य अनुशासनों के लिए

निर्माण

इसके विपरीत, भौतिक प्रणालियों (भवनों, पुलों) का निर्माण पुन: प्रयोज्य के रूप में कहीं नहीं है। यह सच है कि घर की ब्लूप्रिंट को घर की एक ही कॉपी बनाने के लिए कई बार पुन: उपयोग किया जा सकता है, लेकिन निर्माण हर बार किया जाना चाहिए। कट और पेस्ट एनालॉग दुनिया में उस तरह काम नहीं करता है। ब्रिज ब्लूप्रिंट कम पुन: प्रयोज्य होते हैं, क्योंकि साइट की स्थिति अलग-अलग होगी।

मास्टर बिल्डरों को उनके क्षेत्र में दसियों, सैकड़ों, या हजारों चीजों को डिजाइन और / या निर्मित करने के लिए पहचाने जाने वाले विशेषज्ञ हैं। उदाहरण के लिए, फ्रैंक लॉयड राइट , एक विश्व प्रसिद्ध वास्तुकार और डिजाइनर designed more than 1,000 structures and completed 532 works। कॉन्ट्रास्ट है कि एंडर्स हेजलबर्ग के साथ जिन्होंने "सिर्फ" पांच भाषाओं (टर्बो पास्कल; डेल्फ़; जे ++; सी #; टाइपस्क्रिप्ट) को डिजाइन किया है। कई मायनों में, यह एक अनुचित तुलना है क्योंकि डोमेन अलग हैं। लेकिन एक व्यापक स्तर पर, दो बहुत ही बुद्धिमान लोगों से मात्रात्मक उत्पादन काफी अलग है।

मार्शल आर्ट

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

लकड़ी

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


तो, क्या सॉफ्टवेयर का पुन: उपयोग सॉफ्टवेयर डेवलपर्स को अधिक कुशल बनने से रोकता है?

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

मेरा प्रश्न: क्या पुन: उपयोग की जाने वाली सॉफ़्टवेयर की क्षमता किसी परियोजना को दोहराने से आने वाली आवश्यक प्रक्रिया में सुधार और दक्षता को रोकती है?


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

2
अच्छी सॉफ्टवेयर परियोजनाएँ QA में बहुत अधिक दोहराव का कारण बनती हैं। जब मैं 1,5 साल की लंबी परियोजना में एक परीक्षक था, तो हम साप्ताहिक "चेकपॉइंट" रिलीज पर परीक्षण चक्र चलाते हैं, परियोजना के माध्यम से कुल 70 गुना। वह था ... काफी दोहरावदार, धीरे-धीरे बोलना (एक हफ्ते में बहुत कुछ नहीं बदलना)। नाइटली बिल्ड का परीक्षण, स्वाभाविक रूप से, और भी अधिक दोहराए जाने योग्य है - परियोजना के माध्यम से लगभग 500 बार (कुछ मनोरंजक शोस्टॉपर कीड़े बहुत फर्क करने के लिए बहुत कम थे)। अब, मुझे एक निर्माण कंपनी बताइए जिसने 500 पुल बनाए हैं - सभी एक ही टीम के साथ हैं
gnat

@gnat - यह एक उत्कृष्ट अंतर्दृष्टि और एक दृष्टिकोण है जो मैंने अभी तक सोचा नहीं था। SDLC के अन्य पहलू उस पुनरावृत्ति के कारण बहुत अधिक कुशल हो जाते हैं।

1
@ GlenH7 ने इसका उत्तर विस्तार से दिया , जिसमें ज्यादातर पुलों के चित्र शामिल हैं :)
gnat

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

जवाबों:


10

सॉफ्टवेयर का पुन: उपयोग करने की क्षमता प्रक्रिया में सुधार को रोकती नहीं है।

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

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

वे प्रक्रिया में सुधार की कुंजी है आपकी गतिविधियों और प्रक्रियाओं के कुछ प्रकार के तार्किक टूटने, यह निर्धारित करने के लिए कि उन्हें कैसे मापना है (अधिमानतः लगातार), और उन मापों को समझने के लिए कैसे प्रक्रिया को कुछ अंत की ओर बदलना है। यह परियोजना को दोहराने के बारे में नहीं है, लेकिन इस प्रक्रिया में स्थिरता के बारे में है कि आप इस प्रक्रिया को कैसे दोहराते हैं।


वास्तव में पुन: उपयोग किए जा रहे पर निर्भर करता है, यह सीएमएमआई अधिग्रहण में भी गिर सकता है, अर्थात विकास कार्य नहीं।
imel96

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

1
@kevincline यह मायने नहीं रखता कि CMMI सफल हुआ है या नहीं। एयरोस्पेस / रक्षा उद्योग में बैठे, मैं अपने संगठन में सीएमएमआई और उन कंपनियों को देखता हूं जिनके साथ हम काम करते हैं, कि हम उपमहाद्वीप हैं और हम उपमहाद्वीप हैं। हालाँकि, मेरा कहना यह है कि प्रक्रिया में सुधार के लिए, आपको अपनी प्रक्रियाओं को पहचानने की आवश्यकता है। CMMI सिर्फ ऐसा करने के लिए एक एकल उपकरण है। वहाँ अन्य लोग हैं, और आप अपने स्वयं को परिभाषित कर सकते हैं। एक बार आपके पास प्रक्रियाएं होने के बाद, आप उन्हें परिभाषित कर सकते हैं, उन्हें माप सकते हैं, और उन्हें सुधार सकते हैं।
थॉमस ओवेन्स

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

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

5

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

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

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


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

1
@ GlenH7 बात यह है कि, सॉफ्टवेयर विकास निर्माण नहीं कर रहा है। इसकी डिजाइनिंग। सामान बनाने के साथ, आप बार-बार एक ही काम कर रहे हैं। लेकिन डिजाइन के साथ, आपके पास हमेशा अलग लक्ष्य और समस्याएं होती हैं। आपको इसकी तुलना भवन निर्माण से नहीं, बल्कि इसके निर्माण से करनी चाहिए।
युफोरिक

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

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

पुल की तुलना करने के लिए - आप सही हैं, पुल एक हल की गई समस्या है। आप एक नया पुल चाहते हैं, पुराने डिजाइनों को धूल चटाते हैं और कुछ मोड़ बनाते हैं और आपके पास एक नया पुल है (मैं यहाँ पर सादगी को बढ़ाता हूँ)। तो क्यों नहीं एक वेब सेवा सॉफ्टवेयर में इसी तरह का निर्माण किया है? यही कारण है कि सॉफ्टवेयर IMHO इंजीनियरिंग नहीं है, हम इसे एक शिल्प (या कला) की तरह मानते हैं जहां हर परियोजना कस्टम काम है।
gbjbaanb

2

सॉफ़्टवेयर अधिकांश अन्य विषयों की तुलना में अलग है, इसलिए जहां हम सबसे अच्छा समय बिताते हैं, वहां का अर्थशास्त्र अक्सर अलग होता है।

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

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

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

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

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

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


2

क्या सॉफ्टवेयर की क्षमता का पुन: उपयोग किया जाना आवश्यक प्रक्रिया सुधार और दक्षता को रोकता है जो किसी परियोजना को दोहराने से आता है?

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

लेकिन आपके संक्षिप्त और संक्षिप्त प्रश्न के लिए: अपने अनुभव से, मैं हाँ और ना दोनों कहूँगा।

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

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

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

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

दी गई, यह अन्य परिस्थितियों के कारण भी है, जैसे कि हम जिस उत्पाद का निर्माण कर रहे हैं वह अविश्वसनीय रूप से जटिल है, और एक व्यक्ति के लिए यह सब सीखना असंभव होगा (और मैं सिर्फ विमान के एक कंप्यूटर के बारे में बात कर रहा हूं - उनमें से सबसे जटिल एक है, लेकिन अभी भी)।

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

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

आह - खतरा, फिर से नज़र रखी गई ... मेरा बहाना है कि मैं 32 घंटे तक नहीं सोया, इसलिए मेरी ध्यान केंद्रित करने की क्षमता थोड़ी है ... मैं क्या कह रहा था?

यदि कोई अभी भी पढ़ रहा है, तो मेरा निष्कर्ष यह है कि:

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

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


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

मुझे यह जानने में कोई सुविधा नहीं है कि एक सॉफ्टवेयर इंजीनियर जो एक विमान में "सबसे जटिल" कंप्यूटर सिस्टम पर काम करता है, वह 32 घंटों में नहीं सोया है। =)
रबरडैक

2

जैसा कि एक अन्य प्रोग्रामर प्रश्न में स्वीकार किए गए उत्तर में बताया गया है , निर्माण के साथ अनुरूपताओं का ध्यान रखा जाना चाहिए:

इसके लिए एक अनुशंसित रीडिंग है द सॉफ्टवेयर कंस्ट्रक्शन एनालॉग, ब्रोकन

सॉफ्टवेयर अक्सर निर्माण की तुलना में है। दुर्भाग्य से यह सादृश्य त्रुटिपूर्ण है और निर्माण उद्योग से प्राप्त सबक संदिग्ध हैं ...

मैंने जो देखा है, वह अच्छी सॉफ़्टवेयर परियोजनाएँ गुणवत्ता आश्वासन में बहुत अधिक दोहराव है।

जब मैं 1,5 साल की लंबी परियोजना में एक परीक्षक था, तो हम साप्ताहिक "चेकपॉइंट" रिलीज पर परीक्षण चक्र चलाते हैं, परियोजना के माध्यम से कुल 70 गुना। वह था ... काफी दोहरावदार, धीरे-धीरे बोलना (एक हफ्ते में बहुत कुछ नहीं बदलना)। नाइटली बिल्ड का परीक्षण, स्वाभाविक रूप से, और भी अधिक दोहराए जाने योग्य है - परियोजना के माध्यम से लगभग 500 बार (कुछ मनोरंजक शोस्टॉपर कीड़े बहुत फर्क करने के लिए बहुत कम थे)।

अब, उस "संदिग्ध" सादृश्य के बाद, मुझे एक निर्माण कंपनी बताएं जिसने 500 पुल बनाए हैं - सभी एक ही टीम के साथ।

  • इसके आगे, मुझे एक कंपनी बताएं जो अपने प्रत्येक नए पुलों पर ज्यादातर बहुत ही ईंटों और लोहे का उपयोग कर रही है (यहां, मैं इस तथ्य का उल्लेख करता हूं कि हमने जो परीक्षण किया था, उसमें ज्यादातर समान दिन, सप्ताह के हिसाब से बिट्स थे। सप्ताह - "बहुत कुछ नहीं बदलता")।
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

मास्टर बिल्डरों को उनके क्षेत्र में दसियों, सैकड़ों, या हजारों चीजों को डिजाइन और / या निर्मित करने के लिए पहचाने जाने वाले विशेषज्ञ हैं।

ठीक है, ऊपर बताए गए दोहराव के आपके स्पष्टीकरण के बाद, मैं कह सकता हूं कि क्या? वापस तो, हमारे छोटे, बहुत विशेष समूह के परीक्षकों ने सत्यापित नहीं किया है, ऊपर देखें ("लगभग 500") हमारे क्षेत्र की सैकड़ों चीजें।

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

यदि कोई व्यक्ति "संदिग्ध" सादृश्य को "हजारों चीजों" तक जारी रखना चाहता है, तो ये राशि फिर से, सॉफ्टवेयर विकास में कुछ भी शानदार नहीं है जब कोई सही चीजों को देखता है।

  • एक उदाहरण के रूप में, अभी तक मेरी पिछली परियोजनाओं में से एक (फिर से, शानदार कुछ भी नहीं, बल्कि नियमित रूप से), इस बार देव भूमिका में, 5 साल से अधिक समय से चल रहा है (8 प्रमुख रिलीज, कई दर्जनों नाबालिग)। इसी तरह की साप्ताहिक चौकियों ( 5x52~=250उनमें से), समान रात्रिकालीन रिलीज़ ( 5x365~=1800उनमें से) और इसी तरह, इन पर काम करने वाली समान देव / क्यूए टीमें थीं। दिन-प्रतिदिन, सप्ताह से सप्ताह, महीने से महीने, ज्यादातर दोहराव वाले सामान (दो रात के निर्माण के बीच ज्यादा बदलाव नहीं) - जैसा कि वादा किया गया था, हजारों गुना (1800) की सीमा में।

लंबे समय तक विंडोज या जावा जैसे प्रोजेक्ट रहते थे, या ऑटोकैड 10, 20, 30 साल का हो सकता है, जो आसानी से "हजारों" रात के निर्माण और रात के परीक्षणों को दोहराता है।


निरंतरता एकीकरण के साथ QA के लिए पुनरावृत्ति परिवर्तन की अवधारणा और भी प्रमुख हो जाती है ...

अभ्यास ... सभी डेवलपर कार्य प्रतियों को एक साझा मेनलाइन के साथ दिन में कई बार मर्ज करना ... CI को आवधिक एकीकरण की प्रथाओं के गहनता के रूप में देखा जा सकता है।

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

Repeatability? यह उतना ही सही है, जितना कि कोई भी इसके बारे में सोच सकता है।

लगातार / निरंतर क्यूए के साथ, जो चीजें गलत हो जाती हैं वे जल्दी से डेवलपर्स के पास वापस आ जाती हैं जो परीक्षण को सफलतापूर्वक पास करने तक इसे सही तरीके से करने के प्रयासों को दोहराने के लिए मजबूर होते हैं। एक अर्थ में, कोड को दोहराने तक का वह चक्र कोड के जैसा होता है ,

प्रोग्रामिंग में एक अभ्यास जो प्रोग्रामर को अभ्यास और पुनरावृत्ति के माध्यम से अपने कौशल को सुधारने में मदद करता है ...


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

@ GlenH7 हाँ पुनरावृत्ति का प्रभाव वास्तव में गहरा है और यह परीक्षण सूट से बहुत आगे निकल गया। ज्ञान हर जगह जमा हुआ जहां पुनरावृत्ति हुई - आप जानते हैं, सब कुछ 20 ... 30 ... 50 बार करने के बाद इष्टतम पर व्यवस्थित हो जाता है। चेकपॉइंट / रात्रिकालीन तैयारी, बग्स सबमिशन (और संपूर्ण "बग लाइफ"), देव / QA / mgmt / sysadmins कम्युनिकेशन, डॉक्यूमेंटिंग सामान आदि आदि। एक है firehose प्रभाव मेरी बात पेश पर
कुटकी

-1

जो कुछ आप कहते हैं वह सच है: जैसे पुस्तकालय उच्च स्तरीय भाषाओं द्वारा हल नहीं किए जाने वाले कार्यों को हल करते हैं जो विधानसभा द्वारा हल नहीं की जाने वाली समस्याओं को हल करते हैं जो मशीन कोड द्वारा हल नहीं की गई समस्याओं को हल करते हैं। जब आप System.out.println () को जावा में कहते हैं, तो आप यह देख रहे हैं कि कैसे CPU किसी डिवाइस को आउटपुट करता है।

तो हाँ, आप कुछ खो रहे हैं। आप जो हासिल करते हैं वह अनसुलझी समस्याओं पर ध्यान केंद्रित करने की क्षमता है। अब यह हो सकता है कि आपको किसी समस्या को हल करने के लिए प्रौद्योगिकी के कुछ अन्य पहलुओं (जैसे कि नेटवर्क कैसे काम करता है) में खुद को विसर्जित करने की आवश्यकता है। लेकिन आपको मशीन भाषा पढ़ने में एक विशेषज्ञ बनने की आवश्यकता नहीं है, जब आप एक वेब पेज बनाना चाहते हैं।

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

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

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


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

-2

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

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


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

आपको इतिहास को देखने की जरूरत है, उदाहरण के लिए सीडीसी 6600 क्रोनोस ओएस के लिए मेनफ्रेम सिस्टम पर हर साल नई तकनीकें नहीं आ रही थीं। यह मूल रूप से 15 वर्षों के लिए स्थिर था। अब चीजें बहुत तेजी से आगे बढ़ती हैं और 15 वर्षों में ज्ञान के गहरे होने का समय नहीं है। उदाहरण के लिए, फ्लैश करने के 15 साल के अनुभव के साथ कोई फ्लैश प्रोग्रामर नहीं हैं। अपनी पोस्ट को दोबारा पढ़ने के बाद, मैं अपनी मूल पोस्ट के साथ खड़ा हूं।
एडवर्ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.