AI உருவாக்கிய குறியீட்டை எப்படி மதிப்பாய்வு செய்வது

AI உருவாக்கிய குறியீட்டை மதிப்பாய்வு செய்ய, எந்த வரியையும் படிப்பதற்கு முன் என்ன மாறியது — எந்தக் கோப்புகள், ஏன் — என்பதிலிருந்து தொடங்குங்கள், பின்னர் நடத்தையை நீங்களே சோதியுங்கள். அதன்பின், AI குறியீடு பெரும்பாலும் தவறாகும் பகுதிகளைச் சரிபாருங்கள்: சேவையகப் பக்க அனுமதிச் சரிபார்ப்புகள் இல்லாதது, உலாவிக்குத் தெரியும் ரகசியங்கள், சரிபார்க்கப்படாத உள்ளீடு, இல்லாத packages அல்லது functions, நீங்கள் தொடச் சொல்லாத விஷயங்களில் திருத்தங்கள்.

AI எழுதும் குறியீடு பொதுவாக இயங்கும், பெரும்பாலும் நேர்த்தியாகவும் தோன்றும். அதனால் உண்மையில் சரிபார்க்காமல் அங்கீகரிப்பது எளிது. இந்த வழிகாட்டி, நீங்கள் குறியீட்டை சரளமாகப் படித்தாலும் சரி, முற்றிலும் படிக்காவிட்டாலும் சரி, வேலை செய்யும் ஒரு மதிப்பாய்வு நடைமுறை.

ஆபத்துக்கு ஏற்ப மதிப்பாய்வை அளவிடுங்கள்

ஒவ்வொரு மாற்றத்திற்கும் ஒரே கவனம் தேவையில்லை.

படி 1: என்ன மாறியது எனப் பாருங்கள்

குறியீட்டை மதிப்பிடுவதற்கு முன், மாற்றங்களின் பட்டியலைப் பெறுங்கள்:

• திட்டம் Git இல் இருந்தால், diff ஐப் பாருங்கள்: கடைசி commit இலிருந்து மாறிய கோப்புகளும் வரிகளும். AI-built ஆப்புடன் Git ஐ எப்படிப் பயன்படுத்துவது ஐப் பாருங்கள்.
• அல்லது நேரடியாக AI இடம் கேளுங்கள்:

கடைசி மாற்றத்தில் நீங்கள் மாற்றிய ஒவ்வொரு கோப்பையும் பட்டியலிடுங்கள், ஒவ்வொன்றுக்கும் என்ன மாறியது, ஏன் என்று ஒரு வாக்கியத்தில் விளக்குங்கள்.

இந்த நிலையில் சிவப்புக் கொடிகள்: கோரிக்கையுடன் தொடர்பில்லாத கோப்புகள், நீக்கப்பட்ட கோப்புகள், நீங்கள் கேட்காத configuration அல்லது dependencies மாற்றங்கள்.

படி 2: முதலில் நடத்தையைச் சோதியுங்கள்

குறியீட்டைப் படிப்பது அது எதைச் செய்ய உத்தேசிக்கப்பட்டது என்று சொல்லும்; சோதிப்பது அது உண்மையில் என்ன செய்கிறது என்று சொல்லும். படிப்பதற்கு முன்:

• desktop மற்றும் தொலைபேசி அளவுத் திரையில், ஒரு சாதாரணப் பயனராக மாற்றத்தை முயற்சியுங்கள்.
• தவறான உள்ளீட்டுடன் முயற்சியுங்கள்: வெற்றுப் புலங்கள், மிக நீண்ட உரை, எதிர்மறை எண்கள், கடந்த தேதி.
• உள்நுழையாமல், வேறொரு பயனராக முயற்சியுங்கள்.
• மிக முக்கியமான flows ஐ மீண்டும் இயக்குங்கள்: பதிவுசெய்தல், உள்நுழைவு, முக்கியச் செயல், கட்டணம்.

சோதனை தோல்வியடைந்தால், படிக்கும் நேரத்தை மிச்சப்படுத்திவிட்டீர்கள் — அதைத் தெளிவாகத் தெரிவித்து AI சரிசெய்ய விடுங்கள். நல்ல பிழை அறிக்கை எழுதுவது எப்படி ஐப் பாருங்கள்.

படி 3: சேவையகத்தில் அனுமதிகளைச் சரிபாருங்கள்

சரிபார்க்க வேண்டிய மிக முக்கியமான விஷயம் இதுவே. AI கருவிகள் பெரும்பாலும் பக்கத்தில் ஒரு பொத்தானை மறைத்துவிடுகின்றன, ஆனால் யாராவது கேட்டால் அந்தச் செயலைச் செய்யத் தயாராக சேவையகத்தை விட்டுவிடுகின்றன.

தரவைப் படிக்கும் அல்லது மாற்றும் ஒவ்வொரு route அல்லது function க்கும் கேளுங்கள்:

• பயனர் உள்நுழைந்துள்ளாரா என்று சரிபார்க்கிறதா?
• இந்தப் பயனர் இந்தப் பதிவை அணுக அனுமதிக்கப்பட்டவரா என்று சரிபார்க்கிறதா?
• அந்தச் சரிபார்ப்பு சேவையகத்தில் உள்ளதா, பக்கத்தில் மட்டும் அல்லவா?

