मौजूदा codebase को Taiga में लाएँ
पूरा हुआRepository से Taiga जो जानकारी निकालता है उसका review करें। वर्तमान और इच्छित व्यवहार अलग रखें और गलत document पर सही प्रतिक्रिया चुनें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंImported document उस code का सही विवरण देता है जिसे आप बदलना चाहते हैं। उचित प्रतिक्रिया क्या है?अभ्यास करें
आप क्या सीखेंगे
- Imported product के लिए जुड़ी repository तैयार करें।
- Code defect, स्थायी instruction और analysis error का अंतर समझें।
- प्रस्तावित initiatives को वास्तविक कमियों और मौजूदा क्षमताओं से मिलाएँ।
मौजूद system से शुरू करें
काल्पनिक equipment request service पहले से है। Team उसकी काम करती integrations बनाए रखते हुए Taiga से उसका रखरखाव चाहती है।
Product बनाते समय Import codebase चुनें। Repository link करें और analysis शुरू करें। इस रास्ते में नए product की conversation की जगह repository analysis होता है। Scratch से बने product में यह import path बाद में नहीं जुड़ता।
Repository access और Taiga के काम करने वाली branch की पुष्टि करें। उचित context level पर स्थायी सीमाएँ जोड़ें। उदाहरण में बताएँ कि मौजूदा employee identity integration का उपयोग जारी रहना चाहिए।
पहले निकाली गई specification का review करें
Taiga code से product documents निकालता है और repository citations जोड़ता है। Citations अर्थ की जाँच में मदद करती हैं। वे हर मौजूदा pattern के पीछे business intent सिद्ध नहीं करतीं।
Specification में तीन बातें देखें:
- उद्देश्य: क्या बताया लक्ष्य service के मौजूद होने के कारण से मेल खाता है?
- सीमाएँ: कौन-से patterns जानबूझकर तय requirements हैं?
- ज्ञात दोष: कौन-से वर्तमान व्यवहार बदलने चाहिए?
Equipment service में legacy authorization module है। Document उसके उपयोग का सही विवरण दे सकता है। इससे यह अर्थ नहीं निकलता कि team को उसका उपयोग बढ़ाना चाहिए।
Cited file खोलें और संबंधित व्यवहार का दावे से मिलान करें। उपलब्ध प्रमाण की सीमाएँ दर्ज करें, जैसे repository के बाहर का configuration या operational behavior।
सही सुधार चुनें
| स्थिति | प्रतिक्रिया |
|---|---|
| Document अनचाहे code का सही विवरण देता है | Code change plan और build करें |
| Team का भविष्य के काम का स्थायी नियम है | नियम product instructions में रखें |
| Analysis ने repository गलत समझी | Refresh this document इस्तेमाल करें और परिणाम देखें |
Imported documents code के अनुसार होते हैं। उन्हें भविष्य की system के हाथ से maintained विवरण न मानें। Document refresh उन documents को भी दोबारा निकालता है जिन पर वह निर्भर है। इसलिए बाद वाला document refresh करने में अधिक काम हो सकता है।
Legacy module के लिए instruction हो सकता है: “Legacy authorization module में नए callers न जोड़ें। नए काम के लिए स्वीकृत replacement interface इस्तेमाल करें।” Interface मौजूद है, यह जाँचें और repository में उसकी वास्तविक जगह बताएँ।
पहली initiatives का आकलन करें
Import workflow repository scans, published policies के विरुद्ध assessment और शुरुआती initiative planning भी करता है। Prerequisite के बिना कोई stage कारण बताकर skip हो सकती है। Planning उपलब्ध findings और policy assessment इस्तेमाल करती है।
Proposed gaps का repository से मिलान करें। शुरुआती initiatives छूटी capabilities, foundations या संबंधित अनसुलझी dependency समस्याएँ सँभालती हैं। वे ऐसे नए features की सूची नहीं हैं जिन्हें किसी ने माँगा नहीं।
उपयोगी मौजूदा capability रखें। अनावश्यक रूप से उसे दोबारा बनाने वाला proposal अस्वीकार या ठीक करें। नई business requirement के लिए अलग initiative जोड़ें।
प्रमाण पर आधारित शुरुआत बनाए रखें
Discovery finish करें और initiative proposals का review करें। Detailed planning से पहले environment और delivery की जिम्मेदारियों की पुष्टि करें। काम आगे बढ़ने पर imports, code changes और product instructions में संगति रखें।
परिणाम समझी गई शुरुआती स्थिति और editable backlog है। यह घोषणा नहीं कि हर मौजूदा व्यवहार सही है। आगे initiative planning पढ़ें।
अभ्यास करें
Imported काल्पनिक service legacy authorization module इस्तेमाल करती है। उसके replacement की योजना पहले से है। नई dependencies रोकने वाला product instruction लिखें। फिर imported specification में एक repository citation चुनें जिसे आप जाँचेंगे।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।