ಕೋಡ್‌ನಾಚೆ

ಒಬ್ಬ ಉತ್ತಮ software engineer ಆಗಿರುವುದು, ಕೆಲಸ ಮಾಡುವ code ಬರೆಯುವುದರಷ್ಟೇ ಅಲ್ಲ. ಇತರರು (ಭವಿಷ್ಯದ ನೀವು ಸಹ) ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಿರ್ವಹಿಸಲು, ಮತ್ತು ಅದೇ ಮೇಲೇ ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗುವ code ಬರೆಯುವುದೂ ಅದರಲ್ಲಿ ಸೇರಿದೆ. ಸ್ಪಷ್ಟವಾಗಿ ಸಂವಹನ ಮಾಡುವುದು, ವಿಚಾರಪೂರ್ವಕವಾಗಿ ಕೊಡುಗೆ ನೀಡುವುದು, ಮತ್ತು ನೀವು ಭಾಗವಹಿಸುವ ecosystem ಗಳಲ್ಲಿ - ಅವು open source ಆಗಿರಲಿ ಅಥವಾ proprietary ಆಗಿರಲಿ - ಉತ್ತಮ ನಾಗರಿಕರಂತೆ ನಡೆದುಕೊಳ್ಳುವುದೂ ಅಷ್ಟೇ ಮುಖ್ಯ.

ಏಕದಿಶ ಸಂವಹನ

software engineering ನ ಬಹುಪಾಲು ಕೆಲಸವು ನಿಮ್ಮ ಇಂದಿನ ಸಂದರ್ಭ ತಿಳಿಯದ ಜನರಿಗಾಗಿ ಬರೆಯುವುದನ್ನು ಒಳಗೊಂಡಿದೆ: ನಂತರ ಸೇರಿಕೊಳ್ಳುವ teammates, ನಿಮ್ಮ code ಅನ್ನು ಪಾರಂಪರ್ಯವಾಗಿ ಸ್ವೀಕರಿಸುವ maintainers, ಅಥವಾ ಆರು ತಿಂಗಳ ನಂತರ ನೀವು ಏಕೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಆಯ್ಕೆಯನ್ನು ಮಾಡಿದ್ದೀರಿ ಎಂಬುದನ್ನೇ ಮರೆತಿರುವ ನಿಮ್ಮದೇ ಸ್ವರೂಪ. ಇಂತಹ ಬರವಣಿಗೆಯ ಮುಖ್ಯ ಸಲಹೆ ಏನೆಂದರೆ - ನಿಮ್ಮ ಗುರಿ ಕೇವಲ what ಅನ್ನು ದಾಖಲಿಸುವುದಲ್ಲ, why ಅನ್ನು ಹಿಡಿದು ಸ್ಪಷ್ಟವಾಗಿ ಹಂಚುವುದಾಗಿರಬೇಕು. what ಸಾಮಾನ್ಯವಾಗಿ code ನಿಂದಲೇ ಗೊತ್ತಾಗುತ್ತದೆ; why ಮಾತ್ರ ಕಷ್ಟಪಟ್ಟು ಗಳಿಸಿದ ಜ್ಞಾನವಾಗಿದ್ದು, ಕಾಲಕ್ರಮೇಣ ಸುಲಭವಾಗಿ ಕಳೆದುಹೋಗುತ್ತದೆ.

ಬಹುಶಃ engineer-to-engineer ಸಂವಹನದ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ರೂಪ (code ನ ಹೊರತಾಗಿ) code comments ಆಗಿದೆ. ನನ್ನ ಅನುಭವದಲ್ಲಿ ಅನೇಕ code comments ಉಪಯೋಗಕಾರಿಯಾಗಿಲ್ಲ. ಆದರೆ ಅದು ಅನಿವಾರ್ಯವಲ್ಲ. ಉತ್ತಮ comments ಗಳು code ತಾನೇ ಹೇಳಲಾರದ ಸಂಗತಿಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ: ಯಾವುದನ್ನಾದರೂ ನಿರ್ದಿಷ್ಟ ರೀತಿಯಲ್ಲಿ ಏಕೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು, ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅಲ್ಲ (ಅದನ್ನು code ತೋರಿಸುತ್ತದೆ). ಉತ್ತಮ comments ಗಳು ಗಂಟೆಗಳ ಗೊಂದಲ ತಪ್ಪಿಸುತ್ತವೆ; ದುರ್ಬಲ comments ಗಳು ಶಬ್ದ ಮಾತ್ರ ಹೆಚ್ಚಿಸಬಹುದು, ಅಥವಾ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ ತಪ್ಪುದಾರಿಗೆ ನಡೆಸಬಹುದು.

ತೀರಾ ಬಹುಶಃ ಯಾವಾಗಲೂ ಉಪಯುಕ್ತವಾಗಿರುವ comment ಪ್ರಕಾರಗಳು:

• TODOs: ಅಪೂರ್ಣ ಅಥವಾ ಇನ್ನೂ ತಿದ್ದಬೇಕಿರುವ code ಅನ್ನು ಗುರುತಿಸಿ; ಆದರೆ ಉಳಿದಿರುವ ಕೆಲಸ ಏನು ಮತ್ತು ಅದು ಏಕೆ ಮುಂದೂಡಲಾಯಿತು ಎಂಬುದನ್ನು ಮತ್ತೊಬ್ಬರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಷ್ಟು ಸಂದರ್ಭವನ್ನು ನೀಡಿ. “TODO: optimize” ಉಪಯೋಗವಿಲ್ಲ; “TODO: this O(n²) loop is fine for n<100, but will need indexing if we scale” ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಸೂಚನೆ.
• References: code ಯಾವುದೇ paper ನ algorithm ಅನ್ನು ಜಾರಿಗೊಳಿಸಿದಾಗ, ಬೇರೆಡೆಗಿನ code ಅನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡಿದಾಗ, ಅಥವಾ documentation ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ behaviour ಅನ್ನು ಒಳಗೊಂಡಿದ್ದಾಗ, ಹೊರಗಿನ ಮೂಲಗಳಿಗೆ link ನೀಡಿ. permalinks ಬಳಸಿ. reference ನಿಂದ ಇರುವ ಭಿನ್ನತೆಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಮೂದಿಸಿ.
• Correctness arguments: ಸರಳವಲ್ಲದ code ಸರಿಯಾದ ಫಲಿತಾಂಶ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ಏಕೆ ಎಂದು ವಿವರಿಸಿ. code ಕ್ರಮಗಳನ್ನು ತೋರಿಸುತ್ತದೆ; comment ಆ ಕ್ರಮಗಳು ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತದೆ.
• Hard-learned lessons: ಯಾವುದನ್ನಾದರೂ debug ಮಾಡಲು 30+ ನಿಮಿಷ ತೆಗೆದುಕೊಂಡು, ಪರಿಹಾರವು ತಕ್ಷಣ ಗೋಚರಿಸದ incantation ಆಗಿದ್ದರೆ, ಅದನ್ನು ದಾಖಲಿಸಿ. ಹಳೆಯ ನಿಮಗೆ ಅದು ಬೇಕೆಂದು ತಿಳಿದಿರಲಿಲ್ಲ; ಭವಿಷ್ಯದ ಓದುಗರಿಗೂ ಹಾಗೆಯೇ ಇರಬಹುದು.
• Rationale for constants: Magic numbers ಗೆ ವಿವರಣೆ ಅಗತ್ಯ. 1492 ಏಕೆ? 16 bits ಏಕೆ? ಅದು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲ್ಪಟ್ಟದೇ, testing ನಿಂದ ಬಂದದೇ, ಅಥವಾ correctness ಗೆ ಅವಶ್ಯವೇ? “chosen arbitrarily” ಎಂಬ ಮಾಹಿತಿ ಸಹ ಉಪಯುಕ್ತವೇ.
• Load-bearing choices: correctness ತೋರಿಕೆಗೆ ಸಾಮಾನ್ಯ implementation detail ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ (ಉದಾ., “must be a BTreeSet because iteration order matters below”), ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ.
• “Why not”s: ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುವ ವಿಧಾನವನ್ನು ತಪ್ಪಿಸಿದರೆ, ಏಕೆ ಎಂದು ವಿವರಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ ನಂತರ ಯಾರಾದರೂ ಅದನ್ನು “ಸರಿಪಡಿಸಲು” ಹೋಗಿ ವ್ಯವಸ್ಥೆ ಹಾಳು ಮಾಡಬಹುದು.

