Front-end entropy என்பது நிஜமானது. ஒரு codebase ஒரே இரவில் சரிந்துவிடாது. அது படிப்படியாகக் குவிகிறது. ஒரு செவ்வாய்க்கிழமை நீங்கள் ஒரு date-formatting library-ஐச் சேர்க்கிறீர்கள். ஆறு மாதங்களுக்குப் பிறகு, யாரோ ஒருவர் முதல் library-ஐக் கண்டுபிடிக்காததால் இன்னொன்றைச் சேர்க்கிறார்கள். நீங்கள் இனி ஆதரிக்காத பிரவுசர்களுக்கான polyfills குவிகின்றன. Build tools ஒன்றன் மேல் ஒன்றாக அடுக்குகளாகச் சேருகின்றன. இறுதியில், node_modules folder என்பது எதையும் பயமின்றித் தூக்கி எறிய முடியாத ஒரு டிஜிட்டல் குப்பைத் தொட்டியாக மாறிவிடுகிறது. நீங்கள் அப்டேட் செய்வதை நிறுத்துகிறீர்கள். பிறகு அதைப் பார்ப்பதையே நிறுத்திவிடுகிறீர்கள். அப்போதுதான் ஒவ்வொரு சிறிய மாற்றமும் ஒரு சூதாட்டமாக மாறுகிறது.

ஒரு பழைய புராஜெக்ட்டில் Material UI-ஐ அப்டேட் செய்ய முயன்றபோது நான் இந்தச் சிக்கலைச் சந்தித்தேன். நான் package.json-ஐத் திறந்தபோது, அதில் இருந்த பாதிப் பதிவுகளையே அடையாளம் காண முடியாமல் போனது. டஜன் கணக்கான libraries அங்கே இருந்தன, சில பல வருடங்களுக்கு முந்தையவை, சில மிகவும் தெளிவற்றவை, அவற்றை யார் ஏன் சேர்த்தார்கள் என்பதைக் கண்டறிய நான் git blame-ஐப் பார்க்க வேண்டியிருந்தது. புதிய Material UI பதிப்பிற்கான install command-ஐ நான் இயக்கியபோது, terminal peer dependency எச்சரிக்கைகளால் (warnings) மின்னியது. நான் அப்டேட் செய்ய விரும்பிய package சரியாக இருந்தது. ஆனால் அதைச் சுற்றியிருந்த ecosystem சரியாக இல்லை. நான் ஒரு upgrade-ஐச் செய்யவில்லை, மாறாக ஒரு சிதிலமடைந்த இடிபாடுகளைத் தோண்டி எடுக்கிறேன் என்பதை உணர்ந்தேன்.

ஏன் இந்தச் சிக்கல் பெருமையை விட அதிக இழப்பை ஏற்படுத்துகிறது

Dependencies-ஐப் புறக்கணிப்பது என்பது வெறும் தோற்றပိုင်းப் பிரச்சனை அல்ல. அது உண்மையான, அதிகச் செலவு பிடிக்கும் சிக்கல்களை உருவாக்குகிறது.

Security risks என்பது வெளிப்படையான அச்சுறுத்தல். கைவிடப்பட்ட packages-களில் ஸ்கேனர்கள் வாராவாரம் கண்டறியும் பாதிப்புகள் (vulnerabilities) இருக்கும். அதைவிட மோசமான விஷயம் என்னவென்றால், நீங்கள் நேரடியாக நிறுவிய libraries சரியாக இருக்கலாம், ஆனால் அவை இழுத்து வரும் transitive dependencies சரியாக இருக்காது. நீங்கள் தெரியாமலேயே மற்றவர்களின் technical debt-ஐ ஏற்கிறீர்கள்.

விலை தூரம் அதிகரிக்க அதிகரிக்க கூடுகிறது. நீங்கள் எவ்வளவு காலம் காத்திருக்கிறீர்களோ, அவ்வளவு அதிகமாக version gap வளரும். ஒரு major React version-ஐத் தாண்டுவது ஒரு வேலை. ஆனால் மூன்று version-களைத் தாண்டுவது வாரக்கணக்கில் நீடிக்கும் ஒரு migration project ஆகும். நீங்கள் bug fixes, performance improvements மற்றும் நவீன கருவிகளுடனான (modern tooling) இணக்கத்தன்மையை இழக்கிறீர்கள். குழுவினர் இனித் தேவையில்லாத கட்டுப்பாடுகளுக்கு மத்தியிலேயே வேலை செய்ய வேண்டியிருக்கும்.

Libraries இறந்துவிடுகின்றன. பராமரிப்பாளர்கள் (maintainers) இல்லாத ஒரு package தானாகவே உங்கள் தனிப்பட்ட fork ஆகிவிடும். அது உடைந்து போகும்போது, நள்ளிரவில் அதன் minified source code-ஐப் படிப்பவர் நீங்கள்தான். சமூகம் சிறந்த தீர்வுகளை நோக்கி நகர்ந்துவிட்டது, ஆனால் உங்கள் குழு ஒரு பேயைப் பராமரிப்பதிலேயே சிக்கிக்கொண்டது.

Velocity craters. புதிய டெவலப்பர்கள், இணையத் தரநிலைகள் (web standards) அல்லது முக்கிய மாற்றுகளால் (mainstream alternatives) மாற்றப்பட்ட கருவிகளின் விசித்திரமான APIs-களைக் கற்றுக்கொள்வதிலேயே தங்கள் முதல் நாட்களைச் செலவிடுகிறார்கள். புதிய அம்சங்களை (features) உருவாக்குவதற்குப் பதிலாக, உங்கள் சீனியர் இன்ஜினியர்கள் ஏன் இந்த புராஜெக்ட் இன்னும் 2015-ஆம் ஆண்டின் task runner-ஐப் பயன்படுத்துகிறது என்று விளக்கும் வரலாற்றாசிரியர்களாக மாறுகிறார்கள்.

