ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಅಗತ್ಯ ಡೆವಲಪರ್ ಕೌಶಲ್ಯ

ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಅಗತ್ಯ ಡೆವಲಪರ್ ಕೌಶಲ್ಯ

ಅನುವಾದಕರ ಮುನ್ನುಡಿ: ಈ ಲೇಖನವನ್ನು ಓದಿದ ನಂತರ, ನೀವು ಆಶ್ಚರ್ಯವಾಗಬಹುದು ಅಥವಾ ಕೋಪಗೊಳ್ಳಬಹುದು. ಹೌದು, ನಮಗೂ ಆಶ್ಚರ್ಯವಾಯಿತು: "ಶೀಘ್ರವಾಗಿ ಮತ್ತು ತರ್ಕವಿಲ್ಲದೆ ಮಾಡಿ" ಎಂಬ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿಸುವ ಬಗ್ಗೆ ಲೇಖಕರು ತಂಡದಲ್ಲಿನ ಕ್ರಮಾನುಗತದ ಬಗ್ಗೆ ಎಂದಿಗೂ ಕೇಳಿಲ್ಲ. ಹೌದು, ಅದು ಸರಿ, ಇದು ಸ್ವಲ್ಪ ವಿಚಿತ್ರ ಪಠ್ಯವಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಪ್ರೋಗ್ರಾಮರ್ ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಟ್ ಪಾತ್ರವನ್ನು ವಹಿಸಿಕೊಳ್ಳಬೇಕೆಂದು ಲೇಖಕರು ಸೂಚಿಸುತ್ತಾರೆ - ಹಾಗಾದರೆ ನಿಮಗೆ ವಾಸ್ತುಶಿಲ್ಪಿ ಏಕೆ ಬೇಕು? ಆದರೆ ಈ ಎಲ್ಲಾ ಆಕ್ಷೇಪಣೆಗಳು ನಿಮ್ಮನ್ನು ಮುಖ್ಯ ವಿಷಯಕ್ಕೆ ಕುರುಡಾಗಿಸಬಾರದು - ಆದರೂ ನಾವು ಈ ಪಠ್ಯವನ್ನು ಏಕೆ ತೆಗೆದುಕೊಂಡು ಅನುವಾದಿಸಿದ್ದೇವೆ. ಅವರು ಪಾತ್ರಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ಈ ಪಠ್ಯವು ವೃತ್ತಿಪರ ವಿಧಾನ ಮತ್ತು ಅರಿವಿನ ಬಗ್ಗೆ. ಸತ್ಯವೆಂದರೆ ನಿಮ್ಮ ಕ್ರಿಯೆಗಳ ಅರ್ಥವನ್ನು ಯೋಚಿಸದೆ ನೀವು "ನಿಮಗೆ ಹೇಳಿದ್ದನ್ನು ಮಾಡಿ" ಅಲ್ಲಿಯವರೆಗೆ, ನೀವು ಎಂದಿಗೂ ಉತ್ತಮ ಪ್ರೋಗ್ರಾಮರ್ ಆಗುವುದಿಲ್ಲ.

ಅನಗತ್ಯ ಕೋಡ್ ಬೇಡ ಎಂದು ಹೇಳಿ. ನೀವು ಮಾಡಬೇಕಾಗಿರುವುದು ಮೂರು ಅಕ್ಷರಗಳನ್ನು ಜೋಡಿಸಿ ಮತ್ತು ಪದವನ್ನು ಹೇಳುವುದು. ಇದನ್ನು ಒಟ್ಟಿಗೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ: "Nooooo!"

ಆದರೆ ನಿಲ್ಲು. ನಾವು ಇದನ್ನು ಏಕೆ ಮಾಡುತ್ತಿದ್ದೇವೆ? ಎಲ್ಲಾ ನಂತರ, ಪ್ರೋಗ್ರಾಮರ್ನ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ ಕೋಡ್ ಬರೆಯುವುದು. ಆದರೆ ನಿಮ್ಮಿಂದ ಕೇಳಲಾದ ಯಾವುದೇ ಕೋಡ್ ಅನ್ನು ನೀವು ಬರೆಯಬೇಕೇ? ಇಲ್ಲ! "ಕೋಡ್ ಅನ್ನು ಯಾವಾಗ ಬರೆಯಬಾರದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹುಶಃ ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ ಪ್ರಮುಖ ಕೌಶಲ್ಯವಾಗಿದೆ." ಓದಬಹುದಾದ ಕೋಡ್ ಕಲೆ.