READMEs (ನಿಮ್ಮದೂ ಇದೆ, ಅಲ್ಲವೇ?) ಕೂಡ ಇತರ developers ಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲ ಸ್ಪರ್ಶಬಿಂದು. ಒಂದು ಉತ್ತಮ README ತಕ್ಷಣ ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು: ಇದು ಏನು ಮಾಡುತ್ತದೆ? ನಾನು ಇದನ್ನು ಏಕೆ ಗಮನಿಸಬೇಕು? ಇದನ್ನು ಹೇಗೆ ಬಳಸುವುದು? ಇದನ್ನು ಹೇಗೆ install ಮಾಡುವುದು? ಇದೇ ಕ್ರಮದಲ್ಲಿ. ಇದನ್ನು funnel ಮಾದರಿಯಲ್ಲಿ ರೂಪಿಸಿ: ಮೇಲ್ಭಾಗದಲ್ಲಿ ಒಂದು one-liner ಮತ್ತು ಸಾಧ್ಯವಾದರೆ ಒಂದು visual demo ಇರಿ, ಇದರಿಂದ ಯಾರಾದರೂ ಕೆಲವೇ ಕ್ಷಣಗಳಲ್ಲಿ ಇದರಿಂದ ತಮ್ಮ ಸಮಸ್ಯೆ ಬಗೆಹರಿಯುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು. ನಂತರ ಹಂತ ಹಂತವಾಗಿ ಆಳವಾದ ವಿವರ ಸೇರಿಸಿ. installation ಗಿಂತ ಮೊದಲು usage ತೋರಿಸಿ - setup ಹಂತಗಳಿಗೆ ಬದ್ಧರಾಗುವ ಮೊದಲು ಅವರು ಏನು ಪಡೆಯುತ್ತಿದ್ದಾರೆ ಎಂಬುದು ಜನರಿಗೆ ತಿಳಿಯಬೇಕಿರುತ್ತದೆ.

commit messages ಕೂಡ ಬಹುಸಾರಿ ನಿರ್ಲಕ್ಷ್ಯಗೊಳ್ಳುವ “ಇತರರಿಗಾಗಿ ಬರವಣಿಗೆ”ಯ ಪ್ರಮುಖ ರೂಪ. ಅವುಗಳನ್ನು ಅನೇಕ ಬಾರಿ “fixed blah” ಅಥವಾ “added foo” ಎಂಬಂತೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಕೆಲ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ಸಾಕಾಗಬಹುದು, ಆದರೆ codebase ಏಕೆ ಈ ರೀತಿಯಲ್ಲಿ ಬದಲಾಗಿದೆ ಎಂಬ ಇತಿಹಾಸದ ದಾಖಲೆಯನ್ನು ಅವೇ ನಿರ್ಮಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಮರೆತಬಾರದು. ಯಾರಾದರೂ (ನಿಮ್ಮೂ ಸೇರಿ) ಗೊಂದಲಕಾರಿ ಬದಲಾವಣೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು git blame ಚಲಾಯಿಸಿದಾಗ, ಉತ್ತಮ commit messages ಉತ್ತರಗಳನ್ನು ನೀಡಬೇಕು.

ಸಾಮಾನ್ಯವಾಗಿ commit body ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು:

• ಈ ಬದಲಾವಣೆಯನ್ನು ಅನಿವಾರ್ಯಗೊಳಿಸಿದ ಸಮಸ್ಯೆ ಯಾವುದು?
• ನೀವು ಯಾವ ಪರ್ಯಾಯಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೀರಿ?
• trade-offs ಅಥವಾ implications ಯಾವುವು?
• ಈ ವಿಧಾನದಲ್ಲಿ ಅಚ್ಚರಿಯಾಯಕವೆನಿಸಬಹುದಾದ ಅಂಶ ಏನು?

ಸ್ಪಷ್ಟವಾಗಿಯೇ, ವಿವರದ ಪ್ರಮಾಣವನ್ನು complexity ಗೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸಬೇಕು. ಒಂದು ಸಾಲಿನ typo fix ಗೆ subject ಸಾಲು ಸಾಕು. ಹಲವು ಗಂಟೆಗಳ debug ನಂತರ ಸರಿಪಡಿಸಿದ ಸೂಕ್ಷ್ಮ race condition ಗೆ ಸಮಸ್ಯೆ ಮತ್ತು ಪರಿಹಾರವನ್ನು ವಿವರಿಸುವ ಕೆಲವು ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ.

ಸಂಕೀರ್ಣ ಬದಲಾವಣೆಗಳಲ್ಲಿ Problem → Solution → Implications ರಚನೆ ಅನುಸರಿಸುವುದು ಉಪಯುಕ್ತ. ಮೊದಲಿಗೆ ಬದಲಾವಣೆಯನ್ನು ಒತ್ತಾಯಿಸಿದ ಕಾರಣ ಅಥವಾ ಮಿತಿ ಏನು ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ; ನಂತರ ಏನು ಬದಲಾಗಿದೆ ಮತ್ತು ಪ್ರಮುಖ design ನಿರ್ಣಯಗಳು ಯಾವುವು ಎಂದು ವಿವರಿಸಿ; ಕೊನೆಯಲ್ಲಿ ಗಮನಾರ್ಹ ಪರಿಣಾಮಗಳನ್ನು (ಧನಾತ್ಮಕ ಹಾಗೂ ಋಣಾತ್ಮಕ) ಪಟ್ಟಿ ಮಾಡಿ. ಈ ಕೊನೆಯ ಭಾಗ ಅತ್ಯಂತ ಪ್ರಮುಖ. ನಿಜವಾದ engineering ಅನೇಕ ಚಿಂತೆಗಳ ಸಮತೋಲನವಾಗಿದ್ದು, trade-off ಉದ್ದೇಶಿತವಾಗಿತ್ತು ಎಂದು ದಾಖಲಿಸಿದರೆ, ಭವಿಷ್ಯದ developers ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಗಮನಿಸದೆ ಬಿಟ್ಟಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸುವುದಿಲ್ಲ.

commit messages ಬರೆಯುವಲ್ಲಿ LLMs ಉಪಯುಕ್ತ_ವಾಗಬಹುದು. ಆದರೆ ನಿಮ್ಮ ಬದಲಾವಣೆಯನ್ನು ಮಾತ್ರ ತೋರಿಸಿ commit message ಬರೆಯಲು ಹೇಳಿದರೆ, LLM ಗೆ _what ಮಾತ್ರ ಗೋಚರಿಸುತ್ತದೆ, why ಅಲ್ಲ. ಫಲವಾಗಿ ಸಿಗುವ commit message ಬಹುತೇಕ ವರ್ಣನಾತ್ಮಕವಾಗಿರುತ್ತದೆ (ನಮಗೆ ಬೇಕಾದುದಕ್ಕೆ ವಿರೋಧವಾಗಿ). ಬದಲಾವಣೆಯನ್ನು ಮಾಡಿಸುವಲ್ಲೇ ನೀವು LLM ಸಹಾಯ ಪಡೆದಿದ್ದರೆ, ಅದೇ session ನಲ್ಲಿ commit ಕೂಡ ಅದರಿಂದ ಬರೆಯಿಸಿಕೊಳ್ಳುವುದು ಹೆಚ್ಚು ಉತ್ತಮ - ಏಕೆಂದರೆ ನಿಮ್ಮ ಸಂಭಾಷಣೆ ಬದಲಾವಣೆಯ ಕುರಿತ ಸಮೃದ್ಧ context ಒದಗಿಸುತ್ತದೆ. ಇದಲ್ಲದೇ, ಅಥವಾ ಇದರ ಜೊತೆಗೆ, “why” ಕೇಂದ್ರಿತ commit message ಬೇಕು (ಮೇಲಿನ ಸೂಚನೆಗಳಲ್ಲಿನ ಇತರೆ ಸೂಕ್ಷ್ಮಾಂಶಗಳೂ ಸೇರಿ) ಎಂದು LLM ಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ; ನಂತರ ಕಡಿಮೆಯಿರುವ ಸಂದರ್ಭಕ್ಕಾಗಿ ನಿಮಗೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಅದಕ್ಕೆ ಸೂಚಿಸಿ. ಅರ್ಥಾತ್, coding agent ಗೆ context “read” ಮಾಡಲು ಬಳಸಬಹುದಾದ MCP “tool” ಆಗಿ ನೀವು ತಾವೇ ವರ್ತಿಸುತ್ತಿದ್ದೀರಿ.

