एक एकल प्रोग्रामर के लिए सॉफ्टवेयर विकास में सर्वोत्तम / प्रसिद्ध प्रथाओं का न्यूनतम सबसेट क्या है? [बन्द है]

Question

मैं काफी समय से अपने काम में अकेला प्रोग्रामर रहा हूं। आमतौर पर मैंने लेख और पोस्ट पढ़े हैं

• संस्करण नियंत्रण प्रणाली
• सतत एकीकरण / वितरण
• विकास के तरीके: स्क्रम, झरना, वी-मॉडल, फुर्तीली, एक्सपी, आदि।
• सॉफ्टवेयर परियोजना प्रबंधन

लेकिन उनमें से लगभग सभी टीम पर केंद्रित हैं। मैं एक टीम नहीं हूं, इसलिए सिर्फ एक प्रोग्रामर के लिए प्रथाओं का बिल्कुल न्यूनतम सेट क्या होगा? निम्नलिखित स्थितियों पर विचार करें:

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

मेरा विचार यह है कि मैं किसी भी चीज़ में समय और ऊर्जा खर्च नहीं करना चाहता, जिसका सीधा संबंध ग्राहकों की आवश्यकताओं से नहीं है। कोई सिफारिशें?

Comments

जंगली में आपके पास कितने रिलीज़ हैं जिनके लिए आपको बग फिक्स करने की आवश्यकता है?

के संभावित डुप्लिकेट एक स्वतंत्र डेवलपर के लिए नंगे न्यूनतम और की एक डेवलपर के लिए डिजाइन और विकास के तरीके

— कुटकी

Answer 1

इस सवाल का कोई सही जवाब नहीं है क्योंकि यह प्रत्येक व्यक्ति पर निर्भर करता है। यदि आप अपने सभी देव कार्यों को करने के लिए एक iPad का उपयोग करते हैं और आपके ग्राहक आपसे खुश हैं, तो आपके पास बदलने का कोई कारण नहीं है।

यदि, हालांकि, मैं आपकी स्थिति में था, तो मैं निम्नलिखित बातों को दृढ़ता से लागू करूंगा:

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

Comments

+2 फुर्तीली और परियोजना प्रबंधन के लिए। हालाँकि, प्रायोगिक सुविधाओं के लिए, मैं आमतौर पर एक आभासी-छवि (जो ब्रांचिंग के बराबर होगी) को फोर्क करता हूं और अंत में अपने वातावरण का एक और उदाहरण खोलता हूं। आपके अच्छे उत्तर के लिए धन्यवाद।

— user869097

Answer 2

संस्करण नियंत्रण किसी भी प्रोग्रामर के लिए एक अकेला भी एक निरपेक्ष होना चाहिए। इसका मतलब है कि आप हटाए गए फ़ाइलों और जटिल परिवर्तनों से बस और जल्दी से ठीक हो सकते हैं जो कि गलत हैं।

मूल रूप से यह आपको बेवकूफ बकवास से बचाता है जब आप लटकाए गए काम पर जाते हैं।

Comments

यह एकमात्र लाभ नहीं है। मुख्य लाभों में से एक सॉफ्टवेयर के पुराने संस्करण को पुन: पेश करने में सक्षम हो रहा है। और यह तब उपयोगी होता है जब किसी समस्या की पुनरावृत्ति करने की कोशिश की जाती है और / या किसी समस्या के शुरू होने के समय का निर्धारण किया जाता है।

— मार्जन वेनेमा

प्लस 1 क्योंकि यह मेरी भूख मस्तिष्क को बचाया है, इसलिए कई बार।

— निकोलस स्मिथ

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

— तमसे सजेलेई

यदि आप उपयोगी चेक-इन टिप्पणियों को लिखते हैं, तो यह आपको इस प्रश्न का उत्तर देने के लिए समय का एक शानदार तरीका देता है "जब मैंने कबाड़ के इस ढेर को लिखा था तो मैं क्या सोच रहा था?"

— नेड

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

— पीटर टेलर

Answer 3

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

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

Answer 4

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

Answer 5

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

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