ನಾವು ನೆನಪಿಸುತ್ತೇವೆ: ಎಲ್ಲಾ Habr ಓದುಗರಿಗೆ - Habr ಪ್ರೊಮೊ ಕೋಡ್ ಬಳಸಿಕೊಂಡು ಯಾವುದೇ ಸ್ಕಿಲ್‌ಬಾಕ್ಸ್ ಕೋರ್ಸ್‌ಗೆ ದಾಖಲಾಗುವಾಗ 10 ರೂಬಲ್ ರಿಯಾಯಿತಿ.

ಸ್ಕಿಲ್‌ಬಾಕ್ಸ್ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ: ಪ್ರಾಯೋಗಿಕ ಕೋರ್ಸ್ "ಮೊಬೈಲ್ ಡೆವಲಪರ್ ಪ್ರೊ".

ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಕಲೆ. ಮತ್ತು ನೀವು ಈ ಕಲೆಯ ಮಾಸ್ಟರ್ಸ್.
ಕೆಲವೊಮ್ಮೆ, ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಪ್ರಯತ್ನದಲ್ಲಿ, ಕೈಯಲ್ಲಿರುವ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದನ್ನು ಬಿಟ್ಟು ಬೇರೆ ಯಾವುದರ ಬಗ್ಗೆಯೂ ನಾವು ಯೋಚಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಇನ್ನಷ್ಟು ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು.

ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಯಾವುದಕ್ಕೆ ಕಣ್ಣು ಮುಚ್ಚುತ್ತಾರೆ?

ನೀವು ಬರೆಯುವ ಎಲ್ಲಾ ಕೋಡ್ ಇತರ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅರ್ಥವಾಗುವಂತಿರಬೇಕು ಮತ್ತು ಪರೀಕ್ಷಿಸಬೇಕು ಮತ್ತು ಡೀಬಗ್ ಮಾಡಬೇಕು.

ಆದರೆ ಸಮಸ್ಯೆ ಇದೆ: ನೀವು ಏನೇ ಬರೆದರೂ ಅದು ನಿಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ದೋಷಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ.

ರಿಚ್ ಸ್ಕ್ರೆಂಟ್ ಪ್ರಕಾರ, ಕೋಡ್ ನಮ್ಮ ಶತ್ರು. ಅವರು ಬರೆಯುವುದು ಇಲ್ಲಿದೆ:

"ಕೋಡ್ ಕೆಟ್ಟದಾಗಿದೆ ಏಕೆಂದರೆ ಅದು ಕೊಳೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ನಿರಂತರ ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿರುತ್ತದೆ. ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಸಾಮಾನ್ಯವಾಗಿ ಹಳೆಯ ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿದೆ. ಇದು ದೊಡ್ಡದಾಗಿದೆ, ದೋಷ ಸಂಭವಿಸುವ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆ ಮತ್ತು ಕಂಪೈಲ್ ಮಾಡಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಇನ್ನೊಬ್ಬ ಡೆವಲಪರ್‌ಗೆ ಹೆಚ್ಚಿನ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅಗತ್ಯವಿದ್ದರೆ, ಖಂಡಿತವಾಗಿಯೂ ಬದಲಾಯಿಸಲು ಯೋಗ್ಯವಾದ ತುಣುಕುಗಳು ಇರುತ್ತವೆ. ದೊಡ್ಡ ಕೋಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ ನಮ್ಯತೆ ಮತ್ತು ಯೋಜನೆಯ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಅರ್ಥೈಸುತ್ತದೆ. ಸರಳ ಮತ್ತು ಸೊಗಸಾದ ಪರಿಹಾರವು ಸಂಕೀರ್ಣ ಕೋಡ್‌ಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ.

ಕೋಡ್ ಅನ್ನು ಯಾವಾಗ ಬರೆಯಬಾರದು ಎಂದು ನಿಮಗೆ ಹೇಗೆ ಗೊತ್ತು?

ಸಮಸ್ಯೆಯೆಂದರೆ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ತಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯವಿರುವ ವೈಶಿಷ್ಟ್ಯಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಾಗಿ ಉತ್ಪ್ರೇಕ್ಷಿಸುತ್ತಾರೆ. ಪರಿಣಾಮವಾಗಿ, ಕೋಡ್‌ನ ಹಲವು ವಿಭಾಗಗಳು ಅಪೂರ್ಣವಾಗಿಯೇ ಉಳಿದಿವೆ ಅಥವಾ ಯಾರೂ ಅವುಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಆದರೆ ಅವುಗಳು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತವೆ.

ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಏನು ಬೇಕು ಮತ್ತು ಏನು ಇಲ್ಲ ಎಂಬುದನ್ನು ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

