ഫ്രണ്ട്-എൻഡ് എൻട്രോപ്പി (Front-end entropy) എന്നത് യാഥാർത്ഥ്യമാണ്. ഒരു കോഡ്ബേസ് ഒറ്റരാത്രികൊണ്ട് തകർന്നടിയുന്നില്ല. അത് ക്രമേണ അടിഞ്ഞുകൂടുകയാണ് ചെയ്യുന്നത്. ഒരു ചൊവ്വാഴ്ച നിങ്ങൾ ഒരു ഡേറ്റ്-ഫോർമാറ്റിംഗ് ലൈബ്രറി ചേർക്കുന്നു. ആറ് മാസത്തിന് ശേഷം മറ്റൊരാൾ അത് കണ്ടെത്താത്തതുകൊണ്ട് വേറൊന്ന് കൂടി ചേർക്കുന്നു. നിങ്ങൾ ഇനി പിന്തുണയ്ക്കാത്ത ബ്രൗസറുകൾക്കായി പോളിഫില്ലുകൾ (Polyfills) കുന്നുകൂടുന്നു. ബിൽഡ് ടൂളുകൾ ഒന്നിനു മുകളിൽ ഒന്നായി അടുക്കിവെക്കപ്പെടുന്നു. ഒടുവിൽ, node_modules ഫോൾഡർ ഭയമില്ലാതെ ഒന്നും വലിച്ചെറിയാൻ കഴിയാത്ത ഒരു ഡിജിറ്റൽ ജങ്ക് ഡ്രോവർ (digital junk drawer) ആയി മാറുന്നു. നിങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുന്നത് നിർത്തുന്നു. പിന്നീട് നിങ്ങൾ അത് ശ്രദ്ധിക്കുന്നത് പോലും നിർത്തുന്നു. അപ്പോഴാണ് ഓരോ ചെറിയ മാറ്റവും ഒരു ചൂതാട്ടമായി മാറുന്നത്.
ഒരു പഴയ പ്രോജക്റ്റിൽ Material UI അപ്ഡേറ്റ് ചെയ്യാൻ ശ്രമിച്ചപ്പോൾ ഞാൻ ഈ പ്രതിസന്ധി നേരിട്ടു. ഞാൻ package.json തുറന്നു നോക്കിയപ്പോൾ അതിലെ പകുതിയോളം എൻട്രികൾ തിരിച്ചറിയാൻ പോലും കഴിഞ്ഞില്ല. ഡസൻ കണക്കിന് ലൈബ്രറികൾ അവിടെയുണ്ടായിരുന്നു, ചിലത് വർഷങ്ങളായി പഴയതാണ്, മറ്റു ചിലത് ആര് എന്തിനാണ് ചേർക്കപ്പെട്ടതെന്ന് അറിയാൻ എനിക്ക് git blame പരിശോധിക്കേണ്ടി വന്നു. പുതിയ Material UI വേർഷനായി ഞാൻ ഇൻസ്റ്റാൾ കമാൻഡ് നൽകിയപ്പോൾ ടെർമിനൽ മുഴുവൻ 'peer dependency' മുന്നറിയിപ്പുകൾ കൊണ്ട് നിറഞ്ഞു. എനിക്ക് അപ്ഡേറ്റ് ചെയ്യേണ്ട പാക്കേജ് ശരിയായിരുന്നു. എന്നാൽ അതിനു ചുറ്റുമുള്ള ഇക്കോസിസ്റ്റം (ecosystem) ശരിയല്ലായിരുന്നു. ഞാൻ ഒരു അപ്ഗ്രേഡ് ചെയ്യുകയല്ല, മറിച്ച് ഒരു അവശിഷ്ടം കുഴിച്ചെടുക്കുകയാണെന്ന് എനിക്ക് മനസ്സിലായി.
ഈ കുഴപ്പങ്ങൾ അഭിമാനത്തേക്കാൾ കൂടുതൽ ചിലവേറിയതാണ്
ഡിപ്പൻഡൻസികളെ (dependencies) അവഗണിക്കുന്നത് വെറുമൊരു കാഴ്ചപ്പാടിലെ പ്രശ്നമല്ല. അത് യഥാർത്ഥവും ചിലവേറിയതുമായ പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു.
സുരക്ഷാ ഭീഷണികൾ (Security risks) ആണ് ഏറ്റവും വ്യക്തമായ ഭീഷണി. ഉപേക്ഷിക്കപ്പെട്ട പാക്കേജുകളിൽ സ്കാനറുകൾ ആഴ്ചതോറും കണ്ടെത്തുന്ന സുരക്ഷാ പിഴവുകൾ ഉണ്ടാകാം. ഇതിലും മോശമായത്, നിങ്ങൾ നേരിട്ട് ഇൻസ്റ്റാൾ ചെയ്ത ലൈബ്രറികൾ ശരിയായിരിക്കാമെങ്കിലും അവ ഉൾക്കൊള്ളുന്ന ട്രാൻസിറ്റീവ് (transitive) ലൈബ്രറികൾ അല്ലാത്തതാകാം. നിങ്ങൾ അറിയാതെ തന്നെ മറ്റൊരാളുടെ ടെക്നിക്കൽ ഡെബ്റ്റ് (technical debt) ഏറ്റെടുക്കുന്നു.
ദൂരം കൂടുന്തോറും ചിലവും വർദ്ധിക്കുന്നു. നിങ്ങൾ എത്രത്തോളം വൈകുന്നുവോ, അത്രത്തോളം വേർഷനുകൾ തമ്മിലുള്ള വ്യത്യാസം കൂടിക്കൊണ്ടിരിക്കും. ഒരു പ്രധാന React വേർഷൻ മാറ്റുന്നത് ഒരു ജോലിയാണ്. എന്നാൽ മൂന്ന് വേർഷനുകൾ മാറ്റുന്നത് ആഴ്ചകൾ എടുക്കുന്ന ഒരു മൈഗ്രേഷൻ പ്രോജക്റ്റ് ആയി മാറും. ബഗ് ഫിക്സുകൾ, പെർഫോമൻസ് മെച്ചപ്പെടുത്തലുകൾ, ആധുനിക ടൂളുകളുമായുള്ള പൊരുത്തം എന്നിവ നിങ്ങൾക്ക് നഷ്ടപ്പെടുന്നു. നിലവിലില്ലാത്ത പരിമിതികൾക്ക് ചുറ്റും ടീം പണിയെടുക്കേണ്ടി വരുന്നു.
ലൈബ്രറികൾ ഇല്ലാതാകുന്നു. സജീവമായ മെയിന്റനർമാരില്ലാത്ത ഒരു പാക്കേജ് സ്വാഭാവികമായും നിങ്ങളുടെ സ്വന്തം ഫോർക്ക് (fork) ആയി മാറുന്നു. അത് തകരുമ്പോൾ, പാതിരാത്രിയിൽ അതിന്റെ മിനിഫൈഡ് (minified) സോഴ്സ് കോഡ് വായിക്കേണ്ടി വരുന്നത് നിങ്ങളായിരിക്കും. കമ്മ്യൂണിറ്റി മികച്ച പരിഹാരങ്ങളിലേക്ക് മാറിയിട്ടുണ്ടാകും, എന്നാൽ നിങ്ങളുടെ ടീം ഒരു പ്രേതത്തെ നിലനിർത്താൻ കഷ്ടപ്പെടുകയാണ്.
വേഗത കുറയുന്നു (Velocity craters). പുതിയ ഡെവലപ്പർമാർ അവരുടെ ആദ്യ ദിവസങ്ങൾ വെബ് സ്റ്റാൻഡേർഡുകൾക്കോ പ്രധാനപ്പെട്ട മറ്റ് ബദലങ്ങൾക്കോ വഴിമാറിക്കൊടുത്ത പഴയ ടൂളുകളുടെ സവിശേഷമായ API പഠിക്കാനായി ചിലവഴിക്കുന്നു. ഫീച്ചറുകൾ പുറത്തിറക്കുന്നതിന് പകരം, നിങ്ങളുടെ സീനിയർ എഞ്ചിനീയർമാർ 2015-ലെ ഒരു ടാസ്ക് റണ്ണർ എന്തുകൊണ്ട് ഇപ്പോഴും ഉപയോഗിക്കുന്നു എന്ന് വിശദീകരിക്കുന്ന ചരിത്രകാരന്മാരായി മാറുന്നു.
ഒരു വേർഷൻ പോലും മാറ്റുന്നതിന് മുമ്പ് ഓഡിറ്റ് ചെയ്യുക
എല്ലാ പാക്കേജുകളും ഒന്നിച്ച് അപ്ഡേറ്റ് ചെയ്യാനും ടെസ്റ്റുകൾ പാസാകുമെന്ന് പ്രതീക്ഷിക്കാനും ശ്രമിക്കുന്നതാണ് ഏറ്റവും വലിയ തെറ്റ്. ഒരു ഓഡിറ്റിലൂടെ തുടങ്ങുക. package.json എടുത്ത് ഓരോ എൻട്രിയെയും പരിശോധിക്കുക.
നാല് ചോദ്യങ്ങൾ ചോദിക്കുക:
- ഇത് ഏത് പ്രശ്നത്തിനാണ് പരിഹാരം കാണുന്നത്?
- നമ്മൾ ഇത് കൃത്യമായി എവിടെയാണ് ഉപയോഗിക്കുന്നത്?
- ഇത് ഇപ്പോഴും ആവശ്യമുണ്ടോ?
- ഇപ്പോൾ ഇതിനേക്കാൾ നല്ലൊരു ബദൽ ലഭ്യമാണോ?
നിങ്ങൾക്ക് അനാവശ്യമായവ കണ്ടെത്താൻ കഴിയും. രണ്ട് ഡെവലപ്പർമാർ വ്യത്യസ്ത സമയങ്ങളിൽ ഒരേ പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിച്ചതുകൊണ്ട് moment-ഉം date-fns-ഉം ഒരേ ലിസ്റ്റിൽ ഉണ്ടാകാം. നിങ്ങളുടെ അനലിറ്റിക്സ് പഴയ ബ്രൗസറുകളിൽ നിന്നുള്ള ട്രാഫിക് പൂജ്യമാണെന്ന് കാണിക്കുന്നുണ്ടെങ്കിലും ഇന്റർനെറ്റ് എക്സ്പ്ലോററിനായുള്ള ഒരു പോളിഫിൽ ഇപ്പോഴും ഉപയോഗിക്കുന്നുണ്ടാകാം. മോഡേൺ ബ്രൗസറുകൾ തന്നെ ഇത്തരം കാര്യങ്ങൾ കൈകാര്യം ചെയ്യുന്നതുകൊണ്ട് fetch-ന് ചുറ്റുമുള്ള ഒരു കസ്റ്റം റാപ്പർ (custom wrapper) ഒഴിവാക്കാവുന്നതാകാം.
ചിലപ്പോൾ അപ്ഡേറ്റ് ചെയ്യുന്നതിനേക്കാൾ നല്ലത് അത് മാറ്റിസ്ഥാപിക്കുന്നതാണ്. മൂന്ന് വർഷത്തെ മാറ്റങ്ങളിലൂടെ ഒരു പഴയ ചാർട്ടിംഗ് ലൈബ്രറിയെ മാറ്റാൻ ശ്രമിക്കുന്നതിനേക്കാൾ എളുപ്പമായിരിക്കും ഒരു പുതിയ ലൈബ്രറി ഉപയോഗിച്ച് കുറച്ച് കമ്പോണന്റുകൾ വീണ്ടും നിർമ്മിക്കുന്നത്. ഒഴിവാക്കാൻ തയ്യാറാവുക.
മറഞ്ഞിരിക്കുന്ന പാളി: ട്രാൻസിറ്റീവ് ഡിപ്പൻഡൻസികളും സെമാന്റിക് വേർഷനിംഗും (Semver)
ഡയറക്ട് ഡിപ്പൻഡൻസികൾ ഐസ്ബർഗിന്റെ കാണുന്ന ഭാഗം മാത്രമാണ്. യഥാർത്ഥ ഭാരം അതിന്റെ അടിയിലുള്ള ട്രാൻസിറ്റീവ് ഡിപ്പൻഡൻസികളിലാണ് (transitive dependencies) - അതായത് നിങ്ങളുടെ പാക്കേജുകൾക്ക് ആവശ്യമായ മറ്റ് പാക്കേജുകൾ. നിങ്ങൾ അവ തിരഞ്ഞെടുത്തിട്ടില്ലെങ്കിലും അവ നിങ്ങളുടെ ബിൽഡിൽ പ്രവർത്തിക്കുന്നുണ്ട്. അവ നിങ്ങളുടെ ബണ്ടിൽ സൈസ് കൂട്ടുകയും, സുരക്ഷാ ഭീഷണി വർദ്ധിപ്പിക്കുകയും, ചിലപ്പോൾ അവ തമ്മിൽ പൊരുത്തക്കേടുകൾ ഉണ്ടാക്കി വിചിത്രമായ ബിൽഡ് എററുകൾക്ക് കാരണമാവുകയും ചെയ്യുന്നു.
സെമാന്റിക് വേർഷനിംഗ് (semantic versioning) എന്നത് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നത് പോലെയല്ല, മറിച്ച് അത് യഥാർത്ഥത്തിൽ എന്താണോ അതാണ് നിങ്ങൾ മനസ്സിലാക്കേണ്ടത്.
- മേജർ അപ്ഡേറ്റുകൾ (Major updates): ഇവ മൈഗ്രേഷനുകളാണ്. മറ്റൊന്ന് തെളിയുന്നത് വരെ ഇവ ബ്രേക്കിംഗ് ചേഞ്ചുകളായി (breaking changes) പരിഗണിക്കുക. ചേഞ്ച്ലോഗ് (changelog) വായിക്കുക, സമയം കണ്ടെത്തുക, കൃത്യമായി ടെസ്റ്റ് ചെയ്യുക.
- മൈനർ അപ്ഡേറ്റുകൾ (Minor updates): ഇവ പുതിയ ഫീച്ചറുകൾ ചേർക്കുന്നു. ഇവ പെരുമാറ്റത്തിൽ ചെറിയ മാറ്റങ്ങൾ വരുത്തിയേക്കാം. ഇവ തികച്ചും സുരക്ഷിതമാണെന്ന് കരുതരുത്.
- പാച്ച് അപ്ഡേറ്റുകൾ (Patch updates): ഇവ ബഗുകൾ പരിഹരിക്കുന്നു. ഇവ സാധാരണയായി സുരക്ഷിതമാണ്, എന്നാൽ നിങ്ങളുടെ കോഡ് ആ ബഗിനെ ആശ്രയിച്ചാണെങ്കിൽ അല്ലെങ്കിൽ ആ പാച്ച് നിങ്ങൾ മാറ്റം വരുത്തിയ ഒരു ഇന്റേണൽ ഭാഗത്തെ ബാധിക്കുന്നുണ്ടെങ്കിൽ പ്രശ്നങ്ങൾ ഉണ്ടായേക്കാം.
നിയമങ്ങൾ അറിയുന്നത് എന്തെങ്കിലും മാറ്റം വരുത്തുന്നതിന് മുമ്പ് റിസ്ക് തിരിച്ചറിയാൻ നിങ്ങളെ സഹായിക്കും.
ഒരു കരകൗശല വിദഗ്ദ്ധനെപ്പോലെ നിങ്ങളുടെ ടൂളുകൾ ഉപയോഗിക്കുക
നിങ്ങൾ Yarn ആണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, അതിലെ ചില ഇൻ-ബിൽറ്റ് കമാൻഡുകൾ ഊഹങ്ങൾ ഒഴിവാക്കി കാര്യങ്ങൾ കൃത്യമായി ചെയ്യാൻ സഹായിക്കും.
ആദ്യം yarn outdated റൺ ചെയ്യുക. അത് നിലവിലുള്ളവയിൽ എത്രത്തോളം മാറ്റം വന്നിരിക്കുന്നു എന്നതിന്റെ ഒരു ചിത്രം നൽകുന്നു...
