1000 பிழைகள், ஒரு Google Sheet, மற்றும் என்னால் மீண்டும் பெற முடியாத ஐந்து மணிநேரம்
ஒவ்வொரு பிழைக்கும் (bug) ஒரு கதை உண்டு. பெரும்பாலானவை "இது என் கணினியில் சரியாக வேலை செய்கிறது" என்ற வாக்கியத்துடன் தொடங்கும்.
நாங்கள் ஒரு லீட் ஜெனரேஷன் (lead generation) நிறுவனத்திற்காக ஒரு டேட்டா இம்போர்ட் (data import) வசதியைச் சோதித்துக் கொண்டிருந்தோம். அந்த வசதி பார்ப்பதற்கு எளிமையாகத் தெரிந்தது. நீங்கள் ஒரு இம்போர்ட் பட்டனை கிளிக் செய்து, ஒரு ஸ்பிரெட்ஷீட்டைப் பதிவேற்றினால், சிஸ்டம் தொடர்புகளை (contacts) ஏற்றிக்கொள்ளும். அது சரியாக வேலை செய்யும் என்று அனைவரும் நினைத்தார்கள்.
அந்த அனுமானம் ஒரு பொறி.
அந்த அனுமானத்தை உடைப்பதற்காகவே டெஸ்டர்கள் (testers) இருக்கிறார்கள். "Happy path" எப்போதும் உங்களுக்குப் பொய் சொல்லும்.
நாங்கள் ஒரு சுத்தமான Excel கோப்பைப் பயன்படுத்தியிருந்தால், இம்போர்ட் வெற்றிகரமாக முடிந்திருக்கும். நாங்கள் மதிய உணவிற்குச் சென்றிருக்கலாம் அல்லது அந்த வசதியை வெளியிட்டிருக்கலாம். ஆனால், ஒரு வாடிக்கையாளர் திங்கட்கிழமை காலை தயாரிப்பு நிலையில் (production) அந்தப் பிழையைக் கண்டிருப்பார்.
பிரச்சனை ஒரு Google Sheet-இல் இருந்தது.
நிஜமான பயனர்கள் சுத்தமான Excel கோப்புகளைப் பயன்படுத்துவதில்லை. அவர்கள் குழப்பமான Google Sheets-களைப் பயன்படுத்துகிறார்கள். அவர்களின் குழப்பமான தரவுகளைக் கையாளுவதற்கு சிஸ்டம் தயாராக இருக்க வேண்டும் என்று அவர்கள் எதிர்பார்க்கிறார்கள்.
நாங்கள் Google Sheet தரவைப் பதிவேற்றியபோது, சிஸ்டம் தோல்வியடைந்தது. 1,000-க்கும் மேற்பட்ட பிழைகளைக் கண்டோம். திரை முழுவதும் பிழைகளால் நிரம்பியது. மூல வடிவம் (source format) மாறிய காரணத்தினால், அதே பட்டனும் அதே தரவு வகையும் (data type) முழுமையான முடக்கத்தை ஏற்படுத்தின.
மேலும் சோதிப்பதற்காக நாங்கள் மீண்டும் Excel-க்குச் சென்றோம். சரியான மற்றும் தவறான வரிசைகளின் (rows) கலவையை முயற்சி செய்தோம். சிஸ்டம் அதைச் சிறப்பாகக் கையாண்டது. அது தவறான வரிசைகளைத் தவிர்த்துவிட்டு அடுத்தடுத்துச் சென்றது.
பிறகு நாங்கள் நிஜ உலகச் சூழலை (real-world chaos) முயற்சி செய்தோம். நூற்றுக்கணக்கான வரிசைகளைக் கொண்ட ஒரு பெரிய கோப்பை (bulk file) பதிவேற்றினோம். அதில் பெரும்பாலானவை குப்பையாக இருந்தன. சில மட்டுமே சரியாக இருந்தன.
சிஸ்டம் முற்றிலும் செயலிழந்தது. சில தவறான வரிசைகளுக்கு மட்டும் validation logic வேலை செய்தது, ஆனால் தரவுகளின் மலைக்குக் கீழே அது முடங்கிப்போனது.
அதன் மூல காரணத்தைக் கண்டறிய ஐந்து மணிநேரம் செலவிட்டோம். திரையைப் பார்த்துக் கொண்டிருந்தோம், சோதனைகளை மீண்டும் செய்தோம், கோப்புகள், பிரவுசர் மற்றும் காபி என அனைத்தையும் குறை கூறினோம்.
அந்த ஐந்து மணிநேரம் மிகக் குறைவான விலைதான். அதற்குப் பதிலாக, ஒரு வாடிக்கையாளர் தனது நேரத்தை இழப்பதும், எங்கள் தயாரிப்பின் மீதுள்ள நம்பிக்கையை இழப்பதும் நடந்திருக்கலாம். டெஸ்டிங்கில் ஏற்படும் பிழைகளுக்கு நேரத்தைக் கொடுத்துச் சரிசெய்யலாம். ஆனால் தயாரிப்பு நிலையில் (production) ஏற்படும் பிழைகளுக்கு வாடிக்கையாளர்களை இழக்க நேரிடும்.
நான் எப்போதும் அந்த ஐந்து மணிநேரத்தையே தேர்ந்தெடுப்பேன்.
ஒரு சிறந்த டெஸ்டர் ஒரு வசதி வேலை செய்கிறதா என்று கேட்க மாட்டார். அதை எப்படி உடைக்கலாம் என்றுதான் கேட்பார்.
ஒரு டெவலப்பரைப் போலச் சிந்திப்பதை நிறுத்துங்கள். இந்த நபர்களைப் போலச் சிந்திக்கத் தொடங்குங்கள்:
- தவறான கோப்பு வடிவத்தைப் பதிவேற்றும் சோம்பேறி பயனர்.
- இணைக்கப்பட்ட செல்கள் (merged cells) மற்றும் காலியான வரிசைகளைக் கொண்ட குழப்பமான பயனர்.
- 10 சுத்தமான பதிவுகளுக்குப் பதிலாக 4,000 அழுக்கான பதிவுகளைப் பதிவேற்றும் பயனர்.
- செய்யக்கூடாததைச் சரியாகச் செய்யும் தொல்லை தரும் பயனர்.
நீங்கள் எதிர்பார்க்காத உள்ளீடுகளால் (inputs) தான் மென்பொருள் செயலிழக்கிறது.
மிகவும் "எளிமையான" வசதிகள் பெரும்பாலும் மிகவும் ஆபத்தானவை. இம்போர்ட் பட்டன், தேடல் பெட்டி (search box) மற்றும் தொடர்பு படிவம் (contact form) ஆகியவை பார்ப்பதற்குத் தீங்கு விளைவிக்காதவை போலத் தெரியும். ஆனால் அவை அப்படி இல்லை.
ஒரு வசதி "happy path"-இல் வெற்றி பெற்றால், அடுத்த கட்டத்திற்குச் செல்லாதீர்கள். "கற்பனை செய்யக்கூடிய மிக மோசமான கோப்பைப் பதிவேற்றினால் என்னவாகும்?" என்று கேட்பவராக இருங்கள்.
பிறகு அதைச் செய்து பாருங்கள்.
Optional learning community: https://t.me/GyaanSetuAi
