गैर-तुच्छ परियोजनाओं में डिजाइन की जटिलता से पेशेवर सॉफ्टवेयर विकास दल कैसे निपटते हैं?


9

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

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

अब, मैं खुद को एक टीम पर लीड पाता हूं, लेकिन कॉर्पोरेट वातावरण में नहीं - मैं इंजीनियरिंग अनुप्रयोगों के लिए वैज्ञानिक सॉफ्टवेयर (C ++ में) विकसित करने वाले विश्वविद्यालय के लिए काम करता हूं। अचानक यह परियोजना (अपेक्षाकृत) बड़ी हो रही है और मुझे ज्यादातर समय इसके दिमाग को लपेटने में परेशानी होती है। मैं ज्यादातर समय दो चीजों पर बहुत समय और प्रयास खो रहा हूं:

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

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

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

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

पढ़ने के लिए बहुत बहुत धन्यवाद, मैं यह कहने में असमर्थ था कि मैं और अधिक संक्षेप में क्या कह रहा हूं (सॉफ्टवेयर डिजाइन अनुभव और शब्दावली में कमी)।


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

जवाबों:


9

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

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

एक आदर्श दुनिया में, आपके पास एक डिज़ाइन दस्तावेज़ होगा जो सिस्टम में विभिन्न मॉड्यूल सेट करता है और उनकी संबंधित जिम्मेदारियों का वर्णन करता है, और आपके प्रत्येक मॉड्यूल उस दस्तावेज़ को वापस संदर्भित कर सकते हैं कि वे क्या करते हैं: "यह मॉड्यूल प्रदान करता है डिज़ाइन दस्तावेज़ के अनुभाग 4.8 में विस्तृत रूप में फ़ाबुलोट्रॉन डेटा संग्रह सेवा: http://fabulotron.org/design/section4-8.html । " यदि आपके पास ऐसा कुछ नहीं है, तो उस पर काम करते समय प्रत्येक मॉड्यूल का अवलोकन शुरू करें। आपको एक पुस्तक लिखने की आवश्यकता नहीं है - कुछ पैराग्राफ अक्सर आपको उन्मुख करने के लिए पर्याप्त होते हैं।

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

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

काश कुछ "आर्किटेक्चर आरेख" होता जहां मैं देख सकता था कि चीजें कैसे होती हैं

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

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


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

5

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

पहली चीजों में से एक जो मेरे पास थी, वह थी साफ बैठना और साफ कोड पढ़ना । यह एक शानदार पुस्तक है जिसने मुझे यह समझने में मदद की कि कोड कैसे लिखा जाए जिसे मैं समझ सकता था जब मैं इसे वापस गया या कोई और समझ सकता था।

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

मेरे मुख्य बिंदु परीक्षण और स्वच्छ कोड हैं।


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

2

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

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

इंजीनियरिंग सॉफ्टवेयर के साथ काम करते हुए मुझे बहुत समय हो गया है, इसलिए आपका सुझाव इन सुझावों पर भिन्न हो सकता है। सौभाग्य!


1

जवाब है सॉफ्टवेयर इंजीनियरिंग।

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

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

सभी मामलों में प्रक्रिया आपको यह निर्धारित करने में मदद करती है कि आप क्या कर रहे हैं, और, परियोजना के अंत की दिशा में आपको यह साबित करने में मदद करता है कि आपने इसे किया है।


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

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

@neuviemeporte: यह निर्भर करता है। कभी-कभी आवश्यकताएं बदल जाती हैं या विकास के दौरान नई आवश्यकताओं की खोज की जाती है। कभी-कभी आवश्यकताएं शुरू से ही काफी स्पष्ट होती हैं और केवल कुछ मामूली विवरण विकास के दौरान बदल जाएंगे लेकिन समग्र वास्तुकला समान रहेगी।
जियोर्जियो

1

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

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

सौभाग्य!


1

मेरा मानना ​​है कि आपकी समस्या के तीन आयाम हैं

  1. प्रोग्रामर उन्मुख
  2. कार्यक्रम उन्मुख
  3. कार्यक्रम रखरखाव - उन्मुख

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

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

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

  • फ्री माइंड - माइंड मैपिंग सॉफ्टवेयर
  • Trac - त्वरित और आसान सॉफ्टवेयर बग प्रोग्राम और एक विकी
  • MoinMoin - कार्यक्रम के बारे में ज्ञान साझा करने में सक्षम करने के लिए त्वरित विकी

हालांकि उपरोक्त युक्तियां कुछ सीखने की अवस्था को लंबे समय में इसके लायक बना लेंगी। और अंत में, प्रोग्रामिंग फोटोनिक इंजीनियरिंग की तुलना में आसान है (हालांकि सी ++ प्रोग्रामिंग नहीं)


0

आपके प्रश्न की तरह, आपके लिए उपयोगी कोई भी उत्तर बहुत लंबा और अस्पष्ट होगा - लेकिन संक्षिप्त उत्तर "सॉफ्टवेयर इंजीनियरिंग" है

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

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