ನಿಮ್ಮ ಬದಲಾವಣೆಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಾ ಹೋದಂತೆ commits ಅನ್ನು ತಾರ್ಕಿಕವಾಗಿ ವಿಭಜಿಸುತ್ತಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ (git add -p ನಿಮಗೆ ಸಹಕಾರಿ). ಪ್ರತಿಯೊಂದು commit ಸ್ವತಂತ್ರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು review ಮಾಡಲು ಸಾಧ್ಯವಾಗುವ ಒಂದು ಸಮ್ಮೇಳಿತ ಬದಲಾವಣೆಯನ್ನು ಪ್ರತಿನಿಧಿಸಬೇಕು. refactoring ಅನ್ನು ಹೊಸ features ಜೊತೆ ಮಿಶ್ರಣ ಮಾಡಬೇಡಿ; ಸಂಬಂಧವಿಲ್ಲದ bug fixes ಗಳನ್ನು ಸೇರಿಸಬೇಡಿ. ಹೀಗೆ ಮಾಡಿದರೆ ಯಾವ ಬದಲಾವಣೆಯಿಂದ ಯಾವ ಸಮಸ್ಯೆ ಬಗೆಹರಿಯಿತು ಎಂಬ ಕಥನ ಅಸ್ಪಷ್ಟವಾಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ review ಬಹುಶಃ ನಿಧಾನಗೊಳ್ಳುತ್ತದೆ. ಇದು git bisect ಮೂಲಕ ನಿಮಗೆ ವಿಶೇಷ ಶಕ್ತಿ ಕೂಡ ನೀಡುತ್ತದೆ, ಆದರೆ ಅದು ಮತ್ತೊಂದು ಸಂದರ್ಭದ ಕಥೆ.

technical writing ಬಗ್ಗೆ ನೀವು ಹೆಚ್ಚು ಶ್ರದ್ಧೆ ತೋರಲಾರಂಭಿಸಿದಾಗ, ಮತ್ತು ಅದನ್ನು ಹೆಚ್ಚು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಓದುಗರಿಗೆ ಗೌರವ ಕೊಡುವುದನ್ನು ಮರೆಯಬೇಡಿ. ಒಮ್ಮೆ ಆರಂಭಿಸಿದ ನಂತರ ಅತಿಯಾಗಿ ವಿವರಿಸುವ ಪ್ರವೃತ್ತಿ ಸುಲಭವಾಗಿ ಬರುತ್ತದೆ. ಆದರೆ ಓದುಗರು ನಿಮ್ಮ ಬರಹವನ್ನೇ ಓದದೆ ಬಿಡುವ ಪರಿಸ್ಥಿತಿ ಬರದಂತೆ ಆ ಪ್ರವೃತ್ತಿಯನ್ನು ನಿಯಂತ್ರಿಸಬೇಕು. “why” ಅನ್ನು ವಿವರಿಸಿ, ಮತ್ತು “how” ಅನ್ನು ತಮ್ಮ ಸಂದರ್ಭಕ್ಕೆ ತಕ್ಕಂತೆ ಅವರು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ ಎಂಬ ನಂಬಿಕೆ ಇರಿ.

ಸಹಯೋಗ

engineers ಆಗಿರುವ ನಾವು ಕೆಲಸದ ಬಹುಭಾಗವನ್ನು ನಮ್ಮದೇ keyboard ಮುಂದೆ coding ಮಾಡುವುದರಲ್ಲಿ ಕಳೆಯಬಹುದು. ಆದರೆ ನಮ್ಮ ಸಮಯದ ಮಹತ್ತರ ಭಾಗ ಇತರರೊಂದಿಗೆ ಸಂವಹನದಲ್ಲಿಯೂ ಹೋಗುತ್ತದೆ. ಆ ಸಮಯವು ಸಾಮಾನ್ಯವಾಗಿ collaboration ಮತ್ತು education ಗಳಾಗಿ ವಿಭಜಿತವಾಗಿರುತ್ತದೆ; ಇವೆರಡರಲ್ಲೂ ಉತ್ತಮವಾಗಲು ಹೂಡಿಕೆ ಮಾಡುವುದರಿಂದ ದೊರೆಯುವ ಪ್ರಯೋಜನ ಗಮನಾರ್ಹವಾಗಿದೆ.

ಕೊಡುಗೆ ನೀಡುವುದು

ನೀವು bug report ಸಲ್ಲಿಸುತ್ತಿರಲಿ, ಸರಳ bug fix ನೀಡುತ್ತಿರಲಿ, ಅಥವಾ ದೊಡ್ಡ feature ಒಂದನ್ನು ಅಮಲುಗೊಳಿಸುತ್ತಿರಲಿ - ಒಂದು ಸಂಗತಿ ನೆನಪಿನಲ್ಲಿ ಇರಲಿ: ಸಾಮಾನ್ಯವಾಗಿ users ಸಂಖ್ಯೆ contributors ಗಿಂತ ಅನೇಕ ಪಟ್ಟು ಹೆಚ್ಚು; contributors ಸಂಖ್ಯೆ maintainers ಗಿಂತಲೂ ಒಂದು ಹಂತ ಹೆಚ್ಚು. ಇದರಿಂದ maintainer ಸಮಯವು ಬಹಳ ಮಟ್ಟಿಗೆ ಒತ್ತಡದಲ್ಲಿರುತ್ತದೆ. ನಿಮ್ಮ ಕೊಡುಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮುಂದುವರಿಯುವ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು, ನಿಮ್ಮ ಕೊಡುಗೆಗೆ ಹೆಚ್ಚಿನ signal-to-noise ratio ಇರಬೇಕು ಮತ್ತು ಅದು maintainers ಸಮಯಕ್ಕೆ ತಕ್ಕ ಮೌಲ್ಯ ಹೊಂದಿರಬೇಕು.

ಉದಾಹರಣೆಗೆ, ಉತ್ತಮ bug report ಒಂದು maintainer ಸಮಯಕ್ಕೆ ಗೌರವ ತೋರಿಸುವಂತೆ, ಸಮಸ್ಯೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಮರುಉತ್ಪಾದಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ:

• Environment: OS, version numbers, ಸಂಬಂಧಿತ configuration
• What you expected vs what actually happened
• Steps to reproduce: ಸ್ಪಷ್ಟವಾಗಿರಿ. “Click the button” ಗಿಂತ, “admin ಆಗಿ login ಆಗಿರುವಾಗ /settings page ನಲ್ಲಿ Submit button ಕ್ಲಿಕ್ ಮಾಡಿ.” ಹೆಚ್ಚು ಉಪಯುಕ್ತ.
• What you’ve already tried: ಇದು ಅದೇ ರೀತಿಯ ಪುನರಾವರ್ತಿತ ಸಲಹೆಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಕೆಲವು ತನಿಖೆ ನಡೆಸಿದ್ದೀರಿ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ

