ಲಾಭಗಳು:
- ಗುರಿ ಪ್ರೇಕ್ಷಕರು ಮತ್ತು AI ಯೊಂದಿಗೆ ಮೂಲವನ್ನು ಆಧರಿಸಿ README, ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ ಮತ್ತು ಚೇಂಜ್ಲಾಗ್ ಡ್ರಾಫ್ಟ್ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಮರ್ಥ್ಯ
- ದಾಖಲಾತಿಯಲ್ಲಿ 'ಏನು/ಹೇಗೆ' ಮತ್ತು 'ಏಕೆ' ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಸಾಮರ್ಥ್ಯ ಮತ್ತು 'ಏಕೆ' ಅನ್ನು ಮಾನವನಂತೆ ಸೇರಿಸುವುದು
- ಅನುಸ್ಥಾಪನಾ ಹಂತಗಳನ್ನು ವೈಯಕ್ತಿಕವಾಗಿ ರನ್ ಮಾಡುವ ಮೂಲಕ ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಕೋಡ್ ಬದಲಾವಣೆಯ ಭಾಗವಾಗಿ ಮಾಡುವುದು
ಸಾಫ್ಟ್ವೇರ್ನ ಅತ್ಯಂತ ಆಗಾಗ್ಗೆ ನಿರ್ಲಕ್ಷಿಸಲ್ಪಟ್ಟ ಆದರೆ ದೀರ್ಘಕಾಲೀನ ಭಾಗವೆಂದರೆ ದಸ್ತಾವೇಜನ್ನು. ಕೋಡ್ ಅನ್ನು ತಿಂಗಳ ನಂತರವೂ ಓದಬಹುದಾಗಿದೆ; ಬರೆದವರು ಹೋದರು, ಸಂದರ್ಭ ಮರೆತು, ಬರೆದದ್ದು ಮಾತ್ರ ಉಳಿದಿದೆ. ಉತ್ತಮ README (ಪ್ರಾಜೆಕ್ಟ್ ಎಂದರೇನು ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಬೇಕು ಮತ್ತು ಚಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಪರಿಚಯಾತ್ಮಕ ದಾಖಲೆ), ವಿವರಣಾತ್ಮಕ ಕೋಡ್ ಕಾಮೆಂಟ್ಗಳು ಮತ್ತು ಅಪ್-ಟು-ಡೇಟ್ API ದಸ್ತಾವೇಜನ್ನು (ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಉಲ್ಲೇಖ) ನೇರವಾಗಿ ತಂಡದ ವೇಗವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. AI ದಸ್ತಾವೇಜನ್ನು ಬಹಳಷ್ಟು "ಬರಹದ ಆಯಾಸ" ವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಆದರೆ ಇದು ಒಂದು ಬಲೆಗೆ ಬರುತ್ತದೆ: AI ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಕೋಡ್ನಿಂದ ಊಹಿಸಬಹುದು, ಆದರೆ ಅದು ಏಕೆ ಆ ರೀತಿ ಮಾಡಲಾಗಿದೆ ಎಂದು ತಿಳಿಯುವುದಿಲ್ಲ.
ಈ ಘಟಕದಲ್ಲಿ, ನೀವು README, ಕೋಡ್ ಕಾಮೆಂಟ್, ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ (ಪ್ರತಿ ಕಾರ್ಯ/ವರ್ಗಕ್ಕೆ ಬರೆಯಲಾದ ಕಾಮೆಂಟ್ ಬ್ಲಾಕ್), API ಡಾಕ್ಯುಮೆಂಟ್ ಮತ್ತು AI ಜೊತೆಗೆ ಚೇಂಜ್ಲಾಗ್ ಅನ್ನು ಹೇಗೆ ತಯಾರಿಸಬೇಕೆಂದು ಕಲಿಯುವಿರಿ; ಮತ್ತು ದಾಖಲೆಯ ಅತ್ಯಮೂಲ್ಯವಾದ ಭಾಗವನ್ನು ಮಾನವೀಯವಾಗಿ ಹೇಗೆ ಸಂರಕ್ಷಿಸುವುದು: "ಏಕೆ."
"ಏನು" ಮತ್ತು "ಏಕೆ" ನಡುವಿನ ವ್ಯತ್ಯಾಸ
ದಾಖಲೆಗಳ ಎರಡು ಪದರಗಳಿವೆ. ಮೊದಲನೆಯದು ಏನು/ಹೇಗೆ: "ಈ ಕಾರ್ಯವು ಪಟ್ಟಿಯನ್ನು ವಿಂಗಡಿಸುತ್ತದೆ", "ಅನುಸ್ಥಾಪಿಸಲು ಈ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ". ಇವುಗಳನ್ನು ಕೋಡ್ ಮತ್ತು ರಚನೆಯಿಂದ ಹೊರತೆಗೆಯಬಹುದು; AI ಇಲ್ಲಿ ಉತ್ತಮವಾಗಿದೆ. ಎರಡನೆಯದಾಗಿ, ಏಕೆ: "ನಾವು ಈ ಸೇವೆಯನ್ನು ಸಿಂಕ್ರೊನಸ್ಗಿಂತ ಅಸಮಕಾಲಿಕವಾಗಿ ಏಕೆ ಮಾಡಿದ್ದೇವೆ", "ಈ ಮಿತಿ ಮೌಲ್ಯ 30 ಸೆಕೆಂಡುಗಳು", "ನಾವು ಈ ಲೈಬ್ರರಿಯನ್ನು ಇನ್ನೊಂದಕ್ಕಿಂತ ಏಕೆ ಆರಿಸಿದ್ದೇವೆ". ಇವುಗಳನ್ನು ಕೋಡ್ನಲ್ಲಿ ಬರೆಯಲಾಗಿಲ್ಲ; ಇದು ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳು, ನಿರ್ಬಂಧಗಳು ಮತ್ತು ಹಿಂದಿನ ನೋವಿನ ಉತ್ಪನ್ನವಾಗಿದೆ.
AI ಗೆ "ಏಕೆ" ಗೊತ್ತಿಲ್ಲ; ಅತ್ಯುತ್ತಮವಾಗಿ, ಇದು ಸಮಂಜಸವಾದ ಊಹೆಯನ್ನು ಮಾಡುತ್ತದೆ-ಇದು ಅಪಾಯಕಾರಿ, ಏಕೆಂದರೆ ತಪ್ಪು ಕಾರಣವು ಯಾವುದೇ ಕಾರಣಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿದೆ. ಆದ್ದರಿಂದ ಕಾರ್ಮಿಕರ ವಿಭಜನೆಯು ಸ್ಪಷ್ಟವಾಗಿದೆ: AI "ಏನು/ಹೇಗೆ," ನೀವು "ಏಕೆ" ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಕೋಡ್ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಹೇಳುವ ಅತ್ಯಂತ ಮೌಲ್ಯಯುತವಾದ ಕಾಮೆಂಟ್ ಆಗಿದೆ.
ಸಲಹೆ: ಕೋಡ್ ಸ್ವತಃ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವುದನ್ನು ಕಾಮೆಂಟ್ನೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸಬೇಡಿ (i = i + 1 // i ಅನ್ನು ಒಂದರಿಂದ ಹೆಚ್ಚಿಸಿ). AI ಕೆಲವೊಮ್ಮೆ ಇಂತಹ ಅನಗತ್ಯ ಕಾಮೆಂಟ್ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ; ಅವುಗಳನ್ನು ನಿವಾರಿಸಿ ಮತ್ತು "ಏಕೆ" ಕಾಮೆಂಟ್ಗಳಿಗೆ ನಿಮ್ಮ ಶಕ್ತಿಯನ್ನು ವಿನಿಯೋಗಿಸಿ.
ಹಂತ ಹಂತವಾಗಿ: AI ನೊಂದಿಗೆ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಜನರೇಷನ್
- ಗುರಿ ಪ್ರೇಕ್ಷಕರನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ. "ಈಗಷ್ಟೇ ಪ್ರಾರಂಭಿಸುತ್ತಿರುವ ಡೆವಲಪರ್," "ಈ API ಅನ್ನು ಬಳಸುವ ಬಾಹ್ಯ ತಂಡ," "ಭವಿಷ್ಯದ ನಾನು" - ಪ್ರೇಕ್ಷಕರು ಭಾಷೆ ಮತ್ತು ಆಳಕ್ಕೆ ಧ್ವನಿಯನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ.
- ಮೂಲವನ್ನು ನೀಡಿ. ಪ್ರಾಂಪ್ಟ್ಗೆ ಸಂಬಂಧಿತ ಕೋಡ್, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ README, ಉದಾಹರಣೆ ಬಳಕೆಯನ್ನು ಸೇರಿಸಿ. ಮೂಲರಹಿತ ಡಾಕ್ಯುಮೆಂಟ್ ಫ್ಯಾಬ್ರಿಕೇಶನ್ಗೆ ಆಹ್ವಾನವಾಗಿದೆ.
- ಹೇರುವ ರಚನೆ. README ಗಾಗಿ ಪ್ರಮಾಣಿತ ವಿಭಾಗಗಳು (ಉದ್ದೇಶ, ಸ್ಥಾಪನೆ, ಬಳಕೆ, ಕಾನ್ಫಿಗರೇಶನ್, ಕೊಡುಗೆ), ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ಗಾಗಿ ಪ್ರಾಜೆಕ್ಟ್ ಫಾರ್ಮ್ಯಾಟ್.
- "ಏಕೆ" ಸ್ಥಳಗಳನ್ನು ಗುರುತಿಸಿ. "ಯಾಕೆ' ಟಿಪ್ಪಣಿ ಇಲ್ಲಿ ಅಗತ್ಯವಿದೆ" ಎಂದು ತಾರ್ಕಿಕತೆಯನ್ನು ತಿಳಿದಿಲ್ಲದ ನಿರ್ಧಾರಗಳನ್ನು ಗುರುತಿಸಲು AI ಅನ್ನು ಕೇಳಿ; ನಂತರ ನೀವು ಆ ಖಾಲಿ ಜಾಗಗಳನ್ನು ಭರ್ತಿ ಮಾಡಿ.
- ಪರಿಶೀಲಿಸಿ. ವಾಸ್ತವವಾಗಿ ಅನುಸ್ಥಾಪನ ಹಂತಗಳನ್ನು ರನ್ ಮಾಡಿ; ಮಾದರಿ ಕೋಡ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಿ. ಕೆಲಸ ಮಾಡದ README ಯಾವುದೇ README ಗಿಂತ ಕೆಟ್ಟದಾಗಿದೆ.
ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು
ಪ್ರಕರಣ 1 - README ವೇಗವರ್ಧಿತ ಆನ್ಬೋರ್ಡಿಂಗ್. ತೆರೆದ ಮೂಲ ಉಪಕರಣದ README ಕಾಣೆಯಾಗಿದೆ; ಹೊಸ ಕೊಡುಗೆದಾರರು ಸರಾಸರಿ 2 ಗಂಟೆಗಳ ಕಾಲ ಅನುಸ್ಥಾಪನೆಯೊಂದಿಗೆ ಹೋರಾಡಿದರು. ತಂಡವು ಅನುಸ್ಥಾಪನಾ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಮತ್ತು ಪ್ಯಾಕೇಜ್.json ಅನ್ನು AI ಗೆ ನೀಡಿತು ಮತ್ತು ರಚನಾತ್ಮಕ README ಅನ್ನು ರಚಿಸಿತು, ನಂತರ ಹಂತಗಳನ್ನು ಸ್ವತಃ ಕ್ಲೀನ್ ಗಣಕದಲ್ಲಿ ಚಲಾಯಿಸಿತು ಮತ್ತು ಎರಡು ಕಾಣೆಯಾದ ಅವಲಂಬನೆಗಳನ್ನು ಸೇರಿಸಿತು. ನಂತರದ ಕೊಡುಗೆದಾರರಿಗೆ ಅನುಸ್ಥಾಪನಾ ಸಮಯವು ಸರಾಸರಿ 25 ನಿಮಿಷಗಳಿಗೆ ಕಡಿಮೆಯಾಗಿದೆ.
ಪ್ರಕರಣ 2 - ನಿರ್ಮಿತ "ಏಕೆ" ಬಲೆ. ಡೆವಲಪರ್ ಕಾಲಾವಧಿ ಮೌಲ್ಯದ (ಕಾಲಾವಧಿ=30) ಮುಂದಿನ ಕಾಮೆಂಟ್ಗಾಗಿ AI ಅನ್ನು ಕೇಳಿದರು. AI ಸಮಂಜಸವಾದ ಆದರೆ ತಪ್ಪಾದ ಸಮರ್ಥನೆಯನ್ನು "ಹೆಚ್ಚಿನ ನೆಟ್ವರ್ಕ್ ಸುಪ್ತತೆಯನ್ನು ಸಹಿಸಿಕೊಳ್ಳಲು" ಬರೆದಿದೆ; ನಿಜವಾದ ಕಾರಣವೆಂದರೆ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸೇವೆಯ ಒಪ್ಪಂದದ 30-ಸೆಕೆಂಡ್ ಮಿತಿ. ತಪ್ಪಾದ ವ್ಯಾಖ್ಯಾನವು ನಂತರದ ಡೆವಲಪರ್ಗೆ ಅನಗತ್ಯವಾಗಿ ಮೌಲ್ಯವನ್ನು ಹೆಚ್ಚಿಸಲು ಕಾರಣವಾಯಿತು, ಇದು ಘಟನೆಗೆ ಕಾರಣವಾಯಿತು. ಪಾಠ: ಕೋಡ್ ಮಾಲೀಕರು ಸಮರ್ಥನೆಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕು.
ಪ್ರಕರಣ 3 - ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ ಮಾನದಂಡವು ಸ್ವಯಂಚಾಲಿತವಾಗಿದೆ. 40 ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಸಹಾಯಕ ಮಾಡ್ಯೂಲ್ ಯಾವುದೇ ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. AI ಗೆ ಪ್ರಾಜೆಕ್ಟ್ ಫಾರ್ಮ್ಯಾಟ್ (ಗೂಗಲ್ ಶೈಲಿ) ನೀಡಲಾಯಿತು ಮತ್ತು ಪ್ರತಿ ಫಂಕ್ಷನ್ಗೆ ಪ್ಯಾರಾಮೀಟರ್, ರಿಟರ್ನ್ ಮತ್ತು ಎಕ್ಸೆಪ್ಶನ್ ವಿವರಣೆಗಳನ್ನು ತಯಾರಿಸಲಾಯಿತು; ಡೆವಲಪರ್ ಇದನ್ನು ಪರಿಶೀಲಿಸಿದ್ದಾರೆ ಮತ್ತು ಕೆಲವು ತಪ್ಪಾದ ಪ್ರಕಾರದ ಘೋಷಣೆಗಳನ್ನು ಸರಿಪಡಿಸಿದ್ದಾರೆ. 40 ಕಾರ್ಯಗಳನ್ನು ದಾಖಲಿಸುವುದು ಸುಮಾರು ಅರ್ಧ ದಿನದಿಂದ ಒಂದು ಗಂಟೆಯವರೆಗೆ ಕಡಿಮೆಯಾಗಿದೆ.
ನಾಲ್ಕು ನಕಲು ಮಾಡಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್ಗಳು
ರಚನಾತ್ಮಕ README ಡ್ರಾಫ್ಟ್:
ಗುರಿ ಪ್ರೇಕ್ಷಕರು: {{ಉದಾ. ಹೊಸ ಕೊಡುಗೆದಾರ}}.ಕೆಳಗಿನ ಫೈಲ್ಗಳ ಆಧಾರದ ಮೇಲೆ ಡ್ರಾಫ್ಟ್ README ಅನ್ನು ಬರೆಯಿರಿ. ವಿಭಾಗಗಳು: ಉದ್ದೇಶ, ವೈಶಿಷ್ಟ್ಯಗಳು, ಅಗತ್ಯತೆಗಳು, ಅನುಸ್ಥಾಪನೆ, ಕಾರ್ಯಾಚರಣೆ, ಸಂರಚನೆ, ಪರೀಕ್ಷೆ, ಕೊಡುಗೆ. ನಿಜವಾದ ಫೈಲ್ಗಳಿಂದ ಅನುಸ್ಥಾಪನ/ಚಾಲನೆಯಲ್ಲಿರುವ ಆಜ್ಞೆಗಳನ್ನು ಹೊರತೆಗೆಯಿರಿ; ಫಿಟ್ಟಿಂಗ್. ನೀವು ಖಚಿತವಾಗಿರದ ಸ್ಥಳಗಳನ್ನು "[ಪರಿಶೀಲಿಸಿ]" ನೊಂದಿಗೆ ಗುರುತಿಸಿ. ಮೂಲ: {{package.json / scripts / ಮಾದರಿ ಕೋಡ್}}
ಡಾಕ್ಸ್ಟ್ರಿಂಗ್/API ಉಲ್ಲೇಖ:
{{ಪ್ರಾಜೆಕ್ಟ್ ಶೈಲಿ: Google/NumPy/JSDoc}} ಫಾರ್ಮ್ಯಾಟ್ನಲ್ಲಿ ಈ ಕಾರ್ಯಗಳಿಗೆ ಡಾಕ್ಸ್ಟ್ರಿಂಗ್ ಬರೆಯಿರಿ: ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶ, ನಿಯತಾಂಕಗಳು (ಪ್ರಕಾರ + ಅರ್ಥ), ಹಿಂತಿರುಗಿಸುವಿಕೆ, ಎಸೆದ ವಿನಾಯಿತಿಗಳು, 1 ಚಿಕ್ಕ ಉದಾಹರಣೆ. ಕೋಡ್ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವುದನ್ನು ಪುನರಾವರ್ತಿಸಬೇಡಿ. "ಏಕೆ" ಅಗತ್ಯವಿರುವ ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳನ್ನು "[ಏಕೆ ಬೇಕು]" ಎಂದು ಗುರುತಿಸಿ, ಕೃತ್ರಿಮ ಸಮರ್ಥನೆಯನ್ನು ಬರೆಯಬೇಡಿ.{{ಕೋಡ್}}
"ಏಕೆ" ಕಾಮೆಂಟ್ಗಾಗಿ ಸ್ಪೇಸ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ:
ಈ ಕೋಡ್ನಲ್ಲಿ, ಮುಂದಿನ ಡೆವಲಪರ್ "ಇದು ಯಾಕೆ ಹೀಗೆ?" (ಮ್ಯಾಜಿಕ್ ಸಂಖ್ಯೆಗಳು, ಅಸಾಮಾನ್ಯ ನಿರ್ಧಾರಗಳು, ಪರಿಹಾರಗಳು). ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸ್ಕೆಲೆಟನ್ ಕಾಮೆಂಟ್ ನೀಡಿ, ಆದರೆ ತಾರ್ಕಿಕತೆಯನ್ನು ಖಾಲಿ ಬಿಡಿ; ನಾನು ಸಮರ್ಥನೆಯನ್ನು ತುಂಬುತ್ತೇನೆ.{{code}}
ಚೇಂಜ್ಲಾಗ್/PR ಹೇಳಿಕೆ:
ಕೆಳಗಿನ ವ್ಯತ್ಯಾಸದಿಂದ {{ಚೇಂಜ್ಲಾಗ್ ನಮೂದು / PR ವಿವರಣೆ}} ಬರೆಯಿರಿ. ಸ್ವರೂಪ: ಏನು ಬದಲಾಗಿದೆ (ಬಳಕೆದಾರ ಭಾಷೆಯಲ್ಲಿ), ಏಕೆ (ಸಂಚಿಕೆ: {{...}}), ಬ್ರೇಕಿಂಗ್ ಬದಲಾವಣೆ (ಯಾವುದಾದರೂ ಇದ್ದರೆ), ಅದನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿದೆಯೇ. ಗುರಿ ಪ್ರೇಕ್ಷಕರಿಗೆ ತಾಂತ್ರಿಕ ಪರಿಭಾಷೆಯನ್ನು ಹೊಂದಿಸಿ.{{diff}}
ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್
ದುರ್ಬಲ: "ಈ ಯೋಜನೆಗಾಗಿ README ಬರೆಯಿರಿ."
ಪ್ರಬಲ: "ಉದ್ದೇಶಿತ ಪ್ರೇಕ್ಷಕರು: ಡೆವಲಪರ್ ಈ ರೆಪೊವನ್ನು ಮೊದಲ ಬಾರಿಗೆ ಕ್ಲೋನ್ ಮಾಡುತ್ತಾರೆ. ಲಗತ್ತಿಸಲಾದ ಪ್ಯಾಕೇಜ್.json, ಡಾಕರ್-ಕಂಪೋಸ್.yml ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ಗಳು/ ಫೋಲ್ಡರ್ ಅನ್ನು ಆಧರಿಸಿ, ಉದ್ದೇಶ, ಅವಶ್ಯಕತೆಗಳು, ಸ್ಥಾಪನೆ, ಕಾರ್ಯಾಚರಣೆ, ಪರೀಕ್ಷೆ, ಕೊಡುಗೆ ವಿಭಾಗಗಳೊಂದಿಗೆ ಡ್ರಾಫ್ಟ್ README ಬರೆಯಿರಿ. ಈ ಫೈಲ್ಗಳಿಂದ ನೀವು ಎಲ್ಲಿಯೂ ಆದೇಶಗಳನ್ನು ಹೊರತೆಗೆಯಬೇಡಿ, ಈ ಫೈಲ್ಗಳಿಂದ ಮಾರ್ಕ್ ಮಾಡಬೇಡಿ [ಪರಿಶೀಲಿಸಿ]."
ಬಲವಾದ ಆವೃತ್ತಿಯು ಪ್ರೇಕ್ಷಕರಿಗೆ, ಮೂಲ, ರಚನೆ ಮತ್ತು "ಮಾಡು, ಅದನ್ನು ಗುರುತಿಸು" ನಿಯಮವನ್ನು ನೀಡುತ್ತದೆ; ಆದ್ದರಿಂದ ಡಾಕ್ಯುಮೆಂಟ್ ನೈಜ ಫೈಲ್ಗಳನ್ನು ಆಧರಿಸಿದೆ ಮತ್ತು ಪರಿಶೀಲಿಸಬೇಕಾದ ಸ್ಥಳಗಳು ಸ್ಪಷ್ಟವಾಗಿ ಗೋಚರಿಸುತ್ತವೆ.
ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರಕಾರ
AI ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ಮಾನವ ಸೇರಿಸುತ್ತದೆ/ಪರಿಶೀಲಿಸುತ್ತದೆ
README ಸ್ಥಾಪನೆ
ಹಂತದ ರೂಪರೇಖೆ
ಹಂತಗಳನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ದೃಢೀಕರಿಸಿ
ಡಾಕ್ಸ್ಟ್ರಿಂಗ್/API
ರಚನೆ, ನಿಯತಾಂಕ, ಪ್ರಕಾರ
ಸರಿಯಾದ ಪ್ರಕಾರ ಮತ್ತು "ಏಕೆ"
ಕೋಡ್ ಕಾಮೆಂಟ್
"ಅವನು ಏನು ಮಾಡುತ್ತಿದ್ದಾನೆ" ಸಾರಾಂಶ
"ಇದು ಏಕೆ" ಸಮರ್ಥನೆ
ಚೇಂಜ್ಲಾಗ್/PR
ಮೊದಲ ಕರಡು
ಪರಿಣಾಮ ಮತ್ತು ನಿಖರತೆ
ಆರ್ಕಿಟೆಕ್ಚರಲ್ ನಿರ್ಧಾರ (ADR)
ಅಸ್ಥಿಪಂಜರ
ನಿಜವಾದ ನಿರ್ಧಾರಗಳು ಮತ್ತು ಹೊಂದಾಣಿಕೆಗಳು
ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿದೆ
ಡಾಕ್ಯುಮೆಂಟ್ನ ಅತ್ಯಂತ ಅಪಾಯಕಾರಿ ಅಂಶವೆಂದರೆ ಅದು ಸುಳ್ಳಾಗಿದ್ದರೂ ಅದು ನಿಜವೆಂದು ತೋರುವುದು. ಕೋಡ್ ಬದಲಾದಾಗ ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ನವೀಕರಿಸದಿದ್ದರೆ, ಅದು ಓದುಗರನ್ನು ಸಕ್ರಿಯವಾಗಿ ದಾರಿತಪ್ಪಿಸುತ್ತದೆ. AI ನವೀಕರಣವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ: ವ್ಯತ್ಯಾಸವನ್ನು ನೀಡಿ ಮತ್ತು "ಈ ಬದಲಾವಣೆಯು ಡಾಕ್ಯುಮೆಂಟ್ನ ಯಾವ ಭಾಗಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?" ನೀವು ಕೇಳಬಹುದು. ಆದರೆ ಇದು ನವೀಕೃತತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ - ದಸ್ತಾವೇಜನ್ನು ನವೀಕರಣವನ್ನು ಕೋಡ್ ಬದಲಾವಣೆಯ ಭಾಗವಾಗಿ ಮಾಡಿ (PR ನ ಸ್ವೀಕಾರ ಮಾನದಂಡ). AI ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ; ತಂಡವು ಶಿಸ್ತನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ.
ಎಚ್ಚರಿಕೆ: README ನಲ್ಲಿನ ಅನುಸ್ಥಾಪನಾ ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸದೆ ಪ್ರಕಟಿಸಬೇಡಿ. "ಬಹುಶಃ ಕೆಲಸ" ಡಾಕ್ಯುಮೆಂಟ್ ಹೊಸ ಡೆವಲಪರ್ನ ಮೊದಲ ದಿನವನ್ನು ಹಾಳುಮಾಡಬಹುದು ಮತ್ತು ನಂಬಿಕೆಯನ್ನು ನಾಶಪಡಿಸಬಹುದು. ಸ್ವಚ್ಛ ಪರಿಸರದಲ್ಲಿ ಹಂತಗಳನ್ನು ನೀವೇ ಚಲಾಯಿಸಿ.
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- AI ಗೆ ಹೊಂದಿಕೊಳ್ಳಲು "ಏಕೆ" ಪಡೆಯುವುದು. ಸುಳ್ಳು ಸಮರ್ಥನೆಯು ಯಾವುದೇ ಸಮರ್ಥನೆಗಿಂತ ಕೆಟ್ಟದಾಗಿದೆ; ಕೋಡ್ ಮಾಲೀಕರು ವಿನ್ಯಾಸದ ಕಾರಣವನ್ನು ಬರೆಯಬೇಕು.
- ಅನುಸ್ಥಾಪನಾ ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿಲ್ಲ. ಕೆಲಸ ಮಾಡದ README ನಂಬಿಕೆಯನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ.
- ಕೋಡ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುವ ಅನಗತ್ಯ ಕಾಮೆಂಟ್. ಇದು ಶಬ್ದವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ನಿಜವಾದ "ಏಕೆ" ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ.
- ಗುರಿ ಪ್ರೇಕ್ಷಕರನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತಿಲ್ಲ. ಯಾರಿಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂಬುದು ಅಸ್ಪಷ್ಟವಾಗಿರುವ ಡಾಕ್ಯುಮೆಂಟ್ ಅನನುಭವಿ ಅಥವಾ ತಜ್ಞರಿಗೆ ಯಾವುದೇ ಪ್ರಯೋಜನವಾಗುವುದಿಲ್ಲ.
- ಪ್ರಕ್ರಿಯೆಯಿಂದ ನವೀಕರಣವನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು. ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಕೋಡ್ನೊಂದಿಗೆ ನವೀಕರಿಸದಿದ್ದರೆ ಅದು ತ್ವರಿತವಾಗಿ ತಪ್ಪುದಾರಿಗೆಳೆಯುತ್ತದೆ.
ಸಾರಾಂಶದಲ್ಲಿ
ದಾಖಲಾತಿಯಿಂದ ಹೆಚ್ಚಿನ ಯಾಂತ್ರಿಕ ಹೊರೆಯನ್ನು AI ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ತ್ವರಿತ ಡ್ರಾಫ್ಟ್ಗಳು README, ಡಾಕ್ಸ್ಟ್ರಿಂಗ್, API ಉಲ್ಲೇಖ, ಚೇಂಜ್ಲಾಗ್ ಮತ್ತು PR ವಿವರಣೆಗಳು. ಆದರೆ ಅದು "ಏಕೆ" ಎಂದು ತಿಳಿಯುವುದಿಲ್ಲ, ಇದು ಅತ್ಯಮೂಲ್ಯವಾದ ಪದರವಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ರೂಪಿಸುವುದು ಅಪಾಯಕಾರಿ. ಕಾರ್ಮಿಕರ ವಿಭಜನೆಯು ಸ್ಪಷ್ಟವಾಗಿದೆ: AI "ಏನು/ಹೇಗೆ" ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ನೀವು "ಏಕೆ" ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಪ್ರೇಕ್ಷಕರನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ, ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒದಗಿಸಿ, ರಚನೆಯನ್ನು ವಿಧಿಸಿ, ಹೊಂದಿಕೊಳ್ಳಲು ಸ್ಥಳಗಳನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಪ್ರತಿ ಅನುಸ್ಥಾಪನ ಹಂತವನ್ನು ನೀವೇ ಚಲಾಯಿಸುವ ಮೂಲಕ ಪರಿಶೀಲಿಸಿ. ದಸ್ತಾವೇಜನ್ನು ಕೋಡ್ ಬದಲಾವಣೆಯ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿ ಮಾಡಿ.
ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ
ದಸ್ತಾವೇಜನ್ನು ಕಾಣೆಯಾಗಿರುವ ಅಥವಾ ಹಳೆಯದಾದ ಮಾಡ್ಯೂಲ್ ಅಥವಾ ಸಣ್ಣ ಯೋಜನೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಮೊದಲು "ರಚನಾತ್ಮಕ README ಡ್ರಾಫ್ಟ್" (ಅಥವಾ ಡಾಕ್ಸ್ಟ್ರಿಂಗ್) ಟೆಂಪ್ಲೇಟ್ನೊಂದಿಗೆ AI ನಿಂದ ಔಟ್ಲೈನ್ ಅನ್ನು ರಚಿಸಿ; ಮೂಲ ಮತ್ತು ಗುರಿ ಪ್ರೇಕ್ಷಕರನ್ನು ನೀಡಲು ಮರೆಯದಿರಿ. ನಂತರ AI ಗುರುತಿಸಿರುವ ಪ್ರತಿಯೊಂದು ಬಿಂದುವಿನ ಮೂಲಕ ಹೋಗಿ [ಪರಿಶೀಲಿಸಿ] ಅಥವಾ [ಏಕೆ ಅಗತ್ಯವಿದೆ]: ವಾಸ್ತವವಾಗಿ ಸೆಟಪ್ ಹಂತಗಳನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಜ್ಞಾನದೊಂದಿಗೆ ವಿನ್ಯಾಸವನ್ನು "ಏಕೆ" ಅನ್ನು ಭರ್ತಿ ಮಾಡಿ. ಎಷ್ಟು ಹಂತಗಳನ್ನು ಸರಿಪಡಿಸಬೇಕು ಮತ್ತು ನೀವು ಎಷ್ಟು "ಏಕೆ" ಸೇರಿಸಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.
ಪರಿಶೀಲನಾಪಟ್ಟಿ
- [ ] ದಾಖಲಾತಿಯಲ್ಲಿ, ನಾನು "ಏನು/ಹೇಗೆ" ಮತ್ತು "ಏಕೆ" ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇನೆ.
- [ ] ನಾನು AI ಅನ್ನು "ಏಕೆ" ಎಂದು ರೂಪಿಸುವುದಿಲ್ಲ, ನಾನೇ ಅದನ್ನು ಸೇರಿಸುತ್ತೇನೆ.
- [ ] ನಾನು ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಗುರಿ ಪ್ರೇಕ್ಷಕರಿಗೆ ಮತ್ತು ನಿಜವಾದ ಮೂಲ ಫೈಲ್ಗಳನ್ನು ನೀಡುತ್ತೇನೆ.
- [ ] ನಾನು ವೈಯಕ್ತಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ AI ಗುರುತಿಸಿದ [ಪರಿಶೀಲಿಸಿ] ಅಂಕಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ.
- [ ] ಕೋಡ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುವ ಅನಗತ್ಯ ಕಾಮೆಂಟ್ಗಳನ್ನು ನಾನು ತೆಗೆದುಹಾಕುತ್ತೇನೆ.
- [ ] ನಾನು ದಸ್ತಾವೇಜನ್ನು ನವೀಕರಣವನ್ನು ಕೋಡ್ ಬದಲಾವಣೆಯ ಭಾಗವಾಗಿ ಮಾಡುತ್ತಿದ್ದೇನೆ.