நீங்கள் சேர்த்த அல்லது மாற்றிய ஒவ்வொரு API route க்கும், சேவையகத்தில் அது என்ன அனுமதிச் சரிபார்ப்பைச் செய்கிறது என்று சொல்லுங்கள், அந்த வரியை மேற்கோள் காட்டி. சரிபார்ப்பு இல்லாத எந்த route ஐயும் குறியிடுங்கள்.

பிறகு அதைச் சோதியுங்கள்: பயனர் A ஆக உள்நுழைந்து ஒரு பதிவின் ID ஐக் குறித்துக்கொள்ளுங்கள், பயனர் B ஆக உள்நுழைந்து அதைக் கோருங்கள். AI-built ஆப்களுக்கான பாதுகாப்புப் பட்டியல் முழு சோதனையைக் கொண்டுள்ளது.

படி 4: வெளிப்பட்ட ரகசியங்களைத் தேடுங்கள்

• மாறிய கோப்புகளில் ஒரு key அல்லது கடவுச்சொல் போலத் தோன்றும் எதையும் தேடுங்கள்.
• ரகசிய keys environment variables இலிருந்து படிக்கப்பட்டு சேவையகக் குறியீட்டில் மட்டுமே பயன்படுத்தப்படுகின்றனவா எனச் சரிபாருங்கள்.
• ரகசிய மாறிகளில் VITE_ அல்லது NEXT_PUBLIC_ போன்ற பொது prefixes உள்ளனவா எனக் கவனியுங்கள் — அவை உலாவிக் குறியீட்டில் கட்டப்பட்டுவிடும்.

API keys ஐ பாதுகாப்பாக வைப்பது எப்படி ஐப் பாருங்கள்.

படி 5: உள்ளீடு மற்றும் பிழைகளைச் சரிபாருங்கள்

• சேவையகத்தில் சரிபார்த்தல். உலாவிச் சரிபார்ப்புகளைத் தவிர்க்க முடியும். தேவையான புலங்கள், நீளங்கள், வடிவங்கள் மற்றும் அனுமதிக்கப்பட்ட மதிப்புகள் சேவையகத்திலும் சரிபார்க்கப்பட வேண்டும்.
• தரவுத்தள வினவல்கள் parameters ஐப் பயன்படுத்துகின்றன, பயனர் உள்ளீட்டை வினவலில் சேர்த்து உருவாக்கப்பட்ட உரையை அல்ல.
• பிழைகள் விழுங்கப்படவில்லை. எதுவும் செய்யாத try/catch தோல்விகளை மறைக்கிறது. பிழைகள் பதிவு செய்யப்பட வேண்டும், பயனர்கள் எளிய செய்தியைப் பார்க்க வேண்டும்.
• பயனர்களுக்கு உள் விவரங்கள் காட்டப்படுவதில்லை — stack traces மற்றும் தரவுத்தளப் பிழைகள் logs இல்தான் இருக்க வேண்டும்.

படி 6: அது உண்மையானதா என்று சரிபாருங்கள்

AI மாதிரிகள் சில நேரங்களில் சரியாகத் தோன்றும் ஆனால் இல்லாத விஷயங்களைக் குறிப்பிடும் குறியீட்டை உருவாக்குகின்றன.

• Packages: ஒவ்வொரு புதிய dependency ம் அந்த சரியான பெயருடன் உண்மையான, பராமரிக்கப்படும் package ஆக இருக்க வேண்டும். பிரபலமானவற்றின் எழுத்துப் பிழை போலத் தோன்றும் பெயர்களில் எச்சரிக்கையாக இருங்கள்.
• Functions மற்றும் API விருப்பங்கள்: குறியீடு நீங்கள் பார்த்திராத library function அல்லது வெளி API விருப்பத்தை அழைத்தால், அதிகாரப்பூர்வ ஆவணங்களைச் சரிபாருங்கள்.
• Placeholder குறியீடு: TODO, mock, fake, கடினக்குறியிட்ட மாதிரித் தரவு, அல்லது நிலையான மதிப்பைத் திருப்பும் functions ஐத் தேடுங்கள்.

நீங்கள் ஏதாவது புதிய packages சேர்த்தீர்களா? ஒவ்வொன்றுக்கும் சரியான பெயர், அது எதற்காக, அது இல்லாமல் நம்மால் செய்ய முடியுமா என்று சொல்லுங்கள்.

படி 7: அது பொருந்துகிறதா என்று சரிபாருங்கள்

குறியீடு வேலை செய்தாலும் பின்னர் ஆப்பை மாற்றுவதை கடினமாக்கலாம்:

• நகல்தன்மை. ஒரே தர்க்கம் பல இடங்களில் நகலெடுக்கப்பட்டால் அவை காலப்போக்கில் வேறுபட்டுவிடும்.
• ஒத்திசைவு. ஆப்பின் மற்ற பகுதிகள் பயன்படுத்தும் வடிவங்களைப் பின்பற்ற வேண்டும்.
• அளவு. 20 வரி கோரிக்கை 600 வரிகளை உருவாக்கியிருந்தால், ஒரு கேள்விக்கு உரியது.
• பயன்படாத குறியீடு. புதியவற்றுக்கு அருகில் விடப்பட்ட பழைய பதிப்புகள்.