ನೀವು security vulnerability ಕಂಡುಹಿಡಿದರೆ, ಅದನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ಪೋಸ್ಟ್ ಮಾಡಬೇಡಿ. ಮೊದಲು maintainers ಅನ್ನು ಖಾಸಗಿವಾಗಿ ಸಂಪರ್ಕಿಸಿ, ಮತ್ತು ಬಹಿರಂಗಪಡಿಸುವುದಕ್ಕೆ ಮುನ್ನ ಅದನ್ನು ಸರಿಪಡಿಸಲು ಅವರಿಗೆ ಸಮಂಜಸವಾದ ಸಮಯ ನೀಡಿ. ಅನೇಕ projects ಗಳು ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ SECURITY.md ಅಥವಾ ಸಮಾನ ದಾಖಲೆ ಹೊಂದಿರುತ್ತವೆ.

ಈಗಾಗಲೇ ಇರುವ issues ಗಳನ್ನು ಹುಡುಕುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ bug ಅಥವಾ feature request ಈಗಾಗಲೇ ವರದಿಯಾಗಿರಬಹುದು; ಅಂಥ ಸಂದರ್ಭದಲ್ಲಿ duplicate issue ತೆರೆವುದಕ್ಕಿಂತ, ಇದ್ದ ಚರ್ಚೆಗೆ ಹೊಸ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸುವುದು ಬಹಳ ಉತ್ತಮ. ಇದರಿಂದ maintainers ಗೆ ಶಬ್ದವೂ ಕಡಿಮೆ.

minimal reproducible examples ಸಿದ್ಧಪಡಿಸಲು ಸಾಧ್ಯವಾದರೆ ಅದು ಅಮೂಲ್ಯ. ಅವು maintainer ಗೆ ಅಪಾರ ಸಮಯ ಮತ್ತು ಪರಿಶ್ರಮ ಉಳಿಸುತ್ತವೆ; bug ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮರುಉತ್ಪಾದಿಸುವುದು ಬಹುಸಾರಿ ಅದನ್ನು ಸರಿಪಡಿಸುವಲ್ಲಿ ಅತೀ ಕಠಿಣ ಹಂತವಾಗಿರುತ್ತದೆ. ಜೊತೆಗೆ, ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನೀವು ಮಾಡುವ ಪ್ರಯತ್ನದಿಂದ ಅದರ ಕುರಿತು ನಿಮ್ಮ ಅರಿವು ಹೆಚ್ಚುತ್ತದೆ; ಕೆಲವೊಮ್ಮೆ ಪರಿಹಾರವನ್ನೇ ನೀವು ಕಂಡುಕೊಳ್ಳಬಹುದು.

ನಿಮಗೆ ತಕ್ಷಣ ಪ್ರತಿಕ್ರಿಯೆ ಬರದಿದ್ದರೆ, maintainers ಬಹುಸಾರಿ ಸೀಮಿತ ಸಮಯ ಹೊಂದಿರುವ volunteers ಎಂಬುದನ್ನು ಮನದಲ್ಲಿಡಿ. ಉತ್ತರಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ, ಒಂದು-ಎರಡು ವಾರಗಳ ನಂತರ ಸೌಜನ್ಯಪೂರ್ವಕ follow-up ಸರಿ; ಪ್ರತಿದಿನ ping ಮಾಡುವುದು ಸೂಕ್ತವಲ್ಲ. ಅದೇ ರೀತಿ, “me too” comments, ಅಥವಾ terminal output ನ copy-paste ಮಾತ್ರ ಹೊಂದಿರುವ bug reports - ನಿಮ್ಮ issue ಗೆ ಗಮನ ಸೆಳೆಯುವ ದೃಷ್ಟಿಯಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿಕೂಲ ಪರಿಣಾಮ ಉಂಟುಮಾಡುತ್ತವೆ.

code contribution ಮಾಡಲು ಬಯಸುತ್ತಿದ್ದರೆ, contribution guidelines ಅನ್ನು ಪರಿಚಯಿಸಿಕೊಳ್ಳಿ. ಅನೇಕ projects ಗಳಲ್ಲಿ CONTRIBUTING.md ಇರುತ್ತದೆ - ಅದನ್ನು ಅನುಸರಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ ಸಣ್ಣದಾಗಿ ಆರಂಭಿಸುವುದು ಉತ್ತಮ; typo fix ಅಥವಾ documentation ಸುಧಾರಣೆ ಮೊದಲ ಕೊಡುಗೆಯಾಗಿ ತುಂಬಾ ಚೆನ್ನಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ವಿಷಯದ ಕುರಿತು ದೀರ್ಘ back-and-forth ಇಲ್ಲದೆ project ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅದು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

project ಯಾವ license ಬಳಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನೀವು ಕೊಡುವ ಯಾವುದೇ code ಅದೇ license ಅಡಿಯಲ್ಲಿ ಬರುತ್ತದೆ. ವಿಶೇಷವಾಗಿ copyleft licenses (ಉದಾ., GPL) ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆಯಾಗಿರಿ - ಅವು derivative works ಕೂಡ open source ಆಗಿರಬೇಕು ಎಂದು ಬೇಡಿಕೆ ಇಡುತ್ತವೆ, ಮತ್ತು ನೀವು ಅದರಲ್ಲಿ ಪಾಲ್ಗೊಂಡರೆ ನಿಮ್ಮ employer ಮೇಲೂ ಅದರ ಪರಿಣಾಮ ಇರಬಹುದು. choosealicense.com ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಉಪಯುಕ್ತ ಮಾಹಿತಿ ಇದೆ.

ನೀವು pull request (“PR”) ತೆರೆಯಲು ನಿರ್ಧರಿಸಿದಾಗ, ಮೊದಲು ನೀವು ಅಂಗೀಕಾರ ಪಡೆಯಲು ಬಯಸುವ ಬದಲಾವಣೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ PR ಒಂದೇ ವೇಳೆ ಅನೇಕ ಸಂಬಂಧವಿಲ್ಲದ ವಿಷಯಗಳನ್ನು ಬದಲಿಸಿದರೆ, reviewer ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಹಿಂದಿರುಗಿಸುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಇದು ನೀವು git commits ಅನ್ನು ಅರ್ಥಪೂರ್ಣ ಸಂಬಂಧಿತ ಭಾಗಗಳಿಗೆ ವಿಭಜಿಸಬೇಕಾದ ವಿಧಾನಕ್ಕೆ ಸಮಾನ.

ಕೆಲ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಬಾಹ್ಯವಾಗಿ ಸಂಬಂಧವಿಲ್ಲದಂತೆ ಕಾಣುವ ಹಲವಾರು ಬದಲಾವಣೆಗಳಿದ್ದರೂ, ಅವೆಲ್ಲವೂ ಒಂದು feature ಸಕ್ರಿಯಗೊಳಿಸಲು ಅಗತ್ಯವಾಗಿದ್ದರೆ, ಅವನ್ನೆಲ್ಲ ಒಳಗೊಂಡ ದೊಡ್ಡ PR ತೆరవುವುದು ಸರಿಯಾಗಬಹುದು. ಆದರೆ ಅಂಥ ಸಂದರ್ಭಗಳಲ್ಲಿ commit hygiene ವಿಶೇಷವಾಗಿ ಮುಖ್ಯ - maintainers ಗೆ ಬದಲಾವಣೆಯನ್ನು “commit by commit” ಆಗಿ review ಮಾಡುವ ಅವಕಾಶ ದೊರಕಬೇಕು.

