CI ಪರಿಕರಗಳು ಮತ್ತು CI ಏಕೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ ಎಂಬುದನ್ನು ಚರ್ಚಿಸೋಣ.
CI ಯಾವ ನೋವನ್ನು ಪರಿಹರಿಸಲು ಉದ್ದೇಶಿಸಿದೆ, ಕಲ್ಪನೆಯು ಎಲ್ಲಿಂದ ಬಂದಿದೆ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಇತ್ತೀಚಿನ ದೃಢೀಕರಣಗಳು ಯಾವುವು, ನೀವು ಅಭ್ಯಾಸವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಕೇವಲ ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ.
ನಿರಂತರ ಏಕೀಕರಣದ ಬಗ್ಗೆ ವರದಿ ಮಾಡುವ ಆಲೋಚನೆ ಒಂದು ವರ್ಷದ ಹಿಂದೆ ಕಾಣಿಸಿಕೊಂಡಿತು, ನಾನು ಸಂದರ್ಶನಗಳಿಗೆ ಹೋಗಿ ಕೆಲಸ ಹುಡುಕುತ್ತಿರುವಾಗ. ನಾನು 10-15 ಕಂಪನಿಗಳೊಂದಿಗೆ ಮಾತನಾಡಿದ್ದೇನೆ, ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ CI ಏನು ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಮತ್ತು ಅವರು ಅದನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದು ಅವರು ಹೇಗೆ ಅರಿತುಕೊಂಡರು ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಉಳಿದವರು ಜೆಂಕಿನ್ಸ್ ಬಗ್ಗೆ ಅರ್ಥವಾಗದ ಅಸಂಬದ್ಧ ಮಾತನಾಡುತ್ತಿದ್ದರು :) ಸರಿ, ನಾವು ಜೆಂಕಿನ್ಸ್ ಹೊಂದಿದ್ದೇವೆ, ಅದು ನಿರ್ಮಿಸುತ್ತದೆ, CI! ವರದಿಯ ಸಮಯದಲ್ಲಿ, ನಿರಂತರ ಏಕೀಕರಣವು ನಿಜವಾಗಿ ಏನೆಂದು ವಿವರಿಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ ಮತ್ತು ಜೆಂಕಿನ್ಸ್ ಮತ್ತು ಅಂತಹುದೇ ಸಾಧನಗಳು ಇದರೊಂದಿಗೆ ಏಕೆ ದುರ್ಬಲ ಸಂಬಂಧವನ್ನು ಹೊಂದಿವೆ.
ಆದ್ದರಿಂದ, ನೀವು CI ಪದವನ್ನು ಕೇಳಿದಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಏನು ನೆನಪಿಗೆ ಬರುತ್ತದೆ? ಹೆಚ್ಚಿನ ಜನರು ಜೆಂಕಿನ್ಸ್, ಗಿಟ್ಲಾಬ್ ಸಿಐ, ಟ್ರಾವಿಸ್, ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಾರೆ.
ನಾವು ಅದನ್ನು ಗೂಗಲ್ ಮಾಡಿದರೂ, ಅದು ನಮಗೆ ಈ ಉಪಕರಣಗಳನ್ನು ನೀಡುತ್ತದೆ.
ನೀವು ಕೇಳಲು ಪರಿಚಿತರಾಗಿದ್ದರೆ, ಉಪಕರಣಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿದ ತಕ್ಷಣ, ನೀವು ಬದ್ಧತೆಗಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ನಿರ್ಮಿಸಿದಾಗ ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದಾಗ CI ಎಂದು ಅವರು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ.
ನಿರಂತರ ಏಕೀಕರಣವು ಪರಿಕರಗಳ ಬಗ್ಗೆ ಅಲ್ಲ, ಶಾಖೆಯಲ್ಲಿ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಅಸೆಂಬ್ಲಿಗಳ ಬಗ್ಗೆ ಅಲ್ಲ! ನಿರಂತರ ಏಕೀಕರಣವು ಹೊಸ ಕೋಡ್‌ನ ಆಗಾಗ್ಗೆ ಏಕೀಕರಣದ ಅಭ್ಯಾಸವಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಬಳಸಲು ಜೆಂಕಿನ್ಸ್, ಗಿಟ್‌ಲ್ಯಾಬ್ ಇತ್ಯಾದಿಗಳನ್ನು ಬೇಲಿ ಹಾಕುವ ಅಗತ್ಯವಿಲ್ಲ.
ಪೂರ್ಣ ಪ್ರಮಾಣದ ಸಿಐ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಮೊದಲು, ಮೊದಲು ಅದರೊಂದಿಗೆ ಬಂದ ಜನರ ಸನ್ನಿವೇಶಕ್ಕೆ ಧುಮುಕುವುದು ಮತ್ತು ಅವರು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ನೋವನ್ನು ಅನುಭವಿಸೋಣ.
ಮತ್ತು ಅವರು ತಂಡವಾಗಿ ಒಟ್ಟಾಗಿ ಕೆಲಸ ಮಾಡುವ ನೋವನ್ನು ಪರಿಹರಿಸಿದರು!
ತಂಡಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಡೆವಲಪರ್‌ಗಳು ಎದುರಿಸುವ ತೊಂದರೆಗಳ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡೋಣ. ಇಲ್ಲಿ ನಾವು ಪ್ರಾಜೆಕ್ಟ್ ಹೊಂದಿದ್ದೇವೆ, ಜಿಟ್‌ನಲ್ಲಿ ಮಾಸ್ಟರ್ ಶಾಖೆ ಮತ್ತು ಇಬ್ಬರು ಡೆವಲಪರ್‌ಗಳು.
ಮತ್ತು ಎಲ್ಲರೂ ಬಹಳ ಹಿಂದೆಯೇ ಒಗ್ಗಿಕೊಂಡಿರುವಂತೆ ಅವರು ಕೆಲಸಕ್ಕೆ ಹೋದರು. ನಾವು ವಸ್ತುಗಳ ಗ್ರ್ಯಾಂಡ್ ಸ್ಕೀಮ್‌ನಲ್ಲಿ ಕಾರ್ಯವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ.
ಒಬ್ಬರು ವೈಶಿಷ್ಟ್ಯವನ್ನು ವೇಗವಾಗಿ ಮುಗಿಸಿದರು ಮತ್ತು ಅದನ್ನು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಿದರು.
ಎರಡನೆಯದಕ್ಕೆ ಹೆಚ್ಚಿನ ಸಮಯ ಬೇಕಾಗಿತ್ತು, ಅದು ನಂತರ ವಿಲೀನಗೊಂಡಿತು ಮತ್ತು ಸಂಘರ್ಷದೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿತು. ಈಗ, ವ್ಯವಹಾರಕ್ಕೆ ಅಗತ್ಯವಿರುವ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬರೆಯುವ ಬದಲು, ಡೆವಲಪರ್ ತನ್ನ ಸಮಯ ಮತ್ತು ಶಕ್ತಿಯನ್ನು ಘರ್ಷಣೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಕಳೆಯುತ್ತಾನೆ.
ನಿಮ್ಮ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸಾಮಾನ್ಯ ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟ, ನಾವು ಅದರಲ್ಲಿ ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತೇವೆ. ಮತ್ತು ನಾನು ಇದನ್ನು ಸರಳವಾದ ಉದಾಹರಣೆಯೊಂದಿಗೆ ತೋರಿಸಿದೆ. ಇದು ಕೇವಲ 2 ಡೆವಲಪರ್‌ಗಳಿರುವ ಉದಾಹರಣೆಯಾಗಿದೆ. ಒಂದು ಕಂಪನಿಯಲ್ಲಿ 10 ಅಥವಾ 15 ಅಥವಾ 100 ಜನರು ಒಂದು ರೆಪೊಸಿಟರಿಗೆ ಬರೆಯುತ್ತಾರೆಯೇ ಎಂದು ಊಹಿಸಿ. ಈ ಎಲ್ಲಾ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು ನೀವು ಹುಚ್ಚರಾಗುತ್ತೀರಿ.
ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದ ಪ್ರಕರಣವಿದೆ. ನಮ್ಮಲ್ಲಿ ಮಾಸ್ಟರ್ ಇದ್ದಾರೆ ಮತ್ತು ಕೆಲವು ಡೆವಲಪರ್‌ಗಳು ಏನನ್ನಾದರೂ ಮಾಡುತ್ತಿದ್ದಾರೆ.
ಅವರು ಒಂದು ರೆಂಬೆಯನ್ನು ರಚಿಸಿದರು.
ಒಬ್ಬರು ಸತ್ತರು, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು, ಅವರು ಕಾರ್ಯವನ್ನು ಅಂಗೀಕರಿಸಿದರು.
ಎರಡನೇ ಡೆವಲಪರ್, ಏತನ್ಮಧ್ಯೆ, ತನ್ನ ಕೆಲಸವನ್ನು ಹಸ್ತಾಂತರಿಸಿದರು. ಅವರು ಅದನ್ನು ಪರಿಶೀಲನೆಗೆ ಕಳುಹಿಸಿದ್ದಾರೆ ಎಂದು ಹೇಳೋಣ. ಅನೇಕ ಕಂಪನಿಗಳು ವಿಮರ್ಶೆ ಎಂಬ ಅಭ್ಯಾಸವನ್ನು ಹೊಂದಿವೆ. ಒಂದೆಡೆ, ಈ ಅಭ್ಯಾಸವು ಒಳ್ಳೆಯದು ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿದೆ, ಮತ್ತೊಂದೆಡೆ, ಇದು ಅನೇಕ ರೀತಿಯಲ್ಲಿ ನಮ್ಮನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ನಾವು ಅದರೊಳಗೆ ಹೋಗುವುದಿಲ್ಲ, ಆದರೆ ಕೆಟ್ಟ ವಿಮರ್ಶೆಯ ಕಥೆಯು ಏನು ಕಾರಣವಾಗಬಹುದು ಎಂಬುದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ. ನೀವು ಪರಿಶೀಲನೆಗಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿರುವಿರಿ. ಡೆವಲಪರ್ ಮಾಡಲು ಹೆಚ್ಚೇನೂ ಇಲ್ಲ. ಅವನು ಏನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ? ಅವನು ಇತರ ಕಾರ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ.
ಈ ಸಮಯದಲ್ಲಿ, ಎರಡನೇ ಡೆವಲಪರ್ ಬೇರೆ ಏನಾದರೂ ಮಾಡಿದರು.
ಮೊದಲನೆಯದು ಮೂರನೇ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿತು.
ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಅವರ ವಿಮರ್ಶೆಯನ್ನು ಪರೀಕ್ಷಿಸಲಾಯಿತು, ಮತ್ತು ಅವರು ನಿಯಮಗಳಿಗೆ ಬರಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ. ಮತ್ತೆ ಏನು ನಡೀತಿದೆ? ಇದು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಘರ್ಷಣೆಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಏಕೆ? ಏಕೆಂದರೆ ಅವರ ಪುಲ್ ವಿನಂತಿಯು ವಿಮರ್ಶೆಯಲ್ಲಿ ನೇತಾಡುತ್ತಿರುವಾಗ, ಕೋಡ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಬಹಳಷ್ಟು ವಿಷಯಗಳು ಬದಲಾಗಿದ್ದವು.
ಸಂಘರ್ಷಗಳೊಂದಿಗಿನ ಕಥೆಯ ಜೊತೆಗೆ, ಸಂವಹನಗಳೊಂದಿಗಿನ ಕಥೆಯೂ ಇದೆ. ನಿಮ್ಮ ಥ್ರೆಡ್ ವಿಮರ್ಶೆಯಲ್ಲಿ ತೂಗಾಡುತ್ತಿರುವಾಗ, ಅದು ಯಾವುದನ್ನಾದರೂ ಕಾಯುತ್ತಿರುವಾಗ, ನೀವು ದೀರ್ಘಕಾಲದವರೆಗೆ ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ, ನಿಮ್ಮ ಸೇವೆಯ ಕೋಡ್ ಬೇಸ್‌ನಲ್ಲಿ ಇನ್ನೇನು ಬದಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಬಹುಶಃ ನೀವು ಈಗ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದನ್ನು ನಿನ್ನೆ ಈಗಾಗಲೇ ಪರಿಹರಿಸಲಾಗಿದೆ ಮತ್ತು ನೀವು ಕೆಲವು ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಆದರೆ ನೀವು ಇದನ್ನು ನೋಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ ನೀವು ಯಾವಾಗಲೂ ಹಳೆಯ ಶಾಖೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ. ಮತ್ತು ಈ ಹಳತಾದ ಶಾಖೆಯು ಯಾವಾಗಲೂ ವಿಲೀನ ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸಲು ನಿಮಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನಾವು ತಂಡವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಅಂದರೆ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸುತ್ತಾಡುತ್ತಿಲ್ಲ, ಆದರೆ 5-10 ಜನರು, ನಂತರ ನಾವು ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಸೇರಿಸದಿದ್ದರೆ, ನಾವು ಹೆಚ್ಚು ಬಳಲುತ್ತಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಮಗೆ ಅಂತಿಮವಾಗಿ ಅಗತ್ಯವಿದೆ ಏನಾದರೂ ನಂತರ ಅದನ್ನು ವಿಲೀನಗೊಳಿಸಿ. ಮತ್ತು ನಾವು ಹೆಚ್ಚು ಸಂಘರ್ಷಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಹಳೆಯ ಆವೃತ್ತಿಯೊಂದಿಗೆ ನಾವು ಕೆಲಸ ಮಾಡುತ್ತೇವೆ, ನಮಗೆ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳಿವೆ.
ಒಟ್ಟಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡುವುದು ನೋವಿನ ಸಂಗತಿ! ನಾವು ಯಾವಾಗಲೂ ಪರಸ್ಪರರ ದಾರಿಯಲ್ಲಿ ಹೋಗುತ್ತೇವೆ.
ಈ ಸಮಸ್ಯೆಯನ್ನು 20 ವರ್ಷಗಳ ಹಿಂದೆ ಗಮನಿಸಲಾಯಿತು. ಎಕ್ಸ್‌ಟ್ರೀಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ನಿರಂತರ ಏಕೀಕರಣದ ಅಭ್ಯಾಸದ ಮೊದಲ ಉಲ್ಲೇಖವನ್ನು ನಾನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ.
ಎಕ್ಸ್‌ಟ್ರೀಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮೊದಲ ಅಗೈಲ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಆಗಿದೆ. ಪುಟವು 96 ರಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ಮತ್ತು ಕಲ್ಪನೆಯು ಕೆಲವು ರೀತಿಯ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅಭ್ಯಾಸಗಳು, ಯೋಜನೆ ಮತ್ತು ಇತರ ವಿಷಯಗಳನ್ನು ಬಳಸುವುದು, ಇದರಿಂದ ಅಭಿವೃದ್ಧಿಯು ಸಾಧ್ಯವಾದಷ್ಟು ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ, ಇದರಿಂದ ನಾವು ನಮ್ಮ ಗ್ರಾಹಕರಿಂದ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಅಥವಾ ಅವಶ್ಯಕತೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು. ಮತ್ತು ಅವರು 24 ವರ್ಷಗಳ ಹಿಂದೆ ಇದನ್ನು ಎದುರಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ನೀವು ಬಹಳ ಸಮಯ ಮತ್ತು ಬದಿಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡಿದರೆ, ನೀವು ಘರ್ಷಣೆಗಳನ್ನು ಹೊಂದಿರುವ ಕಾರಣ ನೀವು ಅದರ ಮೇಲೆ ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತೀರಿ.
ಈಗ ನಾವು "ನಿರಂತರ ಏಕೀಕರಣ" ಎಂಬ ಪದಗುಚ್ಛವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ. ನಾವು ಅದನ್ನು ನೇರವಾಗಿ ಅನುವಾದಿಸಿದರೆ, ನಾವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಆದರೆ ಇದು ಎಷ್ಟು ನಿರಂತರವಾಗಿದೆ ಎಂಬುದು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ; ಇದು ತುಂಬಾ ಸ್ಥಗಿತವಾಗಿದೆ. ಆದರೆ ಅದು ಎಷ್ಟು ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದೆ ಎಂಬುದು ಸಹ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.
ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ನಾನು ಈಗ ನಿಮಗೆ ಎಕ್ಸ್‌ಟ್ರೀಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಿಂದ ಉಲ್ಲೇಖಗಳನ್ನು ನೀಡುತ್ತಿದ್ದೇನೆ. ಮತ್ತು ನಾವು ಎರಡೂ ಪದಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ.
ಏಕೀಕರಣ - ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಪ್ರತಿಯೊಬ್ಬ ಇಂಜಿನಿಯರ್ ಕೋಡ್‌ನ ಅತ್ಯಂತ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಅವರು ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ಸಾಮಾನ್ಯ ಶಾಖೆಗೆ ಆಗಾಗ್ಗೆ ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ, ಇದರಿಂದ ಇವುಗಳು ಸಣ್ಣ ಶಾಖೆಗಳಾಗಿವೆ. ಏಕೆಂದರೆ ಅವು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ನಾವು ಒಂದು ವಾರದವರೆಗೆ ವಿಲೀನ ಸಂಘರ್ಷಗಳೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಸಿಲುಕಿಕೊಳ್ಳಬಹುದು. ನಾವು ಜಲಪಾತದಂತಹ ದೀರ್ಘ ಅಭಿವೃದ್ಧಿ ಚಕ್ರವನ್ನು ಹೊಂದಿದ್ದರೆ, ಕೆಲವು ದೊಡ್ಡ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಕಡಿತಗೊಳಿಸಲು ಡೆವಲಪರ್ ಒಂದು ತಿಂಗಳ ಕಾಲ ದೂರ ಹೋದರೆ ಇದು ವಿಶೇಷವಾಗಿ ಸತ್ಯವಾಗಿದೆ. ಮತ್ತು ಅವರು ಬಹಳ ಸಮಯದವರೆಗೆ ಏಕೀಕರಣದ ಹಂತದಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುತ್ತಾರೆ.
ಏಕೀಕರಣವೆಂದರೆ ನಾವು ನಮ್ಮ ಶಾಖೆಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದಾಗ, ನಾವು ಅದನ್ನು ವಿಲೀನಗೊಳಿಸುತ್ತೇವೆ. ನಾವು ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಡೆವಲಪರ್ ಆಗಿರುವಾಗ ಅಂತಿಮ ಆಯ್ಕೆಯಿದೆ, ಅಲ್ಲಿ ನಾವು ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಶಾಖೆಗಳಿಲ್ಲದೆ ಮಾಸ್ಟರ್‌ಗೆ ತಕ್ಷಣ ಬರೆಯುತ್ತೇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಏಕೀಕರಣ ಎಂದರೆ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಎಳೆಯುವುದು.
"ನಿರಂತರ" ಎಂಬ ಪದದಿಂದ ಇಲ್ಲಿ ಏನು ಅರ್ಥೈಸಲಾಗುತ್ತದೆ, ಅದನ್ನು ನಿರಂತರತೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ? ಡೆವಲಪರ್ ತನ್ನ ಕೋಡ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸಂಯೋಜಿಸಲು ಶ್ರಮಿಸುತ್ತಾನೆ ಎಂದು ಅಭ್ಯಾಸವು ಸೂಚಿಸುತ್ತದೆ. ಯಾವುದೇ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುವಾಗ ಇದು ಅವನ ಗುರಿಯಾಗಿದೆ - ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ತನ್ನ ಕೋಡ್ ಅನ್ನು ಮಾಸ್ಟರ್ ಆಗಿ ಪಡೆಯುವುದು. ಆದರ್ಶ ಜಗತ್ತಿನಲ್ಲಿ, ಅಭಿವರ್ಧಕರು ಪ್ರತಿ ಕೆಲವು ಗಂಟೆಗಳಿಗೊಮ್ಮೆ ಇದನ್ನು ಮಾಡುತ್ತಾರೆ. ಅಂದರೆ, ನೀವು ಒಂದು ಸಣ್ಣ ಸಮಸ್ಯೆಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಮಾಸ್ಟರ್ ಆಗಿ ವಿಲೀನಗೊಳಿಸುತ್ತೀರಿ. ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ. ಇದಕ್ಕಾಗಿ ನೀವು ಶ್ರಮಿಸುತ್ತೀರಿ. ಮತ್ತು ಇದನ್ನು ನಿರಂತರವಾಗಿ ಮಾಡಬೇಕು. ನೀವು ಏನನ್ನಾದರೂ ಮಾಡಿದ ತಕ್ಷಣ, ನೀವು ತಕ್ಷಣ ಅದನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಹಾಕುತ್ತೀರಿ.
ಮತ್ತು ಏನನ್ನಾದರೂ ಮಾಡುವ ಡೆವಲಪರ್ ಅದನ್ನು ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಯಾವುದನ್ನೂ ಮುರಿಯದಿರಲು ಅವನು ಏನು ಮಾಡಿದನೋ ಅದಕ್ಕೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ. ಪರೀಕ್ಷೆಯ ಕಥೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೊರಬರುವುದು ಇಲ್ಲಿಯೇ. ನಮ್ಮ ಬದ್ಧತೆಯ ಮೇಲೆ, ನಮ್ಮ ವಿಲೀನದ ಮೇಲೆ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಕೆಲವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ಬಯಸುತ್ತೇವೆ. ಮತ್ತು ಇಲ್ಲಿ ಜೆಂಕಿನ್ಸ್ ನಿಮಗೆ ಸಹಾಯ ಮಾಡಬಹುದು.
ಆದರೆ ಕಥೆಗಳೊಂದಿಗೆ: ಬದಲಾವಣೆಗಳನ್ನು ಚಿಕ್ಕದಾಗಿ ಮಾಡೋಣ, ಕಾರ್ಯಗಳು ಚಿಕ್ಕದಾಗಿರಲಿ, ಸಮಸ್ಯೆಯನ್ನು ಮಾಡೋಣ ಮತ್ತು ಅದನ್ನು ಹೇಗಾದರೂ ಮಾಸ್ಟರ್‌ಗೆ ಎಂಬೆಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ - ಇಲ್ಲಿ ಯಾವುದೇ ಜೆಂಕಿನ್ಸ್ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಜೆಂಕಿನ್ಸ್ ನಿಮಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.
ನೀವು ಅವರಿಲ್ಲದೆ ಮಾಡಬಹುದು. ಇದರಿಂದ ನಿಮಗೆ ಯಾವುದೇ ತೊಂದರೆಯಾಗುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಅಭ್ಯಾಸದ ಗುರಿಯು ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಾಗಿ ಅಳೆಯುವುದು, ಆದ್ದರಿಂದ ಭವಿಷ್ಯದಲ್ಲಿ ಯಾವುದೇ ಘರ್ಷಣೆಗೆ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡಬಾರದು.
ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನಾವು 2020 ರಲ್ಲಿ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲದೆ ಇದ್ದೇವೆ ಎಂದು ಊಹಿಸೋಣ. ಮತ್ತು ನಾವು ಸ್ಥಳೀಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ನಮ್ಮಲ್ಲಿ ಜೆಂಕಿನ್ಸ್ ಇಲ್ಲ. ಇದು ಚೆನ್ನಾಗಿದೆ. ನೀವು ಇನ್ನೂ ಮುಂದುವರಿಯಬಹುದು ಮತ್ತು ಸ್ಥಳೀಯ ಶಾಖೆಯನ್ನು ಮಾಡಬಹುದು. ನೀವು ಅದರಲ್ಲಿ ಕೆಲವು ಕೋಡ್ ಬರೆದಿದ್ದೀರಿ. ನಾವು 3-4 ಗಂಟೆಗಳಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ್ದೇವೆ. ನಾವು ಮಾಸ್ಟರ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಜಿಟ್ ಪುಲ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಶಾಖೆಯನ್ನು ಅಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಿದ್ದೇವೆ. ಸಿದ್ಧವಾಗಿದೆ. ನೀವು ಇದನ್ನು ಆಗಾಗ್ಗೆ ಮಾಡಿದರೆ, ಅಭಿನಂದನೆಗಳು, ನೀವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದ್ದೀರಿ!
ಆಧುನಿಕ ಜಗತ್ತಿನಲ್ಲಿ ಶಕ್ತಿಯನ್ನು ವ್ಯಯಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಯಾವ ಪುರಾವೆಗಳಿವೆ? ಏಕೆಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಕಷ್ಟ. ನೀವು ಈ ರೀತಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಕೆಲವು ಯೋಜನೆಗಳು ಈಗ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ, ನೀವು ಕೊಳೆಯುವ ಕಾರ್ಯಗಳಿಗೆ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸಬೇಕು. ಏಕೆಂದರೆ ನೀವು ಮನುಷ್ಯನನ್ನು ಮಾಡಿದರೆ ..., ನಂತರ ನೀವು ಬೇಗನೆ ಹೊಂದಾಣಿಕೆ ಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ತೊಂದರೆಗೆ ಸಿಲುಕುತ್ತೀರಿ. ನೀವು ಇನ್ನು ಮುಂದೆ ಅಭ್ಯಾಸವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ.
ಮತ್ತು ಇದು ದುಬಾರಿಯಾಗಲಿದೆ. ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು ನಾಳೆಯಿಂದ ತಕ್ಷಣವೇ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಇದು ನಿಮಗೆ ಒಗ್ಗಿಕೊಳ್ಳಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಕೊಳೆಯುವ ಕಾರ್ಯಗಳಿಗೆ ಒಗ್ಗಿಕೊಳ್ಳಲು ನಿಮಗೆ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ವಿಮರ್ಶೆ ಅಭ್ಯಾಸವನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ ಅದನ್ನು ಮತ್ತೆ ಮಾಡಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ . ಏಕೆಂದರೆ ಅದು ಇಂದು ಕರಗಲಿ ಎಂಬುದು ನಮ್ಮ ಗುರಿ. ಮತ್ತು ನೀವು ಮೂರು ದಿನಗಳಲ್ಲಿ ವಿಮರ್ಶೆಯನ್ನು ಮಾಡಿದರೆ, ನಿಮಗೆ ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣವು ನಿಮಗಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ.
ಆದರೆ ಈ ಅಭ್ಯಾಸದಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಎಂದು ಹೇಳುವ ಯಾವುದೇ ಸಂಬಂಧಿತ ಪುರಾವೆಗಳು ನಮ್ಮ ಬಳಿ ಇವೆಯೇ?
ನನ್ನ ಮನಸ್ಸಿಗೆ ಬಂದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಸ್ಟೇಟ್ ಆಫ್ ಡೆವೊಪ್ಸ್. ಇದು ಹುಡುಗರು 7 ವರ್ಷಗಳಿಂದ ನಡೆಸುತ್ತಿರುವ ಅಧ್ಯಯನವಾಗಿದೆ. ಈಗ ಅವರು ಅದನ್ನು ಸ್ವತಂತ್ರ ಸಂಸ್ಥೆಯಾಗಿ ಮಾಡುತ್ತಾರೆ, ಆದರೆ Google ಅಡಿಯಲ್ಲಿ.
ಮತ್ತು ಅವರ 2018 ರ ಅಧ್ಯಯನವು ತ್ವರಿತವಾಗಿ ಸಂಯೋಜಿಸುವ, ಆಗಾಗ್ಗೆ ಸಂಯೋಜಿಸುವ ಮತ್ತು ಉತ್ತಮ ಐಟಿ ಕಾರ್ಯಕ್ಷಮತೆ ಸೂಚಕಗಳನ್ನು ಹೊಂದಿರುವ ಅಲ್ಪಾವಧಿಯ ಶಾಖೆಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುವ ಕಂಪನಿಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ತೋರಿಸಿದೆ.
ಈ ಸೂಚಕಗಳು ಯಾವುವು? ಇವುಗಳು ತಮ್ಮ ಪ್ರಶ್ನಾವಳಿಗಳಲ್ಲಿ ಎಲ್ಲಾ ಕಂಪನಿಗಳಿಂದ ತೆಗೆದುಕೊಳ್ಳುವ 4 ಮೆಟ್ರಿಕ್‌ಗಳಾಗಿವೆ: ನಿಯೋಜನೆ ಆವರ್ತನ, ಬದಲಾವಣೆಗಳಿಗೆ ಪ್ರಮುಖ ಸಮಯ, ಸೇವೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಸಮಯ, ವೈಫಲ್ಯದ ದರವನ್ನು ಬದಲಾಯಿಸುವುದು.
ಮತ್ತು, ಮೊದಲನೆಯದಾಗಿ, ಈ ಪರಸ್ಪರ ಸಂಬಂಧವಿದೆ, ಆಗಾಗ್ಗೆ ಅಳತೆ ಮಾಡುವ ಕಂಪನಿಗಳು ಉತ್ತಮ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿವೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ. ಮತ್ತು ಅವರು ಹಲವಾರು ವರ್ಗಗಳಾಗಿ ಕಂಪನಿಗಳ ವಿಭಾಗವನ್ನು ಹೊಂದಿದ್ದಾರೆ: ಇವು ನಿಧಾನವಾಗಿ ಏನನ್ನಾದರೂ ಉತ್ಪಾದಿಸುವ ನಿಧಾನಗತಿಯ ಕಂಪನಿಗಳು, ಮಧ್ಯಮ ಪ್ರದರ್ಶನಕಾರರು, ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಗಣ್ಯರು. ಗಣ್ಯರೆಂದರೆ ನೆಟ್‌ಫ್ಲಿಕ್ಸ್, ಅಮೆಜಾನ್, ಇದು ಅತಿ ವೇಗವಾಗಿದೆ, ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ, ಸುಂದರವಾಗಿ ಮತ್ತು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮಾಡಿ.
ಕೇವಲ ಒಂದು ತಿಂಗಳ ಹಿಂದೆ ನಡೆದ ಎರಡನೇ ಕಥೆ. ತಂತ್ರಜ್ಞಾನ ರಾಡಾರ್ Gitflow ಕುರಿತು ಉತ್ತಮ ಲೇಖನವನ್ನು ಹೊಂದಿದೆ. ಗಿಟ್‌ಫ್ಲೋ ಎಲ್ಲಾ ಇತರರಿಗಿಂತ ಭಿನ್ನವಾಗಿದೆ, ಅದರ ಶಾಖೆಗಳು ದೀರ್ಘಕಾಲ ಬದುಕುತ್ತವೆ. ದೀರ್ಘಕಾಲ ಬದುಕುವ ಬಿಡುಗಡೆ ಶಾಖೆಗಳಿವೆ, ಮತ್ತು ದೀರ್ಘಕಾಲ ಬದುಕುವ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಗಳಿವೆ. ತಂತ್ರಜ್ಞಾನ ರಾಡಾರ್‌ನಲ್ಲಿನ ಈ ಅಭ್ಯಾಸವು HOLD ಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ. ಏಕೆ? ಏಕೆಂದರೆ ಜನರು ಏಕೀಕರಣದ ನೋವನ್ನು ಎದುರಿಸುತ್ತಾರೆ.
ನಿಮ್ಮ ಶಾಖೆಯು ಬಹಳ ಸಮಯದವರೆಗೆ ಜೀವಿಸಿದರೆ, ಅದು ಸಿಲುಕಿಕೊಳ್ಳುತ್ತದೆ, ಕೊಳೆಯುತ್ತದೆ, ಮತ್ತು ನಾವು ಅದರಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಬದಲಾವಣೆಯನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.
ಮತ್ತು ಇತ್ತೀಚೆಗೆ Gitflow ನ ಲೇಖಕರು ನಿಮ್ಮ ಗುರಿಯು ನಿರಂತರ ಏಕೀಕರಣವಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಗುರಿಯು ನೀವು ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಾಗಿ ರೋಲ್ ಮಾಡಲು ಬಯಸಿದರೆ, Gitflow ಒಂದು ಕೆಟ್ಟ ಕಲ್ಪನೆಯಾಗಿದೆ ಎಂದು ಹೇಳಿದರು. ನೀವು ಇದಕ್ಕಾಗಿ ಶ್ರಮಿಸುವ ಬ್ಯಾಕೆಂಡ್ ಹೊಂದಿದ್ದರೆ, Gitflow ನಿಮಗೆ ಅತಿಯಾದದ್ದು ಎಂದು ಅವರು ಲೇಖನಕ್ಕೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಸೇರಿಸಿದ್ದಾರೆ, ಏಕೆಂದರೆ Gitflow ನಿಮ್ಮನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ, Gitflow ಏಕೀಕರಣದೊಂದಿಗೆ ನಿಮಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
Gitflow ಕೆಟ್ಟದಾಗಿದೆ ಮತ್ತು ಬಳಸಬಾರದು ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಇದು ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ಸೇವೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಲವಾರು ಆವೃತ್ತಿಗಳನ್ನು ಬೆಂಬಲಿಸಬೇಕಾದಾಗ, ಅಂದರೆ ನಿಮಗೆ ದೀರ್ಘಾವಧಿಯವರೆಗೆ ಬೆಂಬಲ ಬೇಕಾಗುತ್ತದೆ.
ಆದರೆ ಅಂತಹ ಸೇವೆಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಜನರೊಂದಿಗೆ ನೀವು ಮಾತನಾಡಿದರೆ, ಈ ಆವೃತ್ತಿಯು 3.2 ತಿಂಗಳ ಹಿಂದೆ 4 ಆಗಿತ್ತು, ಆದರೆ ಈ ಪರಿಹಾರವನ್ನು ಅದರಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಈಗ ಅದನ್ನು ಮಾಡಲು, ನೀವು ಸಾಕಷ್ಟು ನೋವನ್ನು ಕೇಳುತ್ತೀರಿ. ನೀವು ಬದಲಾವಣೆಗಳ ಗುಂಪನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಮತ್ತು ಈಗ ಅವರು ಮತ್ತೆ ಸಿಲುಕಿಕೊಂಡಿದ್ದಾರೆ, ಮತ್ತು ಈಗ ಅವರು ಕೆಲವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಒಂದು ವಾರದವರೆಗೆ ಸುತ್ತಾಡುತ್ತಿದ್ದಾರೆ.
ಅಲೆಕ್ಸಾಂಡರ್ ಕೊವಾಲೆವ್ ಚಾಟ್‌ನಲ್ಲಿ ಸರಿಯಾಗಿ ಗಮನಿಸಿದಂತೆ, ಪರಸ್ಪರ ಸಂಬಂಧವು ಕಾರಣದಂತೆಯೇ ಅಲ್ಲ. ಇದು ಸತ್ಯ. ಅಂದರೆ, ನೀವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದ್ದರೆ, ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳು ಉತ್ತಮವಾಗಿರುತ್ತವೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ನೇರ ಸಂಪರ್ಕವಿಲ್ಲ. ಆದರೆ ಒಂದು ಸಕಾರಾತ್ಮಕ ಸಂಬಂಧವಿದೆ, ಒಬ್ಬರು ಒಂದಾಗಿದ್ದರೆ, ಹೆಚ್ಚಾಗಿ ಇನ್ನೊಂದು ಕೂಡ ಇರುತ್ತದೆ. ಸತ್ಯವಲ್ಲ, ಆದರೆ ಹೆಚ್ಚಾಗಿ. ಇದು ಕೇವಲ ಪರಸ್ಪರ ಸಂಬಂಧವಾಗಿದೆ.
ನಾವು ಈಗಾಗಲೇ ಏನನ್ನಾದರೂ ಮಾಡುತ್ತಿದ್ದೇವೆ ಎಂದು ತೋರುತ್ತದೆ, ನಾವು ಈಗಾಗಲೇ ವಿಲೀನಗೊಳ್ಳುತ್ತಿದ್ದೇವೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ನಾವು ಇನ್ನೂ ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಆಗಾಗ್ಗೆ ವಿಲೀನಗೊಳ್ಳುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾವು ಹೇಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು?
ಜೆಜ್ ಹಂಬಲ್ ಅವರು ಹ್ಯಾಂಡ್‌ಬುಕ್, ಆಕ್ಸಲರೇಟ್, ಕಂಟಿನ್ಯೂಯಸ್ ಡೆಲಿವರಿ ವೆಬ್‌ಸೈಟ್ ಮತ್ತು ನಿರಂತರ ವಿತರಣೆ ಪುಸ್ತಕದ ಲೇಖಕರಾಗಿದ್ದಾರೆ. ಅವರು ಈ ಪರೀಕ್ಷೆಯನ್ನು ನೀಡುತ್ತಾರೆ:
- ಇಂಜಿನಿಯರ್‌ನ ಕೋಡ್ ಪ್ರತಿದಿನ ಮಾಸ್ಟರ್‌ಗೆ ಸಿಗುತ್ತದೆ.
- ಪ್ರತಿ ಬದ್ಧತೆಗೆ ನೀವು ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತೀರಿ.
- ಮಾಸ್ಟರ್‌ನಲ್ಲಿನ ನಿರ್ಮಾಣವು ಕುಸಿಯಿತು, ಅದನ್ನು ಸುಮಾರು 10 ನಿಮಿಷಗಳಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗಿದೆ.
ನೀವು ಸಾಕಷ್ಟು ಅಭ್ಯಾಸವನ್ನು ಹೊಂದಿರುವಿರಾ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಈ ರೀತಿಯ ಪರೀಕ್ಷೆಯನ್ನು ಬಳಸಲು ಅವರು ಸಲಹೆ ನೀಡುತ್ತಾರೆ.
ನನಗೆ ಎರಡನೆಯದು ಸ್ವಲ್ಪ ವಿವಾದಾತ್ಮಕವಾಗಿದೆ. ಅಂದರೆ, ನೀವು ಅದನ್ನು 10 ನಿಮಿಷಗಳಲ್ಲಿ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾದರೆ, ನೀವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಇದು ಸ್ವಲ್ಪ ವಿಚಿತ್ರವಾಗಿದೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಆದರೆ ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಏಕೆ? ಏಕೆಂದರೆ ನೀವು ಆಗಾಗ್ಗೆ ಫ್ರೀಜ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಬದಲಾವಣೆಗಳು ಚಿಕ್ಕದಾಗಿದೆ ಎಂದರ್ಥ. ಒಂದು ಸಣ್ಣ ಬದಲಾವಣೆಯು ನಿಮ್ಮ ಮಾಸ್ಟರ್ ಬಿಲ್ಡ್ ಮುರಿದುಹೋಗಿದೆ ಎಂದರ್ಥವಾದರೆ, ಬದಲಾವಣೆಯು ಚಿಕ್ಕದಾಗಿರುವುದರಿಂದ ನೀವು ತ್ವರಿತವಾಗಿ ಉದಾಹರಣೆಯನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು. ಇಲ್ಲಿ ನೀವು ಸಣ್ಣ ವಿಲೀನವನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಅದರಲ್ಲಿ 20-30 ಸಾಲುಗಳು ಬದಲಾಗಿವೆ. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಕಾರಣ ಏನೆಂದು ನೀವು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು, ಏಕೆಂದರೆ ಬದಲಾವಣೆಗಳು ಚಿಕ್ಕದಾಗಿರುತ್ತವೆ, ಸಮಸ್ಯೆಯನ್ನು ಹುಡುಕಲು ನೀವು ಬಹಳ ಸಣ್ಣ ಪ್ರದೇಶವನ್ನು ಹೊಂದಿದ್ದೀರಿ.
ಮತ್ತು ಬಿಡುಗಡೆಯ ನಂತರ ನಮ್ಮ ಉತ್ಪನ್ನವು ಬೇರ್ಪಟ್ಟರೂ ಸಹ, ನಾವು ನಿರಂತರ ಏಕೀಕರಣದ ಅಭ್ಯಾಸವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಮಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಇದು ತುಂಬಾ ಸುಲಭ, ಏಕೆಂದರೆ ಬದಲಾವಣೆಗಳು ಚಿಕ್ಕದಾಗಿರುತ್ತವೆ. ಹೌದು, ಇದು ಯೋಜನೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಇದರಿಂದ ನೋವಾಗುತ್ತದೆ. ಮತ್ತು, ಬಹುಶಃ, ಈ ಅಭ್ಯಾಸದಲ್ಲಿ ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ವಿಷಯವೆಂದರೆ ಕಾರ್ಯಗಳನ್ನು ಒಡೆಯಲು ಒಗ್ಗಿಕೊಳ್ಳುವುದು, ಅಂದರೆ, ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು ಇದರಿಂದ ನೀವು ಏನನ್ನಾದರೂ ತೆಗೆದುಕೊಂಡು ಕೆಲವು ಗಂಟೆಗಳಲ್ಲಿ ಅದನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ವಿಮರ್ಶೆಯನ್ನು ರವಾನಿಸಬಹುದು. ನೀವು ಒಂದನ್ನು ಹೊಂದಿದ್ದೀರಿ. ವಿಮರ್ಶೆಯು ಪ್ರತ್ಯೇಕ ನೋವು.
ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳು ಕೇವಲ ಸಹಾಯಕವಾಗಿದ್ದು ಅದು ನಿಮ್ಮ ಏಕೀಕರಣ ಯಶಸ್ವಿಯಾಗಿದೆಯೇ ಮತ್ತು ಏನೂ ಮುರಿದುಹೋಗಿಲ್ಲವೇ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಕಡ್ಡಾಯವಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಅಭ್ಯಾಸದ ಅಂಶವಲ್ಲ.
ಇದು ನಿರಂತರ ಏಕೀಕರಣದ ಸಂಕ್ಷಿಪ್ತ ಪರಿಚಯವಾಗಿದೆ. ಈ ಅಭ್ಯಾಸವೂ ಅಷ್ಟೆ. ನಾನು ಪ್ರಶ್ನೆಗಳಿಗೆ ಸಿದ್ಧನಿದ್ದೇನೆ.
ನಾನು ಮತ್ತೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುತ್ತೇನೆ:
- ನಿರಂತರ ಏಕೀಕರಣವು ಜೆಂಕಿನ್ಸ್ ಅಲ್ಲ, ಇದು ಗಿಟ್ಲಾಬ್ ಅಲ್ಲ.
- ಇದು ಸಾಧನವಲ್ಲ, ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಾಗಿ ವಿಲೀನಗೊಳಿಸುವ ಅಭ್ಯಾಸವಾಗಿದೆ.
- ಭವಿಷ್ಯದಲ್ಲಿ ವಿಲೀನಗಳೊಂದಿಗೆ ಉಂಟಾಗುವ ಅಗಾಧವಾದ ನೋವನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ, ಅಂದರೆ, ಭವಿಷ್ಯದಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ಅನುಭವಿಸದಿರಲು ನಾವು ಈಗ ಸ್ವಲ್ಪ ನೋವನ್ನು ಅನುಭವಿಸುತ್ತೇವೆ. ಅದು ಸಂಪೂರ್ಣ ವಿಷಯವಾಗಿದೆ.
- ಬದಿಯಲ್ಲಿ ಕೋಡ್ ಮೂಲಕ ಸಂವಹನವಿದೆ, ಆದರೆ ನಾನು ಇದನ್ನು ಬಹಳ ವಿರಳವಾಗಿ ನೋಡುತ್ತೇನೆ, ಆದರೆ ಇದನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.
ಪ್ರಶ್ನೆಗಳು
ಕೊಳೆಯದ ಕಾರ್ಯಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು?
ಕೊಳೆಯಿರಿ. ಸಮಸ್ಯೆ ಏನು? ಕಾರ್ಯವಿದೆ ಮತ್ತು ಅದು ಕೊಳೆಯುವುದಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ನೀವು ಉದಾಹರಣೆ ನೀಡಬಹುದೇ?
"ಸಂಪೂರ್ಣವಾಗಿ" ಪದದಿಂದ ಕೊಳೆಯಲಾಗದ ಕಾರ್ಯಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, ಬಹಳ ಆಳವಾದ ಪರಿಣತಿಯ ಅಗತ್ಯವಿರುವ ಮತ್ತು ಕೆಲವು ಜೀರ್ಣಕಾರಿ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಲು ಒಂದು ತಿಂಗಳ ಅವಧಿಯಲ್ಲಿ ವಾಸ್ತವವಾಗಿ ಪರಿಹರಿಸಬಹುದು.
ನಾನು ನಿಮ್ಮನ್ನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಕೆಲವು ದೊಡ್ಡ ಮತ್ತು ಸಂಕೀರ್ಣವಾದ ಕಾರ್ಯವಿದೆ, ಅದರ ಫಲಿತಾಂಶವು ಕೇವಲ ಒಂದು ತಿಂಗಳಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆಯೇ?
ಹೌದು ಅದು ಸರಿ. ಹೌದು, ಒಂದು ತಿಂಗಳಿಗಿಂತ ಮುಂಚೆಯೇ ಫಲಿತಾಂಶವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಫೈನ್. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಸಮಸ್ಯೆಯಲ್ಲ. ಏಕೆ? ಏಕೆಂದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಕೊಂಬೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ನಾವು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿರುವ ಕೊಂಬೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ವೈಶಿಷ್ಟ್ಯಗಳು ದೊಡ್ಡದಾಗಿರಬಹುದು ಮತ್ತು ಸಂಕೀರ್ಣವಾಗಬಹುದು. ಅವರು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಘಟಕಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು. ಮತ್ತು ಬಹುಶಃ ನಾವು ಅವುಗಳನ್ನು ಒಂದು ಶಾಖೆಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಚೆನ್ನಾಗಿದೆ. ನಾವು ಈ ಕಥೆಯನ್ನು ಮುರಿಯಬೇಕಾಗಿದೆ. ವೈಶಿಷ್ಟ್ಯವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧವಾಗಿಲ್ಲದಿದ್ದರೆ, ಅದರ ಕೋಡ್‌ನ ಕೆಲವು ತುಣುಕುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ನೀವು ವಲಸೆಯನ್ನು ಸೇರಿಸಿದ್ದೀರಿ, ಹೇಳುತ್ತೀರಿ ಮತ್ತು ವೈಶಿಷ್ಟ್ಯದ ಒಳಗೆ ಕೆಲವು ಹಂತಗಳಿವೆ. ನೀವು ಒಂದು ಹಂತವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ - ವಲಸೆ ಮಾಡಿ, ಹೊಸ ವಿಧಾನವನ್ನು ಸೇರಿಸಿ. ಮತ್ತು ನೀವು ಈಗಾಗಲೇ ಪ್ರತಿದಿನ ಈ ವಿಷಯಗಳನ್ನು ಅಳೆಯಬಹುದು.
ಫೈನ್. ಹಾಗಾದರೆ ಏನು ಪ್ರಯೋಜನ?
ದಿನವೂ ಸಣ್ಣಪುಟ್ಟ ವಸ್ತುಗಳನ್ನು ಕೊಲ್ಲುವುದರಿಂದ ಏನು ಪ್ರಯೋಜನ?
ಹೌದು.
ಅವರು ಏನನ್ನಾದರೂ ಮುರಿದರೆ, ನೀವು ತಕ್ಷಣ ಅದನ್ನು ನೋಡುತ್ತೀರಿ. ನೀವು ಏನನ್ನಾದರೂ ಮುರಿದಿರುವ ಸಣ್ಣ ತುಂಡನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಅದನ್ನು ಸರಿಪಡಿಸಲು ನಿಮಗೆ ಸುಲಭವಾಗಿದೆ. ಕೆಲವು ವಾರಗಳಲ್ಲಿ ದೊಡ್ಡದನ್ನು ವಿಲೀನಗೊಳಿಸುವುದಕ್ಕಿಂತ ಈಗ ಸಣ್ಣ ತುಣುಕನ್ನು ವಿಲೀನಗೊಳಿಸುವುದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ಮತ್ತು ಮೂರನೇ ಅಂಶವೆಂದರೆ ಇತರ ಎಂಜಿನಿಯರ್‌ಗಳು ಕೋಡ್‌ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಇಲ್ಲಿ ಕೆಲವು ವಲಸೆಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ಅವರು ನೋಡುತ್ತಾರೆ, ಮತ್ತು ನಂತರ ಅವರು ಬಳಸಲು ಬಯಸುವ ಕೆಲವು ವಿಧಾನವು ಕಾಣಿಸಿಕೊಂಡಿದೆ. ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಎಲ್ಲರೂ ನೋಡುತ್ತಾರೆ. ಈ ಮೂರು ವಿಷಯಗಳಿಗಾಗಿಯೇ ಅಭ್ಯಾಸವನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.
ಧನ್ಯವಾದಗಳು, ಸಮಸ್ಯೆಯನ್ನು ಮುಚ್ಚಲಾಗಿದೆ!
(ಒಲೆಗ್ ಸೊರೊಕಾ) ನಾನು ಸೇರಿಸಬಹುದೇ? ನೀವು ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಹೇಳಿದ್ದೀರಿ, ನಾನು ಒಂದು ಪದಗುಚ್ಛವನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತೇನೆ.
So.
ನಿರಂತರ ಏಕೀಕರಣದೊಂದಿಗೆ, ವೈಶಿಷ್ಟ್ಯವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧವಾದಾಗ ಕೋಡ್ ಅನ್ನು ಸಾಮಾನ್ಯ ಶಾಖೆಯಾಗಿ ವಿಲೀನಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಬಿಲ್ಡ್ ಒಡೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿದಾಗ. ಮತ್ತು ನೀವು ದಿನಕ್ಕೆ ಎಷ್ಟು ಬಾರಿ ಬೇಕಾದರೂ ಮಾಸ್ಟರ್ ಮಾಡಲು ನೀವು ಸುರಕ್ಷಿತವಾಗಿ ಬದ್ಧರಾಗಬಹುದು. ಎರಡನೆಯ ಅಂಶವೆಂದರೆ, ಕೆಲವು ಕಾರಣಗಳಿಂದ ನೀವು ಮಾಸಿಕ ಕೆಲಸವನ್ನು ಕನಿಷ್ಠ ಮೂರು ದಿನಗಳವರೆಗೆ ಕಾರ್ಯಗಳಾಗಿ ಮುರಿಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಾನು ಸುಮಾರು ಮೂರು ಗಂಟೆಗಳ ಕಾಲ ಮೌನವಾಗಿರುತ್ತೇನೆ, ಆಗ ನಿಮಗೆ ದೊಡ್ಡ ಸಮಸ್ಯೆ ಇದೆ. ಮತ್ತು ನೀವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿಲ್ಲದಿರುವುದು ಈ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಕನಿಷ್ಠವಾಗಿದೆ. ಇದರರ್ಥ ನೀವು ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಶೂನ್ಯ ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಏಕೆಂದರೆ ಇದು ಸಂಶೋಧನೆಯಾಗಿದ್ದರೂ ಸಹ, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಅದನ್ನು ಕಲ್ಪನೆ ಅಥವಾ ಚಕ್ರದ ರೂಪದಲ್ಲಿ ರೂಪಿಸಬೇಕು.
ಯಶಸ್ವಿ ಕಂಪನಿಗಳನ್ನು ಹಿಂದುಳಿದವರಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ 4 ಮೆಟ್ರಿಕ್‌ಗಳ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡಿದ್ದೇವೆ. ಈ 4 ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನೋಡಲು ನಾವು ಇನ್ನೂ ಬದುಕಬೇಕು. ನಿಮ್ಮ ಸರಾಸರಿ ಕಾರ್ಯವು ಪೂರ್ಣಗೊಳ್ಳಲು ಒಂದು ತಿಂಗಳು ತೆಗೆದುಕೊಂಡರೆ, ನಾನು ಮೊದಲು ಈ ಮೆಟ್ರಿಕ್ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇನೆ. ನಾನು ಅದನ್ನು ಮೊದಲು 3 ದಿನಕ್ಕೆ ಇಳಿಸುತ್ತೇನೆ. ಮತ್ತು ಅದರ ನಂತರ ನಾನು ನಿರಂತರ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ.
ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಕೆಲಸವು ಪೂರ್ಣಗೊಳ್ಳಲು ಒಂದು ತಿಂಗಳು ತೆಗೆದುಕೊಂಡರೆ ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ ಎಂದು ನಾನು ನಿಮಗೆ ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆಯೇ?
ನೀವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಮತ್ತು ಅಂತಹ ಒಂದು ವಿಷಯವಿದೆ, 10 ನಿಮಿಷಗಳಲ್ಲಿ ನೀವು ಫಿಕ್ಸ್ ಅನ್ನು ಸರಿಪಡಿಸಬಹುದು ಅಥವಾ ಅದನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ನೀವು ಅದನ್ನು ಹೊರತೆಗೆದಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಇದಲ್ಲದೆ, ನೀವು ನಿರಂತರ ನಿಯೋಜನೆಯನ್ನು ಸಹ ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಅದನ್ನು ಉತ್ಪನ್ನಕ್ಕೆ ಹೊರತೆಗೆದಿದ್ದೀರಿ ಮತ್ತು ಆಗ ಮಾತ್ರ ಏನೋ ತಪ್ಪಾಗಿದೆ ಎಂದು ಗಮನಿಸಿದ್ದೀರಿ. ಮತ್ತು ನೀವು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕಾಗಿದೆ, ಆದರೆ ನೀವು ಈಗಾಗಲೇ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ್ದೀರಿ. ನೀವು ಈಗಾಗಲೇ ಮುಂದಿನ ಆವೃತ್ತಿಯ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾವನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಮೇಲಾಗಿ, ನೀವು ಕೆಲವು ರೀತಿಯ ಬ್ಯಾಕಪ್ ಅನ್ನು ಸಹ ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಡೇಟಾವನ್ನು ಅಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ.
ಮತ್ತು ನೀವು ಯಾವ ಪರ್ಯಾಯವನ್ನು ಹೊಂದಿದ್ದೀರಿ? ನೀವು ಕೋಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ಈ ನವೀಕರಿಸಿದ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಅದು ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.
ಬೇಸ್ ಮಾತ್ರ ಮುಂದಕ್ಕೆ ಚಲಿಸುತ್ತದೆ, ಹೌದು.
ಕಳಪೆ ಎಂಜಿನಿಯರಿಂಗ್ ಅಭ್ಯಾಸಗಳನ್ನು ಹೊಂದಿರುವ ಜನರು ಹೆಚ್ಚಾಗಿ ದಪ್ಪ ಪುಸ್ತಕವನ್ನು ಓದಿಲ್ಲ ... ಬ್ಯಾಕ್‌ಅಪ್‌ನೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು? ನೀವು ಬ್ಯಾಕಪ್‌ನಿಂದ ಮರುಸ್ಥಾಪಿಸಿದರೆ, ಆ ಕ್ಷಣದಲ್ಲಿ ನೀವು ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾವನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ ಎಂದರ್ಥ. ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯೊಂದಿಗೆ ನಾವು ಮೂರು ಗಂಟೆಗಳ ಕಾಲ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ, ಬಳಕೆದಾರರು ಅಲ್ಲಿ ನೋಂದಾಯಿಸಿದ್ದಾರೆ. ನೀವು ಹಳೆಯ ಬ್ಯಾಕಪ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತೀರಿ ಏಕೆಂದರೆ ಸ್ಕೀಮ್ ಹೊಸ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಈ ಬಳಕೆದಾರರನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಿ. ಮತ್ತು ಅವರು ಅತೃಪ್ತರಾಗಿದ್ದಾರೆ, ಅವರು ಪ್ರತಿಜ್ಞೆ ಮಾಡುತ್ತಾರೆ.
ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ನಿರಂತರ ವಿತರಣೆಯನ್ನು ಬೆಂಬಲಿಸುವ ಸಂಪೂರ್ಣ ಶ್ರೇಣಿಯ ಅಭ್ಯಾಸಗಳನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳಲು, ಹೇಗೆ ಬರೆಯಬೇಕೆಂದು ಕಲಿಯುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಮೊದಲನೆಯದಾಗಿ, ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇರಬಹುದು, ಅದು ಅಪ್ರಾಯೋಗಿಕವಾಗಿರುತ್ತದೆ. ಜೊತೆಗೆ ವೈಜ್ಞಾನಿಕ ರೀತಿಯ ಇತರ ಅಭ್ಯಾಸಗಳ ಗುಂಪೂ ಇವೆ. ಅಂತಹ ಅಭ್ಯಾಸವಿದೆ, GitHub ಒಂದು ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಜನಪ್ರಿಯಗೊಳಿಸಿತು. ನೀವು ಹಳೆಯ ಕೋಡ್ ಮತ್ತು ಹೊಸ ಕೋಡ್ ಎರಡನ್ನೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ನೀವು ಅಪೂರ್ಣ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮಾಡಿದಾಗ, ಆದರೆ ಇದು ಕೆಲವು ಮೌಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು: ಕಾರ್ಯವಾಗಿ ಅಥವಾ ವಿಶ್ರಾಂತಿ API ಆಗಿ. ನೀವು ಹೊಸ ಕೋಡ್ ಮತ್ತು ಹಳೆಯ ಕೋಡ್ ಎರಡನ್ನೂ ಕಾರ್ಯಗತಗೊಳಿಸಿ ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ. ಮತ್ತು ವ್ಯತ್ಯಾಸವಿದ್ದರೆ, ನೀವು ಈ ಈವೆಂಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ. ಈ ರೀತಿಯಾಗಿ ನೀವು ನಿರ್ದಿಷ್ಟ ಸಮಯದವರೆಗೆ ಎರಡರ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಹಳೆಯದಕ್ಕಿಂತ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊರತರಲು ಸಿದ್ಧವಾಗಿರುವಿರಿ ಎಂದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.
ಇಂತಹ ನೂರಾರು ಆಚರಣೆಗಳಿವೆ. ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಅವಳು ನಿರಂತರ ಏಕೀಕರಣದಲ್ಲಿ 100% ಅಲ್ಲ, ಆದರೆ ಅಭ್ಯಾಸಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ, ಒಬ್ಬರು ಇನ್ನೊಬ್ಬರು ಇಲ್ಲದೆ ಚೆನ್ನಾಗಿ ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನೀವು ಅಭ್ಯಾಸಗಳನ್ನು ನೋಡಬಹುದಾದ ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಅಭಿವೃದ್ಧಿಯನ್ನು ಉದಾಹರಣೆಯಾಗಿ ನೀಡಿದ್ದೀರಾ ಅಥವಾ ಜನರು ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಡಿಬೆಲೋಪ್‌ಮೆಂಟ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಾ?
ಒಮ್ಮೆ ನೋಡಿ, ಏಕೆಂದರೆ ಅವರು ಅದನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಅವುಗಳನ್ನು ಬಳಸಲು, ನೀವು ಬಹಳಷ್ಟು ಓದಬೇಕು. ಮತ್ತು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಕೇಳಿದಾಗ: "ಒಂದು ತಿಂಗಳು ತೆಗೆದುಕೊಳ್ಳುವ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಏನು ಮಾಡಬೇಕೆಂದು, ಅವನು ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ ಓದಿಲ್ಲ ಎಂದರ್ಥ." ನಾನು ಅದನ್ನು ಇನ್ನೂ ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ. ದೊಡ್ಡ ಕಾರ್ಯಗಳನ್ನು ಚಿಕ್ಕದಾಗಿ ವಾಸ್ತುಶಿಲ್ಪೀಯವಾಗಿ ಸರಿಯಾಗಿ ಒಡೆಯುವುದು ಹೇಗೆ ಎಂಬ ವಿಷಯದ ಮೇಲೆ ಮಾತ್ರ ಕೇಂದ್ರೀಕರಿಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಇದು ವಿಘಟನೆಯ ಸಾರವಾಗಿದೆ.
ವಿಘಟನೆಯು ವಾಸ್ತುಶಿಲ್ಪಿಗಳ ಸಾಧನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾವು ಮೊದಲು ವಿಶ್ಲೇಷಣೆ ಮಾಡುತ್ತೇವೆ, ನಂತರ ವಿಭಜನೆ, ನಂತರ ಸಂಶ್ಲೇಷಣೆ, ನಂತರ ಏಕೀಕರಣ. ಮತ್ತು ಈ ರೀತಿ ಎಲ್ಲವೂ ನಮಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮತ್ತು ನಾವು ಇನ್ನೂ ವಿಭಜನೆಯ ಮೂಲಕ ನಿರಂತರ ಏಕೀಕರಣಕ್ಕೆ ಬೆಳೆಯಬೇಕಾಗಿದೆ. ಮೊದಲ ಹಂತದಲ್ಲಿ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ, ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ನಾಲ್ಕನೇ ಹಂತದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಅಂದರೆ ನಾವು ಹೆಚ್ಚಾಗಿ ಏಕೀಕರಣವನ್ನು ಮಾಡುತ್ತೇವೆ, ಉತ್ತಮ. ಇದನ್ನು ಮಾಡಲು ಇನ್ನೂ ಮುಂಚೆಯೇ; ನಿಮ್ಮ ಏಕಶಿಲೆಯನ್ನು ಮೊದಲು ಕತ್ತರಿಸುವುದು ಒಳ್ಳೆಯದು.
ಕೆಲವು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ನೀವು ಹಲವಾರು ಬಾಣಗಳು ಮತ್ತು ಚೌಕಗಳನ್ನು ಸೆಳೆಯಬೇಕಾಗಿದೆ. ಈಗ ನಾನು ಹೊಸ ಅಪ್ಲಿಕೇಶನ್‌ನ ವಾಸ್ತುಶಿಲ್ಪದ ರೇಖಾಚಿತ್ರವನ್ನು ತೋರಿಸುತ್ತೇನೆ ಮತ್ತು ಒಂದು ಚೌಕವನ್ನು ತೋರಿಸುತ್ತೇನೆ ಎಂದು ನೀವು ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಅದರೊಳಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹಸಿರು ಬಟನ್ ಇದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಹೆಚ್ಚು ಚೌಕಗಳು ಮತ್ತು ಬಾಣಗಳು ಇರುತ್ತದೆ. ನಾನು ನೋಡಿದ ಪ್ರತಿ ರೇಖಾಚಿತ್ರವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಿತ್ತು. ಮತ್ತು ವಿಘಟನೆ, ಚಿತ್ರಾತ್ಮಕ ಪ್ರಾತಿನಿಧ್ಯದ ಮಟ್ಟದಲ್ಲಿಯೂ ಸಹ, ಈಗಾಗಲೇ ನಡೆಯುತ್ತಿದೆ. ಆದ್ದರಿಂದ, ಚೌಕಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಮಾಡಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ವಾಸ್ತುಶಿಲ್ಪಿಗೆ ನನ್ನ ಬಳಿ ದೊಡ್ಡ ಪ್ರಶ್ನೆಗಳಿವೆ.
ಚಾಟ್‌ನಿಂದ ಒಂದು ಪ್ರಶ್ನೆಯಿದೆ: "ವಿಮರ್ಶೆಯು ಕಡ್ಡಾಯವಾಗಿದ್ದರೆ ಮತ್ತು ದೀರ್ಘ ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ, ಬಹುಶಃ ಒಂದು ದಿನ ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ?"
ಅಭ್ಯಾಸದಲ್ಲಿ ನಿಮಗೆ ಸಮಸ್ಯೆಗಳಿವೆ. ವಿಮರ್ಶೆಯು ಒಂದು ದಿನ ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಇರಬಾರದು. ಇದು ಹಿಂದಿನ ಪ್ರಶ್ನೆಗೆ ಅದೇ ಕಥೆ, ಸ್ವಲ್ಪ ಮೃದುವಾಗಿರುತ್ತದೆ. ವಿಮರ್ಶೆಯು ಒಂದು ದಿನದವರೆಗೆ ಮುಂದುವರಿದರೆ, ಹೆಚ್ಚಾಗಿ ಈ ವಿಮರ್ಶೆಯು ಕೆಲವು ದೊಡ್ಡ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುತ್ತಿದೆ. ಇದರರ್ಥ ಅದನ್ನು ಚಿಕ್ಕದಾಗಿ ಮಾಡಬೇಕಾಗಿದೆ. ಒಲೆಗ್ ಶಿಫಾರಸು ಮಾಡಿದ ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ನಿರಂತರ ವಿಮರ್ಶೆ ಎಂಬ ಕಥೆ ಇದೆ. ನಾವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಇಂತಹ ಸಣ್ಣ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತೇವೆ ಎಂಬುದು ಅವಳ ಕಲ್ಪನೆ, ಏಕೆಂದರೆ ನಾವು ನಿರಂತರವಾಗಿ ಮತ್ತು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ವಿಲೀನಗೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ ಪುಲ್ ವಿನಂತಿಯು ಒಂದು ಅಮೂರ್ತತೆ ಅಥವಾ 10 ಸಾಲುಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಈ ವಿಮರ್ಶೆಗೆ ಧನ್ಯವಾದಗಳು, ಇದು ನಮಗೆ ಒಂದೆರಡು ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಪರಿಶೀಲನೆಯು ಒಂದು ದಿನ ಅಥವಾ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಏನೋ ತಪ್ಪಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ನೀವು ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಅಥವಾ ಇದು ದೊಡ್ಡ ತುಂಡು ಕೋಡ್, 1 ಸಾಲುಗಳು, ಉದಾಹರಣೆಗೆ. ಅಥವಾ ನಿಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪವು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಿದೆ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಸ್ವಲ್ಪ ಪಕ್ಕದ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಆದರೆ ಇದನ್ನು ಸಹ ಪರಿಹರಿಸಬೇಕಾಗಿದೆ. ಬಹುಶಃ ವಿಮರ್ಶೆಯ ಅಗತ್ಯವಿಲ್ಲ. ಈ ಬಗ್ಗೆಯೂ ನಾವು ಯೋಚಿಸಬೇಕಾಗಿದೆ. ವಿಮರ್ಶೆಯು ನಿಮ್ಮನ್ನು ನಿಧಾನಗೊಳಿಸುವ ವಿಷಯವಾಗಿದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅದರ ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ನೀವು ಅದನ್ನು ಏಕೆ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಮಾಹಿತಿಯನ್ನು ತ್ವರಿತವಾಗಿ ತಿಳಿಸಲು ಇದು ನಿಮಗೆ ಒಂದು ಮಾರ್ಗವೇ, ಆಂತರಿಕವಾಗಿ ಕೆಲವು ಮಾನದಂಡಗಳನ್ನು ಹೊಂದಿಸಲು ಇದು ಒಂದು ಮಾರ್ಗವೇ ಅಥವಾ ಏನು? ನಿಮಗೆ ಇದು ಏಕೆ ಬೇಕು? ಏಕೆಂದರೆ ಪರಿಶೀಲನೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಮಾಡಬೇಕಾಗಿದೆ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ರದ್ದುಗೊಳಿಸಬೇಕಾಗಿದೆ. ಇದು ಟ್ರಾನ್ಸ್‌ಬೇಸ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಂತಿದೆ - ಕಥೆ ತುಂಬಾ ಸುಂದರವಾಗಿದೆ, ಆದರೆ ಪ್ರಬುದ್ಧ ಹುಡುಗರಿಗೆ ಮಾತ್ರ.
4 ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ಏನು ಕಾರಣವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ನಾನು ಇನ್ನೂ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಸಂಖ್ಯೆಗಳನ್ನು ನೋಡಿ, ಚಿತ್ರವನ್ನು ನೋಡಿ, ಎಲ್ಲವೂ ಎಷ್ಟು ಕೆಟ್ಟದಾಗಿದೆ.
(ಡಿಮಿಟ್ರಿ) ನಾನು ನಿಮ್ಮೊಂದಿಗೆ ಈ ಬಗ್ಗೆ ಚರ್ಚೆಗೆ ಪ್ರವೇಶಿಸಲು ಸಿದ್ಧನಿದ್ದೇನೆ. ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿವೆ, ಅಭ್ಯಾಸಗಳು ಉತ್ತಮವಾಗಿವೆ. ಆದರೆ ವ್ಯವಹಾರಕ್ಕೆ ಇದು ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಆ ರೀತಿಯ ಬದಲಾವಣೆಯ ವೇಗದ ಅಗತ್ಯವಿಲ್ಲದ ವ್ಯವಹಾರಗಳಿವೆ. ಪ್ರತಿ 15 ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗದ ಕಂಪನಿಗಳು ನನಗೆ ಗೊತ್ತು. ಮತ್ತು ಅವರು ತುಂಬಾ ಕೆಟ್ಟವರಾಗಿರುವುದರಿಂದ ಅಲ್ಲ. ಇದು ಅಂತಹ ಜೀವನ ಚಕ್ರ. ಮತ್ತು ಶಾಖೆಗಳನ್ನು ವೈಶಿಷ್ಟ್ಯಗೊಳಿಸಲು, ಟಾಗಲ್ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮಾಡಲು, ನಿಮಗೆ ಆಳವಾದ ಜ್ಞಾನದ ಅಗತ್ಯವಿದೆ.
ತುಂಬ ಸಂಕೀರ್ಣವಾಗಿದೆ. ಟಾಗಲ್ ವೈಶಿಷ್ಟ್ಯದ ಕುರಿತು ನೀವು ಕಥೆಯನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಓದಲು ಬಯಸಿದರೆ, ನಾನು ಅದನ್ನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ . ಮತ್ತು ಟಾಗಲ್ ವೈಶಿಷ್ಟ್ಯಗಳ ಬಗ್ಗೆ ಮಾರ್ಟಿನ್ ಫೌಲರ್ ಅವರ ಅದ್ಭುತ ಲೇಖನವಿದೆ: ಯಾವ ಪ್ರಕಾರಗಳಿವೆ, ಜೀವನ ಚಕ್ರಗಳು, ಇತ್ಯಾದಿ. ಟಾಗಲ್ ವೈಶಿಷ್ಟ್ಯವು ಸಂಕೀರ್ಣವಾಗಿದೆ.
ಮತ್ತು ನೀವು ಇನ್ನೂ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಿಲ್ಲ: "ಜೆಂಕಿನ್ಸ್ ಅಗತ್ಯವಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ?"
ಜೆಂಕಿನ್ಸ್ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿಲ್ಲ. ಗಂಭೀರವಾಗಿ ಆದರೂ, ಉಪಕರಣಗಳು: ಜೆಂಕಿನ್ಸ್, ಗಿಟ್ಲಾಬ್ ನಿಮಗೆ ಅನುಕೂಲವನ್ನು ತರುತ್ತದೆ. ಅಸೆಂಬ್ಲಿಯನ್ನು ಜೋಡಿಸಲಾಗಿದೆ ಅಥವಾ ಜೋಡಿಸಲಾಗಿಲ್ಲ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ. ಅವರು ನಿಮಗೆ ಸಹಾಯ ಮಾಡಬಹುದು, ಆದರೆ ಅವರು ನಿಮಗೆ ಅಭ್ಯಾಸವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಅವರು ನಿಮಗೆ ವೃತ್ತವನ್ನು ಮಾತ್ರ ನೀಡಬಹುದು - ಸರಿ, ಸರಿ ಅಲ್ಲ. ತದನಂತರ, ನೀವು ಪರೀಕ್ಷೆಗಳನ್ನು ಸಹ ಬರೆದರೆ, ಏಕೆಂದರೆ ಯಾವುದೇ ಪರೀಕ್ಷೆಗಳಿಲ್ಲದಿದ್ದರೆ, ಅದು ಬಹುತೇಕ ಅರ್ಥಹೀನವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿರುವುದರಿಂದ ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಇಲ್ಲದೆ ಬದುಕಬಹುದು, ನೀವು ಹೆಚ್ಚು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.
ಅಂದರೆ, ನೀವು ಅಭ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ನಿಮಗೆ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಅರ್ಥವೇ?
ಅದು ಸರಿ. ನಾನು ಜೆಜ್ ಹಂಬಲ್ ಪರೀಕ್ಷೆಯನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಅಲ್ಲಿ ನಾನು ಕೊನೆಯ ಹಂತದ ಬಗ್ಗೆ ದ್ವಂದ್ವಾರ್ಥ ಮನೋಭಾವವನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಮೂರು ವಿಷಯಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ನಿರಂತರವಾಗಿ ವಿಲೀನಗೊಳ್ಳುತ್ತೀರಿ, ನೀವು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಕಮಿಟ್‌ಗಳ ಮೇಲೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತೀರಿ, ನೀವು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ತ್ವರಿತವಾಗಿ ನಿರ್ಮಾಣವನ್ನು ಸರಿಪಡಿಸುತ್ತೀರಿ, ಆಗ ನಿಮಗೆ ಬೇರೆ ಏನೂ ಅಗತ್ಯವಿಲ್ಲ.
ಭಾಗವಹಿಸುವವರ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ ನಾವು ಕಾಯುತ್ತಿರುವಾಗ, ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆಯಿದೆ. ನಾವು ಕೇವಲ ಉತ್ಪನ್ನ ಕೋಡ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ನೀವು ಅದನ್ನು ಮೂಲಸೌಕರ್ಯ ಕೋಡ್‌ಗಾಗಿ ಬಳಸಿದ್ದೀರಾ? ಇದು ಒಂದೇ ಕೋಡ್, ಇದು ಒಂದೇ ತತ್ವಗಳು ಮತ್ತು ಅದೇ ಜೀವನ ಚಕ್ರವನ್ನು ಹೊಂದಿದೆಯೇ ಅಥವಾ ವಿಭಿನ್ನ ಜೀವನ ಚಕ್ರಗಳು ಮತ್ತು ತತ್ವಗಳಿವೆಯೇ? ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲರೂ ನಿರಂತರ ಏಕೀಕರಣ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಕೂಡ ಇದೆ ಎಂಬುದನ್ನು ಎಲ್ಲರೂ ಮರೆತುಬಿಡುತ್ತಾರೆ. ಮತ್ತು ಇತ್ತೀಚೆಗೆ ಇದು ಹೆಚ್ಚು ಹೆಚ್ಚು ಕಂಡುಬಂದಿದೆ. ಮತ್ತು ಈ ಎಲ್ಲಾ ನಿಯಮಗಳನ್ನು ಅಲ್ಲಿಗೆ ತರಬೇಕೇ?
ಅದು ಇರಬಾರದು, ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ಜೀವನವನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ನಾವು ಕೋಡ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ ತಕ್ಷಣ, ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳೊಂದಿಗೆ ಅಲ್ಲ, ಆದರೆ ನಾವು ಸಾಮಾನ್ಯ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ನಿಲ್ಲಿಸು, ನಿಲ್ಲಿಸು, ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಕೂಡ ಕೋಡ್ ಆಗಿದೆ. ನನ್ನ ಹಳೆಯ ಪ್ರೀತಿಯನ್ನು ಮುಟ್ಟಬೇಡ.
ಸರಿ, ನಾನು ನಿನ್ನ ನೆನಪುಗಳನ್ನು ತುಳಿಯುವುದಿಲ್ಲ. ನನಗೆ ಬ್ಯಾಷ್ ಬಗ್ಗೆ ವೈಯಕ್ತಿಕ ಅಸಹ್ಯವಿದೆ. ಇದು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಕೊಳಕು ಮತ್ತು ಭಯಾನಕವಾಗಿ ಒಡೆಯುತ್ತದೆ. ಮತ್ತು ಇದು ಆಗಾಗ್ಗೆ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಒಡೆಯುತ್ತದೆ, ಅದಕ್ಕಾಗಿಯೇ ನಾನು ಅದನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ. ಆದರೆ ಸರಿ, ನಿಮ್ಮ ಬಳಿ ಬ್ಯಾಷ್ ಕೋಡ್ ಇದೆ ಎಂದು ಹೇಳೋಣ. ಬಹುಶಃ ನನಗೆ ನಿಜವಾಗಿಯೂ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ಮತ್ತು ಅಲ್ಲಿ ಸಾಮಾನ್ಯ ಪರೀಕ್ಷಾ ಚೌಕಟ್ಟುಗಳಿವೆ. ನನಗೆ ಗೊತ್ತೇ ಇಲ್ಲ. ಮತ್ತು ನಾವು ಅದೇ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ.
ನಾವು ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಂತೆ ಕೆಲಸ ಮಾಡಿದ ತಕ್ಷಣ, ನಾವು ಡೆವಲಪರ್‌ಗಳಂತೆಯೇ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ. ಕೆಲವು ತಿಂಗಳ ಹಿಂದೆ, ಸಹೋದ್ಯೋಗಿಯೊಬ್ಬರು ನನಗೆ ಬ್ಯಾಷ್‌ನಲ್ಲಿ 1 ಸಾಲುಗಳಿಗಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾನು ಎದುರಿಸಿದೆ. ಮತ್ತು ನೀವು ವಿಮರ್ಶೆಯಲ್ಲಿ 000 ಗಂಟೆಗಳ ಕಾಲ ಸುತ್ತಾಡುತ್ತೀರಿ. ಅದೇ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ. ಇದು ಇನ್ನೂ ಕೋಡ್ ಆಗಿದೆ. ಮತ್ತು ಇದು ಇನ್ನೂ ಸಹಯೋಗವಾಗಿದೆ. ನಾವು ಪುಲ್ ವಿನಂತಿಯೊಂದಿಗೆ ಸಿಲುಕಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ನಾವು ಅದೇ ಬ್ಯಾಷ್‌ನಲ್ಲಿ ಅದೇ ವಿಲೀನ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ನಾವು ಸಿಲುಕಿಕೊಳ್ಳುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ.
ನಾನು ಈಗ ಅತ್ಯಂತ ಸುಂದರವಾದ ಇನ್‌ಫ್ರಾ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ಈ ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ಬಹಳ ಸಕ್ರಿಯವಾಗಿ ನೋಡುತ್ತಿದ್ದೇನೆ. ನಾನು ಈಗ ಪುಲುಮಿಯನ್ನು ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ತಂದಿದ್ದೇನೆ. ಇದು ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಆಗಿದೆ. ಅಲ್ಲಿ ಅದು ಇನ್ನೂ ಉತ್ತಮವಾಗಿದೆ, ಏಕೆಂದರೆ ನಾನು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ, ಅಂದರೆ ನಾನು ಅದೇ ifs ನೊಂದಿಗೆ ನೀಲಿ ಬಣ್ಣವನ್ನು ಸುಂದರವಾಗಿ ಟಾಗಲ್ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಅಂದರೆ, ನನ್ನ ಬದಲಾವಣೆ ಈಗಾಗಲೇ ಮಾಸ್ಟರ್ನಲ್ಲಿದೆ. ಎಲ್ಲರೂ ಈಗಾಗಲೇ ಅವನನ್ನು ನೋಡಬಹುದು. ಇತರ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಅದರ ಬಗ್ಗೆ ತಿಳಿದಿದೆ. ಇದು ಈಗಾಗಲೇ ಅಲ್ಲಿ ಏನನ್ನಾದರೂ ಪ್ರಭಾವಿಸಿದೆ. ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಮೂಲಸೌಕರ್ಯಗಳಿಗೆ ಇದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿಲ್ಲ. ಇದು ನನ್ನ ಪರೀಕ್ಷಾ ಬೆಂಚುಗಳಿಗಾಗಿ ಆನ್ ಮಾಡಿದೆ, ಉದಾಹರಣೆಗೆ. ಆದ್ದರಿಂದ, ನಿಮ್ಮ ಪ್ರಶ್ನೆಗೆ ಮತ್ತೊಮ್ಮೆ ಉತ್ತರಿಸಲು, ಇದು ಅವಶ್ಯಕವಾಗಿದೆ. ಕೋಡ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಎಂಜಿನಿಯರ್‌ಗಳಂತೆ ಇದು ನಮಗೆ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
ಬೇರೆ ಯಾರಾದರೂ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ?
ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆ ಇದೆ. ನಾನು ಒಲೆಗ್ ಅವರೊಂದಿಗೆ ಚರ್ಚೆಯನ್ನು ಮುಂದುವರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಹೇಳಿದ್ದು ಸರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಒಂದು ಕಾರ್ಯವು ಪೂರ್ಣಗೊಳ್ಳಲು ಒಂದು ತಿಂಗಳು ತೆಗೆದುಕೊಂಡರೆ, ನಿಮಗೆ ವಾಸ್ತುಶಾಸ್ತ್ರದಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ, ನಿಮಗೆ ವಿಶ್ಲೇಷಣೆ, ವಿಭಜನೆ, ಯೋಜನೆ ಇತ್ಯಾದಿಗಳ ಸಮಸ್ಯೆ ಇದೆ. ಆದರೆ ನೀವು ಪ್ರಾರಂಭಿಸಿದರೆ ಎಂಬ ಭಾವನೆ ನನ್ನಲ್ಲಿದೆ. ನಿರಂತರ ಏಕೀಕರಣದ ಪ್ರಕಾರ ಲೈವ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ, ನಂತರ ನೀವು ಯೋಜನೆಯೊಂದಿಗೆ ನೋವನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ, ಏಕೆಂದರೆ ನೀವು ಬೇರೆಲ್ಲಿಯೂ ಅದರಿಂದ ದೂರವಾಗುವುದಿಲ್ಲ.
(ಒಲೆಗ್) ಹೌದು, ಅದು ಸರಿ. ಈ ಅಭ್ಯಾಸವು ಯಾವುದೇ ಗಂಭೀರ ಸಂಸ್ಕೃತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಅಭ್ಯಾಸಕ್ಕೆ ಹೋಲಿಸಬಹುದು. ಜಯಿಸಲು ಕಠಿಣ ವಿಷಯವೆಂದರೆ ಅಭ್ಯಾಸಗಳು, ವಿಶೇಷವಾಗಿ ಕೆಟ್ಟ ಅಭ್ಯಾಸಗಳು. ಮತ್ತು ಈ ಅಭ್ಯಾಸವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನಿಮ್ಮ ಸುತ್ತಲಿರುವವರ ಅಭ್ಯಾಸದಲ್ಲಿ ಗಂಭೀರ ಬದಲಾವಣೆಯ ಅಗತ್ಯವಿದ್ದರೆ: ಡೆವಲಪರ್‌ಗಳು, ನಿರ್ವಹಣೆ, ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥಾಪಕ, ನಂತರ ಆಶ್ಚರ್ಯಗಳು ನಿಮಗೆ ಕಾಯುತ್ತಿವೆ.
ಯಾವ ಆಶ್ಚರ್ಯಗಳು ಇರಬಹುದು? ನೀವು ಹೆಚ್ಚಾಗಿ ಸಂಯೋಜಿಸುವಿರಿ ಎಂದು ನೀವು ನಿರ್ಧರಿಸುತ್ತೀರಿ ಎಂದು ಹೇಳೋಣ. ಮತ್ತು ನೀವು ಏಕೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ಇತರ ವಿಷಯಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಉದಾಹರಣೆಗೆ, ಕಲಾಕೃತಿಗಳು. ಮತ್ತು ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಕಲಾಕೃತಿಯನ್ನು ಕೆಲವು ರೀತಿಯ ಕಲಾಕೃತಿ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಲೆಕ್ಕ ಹಾಕಬೇಕು ಎಂಬ ನೀತಿ ಇದೆ. ಮತ್ತು ಇದು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಿಡುಗಡೆಗೆ ಸಿದ್ಧವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರಾಗಿ ಈ ಕಲಾಕೃತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದಾರೆ ಎಂಬ ಪೆಟ್ಟಿಗೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಅಗತ್ಯವಿದೆ. ಇದು 5-10-15 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಆದರೆ ನೀವು ವಾರಕ್ಕೊಮ್ಮೆ ಲೇಔಟ್ ಮಾಡಿದರೆ, ವಾರಕ್ಕೊಮ್ಮೆ ಅರ್ಧ ಗಂಟೆ ಖರ್ಚು ಮಾಡುವುದು ಸಣ್ಣ ತೆರಿಗೆಯಾಗಿದೆ.
ನೀವು ದಿನಕ್ಕೆ 10 ಬಾರಿ ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಮಾಡಿದರೆ, ನಂತರ 10 ಬಾರಿ 30 ನಿಮಿಷಗಳಿಂದ ಗುಣಿಸಬೇಕಾಗಿದೆ. ಮತ್ತು ಇದು ಈ ಬಿಡುಗಡೆ ವ್ಯವಸ್ಥಾಪಕರ ಕೆಲಸದ ಸಮಯವನ್ನು ಮೀರಿದೆ. ಅವನು ಅದನ್ನು ಮಾಡಲು ಸುಸ್ತಾಗುತ್ತಾನೆ. ಕೆಲವು ಅಭ್ಯಾಸಗಳಿಗೆ ನಿಶ್ಚಿತ ವೆಚ್ಚಗಳಿವೆ. ಅಷ್ಟೇ.
ಮತ್ತು ನೀವು ಈ ನಿಯಮವನ್ನು ರದ್ದುಗೊಳಿಸಬೇಕು ಇದರಿಂದ ನೀವು ಇನ್ನು ಮುಂದೆ ಅಂತಹ ಕಸವನ್ನು ಮಾಡಬಾರದು, ಅಂದರೆ ನೀವು ಯಾವುದನ್ನಾದರೂ ಹೊಂದಿಕೆಯಾಗಲು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪದವಿಯನ್ನು ನಿಯೋಜಿಸುವುದಿಲ್ಲ. ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲವು ಸ್ವಯಂಚಾಲಿತ ಸಿದ್ಧತೆ ಪರೀಕ್ಷೆಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಿದ್ದೀರಿ.
ಮತ್ತು ನಿಮಗೆ ಯಾರೊಂದಿಗಾದರೂ ಪುರಾವೆ ಬೇಕಾದರೆ, ಬಾಸ್ ಅದಕ್ಕೆ ಸಹಿ ಹಾಕುತ್ತಾನೆ ಮತ್ತು ವಾಸ್ಯಾ ಅವರು ಅದನ್ನು ಅನುಮತಿಸುತ್ತಾರೆ ಎಂದು ಹೇಳದೆ ನೀವು ಉತ್ಪಾದನೆಗೆ ಬರುವುದಿಲ್ಲ, ಇತ್ಯಾದಿ - ಈ ಎಲ್ಲಾ ಅಸಂಬದ್ಧತೆಯು ವೈದ್ಯರ ದಾರಿಯಲ್ಲಿ ಸಿಗುತ್ತದೆ. ಏಕೆಂದರೆ ತೆರಿಗೆಗೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ಚಟುವಟಿಕೆಗಳು ಇದ್ದರೆ, ನಂತರ ಎಲ್ಲವೂ 100 ಪಟ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಶಿಫ್ಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲರೂ ಸಂತೋಷದಿಂದ ಸ್ವಾಗತಿಸುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಜನರ ಅಭ್ಯಾಸಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಕಷ್ಟ.
ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ತನ್ನ ಸಾಮಾನ್ಯ ಕೆಲಸವನ್ನು ಮಾಡಿದಾಗ, ಅವನು ಅದನ್ನು ಯೋಚಿಸದೆಯೇ ಮಾಡುತ್ತಾನೆ. ಅವಳ ಅರಿವಿನ ಹೊರೆ ಶೂನ್ಯವಾಗಿರುತ್ತದೆ. ಅವನು ಅದರೊಂದಿಗೆ ಆಡುತ್ತಾನೆ, ಅವನ ತಲೆಯಲ್ಲಿ ಈಗಾಗಲೇ ಪರಿಶೀಲನಾಪಟ್ಟಿ ಇದೆ, ಅವನು ಅದನ್ನು ಸಾವಿರ ಬಾರಿ ಮಾಡಿದ್ದಾನೆ. ಮತ್ತು ನೀವು ಬಂದು ಅವನಿಗೆ ಹೇಳಿದ ತಕ್ಷಣ: "ಈ ಅಭ್ಯಾಸವನ್ನು ರದ್ದುಗೊಳಿಸೋಣ ಮತ್ತು ಸೋಮವಾರದಿಂದ ಹೊಸದನ್ನು ಪರಿಚಯಿಸೋಣ" ಎಂದು ಅವನಿಗೆ ಅದು ಶಕ್ತಿಯುತವಾದ ಅರಿವಿನ ಹೊರೆಯಾಗುತ್ತದೆ. ಮತ್ತು ಇದು ಎಲ್ಲರಿಗೂ ಒಂದೇ ಬಾರಿಗೆ ಬರುತ್ತದೆ.
ಆದ್ದರಿಂದ, ಸರಳವಾದ ವಿಷಯವೆಂದರೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಈ ಐಷಾರಾಮಿ ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ನಾನು ಯಾವಾಗಲೂ ಮಾಡುತ್ತೇನೆ, ಇದು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ. ಹೊಸ ಯೋಜನೆಯು ಪ್ರಾರಂಭವಾದರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ಪರೀಕ್ಷಿಸದ ಅಭ್ಯಾಸಗಳನ್ನು ತಕ್ಷಣವೇ ಈ ಯೋಜನೆಯಲ್ಲಿ ತುಂಬಿಸಲಾಗುತ್ತದೆ. ಯೋಜನೆಯು ಚಿಕ್ಕದಾಗಿದ್ದರೂ, ನಾವು ನಿಜವಾಗಿಯೂ ಏನನ್ನೂ ಅಪಾಯಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಇನ್ನೂ ಯಾವುದೇ ಉತ್ಪನ್ನವಿಲ್ಲ, ನಾಶಮಾಡಲು ಏನೂ ಇಲ್ಲ. ಆದ್ದರಿಂದ, ಇದನ್ನು ತರಬೇತಿಯಾಗಿ ಬಳಸಬಹುದು. ಈ ವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಎಲ್ಲಾ ಕಂಪನಿಗಳಿಗೆ ಇಂತಹ ಯೋಜನೆಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಪ್ರಾರಂಭಿಸಲು ಅವಕಾಶವಿಲ್ಲ. ಇದು ಸ್ವಲ್ಪ ವಿಚಿತ್ರವಾದರೂ, ಈಗ ಸಂಪೂರ್ಣ ಡಿಜಿಟಲ್ ರೂಪಾಂತರವಿರುವುದರಿಂದ, ಪ್ರತಿಸ್ಪರ್ಧಿಗಳೊಂದಿಗೆ ಮುಂದುವರಿಯಲು ಪ್ರತಿಯೊಬ್ಬರೂ ಪ್ರಯೋಗಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು.
ಇಲ್ಲಿ ನೀವು ಮೊದಲು ನೀವು ಏನು ಮಾಡಬೇಕೆಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬರುತ್ತೀರಿ. ಜಗತ್ತು ಆದರ್ಶವಲ್ಲ, ಮತ್ತು ಉತ್ಪನ್ನವೂ ಆದರ್ಶವಲ್ಲ.
ಹೌದು, ಈ ವಸ್ತುಗಳು ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿವೆ.
ಅವರು ಈ ರೀತಿಯಲ್ಲಿ ಹೋಗಬೇಕು ಎಂದು ವ್ಯಾಪಾರಗಳು ಯಾವಾಗಲೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಸಾಧ್ಯವೇ ಇಲ್ಲ ಎನ್ನುವ ಪರಿಸ್ಥಿತಿ ಇದೆ. ಇದರಿಂದ ತಂಡದ ಮೇಲೆ ಒತ್ತಡ ಹೆಚ್ಚಿದೆ. ತಂಡ ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಸುಟ್ಟುಹೋಗಿದೆ. ಆಕೆಗೆ ಯಾವುದೇ ಪ್ರಯೋಗಗಳಿಗೆ ಬಿಡುವಿಲ್ಲ. ಅವರು ಬೆಳಿಗ್ಗೆಯಿಂದ ಸಂಜೆಯವರೆಗೆ ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಮತ್ತು ನಿರ್ವಹಣೆಯು ಕಡಿಮೆ ಮತ್ತು ಕಡಿಮೆ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ. ಹೆಚ್ಚು ಹೆಚ್ಚು ಅಗತ್ಯವಿದೆ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಸಾಧ್ಯವಿಲ್ಲ. ನಾಳೆ ನಾವು ನಿನ್ನೆಯಂತೆಯೇ ಮಾಡುತ್ತೇವೆ ಎಂದು ತಂಡಕ್ಕೆ ಮಾತ್ರ ಹೇಳಬಹುದು, ನಾವು ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಈ ಅರ್ಥದಲ್ಲಿ, ಯಾವುದೇ ಆಚರಣೆಗಳಿಗೆ ಯಾವುದೇ ಪರಿವರ್ತನೆಗಳು ಸಾಧ್ಯವಿಲ್ಲ. ಕೊಡಲಿಯನ್ನು ಚುರುಕುಗೊಳಿಸಲು ಸಮಯವಿಲ್ಲದಿದ್ದಾಗ ಇದು ಒಂದು ಶ್ರೇಷ್ಠ ಸನ್ನಿವೇಶವಾಗಿದೆ, ಮರಗಳನ್ನು ಕತ್ತರಿಸಬೇಕಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವರು ಅದನ್ನು ಮಂದ ಕೊಡಲಿಯಿಂದ ಕತ್ತರಿಸುತ್ತಾರೆ. ಇಲ್ಲಿ ಯಾವುದೇ ಸರಳ ಸಲಹೆಗಳಿಲ್ಲ.
(ಡಿಮಿಟ್ರಿ) ನಾನು ಚಾಟ್‌ನಿಂದ ಸ್ಪಷ್ಟೀಕರಣವನ್ನು ಓದುತ್ತೇನೆ: “ಆದರೆ ನಮಗೆ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿಯ ಅಗತ್ಯವಿದೆ. ಪರೀಕ್ಷೆಗಳಿಗೆ ಎಷ್ಟು ಸಮಯವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ? ಇದು ಸ್ವಲ್ಪ ದುಬಾರಿ ಮತ್ತು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ”
(ಒಲೆಗ್) ಇದು ಒಂದು ಶ್ರೇಷ್ಠ ತಪ್ಪು ಕಲ್ಪನೆ. ನೀವು ಆತ್ಮವಿಶ್ವಾಸದಿಂದಿರಲು ಸಾಕಷ್ಟು ಪರೀಕ್ಷೆಗಳು ಇರಬೇಕು. ನಿರಂತರ ಏಕೀಕರಣವು 100% ಪರೀಕ್ಷೆಗಳನ್ನು ಮೊದಲು ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಮಾತ್ರ ನೀವು ಈ ಅಭ್ಯಾಸವನ್ನು ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭಿಸುವ ವಿಷಯವಲ್ಲ. ನಿರಂತರ ಏಕೀಕರಣವು ನಿಮ್ಮ ಅರಿವಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಕಣ್ಣುಗಳಿಂದ ನೀವು ನೋಡುವ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಗಳು ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿದ್ದು, ಪರೀಕ್ಷೆಗಳಿಲ್ಲದೆಯೇ ಅದು ಏನನ್ನಾದರೂ ಮುರಿಯುತ್ತದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಬದಲಾವಣೆಗಳು ಚಿಕ್ಕದಾಗಿರುವುದರಿಂದ ನೀವು ಇದನ್ನು ನಿಮ್ಮ ತಲೆಯಲ್ಲಿ ತ್ವರಿತವಾಗಿ ಪರೀಕ್ಷಿಸಬಹುದು. ನೀವು ಕೇವಲ ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷಕರನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ, ಅದು ಅವರಿಗೆ ಸುಲಭವಾಗಿದೆ. ನೀವು ಹೊರಳಾಡಿಕೊಂಡು ಹೇಳಿದಿರಿ: "ನೋಡಿ, ಏನಾದರೂ ಮುರಿದುಹೋಗಿದೆಯೇ?" ಅವರು ಪರಿಶೀಲಿಸಿದರು ಮತ್ತು ಹೇಳಿದರು, "ಇಲ್ಲ, ಏನೂ ಮುರಿದುಹೋಗಿಲ್ಲ." ಏಕೆಂದರೆ ಪರೀಕ್ಷಕನಿಗೆ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ತಿಳಿದಿದೆ. ಒಂದು ತುಂಡು ಕೋಡ್ನೊಂದಿಗೆ ನೀವು ಒಂದು ಬದ್ಧತೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಮತ್ತು ಇದನ್ನು ನಿರ್ದಿಷ್ಟ ನಡವಳಿಕೆಯಿಂದ ಬಳಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ.
ಇಲ್ಲಿ ನೀವು, ಸಹಜವಾಗಿ, ಅಲಂಕರಿಸಲಾಗಿದೆ.
(ಡಿಮಿಟ್ರಿ) ನಾನು ಇಲ್ಲಿ ಒಪ್ಪುವುದಿಲ್ಲ. ಅಭ್ಯಾಸವಿದೆ - ಪರೀಕ್ಷಾ-ಚಾಲಿತ ಅಭಿವೃದ್ಧಿ, ಇದರಿಂದ ನಿಮ್ಮನ್ನು ಉಳಿಸುತ್ತದೆ.
(ಒಲೆಗ್) ಸರಿ, ನಾನು ಇನ್ನೂ ಆ ಹಂತಕ್ಕೆ ಬಂದಿಲ್ಲ. ಮೊದಲ ಭ್ರಮೆ ಎಂದರೆ ನೀವು 100% ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬೇಕು ಅಥವಾ ನೀವು ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಸತ್ಯವಲ್ಲ. ಇವು ಎರಡು ಸಮಾನಾಂತರ ಅಭ್ಯಾಸಗಳು. ಮತ್ತು ಅವರು ನೇರವಾಗಿ ಅವಲಂಬಿತವಾಗಿಲ್ಲ. ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಕವರೇಜ್ ಅತ್ಯುತ್ತಮವಾಗಿರಬೇಕು. ಆಪ್ಟಿಮಲ್ - ಇದರರ್ಥ ಬದ್ಧತೆಯ ನಂತರ ನಿಮ್ಮ ಮಾಸ್ಟರ್ ಉಳಿದಿರುವ ಮಾಸ್ಟರ್‌ನ ಗುಣಮಟ್ಟವು ಕುಡಿದ ಶುಕ್ರವಾರ ಸಂಜೆ “ನಿಯೋಜಿಸು” ಗುಂಡಿಯನ್ನು ವಿಶ್ವಾಸದಿಂದ ಒತ್ತಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ಎಂದು ನೀವೇ ವಿಶ್ವಾಸ ಹೊಂದಿದ್ದೀರಿ ಎಂದರ್ಥ. ನೀವು ಇದನ್ನು ಹೇಗೆ ಸಾಧಿಸುತ್ತೀರಿ? ವಿಮರ್ಶೆಯ ಮೂಲಕ, ಕವರೇಜ್ ಮೂಲಕ, ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣೆಯ ಮೂಲಕ.
ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಪರೀಕ್ಷೆಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗುವುದಿಲ್ಲ. ನೀವು ಪೂರ್ವ ಉತ್ಪನ್ನದಲ್ಲಿ ಒಮ್ಮೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದರೆ, ನಂತರ ಅವರು ನಿಮ್ಮ ಎಲ್ಲಾ ಬಳಕೆದಾರರ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಒಮ್ಮೆ ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ಅಷ್ಟೆ. ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್‌ನಲ್ಲಿ ಓಡಿಸಿದರೆ, ಇದು ನಿಮ್ಮ ನಿಯೋಜಿತ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಆಗಿದ್ದು, ಇದು ಎಲ್ಲವನ್ನೂ ಅಂತ್ಯವಿಲ್ಲದೆ ಪರೀಕ್ಷಿಸುತ್ತದೆ - ಅದು ಕ್ರ್ಯಾಶ್ ಆಗಿರಲಿ ಅಥವಾ ಇಲ್ಲದಿರಲಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದನ್ನು ಒಮ್ಮೆ ಅಥವಾ ಎರಡು ಬಾರಿ ಮಾಡಲಾಗುತ್ತದೆಯೇ ಎಂಬುದು ಒಂದೇ ವ್ಯತ್ಯಾಸ. ಪರೀಕ್ಷೆಗಳ ಒಂದು ಉತ್ತಮ ಸೆಟ್... ಅಂತ್ಯವಿಲ್ಲದಂತೆ ಚಾಲನೆಯಲ್ಲಿದೆ, ಇದು ಮೇಲ್ವಿಚಾರಣೆಯಾಗಿದೆ. ಮತ್ತು ಸರಿಯಾದ ಮೇಲ್ವಿಚಾರಣೆ ಹೀಗಿರಬೇಕು.
ಆದ್ದರಿಂದ, ನೀವು ಶುಕ್ರವಾರ ಸಂಜೆ ತಯಾರಾಗಿ ಮನೆಗೆ ಹೋದಾಗ ನೀವು ಈ ಸ್ಥಿತಿಯನ್ನು ಹೇಗೆ ನಿಖರವಾಗಿ ಸಾಧಿಸುತ್ತೀರಿ ಎಂಬುದು ಇನ್ನೊಂದು ಪ್ರಶ್ನೆ. ಬಹುಶಃ ನೀವು ಕೇವಲ ಧೈರ್ಯಶಾಲಿ ಕೊಳಕು.
ನಿರಂತರ ಏಕೀಕರಣಕ್ಕೆ ಸ್ವಲ್ಪ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ನಾವು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದ ಸಂಕೀರ್ಣ ಅಭ್ಯಾಸಕ್ಕೆ ಓಡಿಹೋದೆವು.
ಮತ್ತು ಎರಡನೆಯ ಭ್ರಮೆಯೆಂದರೆ, MVP ಅನ್ನು ತ್ವರಿತವಾಗಿ ಮಾಡಬೇಕಾಗಿದೆ, ಆದ್ದರಿಂದ ಪರೀಕ್ಷೆಗಳು ಅಲ್ಲಿ ಅಗತ್ಯವಿಲ್ಲ. ಖಂಡಿತವಾಗಿಯೂ ಆ ರೀತಿಯಲ್ಲಿ ಅಲ್ಲ. ಸತ್ಯವೆಂದರೆ ನೀವು MVP ಯಲ್ಲಿ ಬಳಕೆದಾರರ ಕಥೆಯನ್ನು ಬರೆಯುವಾಗ, ನೀವು ಅದನ್ನು ಚೆಂಡಿನ ಮೇಲೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು, ಅಂದರೆ, ಕೆಲವು ರೀತಿಯ ಬಳಕೆದಾರ ಕಥೆಯಿದೆ ಎಂದು ನೀವು ಕೇಳಿದ್ದೀರಿ ಮತ್ತು ತಕ್ಷಣವೇ ಅದನ್ನು ಕೋಡ್ ಮಾಡಲು ಓಡಿದ್ದೀರಿ ಅಥವಾ ನೀವು TDD ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕೆಲಸ ಮಾಡಬಹುದು. ಮತ್ತು TDD ಪ್ರಕಾರ, ಅಭ್ಯಾಸ ಪ್ರದರ್ಶನಗಳಂತೆ, ಇದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಅಂದರೆ ಪರೀಕ್ಷೆಗಳು ಅಡ್ಡ ಪರಿಣಾಮವಾಗಿದೆ. TDD ಯ ಅಭ್ಯಾಸವು ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ಅಲ್ಲ. ಟೆಸ್ಟ್ ಡ್ರೈವನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಎಂದು ಕರೆಯಲಾಗಿದ್ದರೂ, ಇದು ಪರೀಕ್ಷೆಗಳ ಬಗ್ಗೆ ಅಲ್ಲ. ಇದು ವಾಸ್ತುಶಾಸ್ತ್ರದ ವಿಧಾನವೂ ಆಗಿದೆ. ಬೇಕಾದುದನ್ನು ನಿಖರವಾಗಿ ಬರೆಯಲು ಮತ್ತು ಅಗತ್ಯವಿಲ್ಲದ್ದನ್ನು ಬರೆಯಲು ಇದು ಒಂದು ವಿಧಾನವಾಗಿದೆ. ಇದು ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ರಚಿಸುವ ವಿಷಯದಲ್ಲಿ ನಿಮ್ಮ ಆಲೋಚನೆಯ ಮುಂದಿನ ಪುನರಾವರ್ತನೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಅಭ್ಯಾಸವಾಗಿದೆ.
ಆದ್ದರಿಂದ, ಈ ಭ್ರಮೆಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಅಷ್ಟು ಸುಲಭವಲ್ಲ. MVP ಮತ್ತು ಪರೀಕ್ಷೆಗಳು ಪರಸ್ಪರ ವಿರುದ್ಧವಾಗಿಲ್ಲ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ನೀವು ಟಿಡಿಡಿ ಅಭ್ಯಾಸವನ್ನು ಬಳಸಿಕೊಂಡು ಎಂವಿಪಿ ಮಾಡಿದರೆ, ನೀವು ಅದನ್ನು ಅಭ್ಯಾಸವಿಲ್ಲದೆ ಮಾಡುವುದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿ ಮತ್ತು ವೇಗವಾಗಿ ಮಾಡುತ್ತೀರಿ, ಆದರೆ ಚೆಂಡಿನ ಮೇಲೆ.
ಇದು ತುಂಬಾ ಸ್ಪಷ್ಟವಲ್ಲದ ಮತ್ತು ಸಂಕೀರ್ಣವಾದ ಕಲ್ಪನೆಯಾಗಿದೆ. ಈಗ ನಾನು ಹೆಚ್ಚು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುತ್ತೇನೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಾನು ಏನನ್ನಾದರೂ ವೇಗವಾಗಿ ಮಾಡುತ್ತೇನೆ ಎಂದು ನೀವು ಕೇಳಿದಾಗ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಮರ್ಪಕವಾಗಿದೆ.
(ಡಿಮಿಟ್ರಿ) ಇಲ್ಲಿ ಅನೇಕ ಜನರು, ಅವರು MVP ಗೆ ಕರೆ ಮಾಡಿದಾಗ, ಜನರು ಸಾಮಾನ್ಯವಾದದ್ದನ್ನು ಬರೆಯಲು ತುಂಬಾ ಸೋಮಾರಿಯಾಗುತ್ತಾರೆ. ಮತ್ತು ಇವು ಇನ್ನೂ ವಿಭಿನ್ನ ವಿಷಯಗಳಾಗಿವೆ. MVP ಅನ್ನು ಕೆಲಸ ಮಾಡದ ಕೆಲವು ಕೆಟ್ಟ ವಿಷಯವಾಗಿ ಪರಿವರ್ತಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಹೌದು, ಹೌದು, ನೀವು ಹೇಳಿದ್ದು ಸರಿ.
ತದನಂತರ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಪ್ರಾಡ್‌ನಲ್ಲಿ MVP.
ಶಾಶ್ವತವಾಗಿ.
ಮತ್ತು ನೀವು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುತ್ತೀರಿ ಮತ್ತು ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತೀರಿ ಎಂದು ನೀವು ಕೇಳಿದಾಗ TDD ತುಂಬಾ ಅಸಾಮಾನ್ಯವಾಗಿದೆ. ಇದು ತುಂಬಾ ವಿಚಿತ್ರವೆನಿಸುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇದು ಈ ರೀತಿಯಲ್ಲಿ ವೇಗವಾಗಿ ಮತ್ತು ಸುಂದರವಾಗಿರುತ್ತದೆ. ನೀವು ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯುವಾಗ, ಯಾವ ಕೋಡ್ ಅನ್ನು ಕರೆಯಲಾಗುವುದು ಮತ್ತು ಹೇಗೆ, ಹಾಗೆಯೇ ನಾವು ಅದರಿಂದ ಯಾವ ನಡವಳಿಕೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ನಿಮ್ಮ ತಲೆಯಲ್ಲಿ ನೀವು ಈಗಾಗಲೇ ಯೋಚಿಸುತ್ತೀರಿ. ನಾನು ಕೆಲವು ಕಾರ್ಯವನ್ನು ಬರೆದಿದ್ದೇನೆ ಮತ್ತು ಅದು ಏನನ್ನಾದರೂ ಮಾಡುತ್ತದೆ ಎಂದು ನೀವು ಹೇಳುವುದಿಲ್ಲ. ಆಕೆಗೆ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಷರತ್ತುಗಳಿವೆ ಎಂದು ನೀವು ಮೊದಲು ಭಾವಿಸಿದ್ದೀರಿ, ಅವಳನ್ನು ಅಂತಹ ಮತ್ತು ರೀತಿಯಲ್ಲಿ ಕರೆಯಲಾಗುವುದು. ನೀವು ಇದನ್ನು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಒಳಗೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ಇದರಿಂದ ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಹೇಗೆ ಕಾಣುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಇದು ವಾಸ್ತುಶಿಲ್ಪದ ಮೇಲೆ ಭಾರಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೆಚ್ಚು ಮಾಡ್ಯುಲರ್ ಆಗುತ್ತದೆ, ಏಕೆಂದರೆ ನೀವು ಅದನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೀರಿ ಮತ್ತು ನಂತರ ಅದನ್ನು ಬರೆಯಿರಿ.
TDD ಯೊಂದಿಗೆ ನನಗೆ ಏನಾಯಿತು ಎಂದರೆ ನಾನು ರೂಬಿ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿದ್ದಾಗ ಕೆಲವು ಸಮಯದಲ್ಲಿ ನಾನು ರೂಬಿ ಮಾರ್ಗದರ್ಶಕನನ್ನು ನೇಮಿಸಿಕೊಂಡೆ. ಮತ್ತು ಅವರು ಹೇಳುತ್ತಾರೆ: "ಟಿಡಿಡಿ ಪ್ರಕಾರ ಅದನ್ನು ಮಾಡೋಣ." ನಾನು ಯೋಚಿಸಿದೆ: "ಡ್ಯಾಮ್, ಈಗ ನಾನು ಹೆಚ್ಚುವರಿ ಏನನ್ನಾದರೂ ಬರೆಯಬೇಕಾಗಿದೆ." ಮತ್ತು ಎರಡು ವಾರಗಳಲ್ಲಿ ನಾನು TDD ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪೈಥಾನ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ವರ್ಕಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತೇನೆ ಎಂದು ನಾವು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ. ಎರಡು ವಾರಗಳ ನಂತರ, ನಾನು ಹಿಂತಿರುಗಲು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ. ಎರಡು ವಾರಗಳ ನಂತರ ಇದನ್ನು ಎಲ್ಲೆಡೆ ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದ ನಂತರ, ನೀವು ಯೋಚಿಸುವುದು ಎಷ್ಟು ಸುಲಭವಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಆದರೆ ಇದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ TDD ಕಷ್ಟ, ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅನಗತ್ಯ ಎಂಬ ಭಾವನೆ ನಿಮ್ಮಲ್ಲಿದ್ದರೆ, ಕೇವಲ ಎರಡು ವಾರಗಳವರೆಗೆ ಅದನ್ನು ಅಂಟಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸಿ ಎಂದು ನಾನು ಎಲ್ಲರಿಗೂ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ನನಗೆ ಎರಡು ಸಾಕಾಗಿತ್ತು.
(ಡಿಮಿಟ್ರಿ) ಮೂಲಸೌಕರ್ಯ ಕಾರ್ಯಾಚರಣೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ನಾವು ಈ ಕಲ್ಪನೆಯನ್ನು ವಿಸ್ತರಿಸಬಹುದು. ನಾವು ಹೊಸದನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮೇಲ್ವಿಚಾರಣೆ ನಮಗೆ ಸಾಮಾನ್ಯ ಪರೀಕ್ಷೆಯಾಗುತ್ತದೆ. ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯ ಮೂಲಕ ಅಭಿವೃದ್ಧಿ ಇದೆ. ಆದರೆ ಬಹುತೇಕ ಎಲ್ಲರೂ ಇದು ಉದ್ದವಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತಾರೆ, ನಾನು ಸೋಮಾರಿಯಾಗಿದ್ದೇನೆ, ನಾನು ತಾತ್ಕಾಲಿಕ ಡ್ರಾಫ್ಟ್ ಮಾಡಿದ್ದೇನೆ. ನಾವು ಸಾಮಾನ್ಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಮಾಡಿದ್ದರೆ, CI ವ್ಯವಸ್ಥೆಯ ಸ್ಥಿತಿಯನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಮತ್ತು ಸಿಐ ವ್ಯವಸ್ಥೆಯು ಸಾಕಷ್ಟು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿದೆ. ನಾವು ವ್ಯವಸ್ಥೆಯ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ, ಅದರೊಳಗೆ ಏನಿದೆ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ನಾವು ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ ಇದರಿಂದ ಅದು ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ತಲುಪುತ್ತದೆ.
ಈ ಅಭ್ಯಾಸಗಳು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ತಿಳಿದಿವೆ. ನಾವು ಸುಮಾರು 4 ವರ್ಷಗಳ ಹಿಂದೆ ಈ ಬಗ್ಗೆ ಚರ್ಚಿಸಿದ್ದೇವೆ. ಆದರೆ 4 ವರ್ಷಗಳಲ್ಲಿ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಏನೂ ಬದಲಾಗಿಲ್ಲ.
ಆದರೆ ಈ ಟಿಪ್ಪಣಿಯಲ್ಲಿ, ಅಧಿಕೃತ ಚರ್ಚೆಯನ್ನು ಕೊನೆಗೊಳಿಸಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ.
ವೀಡಿಯೊ (ಮಾಧ್ಯಮ ಅಂಶವಾಗಿ ಸೇರಿಸಲಾಗಿದೆ, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ):
ಮೂಲ: www.habr.com