आप सॉफ्टवेयर इंजीनियरिंग के पवित्र कंघी बनानेवाले की रेती के लिए पूछ रहे हैं, और इस सवाल का जवाब अभी तक किसी के पास नहीं है।
यह आवश्यक है कि आप उन त्रुटियों के प्रकारों को ट्रैक करें जो आप कर रहे हैं और फिर उन त्रुटियों का विश्लेषण करें ताकि यह निर्धारित किया जा सके कि क्या एक सामान्य प्रवृत्ति है। मूल कारण विश्लेषण इस प्रकार के आत्मनिरीक्षण का औपचारिक नाम है, और इसके बारे में वेब पर बहुत सारी सामग्री है।
पेशेवर बग ट्रैकिंग सिस्टम का उपयोग करते हैं ताकि वे (1) जान सकें कि क्या तय करना है, लेकिन यह भी (2) विश्लेषण करें कि वास्तव में क्या तय किया जाना था। आपको इतना औपचारिक होने की आवश्यकता नहीं है - बस एक नोटबुक में एक मिलान रखना आपके लिए ठीक हो सकता है।
डिजाइन चरण दोष
यदि आप पाते हैं कि आपकी अधिकांश त्रुटियां समस्या कथन की गलतफहमी से आती हैं, या यदि आप पाते हैं कि आपने अपनी समस्याओं को हल करने के लिए गलत एल्गोरिथम या रास्ता चुना है, तो आपको डिजाइन चरण में समस्याएं हैं।
यह परियोजना की शुरुआत में अधिक समय लेने के लिए आपको बताना होगा और लिखना होगा कि क्या किया जाना चाहिए और इसे कैसे करना चाहिए। इस काम की सावधानीपूर्वक समीक्षा करें और मूल समस्या को फिर से देखें और निर्धारित करें कि क्या आप वास्तव में सही तरीके से निपट रहे हैं। शुरुआत में एक अतिरिक्त घंटा या तीन आपको सड़क से कई घंटे बचा सकता है।
कोडिंग त्रुटियां
यदि आपका डिज़ाइन ठोस है, लेकिन आप लगातार उस भाषा से लड़ रहे हैं जिसके साथ आप कोडिंग कर रहे हैं, तो अपने आप को कुछ उपकरण प्राप्त करें जो आपके लिए आपके कोड का विश्लेषण करेंगे और आपको जल्दी और अक्सर चेतावनी देंगे कि आप गलतियाँ कर रहे हैं।
यदि आप C में प्रोग्रामिंग कर रहे हैं, तो सभी संकलक चेतावनियों को चालू करें lint, जैसे अर्थ-चेकर का उपयोग करें, और valgrindसामान्य डायनेमिक-मेमोरी से संबंधित समस्याओं को पकड़ने के लिए जैसे टूल का उपयोग करें ।
यदि आप पर्ल प्रोग्रामिंग कर रहे हैं, तो चालू करें strictऔर warningsयह कहते हैं कि यह क्या कहता है।
कोई फर्क नहीं पड़ता कि आप किस भाषा का उपयोग कर रहे हैं, संभवतः डिबगिंग चरण तक पहुँचने से पहले सामान्य गलतियों को पकड़ने में मदद करने के लिए कई उपकरण मौजूद हैं।
एकीकरण चरण दोष
जैसे ही आप अच्छी मॉड्युलैरिटी प्रथाओं का पालन करते हुए अपना कोड विकसित करते हैं, आपको अलग-अलग टुकड़ों को एक साथ जोड़ना शुरू करना होगा। उदाहरण के लिए, आपके कोड के विभिन्न अनुभागों को उपयोगकर्ता इनपुट, डेटाबेस इंटरैक्शन, डेटा डिस्प्ले, एल्गोरिदम / तर्क के साथ करना पड़ सकता है, और इनमें से प्रत्येक को एक दूसरे से अपेक्षाकृत स्वतंत्र बनाया गया है (यानी, आप हाथ में अनुभाग पर ध्यान केंद्रित करते हैं। सब कुछ के साथ एकीकरण के बारे में चिंता करने के बजाय)।
यहाँ है जहाँ परीक्षण संचालित विकास (TDD) बहुत काम आता है। आपके कोड के प्रत्येक मॉड्यूल में परीक्षण हो सकते हैं जो यह सत्यापित करते हैं कि वे कैसे डिजाइन किए गए थे उसी के अनुसार काम करते हैं। इन परीक्षणों को या तो पहले या बहुत पहले प्रक्रिया में लिखा जाना चाहिए ताकि आपको ईमानदार रखने के लिए "सहायकों" का एक सेट हो सके। जब आप सब कुछ एक साथ काम करना शुरू करते हैं, और आप पाते हैं कि आपको यह बदलना है कि यह कैसे लागू होता है या किसी अन्य उप-प्रणाली के साथ सहभागिता करता है, तो आप यह सुनिश्चित करने के लिए अपने परीक्षणों पर वापस गिर सकते हैं कि आपने क्या किया है यह सब मिलकर काम करने से कोड की शुद्धता नहीं टूटती।
और इसी तरह...
सॉफ़्टवेयर इंजीनियरिंग और व्यावहारिक कोडिंग तकनीकों पर कुछ किताबें चुनें, और आप विकास को कम अराजक और अधिक विश्वसनीय बनाने के कई अलग-अलग तरीके सीखेंगे। आपको यह भी पता चलेगा कि बस सादा पुराना अनुभव - हार्ड नॉक के स्कूल से डिग्री प्राप्त करें - आपको आकार में भी मिलेगा।
लगभग जो कुछ भी उबलता है वह यह है कि थोड़ा समय और काम के बाद विकास / रिलीज की प्रक्रिया में बाद में भारी लाभांश का भुगतान होता है।
यह तथ्य कि आपने अपने करियर में इतनी जल्दी इन मुद्दों पर गौर किया है, आपके भविष्य के लिए अच्छा है, और मैं आपको शुभकामनाएं देता हूं।