ಮುಂದೆ, ಬದಲಾವಣೆಯ ಹಿಂದಿನ “why” ಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. what ಮಾತ್ರ ಹೇಳಬೇಡಿ - ಈ ಬದಲಾವಣೆ ಏಕೆ ಅಗತ್ಯ ಮತ್ತು ಸಮಸ್ಯೆಗೆ ಇದು ಏಕೆ ಸೂಕ್ತ ವಿಧಾನ ಎಂಬುದನ್ನು ವಿವರಿಸಿ. review ವೇಳೆ ವಿಶೇಷ ಗಮನಕ್ಕೆ ಪಾತ್ರವಾಗುವ ಭಾಗಗಳಿದ್ದರೆ, ಅವನ್ನು ನೀವು ಮುಂಚಿತವಾಗಿಯೇ ಸೂಚಿಸಬೇಕು. CONTRIBUTING.md ಮತ್ತು ನಿಮ್ಮ ಬದಲಾವಣೆಯ ಸ್ವಭಾವವನ್ನು ಅವಲಂಬಿಸಿ, ನೀವು ಮಾಡಿದ trade-offs ಅಥವಾ ಬದಲಾವಣೆಯನ್ನು ಹೇಗೆ test ಮಾಡುವುದು ಇತ್ಯಾದಿ ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನೂ reviewers ನಿರೀಕ್ಷಿಸಬಹುದು.

ಮೊದಲ ವಿಧಾನವಾಗಿ ಕನಿಷ್ಠ upstream projects ಗೆ ಹಿಂದಿರುಗಿ ಕೊಡುಗೆ ನೀಡುವುದನ್ನು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ; project ಅನ್ನು “fork” ಮಾಡುವುದು ಅಂತಿಮ ಆಯ್ಕೆಯಾಗಿರಲಿ. Forking (license ಅನುಮತಿ ಇದ್ದರೆ) ನೀವು ನೀಡಬಯಸುವ ಕೊಡುಗೆಗಳು ಮೂಲ project ವ್ಯಾಪ್ತಿಗೆ ಹೊರಗಿರುವಾಗ ಮಾತ್ರ ಬಳಸಬೇಕು. fork ಮಾಡಿದರೆ, ಮೂಲ project ಗೆ ಸರಿಯಾದ ಮಾನ್ಯತೆ ನೀಡುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

AI ಬಳಸಿ ದೃಷ್ಟಿಗೆ ನಂಬಬಹುದಾದ code ಮತ್ತು PRs ಅನ್ನು ವೇಗವಾಗಿ ರಚಿಸುವುದು ಅತೀ ಸುಲಭವಾಗಿದೆ. ಆದರೂ ನೀವು ಏನು ಕೊಡುಗೆ ನೀಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಹೊಣೆಗಾರಿಕೆಯಿಂದ ಅದು ವಿನಾಯಿತಿ ಕೊಡುವುದಿಲ್ಲ. ನೀವು ವಿವರಿಸಲಾರದ AI-generated code ಅನ್ನು ಸಲ್ಲಿಸುವುದು, ಅದರ ಲೇಖಕನೇ ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳದ code ಅನ್ನು review ಮತ್ತು ನಿರ್ವಹಿಸುವ ಭಾರವನ್ನು maintainers ಮೇಲೆ ಹಾಕುತ್ತದೆ. issues ಗುರುತಿಸಲು ಮತ್ತು fixes/features ಸಿದ್ಧಪಡಿಸಲು AI ಬಳಸದರಲ್ಲಿ ತೊಂದರೆಯಿಲ್ಲ - ಆದರೆ ನೀವು ಅಗತ್ಯ due diligence ಮಾಡಿಯೇ ಅದನ್ನು ಮೌಲ್ಯಯುತ ಕೊಡುಗೆಯಾಗಿ ಮೆರುಗುಗೊಳಿಸಬೇಕು; ಈಗಾಗಲೇ ಒತ್ತಡದಲ್ಲಿರುವ maintainers ಮೇಲೆ ಆ ಕೆಲಸವನ್ನು ಹೊರೆ ಹಾಕಬಾರದು.

maintainers ದೃಷ್ಟಿಯಿಂದ PR ಸ್ವೀಕರಿಸುವುದೆಂದರೆ ದೀರ್ಘಕಾಲಿಕ ಹೊಣೆಗಾರಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದೇ. contributor ಮುಂದೆ ಸಾಗಿದ ನಂತರವೂ ಅವರು ಈ code ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಒಳ್ಳೆಯ ಉದ್ದೇಶದಿಂದ ಬಂದಿದ್ದರೂ project ದಿಕ್ಕಿಗೆ ಹೊಂದದ, ಅವರು ನಿರ್ವಹಿಸಲು ಬಯಸದ complexity ಸೇರಿಸುವ, ಅಥವಾ ಅಗತ್ಯತೆಯ ದಾಖಲೆ ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಿಲ್ಲದ ಬದಲಾವಣೆಗಳನ್ನು ಅವರು ತಿರಸ್ಕರಿಸಬಹುದು. ಕೊಡುಗೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದು maintenance burden ಗೆ ತಕ್ಕ ಮೌಲ್ಯ ಕೊಡುತ್ತದೆ ಎಂಬ ದೃಢವಾದ ಕಾರಣವನ್ನು ಮಂಡಿಸುವುದು contributor ಆಗಿರುವ ನಿಮ್ಮ ಜವಾಬ್ದಾರಿ.

PR ಬಗ್ಗೆ feedback ಸ್ವೀಕರಿಸುವಾಗ ನಿಮ್ಮ code ಎಂದರೆ ನೀವು ಅಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. reviewers code ಉತ್ತಮಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ; ಅವರು ವೈಯಕ್ತಿಕವಾಗಿ ನಿಮ್ಮನ್ನು ಟೀಕಿಸುತ್ತಿಲ್ಲ. ಒಪ್ಪಂದವಿಲ್ಲದಿದ್ದರೆ ಸ್ಪಷ್ಟೀಕರಣ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ - ನಿಮಗೂ ಹೊಸದಾಗಿ ಕಲಿಯಬಹುದು, ಅಥವಾ ಅವರಿಗೆ.

ವಿಮರ್ಶೆ

code review ಎನ್ನುವುದು senior developers ಮಾತ್ರ ಮಾಡುವ ಕೆಲಸ ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು. ಆದರೆ ನೀವು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ಬೇಗ ನಿಮಗೆ review ಮಾಡಲು ಕೇಳಲಾಗುವ ಸಾಧ್ಯತೆ ಇದೆ, ಮತ್ತು ನಿಮ್ಮ ದೃಷ್ಟಿಕೋನ ಮೌಲ್ಯಯುತ. ಹೊಸ ಕಣ್ಣುಗಳು ಅನುಭವಿಗಳ ಗಮನ ತಪ್ಪಿದ ವಿಷಯಗಳನ್ನು ಹಿಡಿಯುತ್ತವೆ; code ಬಗ್ಗೆ ಕಡಿಮೆ ಪರಿಚಯವಿರುವವರ ಪ್ರಶ್ನೆಗಳು ದಾಖಲೆ ಮಾಡಬೇಕಾದ ಅಥವಾ ಸರಳಗೊಳಿಸಬೇಕಾದ ಅಡಗಿದ ಅನುಮಾನಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ.

review ಕಲಿಯುವ ಅತ್ಯಂತ ವೇಗವಾದ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇತರರು ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಎದುರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ; patterns ಮತ್ತು idioms ಗಳನ್ನು ಕಲಿಯುತ್ತೀರಿ; code ಓದಿಸಿಕೊಳ್ಳುವಂತೆ ಮಾಡುವುದೇನು ಎಂಬುದರ ಬಗ್ಗೆ ಒಳನೋಟ ಬೆಳೆಸುತ್ತೀರಿ. ವೈಯಕ್ತಿಕ ಬೆಳವಣಿಗೆಯ ಹೊರತಾಗಿ, reviews ಗಳು bugs ಅನ್ನು production ತಲುಪುವ ಮುನ್ನ ಹಿಡಿಯುತ್ತವೆ, ತಂಡದೊಳಗಿನ ಜ್ಞಾನ ಹಂಚಿಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ, ಮತ್ತು collaboration ಮುಖಾಂತರ code ಗುಣಮಟ್ಟವನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತವೆ. ಅವು ಕೇವಲ ಆಡಳಿತಾತ್ಮಕ ರೂಪರೇಷೆ ಅಲ್ಲ.

