𝗙𝗿𝗼𝗺 𝗤𝗔 𝘁𝗼 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁
AI ಕೋಡ್ ಎಡಿಟರ್ಗಳು ಈಗ ಹೆಚ್ಚಿನ ಬಾಯ್ಲರ್ಪ್ಲೇಟ್ (boilerplate) ಕೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಿವೆ. ಇದು ಒಂದು ಅಪಾಯಕಾರಿ ಭ್ರಮೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತಿದೆ. AI ಕೋಡ್ ಬರೆದು ಅದು ಕಾಂಪೈಲ್ (compile) ಆದರೆ, ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ತಂಡಗಳು ಭಾವಿಸುತ್ತಿವೆ.
ಈ ಮನೋಭಾವವು ಸಣ್ಣ ಫೀಚರ್ಗಳಿಗೆ (features) ಕೆಲಸ ಮಾಡಬಹುದು. ಆದರೆ ಡಿಸೈನ್ ಸಿಸ್ಟಮ್ಗಳಿಗೆ (design systems) ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
ಡಿಸೈನ್ ಸಿಸ್ಟಮ್ ಕಾಂಪೊನೆಂಟ್ ಎಂಬುದು ಕೇವಲ ಒಂದು ಬಾರಿಯ ಫೀಚರ್ ಅಲ್ಲ. ಅದು ಮೂಲಸೌಕರ್ಯ (infrastructure). ಒಂದು ಬಟನ್ ಅಥವಾ ಇನ್ಪುಟ್ ಫೀಲ್ಡ್ ನೂರಾರು ಉತ್ಪನ್ನಗಳ ಮೂಲಕ ಲಕ್ಷಾಂತರ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ.
ನಿಜವಾದ ಅನುಕೂಲವು ನೀವು ಎಷ್ಟು ವೇಗವಾಗಿ ಕೋಡ್ ಬರೆಯುತ್ತೀರಿ ಎಂಬುದಲ್ಲ; ಬದಲಾಗಿ ನೀವು ವೈಫಲ್ಯವನ್ನು (failure) ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಊಹಿಸುತ್ತೀರಿ ಎಂಬುದರಲ್ಲಿದೆ.
ನೀವು 'ಬಿಲ್ಡರ್' (builder) ಮನೋಭಾವದಿಂದ 'ಬ್ರೇಕರ್' (breaker) ಮನೋಭಾವಕ್ಕೆ ಬದಲಾಗಬೇಕು. ನೀವು TDD, BDD ಮತ್ತು Spec-Driven Development ಮೂಲಕ ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
ಹೆಚ್ಚಿನ ತಂಡಗಳು "Happy Path" ಗಾಗಿ ನಿರ್ಮಿಸುತ್ತವೆ. ಅವರು Figma ಫೈಲ್ ಅನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿ ಅಲ್ಲಿಗೆ ನಿಲ್ಲುತ್ತಾರೆ. ಆದರೆ ಕಾಂಪೊನೆಂಟ್ಗಳು ನೈಜ ಪ್ರಪಂಚದ ಗೊಂದಲಗಳನ್ನು ಎದುರಿಸುವಂತಿರಬೇಕು.
ಒಂದು ಬಲಿಷ್ಠ ತಂಡವು ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು ಕಠಿಣ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತದೆ:
- ಡಿಸೈನರ್ಗಳು: ಒಂದು ಟೆಕ್ಸ್ಟ್ ಸ್ಟ್ರಿಂಗ್ (text string) 400 ಅಕ್ಷರಗಳ ಉದ್ದವಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? UI ಹಾಳಾಗುತ್ತದೆಯೇ?
- ಎಂಜಿನಿಯರ್ಗಳು: ಬಳಕೆದಾರರು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹತ್ತು ಬಾರಿ ಟೋಗಲ್ (toggle) ಕ್ಲಿಕ್ ಮಾಡಿದರೆ ಏನಾಗುತ್ತದೆ? ಸ್ಟೇಟ್ (state) ದೋಷಗ್ರಸ್ತವಾಗುತ್ತದೆಯೇ?
- ಅಕ್ಸೆಸಿಬಿಲಿಟಿ (Accessibility): ಕೇವಲ ಕೀಬೋರ್ಡ್ ಬಳಸಿ ಈ ಡ್ರಾಪ್ಡೌನ್ ಅನ್ನು ಸ್ಕ್ರೀನ್ ರೀಡರ್ ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ?
AI ಪರಿಕರಗಳು ಕೋಡ್ ಬರೆಯಲು ಉತ್ತಮವಾಗಿವೆ ಆದರೆ ಊಹೆ ಮಾಡುವಲ್ಲಿ (assumptions) ಕಳಪೆ. ಅವು ಅಸ್ಥಿರವಾದ (brittle) ಕಾಂಪೊನೆಂಟ್ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ.
ನಿಮ್ಮ ಕೆಲಸವನ್ನು ರಕ್ಷಿಸಲು ಈ ವರ್ಕ್ಫ್ಲೋ (workflow) ಬಳಸಿ:
- ಸ್ಪೆಕ್ (Spec - Tokens, Accessibility, API) ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ.
- ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಲು ಮೊದಲು ಟೆಸ್ಟ್ಗಳು ಮತ್ತು ಸ್ಟೋರಿಗಳನ್ನು ಬರೆಯಿರಿ.
- ಆ ಮಿತಿಗಳ ಒಳಗೆ ಕೋಡ್ ಜನರೇಟ್ ಮಾಡಲು AI ಬಳಸಿ.
TDD ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉಲ್ಟಾ ಮಾಡುತ್ತದೆ. ನಂತರ ಬಗ್ಗಳನ್ನು (bugs) ಸರಿಪಡಿಸುವ ಬದಲು, ನೀವು ಮೊದಲೇ ಮಿತಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೀರಿ. ನಂತರ AI ಆ ಟೆಸ್ಟ್ಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ.
Behavior-Driven Development (BDD) ಕೂಡ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದು ಡಿಸೈನ್ ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮಾನವ ಭಾಷೆಯನ್ನು ಬಳಸುತ್ತದೆ.
ಉದಾಹರಣೆ:
- ಬಳಕೆದಾರರಿಗೆ ನಿಧಾನಗತಿಯ ಸಂಪರ್ಕವಿದ್ದರೆ,
- ಅವರು ಸಬ್ಮಿಟ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ,
- ಆಗ ಬಟನ್ ಲೋಡಿಂಗ್ ಸ್ಟೇಟ್ (loading state) ಅನ್ನು ತೋರಿಸಬೇಕು ಮತ್ತು ಕ್ಲಿಕ್ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು.
ಕೆಲವು ನಾಯಕರು ಟೆಸ್ಟಿಂಗ್ ವೇಗವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಎಂದು ಹೆದರುತ್ತಾರೆ. ಇದು ತಪ್ಪು.
ಆರಂಭಿಕ ಕೋಡಿಂಗ್ ಒಂದು ಕಾಂಪೊನೆಂಟ್ನ ವೆಚ್ಚದ ಕೇವಲ 5% ಮಾತ್ರ. ಉಳಿದ 95% ನಿರ್ವಹಣೆ (maintenance) ಮತ್ತು ಬಗ್ಗಳನ್ನು ಸರಿಪಡಿಸಲು ಬಳಕೆಯಾಗುತ್ತದೆ.
ಟೆಸ್ಟಿಂಗ್ ಮನೋಭಾವವು ನಿಮಗೆ ಇವುಗಳನ್ನು ನೀಡುತ್ತದೆ:
- ನೀವು ರಿಫ್ಯಾಕ್ಟರ್ (refactor) ಮಾಡುವಾಗ ಕಡಿಮೆ ರಿಗ್ರೆಷನ್ಗಳು (regressions) ಸಂಭವಿಸುತ್ತವೆ.
- ಇತರ ಡೆವಲಪರ್ಗಳಿಗಾಗಿ ಸೆಲ್ಫ್-ಸರ್ವಿಸ್ ಸಿಸ್ಟಮ್ (self-service system).
- ಸಾಂಸ್ಥಿಕ ನಂಬಿಕೆ (Organizational trust).
AI ಜಗತ್ತಿನಲ್ಲಿ, ಕೋಡಿಂಗ್ ವೇಗವು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಸಿಸ್ಟಮ್ಸ್ ಥಿಂಕಿಂಗ್ (Systems thinking) ಅಪರೂಪವಾಗಿದೆ.
ವೇಗವಾಗಿ ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಮುರಿಯುವಂತಿರುವಂತೆ (to break) ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸಿ.
ನಿಮ್ಮ ತಂಡವು ವೇಗ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದ (resilience) ನಡುವೆ ಸಮತೋಲನವನ್ನು ಹೇಗೆ ಕಾಪಾಡಿಕೊಳ್ಳುತ್ತದೆ? ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ತಿಳಿಸಿ.