कृपया, तकनीकी मुद्दों पर बने रहें, व्यवहार, सांस्कृतिक, कैरियर या राजनीतिक मुद्दों से बचें।
कृपया, तकनीकी मुद्दों पर बने रहें, व्यवहार, सांस्कृतिक, कैरियर या राजनीतिक मुद्दों से बचें।
जवाबों:
बग आपके कोड में है, संकलक या रनटाइम लाइब्रेरी में नहीं।
यदि आपको एक बग दिखाई देता है जो संभवतः नहीं हो सकता है, तो जांचें कि आपने अपना प्रोग्राम सही ढंग से बनाया और तैनात किया है। (खासकर यदि आप एक जटिल आईडीई का उपयोग कर रहे हैं या फ्रेमवर्क का निर्माण कर रहे हैं जो आपसे गंदे विवरण को छिपाने की कोशिश करता है ... या यदि आपके निर्माण में बहुत सारे मैनुअल चरण शामिल हैं।)
समवर्ती / बहु-थ्रेडेड प्रोग्रामों को लिखना मुश्किल है और ठीक से परीक्षण करने के लिए कठिन है। यह उतना ही सबसे अच्छा है जितना आप पुस्तकालयों और रूपरेखाओं को समाप्त कर सकते हैं।
प्रलेखन लिखना एक प्रोग्रामर के रूप में आपकी नौकरी का हिस्सा है। इसे करने के लिए "किसी और के लिए" मत छोड़ो।
संपादित करें
हां, मेरी बात # 1 ओवरस्टेट है। यहां तक कि सबसे अच्छे इंजीनियर एप्लिकेशन प्लेटफॉर्म में उनके हिस्से होते हैं, और कुछ कम अच्छी तरह से इंजीनियर उनके साथ व्याप्त होते हैं। लेकिन फिर भी, आप हमेशा अपने कोड पर शक करना चाहिए पहले , और केवल संकलक / पुस्तकालय कीड़े को दोष देने शुरू जब आप स्पष्ट सबूत है कि अपने कोड की गलती नहीं है।
उन दिनों में जब मैंने C / C ++ डेवलपमेंट किया था, मुझे ऐसे मामले याद हैं, जहाँ आशावादी "बग्स" मेरी वजह से बने हैं / कुछ अन्य प्रोग्रामर ने ऐसी चीजें की हैं, जिनके बारे में भाषा का कहना है कि अपरिभाषित परिणाम हैं। यह जावा जैसी कथित सुरक्षित भाषाओं के लिए भी लागू होता है; उदाहरण के लिए, जावा मेमोरी मॉडल (JLS चैप्टर 17) पर एक लंबी कड़ी नज़र डालें।
फ्लोटिंग पॉइंट कंप्यूटेशन सटीक नहीं हैं ।
वह # 1 चीज़ जो आप अपने कोड की गुणवत्ता और रखरखाव को बढ़ाने के लिए कर सकते हैं वह है REDUCE DUPLICATION।
समस्या निवारण और डिबगिंग कौशल
वे शायद ही किसी विषय पर मेरे द्वारा लिए गए प्रोग्रामिंग पाठ्यक्रमों में से किसी पर भी समय बिताते हैं, और मेरे अनुभव में यह सबसे बड़ा निर्धारक है कि प्रोग्रामर कितना उत्पादक है। यह पसंद है या नहीं, आप नए विकास चरण की तुलना में अपने ऐप के रखरखाव चरण में बहुत अधिक समय बिताते हैं।
मैंने कई प्रोग्रामर्स के साथ काम किया है जो समस्या को खोजने के लिए बिना किसी रणनीति के बेतरतीब ढंग से चीजों को बदलकर डिबग करते हैं। मैंने दर्जनों बार यह बातचीत की है।
अन्य प्रोग्रामर: मुझे लगता है कि हमें यह देखने की कोशिश करनी चाहिए कि क्या वह इसे ठीक करता है।
Me: ठीक है, यह मानते हुए कि यह ठीक करता है। यह आपको क्या बताता है कि समस्या का स्रोत कहां है?
अन्य प्रोग्रामर: मुझे नहीं पता, लेकिन हमें कुछ प्रयास करना होगा ।
मूल बातें। वर्तमान में प्रोग्रामर प्रौद्योगिकियां सीखते हैं, अवधारणाएं नहीं। यह गलत है।
Its wrong
होना चाहिए it's wrong
।
प्रत्येक प्रोग्रामर को पता होना चाहिए कि वह हर समय कोड में धारणाएं डाल रहा है, जैसे "यह संख्या सकारात्मक और परिमित होगी", "यह कोड पलक झपकते ही सर्वर से कनेक्ट हो जाएगा"।
और उसे पता होना चाहिए कि उन मान्यताओं के टूटने पर उसे तैयार करना चाहिए।
assert()
- हर जगह। assert()
आपकी मान्यताओं को दस्तावेज़ित करने में आपकी सहायता करेगा और गलत होने पर आपको बचाएगा।
प्रत्येक प्रोग्रामर को परीक्षण के बारे में पता होना चाहिए।
आलोचनात्मक और तार्किक सोच। आप इसके बिना कुछ भी अच्छा नहीं कर सकते।
आपके विचार से यह कठिन है।
हालांकि यह (ईश) कुछ ऐसा है जो सामान्य रूप से उपयोग किए जाने पर काम करता है, गलत इनपुट, सभी किनारे और कोने के मामलों, संभावित विफलता मोड आदि के साथ मुकाबला करने में समय लगता है और संभवतः नौकरी का सबसे कठिन हिस्सा होगा।
तो फिर आप आवेदन भी अच्छा लग रहे बनाने के लिए मिल गया है।
डोमेन की जानकारी। कल्पना कभी 100% नहीं होती है; उस वास्तविक डोमेन को जानना जिसके साथ आप विकसित कर रहे हैं, हमेशा उत्पाद की गुणवत्ता बढ़ाएगा।
बिग ओ अंकन और इसके निहितार्थ।
कुछ उपयोगी संदर्भ
संकेत, जाहिर है। :)
कोड पूरा 2 - कवर करने के लिए कवर
कोड की तुलना में डेटा अधिक महत्वपूर्ण है।
यदि आपका डेटा स्मार्ट है, तो कोड को डंबल किया जा सकता है।
गूंगा कोड को समझना आसान है। तो स्मार्ट डेटा है।
लगभग हर अल्गोरिमिक दु: ख जो मैं कभी भी गलत स्थान पर होने या उसके सही अर्थ के दुरुपयोग के कारण हुआ हूं। यदि आपके डेटा का अर्थ उस प्रकार के सिस्टम में है ।
विभाजन और जीत। यह आमतौर पर शेड्यूलिंग से डिबगिंग तक किसी भी प्रकार की व्यावहारिक समस्या को हल करने का सबसे अच्छा तरीका है।
सच्चा कौशल एक सरल डिजाइन को अच्छी तरह से निष्पादित करने की क्षमता में परिलक्षित होता है, न कि एक जटिल डिजाइन काम करने की क्षमता में।
यह कौशल मूल सिद्धांतों की अधिक निपुणता से आता है, न कि पुरातन की महारत में। एक उच्च-कैलिबर प्रोग्रामर को अन्य लोगों द्वारा कोड करने की उनकी क्षमता से परिभाषित नहीं किया जाता है (उच्च स्तर के कार्यों, उन्नत कार्यात्मक प्रोग्रामिंग, व्हाट्स-यू-यू का उपयोग करके) बल्कि पूरी तरह से सांसारिक कोडिंग को परिष्कृत करने की उनकी क्षमता में। कक्षाओं के बीच कार्यक्षमता का उचित अपघटन चुनना; मजबूती में निर्माण; रक्षात्मक प्रोग्रामिंग तकनीकों का उपयोग करना; और पैटर्न और नामों का उपयोग करके जो अधिक से अधिक स्व-प्रलेखन का नेतृत्व करते हैं, ये उच्च-कैलिबर प्रोग्रामिंग की रोटी और मक्खन हैं।
अच्छा कोड लिखना जो आप, या कोई और, एक महीने या एक सप्ताह में वापस आ सकते हैं और समझ सकते हैं कि उस कोड का उपयोग, संशोधन, वृद्धि या विस्तार कैसे किया जा सकता है। यह आपको समय और मानसिक प्रयास बचाता है। यह उन बाधाओं को दूर करके उत्पादकता के पहिये को कम कर देता है, जिन्हें आप पहले भी ठोकर खा चुके होते हैं (शायद आपकी ट्रेन की सोच बाधित होती है, या शायद दूसरे काम से घंटों या दिनों के प्रयास को दूर करना, आदि) इससे कठिन समस्याओं पर ध्यान केंद्रित करना आसान हो जाता है। , और कभी-कभी यह कठिन समस्याओं को दूर कर देता है।
एक शब्द में: लालित्य। हर वर्ग, हर विधि, हर स्थिति, हर ब्लॉक, हर चर नाम: लालित्य के लिए प्रयास करते हैं।
एक साफ-सुथरे उपयोगकर्ता अनुभव या बेहतर प्रलेखन के साथ तय किए जा सकने वाले उपयोगकर्ता पर कभी दोष न लगाएं। अक्सर, प्रोग्रामर स्वचालित रूप से मान लेते हैं कि उपयोगकर्ता एक बेवकूफ है जो कुछ भी सही नहीं कर सकता है, जब समस्या एक खराब समग्र अनुभव या संचार की कमी है। प्रोग्राम का उपयोग किया जाना है, और अवमानना के साथ उपयोगकर्ता का इलाज करना पहली जगह में प्रोग्रामिंग के बिंदु को याद करना है।
हर प्रोग्रामर कैसे डिबगर उपयोग करने के लिए पता है, और यह कैसे उपयोग करने के लिए पता होना चाहिए अच्छी तरह से ।
शॉर्ट-सर्किट मूल्यांकन, यह पहली बात है कि वे आपको बूलियन ऑपरेटरों के बारे में सिखाते हैं।
कोडिंग शैली मायने रखती है:
... और अच्छी डिजाइन मायने रखती है।
आदर्श रूप से, प्रोग्रामर अपनी पहली कोड समीक्षा से पहले (या उस दौरान) इन चीजों को सीखता है। सबसे खराब स्थिति में, प्रोग्रामर उन्हें सीखता है जब बॉस उसे / उसे जल्दी में कुछ भयानक कोड में कुछ गैर-तुच्छ परिवर्तन करने के लिए कहता है।