क्या ऐसा सॉफ्टवेयर लिखना संभव है जिसे लगातार संशोधित करने की आवश्यकता नहीं है?


23

मैंने कई अलग-अलग भाषाओं में बहुत सारे सॉफ्टवेयर लिखे हैं, और मैंने Verilog और VHDL का उपयोग करके FPGAs के साथ उपयोग के लिए "लिखित" हार्डवेयर भी बनाया है।

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

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

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

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


8
आप OCP
Oded

यह ओपन-क्लोज्ड प्रिंसिपल सामान बहुत अच्छा लगता है! क्या किसी ने इसका सफलतापूर्वक उपयोग किया है?
नाथन फ़रिंग्टन

2
@NathanFarrington: अधिकांश डिज़ाइन पैटर्न ( GOF द्वारा वर्णित ) OCP का अनुसरण कर रहे हैं। एक उदाहरण टेम्पलेट विधि पैटर्न होगा
9

2
@NathanFarrington सॉफ़्टवेयर को डिज़ाइन करते समय सॉफ़्टवेयर डेवलपर्स द्वारा उपयोग किया जाने वाला खुला-बंद सिद्धांत एक सामान्य सिद्धांत है।
जेसपर

1
मुझे लगता है कि आज हम जिन कार्यक्रमों का उपयोग करते हैं उनमें से कई बिट्स और टुकड़ों का उपयोग करके बनाए गए हैं जो कि कार्बन प्रतियां कोड के लिए हैं जो 20 साल पहले लिखी गई थीं।
मैलो

जवाबों:


16

हो सकता है कि इसका हार्डवेयर के साथ अच्छी तरह से परिभाषित इंटरफेस और परीक्षण के साथ कुछ करना है?

बिल्कुल मेरे विचार!

स्पष्ट इंटरफेस के साथ अच्छी तरह से डिजाइन किए गए मॉड्यूल अनिवार्य रूप से परिपूर्ण होते हैं। Stringजावा के वर्ग की तरह कुछ सोचो । यह एक कंप्यूटर प्रोग्राम है, लेकिन इसमें एक क्रिस्टल-क्लियर इंटरफ़ेस है। इसमें कोई ज्ञात कीड़े नहीं हैं। यह वही करता है जो इसे करना चाहिए, पूरी तरह से। निश्चित रूप से, पिछले 15 वर्षों के दौरान इसका बड़े पैमाने पर परीक्षण किया गया है, और चूंकि लगभग सभी कार्यक्रमों का उपयोग Stringबुनियादी भवन ब्लॉकों के रूप में किया जाता है, इसलिए इसमें कोई भी बग जल्दी से देखा जाएगा। किसी भी "झगड़े" - सख्ती से बग नहीं, लेकिन जागरूक होने के लायक डिजाइन विवरण - जैसे कि यहां वर्णित http://www.jwz.org/doc/java.html अब तक अच्छी तरह से ज्ञात हैं, और इस तरह से लिया जा सकता है लेखा।

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

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

कोई सिल्वर बुलेट नहीं, लेकिन सर्वोत्तम प्रथाओं का एक अच्छा संयोजन, जिसमें शामिल हैं:

  • सरल, स्वायत्त मॉड्यूल। दूसरे शब्दों में, कम युग्मन और उच्च सामंजस्य।
  • अचल स्थिति। बढ़ती संगति के साथ विशेष रूप से महत्वपूर्ण है।

यह ध्यान देने योग्य है कि दोनों बिंदुओं का उद्देश्य जटिलता को कम करना है। यही प्रमुख बिंदु है। एन्ट्रापी हमेशा बढ़ती जाती है, और जब तक हम लड़ते नहीं हैं, हम जल्द ही जटिलता में डूब जाएंगे। यह देखना भी दिलचस्प है कि पिछले कुछ वर्षों के दौरान, प्रोग्रामिंग भाषाएँ उक्त प्रथाओं को प्रोत्साहित करने या लागू करने की दिशा में भी विकसित हो रही हैं। विशेष रूप से, कार्यात्मक भाषाओं का उदय सिर्फ इतना है कि: शुद्ध कार्य हमेशा एक ही इनपुट के लिए समान मान लौटाते हैं, उनमें कोई स्थिति नहीं होती है। फिर आप बस शुद्ध कार्यों की रचना करते हैं जो अपरिवर्तनीय मूल्यों को लेते हैं और वापस करते हैं , और अपरिहार्य उत्परिवर्तन को चारों ओर फैलाने के बजाय छोटे अच्छी तरह से परिभाषित स्थानों तक सीमित करते हैं। इसे देखें: http://clojure.org/state


1
jwz इस बात से बिलकुल सहमत नहीं है कि स्ट्रिंग क्लास बगफ्री है

1
यह डिज़ाइन के अनुसार काम कर सकता है, इसलिए सवाल यह है कि यदि अंतर्निहित डिज़ाइन टूट गया है। हालाँकि, मैं सहमत हूँ कि स्ट्रिंग एक बहुत ही विश्वसनीय वर्ग है।

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

