𝗙𝗿𝗼𝗺 𝗤𝗔 𝘁𝗼 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁
AI code editors இப்போது பெரும்பாலான boilerplate குறியீடுகளைக் கையாண்டுவிடுகின்றன. இது ஒரு ஆபத்தான மாயையை உருவாக்குகிறது. AI குறியீட்டை எழுதி அது compile ஆனால், அது வேலை செய்கிறது என்று குழுக்கள் நினைக்கின்றன.
இந்த மனநிலை சிறிய அம்சங்களுக்கு (features) பொருந்தும். ஆனால் design systems-க்கு இது தோல்வியடையும்.
ஒரு design system component என்பது ஒருமுறை மட்டும் பயன்படும் அம்சம் அல்ல. அது ஒரு உள்கட்டமைப்பு (infrastructure). ஒரு பட்டன் அல்லது input field நூற்றுக்கணக்கான தயாரிப்புகளில் உள்ள மில்லியன் கணக்கான பயனர்களுக்குப் பயன்படும்.
உண்மையான சாதகம் நீங்கள் எவ்வளவு வேகமாக குறியீடு எழுதுகிறீர்கள் என்பதில் இல்லை. தோல்விகளை நீங்கள் எவ்வளவு சிறப்பாகக் கணிக்கிறீர்கள் என்பதில்தான் உள்ளது.
நீங்கள் ஒரு 'builder' மனநிலையிலிருந்து 'breaker' மனநிலைக்கு மாற வேண்டும். TDD, BDD மற்றும் Spec-Driven Development மூலம் சோதனை முறைகளை (testing) நீங்கள் ஏற்றுக்கொள்ள வேண்டும்.
பெரும்பாலான குழுக்கள் "Happy Path"-க்காகவே உருவாக்குகின்றன. அவர்கள் ஒரு Figma கோப்பைப் போலவே அமைத்துவிட்டு நிறுத்திவிடுகிறார்கள். ஆனால் components நிஜ உலகச் சிக்கல்களைத் தாங்கி நிற்க வேண்டும்.
ஒரு வலிமையான குழு குறியீடு எழுதுவதற்கு முன் கடினமான கேள்விகளைக் கேட்கிறது:
- வடிவமைப்பாளர்கள் (Designers): ஒரு உரைச் சரம் (text string) 400 எழுத்துகள் நீளமாக இருந்தால் என்னவாகும்? UI உடைந்துவிடுமா?
- பொறியாளர்கள் (Engineers): ஒரு பயனர் ஒரு வினாடிக்கு பத்து முறை ஒரு toggle-ஐக் கிளிக் செய்தால் என்னவாகும்? அதன் நிலை (state) சிதைந்துவிடுமா?
- அணுகல்தன்மை (Accessibility): ஒரு screen reader விசைப்பலகையை (keyboard) மட்டும் பயன்படுத்தி இந்த dropdown-ஐ எவ்வாறு கையாளும்?
AI கருவிகள் குறியீட்டில் சிறந்து விளங்கினாலும், அனுமானங்களில் (assumptions) பலவீனமானவை. அவை எளிதில் உடையக்கூடிய (brittle) components-களை உருவாக்குகின்றன.
உங்கள் வேலையைப் பாதுகாக்க இந்த பணிப்பாய்வைப் (workflow) பயன்படுத்துங்கள்:
- விபரக்குறிப்பை (spec) வரையறுக்கவும் (Tokens, Accessibility, API).
- எல்லைகளைத் தீர்மானிக்க முதலில் சோதனைகளையும் (tests) கதைகளையும் (stories) எழுதவும்.
- அந்த எல்லைகளுக்குள் குறியீட்டை உருவாக்க AI-ஐப் பயன்படுத்தவும்.
TDD இந்தச் செயல்முறையைத் தலைகீழாக மாற்றுகிறது. பிழைகளை (bugs) பிறகு சரிசெய்வதற்குப் பதிலாக, நீங்கள் முன்கூட்டியே எல்லைகளை வரையறுக்கிறீர்கள். பின்னர் AI அந்தச் சோதனைகளை நிறைவு செய்கிறது.
Behavior-Driven Development (BDD)-உம் உதவுகிறது. இது வடிவமைப்புக்கும் பொறியியலுக்கும் இடையிலான இடைவெளியைக் குறைக்க மனித மொழியைப் பயன்படுத்துகிறது.
உதாரணம்:
- ஒரு பயனர் மெதுவான இணைப்பைக் கொண்டிருக்கும்போது,
- அவர்கள் submit என்பதைக் கிளிக் செய்யும்போது,
- பட்டன் ஒரு loading நிலையைக் காட்ட வேண்டும் மற்றும் கிளிக் செய்வதைத் தவிர்க்க வேண்டும்.
சோதனை வேகம் குறையும் என்று சில தலைவர்கள் அஞ்சுகிறார்கள். இது ஒரு தவறு.
ஒரு component-ன் செலவில் ஆரம்பக் குறியீட்டு முறை (initial coding) வெறும் 5% மட்டுமே. மீதமுள்ள 95% பராமரிப்பு மற்றும் பிழைகளைச் சரிசெய்வதற்கே செலவிடப்படுகிறது.
ஒரு சோதனை மனநிலை உங்களுக்குக் கிடைப்பவை:
- நீங்கள் refactor செய்யும்போது குறைவான பின்னடைவுகள் (regressions).
- மற்ற டெவலப்பர்களுக்கான ஒரு சுய-சேவை அமைப்பு (self-service system).
- நிறுவனத்தின் நம்பிக்கை.
AI உலகில், குறியீட்டு வேகம் என்பது சாதாரணமாகிவிட்டது. ஆனால் systems thinking என்பது அரிதானது.
வேகமாக உருவாக்க முயற்சிப்பதை நிறுத்துங்கள். உடைந்து போகும் வகையில் (to break) உருவாக்கத் தொடங்குங்கள்.
உங்கள் குழு வேகம் மற்றும் மீள்தன்மைக்கு (resilience) இடையே எவ்வாறு சமநிலையைப் பேணுகிறது? கருத்துகளில் (comments) எனக்குத் தெரியப்படுத்துங்கள்.