ఫ్రంట్-ఎండ్ ఎంట్రోపీ (Front-end entropy) అనేది నిజం. ఒక కోడ్‌బేస్ రాత్రికి రాత్రే కుప్పకూలిపోదు. అది పేరుకుపోతుంది. ఒక మంగళవారం మీరు ఒక డేట్-ఫార్మాటింగ్ లైబ్రరీని జోడిస్తారు. ఆరు నెలల తర్వాత, మొదటిది దొరకకపోవడం వల్ల మరొకరు ఇంకోదాన్ని జోడిస్తారు. మీరు ఇకపై సపోర్ట్ చేయని బ్రౌజర్‌ల కోసం పాలిఫిల్స్ (Polyfills) పేరుకుపోతాయి. బిల్డ్ టూల్స్ ఒకదానిపై ఒకటి పొరలుగా పేరుకుపోతాయి. చివరికి, node_modules ఫోల్డర్ ఒక డిజిటల్ జంక్ డ్రాయర్‌లా మారుతుంది, అక్కడ భయం లేకుండా దేనినీ పారేయలేము. మీరు అప్‌డేట్ చేయడం ఆపేస్తారు. ఆ తర్వాత చూడటం కూడా మానేస్తారు. అప్పుడే ప్రతి చిన్న మార్పు ఒక జూదంలా మారుతుంది.

ఒక పాత ప్రాజెక్ట్‌లో Material UIని అప్‌డేట్ చేయడానికి ప్రయత్నించినప్పుడు నేను ఈ సమస్యను ఎదుర్కొన్నాను. నేను package.json ఓపెన్ చేసి చూస్తే, అందులోని సగం ఎంట్రీలను కూడా గుర్తుపట్టలేకపోయాను. డజన్ల కొద్దీ లైబ్రరీలు అక్కడ ఉన్నాయి, కొన్ని సంవత్సరాల క్రితమే పాతబడిపోయాయి, మరికొన్ని ఎంత అస్పష్టంగా ఉన్నాయంటే, వాటిని ఎవరు, ఎందుకు జోడించారో తెలుసుకోవడానికి నేను git blame చెక్ చేయాల్సి వచ్చింది. కొత్త Material UI వెర్షన్ కోసం నేను ఇన్‌స్టాల్ కమాండ్‌ను రన్ చేయగానే, టెర్మినల్ పీర్ డిపెండెన్సీ వార్నింగ్‌లతో (peer dependency warnings) నిండిపోయింది. నేను అప్‌డేట్ చేయాలనుకున్న ప్యాకేజీ బాగుంది, కానీ దాని చుట్టూ ఉన్న ఎకోసిస్టమ్ సరిగ్గా లేదు. నేను కేవలం ఒక అప్‌డేట్ చేయడం లేదని, ఒక శిథిలాన్ని తవ్వుతున్నానని నాకు అర్థమైంది.

ఈ గందరగోళం మీ గర్వం కంటే ఎక్కువ ఖర్చు పెడుతుంది

డిపెండెన్సీలను విస్మరించడం అనేది కేవలం పైపైన కనిపించే సమస్య కాదు. ఇది నిజమైన, ఖరీదైన సమస్యలను సృష్టిస్తుంది.

సెక్యూరిటీ రిస్క్‌లు (Security risks) స్పష్టమైన ముప్పు. వదిలివేసిన ప్యాకేజీలు వెల్లడైన లోపాలను (vulnerabilities) కలిగి ఉంటాయి, వీటిని స్కానర్లు ప్రతి వారం గుర్తిస్తాయి. ఇంకా దారుణమైన విషయం ఏమిటంటే, మీరు నేరుగా ఇన్‌స్టాల్ చేసిన లైబ్రరీలు బాగుండవచ్చు, కానీ అవి తీసుకువచ్చిన ట్రాన్సిటివ్ డిపెండెన్సీలు (transitive dependencies) సరిగ్గా లేకపోవచ్చు. మీరు తెలియకుండానే ఇతరుల టెక్నికల్ డెట్‌ను (technical debt) భుజాన వేసుకుంటారు.

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

లైబ్రరీలు అంతరించిపోతాయి. యాక్టివ్ మెయింటైనర్లు లేని ప్యాకేజీ డిఫాల్ట్‌గా మీ సొంత ఫోర్క్ (fork) లా మారుతుంది. అది విచ్ఛిన్నమైనప్పుడు, అర్ధరాత్రి వేళ దాని మినీఫైడ్ సోర్స్ కోడ్‌ను చదవాల్సి వచ్చేది మీరే. కమ్యూనిటీ మెరుగైన పరిష్కారాల వైపు వెళ్ళిపోతుంది, కానీ మీ టీమ్ మాత్రం ఒక పాత శిథిలాన్ని మెయింటైన్ చేస్తూ ఇరుక్కుపోతుంది.

పని వేగం (Velocity) పడిపోతుంది. కొత్త డెవలపర్లు వెబ్ స్టాండర్డ్స్ లేదా మెయిన్ స్ట్రీమ్ ప్రత్యామ్నాయాల ద్వారా భర్తీ చేయబడిన పాత టూల్స్ కోసం వాటి ప్రత్యేక APIలను నేర్చుకోవడానికే తమ మొదటి రోజులను గడుపుతారు. ఫీచర్లను డెలివరీ చేయడానికి బదులుగా, మీ సీనియర్ ఇంజనీర్లు 2015 నాటి టాస్క్ రన్నర్‌ను ఈ ప్రాజెక్ట్ ఎందుకు ఇంకా వాడుతుందో వివరించే చరిత్రకారులుగా మారుతారు.

