2009-08-21 9 views
6

टीमों और/या बड़ी परियोजनाओं पर काम करते समय मैं चुस्त विधियों का एक बड़ा वकील हूं।छोटी परियोजनाओं पर काम कर रहे सोलो: काउबॉय कोडिंग करने का रास्ता?

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

क्या अन्य लोग मेरी भावना साझा करते हैं? या क्या आपको लगता है कि किसी को अपनी बंदूकें कभी नहीं रहना चाहिए (इसे प्राप्त करें? काउबॉय)?

तो असली सवाल: क्या कोई ऐसी चुस्त प्रक्रिया है जो विशेष रूप से एकल परियोजना के अनुरूप होती है? (उपरोक्त मेरे "चुस्त काउबॉय" विधि के अलावा)

उत्तर

4

Agile एक दर्शन है, एक पर्चे नहीं। आप उन टुकड़ों का उपयोग करते हैं जो आपकी विकास शैली, आपकी परियोजना और आपकी व्यावसायिक आवश्यकताओं के अनुरूप हैं।

मुझे लगता है कि आपका "परीक्षण अक्सर मानव-पठनीय कोड लिखें" प्रस्ताव छोटी परियोजनाओं के लिए एकल टीम पर अच्छा सॉफ्टवेयर बनाने के लिए एक बिल्कुल उपयुक्त दृष्टिकोण है।

+0

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

+0

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

1

काउबॉय कोडिंग और फुर्तीली प्रक्रिया समान नहीं है।

छोटी निजी परियोजनाओं के लिए, निश्चित रूप से ऐसी कई चीजें हैं जो अधिक हो जाएंगी। Agile विकास, लघु पुनरावृत्तियों, लगातार कोड समीक्षा और स्वयं दस्तावेज कोड जाने का रास्ता है।

+0

मैं स्वीकार करूंगा कि जब मैं इस मोड में जाता हूं तो मैं लंबे पुनरावृत्तियों का दोषी हूं। मैं आमतौर पर बहुत देर हो चुकी है इससे पहले कि मैं खुद को पकड़ लेता हूं। – snicker

2

आप c2.com के सोलो Programming Xp Workarounds पर देख सकते हैं। Cardboard Programmer किसी कारण से मुझे विशेष रूप से मनोरंजक लगता है। आप शायद आपके बगल में एक कार्डबोर्ड जॉन स्कीट के साथ कोड कर सकते हैं?

+2

मैं यहां अद्भुत व्यावसायिक अवसरों की गंध करता हूं। जॉन के साथ एक विशेष सौदा सुरक्षित करने वाले पहले व्यक्ति कौन होंगे? ;) –

+0

रबर डकिंग को बेकार मत करो: http://c2.com/cgi/wiki?RubberDucking –

+0

मैं कुत्ते से बात करता था, वास्तव में, इसलिए मुझे इसमें वैधता मिलती है। – snicker

0

मैं वर्तमान में एएसपी.NET प्रोजेक्ट पर अकेले काम कर रहा हूं (हालांकि एक छोटा सा नहीं)। मैं टीडीडी का काफी उपयोग करता हूं, और मुझे लगता है कि टीडीडी का उपयोग करके इसे विकसित करने में लंबा समय नहीं लग रहा है, वास्तव में मैं समय बचाता हूं।

यह मुख्य रूप से है क्योंकि यूनिट परीक्षणों का सूट होने से सिस्टम को परीक्षण और डीबग करने में बहुत तेज़ हो जाता है। जैसे जब कोई सुविधा इरादे से काम नहीं कर रही है, तो डीबग मोड में वेब सर्वर शुरू करने के बजाय डीबगर को एनयूनीट प्रक्रिया में संलग्न करना बहुत तेज़ है, सही पृष्ठ पर जाकर (पहले लॉगिन स्क्रीन पास करना) इत्यादि। तो यूनिट परीक्षण नहीं होने के कारण, मैं लंबे समय तक परीक्षण और डिबगिंग का एक बड़ा सौदा खर्च करूंगा।

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

0

मैं कहूंगा कि परियोजना पर काम करने वाले लोगों की संख्या पर विचार करने का एकमात्र कारक नहीं है। मुझे लगता है कि आपको पूर्ण एग्इल (दस्तावेज, रिफैक्टरिंग, यूनिट टेस्ट ..........) संभवतः Agile नहीं है, हालांकि, वे लंबे समय तक रहे हैं) समय होने के कारण -वास्टिंग इसलिए है क्योंकि एकल परियोजनाएं छोटी परियोजनाएं होती हैं।

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