అన్నీ అంగీకరించండి, ఏమీ అర్థం చేసుకోకండి
కోడ్ సూచనలను (code suggestions) స్క్రోల్ చేసి వెళ్లడం కంటే, ఎంటర్ నొక్కి వాటిని అంగీకరించడం చాలా సులభం. ఒక్క కీస్ట్రోక్తో ఆ కోడ్ మీ సొంతం అవుతుంది. కానీ ఆ కోడ్ను చదవడం మరియు అర్థం చేసుకోవడం మాత్రం అంత వేగంగా పెరగలేదు.
మీరు కోడ్ను ఎంత వేగంగా అంగీకరిస్తున్నారు మరియు దానిని ఎంత వేగంగా అర్థం చేసుకుంటున్నారు అనే అంశాల మధ్య ఒక వ్యత్యాసం ఉంది. ఈ వ్యత్యాసమే తప్పులకు దారితీస్తుంది.
టెక్నికల్ డెట్ (Technical debt) కి గతంలో స్పష్టమైన కారణాలు ఉండేవి. మీకు డెడ్లైన్లు తక్కువగా ఉండటం లేదా పనిని త్వరగా ముగించడానికి కొన్ని పద్ధతులను వదిలేయడం వంటివి. మీరు ఆ కారణాన్ని చెప్పగలిగేవారు. కానీ ఇప్పుడు, ఒక ప్రశాంతమైన మంగళవారం నాడు కూడా మీరు డెట్ను సృష్టిస్తున్నారు. ఆ సూచనలు బాగున్నాయని మీరు వరుసగా ఆరు సూచనలను అంగీకరిస్తారు. మిమ్మల్ని ఎవరూ తొందరపెట్టలేదు, కానీ ఆ కోడ్ తనిఖీ చేయబడలేదు.
1974లో బ్రయాన్ కెర్నిఘన్ (Brian Kernighan) ప్రోగ్రామ్ రాయడం కంటే డీబగ్గింగ్ (debugging) చేయడం రెండు రెట్లు కష్టమని చెప్పారు. ఆయన మనుషులు రాసే కోడ్ గురించి మాట్లాడుతున్నారు. కనీసం మనుషులు తమ సొంత పనిని అర్థం చేసుకోగలరు.
నేడు, ఒక సూచన లీంటర్ (linter) పరీక్షలను మరియు టెస్ట్లను కూడా పాస్ చేయగలదు. అయినప్పటికీ అది తప్పు అంచనాలపై ఆధారపడి ఉండవచ్చు. ఎందుకంటే ప్రజలు ఆ సూచనను కోడ్లా కాకుండా ఒక అవుట్పుట్లా చూస్తున్నారు. చూడటానికి బాగున్న అవుట్పుట్ను వెంటనే అంగీకరిస్తున్నారు.
ఒకవేళ మోడల్ కోడ్ మరియు టెస్ట్లు రెండింటినీ రాస్తే, మీరు విద్యార్థి రాసిన సమాధానాలతోనే వారి హోంవర్క్ను గ్రేడ్ చేస్తున్నట్లు అవుతుంది. దీనివల్ల లాజిక్ సరిగ్గా ఉందో లేదో మీకు తెలియదు. ఎడ్జ్ కేస్లు (edge cases) కవర్ చేయబడ్డాయో లేదో కూడా తెలియదు. ఆ కోడ్ మీ ఎడిటర్లో, మీ శైలిలోనే కనిపిస్తున్నప్పుడు దీనిని మర్చిపోవడం చాలా సులభం.
ఇది నిజమైన సమస్యలను సృష్టిస్తుంది:
- మీరు ఎప్పుడూ చదవని కోడ్ను డీబగ్ చేస్తారు. కొన్ని వారాల తర్వాత ఏదైనా విఫలమైనప్పుడు, మీరు మళ్ళీ మొదటి నుండి ప్రారంభించాల్సి వస్తుంది.
- ఎడ్జ్ కేస్లు విఫలమవుతాయి. ఒక సూచన సాధారణ పరిస్థితులను (happy path) బాగా హ్యాండిల్ చేయవచ్చు. అందులో నల్ చెక్ (null check) కూడా ఉండవచ్చు. కానీ మీ వ్యాపారానికి అవసరమైన ప్రత్యేక లాజిక్ను అది వదిలివేస్తుంది.
- మీరు మీ స్వంత పుల్ రిక్వెస్ట్లను (pull requests) సమర్థించలేరు. రివ్యూయర్ మీరు ఒక పద్ధతిని ఎందుకు ఎంచుకున్నారని అడిగితే, మీ దగ్గర సమాధానం ఉండదు. ఆ నిర్ణయం మీరు తీసుకోలేదు. మీరు దానిని తిరస్కరించలేదు అంతే.
ఈ సాధనాలు ఉపయోగకరమైనవే. ఇవి కోడ్బేస్లను (codebases) పరిశీలించడానికి లేదా కొత్త ఫీచర్లను ప్లాన్ చేయడానికి సహాయపడతాయి. సమస్య మీ వైఖరిలో ఉంది. ప్రతి సూచనను కేవలం ఒక చూపు చూడటమే కాకుండా, చదివి నిర్ణయం తీసుకోవాల్సిన అంశంగా మీరు పరిగణించాలి.
బాయిలర్ప్లేట్ (boilerplate) లేదా త్వరిత స్క్రిప్ట్ల కోసం వేగం పర్వాలేదు. కానీ బిజినెస్ లాజిక్ లేదా సెక్యూరిటీ విషయానికి వస్తే, మీ విధానం మారాలి. ఆ కోడ్ మీదేనని భావించి చదవండి. ఎందుకంటే అది మీదే అవుతుంది.
దానికి బదులుగా ఇవి చేయండి:
- కోడ్ అడగకముందే మీ పరిష్కారాన్ని మోడల్తో చర్చించండి.
- మీరు స్వయంగా రాసినట్లుగా డిఫ్ (diff) ను రివ్యూ చేయండి.
- కోడ్ను అంగీకరించే ముందు, ఆ సాధనం యొక్క తర్కాన్ని (reasoning) వివరించమని అడగండి.
- సూచనలను ఒక జూనియర్ డెవలపర్ చేసిన పనిలా పరిగణించండి. అది ఉపయోగకరంగా ఉండవచ్చు కానీ అది అంతిమ సత్యం కాదు.
- మిమ్మల్ని ఆశ్చర్యపరిచే లైన్ల వద్ద నెమ్మదించండి. ఆశ్చర్యం అనేది ఒక సంకేతం.
కీస్ట్రోక్ సులభమైంది, కానీ మీ బాధ్యత కాదు. అవగాహన లేకుండా వేగం అనేది కేవలం వేగవంతమైన డెట్ (fast debt) మాత్రమే.
Source: https://dev.to/cloudx/accept-all-understand-none-4dob
Optional learning community: https://t.me/GyaanSetuAi