சரியாக வேலை செய்யும் திட்டம்

1. ஒரு புரோகிராமரின் வேலை

அனுபவம் வாய்ந்த புரோகிராமர்கள் எப்படி நினைக்கிறார்கள் என்பதை விட புதிய புரோகிராமர்கள் ஒரு புரோகிராமரின் வேலையை முற்றிலும் வித்தியாசமாக நினைக்கிறார்கள் .

ஆரம்பநிலையாளர்கள் அடிக்கடி "நிரல் வேலை செய்கிறது, வேறு என்ன வேண்டும்?" ஒரு அனுபவமிக்க புரோகிராமருக்கு "சரியாக வேலை செய்கிறது" என்பது ஒரு நிரலுக்கான தேவைகளில் ஒன்று மட்டுமே என்பதை அறிவார் , மேலும் இது மிக முக்கியமான விஷயம் கூட அல்ல !

குறியீடு வாசிப்புத்திறன்

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

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

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

மைக்ரோசாப்ட் டெவலப்பர்கள் பின்பால் விளையாட்டை விண்டோஸிலிருந்து அகற்றியது ஒரு பாடப்புத்தக உதாரணம், ஏனெனில் அவர்களால் அதை 64-பிட் கட்டமைப்பிற்கு போர்ட் செய்ய முடியவில்லை. அவர்கள் அதன் மூலக் குறியீட்டைக் கூட வைத்திருந்தனர். குறியீடு எவ்வாறு செயல்படுகிறது என்பதை அவர்களால் புரிந்து கொள்ள முடியவில்லை .

ஒவ்வொரு பயன்பாட்டு வழக்குக்கும் கணக்கியல்

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

ஒரு புதிய புரோகிராமர் SMS செய்திகளை அனுப்புவதை எவ்வாறு பார்க்கிறார்:

ஒரு தொழில்முறை புரோகிராமர் அதை எவ்வாறு பார்க்கிறார்:

"சரியாக வேலை செய்கிறது" சூழ்நிலை பொதுவாக ஒன்று மட்டுமே சாத்தியமாகும். அதனால்தான் பல புதியவர்கள் CodeGym இன் டாஸ்க் வேலிடேட்டரைப் பற்றி புகார் செய்கின்றனர்: 10 படைப்புகளில் ஒரே ஒரு காட்சி மட்டுமே போதுமானது என்று புதிய புரோகிராமர் நினைக்கிறார்.

2. அசாதாரண சூழ்நிலைகள்

எந்தவொரு திட்டத்தையும் செயல்படுத்துவதில் அசாதாரண சூழ்நிலைகள் ஏற்படலாம்.

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

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

அதனால்தான் நிரல்கள் நீண்ட காலமாக மிகவும் எளிமையான நடத்தையைக் கொண்டிருந்தன: நிரலில் பிழை ஏற்பட்டால், நிரல் நிறுத்தப்பட்டது. அது ஒரு நல்ல அணுகுமுறை.

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

• நிரல் முடிவடைகிறது
• நிரல் தொடர்ந்து இயங்குகிறது, ஆனால் கோப்பை சேமிக்காது.

ஒரு புதிய புரோகிராமர் இரண்டாவது விருப்பம் சிறந்தது என்று நினைக்கலாம், ஏனெனில் நிரல் இன்னும் இயங்குகிறது. ஆனால் உண்மையில் அப்படி இல்லை.

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

நிரல் தனக்குத் தேவையானதைச் செய்ய முடியாவிட்டால், எல்லாம் சரியாகிவிட்டது என்று பாசாங்கு செய்வதை விட அதை மூடுவது நல்லது. ஒரு நிரல் தன்னால் சரிசெய்ய முடியாத ஒரு தோல்வியை சந்திக்கும் போது செய்யக்கூடிய சிறந்த விஷயம், சிக்கலை உடனடியாக பயனரிடம் புகாரளிப்பதாகும்.

3. விதிவிலக்குகள் பற்றிய பின்னணி

நிகழ்ச்சிகள் மட்டும் அசாதாரண சூழ்நிலைகளை எதிர்கொள்வதில்லை. அவை நிரல்களுக்குள்ளும் நிகழ்கின்றன - முறைகளில். உதாரணத்திற்கு:

• ஒரு முறை ஒரு கோப்பை வட்டில் எழுத விரும்புகிறது, ஆனால் இடம் இல்லை.
• ஒரு முறை ஒரு மாறியில் ஒரு செயல்பாட்டை அழைக்க விரும்புகிறது, ஆனால் மாறி பூஜ்யத்திற்கு சமம்.
• 0 ஆல் வகுத்தல் ஒரு முறையில் நிகழ்கிறது.

இந்த வழக்கில், அழைக்கப்பட்ட முறையில் என்ன வகையான சிக்கல் ஏற்பட்டது என்பதை அறிந்தால், அழைப்பு முறையானது சூழ்நிலையை சரிசெய்யலாம் (மாற்று சூழ்நிலையை இயக்கவும்).

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

ஒரு காலத்தில், புரோகிராமர்கள் இந்தக் கேள்வியைப் பற்றி யோசித்து, பின்வரும் தீர்வைக் கொண்டு வந்தனர்: அனைத்து முறைகள்/செயல்பாடுகளும் அவற்றின் செயல்பாட்டின் முடிவைக் குறிக்கும் பிழைக் குறியீட்டை வழங்க வேண்டும். ஒரு செயல்பாடு சரியாக வேலை செய்தால், அது 0 ஐத் தருகிறது . இல்லையெனில், அது பிழைக் குறியீட்டை வழங்கியது (பூஜ்ஜியம் அல்ல).

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

File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

மேலும் என்னவென்றால், அடிக்கடி ஒரு பிழை ஏற்பட்டதைக் கண்டறிந்த ஒரு செயல்பாடு அதை என்ன செய்வது என்று தெரியவில்லை: அழைப்பாளர் பிழையைத் திருப்பித் தர வேண்டும், மேலும் அழைப்பாளரின் அழைப்பாளர் அதை அழைப்பாளரிடம் திருப்பி அனுப்பினார்.

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

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