ಫ್ರಂಟ್-ಎಂಡ್ ಎಂಟ್ರೋಪಿ (Front-end entropy) ನಿಜವಾದ ಸಂಗತಿ. ಒಂದು ಕೋಡ್ಬೇಸ್ ಒಂದೇ ರಾತ್ರಿಯಲ್ಲಿ ಕುಸಿಯುವುದಿಲ್ಲ. ಅದು ಕ್ರಮೇಣವೇ ಸಂಗ್ರಹವಾಗುತ್ತದೆ. ಒಂದು ಮಂಗಳವಾರ ನೀವು ಒಂದು ಡೇಟ್-ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಲೈಬ್ರರಿಯನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಆರು ತಿಂಗಳ ನಂತರ ಯಾರೋ ಒಬ್ಬರು ಮೊದಲನೆಯದನ್ನು ಹುಡುಕದ ಕಾರಣ ಮತ್ತೊಂದನ್ನು ಸೇರಿಸುತ್ತಾರೆ. ನೀವು ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸದ ಬ್ರೌಸರ್ಗಳಿಗಾಗಿ ಪಾಲಿಫಿಲ್ಗಳು (Polyfills) ರಾಶಿಬಿದ್ದಿರುತ್ತವೆ. ಬಿಲ್ಡ್ ಟೂಲ್ಗಳು ಒಂದರ ಮೇಲೊಂದು ಪದರಗಳಂತೆ ನಿರ್ಮಾಣವಾಗುತ್ತವೆ. ಅಂತಿಮವಾಗಿ, node_modules ಫೋಲ್ಡರ್ ಒಂದು ಡಿಜಿಟಲ್ ಕಸದ ಡ್ರಾಯರ್ನಂತೆ ಆಗುತ್ತದೆ, ಅಲ್ಲಿ ಭಯವಿಲ್ಲದೆ ಯಾವುದನ್ನೂ ಎಸೆದುಬಿಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ನೀವು ಅಪ್ಡೇಟ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ನಂತರ ನೋಡುವುದನ್ನೂ ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಆಗ ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ಬದಲಾವಣೆಯೂ ಒಂದು ಜೂಜಾಗಿ ಪರಿಣಮಿಸುತ್ತದೆ.
ಹಳೆಯ ಪ್ರಾಜೆಕ್ಟ್ನಲ್ಲಿ Material UI ಅನ್ನು ಅಪ್ಗ್ರೇಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವಾಗ ನಾನು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದೆ. ನಾನು package.json ಅನ್ನು ತೆರೆದಾಗ ಅದರಲ್ಲಿನ ಅರ್ಧದಷ್ಟು ಎಂಟ್ರಿಗಳನ್ನು ಗುರುತಿಸಲು ಕಷ್ಟವಾಯಿತು. ಡಜನ್ಗಟ್ಟಲೆ ಲೈಬ್ರರಿಗಳು ಅಲ್ಲಿಯೇ ಇದ್ದವು, ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆಯೇ ಹಳೆಯದಾಗಿದ್ದವು, ಇನ್ನು ಕೆಲವು ಎಷ್ಟು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದವು ಎಂದರೆ ಅವುಗಳನ್ನು ಯಾರು ಮತ್ತು ಏಕೆ ಸೇರಿಸಿದ್ದಾರೆ ಎಂದು ತಿಳಿಯಲು ನಾನು git blame ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಯಿತು. ನಾನು ಹೊಸ Material UI ಆವೃತ್ತಿಗಾಗಿ ಇನ್ಸ್ಟಾಲ್ ಕಮಾಂಡ್ ಚಲಾಯಿಸಿದಾಗ, ಟರ್ಮಿನಲ್ ಪೀರ್ ಡಿಪೆಂಡೆನ್ಸಿ (peer dependency) ಎಚ್ಚರಿಕೆಗಳಿಂದ ತುಂಬಿಹೋಯಿತು. ನಾನು ಅಪ್ಡೇಟ್ ಮಾಡಲು ಬಯಸಿದ ಪ್ಯಾಕೇಜ್ ಸರಿಯಾಗಿತ್ತು. ಆದರೆ ಅದರ ಸುತ್ತಲಿನ ಪರಿಸರ ವ್ಯವಸ್ಥೆ (ecosystem) ಸರಿಯಾಗಿರಲಿಲ್ಲ. ನಾನು ಕೇವಲ ಅಪ್ಗ್ರೇಡ್ ಮಾಡುತ್ತಿಲ್ಲ, ಬದಲಾಗಿ ಒಂದು ಅವಶೇಷವನ್ನು ಅಗೆಯುತ್ತಿದ್ದೇನೆ ಎಂದು ನನಗೆ ಅರಿವಾಯಿತು.
ಈ ಅವ್ಯವಸ್ಥೆಯು ಹೆಮ್ಮೆಯಿಗಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವನ್ನು ಏಕೆ ಉಂಟುಮಾಡುತ್ತದೆ
ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು ಕೇವಲ ಬಾಹ್ಯ ಸಮಸ್ಯೆಯಲ್ಲ. ಇದು ನೈಜವಾದ ಮತ್ತು ದುಬಾರಿ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಭದ್ರತಾ ಅಪಾಯಗಳು (Security risks) ಸ್ಪಷ್ಟವಾದ ಬೆದರಿಕೆಗಳಾಗಿವೆ. ಕೈಬಿಡಲಾದ ಪ್ಯಾಕೇಜ್ಗಳು ವಾರಕ್ಕೊಮ್ಮೆ ಸ್ಕ್ಯಾನರ್ಗಳು ಗುರುತಿಸುವಂತಹ ಬಹಿರಂಗಪಡಿಸಿದ ದೋಷಗಳನ್ನು (vulnerabilities) ಹೊಂದಿರುತ್ತವೆ. ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದೇನೆ, ನೀವು ನೇರವಾಗಿ ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿದ ಲೈಬ್ರರಿಗಳು ಸರಿಯಾಗಿರಬಹುದು, ಆದರೆ ಅವುಗಳು ತាញಿಸಿಕೊಂಡ ಟ್ರಾನ್ಸಿಟಿವ್ (transitive) ಲೈಬ್ರರಿಗಳು ಸರಿಯಾಗಿರಲಿಕ್ಕಿಲ್ಲ. ನೀವು ತಿಳಿಯದೆಯೇ ಬೇರೆಯವರ ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು (technical debt) ಹೊರುತ್ತೀರಿ.
ದೂರ ಹೆಚ್ಚಾದಂತೆ ವೆಚ್ಚವೂ ಹೆಚ್ಚಾಗುತ್ತದೆ. ನೀವು ಎಷ್ಟು ಹೆಚ್ಚು ಕಾಲ ಕಾಯುತ್ತೀರೋ, ಆವೃತ್ತಿಗಳ ನಡುವಿನ ಅಂತರ ಅಷ್ಟೇ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಒಂದು ಮೇಜರ್ React ಆವೃತ್ತಿಯನ್ನು ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದು ಒಂದು ಕೆಲಸವಾದರೆ, ಮೂರು ಆವೃತ್ತಿಗಳನ್ನು ಅಪ್ಗ್ರೇಡ್ ಮಾಡುವುದು ವಾರಗಟ್ಟಲೆ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಮೈಗ್ರೇಷನ್ ಪ್ರಾಜೆಕ್ಟ್ ಆಗುತ್ತದೆ. ನೀವು ಬಗ್ ಫಿಕ್ಸ್ಗಳು, ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆಗಳು ಮತ್ತು ಆಧುನಿಕ ಟೂಲ್ಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ತಂಡವು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಮಿತಿಗಳ ಸುತ್ತ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಲೈಬ್ರರಿಗಳು ಸಾಯುತ್ತವೆ. ಸಕ್ರಿಯ ನಿರ್ವಹಕರಿಲ್ಲದ ಪ್ಯಾಕೇಜ್ ಡಿಫಾಲ್ಟ್ ಆಗಿ ನಿಮ್ಮ ಸ್ವಂತ ಫೋರ್ಕ್ (fork) ಆಗುತ್ತದೆ. ಅದು ಕೆಲಸ ಮಾಡದಿದ್ದಾಗ, ಮಧ್ಯರಾತ್ರಿಯಲ್ಲಿ ಅದರ ಮಿನಿಫೈಡ್ ಸೋರ್ಸ್ ಕೋಡ್ ಅನ್ನು ಓದಬೇಕಾದ ಪರಿಸ್ಥಿತಿ ನಿಮ್ಮದಾಗುತ್ತದೆ. ಸಮುದಾಯವು ಉತ್ತಮ ಪರಿಹಾರಗಳತ್ತ ಸಾಗಿರುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ತಂಡವು ಒಂದು ಹಳೆಯ ನೆನಪನ್ನು (ghost) ನಿರ್ವಹಿಸುವಲ್ಲಿ ಸಿಲುಕಿಕೊಂಡಿರುತ್ತದೆ.
ವೇಗವು ಕುಸಿಯುತ್ತದೆ (Velocity craters). ಹೊಸ ಡೆವಲಪರ್ಗಳು ವೆಬ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ಗಳು ಅಥವಾ ಪ್ರಮುಖ ಪರ್ಯಾಯಗಳ ಮೂಲಕ ಬದಲಾಗಿರುವ ಹಳೆಯ ಟೂಲ್ಗಳ ವಿಶಿಷ್ಟ APIಗಳನ್ನು ಕಲಿಯಲು ತಮ್ಮ ಮೊದಲ ದಿನಗಳನ್ನು ವ್ಯಯಿಸುತ್ತಾರೆ. ಹೊಸ ಫೀಚರ್ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಬದಲು, ನಿಮ್ಮ ಹಿರಿಯ ಎಂಜಿನಿಯರ್ಗಳು ಇತಿಹಾಸಕಾರರಾಗಿ, ಈ ಪ್ರಾಜೆಕ್ಟ್ ಏಕೆ ಇಂದಿಗೂ 2015ರ ಟಾಸ್ಕ್ ರನ್ನರ್ ಅನ್ನು ಬಳಸುತ್ತಿದೆ ಎಂದು ವಿವರಿಸುತ್ತಿರುತ್ತಾರೆ.
ಒಂದೇ ಒಂದು ಆವೃತ್ತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು ಆಡಿಟ್ ಮಾಡಿ
ಎಲ್ಲವನ್ನೂ ಒಟ್ಟಿಗೆ ಅಪ್ಡೇಟ್ ಮಾಡಿ ಟೆಸ್ಟ್ಗಳು ಪಾಸಾಗುತ್ತವೆ ಎಂದು ಭಾವಿಸುವುದು ದೊಡ್ಡ ತಪ್ಪು. ಆಡಿಟ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. package.json ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಪ್ರತಿಯೊಂದು ಎಂಟ್ರಿಯನ್ನು ಕೂಲಂಕಷವಾಗಿ ಪರಿಶೀಲಿಸಿ.
ಈ ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ:
- ಇದು ಯಾವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ?
- ನಾವು ಇದನ್ನು ನಿಖರವಾಗಿ ಎಲ್ಲಿ ಬಳಸುತ್ತಿದ್ದೇವೆ?
- ಇದು ಇನ್ನೂ ಅಗತ್ಯವಿದೆಯೇ?
- ಈಗ ಇದಕ್ಕಿಂತ ಉತ್ತಮ ಪರ್ಯಾಯವಿದೆಯೇ?
ನೀವು ಅನಗತ್ಯತೆಗಳನ್ನು (redundancy) ಕಾಣುವಿರಿ. ಬಹುಶಃ ಇಬ್ಬರು ಡೆವಲಪರ್ಗಳು ಬೇರೆ ಬೇರೆ ಸಮಯದಲ್ಲಿ ಒಂದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದರಿಂದ moment ಮತ್ತು date-fns ಎರಡೂ ಪಟ್ಟಿಯಲ್ಲಿರಬಹುದು. ಅಥವಾ ನಿಮ್ಮ ಅನಾಲಿಟಿಕ್ಸ್ ಪ್ರಕಾರ ಹಳೆಯ ಬ್ರೌಸರ್ಗಳಿಂದ ಯಾವುದೇ ಟ್ರಾಫಿಕ್ ಇಲ್ಲದಿದ್ದರೂ, ಇಂಟರ್ನೆಟ್ ಎಕ್ಸ್ಪ್ಲೋರರ್ (Internet Explorer) ಗಾಗಿ ಬಳಸುವ ಪಾಲಿಫಿಲ್ ಇರಬಹುದು. ಆಧುನಿಕ ಬ್ರೌಸರ್ಗಳು fetch ನ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು ನೈಸರ್ಗಿಕವಾಗಿ ನಿರ್ವಹಿಸುವುದರಿಂದ, ಅದರ ಸುತ್ತಲಿನ ಕಸ್ಟಮ್ ವ್ಯಾಪರ್ ಅನ್ನು ನೀವು ತೆಗೆದುಹಾಕಬಹುದು.
ಕೆಲವೊಮ್ಮೆ ಅಪ್ಡೇಟ್ ಮಾಡುವ ಬದಲು ಬದಲಾಯಿಸುವುದು ಉತ್ತಮ. ಕೈಬಿಡಲಾದ ಚಾರ್ಟಿಂಗ್ ಲೈಬ್ರರಿಯನ್ನು ಮೂರು ವರ್ಷಗಳ ಬ್ರೇಕಿಂಗ್ ಚೇಂಜ್ಗಳ ಮೂಲಕ ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ, ಒಂದು ಸ್ಥಿರ ಪರ್ಯಾಯವನ್ನು ಬಳಸಿ ಕೆಲವು ಘಟಕಗಳನ್ನು (components) ಮರುನಿರ್ಮಿಸುವುದು ಸುಲಭ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ. ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ತೆಗೆದುಹಾಕಲು ಸಿದ್ಧರಿರಿ.
ಗುಪ್ತ ಪದರ: ಟ್ರಾನ್ಸಿಟಿವ್ ಡಿಪೆಂಡೆನ್ಸಿಗಳು ಮತ್ತು Semver
ಡೈರೆಕ್ಟ್ ಡಿಪೆಂಡೆನ್ಸಿಗಳು (Direct dependencies) ಐಸ್ಬರ್ಗ್ನ ಕೇವಲ ಕಾಣುವ ಭಾಗಗಳಷ್ಟೇ. ನಿಜವಾದ ಭಾರವು ಟ್ರಾನ್ಸಿಟಿವ್ ಡಿಪೆಂಡೆನ್ಸಿಗಳಲ್ಲಿ (transitive dependencies) ಅಡಗಿದೆ—ಅಂದರೆ ನಿಮ್ಮ ಪ್ಯಾಕೇಜ್ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಇತರ ಪ್ಯಾಕೇಜ್ಗಳು. ನೀವು ಅವುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿಲ್ಲ, ಆದರೆ ಅವು ನಿಮ್ಮ ಬಿಲ್ಡ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ನಿಮ್ಮ ಬಂಡಲ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ, ಅಟ್ಯಾಕ್ ಸರ್ಫೇಸ್ ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತವೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಗೊಂದಲಮಯ ಬಿಲ್ಡ್ ಎರ್ರರ್ಗಳನ್ನು ಉಂಟುಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಸಂಘರ್ಷಿಸುತ್ತವೆ.
ಸೆಮ್ಯಾಂಟಿಕ್ ವರ್ಷನಿಂಗ್ (semantic versioning) ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ಅದರ ನಿಜವಾದ ಅರ್ಥದಲ್ಲಿ ಓದಬೇಕೇ ಹೊರತು, ನೀವು ಏನನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತೀರೋ ಅದನ್ನು ಅಲ್ಲ.
- ಮೇಜರ್ ಅಪ್ಡೇಟ್ಗಳು (Major updates): ಇವು ಮೈಗ್ರೇಷನ್ಗಳು. ಇವುಗಳ ಬಗ್ಗೆ ಖಚಿತತೆ ಬರುವವರೆಗೆ ಇವುಗಳನ್ನು ಬ್ರೇಕಿಂಗ್ ಚೇಂಜ್ಗಳೆಂದು ಪರಿಗಣಿಸಿ. ಚೇಂಜ್ಲಾಗ್ (changelog) ಓದಿ, ಸಮಯವನ್ನು ಮೀಸಲಿಡಿ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ.
- ಮೈನರ್ ಅಪ್ಡೇಟ್ಗಳು (Minor updates): ಇವು ಹೊಸ ಫೀಚರ್ಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ. ಇವು ವರ್ತನೆಯಲ್ಲಿ ಸೂಕ್ಷ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ತರಬಹುದು. ಇವು ಯಾವುದೇ ತೊಂದರೆ ಉಂಟುಮಾಡುವುದಿಲ್ಲ ಎಂದು ಭಾವಿಸಬೇಡಿ.
- ಪ್ಯಾಚ್ ಅಪ್ಡೇಟ್ಗಳು (Patch updates): ಇವು ಬಗ್ಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತವೆ. ಇವು ಸಾಮಾನ್ಯವಾಗಿ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತವೆ, ಆದರೆ ನಿಮ್ಮ ಕೋಡ್ ಆ ಬಗ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ ಅಥವಾ ಪ್ಯಾಚ್ ನೀವು ಮಂಕಿ-ಪ್ಯಾಚ್ (monkey-patching) ಮಾಡುತ್ತಿದ್ದ ಯಾವುದನ್ನಾದರೂ ಬದಲಾಯಿಸಿದರೆ, ಸಮಸ್ಯೆ ಉಂಟಾಗಬಹುದು.
ನಿಯಮಗಳನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ನೀವು ಯಾವುದನ್ನೂ ಮುಟ್ಟುವ ಮೊದಲು ಅಪಾಯವನ್ನು ವರ್ಗೀಕರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ನಿಮ್ಮ ಪರಿಕರಗಳನ್ನು ಒಬ್ಬ ಕುಶಲಕರ್ಮಿಯಂತೆ ಬಳಸಿ
ನೀವು Yarn ಬಳಸುತ್ತಿದ್ದರೆ, ಅದರ ಕೆಲವು ಬಿಲ್ಟ್-ಇನ್ ಕಮಾಂಡ್ಗಳು ಊಹಾಪೋಹಗಳನ್ನು ಒಂದು ವ್ಯವಸ್ಥಿತ ಪ್ರಕ್ರಿಯೆಯನ್ನಾಗಿ ಮಾಡುತ್ತವೆ.
ಮೊದಲು yarn outdated ಅನ್ನು ರನ್ ಮಾಡಿ. ಇದು ಯಾವುದಾದರೂ ಬದಲಾವಣೆಗಳಿದ್ದರೆ ಅದರ ಸ್ನ್ಯಾಪ್ಶಾಟ್ ನೀಡುತ್ತದೆ