📆 🕑 📶 बिग कैलकुलेटर हाथ से निकल जाता है 👨🏻‍🏭 🌻 🛬

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

बड़ा कैलकुलेटर

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

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

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

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

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

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

मेरे अध्ययन के दौरान, यह काफी स्वाभाविक रूप से निकला कि प्रोग्रामिंग के संदर्भ में (शारीरिक मॉडलिंग के गणितीय तरीकों सहित) मैं सर्वश्रेष्ठ में से एक था। और वहां निम्नलिखित तथ्य स्पष्ट हो गए:

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

2. इस तथ्य के परिणामस्वरूप, एक प्रोग्रामर एक पेशा नहीं है। एक प्रोग्रामर सिर्फ वह व्यक्ति होता है जो एक निर्धारित शेड्यूल बनाने के लिए बिग कैलकुलेटर का उपयोग करना जानता है। कैसे शेड्यूल बनाया जाएगा इससे कोई फर्क नहीं पड़ता। निश्चित रूप से। कैसे-कैसे बोले? स्थैतिक विश्लेषण? संस्करण नियंत्रण? चारों ओर देखो, प्रिय! C ++ प्रोग्रामर्स के लिए एक भाषा है। फोरट्रान पर भौतिक विज्ञानी लिखते हैं!

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

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

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

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

2. काम करने वाले कंप्यूटर पर कोई प्रशासनिक अधिकार नहीं। शायद यह नियम कार्यालय प्लवक के लिए उचित है, लेकिन मेरे लिए एक प्रोग्रामर की कल्पना करना मुश्किल है जो इसे पसंद करेगा।

3. (अप्रासंगिक, सिर्फ एक उदाहरण) आप एक कैमरा फोन भी नहीं ले सकते हैं (और अब आपने दूसरों को कहां देखा है)?

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

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

यह सिर्फ इतना है कि लोग उन क्षेत्रों में बहुत रूढ़िवादी हो जाते हैं जो उनके मुख्य रिज नहीं हैं।

(इल्या मेयुस। मूल टिप्पणी ।)

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

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

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

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

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

मैं कुर्सी से कूद गया और, जीत के नशे में धुत्त, कमरे के चारों ओर एक घेरा बना लिया। मॉरिसन, बीमिंग, एक कंप्यूटर पर बैठा था। और केवल एस्पिनवॉल की प्रतिक्रिया गैर-मानक थी। "यह बहुत अच्छा है। मुझे कोई संदेह नहीं था कि सब कुछ ऐसा होगा, ”एस्पिनवाल ने शांति से कहा। "मेरी बियर कहाँ है?"

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

यहां ऐसी हकीकत है। यह कैसे न केवल व्यक्तिगत कंप्यूटर का उपयोग किया जाता है, बल्कि वैज्ञानिक कंप्यूटिंग में क्लस्टर सिस्टम भी है। और सबसे महत्वपूर्ण बात, लोग कार्यक्रमों के परिणामों पर भरोसा करते हैं। और आगे, ऐसी गणना अधिक होगी। और अधिक से अधिक उनके कोड में त्रुटियों का खतरा होगा।

शायद यह कुछ बदलने का समय है?

मुझे अपने दम पर एक छड़ी छड़ी करने का अधिकार है। मैं सिफारिश कर सकता हूं कि, मेरी राय में, यह एक ठंड के साथ पीने के लायक है। लेकिन अब और नहीं। मैं एक दाँत ड्रिल नहीं कर सकता या एक पर्चे लिख सकता हूँ।

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

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

खतरे का उदाहरण

मुझे लगता है कि मेरे कई अनुभव बहुत सारगर्भित हैं। इसलिए, अभ्यास से कुछ पर नजर डालते हैं। जीव विज्ञान के क्षेत्र में समस्याओं को हल करने के लिए एक खुला पैकेज ट्रांस-प्रोटीन पाइपलाइन (टीपीपी) है। यह स्पष्ट रूप से उपयोग किया जाता है। इसका उपयोग उन लोगों द्वारा किया जाता है जो विकसित होते हैं और संभवतः तृतीय-पक्ष संगठन। यह मुझे लगता है कि इसमें किसी भी त्रुटि की उपस्थिति पहले से ही एक संभावित समस्या है। क्या इसमें कोई गलतियाँ हैं? हाँ है। और सभी नए दिखाई देते हैं। एक साल पहले, हमने इस परियोजना की जाँच की और " ट्रांस-प्रोटीन पाइपलाइन (टीपीपी) परियोजना का सत्यापन " नोट लिखा।

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