ಒಂದು ಉದಾಹರಣೆಯೆಂದರೆ ಕೇವಲ ಒಂದು ಕಾರ್ಯವನ್ನು ಪರಿಹರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ - ಇಮೇಲ್ ನಿರ್ವಹಿಸುವುದು. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ಎರಡು ಕಾರ್ಯಗಳನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ - ಪತ್ರಗಳನ್ನು ಕಳುಹಿಸುವುದು ಮತ್ತು ಸ್ವೀಕರಿಸುವುದು. ಮೇಲ್ ನಿರ್ವಾಹಕರು ಅದೇ ಸಮಯದಲ್ಲಿ ಕಾರ್ಯ ನಿರ್ವಾಹಕರಾಗುತ್ತಾರೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸಬಾರದು.

ಅಪ್ಲಿಕೇಶನ್‌ನ ಮುಖ್ಯ ಕಾರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲು ನೀವು ಪ್ರಸ್ತಾಪಗಳಿಗೆ "ಇಲ್ಲ" ಎಂದು ದೃಢವಾಗಿ ಹೇಳಬೇಕಾಗಿದೆ. ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾದ ಕ್ಷಣ ಇದು.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಗಮನವನ್ನು ಎಂದಿಗೂ ಕಳೆದುಕೊಳ್ಳಬೇಡಿ.

ಯಾವಾಗಲೂ ನಿಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳಿ:

- ಈಗ ಯಾವ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು?
- ನಾನು ಯಾವ ಕೋಡ್ ಬರೆಯಬೇಕು?

ಮನಸ್ಸಿಗೆ ಬರುವ ವಿಚಾರಗಳನ್ನು ಪ್ರಶ್ನಿಸಿ ಮತ್ತು ಹೊರಗಿನಿಂದ ಬರುವ ಸಲಹೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ. ಇಲ್ಲದಿದ್ದರೆ, ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಕೇವಲ ಯೋಜನೆಯನ್ನು ಕೊಲ್ಲಬಹುದು.

ಅನಗತ್ಯ ವಿಷಯಗಳನ್ನು ಯಾವಾಗ ಸೇರಿಸಬಾರದು ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ನಿಮ್ಮ ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಸಂಸ್ಥೆಯ ನಿಯಂತ್ರಣದಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಅಗತ್ಯ ಡೆವಲಪರ್ ಕೌಶಲ್ಯ

ಮಾರ್ಗದ ಪ್ರಾರಂಭದಲ್ಲಿ, ಪ್ರೋಗ್ರಾಮರ್ ಕೇವಲ ಎರಡು ಅಥವಾ ಮೂರು ಮೂಲ ಫೈಲ್ಗಳನ್ನು ಹೊಂದಿದೆ. ಇದು ಸರಳವಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡಲು ಮತ್ತು ಪ್ರಾರಂಭಿಸಲು ಕನಿಷ್ಠ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ; ಎಲ್ಲಿ ಮತ್ತು ಯಾವುದನ್ನು ನೋಡಬೇಕು ಎಂಬುದು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ವಿಸ್ತರಿಸಿದಂತೆ, ಹೆಚ್ಚು ಹೆಚ್ಚು ಕೋಡ್ ಫೈಲ್‌ಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಅವರು ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ತುಂಬುತ್ತಾರೆ, ಪ್ರತಿಯೊಂದೂ ನೂರಾರು ಸಾಲುಗಳೊಂದಿಗೆ. ಇದೆಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಸಂಘಟಿಸಲು, ನೀವು ಹೆಚ್ಚುವರಿ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ರಚಿಸಬೇಕಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಯಾವ ಕಾರ್ಯಗಳು ಯಾವುದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ ಮತ್ತು ಯಾವ ಕ್ರಿಯೆಗಳು ಕಾರಣವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗುತ್ತಿದೆ; ದೋಷಗಳನ್ನು ಹಿಡಿಯಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಪ್ರಾಜೆಕ್ಟ್ ನಿರ್ವಹಣೆಯು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿದೆ; ಒಂದಲ್ಲ, ಆದರೆ ಹಲವಾರು ಡೆವಲಪರ್‌ಗಳು ಎಲ್ಲವನ್ನೂ ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಅಂತೆಯೇ, ವಿತ್ತೀಯ ಮತ್ತು ಸಮಯ ಎರಡೂ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯು ನಿಧಾನಗೊಳ್ಳುತ್ತದೆ.

