హలో, ప్రపంచం! మీరు తెలుసుకోవలసిన ప్రతిదాన్ని నేర్చుకుని, చివరకు ఇంటర్న్ లేదా జూనియర్ దేవ్‌గా పని చేసిన తర్వాత, మీరు విశ్రాంతి తీసుకోవచ్చు, సరియైనదా? లేదు. మీ కోసం అంతా ఇప్పుడే మొదలవుతోంది... మీ చుట్టూ చాలా కొత్తవి మరియు అపారమయినవి ఉన్నాయి. మీరు దానిని గేట్ నుండి ఎలా స్క్రూ చేయకూడదు? ఈరోజు మనం మాట్లాడుకోబోయేది అదే. ఈ వ్యాసంలో, నేను సాధారణ రూకీ తప్పులను విశ్లేషించాలనుకుంటున్నాను మరియు వాటిని ఎలా నివారించాలో నా స్వంత అనుభవం ఆధారంగా కొన్ని సలహాలు ఇవ్వాలనుకుంటున్నాను. కాబట్టి, ఎటువంటి సందేహం లేకుండా ప్రారంభిద్దాం:
1. మరింత అనుభవజ్ఞులైన సహోద్యోగుల నుండి సహాయం కోరే భయం
మనమంతా మనుషులం. మనమందరం తెలివితక్కువవారిగా కనిపించడానికి భయపడుతున్నాము, ప్రత్యేకించి మా కొత్త, మరింత అనుభవజ్ఞులైన సహోద్యోగుల దృష్టిలో. డెవలపర్లు తమ మొదటి ఉద్యోగాన్ని తీసుకున్నప్పుడు, వారు తరచుగా ఈ భయంతో మార్గనిర్దేశం చేయబడతారు మరియు భారీ వినికిడితో, తమలో తాము ఉపసంహరించుకుంటారు, ప్రతిదీ వారి స్వంతంగా గుర్తించడానికి ప్రయత్నిస్తారు. అదనంగా, ఎవరైనా మరింత అనుభవజ్ఞులైన సహోద్యోగులతో చుట్టుముట్టబడవచ్చు, వారు అతనిని లేదా ఆమెను అత్యంత ఆశాజనకమైన దిశలో సూచించగలుగుతారు, మరిన్ని తప్పులు మరియు అనవసరమైన "తలపై గడ్డలు" నివారించడానికి సహాయం చేస్తారు. కాబట్టి గుర్తుంచుకోండి: ప్రశ్నలు అడగడానికి బయపడకండి. మీరు ఒక అనుభవశూన్యుడు మరియు ప్రతి ఒక్కరూ దీన్ని బాగా అర్థం చేసుకుంటారు. అని అడిగితే ఎవరూ లాఠీలతో కొట్టరు. బహుశా దీనికి విరుద్ధంగా కూడా జరగవచ్చు: మీరు మీ సహోద్యోగులతో మరింత త్వరగా స్నేహితులు అవుతారు మరియు వారితో మరింత చురుకైన సంభాషణను ఆస్వాదించడం ప్రారంభిస్తారు. నేను ఇంకా ఎక్కువ చెబుతాను: మీరు వివిధ సాంకేతిక సమస్యలను ఎంత ఎక్కువగా అడిగితే మరియు చర్చిస్తే, అంత వేగంగా మీరు మీ పచ్చని కొత్త చర్మాన్ని తొలగించి, మీ రంగంలో నిపుణుడిగా ఎదగగలుగుతారు. మరియు మరొక సలహా. అపరిచితుడు కావద్దుస్టాక్ ఓవర్‌ఫ్లో . నేను ప్రత్యేకంగా ఈ వనరుపై ప్రశ్నలు అడగడం గురించి మాట్లాడుతున్నాను. ఒక వైపు, మీ ప్రశ్నకు సమాధానం పొందడానికి కొంత సమయం పడుతుంది. కానీ మరోవైపు, మీరు మీ సమస్యను పరిష్కరించడానికి బహుళ విధానాలను త్వరగా నేర్చుకుంటారు మరియు కొద్దిగా భిన్నమైన కోణం నుండి చూడవచ్చు. ఇతర డెవలపర్‌ల నుండి StackOverflow ప్రశ్నలపై వ్యాఖ్యానం/సమాధానాలు రాయడం మరియు స్పష్టమైన ప్రశ్నలను వ్రాయడం వల్ల ఆచరణాత్మక ప్రయోజనాలు ఉన్నాయని కూడా నేను గమనించాలనుకుంటున్నాను: కర్మ బూస్ట్ గురించి చెప్పకుండా, చర్చలు మరియు సమస్యలను లోతుగా పరిశోధించడానికి మీకు అవకాశం లభిస్తుంది.
2. సొంతంగా సమాచారాన్ని వెతకడానికి ప్రయత్నించకపోవడం
ఈ పొరపాటు మునుపటి తప్పుగా పరిగణించబడుతుంది.మీరు ఎదుర్కొనే ప్రతి సమస్య లేదా ఎక్కిళ్ళు గురించి మీరు మీ సహోద్యోగులను మరియు పరిచయస్తులను ఇబ్బంది పెట్టడం ప్రారంభించినప్పుడు ఇక్కడ నా ఉద్దేశ్యం. అడగడం మంచిది, కానీ ప్రశ్నలతో అతిగా వెళ్లవద్దు. లేకపోతే, ప్రజలు మిమ్మల్ని బాధించేదిగా భావించవచ్చు. మీరు ఏదైనా విషయం గురించి గందరగోళానికి గురైతే, మొదటి విషయం ఏమిటంటే, ఉత్తమ శోధన ఇంజిన్‌లో మీ శోధన నైపుణ్యాలను ఉపయోగించడం - Google. వేరొకరు ఇప్పటికే అధిక సంఖ్యలో అపారమయిన లోపాలు మరియు ఇతర సమస్యలను ఎదుర్కొన్నారు. మరియు మీరు మీ ప్రశ్నను గూగుల్ చేసి, ఇలాంటి సమస్య గురించి తెలిసిన వ్యక్తుల సంఖ్యను చూస్తే మరియు మీరు మీ స్వంత పనిలో దరఖాస్తు చేసుకోగల సమగ్ర సమాధానాలను ఇప్పటికే అందుకున్నట్లయితే మీరు చాలా ఆశ్చర్యపోతారు. అందుకే మీ సహోద్యోగులు "గూగుల్ ఇట్" అని ప్రత్యుత్తరం ఇవ్వడం మీరు తరచుగా వింటారు. చేయవద్దు' ఈ సమాధానంతో బాధపడకండి - మీ సహోద్యోగి మీ వ్యక్తిగత ఉపాధ్యాయుడు కాదు, అతను మీ పని రంగంలోని అన్ని సూక్ష్మబేధాలను తెలియజేయాలి. ఇంటర్నెట్ యొక్క అంతులేని విస్తరణలు మీ గురువుగా ఉంటాయి. కొన్నిసార్లు ప్రోగ్రామర్లను కూడా సూచిస్తారుGoogle శోధనలో బ్లాక్ బెల్ట్ ఉన్న వ్యక్తులు . కాబట్టి మనకు " ఎక్కిళ్ళు" ఉన్నట్లయితే, మేము ముందుగా సమస్యను గూగుల్ చేస్తాము. ఒక పరిష్కారం కనుగొనబడకపోతే (ఇది చాలా అరుదు, కానీ ఇది జరుగుతుంది), అప్పుడు మాత్రమే మేము సహోద్యోగులను అడగడం ప్రారంభిస్తాము. మీరు స్పీడ్ బంప్ లేదా అపారమయిన ఎర్రర్ మెసేజ్‌ని నొక్కినప్పుడు మీరు చేసే దాని కంటే సమస్యను పరిష్కరించడానికి మీరు ఏ విధానాన్ని ఎంచుకోవాలి అనే దాని గురించి సలహా పొందడం కోసం తక్షణ ప్రశ్నలు. అన్నింటికంటే, వారు మీ ప్రాధాన్య విధానానికి మించి చూడగలరు మరియు ఏదైనా విధానం దీర్ఘకాలంలో ఎక్కడికి దారితీస్తుందో వెంటనే అంచనా వేయగలరు.
3. గుడ్డిగా కాపీ చేయడం మరియు అతికించడం
కానీ గూగ్లింగ్ సమస్యలు మరియు వాటి పరిష్కారాలు దాని ఆపదలను కలిగి ఉంటాయి. ఉదాహరణకు, గుడ్డిగా కాపీ చేయడం మరియు అతికించడం .మీరు ఇలాంటి సమస్య (కానీ బహుశా అదే కాదు) మరియు అనుబంధిత పరిష్కారాన్ని కనుగొన్నప్పుడు ఇది సాధారణంగా జరుగుతుంది, ఉదాహరణకు, StackOverflowలో. మీరు ఈ పరిష్కారాన్ని పట్టుకుని, వివరాలను మరింత లోతుగా పరిశోధించకుండా కాపీ చేసి అతికించండి. ఆపై మీరు లేదా మీ సహోద్యోగులు మీ కోడ్‌లో కొన్ని వింత బగ్‌లు లేదా తప్పు ప్రవర్తనను కనుగొంటారు. మరియు వారు ఎక్కడ నుండి వచ్చారో ఎవరూ వెంటనే ఊహించలేరు. చివరికి, వాస్తవానికి, కాపీ చేయబడిన కోడ్ ఉన్న స్థలం కనుగొనబడుతుంది మరియు మీ పరిష్కారం కోసం మీరు ఖచ్చితంగా ప్రశంసించబడరు. కాబట్టి, మీరు StackOverflow (లేదా మరెక్కడైనా) పై రెడీమేడ్ పరిష్కారాన్ని కనుగొన్నప్పుడు, మీరు మొదట ఏమి, ఎలా మరియు ఎందుకు అనే విషయాలను పూర్తిగా అర్థం చేసుకోవాలి. బహుశా సంబంధిత ఫంక్షనాలిటీని గూగుల్ చేసి, దాని కోసం డాక్యుమెంటేషన్ చదవండి. మరియు మీరు దీన్ని పూర్తి చేసిన తర్వాత మాత్రమే మీ ప్రాజెక్ట్‌కి జోడించాలి.
4. తప్పు పరిష్కారంతో అంటుకోవడం
ఒక పరిష్కారాన్ని వ్రాసేటప్పుడు, అది నిరంతరం మరింత క్లిష్టంగా మారుతున్నట్లు మీరు కొన్నిసార్లు కనుగొంటారు, చివరికి చివరి దశకు చేరుకుంటారు. ఆపై మీరు మరొక, మరింత సరిఅయిన ప్రత్యామ్నాయం కోసం వెతకడానికి బదులుగా దాన్ని ఎలాగైనా పని చేయడానికి పరిష్కారాన్ని మరింత విస్తృతంగా చేయడానికి ప్రయత్నిస్తారు. బహుశా మీరు చాలా సమయం మరియు కృషిని పెట్టుబడి పెట్టినట్లు మీకు అనిపించవచ్చు మరియు అందువల్ల మీరు ఏమి చేసినా, మీరు వదులుకోరని మరియు మీ ప్రస్తుత విధానంతో సమస్యను పరిష్కరించుకోవాలని నిర్ణయించుకున్నారు. ఇది చాలా సరైన వైఖరి కాదు. కనీసం ప్రోగ్రామింగ్‌లోనైనా. మీరు వేరొక విధానాన్ని ఎంత త్వరగా ప్రయత్నిస్తే అంత ఎక్కువ సమయం ఆదా అవుతుంది. కాబట్టి మీరు మీ ప్రస్తుత దానిలో పెట్టుబడి పెట్టిన సమయంతో సంబంధం లేకుండా, ఇతర విధానాలను ప్రయోగాలు చేయడానికి మరియు ప్రయత్నించడానికి బయపడకండి. ఇంకా ఏమిటంటే, బహుళ విధానాలను ప్రయత్నించడం ద్వారా మరియు సబ్జెక్ట్‌లో మరింత లోతుగా డైవ్ చేయడం ద్వారా, మీరు'
5. మీ ప్రస్తుత అసైన్‌మెంట్ గురించి ప్రశ్నలు అడిగే భయం
సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ ప్రాజెక్ట్‌లో పని చేయడం సాధారణంగా నిర్దిష్ట పనులను చేయడం వరకు తగ్గుతుంది. ఉదాహరణకు, జిరాలో. ఈ పనులు ఎల్లప్పుడూ స్పష్టంగా మరియు వివరంగా వివరించబడవు. టాస్క్ వివరణలు సాధారణంగా టీమ్ లీడర్‌లచే వ్రాయబడతాయి, వారు కూడా కేవలం మనుషులే. వారు ఏదైనా జోడించడం మరచిపోవచ్చు లేదా మీకు ఈ లేదా ఆ కార్యాచరణ గురించి తెలియదనే వాస్తవాన్ని పరిగణనలోకి తీసుకోవడంలో విఫలం కావచ్చు. లేదా బహుశా మీకు ప్రాజెక్ట్‌కి ఎలాంటి యాక్సెస్ లేకపోవచ్చు (ఉదాహరణకు, డేటాబేస్, లాగ్ సర్వర్ మొదలైన వాటికి యాక్సెస్). ఇప్పుడు, మీరు పనిని స్వీకరించారు, రెండు గంటల కంటే ఎక్కువసేపు అధ్యయనం చేసారు, కానీ మీరు ఇప్పటికీ అక్కడే కూర్చొని, దిగ్భ్రాంతితో స్క్రీన్ వైపు చూస్తున్నారు. దీన్ని అర్థం చేసుకోవడానికి విఫలమైన ప్రయత్నం కొనసాగించడానికి బదులుగా, మీరు టాస్క్‌ను సృష్టించిన వారి నుండి వివరణ లేదా మార్గదర్శకత్వం కోసం అడగడం ప్రారంభించాలి. ఉదాహరణకు, మీ బృందం కమ్యూనికేషన్ కోసం ఉపయోగించే యాప్‌లో (ఉదాహరణకు, Microsoft బృందాలు), మీరు టాస్క్‌కు సంబంధించి ప్రశ్నలు అడగవచ్చు లేదా నేరుగా వ్యాఖ్యానించవచ్చు. ఒకవైపు, మీరు మీ ప్రశ్నను వ్యక్తిగత సందేశంలో వ్రాస్తే, ఆ వ్యక్తి మీ ప్రశ్నను వెంటనే చూస్తారు కాబట్టి, మీరు బహుశా వేగంగా సమాధానం పొందుతారు. మరోవైపు, జిరాలో ఒక ప్రశ్న అడగడం ద్వారా, మీరు ఏదో చేస్తున్నారనే రుజువును ఏర్పాటు చేస్తారు, అవి సమస్యను విశ్లేషించడం. ఈ ప్రక్రియను వేగవంతం చేయడానికి ఒక మార్గం ఉంది: మీ ప్రశ్నను జిరాలో కామెంట్‌లో అడగండి, ఆపై DMలో, మీ వ్యాఖ్యకు లింక్‌ను వదలండి మరియు పరిశీలించమని అడగండి.
6. టీమ్ లీడ్‌పై అవాస్తవంగా అధిక అంచనాలను ఉంచడం
మళ్ళీ, ఇది మునుపటి పాయింట్ యొక్క ఫ్లిప్ సైడ్. టీమ్ లీడ్ డెవలప్‌మెంట్ టీమ్‌కి అధిపతి. నియమం ప్రకారం, మీ టీమ్ లీడ్ అతని లేదా ఆమె ఎక్కువ సమయాన్ని వివిధ రకాల కమ్యూనికేషన్‌లపై గడుపుతారు. అయినప్పటికీ, అతను లేదా ఆమె ప్రోగ్రామింగ్ గురించి ప్రతిదీ మర్చిపోకుండా ఉండటానికి కోడ్‌ను కూడా వ్రాస్తారు. మీరు అర్థం చేసుకున్నట్లుగా, టీమ్ లీడ్ జీవితం చాలా బిజీగా ఉంటుంది. మీరు తుమ్మాల్సిన ప్రతిసారీ మీ టీమ్ లీడ్ స్లీవ్‌పై లాగడం స్పష్టంగా నచ్చదు. జట్టులోని ప్రతి సభ్యుడు అనేక ప్రశ్నలతో ముందంజ వేస్తున్నట్లు ఊహించుకోండి. అది ఎవరినైనా వెర్రివాడిగా మార్చగలదు, సరియైనదా? మరియు మీరు చాలా ప్రశ్నలను పోగు చేస్తే, మీ టీమ్ లీడ్ మీకు సమాధానం ఇవ్వడానికి చాలా సమయం వెచ్చించాల్సి ఉంటుంది. టీమ్ లీడ్‌కి సంబంధించిన ప్రశ్నల సంఖ్యను తగ్గించడానికి ఏమి చేయాలి:
బ్లైండ్ స్పాట్‌ల సంఖ్యను తగ్గించడానికి ప్రాజెక్ట్ డాక్యుమెంటేషన్‌ను మరింత లోతుగా అన్వేషించండి.
మీ ప్రశ్నలను మీ ఇతర బృంద సభ్యులకు పంపండి. ఈ ఫంక్షనాలిటీని లీడ్‌గా తెలిసినంతగా లేదా బహుశా మరింత ఎక్కువగా వారికి తెలిసి ఉండవచ్చు, ఎందుకంటే ఫంక్షనాలిటీని ఎక్కువగా వారిలో ఒకరు వ్రాసారు.
ప్రత్యామ్నాయంగా, మీరు నిర్దిష్ట లైన్‌లోని కోడ్‌ని ఎవరు మరియు ఎప్పుడు మార్చారు అనేదానికి IDEలోని ఉల్లేఖనాలను చూడవచ్చు. మీ ప్రశ్న అడగడానికి అత్యంత సరైన వ్యక్తి ఎవరు అని మీరు ఖచ్చితంగా ఎలా కనుగొనగలరు. మీరు బహుశా ఇప్పటికే గ్రహించినట్లుగా, టీమ్ లీడ్‌కి ప్రశ్నల విషయానికి వస్తే, సహోద్యోగులకు ప్రశ్నల మాదిరిగానే, మీరు సంతోషకరమైన మాధ్యమాన్ని కనుగొనడానికి ప్రయత్నించాలి — ప్రశ్నలు అడగడానికి బయపడకండి, కానీ చాలా ఎక్కువ అడగవద్దు. వారిది.
7. కోడ్ సమీక్షల భయం
ఒక కోడ్ సమీక్షమీరు మీ కోడ్‌ని ఒక సాధారణ అప్లికేషన్‌కు (షేర్డ్ బ్రాంచ్‌కి, ఉదాహరణకు, మాస్టర్ లేదా దేవ్) సమర్పించడానికి ముందు జరిగే దశ. టాస్క్‌లో పాలుపంచుకోని డెవలపర్ ద్వారా ఈ తనిఖీని నిర్వహిస్తారు, దీని తాజా కళ్ళు మీ కోడ్ శైలిలో లోపాలు, తప్పులు లేదా లోపాలను గుర్తించగలవు, అవి మీరు మొదట్లో మీ కోడ్‌ను వ్రాసినప్పుడు గుర్తించబడవు. విమర్శలు ఉంటే, అవి కోడ్‌లోని కొన్ని భాగాలపై వ్యాఖ్యలుగా మిగిలిపోతాయి. ఈ సందర్భంలో, కోడ్‌ను వ్రాసిన డెవలపర్ తప్పనిసరిగా సమీక్షలో గుర్తించిన లోపాలను సరిదిద్దాలి (లేదా సమీక్షకుడితో అతని నిర్ణయాలను చర్చించి, అవి సరైనవని అతనిని లేదా ఆమెను ఒప్పించి ఉండవచ్చు). సమీక్షకుడికి ఎటువంటి వ్యాఖ్యలు లేనంత వరకు కోడ్ మళ్లీ మళ్లీ సమీక్ష కోసం సమర్పించబడుతుంది. కోడ్ కట్టుబడి ఉండే ముందు సమీక్షకుడు "గేట్‌వే" వలె వ్యవహరిస్తాడు. చాలా మంది అనుభవం లేని ప్రోగ్రామర్లు కోడ్ సమీక్షను విమర్శ మరియు ఖండనగా భావించడం సవాలు. వారు కోడ్ రివ్యూలను మెచ్చుకోరు మరియు వాటికి భయపడతారు. వారు చేయకూడదు. కోడ్ రివ్యూలు ఖచ్చితంగా మన కోడ్‌ని మెరుగుపరుస్తాయి. అన్నింటికంటే, మేము ఏమి తప్పు చేస్తున్నాము మరియు దేనిపై శ్రద్ధ వహించాలి అనే దాని గురించి మేము ముఖ్యమైన సమాచారాన్ని అందుకుంటాము. మీరు ప్రతి కోడ్ సమీక్షను అభ్యాస వక్రతలో భాగంగా పరిగణించాలి, ఇది మీరు మెరుగుపరచడంలో సహాయపడగలదు. ఎవరైనా మీ కోడ్‌పై వ్యాఖ్యానించినప్పుడు, అతను లేదా ఆమె మీతో అనుభవాన్ని మరియు ఉత్తమ అభ్యాసాలను పంచుకుంటున్నారు. కోడ్ రివ్యూలను పొందకుండానే మీరు మంచి ప్రోగ్రామర్ అవుతారని నేను వ్యక్తిగతంగా నమ్మను. ఎందుకంటే మీ కోడ్ నాణ్యత గురించి మరియు అనుభవజ్ఞుడైన బయటి వ్యక్తి తప్పులను సూచిస్తారా లేదా అనే దాని గురించి కూడా మీకు తెలియదు. t కోడ్ సమీక్షలను అభినందిస్తున్నాము మరియు వాటికి భయపడతారు. వారు చేయకూడదు. కోడ్ రివ్యూలు ఖచ్చితంగా మన కోడ్‌ని మెరుగుపరుస్తాయి. అన్నింటికంటే, మేము ఏమి తప్పు చేస్తున్నాము మరియు దేనిపై శ్రద్ధ వహించాలి అనే దాని గురించి మేము ముఖ్యమైన సమాచారాన్ని అందుకుంటాము. మీరు ప్రతి కోడ్ సమీక్షను అభ్యాస వక్రతలో భాగంగా పరిగణించాలి, ఇది మీరు మెరుగుపరచడంలో సహాయపడగలదు. ఎవరైనా మీ కోడ్‌పై వ్యాఖ్యానించినప్పుడు, అతను లేదా ఆమె మీతో అనుభవాన్ని మరియు ఉత్తమ అభ్యాసాలను పంచుకుంటున్నారు. కోడ్ రివ్యూలను పొందకుండానే మీరు మంచి ప్రోగ్రామర్ అవుతారని నేను వ్యక్తిగతంగా నమ్మను. ఎందుకంటే మీ కోడ్ నాణ్యత గురించి మరియు అనుభవజ్ఞుడైన బయటి వ్యక్తి తప్పులను సూచిస్తారా లేదా అనే దాని గురించి కూడా మీకు తెలియదు. t కోడ్ సమీక్షలను అభినందిస్తున్నాము మరియు వాటికి భయపడతారు. వారు చేయకూడదు. కోడ్ రివ్యూలు ఖచ్చితంగా మన కోడ్‌ని మెరుగుపరుస్తాయి. అన్నింటికంటే, మేము ఏమి తప్పు చేస్తున్నాము మరియు దేనిపై శ్రద్ధ వహించాలి అనే దాని గురించి మేము ముఖ్యమైన సమాచారాన్ని అందుకుంటాము. మీరు ప్రతి కోడ్ సమీక్షను అభ్యాస వక్రతలో భాగంగా పరిగణించాలి, ఇది మీరు మెరుగుపరచడంలో సహాయపడగలదు. ఎవరైనా మీ కోడ్‌పై వ్యాఖ్యానించినప్పుడు, అతను లేదా ఆమె మీతో అనుభవాన్ని మరియు ఉత్తమ అభ్యాసాలను పంచుకుంటున్నారు. కోడ్ రివ్యూలను పొందకుండానే మీరు మంచి ప్రోగ్రామర్ అవుతారని నేను వ్యక్తిగతంగా నమ్మను. ఎందుకంటే మీ కోడ్ నాణ్యత గురించి మరియు అనుభవజ్ఞుడైన బయటి వ్యక్తి తప్పులను సూచిస్తారా లేదా అనే దాని గురించి కూడా మీకు తెలియదు. నేను తప్పు చేస్తున్నాను మరియు దేనిపై శ్రద్ధ వహించాలి. మీరు ప్రతి కోడ్ సమీక్షను అభ్యాస వక్రతలో భాగంగా పరిగణించాలి, ఇది మీరు మెరుగుపరచడంలో సహాయపడగలదు. ఎవరైనా మీ కోడ్‌పై వ్యాఖ్యానించినప్పుడు, అతను లేదా ఆమె మీతో అనుభవాన్ని మరియు ఉత్తమ అభ్యాసాలను పంచుకుంటున్నారు. కోడ్ రివ్యూలను పొందకుండానే మీరు మంచి ప్రోగ్రామర్ అవుతారని నేను వ్యక్తిగతంగా నమ్మను. ఎందుకంటే మీ కోడ్ నాణ్యత గురించి మరియు అనుభవజ్ఞుడైన బయటి వ్యక్తి తప్పులను సూచిస్తారా లేదా అనే దాని గురించి కూడా మీకు తెలియదు. నేను తప్పు చేస్తున్నాను మరియు దేనిపై శ్రద్ధ వహించాలి. మీరు ప్రతి కోడ్ సమీక్షను అభ్యాస వక్రతలో భాగంగా పరిగణించాలి, ఇది మీరు మెరుగుపరచడంలో సహాయపడగలదు. ఎవరైనా మీ కోడ్‌పై వ్యాఖ్యానించినప్పుడు, అతను లేదా ఆమె మీతో అనుభవాన్ని మరియు ఉత్తమ అభ్యాసాలను పంచుకుంటున్నారు. కోడ్ రివ్యూలను పొందకుండానే మీరు మంచి ప్రోగ్రామర్ అవుతారని నేను వ్యక్తిగతంగా నమ్మను. ఎందుకంటే మీ కోడ్ నాణ్యత గురించి మరియు అనుభవజ్ఞుడైన బయటి వ్యక్తి తప్పులను సూచిస్తారా లేదా అనే దాని గురించి కూడా మీకు తెలియదు.
8. మర్మమైన నిర్ణయాలకు ప్రవృత్తి
వివిధ పనులు/సమస్యలు తరచుగా అనేక విభిన్న పరిష్కారాలను కలిగి ఉంటాయి. మరియు అందుబాటులో ఉన్న అన్ని పరిష్కారాలలో, ప్రారంభకులు చాలా క్లిష్టమైన మరియు రహస్యమైన వాటిని ఉపయోగిస్తారు. మరియు అది అర్ధమే: అనుభవశూన్యుడు ప్రోగ్రామర్లు నిన్ననే చాలా విభిన్న అల్గారిథమ్‌లు, నమూనాలు మరియు డేటా నిర్మాణాలను నేర్చుకున్నారు, కాబట్టి వాటిలో కొన్నింటిని అమలు చేయడానికి వారి చేతులు దురదగా ఉన్నాయి. నన్ను నమ్మండి, నేను అలా ఉన్నాను, కాబట్టి నేను ఏమి మాట్లాడుతున్నానో నాకు తెలుసు :) నేను చాలా కాలం పాటు కొంత కార్యాచరణను అమలు చేస్తున్న పరిస్థితి వచ్చింది. ఇది చాలా చాలా క్లిష్టంగా మారింది. అప్పుడు సీనియర్ డెవలపర్ నా కోడ్‌ని తిరిగి వ్రాసారు. అయితే, అతను దానిని ఏమి మరియు ఎలా మార్చాడో చూడాలని నేను చాలా ఆసక్తిగా ఉన్నాను. నేను అతని అమలును చూశాను మరియు అది ఎంత సరళంగా ఉందో చూసి ఆశ్చర్యపోయాను. మరియు మూడు రెట్లు తక్కువ కోడ్ ఉంది. మరియు ఆశ్చర్యకరంగా, ఈ కార్యాచరణ కోసం ఆటోమేటెడ్ పరీక్షలు తీసివేయబడలేదు లేదా మార్చబడలేదు! మరో మాటలో చెప్పాలంటే, సాధారణ తర్కం అలాగే ఉంది. దీని నుండి, నేను ఒక నిర్ణయానికి వచ్చానుఅత్యంత తెలివిగల పరిష్కారాలు ఎల్లప్పుడూ సరళంగా ఉంటాయి . ఈ అవగాహన తర్వాత, కోడింగ్ చాలా సులభమైంది మరియు నా కోడ్ నాణ్యత గణనీయంగా అధిక స్థాయికి పెరిగింది. డిజైన్ నమూనాలు మరియు ఫాన్సీ అల్గారిథమ్‌లను వర్తింపజేయడం ఎప్పుడు విలువైనది అని మీరు అడగండి? వాటిని దరఖాస్తు చేసినప్పుడు సరళమైన మరియు అత్యంత కాంపాక్ట్ పరిష్కారం ఉంటుంది.
9. చక్రం తిరిగి ఆవిష్కరించడం
చక్రం చాలా కాలం క్రితం కనుగొనబడిన ఒక మన్నికైన పరిష్కారం. ఈ వ్యతిరేక నమూనాలో, డెవలపర్ ఇప్పటికే పరిష్కరించబడిన సమస్య కోసం తన స్వంత యాజమాన్య పరిష్కారాన్ని అమలు చేస్తాడు. కొన్నిసార్లు ఈ ఇప్పటికే ఉన్న పరిష్కారాలు ప్రోగ్రామర్ అందించే దానికంటే మెరుగ్గా ఉంటాయి. నియమం ప్రకారం, చక్రాన్ని తిరిగి ఆవిష్కరిస్తే సమయం కోల్పోయింది మరియు ఉత్పాదకత తగ్గుతుంది, ఎందుకంటే మీరు కనుగొన్న పరిష్కారం ఉత్తమమైనది కాదు, లేదా, మీరు ఒకదాన్ని కనుగొనలేకపోవచ్చు. మా స్వంత స్వతంత్ర పరిష్కారాన్ని సృష్టించే అవకాశాన్ని మేము తోసిపుచ్చలేము: మేము అలా చేస్తే, అప్పుడు మిగిలేది కాపీ-అండ్-పేస్ట్ ప్రోగ్రామింగ్ మాత్రమే. రెడీమేడ్ సొల్యూషన్స్‌ని ఉపయోగించడం ద్వారా లేదా కస్టమ్ సొల్యూషన్‌లను రూపొందించడం ద్వారా వాటిని సమర్ధవంతంగా మరియు వెంటనే పరిష్కరించడానికి ఉత్పన్నమయ్యే నిర్దిష్ట ప్రోగ్రామింగ్ టాస్క్‌ల ద్వారా ప్రోగ్రామర్ సరిగ్గా మార్గనిర్దేశం చేయాలి. ఒకవైపు, విశ్వవిద్యాలయాలలో మరియు ఆన్‌లైన్ కోర్సులలో, చక్రాలను తిరిగి ఆవిష్కరించడంలో మాకు సహాయపడటానికి రూపొందించబడిన వివిధ రకాల టాస్క్‌లతో మేము దూసుకుపోతున్నాము. కానీ మొదటి చూపులో మాత్రమే: ఇక్కడ నిజమైన ఉద్దేశ్యం అల్గారిథమిక్ ఆలోచనను అభివృద్ధి చేయడం మరియు భాషా వాక్యనిర్మాణంలో లోతైన నైపుణ్యం. ఇటువంటి పనులు అల్గారిథమ్‌లు మరియు డేటా స్ట్రక్చర్‌లను బాగా అర్థం చేసుకోవడంలో మీకు సహాయపడతాయి మరియు అవసరమైతే మరింత అధునాతన ప్రతిరూపాలను అమలు చేయడానికి మీకు నైపుణ్యాలను అందిస్తాయి (ఇది కొన్నిసార్లు అవసరం, కానీ ఇది చాలా అరుదు). నిజ జీవితంలో, మీ అవసరాలను తీర్చే చక్రాలు చాలా కాలం నుండి ఉన్నందున, అధిక సంఖ్యలో సందర్భాలలో మీరు మీ స్వంత చక్రాన్ని కనుగొనవలసిన అవసరం లేదు. బహుశా మీ అనుభవం మీకు అవసరమైన కార్యాచరణను అమలు చేయడం గురించి తెలుసుకోవడం నుండి మిమ్మల్ని నిరోధిస్తుంది. ఇక్కడే మీరు ఈ ఆర్టికల్‌లోని మొదటి పాయింట్‌లో ఇచ్చిన సలహాను తీసుకోవాలి, అవి, సహాయం కోసం మరింత అనుభవజ్ఞులైన సహోద్యోగులను అడగండి. వారు మీకు మార్గనిర్దేశం చేయగలరు (ఉదాహరణకు, మీ Google శోధనలో మిమ్మల్ని సరైన దిశలో చూపుతారు) లేదా నిర్దిష్ట అమలును సూచిస్తారు (ఉదాహరణకు, కొన్ని లైబ్రరీ).
10. పరీక్షలు రాయడంలో వైఫల్యం
కొత్తవారందరూ పరీక్షలు రాయడానికి ఇష్టపడరు. అయితే ఇక్కడ కొత్తవారిని ఎందుకు గుర్తించాలి? ఎక్కువ అనుభవజ్ఞులైన డెవలపర్లు కూడా పరీక్షలు రాయడానికి ఇష్టపడరు, అయితే పరీక్షలు ఎందుకు అవసరమో వారు బాగా అర్థం చేసుకుంటారు. మీరు పూర్తిగా పచ్చగా ఉన్నప్పుడు, మీరు వాటిని ఎందుకు వ్రాయాలి అని మీరు ఆలోచిస్తారు. ప్రతిదీ పని చేస్తుంది, కాబట్టి తప్పులు ఉండకూడదు. కానీ మీ మార్పులు సిస్టమ్‌లో మరెక్కడా విచ్ఛిన్నం కావు అని మీరు ఎలా నిర్ధారిస్తారు? మీరు మంచి కంటే ఎక్కువ హాని కలిగించే మార్పులను చేస్తే మీ సహోద్యోగులు దానిని అభినందించరు. ఇక్కడే పరీక్షలు మన రక్షణకు వస్తాయి. అప్లికేషన్ యొక్క కోడ్ పరీక్షల ద్వారా ఎంత ఎక్కువ కవర్ చేయబడితే, అంత మంచిది (దీనిని కోడ్ కవరేజ్ లేదా టెస్ట్ కవరేజ్ అంటారు). అప్లికేషన్ మంచి పరీక్ష కవరేజీని కలిగి ఉంటే, మీ కోడ్ ద్వారా విచ్ఛిన్నమయ్యే స్థలాలను కనుగొనడానికి మీరు అన్ని పరీక్షలను అమలు చేయవచ్చు. మరియు నేను పై ఉదాహరణలో చెప్పినట్లుగా, సీనియర్ డెవలపర్ కోడ్‌ని రీఫ్యాక్టర్ చేసినప్పుడు, పరీక్షలు విఫలం కాలేదు. సాధారణ తర్కం మారకపోవడమే దీనికి కారణం. నిర్దిష్ట ఫంక్షనాలిటీ యొక్క లాజిక్ మార్చబడిందా లేదా అని నిరూపించడానికి మేము పరీక్షలను ఉపయోగిస్తాము. కాబట్టి మీరు పరీక్షలు రాయడం ఇష్టం లేకపోయినా, అవి ఖచ్చితంగా ఉపయోగపడతాయి మరియు వాటి కోసం వెచ్చించే సమయానికి విలువైనవి.
11. మితిమీరిన వ్యాఖ్యలు
చాలా మంది డెవలపర్లు పరిపూర్ణతతో బాధపడుతున్నారు మరియు కొత్తవారు దీనికి మినహాయింపు కాదు. వారు ప్రతి ఒక్కరిపై మరియు ప్రతిదానిపై వ్యాఖ్యానించడం ప్రారంభించినప్పుడు వారు కొన్నిసార్లు ఈ ప్రవృత్తి యొక్క ఒక కోణాన్ని మాత్రమే ప్రదర్శిస్తారు. కోడ్ చాలా స్పష్టంగా ఉన్నందున అనవసరమైన వ్యాఖ్యలు చేయడం కూడా:
Cat cat = new Cat(); // Cat object
వ్యాఖ్యానించడం కోడ్ ఎల్లప్పుడూ మంచిది కాదని అన్ని అనుభవం లేని ప్రోగ్రామర్లు వెంటనే గ్రహించలేరు, ఎందుకంటే మితిమీరిన వ్యాఖ్యలు కోడ్‌ను చిందరవందర చేస్తాయి మరియు చదవడం కష్టతరం చేస్తాయి. మరియు కోడ్ మారితే, కానీ పాత వ్యాఖ్యలు నవీకరించబడకపోతే? అప్పుడు వారు మనల్ని తప్పుదారి పట్టిస్తారు మరియు గందరగోళానికి గురిచేస్తారు. అలాంటప్పుడు అలాంటి వ్యాఖ్య ఎందుకు? సాధారణంగా, బాగా వ్రాసిన కోడ్ వ్యాఖ్యానించవలసిన అవసరం లేదు , దానిలోని ప్రతిదీ ఇప్పటికే స్పష్టంగా మరియు చదవగలిగేలా ఉంది. మీరు వ్యాఖ్యను వ్రాయవలసి వస్తే, మీరు ఇప్పటికే కోడ్ యొక్క రీడబిలిటీని పాడు చేసారు మరియు పరిస్థితిని ఎలాగైనా సరిచేయడానికి ప్రయత్నిస్తున్నారు. మొదటి నుండి చదవగలిగే కోడ్‌ను వ్రాయడం ఉత్తమ విధానం, అంటే వ్యాఖ్యలు అవసరం లేని కోడ్. పద్ధతులు, వేరియబుల్స్ మరియు తరగతులకు సరైన పేరు పెట్టే సంప్రదాయాలను అనుసరించాల్సిన అవసరాన్ని నేను ప్రస్తావించకుండా ఉండలేను. ఇదిగో నా నియమం: మీ అప్లికేషన్‌లోని కార్యాచరణను స్పష్టంగా వివరించే వ్యాఖ్య లేదా సరైన పేరు పెట్టడం ఉత్తమ వ్యాఖ్య .
12. చెడ్డ పేరు పెట్టడం
కొత్తవారు క్లాసులు, వేరియబుల్స్, మెథడ్స్ మొదలైన వాటి పేర్లను వేగంగా మరియు వదులుగా ఆడతారు. ఉదాహరణకు, పేరు దాని ప్రయోజనాన్ని వివరించని తరగతిని సృష్టించడం ద్వారా. లేదా వారు x వంటి చిన్న పేరుతో వేరియబుల్‌ని ప్రకటిస్తారు . అవి n మరియు y అనే మరో రెండు వేరియబుల్స్ ఉన్నప్పుడుసృష్టించబడతాయి, x దేనికి బాధ్యత వహిస్తుందో గుర్తుంచుకోవడం చాలా కష్టం అవుతుంది. ఈ పరిస్థితిని ఎదుర్కొన్నప్పుడు, మీరు కోడ్ గురించి జాగ్రత్తగా ఆలోచించాలి, మైక్రోస్కోప్‌లో విశ్లేషించడం (బహుశా డీబగ్గర్ ఉపయోగించి), ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి కార్యాచరణను అధ్యయనం చేయడం. ఇక్కడే నేను పైన పేర్కొన్న సరైన నామకరణ సంప్రదాయాలు మా సహాయానికి వస్తాయి. సరైన పేర్లు కోడ్ రీడబిలిటీని మెరుగుపరుస్తాయి, తద్వారా కోడ్‌తో మిమ్మల్ని మీరు పరిచయం చేసుకోవడానికి అవసరమైన సమయాన్ని తగ్గిస్తుంది, ఎందుకంటే దాని పేరు దాని కార్యాచరణను సుమారుగా వివరించినప్పుడు పద్ధతిని ఉపయోగించడం చాలా సులభం. కోడ్‌లోని ప్రతిదీ పేర్లను కలిగి ఉంటుంది (వేరియబుల్స్, పద్ధతులు, తరగతులు, వస్తువులు, ఫైల్‌లు మొదలైనవి), కాబట్టి సరైన, క్లీన్ కోడ్‌ను రూపొందించేటప్పుడు ఈ పాయింట్ చాలా ముఖ్యమైనది. పేరు అర్థాన్ని తెలియజేయాలని మీరు గుర్తుంచుకోవాలి, ఉదాహరణకు, వేరియబుల్ ఎందుకు ఉంది, అది ఏమి చేస్తుంది, మరియు అది ఎలా ఉపయోగించబడుతుంది. వేరియబుల్‌కి మంచి పేరు పెట్టడమే ఉత్తమమైన వ్యాఖ్య అని నేను ఒకటి కంటే ఎక్కువసార్లు గమనించాను. వ్యాఖ్యలపై లోతైన అధ్యయనం మరియు సరైన పేరు కోసం, నేను టైమ్‌లెస్ క్లాసిక్‌లను చదవమని సిఫార్సు చేస్తున్నాను:రాబర్ట్ మార్టిన్ రచించిన "క్లీన్ కోడ్: ఎ హ్యాండ్‌బుక్ ఆఫ్ ఎజైల్ సాఫ్ట్‌వేర్ క్రాఫ్ట్స్‌మ్యాన్‌షిప్" . ఆ గమనికలో, ఈ వ్యాసం యొక్క మొదటి భాగం (నా ప్రతిబింబాలు) ముగిసింది. కొనసాగుతుంది...
కాబట్టి, ఎటువంటి సందేహం లేకుండా ప్రారంభిద్దాం:
మీరు ఎదుర్కొనే ప్రతి సమస్య లేదా ఎక్కిళ్ళు గురించి మీరు మీ సహోద్యోగులను మరియు పరిచయస్తులను ఇబ్బంది పెట్టడం ప్రారంభించినప్పుడు ఇక్కడ నా ఉద్దేశ్యం. అడగడం మంచిది, కానీ ప్రశ్నలతో అతిగా వెళ్లవద్దు. లేకపోతే, ప్రజలు మిమ్మల్ని బాధించేదిగా భావించవచ్చు. మీరు ఏదైనా విషయం గురించి గందరగోళానికి గురైతే, మొదటి విషయం ఏమిటంటే, ఉత్తమ శోధన ఇంజిన్‌లో మీ శోధన నైపుణ్యాలను ఉపయోగించడం - Google. వేరొకరు ఇప్పటికే అధిక సంఖ్యలో అపారమయిన లోపాలు మరియు ఇతర సమస్యలను ఎదుర్కొన్నారు. మరియు మీరు మీ ప్రశ్నను గూగుల్ చేసి, ఇలాంటి సమస్య గురించి తెలిసిన వ్యక్తుల సంఖ్యను చూస్తే మరియు మీరు మీ స్వంత పనిలో దరఖాస్తు చేసుకోగల సమగ్ర సమాధానాలను ఇప్పటికే అందుకున్నట్లయితే మీరు చాలా ఆశ్చర్యపోతారు. అందుకే మీ సహోద్యోగులు "గూగుల్ ఇట్" అని ప్రత్యుత్తరం ఇవ్వడం మీరు తరచుగా వింటారు. చేయవద్దు' ఈ సమాధానంతో బాధపడకండి - మీ సహోద్యోగి మీ వ్యక్తిగత ఉపాధ్యాయుడు కాదు, అతను మీ పని రంగంలోని అన్ని సూక్ష్మబేధాలను తెలియజేయాలి. ఇంటర్నెట్ యొక్క అంతులేని విస్తరణలు మీ గురువుగా ఉంటాయి. కొన్నిసార్లు ప్రోగ్రామర్లను కూడా సూచిస్తారుGoogle శోధనలో బ్లాక్ బెల్ట్ ఉన్న వ్యక్తులు . కాబట్టి మనకు " ఎక్కిళ్ళు" ఉన్నట్లయితే, మేము ముందుగా సమస్యను గూగుల్ చేస్తాము. ఒక పరిష్కారం కనుగొనబడకపోతే (ఇది చాలా అరుదు, కానీ ఇది జరుగుతుంది), అప్పుడు మాత్రమే మేము సహోద్యోగులను అడగడం ప్రారంభిస్తాము. మీరు స్పీడ్ బంప్ లేదా అపారమయిన ఎర్రర్ మెసేజ్‌ని నొక్కినప్పుడు మీరు చేసే దాని కంటే సమస్యను పరిష్కరించడానికి మీరు ఏ విధానాన్ని ఎంచుకోవాలి అనే దాని గురించి సలహా పొందడం కోసం తక్షణ ప్రశ్నలు. అన్నింటికంటే, వారు మీ ప్రాధాన్య విధానానికి మించి చూడగలరు మరియు ఏదైనా విధానం దీర్ఘకాలంలో ఎక్కడికి దారితీస్తుందో వెంటనే అంచనా వేయగలరు.
మీరు ఇలాంటి సమస్య (కానీ బహుశా అదే కాదు) మరియు అనుబంధిత పరిష్కారాన్ని కనుగొన్నప్పుడు ఇది సాధారణంగా జరుగుతుంది, ఉదాహరణకు, StackOverflowలో. మీరు ఈ పరిష్కారాన్ని పట్టుకుని, వివరాలను మరింత లోతుగా పరిశోధించకుండా కాపీ చేసి అతికించండి. ఆపై మీరు లేదా మీ సహోద్యోగులు మీ కోడ్‌లో కొన్ని వింత బగ్‌లు లేదా తప్పు ప్రవర్తనను కనుగొంటారు. మరియు వారు ఎక్కడ నుండి వచ్చారో ఎవరూ వెంటనే ఊహించలేరు. చివరికి, వాస్తవానికి, కాపీ చేయబడిన కోడ్ ఉన్న స్థలం కనుగొనబడుతుంది మరియు మీ పరిష్కారం కోసం మీరు ఖచ్చితంగా ప్రశంసించబడరు. కాబట్టి, మీరు StackOverflow (లేదా మరెక్కడైనా) పై రెడీమేడ్ పరిష్కారాన్ని కనుగొన్నప్పుడు, మీరు మొదట ఏమి, ఎలా మరియు ఎందుకు అనే విషయాలను పూర్తిగా అర్థం చేసుకోవాలి. బహుశా సంబంధిత ఫంక్షనాలిటీని గూగుల్ చేసి, దాని కోసం డాక్యుమెంటేషన్ చదవండి. మరియు మీరు దీన్ని పూర్తి చేసిన తర్వాత మాత్రమే మీ ప్రాజెక్ట్‌కి జోడించాలి.
మరియు మీరు చాలా ప్రశ్నలను పోగు చేస్తే, మీ టీమ్ లీడ్ మీకు సమాధానం ఇవ్వడానికి చాలా సమయం వెచ్చించాల్సి ఉంటుంది. టీమ్ లీడ్‌కి సంబంధించిన ప్రశ్నల సంఖ్యను తగ్గించడానికి ఏమి చేయాలి:
GO TO FULL VERSION