ஒரு பதிப்பைத் தொடுவதற்கு முன்பே தணிக்கை (Audit) செய்யுங்கள்

அனைத்தையும் ஒரே நேரத்தில் அப்டேட் செய்து, டெஸ்ட்கள் (tests) சரியாக வரும் என்று எதிர்பார்ப்பதே மிகப்பெரிய தவறு. முதலில் ஒரு audit-லிருந்து தொடங்குங்கள். package.json-ஐ எடுத்து ஒவ்வொரு பதிவையும் ஆராயுங்கள்.

நான்கு கேள்விகளைக் கேளுங்கள்:

  • இது எந்தப் பிரச்சனையைத் தீர்க்கிறது?
  • நாம் இதை சரியாக எங்கே பயன்படுத்துகிறோம்?
  • இது இன்னும் அவசியமா?
  • இப்போது இதற்குச் சிறந்த மாற்று இருக்கிறதா?

நீங்கள் தேவையற்ற விஷயங்களைக் (redundancy) காண்பீர்கள். ஒருவேளை moment மற்றும் date-fns ஆகிய இரண்டும் பட்டியலில் இருக்கலாம், ஏனெனில் இரண்டு டெவலப்பர்கள் வெவ்வேறு நேரங்களில் ஒரே பிரச்சனையைத் தீர்க்க முயன்றிருக்கலாம். ஒருவேளை உங்கள் analytics பழைய பிரவுசர்களிலிருந்து (legacy browsers) பூஜ்ஜிய டிராஃபிக்கைக் காட்டினாலும், Internet Explorer-க்கான polyfill இன்னும் இருக்கலாம். ஒருவேளை fetch-ஐச் சுற்றியுள்ள ஒரு custom wrapper-ஐ நீக்கிவிடலாம், ஏனெனில் நவீன பிரவுசர்கள் அந்தச் சிக்கல்களைத் தாங்களாகவே கையாளுகின்றன.

சில நேரங்களில் அப்டேட் செய்வதை விட மாற்றுவது (replacement) சிறந்தது. மூன்று வருடங்களாகத் தொடர்ந்து மாறி வரும் ஒரு கைவிடப்பட்ட charting library-யுடன் போராடுவதை விட, ஒரு நிலையான (stable) மாற்றாக மாற்றி சில components-களை மீண்டும் உருவாக்குவது எளிது. எதையும் நீக்கத் தயங்காதீர்கள்.

மறைக்கப்பட்ட அடுக்கு: Transitive Dependencies மற்றும் Semver

Direct dependencies என்பது பனிப்பாறையின் (iceberg) கண்ணுக்குத் தெரியும் பகுதி மட்டுமே. உண்மையான பெரும்பகுதி transitive dependencies-களில், அதாவது உங்கள் packages-களுக்குத் தேவைப்படும் packages-களில் உள்ளது. நீங்கள் அவற்றைத் தேர்ந்தெடுக்கவில்லை, ஆனால் அவை உங்கள் build-இல் இயங்குகின்றன. அவை உங்கள் bundle அளவை அதிகரிக்கின்றன, தாக்குதல் பரப்பை (attack surface) விரிவுபடுத்துகின்றன, மேலும் சில நேரங்களில் புரியாத build errors-களை உருவாக்கும் வகையில் ஒன்றுடன் ஒன்று மோதிக்கொள்கின்றன.

Semantic versioning என்பது நீங்கள் எதை எதிர்பார்க்கிறீர்களோ அதை வைத்து அல்ல, அது உண்மையில் எதைக் குறிக்கிறதோ அதை வைத்துப் படிக்க வேண்டும்.

  • Major updates: இவை migrations ஆகும். மற்றபடி நிரூபிக்கப்படும் வரை இவற்றை breaking changes ஆகக் கருதுங்கள். changelog-ஐப் படியுங்கள், நேரத்தை ஒதுக்குங்கள் மற்றும் முழுமையாகச் சோதியுங்கள்.
  • Minor updates: இவை புதிய அம்சங்களைச் சேர்க்கின்றன. இவை நடத்தையில் (behavior) நுணுக்கமான மாற்றங்களையும் ஏற்படுத்தலாம். இவை எவ்வித பாதிப்பும் தராதவை என்று assumptions வைத்துக்கொள்ளாதீர்கள்.
  • Patch updates: இவை பிழைகளை (bugs) சரிசெய்கின்றன. இவை பொதுவாகப் பாதுகாப்பானவை, ஆனால் உங்கள் code அந்தப் பிழையைச் சார்ந்து இருந்தால், அல்லது அந்த patch நீங்கள் monkey-patching செய்த ஒரு உட்புறப் பகுதியை மாற்றினால், உங்கள் code உடைந்து போகலாம்.

விதிமுறைகளைத் தெரிந்து கொள்வது, எதையும் தொடங்குவதற்கு முன்பே அபாயங்களை வகைப்படுத்த உதவும்.

உங்கள் கருவிகளை ஒரு கைவினைஞரைப் போலப் பயன்படுத்துங்கள்

நீங்கள் Yarn பயன்படுத்தினால், அதன் பல built-in commands யூகங்களை ஒரு முறையான செயல்முறையாக மாற்றும்.

முதலில் yarn outdated-ஐ இயக்கவும். இது எவை விலகிச் சென்றுள்ளன (drift) என்பதன் ஒரு snapshot-ஐ உங்களுக்கு வழங்கும்.