రాసిన కోడ్ డీబగ్ చేయడం ఎందుకు అంత విసుగెత్తిస్తుంది?
ఎవరు రాసిన కోడ్ వాళ్లే డీబగ్ చెయ్యడం మరీ అంతగా విసుగనిపించదు. పరిస్థితి బట్టి ఒక్కొక్కసారి ఆసక్తికరంగా ఉంటుంది. కానీ వేరెవరో రాసిన కోడ్ ని డీబగ్ చెయ్యాల్సి వచ్చినప్పుడు, పైగా వాళ్ళ కోడింగ్ శైలి మన కోడింగ్ శైలికి భిన్నంగా ఉన్నప్పుడు, అదే సమయంలో మన రిపోర్టింగ్ మేనేజర్ మన నెత్తి మీద డాన్స్ కట్టినప్పుడు మాత్రం ఆ అవస్థ పగవాడికి కూడా రాకూడదనిపిస్తుంది.
నాకు తెలిసి ప్రతీ ప్రాజెక్ట్ లోనూ కోడింగ్ శైలికి సంబంధించి కొన్ని రకాల ప్రమాణాలు, నియమాలు ఉంటాయి. ఒక వేరియబుల్ కి పేరు పెట్టడం దగ్గర్నుండి, లాగింగ్, వ్యాఖ్యలు రాయడం లాంటి వాటివరకూ ప్రాజెక్ట్ లోని వారందరూ ఒకే నియమాలు పాటించాల్సి వస్తుంది. ఆ నియమాలను గుర్తుచేసే IDE ఎక్సటెన్షన్లు, మాన్యూవల్ కోడ్ రివ్యూలు ఉంటాయి. ఇన్ని ఉన్నప్పటికీ ఎదో ఒక సందర్భంలో ఎవరికీ అర్ధం కాకుండా రాయబడే కోడ్ ప్రోడక్ట్ లోకి వెళ్ళిపోతుంది. నూటికి తొంబై శాతం కోడింగ్ ఎర్రర్స్ ఈ ప్రదేశాల్లోనే ఉంటాయి. వాటిని డీబగ్ చెయ్యడానికి ముందు ఆ కోడ్ ని అర్ధం చేసుకోవడానికే పుణ్యకాలం గడిచిపోతుంది.
ప్రాజెక్ట్ పరిమాణం కూడా డీబగ్గింగ్ ని బ్రహ్మ రాక్షసిలా మార్చే అవకాశం ఉంది. నేను ఇంతకు ముందు పనిచేసిన ప్రాజెక్టులో కొన్ని క్లాసుల్లో ఐదు వేల లైన్ల కోడ్ ఉండేది. ట్రబుల్ రిపోర్ట్ వచ్చిన ప్రతీసారి ఆ సబ్ మాడ్యూల్ అవ్వకూడదని కోరుకునేవాడిని.
డెవలపర్ మీద ఒత్తిడి కలిగించే పరిస్థితులలో మామూలుగా డీబగ్ చెయ్యడానికి పట్టే సమయం కంటే ఎక్కువ సమయం పట్టడం నేను గమనించాను. ముఖ్యంగా డెలివరీ రిపోర్ట్స్ పంపాల్సిన రోజు వచ్చే ట్రబుల్ రిపోర్టులు, మేనేజర్లు గంటకొకసారి స్టేటస్ అప్డేట్లు అడిగే సందర్భాల్లో.
వీటికి తోడు మెమరీ లీక్ లాంటి తప్పులు కనిపెట్టాల్సినప్పుడు తల ప్రాణం తోకకొస్తుంది. ఇటువంటి సమస్య ఒకదానిమీద పనిచేసినప్పుడు తప్పు కనిపెట్టడానికి మాకు మూడు రోజులు పట్టింది. అంతా చేసి కోడ్ లో మార్చింది కేవలం ఒకే ఒక్క అక్షరం. మాకు ఆ సందర్భం "ది గ్రేట్ వీకెండ్" పేరుతో గుర్తుండిపోయింది.
టీం లోని వారందరూ ఒకే రకమైన ప్రమాణాలు పాటించడం, చిన్న చిన్న బ్లాకులు రాసుకోవడం, టెస్ట్ కేసెస్ లేకుండా కోడ్ ని అనుమతించకపోవడం వంటి పద్దతులతో డీబగ్గింగ్ ని కొంతవరకు సులభతరం చెయ్యొచ్చు.
Comments
Post a Comment