ఒక్క వెర్షన్‌ను కూడా మార్చకముందే ఆడిట్ చేయండి

అన్నింటినీ ఒకేసారి అప్‌డేట్ చేసి, టెస్ట్‌లు పాస్ అవుతాయని ఆశించడం అతి పెద్ద తప్పు. ఆడిట్‌తో ప్రారంభించండి. package.json తీసుకోండి మరియు ప్రతి ఎంట్రీని నిశితంగా పరిశీలించండి.

ఈ నాలుగు ప్రశ్నలు వేయండి:

  • ఇది ఏ సమస్యను పరిష్కరిస్తుంది?
  • మనం దీనిని ఖచ్చితంగా ఎక్కడ ఉపయోగిస్తున్నాము?
  • ఇది ఇంకా అవసరమా?
  • ఇప్పుడు దీనికంటే మెరుగైన ప్రత్యామ్నాయం ఉందా?

మీరు అనవసరమైన వాటిని (redundancy) గుర్తిస్తారు. బహుశా ఇద్దరు డెవలపర్లు వేర్వేరు సమయాల్లో ఒకే సమస్యను పరిష్కరించినందున moment మరియు date-fns రెండూ జాబితాలో ఉండవచ్చు. బహుశా మీ అనలిటిక్స్ ప్రకారం పాత బ్రౌజర్‌ల నుండి ట్రాఫిక్ సున్నా ఉన్నప్పటికీ, Internet Explorer కోసం ఒక పాలిఫిల్ ఇంకా అందుబాటులో ఉండవచ్చు. బహుశా ఆధునిక బ్రౌజర్‌లు ఎడ్జ్ కేస్‌లను నేరుగా హ్యాండిల్ చేయగలవు కాబట్టి, fetch చుట్టూ ఉన్న కస్టమ్ రాపర్‌ను తొలగించవచ్చు.

కొన్నిసార్లు అప్‌డేట్ చేయడం కంటే మార్చడం (replacement) మేలు. మూడు సంవత్సరాల బ్రేకింగ్ మార్పుల మధ్య ఒక పాత చార్టింగ్ లైబ్రరీని సరిచేయడం కంటే, ఒక స్థిరమైన ప్రత్యామ్నాయాన్ని ఉపయోగించి కొన్ని కాంపోనెంట్లను మళ్ళీ నిర్మించడం సులభం కావచ్చు. ఏదైనా తొలగించడానికి సిద్ధంగా ఉండండి.

దాగి ఉన్న పొర: ట్రాన్సిటివ్ డిపెండెన్సీలు మరియు Semver

డైరెక్ట్ డిపెండెన్సీలు ఐస్‌బర్గ్ యొక్క కనిపించే భాగం మాత్రమే. అసలైన బరువు ట్రాన్సిటివ్ డిపెండెన్సీలలో (transitive dependencies) ఉంటుంది — అంటే మీ ప్యాకేజీలకు అవసరమైన ఇతర ప్యాకేజీలు. మీరు వాటిని ఎంచుకోలేదు, కానీ అవి మీ బిల్డ్‌లో రన్ అవుతాయి. అవి మీ బండిల్ పరిమాణాన్ని పెంచుతాయి, సెక్యూరిటీ రిస్క్‌లను పెంచుతాయి మరియు అప్పుడప్పుడు ఒకదానితో ఒకటి ఘర్షణ పడి అర్థం కాని బిల్డ్ ఎర్రర్‌లను కలిగిస్తాయి.

సెమాంటిక్ వెర్షనింగ్ (semantic versioning) అంటే ఏమిటో అర్థం చేసుకోవాలి, అది మీకు ఎలా ఉపయోగపడుతుందో అని ఆశించడం కాదు.

  • మేజర్ అప్‌డేట్‌లు (Major updates): ఇవి మైగ్రేషన్లు. ఇవి బ్రేకింగ్ మార్పులు అని భావించి జాగ్రత్తగా ఉండండి. changelog చదవండి, సమయాన్ని కేటాయించండి మరియు పూర్తిగా టెస్ట్ చేయండి.
  • మైనర్ అప్‌డేట్‌లు (Minor updates): ఇవి కొత్త ఫీచర్లను జోడిస్తాయి. ఇవి కూడా ప్రవర్తనను (behavior) స్వల్పంగా మార్చవచ్చు. ఇవి ఎటువంటి ఇబ్బంది లేకుండా జరుగుతాయని అనుకోవద్దు.
  • ప్యాచ్ అప్‌డేట్‌లు (Patch updates): ఇవి బగ్‌లను సరిచేస్తాయి. ఇవి సాధారణంగా సురక్షితమే, కానీ మీ కోడ్ ఆ బగ్ మీద ఆధారపడి ఉన్నా, లేదా ఆ ప్యాచ్ మీరు మార్చిన అంతర్గత అంశాన్ని (internal) ప్రభావితం చేసినా, సమస్యలు రావచ్చు.

నియమాలను తెలుసుకోవడం వల్ల మీరు దేనినీ తాకకముందే రిస్క్‌ను అంచనా వేయగలరు.

మీ టూల్స్‌ను ఒక నిపుణుడిలా ఉపయోగించండి

మీరు Yarn ఉపయోగిస్తుంటే, అందులోని కొన్ని బిల్ట్-ఇన్ కమాండ్‌లు ఊహలను ఒక పద్ధతిగా మారుస్తాయి.

మొదట yarn outdated రన్ చేయండి. ఇది ఏయే వెర్షన్లు పాతబడ్డాయో ఒక స్నాప్‌షాట్‌ను ఇస్తుంది