இந்த மாற்றத்தின் காரணமாக திட்டத்தில் இப்போது பயன்படாத குறியீடு ஏதேனும் உள்ளதா, அல்லது வேறெங்காவது நகலெடுக்கப்பட்ட தர்க்கம் உள்ளதா? எதையும் மாற்ற வேண்டாம்; பட்டியலிடுங்கள் மட்டும்.

பொதுவான தவறுகள்

• சுத்தமாகத் தெரிவதால் அங்கீகரிப்பது. நேர்த்தியான குறியீடு இன்னும் ஒரு அனுமதிச் சரிபார்ப்பைத் தவிர்க்கலாம்.
• சோதிப்பதற்குப் பதிலாகப் படிப்பது. முதலில் சோதியுங்கள்; பின்னர் படியுங்கள்.
• சரியான பாதையை மட்டும் சோதிப்பது. தவறான உள்ளீடு, தவறான பயனர், உள்நுழையாத நிலை ஆகியவற்றை முயற்சியுங்கள்.
• தொடர்பில்லாத கோப்பு மாற்றங்களைப் புறக்கணிப்பது. ஒவ்வொரு கோப்பும் ஏன் மாறியது என்று கேளுங்கள்.
• சுய மதிப்பாய்வை முழுமையாக நம்புவது. AI இன் மதிப்பாய்வை முதல் கட்டமாகப் பயன்படுத்தி சோதனை மூலம் உறுதிப்படுத்துங்கள்.
• ஒரு வாரத்தின் மாற்றங்களை ஒரே நேரத்தில் மதிப்பாய்வு செய்வது. சிறிய மாற்றங்களை நடக்கும்போதே மதிப்பாய்வு செய்யுங்கள்.

சரிபார்ப்புப் பட்டியல்

• எந்தக் கோப்புகள் மாறின, ஏன் என்று எனக்குத் தெரியும், தொடர்பில்லாதது எதுவும் மாறவில்லை.
• மாற்றம் desktop மற்றும் தொலைபேசியில், தவறான உள்ளீடு, உள்நுழையாத நிலை மற்றும் வேறொரு பயனராக வேலை செய்கிறது.
• ஒவ்வொரு தரவு route ம் சேவையகத்தில் login மற்றும் உரிமையைச் சரிபார்க்கிறது.
• குறியீட்டிலோ உலாவித் தொகுப்புகளிலோ ரகசியங்கள் இல்லை.
• உள்ளீடு சேவையகத்தில் சரிபார்க்கப்படுகிறது; வினவல்கள் parameters ஐப் பயன்படுத்துகின்றன.
• பிழைகள் பதிவு செய்யப்படுகின்றன, விழுங்கப்படவில்லை, பயனர்களுக்கு விரிவாகக் காட்டப்படவில்லை.
• புதிய packages உண்மையானவை, தேவையானவை; கற்பனையான functions அல்லது placeholders எதுவும் மீதமில்லை.
• அதிக ஆபத்துள்ள மாற்றங்கள் கவனமாகப் படிக்கப்பட்டன, தேவைப்பட்ட இடத்தில் இரண்டாவது மதிப்பாய்வாளரும் இருந்தார்.

Mythex இல் குறியீட்டை மதிப்பாய்வு செய்வது

• Ask mode குறியீட்டைத் திருத்தாமல் அதைப் பற்றிய கேள்விகளுக்குப் பதிலளிக்கிறது — "ஒவ்வொரு மாற்றத்தையும் விளக்கு" மற்றும் "எந்த routes இல் அனுமதிச் சரிபார்ப்பு இல்லை" போன்ற prompts க்கு ஏற்றது. அரட்டை ஐப் பாருங்கள்.
• Code view ஒவ்வொரு திட்டத்திலும் கோப்பு மரம், editor மற்றும் terminal ஐக் காட்டுகிறது (Free இல் படிக்க மட்டும், Pro இல் திருத்தலாம்), எனவே என்ன மாறியது என்பதை நீங்களே படிக்கலாம். Code editor ஐப் பாருங்கள்.
• /test agent ஒரு பயனராக preview வழியாகக் கிளிக் செய்து உடைந்த flows ஐ அறிக்கை செய்ய வைக்கிறது.
• Checkpoints மதிப்பாய்வில் தோல்வியடையும் ஒரு மாற்றத்தைத் திரும்பப் பெற அனுமதிக்கின்றன.

உங்களுக்காக ஒரு டெவலப்பர் மதிப்பாய்வு செய்தால், AI-built ஆப்பில் டெவலப்பருடன் வேலை செய்வது எப்படி ஒப்படைப்பை உள்ளடக்குகிறது; மதிப்பாய்வில் ஒரு பிழை கண்டறியப்பட்டால், AI-built ஆப்பை எப்படி debug செய்வது ஐப் பாருங்கள்.

கேள்விகள்