1. गलत तरीके से गलत चक्र लिखना जारी है

पिछले लेख में, मैंने पहले ही चक्रों में गलत स्थितियों के बारे में लिखा था। ऐसी त्रुटियां हैं और पैकेज का नया संस्करण है।

double SpectraSTPeakList::calcDot(SpectraSTPeakList* other) { .... for (i = this->m_bins->begin(), j = other->m_bins->begin(); i != this->m_bins->end(), j != other->m_bins->end(); i++, j++) { d = (*i) * (*j); dot += d; } .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V521 ',' ऑपरेटर का उपयोग करने वाले ऐसे भाव खतरनाक हैं। सुनिश्चित करें कि अभिव्यक्ति सही है। spectrastpeaklist.cpp 504

चेक में "i! = This-> m_bins-> end (), j! = Other-> m_bins-> एंड ()", दशमलव बिंदु से पहले की अभिव्यक्ति कुछ भी चेक नहीं करती है। अल्पविराम ऑपरेटर ',' का उपयोग इसके दोनों ओर के भावों को बाएं से दाएं क्रम में निष्पादित करने के लिए किया जाता है और सही अभिव्यक्ति का मान लौटाता है । एक मान्य चेक इस तरह दिखना चाहिए:

 i != this->m_bins->end() && j != other->m_bins->end()

इसी तरह के ब्लूपर्स यहां देखे जा सकते हैं:

spectrastpeaklist.cpp 516
spectrastpeaklist.cpp 529
spectrastpeaklist.cpp 592
spectrastpeaklist.cpp 608
spectrastpeaklist.cpp 625
spectrastpeaklist.cpp 696

2. एक अशक्त सूचक को छोड़ना

ऐसी त्रुटि से गलत गणना परिणाम नहीं होंगे। एक प्रोग्राम क्रैश होगा, जो बहुत बेहतर है। हालांकि, इन त्रुटियों के बारे में नहीं लिखना भी अजीब होगा।

 void ASAPRatio_getDataStrctRatio(dataStrct *data, ....) { .... int *outliers, *pepIndx=NULL; .... //pepIndx   .... if(data->dataCnts[i] == 1 && pepIndx[i] == 0) data->dataCnts[i] = 0; .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V522 अशक्त सूचक 'pepIndx' की डेरेफेरिंग हो सकती है। asapcgidisplay2main.cxx 534

नल पॉइंटर को भी यहाँ पर दिया गया है:

सूचक 'पेप्टाइड्स'। asapcgidisplay2main.cxx 556
सूचक 'पेप्टाइड्स'। asapcgidisplay2main.cxx 557
सूचक 'पेप्टाइड्स'। asapcgidisplay2main.cxx 558
सूचक 'पेप्टाइड्स'। asapcgidisplay2main.cxx 559
सूचक 'पेप्टाइड्स'। asapcgidisplay2main.cxx 560
सूचक 'pepIndx'। asapcgidisplay2main.cxx 569

3. अशुद्ध सरण

 static void clearTagNames() { std::vector<const char *>ptrs; for (tagname_set::iterator i = tagnames.begin(); i!=tagnames.end();i++) { ptrs.push_back(*i); } for (tagname_set::iterator j = attrnames.begin(); j!=attrnames.end();j++) { ptrs.push_back(*j); } tagnames.empty(); attrnames.empty(); for (size_t n=ptrs.size();n--;) { delete [] (char *)(ptrs[n]); // cast away const } }

विश्लेषक ने तुरंत यहां दो अशुद्ध सरणियों को देखा:

V530 'खाली' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। tag.cxx 72

V530 'खाली' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। tag.cxx 73

खाली () फ़ंक्शन के बजाय, आपको स्पष्ट () फ़ंक्शन को कॉल करना चाहिए।

4. अनारक्षित वर्ग की वस्तुएं

 class ExperimentCycleRecord { public: ExperimentCycleRecord() { ExperimentCycleRecord(0,0,0,True,False); } ExperimentCycleRecord(long lExperiment, long lCycleStart, long lCycleEnd, Boolean bSingleCycle, Boolean bRangleCycle) { .... } .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V603 ऑब्जेक्ट बनाया गया था लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'this-> ExperimentCycleRecord :: ExperimentCycleRecord (....)' का उपयोग किया जाना चाहिए। mascotconverter.cxx 101

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

"ExperimentCycleRecord (0,0,0, True, False)" लाइन वह जगह है जहाँ एक और कंस्ट्रक्टर को बुलाया जाता है, एक अस्थायी ऑब्जेक्ट बनाता है जो नष्ट हो जाएगा। मैंने इस त्रुटि पैटर्न की जांच लेख में " फोर्ड को जाने बिना, पानी में मत जाओ - भाग एक " में की।

ऐसे ही गलत कंस्ट्रक्टर यहां मिल सकते हैं:

asapratiopeptideparser.cxx 57
asapratiopeptidecgidisplayparser.cxx 36
cruxdiscrimfunction.cxx 36
discrimvalmixturedistr.cxx 34
mascotdiscrimfunction.cxx 47
mascotscoreparser.cxx 37
tandemdiscrimfunction.cxx 35
tandemkscoredf.cxx 37
tandemnativedf.cxx 37

5. टिप्पणियां जो तर्क का उल्लंघन करती थीं

 int main(int argc, char** argv) { .... if (getIsInteractiveMode()) //p->writePepSHTML(); //p->printResult(); // regression test? if (testType!=NO_TEST) { TagListComparator("InterProphetParser",testType, outfilename,testFileName); .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V628 यह संभव है कि लाइन को अनुचित तरीके से टिप्पणी की गई थी, इस प्रकार कार्यक्रम के संचालन लॉगिक्स में बदलाव किया गया था। interprophetmain.cxx 175

'अगर' कथन के बाद, क्रियाओं को करने वाली पंक्तियों पर टिप्पणी की गई। परिणामस्वरूप, प्रोग्रामर की योजना के अनुसार प्रोग्राम लॉजिक नहीं बदला। वह चाहता था कि जब हालत मिले तब कुछ न हो। इसके बजाय, यदि नीचे दिए गए कोड पर स्टेटमेंट का प्रभाव पड़ता है। परिणाम - चल रहे परीक्षण अब न केवल "testType! = NO_TEST" स्थिति पर निर्भर करते हैं, बल्कि "getIsInteractiveMode ()" स्थिति पर भी निर्भर करते हैं। एक परीक्षण कुछ भी परीक्षण नहीं कर सकता है। मैं अत्यधिक एक परीक्षण पद्धति (जैसे TDD) पर पूरी तरह भरोसा नहीं करने की सलाह देता हूं ।

6. टाइपो

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

 void ASAPRatio_getProDataStrct(proDataStrct *data, char **pepBofFiles) { .... if (data->indx == -1) { data->ratio[0] = -2.; data->ratio[0] = 0.; data->inv_ratio[0] = -2.; data->inv_ratio[1] = 0.; return; } .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V519 'डेटा-> अनुपात [0]' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 130, 131. asapcgidisplay2main.cxx 131

संयोग से दो बार हमने उसी चर में मानों को लिखा। यह होना चाहिए था:

 data->ratio[0] = -2.; data->ratio[1] = 0.;

और फिर, हमने इस टुकड़े को कार्यक्रम में अन्य स्थानों पर भी कॉपी किया:

asapcgidisplay2main.cxx 338
asapcgidisplay2main.cxx 465
asapratioproteincgidisplayparser.cxx 393
asapratioproteincgidisplayparser.cxx 518

7. हस्ताक्षरित और अहस्ताक्षरित संख्याओं की तुलना।

आपको हस्ताक्षरित और अहस्ताक्षरित संख्याओं की तुलना करने में सक्षम होना चाहिए। साधारण कैलकुलेटर में कोई अहस्ताक्षरित संख्या नहीं हैं। लेकिन C ++ में है।

 size_type size() const; void computeDegenWts() { .... int have_cluster = 0; .... if ( have_cluster > 0 && ppw_ref.size() - have_cluster > 0 ) .... }

PVS- स्टूडियो डायग्नोस्टिक संदेश: V555 अभिव्यक्ति 'ppw_ref.size () - has_cluster> 0' 'ppw_ref.size ()! = Have_cluster' के रूप में काम करेगा। प्रोटीनप्रोटेक्ट। सीपी 6767

मैं "ppw_ref.size ()> has_cluster" चेक चलाना चाहता था। लेकिन यह काफी अलग था।

सरलता के लिए, हमारे पास 'size_t' प्रकार 32-बिट है। मान लें कि फ़ंक्शन "ppw_ref.size ()" 10 देता है और चर has_cluster 15. है। फ़ंक्शन ppw_ref.size () अहस्ताक्षरित प्रकार 'size_t' लौटाता है। C ++ के नियमों के अनुसार, घटाव से पहले, माइनस ऑपरेशन में सही ऑपरेटर भी 'size_t' प्रकार का हो जाएगा। अभी तक तो अच्छा है। बाईं ओर हमारे पास 10u है, दाईं ओर 15u है।

घटाना:

10u - 15u

और यहाँ मुसीबत है। सभी समान C ++ नियमों का कहना है कि एक अहस्ताक्षरित प्रकार के दो चर घटने का परिणाम भी एक अहस्ताक्षरित प्रकार होगा।

इसका मतलब है कि 10u - 15u = FFFFFFFBu। और, जैसा कि आप जानते हैं, 4294967291 0 से अधिक है।

ग्रेट कैलकुलेटर का दंगा सफल होता है। सही सैद्धांतिक एल्गोरिदम लिखना पर्याप्त नहीं है। आपको सही कोड भी लिखना होगा।

एक समान त्रुटि यहाँ है:

 double SpectraSTPeakList::calcXCorr() { .... for (int tau = -75; tau <= 75; tau++) { float dot = 0.0; for (unsigned int b = 0; b < numBins; b++) { if (b + tau >= 0 && b + tau < (int)numBins) { dot += (*m_bins)[b] * theoBins[b + tau] / 10000.0; } } .... .... }

PVS-Studio नैदानिक संदेश: V547 अभिव्यक्ति 'b + tau> = 0' हमेशा सत्य होता है। अहस्ताक्षरित प्रकार का मान हमेशा> = 0. स्पेक्ट्रास्पीकललिस्ट। 2058 है

जैसा कि कोड दिखाता है, चर 'ताऊ' रेंज [-75, 75] में मान लेता है। सरणी की सीमा से आगे नहीं जाने के लिए, एक चेक है: b + tau> = 0. मुझे लगता है कि आपको पहले ही पता चल गया है कि यह चेक काम नहीं करता है। चर 'b' प्रकार का 'अहस्ताक्षरित' है। इसका मतलब यह है कि अभिव्यक्ति "बी + ताऊ" टाइप अहस्ताक्षरित है। अहस्ताक्षरित प्रकार का मान हमेशा 0 से अधिक या उसके बराबर होता है।

8. एक अजीब चक्र

 const char* ResidueMass::getStdModResidues(....) { .... for (rmap::const_iterator i = p.first; i != p.second; ++i) { const cResidue &r = (*i).second; if (r.m_masses[0].m_nterm) { n_term_aa_mod = true; } else if (r.m_masses[0].m_cterm) { c_term_aa_mod = true; } return r.m_residue.c_str(); } if(! strcmp(mod, "+N-formyl-met (Protein)")) { return "n"; } if (! strcmp(mod, "13C6-15N2 (K)")) { return "K"; } if (! strcmp(mod, "13C6-15N4 (R)")) { return "R"; .... }

PVS-Studio द्वारा जारी की गई चेतावनी: V612 लूप के भीतर बिना शर्त 'वापसी'। रेसुडेमास.कां। 1442

लूप के अंदर एक 'रिटर्न' स्टेटमेंट होता है, जिसे वैसे भी कहा जाता है। एक लूप केवल एक पुनरावृत्ति कर सकता है, जिसके बाद फ़ंक्शन समाप्त हो जाएगा। मुझे लगता है कि यहां या तो टाइपो है या 'रिटर्न' ऑपरेटर से पहले पर्याप्त स्थिति नहीं है।

9. रफ कंप्यूटिंग

 double RTCalculator::getUsedForGradientRate() { if (rts_.size() > 0) return used_count_ / rts_.size(); return 0.; }

PVS-Studio द्वारा जारी चेतावनी: V636 'used_count_ / rts_.size ()' अभिव्यक्ति को 'int' प्रकार से 'double' प्रकार में निहित किया गया था। एक आंशिक भाग के नुकसान से बचने के लिए एक स्पष्ट प्रकार के कलाकारों का उपयोग करने पर विचार करें। एक उदाहरण: डबल ए = (डबल) (एक्स) / वाई ;; rtcalculator.cxx 6406

चूंकि फ़ंक्शन दोहरा मान लौटाता है, इसलिए यह निम्नलिखित मान लेना उचित है।

यदि चर 'used_count_' 5 है, और rts_.size () फ़ंक्शन 7 देता है, तो परिणाम लगभग 0.714 होना चाहिए। केवल getUsedForGradientRate () फ़ंक्शन इस मामले में 0 लौटाएगा।

चर 'used_count_' प्रकार का है। Rts_.size () फ़ंक्शन भी प्रकार 'int' का मान लौटाता है। पूर्णांक विभाजन होता है। परिणाम स्पष्ट है। यह शून्य है। फिर शून्य को स्पष्ट रूप से डबल कास्ट किया जाता है। लेकिन यह अब महत्वपूर्ण नहीं है।

स्थिति को ठीक करने के लिए, आप इसे लिख सकते हैं:

 return static_cast<double>(used_count_) / rts_.size();

इसी तरह की खामियां:

cgi_pep3d_xml.cxx 3203
cgi_pep3d_xml.cxx 3204
asapratiopeptideparser.cxx 4108

10. द ग्रेट एंड माइटी कॉपी-पेस्ट

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

 void setPepMaxProb( bool use_nsp, bool use_fpkm, bool use_joint_probs, bool compute_spectrum_cnts ) { double prob = 0.0; double max2 = 0.0; double max3 = 0.0; double max4 = 0.0; double max5 = 0.0; double max6 = 0.0; double max7 = 0.0; .... if ( pep3 ) { ... if ( use_joint_probs && prob > max3 ) ... } .... if ( pep4 ) { ... if ( use_joint_probs && prob > max4 ) ... } .... if ( pep5 ) { ... if ( use_joint_probs && prob > max5 ) ... } .... if ( pep6 ) { ... if ( use_joint_probs && prob > max6 ) ... } .... if ( pep7 ) { ... if ( use_joint_probs && prob > max6 ) ... } .... }

V525 समान ब्लॉकों के संग्रह वाले कोड। चेक आइटम 'मैक्स 3', 'मैक्स 4', 'मैक्स 5', 'मैक्स 6', 'मैक्सम 6' इन लाइन्स 4664, 4690, 4716, 4743, 4770। प्रोटीनप्रॉपेट.कैप 4664

PVS-Studio द्वारा जारी चेतावनी: V525 समान ब्लॉकों के संग्रह वाला कोड। चेक आइटम 'मैक्स 3', 'मैक्स 4', 'मैक्स 5', 'मैक्स 6', 'मैक्सम 6' इन लाइन्स 4664, 4690, 4716, 4743, 4770। प्रोटीनप्रॉपेट.कैप 4664

दुर्भाग्य से, V525 डायग्नोस्टिक बहुत सारी झूठी सकारात्मकता देता है और इसे तीसरे स्तर की चेतावनी के लिए सौंपा गया है। लेकिन अगर आप उनका अध्ययन करने के लिए बहुत आलसी नहीं हैं, तो आप ऐसे अद्भुत कीड़े पा सकते हैं।

11. सूचक हमेशा आरंभीकृत नहीं होता है

 int main(int argc, char** argv) { .... ramp_fileoffset_t *pScanIndex; .... if ( (pFI=rampOpenFile(mzXmlPath_.c_str()))==NULL) { .... } else { .... pScanIndex = readIndex(pFI, indexOffset, &iAnalysisLastScan); .... } .... if (pScanIndex != NULL) free(pScanIndex); return 0; }

PVS-Studio द्वारा जारी की गई चेतावनी: V614 संभावित रूप से असंगठित सूचक 'pScanIndex' का उपयोग किया जाता है। sqt2xml.cxx 476

यदि rampOpenFile () NULL देता है तो यह प्रोग्राम अंत में क्रैश हो सकता है। आलोचनात्मक नहीं, बल्कि अप्रिय।

एक और वैरिएबल जिसे इनिशियलाइज़ नहीं किया जा सकता है वह यहाँ है:

संभावित रूप से असिंचित सूचक 'fp_' का उपयोग किया जाता है। dta-xml.cpp 307

12. कोई वर्चुअल विध्वंसक नहीं

 class DiscriminantFunction { public: DiscriminantFunction(int charge); virtual Boolean isComputable(SearchResult* result) = 0; virtual double getDiscriminantScore(SearchResult* result) = 0; virtual void error(int charge); protected: int charge_; double const_; }; // class class CometDiscrimFunction : public DiscriminantFunction; class CruxDiscrimFunction : public DiscriminantFunction; class InspectDiscrimFunction : public DiscriminantFunction; ..... class DiscrimValMixtureDistr : public MixtureDistr { .... DiscriminantFunction* discrim_func_; .... }; DiscrimValMixtureDistr::~DiscrimValMixtureDistr() { delete[] posinit_; delete[] neginit_; delete discrim_func_; }

PVS-Studio द्वारा जारी चेतावनी: V599 वर्चुअल विध्वंसक मौजूद नहीं है, हालांकि 'डिस्क्रिमिनेशन फंक्शन' क्लास में वर्चुअल फ़ंक्शंस होते हैं। discrimvalmixturedistr.cxx 206

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

13. विविध

आप बहुत सी खामियां पा सकते हैं जो गंभीर परिणाम नहीं देगा, लेकिन कोड में उनकी उपस्थिति अप्रिय है। बस संदिग्ध हैं, लेकिन जरूरी नहीं कि गलत जगह हों। यहाँ उनमें से एक है:

 Boolean MixtureModel::iterate(int counter) { .... if (done_[charge] < 0) { done_[charge]; } else if (priors_[charge] > 0.0) { done_[charge] += extraitrs_; } .... }

PVS-Studio द्वारा जारी चेतावनी: V607 स्वामी अभिव्यक्ति 'किया_ [आवेश]'। mixmodel.cxx 1558

यह क्या है अधूरा कोड? या क्या आप इस बात पर ज़ोर देना चाहेंगे कि शर्त "किया_ [आरोप] <0" पूरी होने पर आपको कुछ करने की ज़रूरत नहीं है?

और यहाँ गलत मेमोरी रिलीज़ है। उच्च संभावना के साथ कोई भयानक परिणाम नहीं होगा, लेकिन यह कोड एक गंध के साथ है।

 string Field::getText(....) { .... char* pepString = new char[peplen + 1]; .... delete pepString; .... }

PVS-Studio द्वारा जारी चेतावनी: V611 'नए टी []' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी, लेकिन 'डिलीट' ऑपरेटर का उपयोग करके जारी किया गया था। इस कोड का निरीक्षण करने पर विचार करें। संभवतः 'डिलीट [] पेप्स्ट्रिंग;' का उपयोग करना बेहतर है। pepxfield.cxx 1023

यहां आपको "हटाएं [] pepString" लिखना चाहिए। ऐसी जगह एक से बहुत दूर है:

cruxdiscrimvalmixturedistr.cxx 705
cruxdiscrimvalmixturedistr.cxx 715
mascotdiscrimvalmixturedistr.cxx 426
mascotdiscrimvalmixturedistr.cxx 550
mascotdiscrimvalmixturedistr.cxx 624
फेनिक्सडिस्क्रीमवलमिक्सटेडर.के। एक्सएक्सएक्स 692
probiddiscrimvalmixturedistr.cxx 487
probiddiscrimvalmixturedistr.cxx 659
tandemdiscrimvalmixturedistr.cxx 731
tandemdiscrimvalmixturedistr.cxx 741

और यहां "-" ऑपरेटर का कार्यान्वयन है। स्पष्ट रूप से इसका कहीं भी उपयोग नहीं किया जाता है। अन्यथा, त्रुटि जल्दी से प्रकाश में आ जाएगी।

 CharIndexedVectorIterator operator++(int) { // postincrement CharIndexedVectorIterator _Tmp = *this; ++m_itr; return (_Tmp); } CharIndexedVectorIterator& operator--() { // predecrement ++m_itr; return (*this); }

PVS-Studio द्वारा जारी चेतावनी: V524 यह अजीब है कि '-' फ़ंक्शन का शरीर '++' फ़ंक्शन के शरीर के पूरी तरह से समकक्ष है। charindexedvector.hpp 81

"-" और "++" ऑपरेटरों को समान रूप से कार्यान्वित किया जाता है। और फिर, शायद, उन्होंने नकल की:

charindexedvector.hpp 87
charindexedvector.hpp 159
charindexedvector.hpp 165

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

मैं संक्षेप में बताता हूं

दुर्भाग्य से, लेख भ्रामक निकला। तो लेखक क्या कहना चाहता था? मैं बहुत संक्षेप में दोहराने की कोशिश करूँगा कि मैं क्या विचार व्यक्त करना चाहता था।

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

और क्या करने का प्रस्ताव है?

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

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

बिग कैलकुलेटर हाथ से निकल जाता है