ಉತ್ತಮ code review ಎನ್ನುವುದು ಕಾಲಕ್ರಮೇಣ ತಿದ್ದಿಕೊಳ್ಳಬೇಕಾದ ಕೌಶಲ್ಯ. ಆದರೂ ಅದನ್ನು ಬೇಗನೆ ಗಣನೀಯವಾಗಿ ಉತ್ತಮಗೊಳಿಸುವ ಕೆಲವು ಸಲಹೆಗಳಿವೆ:

• ವಿಮರ್ಶೆ code ಗೆ ಇರಲಿ, ವ್ಯಕ್ತಿಗೆ ಅಲ್ಲ: “This function is confusing” ಎಂಬ ಹೇಳಿಕೆ, “You wrote confusing code.” ಎನ್ನುವುದಕ್ಕಿಂತ ಉತ್ತಮ.
• ಅಮಲುಗೊಳಿಸಬಹುದಾದ comments ನೀಡಿ: “Don’t use globals here” ಎನ್ನುವುದಕ್ಕಿಂತ, “Can you replace these globals with a config dataclass” ಎಂಬುದು ಪರಿಹರಿಸಲು ಸುಲಭ.
• ಆಜ್ಞೆಯ ಬದಲು ಪ್ರಶ್ನೆ ಕೇಳಿ: “Handle the null case.” ಎನ್ನುವುದಕ್ಕಿಂತ, “What happens if X is null here?” ಚರ್ಚೆಗೆ ಉತ್ತಮವಾಗಿ ಆಹ್ವಾನಿಸುತ್ತದೆ.
• “why” ಅನ್ನು ವಿವರಿಸಿ: “Consider using a constant here” ಎನ್ನುವುದಕ್ಕಿಂತ, “ಪರಿಸರದ ಆಧಾರದ ಮೇಲೆ timeout ಅನ್ನು ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಲು ಇಲ್ಲಿ constant ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.” ಎಂಬುದು ಹೆಚ್ಚು ಉಪಯುಕ್ತ.
• blocking issues ಮತ್ತು suggestions ಬೇರ್ಪಡಿಸಿ: ಕಡ್ಡಾಯವಾಗಿ ಬದಲಿಸಬೇಕಾದದ್ದು ಯಾವುದು, ವೈಯಕ್ತಿಕ ಅಭಿರುಚಿ ಯಾವುದು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಿ.
• ಒಳ್ಳೆಯ ಭಾಗವನ್ನೂ ಗುರುತಿಸಿ: ಚಾಕಚಕ್ಯ ಪರಿಹಾರಗಳು ಅಥವಾ ಸ್ವಚ್ಛ implementation ಗಳನ್ನು ಸೂಚಿಸುವುದು ಪ್ರೋತ್ಸಾಹಕಾರಿ, ಮತ್ತು ಲೇಖಕರು ಮುಂದುವರಿಸಬೇಕಾದ ಉತ್ತಮ ಕ್ರಮಗಳನ್ನು ತಿಳಿಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ಎಲ್ಲಿ ನಿಲ್ಲಬೇಕು ಎಂಬುದನ್ನು ತಿಳಿ: contributors ಗೆ ಸಮಯ ಮತ್ತು ಸಹನಶೀಲತೆ ಸೀಮಿತ. ಎಲ್ಲಾ nits ಮೇಲೆ ಸಮಯ ವ್ಯಯಿಸುವುದು ಯಾವಾಗಲೂ ಉತ್ತಮವಲ್ಲ. ದೊಡ್ಡ ವಿಷಯಗಳಿಗೆ ಗಮನ ನೀಡಿ; nits ಅನ್ನು ನಂತರ ನೀವು ತಾವೇ ತಿದ್ದುವ ಸಾಧ್ಯತೆಯನ್ನೂ ಪರಿಗಣಿಸಿ.

AI tools ಕೆಲವು issues ಹಿಡಿಯಬಹುದು; ಆದರೆ human review ಗೆ ಅವು ಪರ್ಯಾಯವಲ್ಲ. ಅವುಗಳಿಗೆ context ತಪ್ಪಬಹುದು, product requirements ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥವಾಗದೆ ಇರಬಹುದು, ಮತ್ತು ತಪ್ಪಾದ ಸಲಹೆಯನ್ನೇ ವಿಶ್ವಾಸದಿಂದ ನೀಡಬಹುದು. ಮೊದಲ pass ಆಗಿ ಬಳಸುವುದು ಉಪಯುಕ್ತ, ಆದರೆ ಚಿಂತಿತ ಮಾನವೀಯ review ಅನ್ನು ಬದಲಿಸಲು ಅಲ್ಲ.

ಶಿಕ್ಷಣ

engineers ಆಗಿರುವ ನಮ್ಮ non-coding ಸಮಯದ ದೊಡ್ಡ ಭಾಗ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವುದಲ್ಲ ಅಥವಾ ಉತ್ತರಿಸುವುದಲ್ಲ, ಅಥವಾ ಎರಡರ ಮಿಶ್ರಣದಲ್ಲೇ ಕಳೆಯುತ್ತದೆ - collaboration ವೇಳೆ, peers ಜೊತೆ ಸಂವಾದದಲ್ಲಿ, ಅಥವಾ ಕಲಿಯುವ ಪ್ರಯತ್ನದಲ್ಲಿ. ಉತ್ತಮ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವುದು, ಅತ್ಯುತ್ತಮವಾಗಿ ವಿವರಿಸುವವರಿಂದ ಮಾತ್ರವಲ್ಲ, ಯಾರಿಂದ ಬೇಕಾದರೂ ಉತ್ತಮವಾಗಿ ಕಲಿಯಲು ಸಹಾಯ ಮಾಡುವ ಕೌಶಲ್ಯ. Julia Evans ಅವರ “How to ask good questions” ಮತ್ತು “How to get useful answers to your questions” ಬ್ಲಾಗ್ ಲೇಖನಗಳು ಓದಲು ಬಹಳ ಉಪಯುಕ್ತ.

ವಿಶೇಷವಾಗಿ ಮೌಲ್ಯಯುತವಾದ ಕೆಲವು ಸಲಹೆಗಳು:

• State your understanding first: ನೀವು ತಿಳಿದಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸುವುದನ್ನು ಮೊದಲು ಹೇಳಿ, ನಂತರ “is that right?” ಎಂದು ಕೇಳಿ. ಇದರಿಂದ ಉತ್ತರಿಸುವವರಿಗೆ ನಿಮ್ಮ ನಿಜವಾದ knowledge gaps ಗುರುತಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ.
• Ask yes/no questions: “Is X true?” ಎಂಬ ಪ್ರಶ್ನೆ ಅನಗತ್ಯ ಬೇರೆ ದಿಕ್ಕಿನ ವಿವರಣೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಉಪಯುಕ್ತ ವಿಸ್ತೃತ ಉತ್ತರಕ್ಕೂ ದಾರಿಯಿಡುತ್ತದೆ.
• Be specific: “How do SQL joins work?” ಬಹಳ ಅಸ್ಪಷ್ಟ. “Does a LEFT JOIN include rows where the right table has no match?” ಉತ್ತರಿಸಬಹುದಾದ ಪ್ರಶ್ನೆ.
• Admit when you don’t understand: ಪರಿಚಯವಿಲ್ಲದ ಪದಗಳು ಬಂದರೆ ಮಧ್ಯೆಯಲ್ಲಿ ಕೇಳಿ. ಇದು ದುರ್ಬಲತೆ ಅಲ್ಲ, ಆತ್ಮವಿಶ್ವಾಸದ ಸೂಚನೆ. ಅದೇ ರೀತಿ, ನಿಮಗೆ ಉತ್ತರ ತಿಳಿಯದ ಪ್ರಶ್ನೆ ಕೇಳಿದರೆ, “I don’t know” ಎಂದು ಹೇಳುವುದು ಉತ್ತಮ; ಅಗತ್ಯವಿದ್ದರೆ “but I think …” ಅಥವಾ “but I can find out” ಎಂದು ಮುಂದುವರಿಯಬಹುದು.
• Don’t accept incomplete answers: ನಿಮಗೆ ವಾಸ್ತವವಾಗಿ ಅರ್ಥವಾಗುವವರೆಗೂ follow-up ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಿರಿ.
• Do some research first: ಮೂಲಭೂತ ಹುಡುಕಾಟ ಮಾಡಿದರೆ ಹೆಚ್ಚು targeted ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದು (ಆದರೆ ಸಹೋದ್ಯೋಗಿಗಳ ಮಧ್ಯೆ casual ಪ್ರಶ್ನೆಗಳು ಸಹ ಸಮಂಜಸವೇ).

