कोड रिफ़ैक्टरिंग के लिए प्रॉम्प्ट टेम्पलेट
सुरक्षित रिफ़ैक्टरिंग के लिए दोबारा इस्तेमाल होने वाले AI प्रॉम्प्ट टेम्पलेट, जो व्यवहार सुरक्षित रखते हैं, दायरा सीमित करते हैं, टेस्ट माँगते हैं और सत्यापन परिभाषित करते हैं।
सुरक्षित रिफ़ैक्टरिंग प्रॉम्प्ट AI कोडिंग सहायक को बताता है कि कौन-सा व्यवहार बचाए रखना है, कहाँ काम करना है, कौन-से टेस्ट contract परिभाषित करते हैं और परिणाम को कैसे सत्यापित करना है। “इसे साफ़ करें” रिफ़ैक्टरिंग योजना नहीं है। यह उन चीज़ों को बदलने का निमंत्रण है जिनकी आपने समीक्षा नहीं की है।
इन टेम्पलेट को शुरुआती बिंदु की तरह इस्तेमाल करें। कोष्ठक में दिए विवरण अपने codebase के तथ्यों से बदलें और व्यापक बदलाव से पहले विश्लेषण माँगें।
टेम्पलेट: सुरक्षित रिफ़ैक्टरिंग
[specific maintainability
problem] सुधारने के लिए [component/module/function] का रिफ़ैक्टर करें।
व्यवहार संरक्षण: [public API, visible behavior, events, error
handling, accessibility, performance characteristic] अपरिवर्तित रखें।
दायरा: बदलाव को [files/boundary] तक सीमित रखें। [explicit non-goals] न बदलें।
टेस्ट: मौजूदा contract सिद्ध करने वाले tests पहचानें। यदि कोई सुरक्षित व्यवहार कवर नहीं है
तो केंद्रित regression coverage जोड़ें।
स्वीकृति मानदंड: डुप्लिकेशन या coupling घटता है, सार्वजनिक व्यवहार
अपरिवर्तित रहता है और diff में असंबंधित cleanup नहीं होता।
सत्यापन: [focused test command], type check और [manual workflow] चलाएँ।
संपादन से पहले वर्तमान contract और सबसे छोटे सुरक्षित extraction का वर्णन करें।
जब आप सुधार जानते हों लेकिन स्थिर feature boundary सुरक्षित रखना चाहते हों, तब इसका उपयोग करें।
टेम्पलेट: component निकालना
[parent components] से बार-बार आने वाले [UI region] को सबसे छोटे
दोबारा इस्तेमाल होने वाले component में निकालें।
व्यवहार संरक्षण: दिखाई देने वाले labels, keyboard focus, aria attributes,
loading state, analytics events और mobile layout समान रखें।
दायरा: केवल [parent components], नया component और सीधे tests। data fetching या
mutation ownership को निकाले गए component में न ले जाएँ।
टेस्ट: [empty, loading, error, populated] states और उपयोगकर्ताओं के भरोसे वाले
interactive behavior के tests सुरक्षित रखें या जोड़ें।
स्वीकृति मानदंड: parents नए component का उपयोग करते हैं, भिन्न व्यवहार
स्पष्ट रहता है और कोई public props या links अनपेक्षित रूप से नहीं बदलते।
सत्यापन: केंद्रित component tests चलाएँ, desktop और mobile widths पर rendered states जाँचें,
और ऐसा व्यवहार बताएँ जिसे सत्यापित नहीं किया जा सका।
कुछ भी निकालने से पहले मौजूदा अंतरों का विश्लेषण करें।
ownership वाली पंक्ति visual extraction को state-management rewrite के साथ मिलाने की आम गलती रोकती है।
टेम्पलेट: डुप्लिकेशन घटाना
[list of files] में duplicated logic खोजें और सबसे छोटा
shared abstraction प्रस्तावित करें।
व्यवहार संरक्षण: हर caller का public behavior, default values,
error handling, telemetry और timing सुरक्षित रखें।
दायरा: इन callers के बाहर generalize न करें। जब अंतर आकस्मिक डुप्लिकेशन के बजाय
product rules दर्शाते हों, तो उन्हें दिखाई देता रहने दें।
टेस्ट: हर मौजूदा test को उसके सुरक्षित किए गए shared behavior से मैप करें। हर
अर्थपूर्ण divergence के लिए एक test जोड़ें।
स्वीकृति मानदंड: repeated logic केवल वहाँ centralize होता है जहाँ contract
वास्तव में समान है; callers पठनीय और व्यवहार में समान रहते हैं।
सत्यापन: callers के केंद्रित tests चलाएँ और उनके देखे जा सकने वाले output की
पहले और बाद में तुलना करें।
कोड से पहले common और intentional differences का विश्लेषण लौटाएँ।
shared code अपने-आप बेहतर नहीं होता। प्रॉम्प्ट को सहायक से सिद्ध कराना चाहिए कि व्यवहार सच में साझा है।
टेम्पलेट: performance रिफ़ैक्टरिंग
[screen/workflow] में performance problem की जाँच करें।
साक्ष्य: [measurement, trace, timing, user report, or reproducible scenario].
[memoization/caching/code splitting] को उत्तर न मानें।
व्यवहार संरक्षण: उपयोगकर्ता को दिखने वाले loading, freshness, accessibility,
authorization और error behavior अपरिवर्तित रखें।
दायरा: पहले [paths] जाँचें। मापी हुई आवश्यकता के बिना persistent caching, नई state
library या server dependency न जोड़ें।
टेस्ट: मौजूदा behavior tests बनाए रखें। regression या measurement check केवल तब जोड़ें
जब project में उसके लिए स्थिर convention हो।
स्वीकृति मानदंड: bottleneck का नाम दें, baseline और परिणाम दिखाएँ और
सुरक्षित व्यवहार बरकरार रखें।
सत्यापन: प्रासंगिक tests चलाएँ, सहमत measurement दर्ज करें और
freshness या memory जैसे tradeoffs दस्तावेज़ित करें।
यह टेम्पलेट optimization को technique-driven के बजाय evidence-driven बनाता है।
टेम्पलेट: legacy-code रिफ़ैक्टरिंग
[legacy module] का रिफ़ैक्टर करें ताकि [specific risk or maintenance cost]
उसके बाहरी रूप से देखे गए व्यवहार को बदले बिना घटे।
व्यवहार संरक्षण: वे legacy inputs, outputs, error modes, side
effects, file formats और compatibility requirements सूचीबद्ध करें जिन पर clients निर्भर हैं।
दायरा: [module/boundary] के भीतर काम करें। असंबंधित dependencies upgrade न करें या
उसी बदलाव में callers को rewrite न करें।
टेस्ट: जहाँ coverage नहीं है वहाँ पहले tests या fixtures से वर्तमान व्यवहार को
characterize करें। ज्ञात edge cases और malformed input शामिल करें।
स्वीकृति मानदंड: नई संरचना के बारे में तर्क करना आसान है,
characterized behavior स्थिर रहता है और compatibility notes स्पष्ट हैं।
सत्यापन: characterization tests, मौजूदा integration tests, type check,
और एक प्रतिनिधि manual या command-line scenario चलाएँ।
कार्यान्वयन प्रस्तावित करने से पहले अज्ञात व्यवहार और जोखिम समझाएँ।
legacy code के लिए, अटपटे मौजूदा व्यवहार को कैप्चर करने वाला test अधिक साफ़ दिखने वाले rewrite से अधिक मूल्यवान हो सकता है।
टेम्पलेट: बड़ी रिफ़ैक्टरिंग
[target architecture] हासिल करने के लिए [system] के staged refactor की योजना बनाएँ।
व्यवहार संरक्षण: [public APIs, data compatibility, permissions,
user workflows, deployment behavior, and rollback path] बनाए रखें।
दायरा: काम को स्वतंत्र रूप से जाँचे जा सकने वाले milestones में बाँटें। वे files पहचानें
जो पहले milestone में नहीं बदलनी चाहिए।
टेस्ट: हर milestone के अगले चरण से पहले पास होने वाले focused tests, contract tests, migration checks
और manual workflows परिभाषित करें।
स्वीकृति मानदंड: हर stage की स्पष्ट entry condition, देखा जा सकने वाला परिणाम,
rollback strategy और बाद के stage पर कोई छिपी निर्भरता नहीं होती।
सत्यापन: वर्तमान architecture के सामने योजना की समीक्षा करें, हर stage की
checks चलाएँ और यदि कोई milestone मूल धारणा अमान्य करे तो रुकें।
जब तक stages, risks और alternatives प्रस्तुत न कर दें, कोड न संपादित करें।
यह planning prompt है, एक विशाल patch का अनुरोध नहीं। यह reviewers को अर्थपूर्ण checkpoints देता है।
रिफ़ैक्टरिंग भी उत्पाद का काम है
रिफ़ैक्टरिंग interaction तोड़ सकती है, event खो सकती है, authorization decision कमज़ोर कर सकती है या उपयोगकर्ता को दिखने वाली string का गलत अनुवाद कर सकती है। जैसे आप कोड सुधारते हैं, वैसे ही जानबूझकर व्यवहार सुरक्षित रखें।
मूल संरचना के लिए बेहतर AI प्रॉम्प्ट कैसे लिखें का उपयोग करें। काम किए हुए उदाहरणों के लिए सॉफ़्टवेयर इंजीनियरों के लिए प्रॉम्प्ट इंजीनियरिंग के उदाहरण पढ़ें। यदि रिफ़ैक्टरिंग किसी production incident से शुरू होती है, तो उसे production issues को डीबग करने के प्रॉम्प्ट टेम्पलेट के साथ जोड़ें।
जब रिफ़ैक्टर किसी script को बदलता हो, तो पहले उसके सुरक्षित रखे जाने वाले commands सत्यापित करें। ब्राउज़र में terminal workflows का अभ्यास करें, ताकि सत्यापन याददाश्त पर नहीं, input और output पर आधारित हो।
संदर्भ
ये दस्तावेज़ लिंक इस लेख में उपयोग किए गए कमांड के लिए आधिकारिक विवरण प्रदान करते हैं।