ફ્રન્ટ-એન્ડ એન્ટ્રોપી (entropy) વાસ્તવિક છે. કોડબેઝ રાતોરાત તૂટી પડતો નથી. તે એકઠા થતો જાય છે. કોઈ મંગળવારે તમે ડેટ-ફોર્મેટિંગ લાઈબ્રેરી ઉમેરો છો. છ મહિના પછી કોઈ બીજી ઉમેરે છે કારણ કે તેમને પહેલી મળી નથી. તમે હવે સપોર્ટ ન કરતા હો તેવા બ્રાઉઝર્સ માટે પોલીફિલ્સ (polyfills) જમા થવા લાગે છે. બિલ્ડ ટૂલ્સ એકબીજા પર સ્તર બનાવતા જાય છે. અંતે, node_modules ફોલ્ડર એક ડિજિટલ કચરાના ડબ્બા જેવું બની જાય છે જ્યાં ડર વગર કંઈપણ ફેંકી શકાતું નથી. તમે અપડેટ કરવાનું બંધ કરો છો. પછી તમે જોવાનું પણ બંધ કરી દો છો. ત્યારે દરેક નાનો ફેરફાર એક જુગાર બની જાય છે.

એક જૂના પ્રોજેક્ટમાં Material UI અપડેટ કરવાનો પ્રયાસ કરતી વખતે હું આ મુશ્કેલીનો સામનો કરી રહ્યો હતો. મેં package.json ખોલ્યું અને અડધા એન્ટ્રીઓ તો ઓળખી પણ ન શક્યો. ડઝનબંધ લાઈબ્રેરીઓ ત્યાં પડી હતી, કેટલીક વર્ષો જૂની હતી, તો કેટલીક એટલી અસ્પષ્ટ હતી કે કોણે અને શા માટે ઉમેરી તે જાણવા માટે મારે git blame તપાસવું પડ્યું. મેં Material UI ના નવા વર્ઝન માટે ઇન્સ્ટોલ કમાન્ડ ચલાવ્યો અને ટર્મિનલ 'peer dependency' ચેતવણીઓથી ભરાઈ ગયું. જે પેકેજ હું અપડેટ કરવા માંગતો હતો તે બરાબર હતું. પરંતુ તેની આસપાસનું ઇકોસિસ્ટમ (ecosystem) યોગ્ય નહોતું. મને સમજાયું કે હું અપગ્રેડ નથી કરી રહ્યો, પણ હું તો એક ખંડેરનું ખોદકામ કરી રહ્યો છું.

શા માટે આ અવ્યવસ્થા ગૌરવ કરતાં વધુ મોંઘી પડે છે

ડિપેન્ડન્સીઝ (dependencies) ને અવગણવી એ માત્ર દેખાવની સમસ્યા નથી. તે વાસ્તવિક અને ખર્ચાળ સમસ્યાઓ ઊભી કરે છે.

સુરક્ષા જોખમો (Security risks) એ સ્પષ્ટ જોખમ છે. ત્યજી દેવાયેલા પેકેજમાં એવી નબળાઈઓ (vulnerabilities) હોય છે જેને સ્કેનર્સ દર અઠવાડિયે ફ્લેગ કરે છે. વધુ ખરાબ બાબત એ છે કે તમે સીધી રીતે ઇન્સ્ટોલ કરેલી લાઈબ્રેરીઓ કદાચ બરાબર હોય, પરંતુ તે સાથે જે ટ્રાન્ઝિટિવ (transitive) લાઈબ્રેરીઓ આવી છે તે નકામી હોઈ શકે છે. તમે જાણ્યા વગર બીજાનું ટેકનિકલ ડેબ્ટ (technical debt) વારસામાં મેળવી લો છો.

સમય જતાં ખર્ચ વધતો જાય છે. તમે જેટલું મોડું કરશો, વર્ઝન વચ્ચેનો તફાવત એટલો જ વધતો જશે. React ના એક મેજર વર્ઝનનો જમ્પ એ કામ છે. પરંતુ ત્રણ વર્ઝનનો જમ્પ એ માઈગ્રેશન પ્રોજેક્ટ છે જે અઠવાડિયાઓ ખાઈ શકે છે. તમે બગ ફિક્સ, પરફોર્મન્સ સુધારા અને આધુનિક ટૂલ્સ સાથેની સુસંગતતા ગુમાવી દો છો. ટીમ અંતે એવી મર્યાદાઓ વચ્ચે કામ કરવા મજબૂર બને છે જે હવે અસ્તિત્વમાં જ નથી.