ಗಮನದಲ್ಲಿರಲಿ: ಚೆನ್ನಾಗಿ ರೂಪುಗೊಂಡ ಪ್ರಶ್ನೆಗಳು ಸಮಗ್ರ ಸಮುದಾಯಕ್ಕೂ ಉಪಕಾರ. ಇತರರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಅಡಗಿದ ಊಹೆಗಳನ್ನು ಅವು ಮೇಲಕ್ಕೆ ತರುತ್ತವೆ.

ಈ ಸಲಹೆ LLMs ಜೊತೆ ಸಂವಹನ ಮಾಡುವ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಸಮಾನವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ.

AI ಶಿಷ್ಟಾಚಾರ

software engineering ಕ್ಷೇತ್ರದಲ್ಲಿ LLMs ಮತ್ತು AI ಬಳಕೆ ಹೆಚ್ಚುತ್ತಿರುವ ಹಿನ್ನೆಲೆ, ಅದರ ಸುತ್ತಲಿನ ಸಾಮಾಜಿಕ ಮತ್ತು ವೃತ್ತಿಪರ norms ಇನ್ನೂ ರೂಪುಗೊಳ್ಳುವ ಹಂತದಲ್ಲಿವೆ. agentic coding lecture ನಲ್ಲಿ tactical ವಿಚಾರಗಳನ್ನು ನಾವು ಈಗಾಗಲೇ ನೋಡಿದ್ದೇವೆ; ಆದರೆ ಅವುಗಳ ಬಳಕೆಯ “soft” ಅಂಶಗಳ ಬಗ್ಗೆ ಚರ್ಚಿಸುವುದೂ ಮಹತ್ವದ್ದು.

ಇದಲ್ಲಿನ ಮೊದಲ ವಿಚಾರ: AI ನಿಮ್ಮ ಕೆಲಸಕ್ಕೆ ಅರ್ಥಪೂರ್ಣವಾಗಿ ಕೊಡುಗೆ ನೀಡಿದರೆ, ಅದನ್ನು ಬಹಿರಂಗಪಡಿಸಿ. ಇದು ಲಜ್ಜೆಯ ವಿಷಯವಲ್ಲ - ಪ್ರಾಮಾಣಿಕತೆ, ಸಮಂಜಸ ನಿರೀಕ್ಷೆ ನಿರ್ಮಾಣ, ಮತ್ತು ಫಲಿತಾಂಶದ ಕೆಲಸಕ್ಕೆ ಸೂಕ್ತ ಮಟ್ಟದ review ಸಿಗುವಂತೆ ಮಾಡುವ ವಿಷಯ. AI ಅನ್ನು ಯಾವ _ಭಾಗಗಳ_ಗಾಗಿ ಬಳಸಿದ್ದೀರಿ ಎಂಬುದನ್ನೂ ಹೇಳುವುದು ಒಳಿತು - “this whole thing is vibecoded” ಮತ್ತು “I wrote this backup tool and used an LLM to style the web frontend” ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಅರ್ಥಪೂರ್ಣ. ಉದಾಹರಣೆಗೆ, ಈ lecture notes ನಲ್ಲಿ proofreading, brainstorming, ಮತ್ತು code snippets ಹಾಗೂ exercises ಗಳ first drafts ರಚಿಸಲು ನಾವು LLMs ಬಳಸಿದ್ದೇವೆ.

ನೀವು ಕೊಡುಗೆ ನೀಡುತ್ತಿರುವ teams ಮತ್ತು projects ಗಳ norms ಅನ್ನು ಅನುಸರಿಸುವುದು ಸಹ ಅಗತ್ಯ. ಕೆಲವು ತಂಡಗಳಲ್ಲಿ AI ಬಳಕೆಗೆ ಇತರರಿಗಿಂತ ಕಠಿಣ policies ಇರುತ್ತವೆ (ಉದಾ., compliance ಅಥವಾ data residency ಕಾರಣಗಳಿಂದ), ಮತ್ತು ತಪ್ಪಾಗಿ ಅವುಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ ನಡೆದುಕೊಳ್ಳಲು ನೀವು ಬಯಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಬಳಕೆಯ ಬಗ್ಗೆ ಮುಕ್ತವಾಗಿ ಹೇಳುವುದರಿಂದ ದುಬಾರಿ ತಪ್ಪುಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ತಪ್ಪಿಸಬಹುದು.

ನೀವು ಮಾಡುತ್ತಿರುವ ಕೆಲಸದ ಭಾಗವಾಗಿ ಕಲಿಯುವುದು ಗುರಿಯಾಗಿದ್ದರೆ, ಎಲ್ಲಾ ಅಥವಾ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು AI ಮೂಲಕ ಮಾಡಿಸುವುದು ಸ್ವತಃ ವಿಫಲತೆಯತ್ತ ಕೊಂಡೊಯ್ಯಬಹುದು. ಆಗ ನೀವು ಕೆಲಸದ ವಿಷಯಕ್ಕಿಂತ prompting (ಮತ್ತು ಬಹುಶಃ AI output review) ಬಗ್ಗೆ ಹೆಚ್ಚು ಕಲಿಯುವ ಸಾಧ್ಯತೆ ಇದೆ. ವಿಶೇಷವಾಗಿ ಕಲಿಯುವ ಹಂತದಲ್ಲಿ, ಗುರಿ ಅಂತಿಮ ಉತ್ತರಕ್ಕಿಂತ ಪಯಣವೇ ಆಗಿರಬಹುದು; ಆದ್ದರಿಂದ AI ಮೂಲಕ “get the solution quickly” ಮಾಡುವುದು anti-goal ಆಗಬಹುದು.

ಇದರೊಂದಿಗೆ ಸಂಬಂಧಿತ ಮತ್ತೊಂದು ಪ್ರಶ್ನೆ interviews ಮತ್ತು ಇತರೆ assessment ಸಂದರ್ಭಗಳಲ್ಲಿ ಬರುತ್ತದೆ. ಇವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಕೌಶಲ್ಯ ಮತ್ತು ಸಾಮರ್ಥ್ಯವನ್ನು ಅಳೆಯಲು ರೂಪುಗೊಂಡಿರುತ್ತವೆ, LLM ನದು ಅಲ್ಲ. ಕೆಲವು ಕಂಪನಿಗಳು ಈಗ interviews ನಲ್ಲಿ LLMs ಮತ್ತು AI-assisted tools ಬಳಕೆಗೆ ಅವಕಾಶ ನೀಡುತ್ತಿವೆ - ಆದರೆ ಆ ಸಂವಹನವನ್ನು ಸಂದರ್ಶನದ ಭಾಗವಾಗಿ ಅವಲೋಕಿಸಲು ಅವಕಾಶ ನೀಡಿದಾಗ ಮಾತ್ರ (ಅಂದರೆ, ಆ tools ಅನ್ನು ಬಳಸುವ ನಿಮ್ಮ ಕೌಶಲ್ಯವನ್ನೂ ಅವು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತವೆ). ಆದಾಗ್ಯೂ, ಇವು ಇನ್ನೂ ಅಲ್ಪಸಂಖ್ಯೆಯಲ್ಲಿವೆ. ನಿರ್ದಿಷ್ಟ ಕೆಲಸಕ್ಕೆ AI ಸಹಾಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿದೆಯೇ ಎಂಬ ಅನುಮಾನ ಇದ್ದರೆ, ಕೇಳಿ.

