సరిగ్గా పని చేసే ప్రోగ్రామ్

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)
{
   ...
}

ఇంకా ఏమిటంటే, చాలా తరచుగా లోపం సంభవించిందని కనుగొన్న ఒక ఫంక్షన్ దానితో ఏమి చేయాలో తెలియదు: కాలర్ లోపాన్ని తిరిగి ఇవ్వవలసి ఉంటుంది మరియు కాలర్ యొక్క కాలర్ దానిని తన కాలర్‌కు తిరిగి ఇచ్చాడు మరియు మొదలైనవి.

ఒక పెద్ద ప్రోగ్రామ్‌లో, డజన్ల కొద్దీ ఫంక్షన్ కాల్‌ల గొలుసు ప్రమాణం: కొన్నిసార్లు మీరు వందలాది ఫంక్షన్‌ల కాల్ డెప్త్‌ను కూడా కనుగొనవచ్చు. మరియు ఇప్పుడు మీరు ఎర్రర్ కోడ్‌ను చాలా దిగువ నుండి పైకి పంపాలి. మరియు ఎక్కడా కొన్ని ఫంక్షన్ నిష్క్రమణ కోడ్‌ను నిర్వహించకపోతే, అప్పుడు లోపం పోతుంది.

ఈ విధానం యొక్క మరొక ప్రతికూలత ఏమిటంటే, ఫంక్షన్‌లు ఎర్రర్ కోడ్‌ను అందించినట్లయితే, వారు ఇకపై వారి స్వంత పని ఫలితాలను తిరిగి ఇవ్వలేరు. గణనల ఫలితాన్ని రిఫరెన్స్ పారామితుల ద్వారా పంపాలి. ఇది కోడ్‌ను మరింత గజిబిజిగా చేసింది మరియు లోపాల సంఖ్యను మరింత పెంచింది.