ನಮಸ್ಕಾರ ಗೆಳೆಯರೆ. ಕೋರ್ಸ್‌ನ ಪ್ರಾರಂಭದ ನಿರೀಕ್ಷೆಯಲ್ಲಿ , ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ನಿಮ್ಮೊಂದಿಗೆ ಉಪಯುಕ್ತ ವಸ್ತುಗಳ ಅನುವಾದವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ.
ಸಾಫ್ಟ್‌ವೇರ್ ಹೆಚ್ಚು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿರುವಾಗ ಹೆಚ್ಚು ಹೆಚ್ಚು ದೈನಂದಿನ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಮಾರ್ಕ್ ಆಂಡ್ರೆಸೆನ್ ಒಮ್ಮೆ ಹೇಳಿದಂತೆ, ಅದು ಜಗತ್ತನ್ನು ಸೇವಿಸುತ್ತದೆ.
ಪರಿಣಾಮವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ವಿತರಿಸುವ ವಿಧಾನವು ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ನಾಟಕೀಯವಾಗಿ ಬದಲಾಗಿದೆ. ಇವು ಟೆಕ್ಟೋನಿಕ್ ಸ್ಕೇಲ್‌ನ ಪಲ್ಲಟಗಳಾಗಿದ್ದು, ಇದು ತತ್ವಗಳ ಗುಂಪಿಗೆ ಕಾರಣವಾಯಿತು. ಈ ತತ್ವಗಳು ತಂಡದ ನಿರ್ಮಾಣ, ವಿನ್ಯಾಸ, ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತಲುಪಿಸುವಲ್ಲಿ ಸಹಾಯಕವಾಗಿವೆ ಎಂದು ಸಾಬೀತಾಗಿದೆ.
ತತ್ವಗಳನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಸಂಕ್ಷೇಪಿಸಬಹುದು: ಅಪ್ಲಿಕೇಶನ್ ಚಿಕ್ಕದಾಗಿರಬೇಕು, ವೆಬ್ ಆಧಾರಿತವಾಗಿರಬೇಕು ಮತ್ತು ಡೆವಲಪರ್-ಕೇಂದ್ರಿತ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಹೊಂದಿರಬೇಕು. ಈ ಮೂರು ತತ್ವಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ನೀವು ದೃಢವಾದ, ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಚಿಸಬಹುದು ಅದು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ತ್ವರಿತವಾಗಿ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ತಲುಪಿಸಬಹುದು ಮತ್ತು ಸುಲಭವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ವಿಸ್ತರಿಸಬಹುದಾಗಿದೆ.
ಪ್ರತಿಯೊಂದು ಪ್ರಸ್ತಾವಿತ ತತ್ವಗಳು ಹಲವಾರು ಅಂಶಗಳನ್ನು ಹೊಂದಿದ್ದು, ಪ್ರತಿಯೊಂದು ತತ್ವವು ಅಂತಿಮ ಗುರಿಗೆ ಹೇಗೆ ಕೊಡುಗೆ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ, ಇದು ವಿಶ್ವಾಸಾರ್ಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ತ್ವರಿತ ವಿತರಣೆಯಾಗಿದ್ದು ಅದು ನಿರ್ವಹಿಸಲು ಮತ್ತು ಬಳಸಲು ಸುಲಭವಾಗಿದೆ. ಇದರ ಅರ್ಥವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವ ಸಲುವಾಗಿ ನಾವು ಅವುಗಳ ವಿರೋಧಾಭಾಸಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ತತ್ವಗಳನ್ನು ನೋಡುತ್ತೇವೆ, "ನೀವು ಬಳಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ಸಣ್ಣತನದ ತತ್ವ».
ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಸ್ತಾವಿತ ತತ್ವಗಳನ್ನು ಬಳಸಲು ಈ ಲೇಖನವು ನಿಮ್ಮನ್ನು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ, ಇದು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟ್ಯಾಕ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ವಿನ್ಯಾಸಕ್ಕೆ ಏಕೀಕೃತ ವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಈ ತತ್ವಗಳನ್ನು ಅನ್ವಯಿಸುವ ಮೂಲಕ, ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿನ ಇತ್ತೀಚಿನ ಪ್ರವೃತ್ತಿಗಳ ಲಾಭವನ್ನು ನೀವು ಪಡೆಯುತ್ತೀರಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ವಿತರಣೆಗೆ, ಧಾರಕಗಳ ಬಳಕೆ (ಉದಾಹರಣೆಗೆ, ) ಮತ್ತು ಕಂಟೈನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಚೌಕಟ್ಟುಗಳು (ಉದಾಹರಣೆಗೆ, ), ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಬಳಕೆ (ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸೇರಿದಂತೆ и ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ.
ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಎಂದರೇನು?
ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ಗಳು? ಆಧುನಿಕ ಸ್ಟಾಕ್? "ಆಧುನಿಕ" ಎಂದರೆ ನಿಖರವಾಗಿ ಏನು?
ಹೆಚ್ಚಿನ ಅಭಿವರ್ಧಕರು ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸಾಮಾನ್ಯ ಕಲ್ಪನೆಯನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಈ ಪರಿಕಲ್ಪನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುವುದು ಅವಶ್ಯಕ.
ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಬಹು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಅದು ರಿಯಾಕ್ಟ್ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಲೈಬ್ರರಿ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಆಗಿರಲಿ, Android ಅಥವಾ iOS ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿರಲಿ ಅಥವಾ ಇನ್ನೊಂದು API ಗೆ ಸಂಪರ್ಕಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿರಲಿ. ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾ ಅಥವಾ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವ ಅನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ವಿನಂತಿಸಿದ ಡೇಟಾ ಮತ್ತು ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. API ಬದಲಾಗದ ಮತ್ತು ಸ್ಥಿರವಾಗಿರಬೇಕು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್‌ನಿಂದ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಗಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಬರೆಯಬಾರದು. API HTTP(S) ಮೂಲಕ ಲಭ್ಯವಿದೆ ಮತ್ತು GUI ಅಥವಾ CLI ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಡೇಟಾವು ಸಾಮಾನ್ಯವಾಗಿ ಅಂಗೀಕರಿಸಲ್ಪಟ್ಟ, JSON ನಂತಹ ಇಂಟರ್‌ಆಪರೇಬಲ್ ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರಬೇಕು. RESTful API ಅಥವಾ GraphQL ನಂತಹ ಶುದ್ಧ, ಸಂಘಟಿತ ರೀತಿಯಲ್ಲಿ ವಸ್ತುಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು API ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಯೋಗ್ಯವಾದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಆಧುನಿಕ ಸ್ಟಾಕ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಆಧುನಿಕ ಸ್ಟಾಕ್ ಕ್ರಮವಾಗಿ ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಸ್ಟಾಕ್ ಆಗಿದೆ. ಈ ಸ್ಟ್ಯಾಕ್ ಡೆವಲಪರ್‌ಗೆ HTTP ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸುಲಭವಾಗಿ ರಚಿಸಲು ಮತ್ತು API ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ತೆರವುಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆಯ್ಕೆಮಾಡಿದ ವಿಧಾನವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು JSON ಸ್ವರೂಪದಲ್ಲಿ ಸುಲಭವಾಗಿ ಸ್ವೀಕರಿಸಲು ಮತ್ತು ಕಳುಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಆಧುನಿಕ ಸ್ಟಾಕ್ ಹನ್ನೆರಡು ಅಂಶಗಳ ಅಪ್ಲಿಕೇಶನ್‌ನ ಅಂಶಗಳಿಗೆ ಅನುರೂಪವಾಗಿದೆ .
ಈ ರೀತಿಯ ಸ್ಟಾಕ್‌ನ ಜನಪ್ರಿಯ ಆವೃತ್ತಿಗಳು ಆಧರಿಸಿವೆ , , , , и . ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಉಲ್ಲೇಖಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಭಾಷೆಯಲ್ಲಿ ಅಳವಡಿಸಲಾದ ಆಧುನಿಕ ಸ್ಟಾಕ್‌ನ ಉದಾಹರಣೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ನಾವು ಪ್ರತ್ಯೇಕವಾಗಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ವಿಧಾನವನ್ನು ಪ್ರತಿಪಾದಿಸುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ನಿಮ್ಮಲ್ಲಿ ಹಲವರು ವಿಕಸನಗೊಳ್ಳಬೇಕಾದ ಏಕಶಿಲೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ, ಆದರೆ ಇತರರು SOA ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿದ್ದಾರೆ ಅದು ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾಗಿ ವಿಸ್ತರಿಸುತ್ತಿದೆ ಮತ್ತು ವಿಕಸನಗೊಳ್ಳುತ್ತಿದೆ. ಇನ್ನೂ ಕೆಲವರು ಸರ್ವರ್‌ಲೆಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳತ್ತ ಸಾಗುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಕೆಲವರು ಮೇಲಿನ ಸಂಯೋಜನೆಗಳನ್ನು ಅಳವಡಿಸುತ್ತಿದ್ದಾರೆ. ಲೇಖನದಲ್ಲಿ ವಿವರಿಸಿರುವ ತತ್ವಗಳು ಈ ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಕೆಲವೇ ಸಣ್ಣ ಮಾರ್ಪಾಡುಗಳೊಂದಿಗೆ ಅನ್ವಯಿಸುತ್ತವೆ.
ತತ್ವಗಳು
ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಆಧುನಿಕ ಸ್ಟಾಕ್ ಎಂದರೇನು ಎಂಬುದರ ಕುರಿತು ನಾವು ಈಗ ಸಾಮಾನ್ಯ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು, ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಉತ್ತಮವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸುವ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತತ್ವಗಳಿಗೆ ಧುಮುಕುವ ಸಮಯ ಬಂದಿದೆ.
ತತ್ವಗಳಲ್ಲಿ ಒಂದು "ಸಣ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮಾಡಿ" ಎಂದು ಧ್ವನಿಸುತ್ತದೆ, ಅದನ್ನು ಕರೆಯೋಣ ಸಣ್ಣತನದ ತತ್ವ. ಅನೇಕ ಚಲಿಸುವ ಭಾಗಗಳಿಂದ ಮಾಡಲ್ಪಟ್ಟಿರುವ ನಂಬಲಾಗದಷ್ಟು ಸಂಕೀರ್ಣವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿವೆ. ಪ್ರತಿಯಾಗಿ, ಸಣ್ಣ, ಪ್ರತ್ಯೇಕ ಘಟಕಗಳಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಒಟ್ಟಾರೆಯಾಗಿ ವಿನ್ಯಾಸ, ನಿರ್ವಹಣೆ ಮತ್ತು ಕೆಲಸ ಮಾಡಲು ಸುಲಭವಾಗುತ್ತದೆ. (ನಾವು ಹೇಳಿದ್ದು "ಸರಳಗೊಳಿಸುತ್ತದೆ" ಅಲ್ಲ "ಸರಳವಾಗಿಸುತ್ತದೆ" ಎಂದು ಗಮನಿಸಿ).
ಎರಡನೆಯ ತತ್ವವೆಂದರೆ, ಡೆವಲಪರ್‌ಗಳ ಉತ್ಪಾದಕತೆಯನ್ನು ಅವರು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಸಹಾಯ ಮಾಡುವ ಮೂಲಕ ನಾವು ಅವುಗಳನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಮತ್ತು ಅನುಷ್ಠಾನದ ಸಮಯದಲ್ಲಿ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು CI/CD ಕಾಳಜಿಗಳಿಂದ ಅವರನ್ನು ಮುಕ್ತಗೊಳಿಸಬಹುದು. ಆದ್ದರಿಂದ, ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ನಮ್ಮ ವಿಧಾನ ಡೆವಲಪರ್‌ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದೆ.
ಅಂತಿಮವಾಗಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಎಲ್ಲವನ್ನೂ ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕಿಸಬೇಕು. ಕಳೆದ 20 ವರ್ಷಗಳಲ್ಲಿ, ನೆಟ್‌ವರ್ಕ್‌ಗಳು ವೇಗವಾಗಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿರುವುದರಿಂದ ನಾವು ನೆಟ್ವರ್ಕ್ ಭವಿಷ್ಯದತ್ತ ಉತ್ತಮ ದಾಪುಗಾಲುಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ. ನಾವು ಈಗಾಗಲೇ ನೋಡಿದಂತೆ, ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹಲವಾರು ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಬಳಸಬೇಕು. ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ನೆಟ್ವರ್ಕ್ ಥಿಂಕಿಂಗ್ ಅನ್ನು ಅನ್ವಯಿಸುವುದು ಗಮನಾರ್ಹ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ ಸಣ್ಣತನದ ತತ್ವ ಮತ್ತು ವಿಧಾನದ ಪರಿಕಲ್ಪನೆ, ಡೆವಲಪರ್ ಆಧಾರಿತ.
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ನೀವು ಈ ತತ್ವಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡರೆ, ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ವಿತರಣೆಯಲ್ಲಿ ನೀವು ನಿರಾಕರಿಸಲಾಗದ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.
ಈ ಮೂರು ತತ್ವಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡೋಣ.
ಸಣ್ಣತನದ ತತ್ವ
ಮಾನವನ ಮೆದುಳಿಗೆ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮಾಹಿತಿಯನ್ನು ಗ್ರಹಿಸುವುದು ಕಷ್ಟ. ಮನೋವಿಜ್ಞಾನದಲ್ಲಿ, ಅರಿವಿನ ಹೊರೆ ಎಂಬ ಪದವು ಮೆಮೊರಿಯಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಅಗತ್ಯವಿರುವ ಒಟ್ಟು ಮಾನಸಿಕ ಪ್ರಯತ್ನವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳ ಮೇಲೆ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಆದ್ಯತೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರಸ್ತುತ ಸಂಕೀರ್ಣ ಮಾದರಿಯನ್ನು ಮತ್ತು ಅವರ ತಲೆಯಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳುವ ಬದಲು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವತ್ತ ಗಮನಹರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಕೆಳಗಿನ ಕಾರಣಗಳಿಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಕೊಳೆಯುತ್ತವೆ:
- ಅಭಿವರ್ಧಕರ ಮೇಲೆ ಅರಿವಿನ ಹೊರೆ ಕಡಿಮೆಯಾಗಿದೆ;
- ಪರೀಕ್ಷೆಯ ವೇಗವರ್ಧನೆ ಮತ್ತು ಸರಳೀಕರಣ;
- ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಬದಲಾವಣೆಗಳ ತ್ವರಿತ ವಿತರಣೆ.
ಅಭಿವರ್ಧಕರ ಮೇಲೆ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಹಲವಾರು ಮಾರ್ಗಗಳಿವೆ, ಮತ್ತು ಇಲ್ಲಿಯೇ ಸಣ್ಣತನದ ತತ್ವವು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ.
ಆದ್ದರಿಂದ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಇಲ್ಲಿ ಮೂರು ಮಾರ್ಗಗಳಿವೆ:
- ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅವರು ಪರಿಗಣಿಸಬೇಕಾದ ಸಮಯದ ಚೌಕಟ್ಟನ್ನು ಕಡಿಮೆ ಮಾಡಿ - ಸಮಯದ ಚೌಕಟ್ಟು ಕಡಿಮೆ, ಅರಿವಿನ ಹೊರೆ ಕಡಿಮೆ.
- ಒಂದು-ಬಾರಿ ಕೆಲಸವನ್ನು ಕೈಗೊಳ್ಳುವ ಕೋಡ್ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಿ - ಕಡಿಮೆ ಕೋಡ್ - ಕಡಿಮೆ ಲೋಡ್.
- ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೆಚ್ಚುತ್ತಿರುವ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸಿ.
ಅಭಿವೃದ್ಧಿ ಸಮಯದ ಚೌಕಟ್ಟನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು
ವಿಧಾನಶಾಸ್ತ್ರದ ದಿನಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ waterfall ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗೆ ಮಾನದಂಡವಾಗಿತ್ತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಅಥವಾ ನವೀಕರಿಸಲು ಆರು ತಿಂಗಳಿಂದ ಎರಡು ವರ್ಷಗಳ ಕಾಲಾವಧಿಯು ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸವಾಗಿತ್ತು. ವಿಶಿಷ್ಟವಾಗಿ, ಎಂಜಿನಿಯರ್‌ಗಳು ಮೊದಲು ಉತ್ಪನ್ನದ ಅಗತ್ಯತೆಗಳು (PRD), ಸಿಸ್ಟಮ್ ರೆಫರೆನ್ಸ್ ಡಾಕ್ಯುಮೆಂಟ್ (SRD), ಆರ್ಕಿಟೆಕ್ಚರ್ ಬ್ಲೂಪ್ರಿಂಟ್‌ನಂತಹ ಸಂಬಂಧಿತ ದಾಖಲೆಗಳನ್ನು ಓದುತ್ತಾರೆ ಮತ್ತು ಈ ಎಲ್ಲಾ ವಿಷಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ಒಂದು ಅರಿವಿನ ಮಾದರಿಯಲ್ಲಿ ಸಂಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ, ಅದರ ಪ್ರಕಾರ ಅವರು ಕೋಡ್ ಮಾಡುತ್ತಾರೆ. ಅಗತ್ಯತೆಗಳು ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ವಾಸ್ತುಶಿಲ್ಪವು ಬದಲಾದಂತೆ, ಅರಿವಿನ ಮಾದರಿಯ ನವೀಕರಣಗಳ ಬಗ್ಗೆ ಸಂಪೂರ್ಣ ತಂಡಕ್ಕೆ ತಿಳಿಸಲು ಗಂಭೀರವಾದ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು. ಅಂತಹ ವಿಧಾನವು ಕೆಟ್ಟದಾಗಿ, ಕೆಲಸವನ್ನು ಸರಳವಾಗಿ ಪಾರ್ಶ್ವವಾಯುವಿಗೆ ತರಬಹುದು.
ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ದೊಡ್ಡ ಬದಲಾವಣೆಯು ಚುರುಕುಬುದ್ಧಿಯ ವಿಧಾನದ ಪರಿಚಯವಾಗಿದೆ. ವಿಧಾನದ ಮುಖ್ಯ ಲಕ್ಷಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ agile ಪುನರಾವರ್ತಿತ ಬೆಳವಣಿಗೆಯಾಗಿದೆ. ಪ್ರತಿಯಾಗಿ, ಇದು ಇಂಜಿನಿಯರ್‌ಗಳ ಮೇಲಿನ ಅರಿವಿನ ಹೊರೆಯಲ್ಲಿ ಇಳಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಒಂದು ದೀರ್ಘ ಚಕ್ರದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಭಿವೃದ್ಧಿ ತಂಡಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಬದಲು, agile ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ತ್ವರಿತವಾಗಿ ಪರೀಕ್ಷಿಸಬಹುದಾದ ಮತ್ತು ನಿಯೋಜಿಸಬಹುದಾದ ಸಣ್ಣ ಪ್ರಮಾಣದ ಕೋಡ್‌ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ವಿಧಾನವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಆರು ತಿಂಗಳಿಂದ ಎರಡು ವರ್ಷಗಳ ಕಾಲಾವಧಿಗೆ ಬದಲಾಯಿಸಲಾಗಿದೆ ಮತ್ತು ಎರಡು ವಾರಗಳ ಆಡ್ ಅಥವಾ ವೈಶಿಷ್ಟ್ಯದ ಬದಲಾವಣೆಗಾಗಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಸ್ಪೆಕ್ಸ್‌ನೊಂದಿಗೆ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೆಚ್ಚು ಮಸುಕಾದ ತಿಳುವಳಿಕೆಯನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದೆ.
ಎರಡು ವಾರಗಳ ಸ್ಪ್ರಿಂಟ್‌ನಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಬಹುದಾದ ಬೃಹತ್ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ನಿರ್ದಿಷ್ಟ ಸಣ್ಣ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಗಮನವನ್ನು ಬದಲಾಯಿಸುವುದು, ಮುಂದಿನ ಸ್ಪ್ರಿಂಟ್‌ನ ಮುಂದೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಗಮನಾರ್ಹ ಬದಲಾವಣೆಯಾಗಿದೆ. ಅರಿವಿನ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವಾಗ ಅಭಿವೃದ್ಧಿ ಉತ್ಪಾದಕತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಇದು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು, ಅದು ನಿರಂತರವಾಗಿ ಏರಿಳಿತಗೊಳ್ಳುತ್ತದೆ.
ವಿಧಾನಶಾಸ್ತ್ರದಲ್ಲಿ agile ಅಂತಿಮ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲ ಪರಿಕಲ್ಪನೆಯ ಸ್ವಲ್ಪ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಯಾಗಿದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅಭಿವೃದ್ಧಿಯ ಅಂತಿಮ ಹಂತವು ಅಗತ್ಯವಾಗಿ ಅಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ. ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ಸ್ಪ್ರಿಂಟ್‌ನ ಫಲಿತಾಂಶಗಳು ಮಾತ್ರ ಸ್ಪಷ್ಟ ಮತ್ತು ನಿಖರವಾಗಿರುತ್ತವೆ.
ಸಣ್ಣ ಕೋಡ್‌ಬೇಸ್‌ಗಳು
ಅರಿವಿನ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮುಂದಿನ ಹಂತವು ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು. ನಿಯಮದಂತೆ, ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಬೃಹತ್ ಪ್ರಮಾಣದಲ್ಲಿವೆ - ದೃಢವಾದ, ಎಂಟರ್‌ಪ್ರೈಸ್ ಅಪ್ಲಿಕೇಶನ್ ಸಾವಿರಾರು ಫೈಲ್‌ಗಳನ್ನು ಮತ್ತು ನೂರಾರು ಸಾವಿರ ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಫೈಲ್‌ಗಳನ್ನು ಹೇಗೆ ಆಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ, ಕೋಡ್ ಮತ್ತು ಫೈಲ್‌ಗಳ ನಡುವಿನ ಲಿಂಕ್‌ಗಳು ಮತ್ತು ಅವಲಂಬನೆಗಳು ಸ್ಪಷ್ಟವಾಗಿರಬಹುದು ಅಥವಾ ಪ್ರತಿಯಾಗಿ. ಬಳಸಿದ ಲೈಬ್ರರಿಗಳನ್ನು ಅವಲಂಬಿಸಿ ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವ ಉಪಕರಣಗಳು ಗ್ರಂಥಾಲಯಗಳು/ಪ್ಯಾಕೇಜ್‌ಗಳು/ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಸ್ಟಮ್ ಕೋಡ್‌ಗಳ ನಡುವೆ ಎಷ್ಟು ಚೆನ್ನಾಗಿ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ ಡೀಬಗ್ ಮಾಡುವ ಕೋಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಹ ಸಮಸ್ಯಾತ್ಮಕವಾಗಿರುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್‌ನ ಕೋಡ್‌ನ ಕೆಲಸದ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುವುದು ಪ್ರಭಾವಶಾಲಿ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಮತ್ತೊಮ್ಮೆ ಡೆವಲಪರ್‌ನ ಮೇಲೆ ದೊಡ್ಡ ಅರಿವಿನ ಹೊರೆಯನ್ನು ಹಾಕಬಹುದು. ಏಕಶಿಲೆಯ ಕೋಡ್ ಬೇಸ್‌ಗಳಿಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಸತ್ಯವಾಗಿದೆ, ಅಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕೋಡ್ ಇರುತ್ತದೆ, ಅದರ ಕ್ರಿಯಾತ್ಮಕ ಘಟಕಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ಗಡಿಗಳನ್ನು ಗೌರವಿಸದ ಕಾರಣ ಗಮನದ ವಸ್ತುಗಳ ಪ್ರತ್ಯೇಕತೆಯು ಹೆಚ್ಚಾಗಿ ಮಸುಕಾಗಿರುತ್ತದೆ.
ಇಂಜಿನಿಯರ್‌ಗಳ ಮೇಲಿನ ಅರಿವಿನ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಒಂದು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವೆಂದರೆ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಹೋಗುವುದು. ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ವಿಧಾನದಲ್ಲಿ, ಪ್ರತಿ ಸೇವೆಯು ಒಂದೊಂದು ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ; ಸೇವೆಯ ಅರ್ಥವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಮತ್ತು ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ. ಸೇವೆಯ ಗಡಿಗಳು ಸಹ ಸ್ಪಷ್ಟವಾಗಿವೆ - ಸೇವೆಯೊಂದಿಗಿನ ಸಂವಹನವನ್ನು API ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ, ಆದ್ದರಿಂದ ಒಂದು ಸೇವೆಯಿಂದ ರಚಿಸಲಾದ ಡೇಟಾವನ್ನು ಸುಲಭವಾಗಿ ಇನ್ನೊಂದಕ್ಕೆ ರವಾನಿಸಬಹುದು.
ಇತರ ಸೇವೆಗಳೊಂದಿಗಿನ ಸಂವಹನವು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಬಳಕೆದಾರ ಸೇವೆಗಳಿಗೆ ಮತ್ತು REST ಅನ್ನು ಬಳಸುವಂತಹ ಸರಳ ಮತ್ತು ಶುದ್ಧ API ಕರೆಗಳನ್ನು ಬಳಸುವ ಕೆಲವು ಪೂರೈಕೆದಾರರ ಸೇವೆಗಳಿಗೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ. ಇದರರ್ಥ ಇಂಜಿನಿಯರ್ ಮೇಲೆ ಅರಿವಿನ ಹೊರೆ ಗಂಭೀರವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ. ಸೇವೆಯ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಮಾದರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಬಹು ಸೇವೆಗಳಲ್ಲಿ ವಹಿವಾಟುಗಳಂತಹ ವಿಷಯಗಳು ಹೇಗೆ ನಡೆಯುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ದೊಡ್ಡ ಸವಾಲಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಬಳಕೆಯು ಕೋಡ್‌ನ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ ಅರಿವಿನ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಸ್ಪಷ್ಟ ಸೇವಾ ಗಡಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಮತ್ತು ಪೂರೈಕೆದಾರರ ನಡುವಿನ ಸಂಬಂಧದ ತಿಳುವಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಸಣ್ಣ ಹೆಚ್ಚುತ್ತಿರುವ ಬದಲಾವಣೆಗಳು
ತತ್ವದ ಕೊನೆಯ ಅಂಶ ಸಣ್ಣತನ ಬದಲಾವಣೆ ನಿರ್ವಹಣೆಯಾಗಿದೆ. ಡೆವಲಪರ್‌ಗಳಿಗೆ ಕೋಡ್ ಬೇಸ್ (ಬಹುಶಃ ಅವರದೇ ಆದ, ಹಳೆಯ ಕೋಡ್ ಕೂಡ) ನೋಡಲು ಮತ್ತು "ಇದು ಅಮೇಧ್ಯ, ನಾವು ಎಲ್ಲವನ್ನೂ ಪುನಃ ಬರೆಯಬೇಕಾಗಿದೆ" ಎಂದು ಹೇಳುವುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಲೋಭನೆಯಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ಇದು ಸರಿಯಾದ ನಿರ್ಧಾರ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅಲ್ಲ. ಇದು ಜಾಗತಿಕ ಮಾದರಿ ಬದಲಾವಣೆಯ ಹೊರೆಯನ್ನು ಅಭಿವೃದ್ಧಿ ತಂಡದ ಮೇಲೆ ಇರಿಸುತ್ತದೆ, ಇದು ಬೃಹತ್ ಅರಿವಿನ ಹೊರೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಇಂಜಿನಿಯರ್‌ಗಳು ಸ್ಪ್ರಿಂಟ್ ಸಮಯದಲ್ಲಿ ಮಾಡಬಹುದಾದ ಬದಲಾವಣೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದು ಉತ್ತಮ, ಇದರಿಂದ ಅವರು ಕ್ರಮೇಣವಾಗಿಯಾದರೂ ಸಮಯಕ್ಕೆ ಅಗತ್ಯವಾದ ಕಾರ್ಯವನ್ನು ಹೊರತರಬಹುದು. ಅಂತಿಮ ಉತ್ಪನ್ನವು ಪೂರ್ವ-ಯೋಜಿತ ಉತ್ಪನ್ನವನ್ನು ಹೋಲುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್‌ನ ಅಗತ್ಯಗಳಿಗೆ ಸರಿಹೊಂದುವಂತೆ ಕೆಲವು ಮಾರ್ಪಾಡುಗಳು ಮತ್ತು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ.
ಕೋಡ್‌ನ ದೊಡ್ಡ ಭಾಗಗಳನ್ನು ಪುನಃ ಬರೆಯುವಾಗ, ಇತರ ಸಿಸ್ಟಮ್ ಅವಲಂಬನೆಗಳು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುವುದರಿಂದ ಬದಲಾವಣೆಯನ್ನು ತ್ವರಿತವಾಗಿ ತಲುಪಿಸಲು ಕೆಲವೊಮ್ಮೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಬದಲಾವಣೆಗಳ ಹರಿವನ್ನು ನಿಯಂತ್ರಿಸಲು, ನೀವು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮರೆಮಾಡುವಿಕೆಯನ್ನು ಬಳಸಬಹುದು. ತಾತ್ವಿಕವಾಗಿ, ಇದರರ್ಥ ಕ್ರಿಯಾತ್ಮಕತೆಯು ಉತ್ಪಾದನೆಯಲ್ಲಿದೆ, ಆದರೆ ಇದು ಪರಿಸರ ವೇರಿಯಬಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು (env-var) ಅಥವಾ ಕೆಲವು ಇತರ ಸಂರಚನಾ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಲಭ್ಯವಿರುವುದಿಲ್ಲ. ಕೋಡ್ ಎಲ್ಲಾ ಗುಣಮಟ್ಟ ನಿಯಂತ್ರಣ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ರವಾನಿಸಿದರೆ, ಅದು ಸುಪ್ತ ಸ್ಥಿತಿಯಲ್ಲಿ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬಹುದು. ಆದಾಗ್ಯೂ, ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಂತಿಮವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಮಾತ್ರ ಈ ತಂತ್ರವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಕೋಡ್ ಅನ್ನು ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದಕವಾಗಲು ಡೆವಲಪರ್ ವ್ಯವಹರಿಸಬೇಕಾದ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಬದಲಾವಣೆ ನಿರ್ವಹಣೆ ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳ ಅರಿವಿನ ಕೆಲಸದ ಹೊರೆಯನ್ನು ನಿರ್ವಹಿಸುವಂತೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಹೆಚ್ಚುವರಿ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಸರಳ ಪರಿಚಯದೊಂದಿಗೆ ಎಂಜಿನಿಯರ್‌ಗಳು ಅನೇಕ ತೊಂದರೆಗಳನ್ನು ಜಯಿಸಬೇಕು. ನಿರ್ವಹಣೆಯ ಕಡೆಯಿಂದ, ತಂಡದ ಮೇಲಿನ ಅನಗತ್ಯ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ವಿವೇಕಯುತವಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಅದು ಪ್ರಮುಖ ಕ್ರಿಯಾತ್ಮಕ ಅಂಶಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಅಭಿವೃದ್ಧಿ ತಂಡಕ್ಕೆ ಸಹಾಯ ಮಾಡಲು ನೀವು ಮಾಡಬಹುದಾದ ಮೂರು ವಿಷಯಗಳಿವೆ:
- ವಿಧಾನವನ್ನು ಬಳಸಿ
agileತಂಡವು ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕಾದ ಸಮಯದ ಚೌಕಟ್ಟನ್ನು ಮಿತಿಗೊಳಿಸಲು. - ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಹು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ನಂತೆ ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಇದು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ವೈಶಿಷ್ಟ್ಯಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲಸದಲ್ಲಿ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಇರಿಸಿಕೊಳ್ಳುವ ಗಡಿಗಳನ್ನು ಬಲಪಡಿಸುತ್ತದೆ.
- ದೊಡ್ಡದಾದ ಮತ್ತು ಅಸಾಧಾರಣವಾಗಿ ಹೆಚ್ಚುತ್ತಿರುವ ಬದಲಾವಣೆಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿ, ಕೋಡ್‌ನ ಸಣ್ಣ ತುಣುಕುಗಳನ್ನು ಬದಲಾಯಿಸಿ. ಬದಲಾವಣೆಗಳನ್ನು ಸೇರಿಸಿದ ನಂತರ ತಕ್ಷಣವೇ ಗೋಚರಿಸದಿದ್ದರೂ ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮರೆಮಾಡುವುದನ್ನು ಬಳಸಿ.
ನಿಮ್ಮ ಕೆಲಸದಲ್ಲಿ ಸಣ್ಣತನದ ತತ್ವವನ್ನು ನೀವು ಅನ್ವಯಿಸಿದರೆ, ನಿಮ್ಮ ತಂಡವು ಹೆಚ್ಚು ಸಂತೋಷದಿಂದ ಕೂಡಿರುತ್ತದೆ, ಅಗತ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಉತ್ತಮವಾಗಿ ಗಮನಹರಿಸುತ್ತದೆ ಮತ್ತು ಗುಣಾತ್ಮಕ ಬದಲಾವಣೆಗಳನ್ನು ವೇಗವಾಗಿ ಹೊರಹಾಕುವ ಸಾಧ್ಯತೆಯಿದೆ. ಆದರೆ ಕೆಲಸವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುವುದಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ, ಕೆಲವೊಮ್ಮೆ, ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಹೊಸ ಕಾರ್ಯಚಟುವಟಿಕೆಯನ್ನು ಪರಿಚಯಿಸಲು ಹಲವಾರು ಸೇವೆಗಳ ಮಾರ್ಪಾಡು ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಈ ಪ್ರಕ್ರಿಯೆಯು ಏಕಶಿಲೆಯ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಹೋಲುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಸಣ್ಣತನದ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರಯೋಜನಗಳು ಯೋಗ್ಯವಾಗಿವೆ.
ಮೊದಲ ಭಾಗದ ಅಂತ್ಯ.
ಶೀಘ್ರದಲ್ಲೇ ನಾವು ಅನುವಾದದ ಎರಡನೇ ಭಾಗವನ್ನು ಪ್ರಕಟಿಸುತ್ತೇವೆ ಮತ್ತು ಈಗ ನಾವು ನಿಮ್ಮ ಕಾಮೆಂಟ್‌ಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ ಮತ್ತು ನಿಮ್ಮನ್ನು ಆಹ್ವಾನಿಸುತ್ತೇವೆ , ಇದು ಇಂದು 20.00 ಕ್ಕೆ ನಡೆಯುತ್ತದೆ.
ಮೂಲ: www.habr.com