assessment ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಹೊರಗಿನ tools ಬೇಡ, LLMs ಬೇಡ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿದ್ದರೆ, ಅವನ್ನು ಬಳಸಬಾರದು ಎಂಬುದು ಸ್ವಯಂಸ್ಪಷ್ಟ. ಹಿಡಿಯಿಸಿಕೊಳ್ಳದೆ ಸದ್ದಿಲ್ಲದೆ ಬಳಸಲು ಪ್ರಯತ್ನಿಸುವುದು ಖಚಿತವಾಗಿಯೂ ನಂತರ ನಿಮಗೆ ಪ್ರತಿಕೂಲವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ಅಭ್ಯಾಸಗಳು

1. ಪ್ರಸಿದ್ಧ project ಒಂದರ source code ಅನ್ನು ಪರಿಶೀಲಿಸಿ (ಉದಾ., Redis ಅಥವಾ curl). lecture ನಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿದ comment ಪ್ರಕಾರಗಳ ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ: ಉಪಯುಕ್ತ TODO, external documentation ಗೆ reference, ತಪ್ಪಿಸಲಾದ ವಿಧಾನವನ್ನು ವಿವರಿಸುವ “why not” comment, ಅಥವಾ hard-learned lesson. ಆ comment ಇಲ್ಲದಿದ್ದರೆ ಯಾವ ಮಾಹಿತಿ ಕಳೆದುಹೋಗುತ್ತಿತ್ತು?

2. ನಿಮಗೆ ಆಸಕ್ತಿಯಿರುವ open-source project ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಅದರ ಇತ್ತೀಚಿನ commit history (git log) ನೋಡಿ. ಬದಲಾವಣೆ ಏಕೆ ಮಾಡಲಾಯಿತು ಎಂಬುದನ್ನು ಹೇಳುವ ಉತ್ತಮ message ಇರುವ ಒಂದು commit ಮತ್ತು ಏನು ಬದಲಾಯಿತು ಎಂಬುದಷ್ಟೇ ಹೇಳುವ ದುರ್ಬಲ message ಇರುವ ಮತ್ತೊಂದು commit ಆಯ್ಕೆಮಾಡಿ. ದುರ್ಬಲ message ಇರುವ commit ಗಾಗಿ, diff (git show <hash>) ನೋಡಿ, Problem → Solution → Implications ರಚನೆ ಅನುಸರಿಸಿ ಉತ್ತಮ commit message ಬರೆಯಲು ಪ್ರಯತ್ನಿಸಿ. ನಂತರದ ಹಂತದಲ್ಲಿ ಅಗತ್ಯ context ಪುನರ್‌ರಚಿಸಲು ಎಷ್ಟು ಶ್ರಮ ಬೇಕಾಗುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ.

3. 1000+ stars ಹೊಂದಿರುವ ಮೂರು GitHub projects ಗಳ READMEs ಹೋಲಿಸಿ. ಅವೆಲ್ಲವೂ ಸಮಾನವಾಗಿ ಉಪಯುಕ್ತವೇ? ಭವಿಷ್ಯದಲ್ಲಿ ನೀವು ಬರೆಯುವ READMEs ಗಾಗಿ ಪಾಠವಾಗಿ, ನಿಮಗೆ ಮುಖ್ಯವಾಗಿ noise ಆಗಿ ಕಾಣುವ ಅಂಶಗಳನ್ನು ಗುರುತಿಸಿ.

4. ನೀವು ಬಳಸುವ project ಒಂದರಲ್ಲಿ open issue ಹುಡುಕಿ (ಇದ್ದರೆ “good first issue” ಅಥವಾ “help wanted” labels ಪರಿಶೀಲಿಸಿ). lecture ಮಾನದಂಡಗಳ ವಿರುದ್ಧ issue ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ: ಅದು maintainer ಸಮಯಕ್ಕೆ ಮೌಲ್ಯ ನೀಡುವಂತಿದೆಯೇ ಮತ್ತು debug ಮಾಡಲು ಅಗತ್ಯ ಎಲ್ಲ ಮಾಹಿತಿ ಇದೆಯೇ? ಅಥವಾ ಮೂಲ ಸಮಸ್ಯೆಗೆ ತಲುಪಲು maintainer ಗೆ submitter ಜೊತೆ ಹಲವಾರು ಸುತ್ತಿನ ಪ್ರಶ್ನೋತ್ತರ ಬೇಕಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಅನಿಸುತ್ತಿದೆಯೇ?

5. ನೀವು ಬಳಸುವ software ನಲ್ಲಿ ಎದುರಿಸಿದ bug ಒಂದನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಿ (ಅಥವಾ issue tracker ನಲ್ಲಿ ೊಂದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ). minimal reproducible example ರಚಿಸುವ ಅಭ್ಯಾಸ ಮಾಡಿ: ಸಮಸ್ಯೆಗೆ ಸಂಬಂಧಿಸದ ಎಲ್ಲವನ್ನೂ ತೆಗೆದುಹಾಕಿ, ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನೂ ತೋರಿಸುವ ಅತಿ ಚಿಕ್ಕ ಪ್ರಕರಣ ಮಾತ್ರ ಉಳಿಯುವವರೆಗೆ ಸರಳಗೊಳಿಸಿ. ನೀವು ಏನು ತೆಗೆದಿರಿ ಮತ್ತು ಏಕೆ ತೆಗೆದಿರಿ ಎಂದು ಬರೆಯಿರಿ.

6. ನಿಮಗೆ ಪರಿಚಿತವಾದ project ಒಂದರಲ್ಲಿ substantive review comments ಹೊಂದಿರುವ (“LGTM” ಮಾತ್ರವಲ್ಲ) merged pull request ಒಂದನ್ನು ಹುಡುಕಿ. review ಸಂಪೂರ್ಣವಾಗಿ ಓದಿ. ಎಲ್ಲಾ comments ಸಮಾನವಾಗಿ ಉತ್ಪಾದಕವಾಗಿದ್ದವೆಯೇ? ನೀವು PR author ಆಗಿದ್ದರೆ, ಇಷ್ಟು comments ಪಡೆಯುವ ಅನುಭವವನ್ನು ಹೇಗೆ ಅನುಭವಿಸುತ್ತಿದ್ದಿರಿ?

7. Stack Overflow ಗೆ ಹೋಗಿ, ನಿಮಗೆ ತಿಳಿದಿರುವ technology ಯೊಂದರಲ್ಲಿ highly-voted answer ಹೊಂದಿರುವ ಪ್ರಶ್ನೆ ಒಂದನ್ನು ಹುಡುಕಿ. ನಂತರ closed ಆಗಿರುವ ಅಥವಾ ಹೆಚ್ಚು downvoted ಆಗಿರುವ ಮತ್ತೊಂದು ಪ್ರಶ್ನೆ ಹುಡುಕಿ. lecture ಸಲಹೆಗಳ ದೃಷ್ಟಿಯಲ್ಲಿ ಎರಡನ್ನೂ ಹೋಲಿಸಿ; ಯಾವ ಪ್ರಶ್ನೆಗೆ ಉತ್ತಮ ಉತ್ತರ ಸಿಗಬಹುದು ಎಂಬುದು ಮುಂಚಿತವಾಗಿ ಊಹಿಸಬಹುದಾಗಿತ್ತೇ?

---