લાઈબ્રેરીઓ મૃત્યુ પામે છે. જે પેકેજમાં કોઈ સક્રિય મેન્ટેનર નથી, તે ડિફોલ્ટ રીતે તમારું પોતાનું પ્રાઇવેટ ફોર્ક (fork) બની જાય છે. જ્યારે તે બગડે છે, ત્યારે મધ્યરાત્રિએ તેનો મિનિફાઇડ (minified) સોર્સ કોડ વાંચવાનું કામ તમારે જ કરવાનું હોય છે. કોમ્યુનિટી વધુ સારા સોલ્યુશન્સ પર આગળ વધી ગઈ હોય છે, અને તમારી ટીમ એક ભૂત (ghost) ને જાળવી રાખવામાં અટવાયેલી રહે છે.

કામ કરવાની ગતિ (Velocity) ઘટી જાય છે. નવા ડેવલપર્સ તેમના શરૂઆતના દિવસો એવા ટૂલ્સના અજીબ APIs શીખવામાં વિતાવે છે જે હવે વેબ સ્ટાન્ડર્ડ્સ અથવા મુખ્ય વિકલ્પો દ્વારા બદલાઈ ગયા છે. ફીચર્સ રિલીઝ કરવાને બદલે, તમારા સિનિયર એન્જિનિયર્સ ઇતિહાસકારો બની જાય છે, જેઓ સમજાવતા રહે છે કે આ પ્રોજેક્ટ હજુ પણ 2015 ના ટાસ્ક રનરનો ઉપયોગ કેમ કરે છે.

એક પણ વર્ઝનને અડતા પહેલા ઓડિટ કરો

સૌથી મોટી ભૂલ એ છે કે બધું જ એકસાથે અપડેટ કરી દેવું અને ટેસ્ટ પાસ થાય તેવી આશા રાખવી. ઓડિટથી શરૂઆત કરો. package.json લો અને દરેક એન્ટ્રીની તપાસ કરો.

ચાર પ્રશ્નો પૂછો:

  • આ કઈ સમસ્યાનો ઉકેલ લાવે છે?
  • આપણે તેનો ચોક્કસ ક્યાં ઉપયોગ કરીએ છીએ?
  • શું તે હજુ પણ જરૂરી છે?
  • શું અત્યારે કોઈ વધુ સારો વિકલ્પ ઉપલબ્ધ છે?

તમને વધારાની (redundancy) વસ્તુઓ મળશે. કદાચ moment અને date-fns બંને લિસ્ટમાં હોય કારણ કે બે ડેવલપર્સે અલગ-અલગ સમયે એક જ સમસ્યાનો ઉકેલ લાવવાનો પ્રયાસ કર્યો હોય. કદાચ Internet Explorer માટેનો પોલીફિલ હજુ પણ સામેલ હોય, ભલે તમારા એનાલિટિક્સ બતાવે કે લેગસી બ્રાઉઝર્સમાંથી શૂન્ય ટ્રાફિક આવે છે. કદાચ fetch ની આસપાસનું કસ્ટમ રેપર ડિલીટ કરી શકાય કારણ કે આધુનિક બ્રાઉઝર્સ એ બાબતોને નેટિવલી (natively) હેન્ડલ કરે છે.

ક્યારેક અપડેટ કરવા કરતાં બદલી નાખવું વધુ સારું છે. ત્રણ વર્ષના બ્રેકિંગ ચેન્જીસ (breaking changes) સાથે એક ત્યજી દેવાયેલી ચાર્ટિંગ લાઈબ્રેરી સાથે ઝઘડવામાં એટલો સમય જઈ શકે છે જેટલો એક સ્થિર વિકલ્પ અપનાવવામાં અને થોડા કમ્પોનન્ટ્સ ફરીથી બનાવવામાં લાગે. કંઈક ઘટાડવા માટે તૈયાર રહો.

છુપાયેલું સ્તર: ટ્રાન્ઝ