2018 ರ ಆರಂಭದಿಂದಲೂ, ನಾನು ತಂಡದಲ್ಲಿ ಲೀಡ್/ಬಾಸ್/ಲೀಡ್ ಡೆವಲಪರ್ ಸ್ಥಾನವನ್ನು ಹೊಂದಿದ್ದೇನೆ - ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಕರೆ ಮಾಡಿ, ಆದರೆ ವಿಷಯವೆಂದರೆ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳಿಗೆ ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತೇನೆ ಅದರ ಮೇಲೆ. ಈ ಸ್ಥಾನವು ನನಗೆ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹೊಸ ದೃಷ್ಟಿಕೋನವನ್ನು ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ನಾನು ಹೆಚ್ಚಿನ ಯೋಜನೆಗಳಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೇನೆ ಮತ್ತು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವುದರಲ್ಲಿ ಹೆಚ್ಚು ಸಕ್ರಿಯವಾಗಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೇನೆ. ಇತ್ತೀಚೆಗೆ, ಈ ಎರಡು ವಿಷಯಗಳಿಗೆ ಧನ್ಯವಾದಗಳು, ತಿಳುವಳಿಕೆಯ ಅಳತೆ ಕೋಡ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮೇಲೆ ಎಷ್ಟು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅರಿತುಕೊಂಡೆ.
ನಾನು ಮಾಡಲು ಬಯಸುವ ಅಂಶವೆಂದರೆ ಕೋಡ್‌ನ ಗುಣಮಟ್ಟ (ಮತ್ತು ಅಂತಿಮ ಉತ್ಪನ್ನ) ಕೋಡ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮತ್ತು ಬರೆಯುವ ಜನರು ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ಎಷ್ಟು ಜಾಗೃತರಾಗಿದ್ದಾರೆ ಎಂಬುದಕ್ಕೆ ನಿಕಟ ಸಂಬಂಧ ಹೊಂದಿದೆ.
ನೀವು ಇದೀಗ ಯೋಚಿಸುತ್ತಿರಬಹುದು, "ಧನ್ಯವಾದಗಳು, ಕ್ಯಾಪ್. ಸಹಜವಾಗಿ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಏನು ಬರೆಯುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಅನಿಯಂತ್ರಿತ ಕೀಗಳನ್ನು ಹೊಡೆಯಲು ಕೋತಿಗಳ ಗುಂಪನ್ನು ಬಾಡಿಗೆಗೆ ಪಡೆಯಬಹುದು ಮತ್ತು ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಮತ್ತು ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಸರಿ. ಅಂತೆಯೇ, ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬ ಸಾಮಾನ್ಯ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರುವುದು ಅವಶ್ಯಕ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂದು ನಾನು ಲಘುವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ. ಇದನ್ನು ಶೂನ್ಯ ಮಟ್ಟದ ತಿಳುವಳಿಕೆ ಎಂದು ಕರೆಯಬಹುದು ಮತ್ತು ನಾವು ಅದನ್ನು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸುವುದಿಲ್ಲ. ನೀವು ನಿಖರವಾಗಿ ಏನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ನೀವು ಪ್ರತಿದಿನ ಮಾಡುವ ನಿರ್ಧಾರಗಳ ಮೇಲೆ ಅದು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ವಿವರವಾಗಿ ನೋಡುತ್ತೇವೆ. ನಾನು ಈ ವಿಷಯಗಳನ್ನು ಮೊದಲೇ ತಿಳಿದಿದ್ದರೆ, ಅದು ನನಗೆ ಸಾಕಷ್ಟು ಸಮಯ ವ್ಯರ್ಥ ಮತ್ತು ಪ್ರಶ್ನಾರ್ಹ ಕೋಡ್ ಅನ್ನು ಉಳಿಸುತ್ತಿತ್ತು.
ನೀವು ಕೆಳಗೆ ಕೋಡ್‌ನ ಒಂದೇ ಸಾಲನ್ನು ನೋಡದಿದ್ದರೂ, ಇಲ್ಲಿ ಹೇಳಲಾದ ಎಲ್ಲವೂ ಉತ್ತಮ-ಗುಣಮಟ್ಟದ, ಅಭಿವ್ಯಕ್ತಿಶೀಲ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ಹೆಚ್ಚಿನ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾನು ಇನ್ನೂ ನಂಬುತ್ತೇನೆ.
ಮೊದಲ ಹಂತದ ತಿಳುವಳಿಕೆ: ಅದು ಏಕೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ?
ಡೆವಲಪರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ವೃತ್ತಿಜೀವನದ ಆರಂಭದಲ್ಲಿ ಈ ಮಟ್ಟವನ್ನು ತಲುಪುತ್ತಾರೆ, ಕೆಲವೊಮ್ಮೆ ಇತರರಿಂದ ಯಾವುದೇ ಸಹಾಯವಿಲ್ಲದೆ - ಕನಿಷ್ಠ ನನ್ನ ಅನುಭವದಲ್ಲಿ. ನೀವು ದೋಷ ವರದಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ: ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕೆಲವು ಕಾರ್ಯಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ. ನೀವು ಹೇಗೆ ಮುಂದುವರೆಯುತ್ತೀರಿ?
ಪ್ರಮಾಣಿತ ಯೋಜನೆ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
- ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುವ ಕೋಡ್‌ನ ತುಣುಕನ್ನು ಹುಡುಕಿ (ಇದನ್ನು ಹೇಗೆ ಮಾಡುವುದು ಒಂದು ಪ್ರತ್ಯೇಕ ವಿಷಯವಾಗಿದೆ, ನಾನು ಅದನ್ನು ಪರಂಪರೆ ಕೋಡ್ ಕುರಿತು ನನ್ನ ಪುಸ್ತಕದಲ್ಲಿ ಕವರ್ ಮಾಡುತ್ತೇನೆ)
- ಈ ತುಣುಕಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿ
- ದೋಷವನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ರಿಗ್ರೆಷನ್ ದೋಷಗಳು ಸಂಭವಿಸಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ
ಈಗ ಎರಡನೇ ಅಂಶದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸೋಣ - ಕೋಡ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವುದು. ಈ ಪ್ರಕ್ರಿಯೆಗೆ ಎರಡು ವಿಧಾನಗಳಿವೆ. ಮೊದಲನೆಯದು ಪ್ರಸ್ತುತ ಕೋಡ್‌ನಲ್ಲಿ ನಿಖರವಾಗಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುವುದು, ದೋಷವನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸುವುದು. ಎರಡನೆಯದು: ಭಾವನೆಯಿಂದ ಸರಿಸಿ - ಷರತ್ತುಬದ್ಧ ಹೇಳಿಕೆ ಅಥವಾ ಲೂಪ್‌ಗೆ ಸೇರಿಸಿ, ಹೇಳಿ, +1, ಕಾರ್ಯವು ಅಪೇಕ್ಷಿತ ಸನ್ನಿವೇಶದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡಿ, ನಂತರ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಪ್ರಯತ್ನಿಸಿ, ಮತ್ತು ಜಾಹೀರಾತು ಅನಂತವಾಗಿ.
ಮೊದಲ ವಿಧಾನವು ಸರಿಯಾಗಿದೆ. ಸ್ಟೀವ್ ಮೆಕ್‌ಕಾನ್ನೆಲ್ ಅವರ ಪುಸ್ತಕ ಕೋಡ್ ಕಂಪ್ಲೀಟ್‌ನಲ್ಲಿ ವಿವರಿಸಿದಂತೆ (ನಾನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ), ಪ್ರತಿ ಬಾರಿ ನಾವು ಕೋಡ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಿದಾಗ, ಅದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ವಿಶ್ವಾಸದಿಂದ ಊಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನಾನು ಮೆಮೊರಿಯಿಂದ ಉಲ್ಲೇಖಿಸುತ್ತಿದ್ದೇನೆ, ಆದರೆ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ರೀತಿಯಲ್ಲಿ ಬಗ್ಫಿಕ್ಸ್ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ನೀವು ತುಂಬಾ ಗಾಬರಿಯಾಗಬೇಕು ಮತ್ತು ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಕ್ರಿಯಾ ಯೋಜನೆಯನ್ನು ನೀವು ಪ್ರಶ್ನಿಸಬೇಕು.
ಹೇಳಿರುವುದನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಲು, ಕೋಡ್‌ನ ಗುಣಮಟ್ಟವನ್ನು ಕ್ಷೀಣಿಸದಂತೆ ಉತ್ತಮ ದೋಷ ಪರಿಹಾರವನ್ನು ನಿರ್ವಹಿಸಲು, ನೀವು ಕೋಡ್‌ನ ಸಂಪೂರ್ಣ ರಚನೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಯ ಮೂಲ ಎರಡನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಎರಡನೇ ಹಂತದ ತಿಳುವಳಿಕೆ: ಅದು ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
ಈ ಹಂತವು ಹಿಂದಿನದಕ್ಕಿಂತ ಕಡಿಮೆ ಅಂತರ್ಬೋಧೆಯಿಂದ ಗ್ರಹಿಸಲ್ಪಟ್ಟಿದೆ. ನಾನು, ಇನ್ನೂ ಅನನುಭವಿ ಡೆವಲಪರ್ ಆಗಿದ್ದಾಗ, ನನ್ನ ಬಾಸ್‌ಗೆ ಧನ್ಯವಾದಗಳು ಅದನ್ನು ಕಲಿತಿದ್ದೇನೆ ಮತ್ತು ತರುವಾಯ ಹೊಸಬರಿಗೆ ವಿಷಯದ ಸಾರವನ್ನು ಪದೇ ಪದೇ ವಿವರಿಸಿದೆ.
ಈ ಸಮಯದಲ್ಲಿ, ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ದೋಷ ವರದಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೀರಿ ಎಂದು ಊಹಿಸೋಣ: ಮೊದಲನೆಯದು ಸನ್ನಿವೇಶ A ಬಗ್ಗೆ, ಎರಡನೆಯದು ಸನ್ನಿವೇಶ B ಬಗ್ಗೆ. ಎರಡೂ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ಏನೋ ತಪ್ಪಾಗಿದೆ. ಅಂತೆಯೇ, ನೀವು ಮೊದಲು ಮೊದಲ ದೋಷವನ್ನು ನಿಭಾಯಿಸುತ್ತೀರಿ. ಹಂತ XNUMX ತಿಳುವಳಿಕೆಗಾಗಿ ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ತತ್ವಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಸಮಸ್ಯೆಗೆ ಸಂಬಂಧಿಸಿದ ಕೋಡ್ ಅನ್ನು ನೀವು ಆಳವಾಗಿ ಅಗೆಯಿರಿ, ಸನ್ನಿವೇಶ A ಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ ಮತ್ತು ನೀವು ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಉಂಟುಮಾಡುವ ಸಮಂಜಸವಾದ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಮಾಡಿ. . ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ನಡೆಯುತ್ತಿದೆ.
ನಂತರ ನೀವು ಸನ್ನಿವೇಶ B ಗೆ ತೆರಳಿ. ದೋಷವನ್ನು ಪ್ರಚೋದಿಸುವ ಪ್ರಯತ್ನದಲ್ಲಿ ನೀವು ಸನ್ನಿವೇಶವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತೀರಿ, ಆದರೆ-ಆಶ್ಚರ್ಯ! - ಈಗ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಿಮ್ಮ ಊಹೆಯನ್ನು ಖಚಿತಪಡಿಸಲು, ಬಗ್ A ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ನೀವು ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ನೀವು ರದ್ದುಗೊಳಿಸುತ್ತೀರಿ ಮತ್ತು ಬಗ್ B ಹಿಂತಿರುಗುತ್ತದೆ. ನಿಮ್ಮ ಬಗ್ಫಿಕ್ಸ್ ಎರಡೂ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದೆ. ಅದೃಷ್ಟವಂತ!
ನೀವು ಇದನ್ನು ಲೆಕ್ಕಿಸಲಿಲ್ಲ. ಸನ್ನಿವೇಶ A ಯಲ್ಲಿನ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲು ನೀವು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ ಮತ್ತು ಅದು ಸನ್ನಿವೇಶ B ಗಾಗಿ ಏಕೆ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ತಿಳಿದಿಲ್ಲ. ಈ ಹಂತದಲ್ಲಿ, ಎರಡೂ ಕಾರ್ಯಗಳು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡಿವೆ ಎಂದು ಯೋಚಿಸುವುದು ಬಹಳ ಪ್ರಲೋಭನಕಾರಿಯಾಗಿದೆ. ಇದು ಸಾಕಷ್ಟು ತಾರ್ಕಿಕವಾಗಿದೆ: ದೋಷಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಪಾಯಿಂಟ್ ಆಗಿತ್ತು, ಅಲ್ಲವೇ? ಆದರೆ ಕೆಲಸವು ಇನ್ನೂ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ: ನಿಮ್ಮ ಕ್ರಿಯೆಗಳು ಸನ್ನಿವೇಶದಲ್ಲಿ ದೋಷವನ್ನು ಏಕೆ ಸರಿಪಡಿಸಿವೆ ಎಂಬುದನ್ನು ನೀವು ಇನ್ನೂ ಕಂಡುಹಿಡಿಯಬೇಕು. ಏಕೆ? ಏಕೆಂದರೆ ಅದು ತಪ್ಪು ತತ್ವಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಬಹುದು, ಮತ್ತು ನಂತರ ನೀವು ಇನ್ನೊಂದು ಮಾರ್ಗವನ್ನು ಹುಡುಕಬೇಕಾಗಿದೆ. ಅಂತಹ ಪ್ರಕರಣಗಳ ಒಂದೆರಡು ಉದಾಹರಣೆಗಳು ಇಲ್ಲಿವೆ:
- ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ದೋಷ B ಗೆ ಪರಿಹಾರವನ್ನು ಹೊಂದಿಸಲಾಗಿಲ್ಲವಾದ್ದರಿಂದ, ನೀವು ತಿಳಿಯದೆ C ಅನ್ನು ಮುರಿದಿರಬಹುದು.
- ಅದೇ ಕಾರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಮೂರನೇ ದೋಷವು ಎಲ್ಲೋ ಅಡಗಿರುವ ಸಾಧ್ಯತೆಯಿದೆ ಮತ್ತು ಬಿ ಸನ್ನಿವೇಶದಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನ ಸರಿಯಾದ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ನಿಮ್ಮ ದೋಷ ಪರಿಹಾರವು ಅದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಈಗ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಒಂದು ದಿನ ಈ ಮೂರನೇ ದೋಷವನ್ನು ಗಮನಿಸಲಾಗುವುದು ಮತ್ತು ಸರಿಪಡಿಸಲಾಗುವುದು. ನಂತರ ಬಿ ಸನ್ನಿವೇಶದಲ್ಲಿ ದೋಷವು ಮತ್ತೆ ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಇದ್ದರೆ ಒಳ್ಳೆಯದು.
ಇದೆಲ್ಲವೂ ಕೋಡ್‌ಗೆ ಅವ್ಯವಸ್ಥೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಒಂದು ದಿನ ನಿಮ್ಮ ತಲೆಯ ಮೇಲೆ ಬೀಳುತ್ತದೆ - ಹೆಚ್ಚಾಗಿ ಅತ್ಯಂತ ಅಸಮರ್ಪಕ ಕ್ಷಣದಲ್ಲಿ. ಎಲ್ಲವೂ ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಮಯವನ್ನು ಕಳೆಯಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸಲು ನಿಮ್ಮ ಇಚ್ಛಾಶಕ್ತಿಯನ್ನು ನೀವು ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಅದು ಯೋಗ್ಯವಾಗಿದೆ.
ಮೂರನೇ ಹಂತದ ತಿಳುವಳಿಕೆ: ಅದು ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
ನನ್ನ ಇತ್ತೀಚಿನ ಒಳನೋಟವು ನಿಖರವಾಗಿ ಈ ಮಟ್ಟಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, ಮತ್ತು ನಾನು ಈ ಆಲೋಚನೆಗೆ ಮೊದಲೇ ಬಂದಿದ್ದರೆ ಬಹುಶಃ ಇದು ನನಗೆ ಹೆಚ್ಚು ಪ್ರಯೋಜನವನ್ನು ನೀಡುತ್ತದೆ.
ಅದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು, ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ: ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಫಂಕ್ಷನ್ X ಗೆ ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಮಾಡಬೇಕಾಗಿದೆ. ನಿಮಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ X ಫಂಕ್ಷನ್ ಪರಿಚಯವಿಲ್ಲ, ಆದರೆ ಅದರೊಂದಿಗೆ ಹೊಂದಿಕೊಳ್ಳಲು ನೀವು F ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿಸಲಾಗಿದೆ. X ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಮಾಡ್ಯೂಲ್‌ಗಳು ಅವನೊಂದಿಗೆ ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ನಿಮ್ಮ ಕೋಡ್ ತನ್ನ ಜೀವನದ ಮೊದಲ ದಿನದಿಂದಲೂ F ಫ್ರೇಮ್‌ವರ್ಕ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕದಲ್ಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ. ಇದು ಮಾಡ್ಯೂಲ್‌ನ ಕೆಲವು ಭಾಗಗಳಿಗೆ ಗಂಭೀರ ಪರಿಣಾಮಗಳನ್ನು ಬೀರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನೀವು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗುತ್ತೀರಿ: ನೀವು ವಾರಗಟ್ಟಲೆ ಕೋಡ್ ಬರೆಯುವುದು, ಪರೀಕ್ಷೆ ಮಾಡುವುದು, ಪೈಲಟ್ ಆವೃತ್ತಿಗಳನ್ನು ಹೊರತರುವುದು, ಪ್ರತಿಕ್ರಿಯೆ ಪಡೆಯುವುದು, ರಿಗ್ರೆಶನ್ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದು, ಅನಿರೀಕ್ಷಿತ ತೊಡಕುಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು, ಮೂಲತಃ ಒಪ್ಪಿದ ಗಡುವನ್ನು ಪೂರೈಸದಿರುವುದು, ಇನ್ನೂ ಕೆಲವು ಕೋಡ್ ಬರೆಯುವುದು, ಪರೀಕ್ಷೆ, ಪ್ರತಿಕ್ರಿಯೆ ಸಂವಹನವನ್ನು ಪಡೆಯುವುದು ರಿಗ್ರೆಷನ್ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದು - ಎಫ್ ಚೌಕಟ್ಟನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಇದೆಲ್ಲವೂ.
ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ - ಅಥವಾ ಯಾರೊಬ್ಬರಿಂದ ಕೇಳಬಹುದು - ಬಹುಶಃ ಫ್ರೇಮ್‌ವರ್ಕ್ ಎಫ್ ನಿಮಗೆ ವೈಶಿಷ್ಟ್ಯ X ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ, ಬಹುಶಃ ಆ ಸಮಯ ಮತ್ತು ಶ್ರಮವು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಾಗಿದೆ.
ನಾನು ಜವಾಬ್ದಾರನಾಗಿದ್ದ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಒಮ್ಮೆ ಇದೇ ರೀತಿಯ ಘಟನೆ ಸಂಭವಿಸಿದೆ. ಇದು ಏಕೆ ಸಂಭವಿಸಿತು? ಏಕೆಂದರೆ X ಕಾರ್ಯ ಯಾವುದು ಮತ್ತು ಅದು F ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ನನಗೆ ಸ್ವಲ್ಪ ತಿಳುವಳಿಕೆ ಇತ್ತು. ನಾನು ಏನು ಮಾಡಬೇಕಿತ್ತು? ಅಭಿವೃದ್ಧಿ ಕಾರ್ಯವನ್ನು ನಿಯೋಜಿಸುವ ವ್ಯಕ್ತಿಯನ್ನು ಇತರ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗಾಗಿ ಮಾಡಿರುವುದನ್ನು ಸರಳವಾಗಿ ಪುನರಾವರ್ತಿಸುವ ಬದಲು ಉದ್ದೇಶಿತ ಕ್ರಮವು ಅಪೇಕ್ಷಿತ ಫಲಿತಾಂಶಕ್ಕೆ ಹೇಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಲು ಕೇಳಿ ಅಥವಾ X ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಅವರ ಮಾತುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಈ ಯೋಜನೆಯ ಅನುಭವವು ಕೆಲವು ವಿಷಯಗಳನ್ನು ಮಾಡಲು ನಮ್ಮನ್ನು ಏಕೆ ಕೇಳಲಾಗುತ್ತಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಮಗೆ ಸ್ಪಷ್ಟವಾದ ತಿಳುವಳಿಕೆ ಬರುವವರೆಗೆ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿರಾಕರಿಸಲು ನನಗೆ ಕಲಿಸಿದೆ. ಸಾರಾಸಗಟಾಗಿ ನಿರಾಕರಿಸು. ನೀವು ಕೆಲಸವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡದಂತೆ ತಕ್ಷಣವೇ ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮೊದಲ ಪ್ರಚೋದನೆಯಾಗಿದೆ. ಆದರೆ "ನಾವು ಎಲ್ಲಾ ವಿವರಗಳನ್ನು ಪಡೆಯುವವರೆಗೆ ಯೋಜನೆಯನ್ನು ಫ್ರೀಜ್ ಮಾಡಿ" ನೀತಿಯು ಪ್ರಮಾಣದ ಆದೇಶಗಳಿಂದ ವ್ಯರ್ಥ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
ಅವರು ನಿಮ್ಮ ಮೇಲೆ ಒತ್ತಡ ಹೇರಲು ಪ್ರಯತ್ನಿಸಿದರೂ, ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸಲು, ಇದರ ತಾರ್ಕಿಕತೆ ನಿಮಗೆ ಅರ್ಥವಾಗದಿದ್ದರೂ, ವಿರೋಧಿಸಿ. ಮೊದಲಿಗೆ, ನಿಮಗೆ ಅಂತಹ ಕೆಲಸವನ್ನು ಏಕೆ ನೀಡಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ, ಮತ್ತು ಇದು ಗುರಿಯ ಸರಿಯಾದ ಮಾರ್ಗವಾಗಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ನಾನು ಇದನ್ನೆಲ್ಲ ಕಷ್ಟಪಟ್ಟು ಕಲಿಯಬೇಕಾಗಿತ್ತು - ನನ್ನ ಉದಾಹರಣೆಯು ಇದನ್ನು ಓದುವವರಿಗೆ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ನಾಲ್ಕನೇ ಹಂತದ ತಿಳುವಳಿಕೆ: ???
ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ಕಲಿಯಲು ಯಾವಾಗಲೂ ಹೆಚ್ಚು ಇರುತ್ತದೆ, ಮತ್ತು ನಾನು ತಿಳುವಳಿಕೆಯ ವಿಷಯದ ಮೇಲ್ಮೈಯನ್ನು ಮಾತ್ರ ಗೀಚಿದ್ದೇನೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ ವರ್ಷಗಳಲ್ಲಿ ನೀವು ಇತರ ಯಾವ ಮಟ್ಟದ ತಿಳುವಳಿಕೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ? ಕೋಡ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಗುಣಮಟ್ಟದ ಮೇಲೆ ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುವ ಯಾವ ನಿರ್ಧಾರಗಳನ್ನು ನೀವು ತೆಗೆದುಕೊಂಡಿದ್ದೀರಿ? ಯಾವ ನಿರ್ಧಾರಗಳು ತಪ್ಪಾಗಿವೆ ಮತ್ತು ನಿಮಗೆ ಅಮೂಲ್ಯವಾದ ಪಾಠವನ್ನು ಕಲಿಸಿದವು? ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ನಿಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ.
ಮೂಲ: www.habr.com