1
@JoonasPulakka: हाँ, यदि सॉफ़्टवेयर का एक-लाइन सारांश है, तो यह "हमेशा एक और बग" हो सकता है। :-) और मुझे लगता है कि यह नातान की बातों में से एक है।
रॉस पैटरसन

1
जूनास, तुम जीतो। मैंने क्लोजर सीखना शुरू कर दिया है। यह प्रोग्रामिंग को फिर से मजेदार बनाने के लिए सबसे अच्छा तरीका है।
नाथन फ़रिंगटन

9

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

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

आपको निश्चित रूप से परीक्षण-संचालित विकास की जांच करनी चाहिए ।


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

1
@NathanFarrington: मेरा मानना ​​है कि हार्डवेयर / सॉफ्टवेयर स्पेसिफिकेशन और डिज़ाइन में बहुत अंतर है। अधिकांश हार्डवेयर निर्माताओं के पास एक सॉफ्टवेयर डेवलपर की तुलना में जो कुछ भी होता है, उसके लिए सबसे बेहतर संभावनाएं होती हैं, जिसका ग्राहक केवल यह कह सकता है "मुझे ऐसा प्रोग्राम चाहिए जो ऐसा करता है!" नई सुविधाओं और क्या नहीं इसकी गारंटी बहुत सुंदर है।
RCE

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

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

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

6

मैं आपकी कुछ टिप्पणियों पर टिप्पणी करूंगा, उम्मीद है कि आपको इन टिप्पणियों से जवाब मिलेगा।

सॉफ्टवेयर के साथ मेरी मुख्य कुंठा यह है कि यह कभी भी "किया" नहीं जाता है।

ऐसा इसलिए है क्योंकि समाधान विनिर्देश अधूरा है या क्योंकि संवर्द्धन देने की योजना सटीक नहीं है। यह किसी भी प्रोजेक्ट सॉफ्टवेयर, हार्डवेयर या किसी अन्य के लिए हो सकता है।

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

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

"वर्किंग कोड में बग्स को शामिल नहीं करने और हमेशा आगे बढ़ने से मुझे और अधिक मजेदार लेखन सॉफ्टवेयर कैसे हो सकता है?"

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

2-अपने उपयोगकर्ता को इस लंबे समय के दर्शन को समझें।

3-योजना को सावधानी से लागू करें

4-कोड से पहले डिजाइन।

5-जब उपयुक्त हो जेनेरिक डिज़ाइन का उपयोग करें।

6-एक डिजाइन पुष्टिकरण उपकरण के रूप में प्रोटोटाइप का उपयोग करें।


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

4

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

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

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

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

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


मैं उत्सुक हूं, आप लिखते हैं कि परीक्षण महत्वपूर्ण है लेकिन मन-सुन्न भी।
नाथन फ़रिंगटन 13

@NathanFarrington कि बाहर इशारा करने के लिए धन्यवाद। मेरी बात परीक्षण के बारे में सकारात्मक रूप से बात करने की थी, लेकिन मैं इसके बारे में सोच रहा था कि कुछ और टाइप करते समय, इसलिए यह उस पैराग्राफ में पूरी तरह से गलत निकला! मैंने उस वास्तविक बिंदु के अनुरूप सुधार किया है जिसे मैं रोशन करने की कोशिश कर रहा था!
रॉबिन्स 22

3

सॉफ्टवेयर के साथ मेरी मुख्य कुंठा यह है कि यह कभी भी "किया" नहीं जाता है। हमेशा जोड़ने के लिए एक और विशेषता है।

यदि वह आपको निराश करता है, तो एक अलग कैरियर पर विचार करें। गंभीरता से।

बिंदु सॉफ्टवेयर की सुविधाओं को जोड़ने के लिए सक्षम होना है। पहली बार "सॉफ़्टवेयर" का आविष्कार करने का पूरा कारण यह था कि हम सुविधाओं को जोड़ सकें।

अक्सर एक सुविधा को जोड़ते समय यह एक बग को कहीं और पेश करता है जो पहले ठीक काम कर रहा था।

यह एक क्यूए समस्या है।

यह हार्डवेयर में तब तक नहीं होता है जब तक इंटरफेस का उल्लंघन नहीं किया जाता है।

यह सॉफ्टवेयर में भी सच है।

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

हाँ। आपको वास्तव में गुणवत्ता आश्वासन का अभ्यास करना होगा।


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

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

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

@NathanFarrington: ट्यूरिंग ने आविष्कार किया सॉफ्टवेयर को बदलने के लिए एनिग्मा कोड। "गुणवत्ता आश्वासन द्वारा आप परीक्षण का मतलब है"। असत्य। मेरा मतलब है कि गुणवत्ता आश्वासन - विकास के हर पहलू में गुणवत्ता मानक होने चाहिए जो मिलने चाहिए। एक प्रकार की कलाकृतियों की गुणवत्ता का आकलन करने के लिए परीक्षण एक (सीमित) तरीका है। "कोड बदल दिया गया है ... जो बग का परिचय दे सकता है"। सही बात। यह गुणवत्ता आश्वासन की विफलता है - सॉफ्टवेयर की एक अंतर्निहित विशेषता नहीं।
S.Lott