ಯೋಜನೆಯು ಅಂತಿಮವಾಗಿ ದೊಡ್ಡದಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸುವುದು ಹೆಚ್ಚು ಹೆಚ್ಚು ಶ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ತೀರಾ ಅತ್ಯಲ್ಪ ವಿಷಯಕ್ಕೆ ಸಹ ನೀವು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಕಳೆಯಬೇಕಾಗುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದರಿಂದ ಹೊಸವುಗಳ ಗೋಚರಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬಿಡುಗಡೆಯ ಗಡುವನ್ನು ತಪ್ಪಿಸಲಾಗುತ್ತದೆ.

ಈಗ ನಾವು ಯೋಜನೆಯ ಜೀವಕ್ಕಾಗಿ ಹೋರಾಡಬೇಕಾಗಿದೆ. ಏಕೆ?

ಸತ್ಯವೆಂದರೆ ನೀವು ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಅನ್ನು ಯಾವಾಗ ಸೇರಿಸಬಾರದು ಎಂದು ನಿಮಗೆ ಅರ್ಥವಾಗಲಿಲ್ಲ ಮತ್ತು ಪ್ರತಿ ಸಲಹೆ ಮತ್ತು ಕಲ್ಪನೆಗೆ "ಹೌದು" ಎಂದು ಉತ್ತರಿಸಿದೆ. ನೀವು ಕುರುಡರಾಗಿದ್ದೀರಿ, ಹೊಸ ವಿಷಯಗಳನ್ನು ರಚಿಸುವ ಬಯಕೆಯು ಪ್ರಮುಖ ಸಂಗತಿಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವಂತೆ ಮಾಡಿದೆ.

ಭಯಾನಕ ಚಲನಚಿತ್ರ ಸ್ಕ್ರಿಪ್ಟ್‌ನಂತೆ ಧ್ವನಿಸುತ್ತದೆ, ಸರಿ?

ನೀವು ಹೌದು ಎಂದು ಹೇಳುತ್ತಿದ್ದರೆ ಇದು ನಿಖರವಾಗಿ ಏನಾಗುತ್ತದೆ. ಕೋಡ್ ಅನ್ನು ಯಾವಾಗ ಸೇರಿಸಬಾರದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸಿ. ಯೋಜನೆಯಿಂದ ಅನಗತ್ಯ ವಿಷಯಗಳನ್ನು ತೆಗೆದುಹಾಕಿ - ಇದು ನಿಮ್ಮ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಜೀವನವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

"ನಾನು 1000 ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ಅಳಿಸಿದಾಗ ನನ್ನ ಅತ್ಯಂತ ಉತ್ಪಾದಕ ದಿನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ."
- ಕೆನ್ ಥಾಂಪ್ಸನ್.

ಕೋಡ್ ಅನ್ನು ಯಾವಾಗ ಬರೆಯಬಾರದು ಎಂಬುದನ್ನು ಕಲಿಯುವುದು ಕಷ್ಟ. ಆದರೆ ಇದು ಅಗತ್ಯ.

ಹೌದು, ನೀವು ಇದೀಗ ಡೆವಲಪರ್‌ನ ಹಾದಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೀರಿ ಮತ್ತು ಕೋಡ್ ಬರೆಯಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ಇದು ಒಳ್ಳೆಯದು, ಮೊದಲ ಆಕರ್ಷಣೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳಬೇಡಿ, ಆದರೆ ಉತ್ಸಾಹದಿಂದ ಪ್ರಮುಖ ಅಂಶಗಳ ದೃಷ್ಟಿ ಕಳೆದುಕೊಳ್ಳಬೇಡಿ. ಪ್ರಯೋಗ ಮತ್ತು ದೋಷದ ಮೂಲಕ ನಾವು ಎಲ್ಲವನ್ನೂ ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ನೀವು ಸಹ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಅವರಿಂದ ಕಲಿಯುವಿರಿ. ಆದರೆ ಮೇಲಿನಿಂದ ನೀವು ಕಲಿಯಬಹುದಾದರೆ, ನಿಮ್ಮ ಕೆಲಸವು ಹೆಚ್ಚು ಜಾಗೃತವಾಗುತ್ತದೆ.

ರಚಿಸುವುದನ್ನು ಮುಂದುವರಿಸಿ, ಆದರೆ ಯಾವಾಗ ಬೇಡ ಎಂದು ಹೇಳಬೇಕೆಂದು ತಿಳಿಯಿರಿ.

ಸ್ಕಿಲ್‌ಬಾಕ್ಸ್ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ:

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