2009-03-12 14 views
5

मुझे अपने प्रोग्रामिंग todo सूचियों को स्टोर करने का सबसे अच्छा तरीका पता लगाने में कुछ परेशानी है।क्या मुझे स्रोत नियंत्रण में टोडो सूचियां रखना चाहिए?

मैं निम्नलिखित पर विचार: प्रत्येक परियोजना

  • एक मास्टर कार्यसूची के लिए स्रोत नियंत्रण में

    • एक कार्यसूची (सामान्य कार्यों के साथ) एक व्यक्तिगत फ़ोल्डर में स्रोत नियंत्रण में

    कैसे क्या आपको वह मिल गया है?

    आप क्या सुझाव देंगे?

    संपादित करें:

    सुझावों के लिए धन्यवाद। मैं बग के लिए एक बग ट्रैकिंग सिस्टम (BugTracker.NET) का उपयोग करता हूं और उन कार्यों के लिए जिनमें अन्य लोगों के अनुरोध शामिल हैं जैसे कि वे स्थिति देख सकते हैं। और मैं कोड में // TODO का उपयोग करता हूं।

    मेरे पास क्या करना है इसके बारे में बहुत सारे अतिरिक्त नोट्स हैं। क्या आप इसे बग ट्रैकर में डालने की भी सिफारिश करेंगे (विशेष रूप से यदि उन्हें कोड में // TODO के रूप में रखना संभव नहीं है)?

  • +0

    हैं कार्य int किसी के लिए या सिर्फ आपके लिए करने के लिए समाप्त हो गया? –

    +0

    @ जेबी किंग: कार्य मुख्य रूप से मेरे लिए लक्षित हैं; लेकिन कुछ दूसरों के लिए भी हो सकता है। –

    उत्तर

    14

    आप एक बग ट्रैकिंग सिस्टम का उपयोग क्यों नहीं करते?

    उदाहरण: Bugzilla Mantis Trac

    और कई अन्य लोगों ...

    +0

    http://ifdefined.com/bugtrackernet.html एक अच्छा मुफ़्त है। – NikolaiDante

    +0

    ट्रैक, मंटिस, बगजिला सभी अच्छे हैं। आप TODO बनाम बग को भी वर्गीकृत कर सकते हैं (और संभावित रूप से उन्हें संबंधित) – basszero

    +0

    बगजिला खुला स्रोत है और सी # में लिखा गया है, क्या आप कार्यक्षमता को विस्तारित करना चाहते हैं। हमने अपने रखरखाव के काम के लिए इसे एक साल से भी अधिक समय तक इस्तेमाल किया है और इसके साथ कोई बड़ी समस्या नहीं है। –

    0

    आप किसी भी पाठ है कि स्रोत नियंत्रण में संशोधित हो जाता है रखना चाहिए। और इसमें जेनरेट कोड शामिल नहीं है (जब तक कि आपके पास क्रैपी जनरेटर नहीं है जिसे बिल्ड प्रक्रिया के हिस्से के रूप में नहीं चलाया जा सकता) और बाइनरी निर्भरताओं के उल्लेखनीय अपवाद के साथ सभी बाइनरी फ़ाइलें।

    4

    एक बग ट्रैकिंग प्रणाली के विकास के लिए एक महत्वपूर्ण उपकरण है।

    आप RtM जैसे एक साधारण वेब आधारित टोडो सूची भी प्राप्त कर सकते हैं।

    अंत में, आप अपने कोड में // TODO "बुकमार्क" का भी उपयोग कर सकते हैं, क्योंकि आईडीई आसानी से उन्हें ढूंढने के लिए कार्यक्षमता प्रदान करता है।

    0

    मैं ऑनटाइम 2008 का उपयोग करता हूं जिसमें मेरी विकास परियोजनाओं को ट्रैक करने के लिए एक निःशुल्क एकल डेवलपर (5 क्लाइंट तक) संस्करण है। बगजिला एक और अच्छा दृष्टिकोण होगा। निश्चित नहीं है कि मैं अपनी 'todo' सूची में हुए परिवर्तनों को ट्रैक करना चाहता हूं क्योंकि मुझे उन परिवर्तनों को पीछे हटाना नहीं चाहिए, मैं सभी गतिविधियों को दर्ज करना चाहता हूं, वार-सब-सब!

    5

    आपको अपने कोड में अपने टोडोस रखना चाहिए। पसंदीदा रूप से एक बगट्रैकिंग प्रोग्राम से जुड़ा हुआ है। और फिर आपको एक दस्तावेज उत्पादन कार्यक्रम का उपयोग करना चाहिए जो सभी टोडोस को पकड़ लेता है और कोड के प्रासंगिक हिस्सों के लिंक के साथ उन्हें एक सूची में लिखता है।

    एक अच्छा उदाहरण Doxygen है।कोड में कार्य करने को देखते हुए:

    // TODO: fix potential non-assigment of var 
    int my_var; 
    

    Doxygen इस जानकारी (आप भी फिल्टर मनमाना एनोटेशन के लिए, FIXME बग LOOK_HERE की तरह इतने पर की स्थापना की और कर सकते हैं) को खींचने के लिए सक्षम हो जाएगा और एक) विशिष्ट के लिए एक कार्य करने प्रविष्टि छोड़ना कक्षा/इंटरफेस और बी) पूरी परियोजना के लिए टोडोस की एक सूची संकलित करें।

    इसके अलावा, आपके todos और todo-list संस्करण नियंत्रित होंगे और सूचियां (यानी प्रलेखन) आसानी से खरोंच से उत्पन्न होती हैं।

    तो, योग के लिए: Doxygen का संयोजन, एक एसएमएम सिस्टम (any करेगा) और bugzilla आपको किसी भी समय मिल जाएगा और चल रहा है।

    अद्यतन: this git hook की जाँच करें Todos से Github मुद्दों बनाता है कि आपके चेकइन

    और चाहे या नहीं अपने कोड में Todos का उपयोग करने का सवाल करने के लिए एक सामान्य टिप्पणी में एक अच्छी बात (टीएम) है: एक मूर्ख एक उपकरण के साथ अभी भी एक मूर्ख है।

    +0

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

    +0

    @ v.oddou: इस (काफी सरल) योजना में पूरा बिंदु यह है कि प्रत्येक मुद्दे पर फिर से विचार करने के लिए बाधा कम रखी जाती है। यदि एक एकल टोडो एक प्रमुख रिफैक्टरिंग की गारंटी देता है, तो मुझे लगता है कि यह बहुत अच्छा है कि इस मुद्दे को प्रकाश में रखा गया है। रिफैक्टरिंग की आवश्यकता सिर्फ इसलिए नहीं चली जाएगी क्योंकि कोई TODO चिह्नित नहीं है। – Steen

    2

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

    महत्वपूर्ण बात यह है कि इस तथ्य को खोना नहीं है कि कुछ करने की जरूरत है!

    बाद में, मैं वापस जाऊंगा और अपने मुद्दे ट्रैकिंग सॉफ्टवेयर में टिकट बनाउंगा .. आप समस्या ट्रैकिंग सॉफ्टवेयर का उपयोग कर रहे हैं? :) उसके बाद, कोड से TODO को हटाया जा सकता है।

    एक लगातार टिप्पणी टैग का उपयोग करने का प्रयास करें ताकि आप आसानी से उन्हें बाद में (टेक्स्ट खोज) grep कर सकें।

    कई विकास पर्यावरण विशेष टैग पहचानते हैं और उन्हें ढूंढने और प्रबंधित करने में सहायता करते हैं।

    उन्हें कोड में रखने से डरो मत और एक ही TODO की दो अलग-अलग प्रतियों को बनाए रखने की कोशिश न करें।

    0
    1. प्रत्येक प्रोजेक्ट के लिए स्रोत नियंत्रण में एक todo सूची। थोड़ी सी देखभाल के साथ, यह आपका Scrum burndown डेटा बन जाता है। थोड़ा कट और पेस्ट प्रबंधन के लिए उपयोग करने के लिए एक चार्ट बनाता है।

    2. कोड में स्पष्ट TODO टिप्पणियां - इन को टोडो सूची से मेल खाना चाहिए। आवधिक मैनुअल सिंक्रनाइज़ेशन और प्राथमिकता महत्वपूर्ण है।

    3. Bugzilla बग ट्रैकिंग के लिए (से अलग दूरंदेशी कार्य करने की)

    1

    आप TFS का उपयोग करते हैं, आप काम आइटम का उपयोग करने के कार्यसूची आइटम प्रतिनिधित्व करने के लिए मिलता है। वे लोगों को करने के लिए सौंपा जा सकता है, चेक-इन के साथ जुड़े, उन्हें संलग्न विवरण, आदि

    0

    मैं Basecamp HQ

    प्यार तुम वहाँ के बारे में परियोजना प्रबंधन से बहुत कुछ नियंत्रित कर सकते हैं।

    मैं उस साइट की अनुशंसा करता हूं।

    1

    हां यदि आपके पास कोई समस्या ट्रैकिंग सिस्टम नहीं है। सुनिश्चित करें कि यह एक सादा पाठ प्रारूप (न्यूलाइन सीमांकित मुद्दों) में है, इसलिए सभी एक ही समय में फ़ाइल को संपादित-प्रतिबद्ध-विलय कर सकते हैं।

    अन्यथा बस एक समस्या ट्रैकर प्राप्त करें।

    0

    ग्रहण (जावा के लिए) में, वहाँ आप अपने TODOS का प्रबंधन करते हैं कि एक बहुत अच्छा दृश्य है:

    • उन सभी को देखने के लिए, जो कुछ भी (खुला) परियोजना वे पर हैं
    • तीन प्राथमिकता स्तर है उन्हें
    • उपयोग से कई कीवर्ड्स, अपनी टीम के लिए अलग अलग बातें अर्थ के लिए (उदाहरण के लिए, FIXME उच्च प्राथमिकता के साथ तत्काल हो सकता बढ़ा एक कम प्राथमिकता आदि के विस्तार के लिए एक भविष्य संभावना हो सकता है ..)
    संबंधित मुद्दे

     संबंधित मुद्दे