हम निश्चित रूप से विषय से दूर हो रहे हैं। इस लिंक के अनुसार , ट्यूरिंग का कोलोसस यूनिवर्सल नहीं था (कंप्यूटिंग अर्थों में) और संग्रहीत कार्यक्रमों (सॉफ़्टवेयर) का उपयोग नहीं करता था।
नाथन फ़रिंगटन

2

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

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

बड़ी समस्या यह है कि चीजें जटिल हैं। और आप जटिलता को समाप्त नहीं कर सकते, आप केवल इसे इधर-उधर कर सकते हैं।


1

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

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

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

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

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

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

एक अंतिम बिंदु: सॉफ़्टवेयर में हार्डवेयर से एक अलग वित्तीय मॉडल है, यहां तक ​​कि प्रोग्राम किए गए हार्डवेयर भी। अधिकांश गैर-उपभोक्ता सॉफ़्टवेयर और कुछ उपभोक्ता सॉफ़्टवेयर भी इस तरह से बेचे जाते हैं, जो बदलाव को प्रोत्साहित करते हैं। जब आप एक व्यवसाय "हमें $ 10,000 अब प्लस 18% एक वर्ष का भुगतान करें" बता सकते हैं, तो आप अनिवार्य रूप से हर कुछ वर्षों में उत्पाद को फिर से बेच सकते हैं। लेकिन उस शुल्क को सही ठहराने के लिए, आपको ग्राहक को वे परिवर्तन देने होंगे जो वे चाहते हैं। हम्म ... Apple के हार्डवेयर-अप्रचलन वक्र के बारे में सोच, शायद यह सब के बाद एक अंतर नहीं है - हार्डवेयर बस आपको वास्तव में इसे फिर से खरीद लेता है!


कभी नहीं कहा कि मैं किसी से बेहतर था। ;-) जब हार्डवेयर में बग होता है, तो यह समाचार बन जाता है। जब सॉफ़्टवेयर में बग, उम, प्रतीक्षा सॉफ़्टवेयर हमेशा बग होता है। वे कौन सी कार्यप्रणाली हैं जिनका हम उपयोग नहीं करते क्योंकि वे बहुत महंगी हैं और मज़ेदार नहीं हैं?
नाथन फ़रिंगटन

0

वर्किंग कोड में बग्स को शुरू करने और हमेशा आगे बढ़ने से मुझे और अधिक मजेदार लेखन सॉफ्टवेयर कैसे हो सकता है?

मुझे आपके प्रश्न का अंतिम उत्तर खोजना अच्छा लगेगा। लेकिन वास्तविकता यह है कि ऐसा करने का कोई आसान तरीका नहीं है, यही कारण है कि चरम प्रोग्रामिंग और टीडीडी टेकनीक इतने लोकप्रिय हो रहे हैं। आपको परिवर्तन को अपनाने की आवश्यकता है, क्योंकि यह होने जा रहा है। मैं नहीं जानता कि अगर इस तरह से इसका मज़ा, लेकिन निश्चित रूप से बहुत कम तनावपूर्ण ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

जब आप हार्डवेयर के साथ बातचीत करते हैं, तो हार्डवेयर को x मान और सभी (सिद्धांत रूप में) की आवश्यकता होती है, लेकिन जब आप लोगों के साथ बातचीत करते हैं तो उन्हें x की आवश्यकता होती है, और कल उन्हें y की आवश्यकता हो सकती है, आदि। यह कैसे है, bussines और लोगों की आवश्यकताएं बदल जाती हैं । क्योंकि लोग! = मशीनें, इसलिए ऐसा कोड जो कभी-कभी बदलता है, संभव नहीं है।

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


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

जैसा कि मैं हमेशा कहता हूं, सबसे अच्छा कोड, कोई कोड नहीं है। :-)
H27studio

0

क्या इसी तरह से सॉफ्टवेयर लिखना संभव है?

हाँ यही है। बस उतना ही सावधान रहें जैसे कि आप हार्डवेयर विकसित कर रहे हैं, आप जो कुछ भी कर सकते हैं उसका परीक्षण करें, और आपका सॉफ्टवेयर समान गुणवत्ता का होगा।

वैसे, क्या आपने HW बग के बारे में नहीं सुना है? बहुत nastier तो किसी भी SW बग और तय करने के लिए कठिन (सिर्फ सॉफ्टवेयर का उन्नयन नहीं)


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

1
@NathanFarrington सॉफ़्टवेयर आमतौर पर अधिक जटिल है तो एक HW। HW का अधिक अच्छी तरह से परीक्षण किया जाता है। एसडब्ल्यू आसान बदल सकता है, इसलिए लोग उतना ध्यान नहीं देते हैं।
B33овиЈ

0

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

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


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

-1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.