एक डेवलपर को कितनी प्रक्रिया का पालन करना चाहिए? औपचारिक प्रक्रिया बहुत अधिक है?

Question

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

मैं अपनी खुद की परियोजनाओं पर आम तौर पर बहुत छोटी चीजें हूं, लेकिन मेरे पास कुछ विचार हैं जो एफओएसएस परियोजनाओं में बदल सकते हैं। मैं प्रलेखन (विशिष्ट परियोजना के आधार पर, विशिष्ट परियोजना और अंतिम उपयोगकर्ता के आधार पर), स्रोत नियंत्रण, और परियोजना प्रबंधन (बग ट्रैकिंग, समय प्रबंधन, आदि सहित) में विश्वास करता हूं। हालांकि, मुझे यकीन नहीं है कि formal process का मुझे कितना पालन करना चाहिए।

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

यदि मुझे औपचारिक प्रक्रिया की भी आवश्यकता है, तो एकल डेवलपर को किस प्रकार की प्रक्रियाएं लागू की जा सकती हैं या अपनाया जा सकता है?

---

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

Answer 1

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

यह नीचे उबलता है: आपको गड़बड़ करने की क्या संभावना है, और कौन सी प्रक्रियाएं आपके काम के विशेष तरीके से मदद करती हैं।

Answer 2

अपने दिल का पालन करें।

Answer 3

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

यह भी याद रखें कि वे "अन्य लोग" आप हो सकते हैं कुछ सालों में, जब आप अब जो कुछ भी जानते हैं उसे भूल गए हैं। (आप जवान हैं - आप अभी तक नहीं जानते कि कितनी जल्दी यादें गायब हो जाती हैं।) तो सोचें कि आप अपने भविष्य के लाभ के लिए क्या रिकॉर्ड करना चाहते हैं।

Answer 4

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

किसी भी महत्वपूर्ण परियोजना के लिए डिज़ाइन, डिज़ाइन निर्णय, संचालन आदि के बारे में दस्तावेज़ीकरण सभी महत्वपूर्ण है।

और परीक्षण, स्रोत नियंत्रण, आदि सभी अच्छे विकास प्रथाएं हैं और परियोजना के आकार के बावजूद किया जाना चाहिए।

Answer 5

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

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

Answer 6

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

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