ഡോക്യുമെൻ്റേഷൻ, README, കോഡ് കമൻ്റുകൾ

നേട്ടങ്ങൾ:

• ടാർഗെറ്റ് പ്രേക്ഷകരെയും AI ഉപയോഗിച്ച് ഉറവിടത്തെയും അടിസ്ഥാനമാക്കി README, docstring, ചേഞ്ച്‌ലോഗ് ഡ്രാഫ്റ്റുകൾ നിർമ്മിക്കാനുള്ള കഴിവ്
• ഡോക്യുമെൻ്റേഷനിൽ 'എന്ത്/എങ്ങനെ', 'എന്തുകൊണ്ട്' എന്നീ പാളികൾ വേർതിരിക്കാനും ഒരു മനുഷ്യനായി 'എന്തുകൊണ്ട്' ചേർക്കാനുമുള്ള കഴിവ്
• ഇൻസ്റ്റാളേഷൻ ഘട്ടങ്ങൾ പരിശോധിച്ച് അവ വ്യക്തിഗതമായി പ്രവർത്തിപ്പിക്കുകയും ഡോക്യുമെൻ്റ് കോഡ് മാറ്റത്തിൻ്റെ ഭാഗമാക്കുകയും ചെയ്യുന്നു

സോഫ്‌റ്റ്‌വെയറിൻ്റെ ഏറ്റവും കൂടുതൽ അവഗണിക്കപ്പെടുന്നതും എന്നാൽ ദീർഘകാലം നിലനിൽക്കുന്നതുമായ ഭാഗം ഡോക്യുമെൻ്റേഷനാണ്. മാസങ്ങൾക്ക് ശേഷവും കോഡ് വായിക്കാവുന്നതാണ്; എഴുതിയ ആൾ പോയി, സന്ദർഭം മറന്നു, എഴുതിയത് മാത്രം അവശേഷിക്കുന്നു. ഒരു നല്ല README (ഒരു പ്രോജക്റ്റ് എന്താണെന്നും അത് എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്ത് പ്രവർത്തിപ്പിക്കാമെന്നും വിശദീകരിക്കുന്ന ആമുഖ പ്രമാണം), വിശദീകരണ കോഡ് കമൻ്റുകളും അപ്-ടു-ഡേറ്റ് API ഡോക്യുമെൻ്റേഷനും (ഒരു ഇൻ്റർഫേസ് എങ്ങനെ ഉപയോഗിക്കണമെന്ന് വിശദീകരിക്കുന്ന ഒരു റഫറൻസ്) ഒരു ടീമിൻ്റെ വേഗത നേരിട്ട് നിർണ്ണയിക്കുന്നു. ഡോക്യുമെൻ്റേഷനിൽ നിന്ന് AI വളരെയധികം "എഴുത്ത് ക്ഷീണം" എടുക്കുന്നു - എന്നാൽ ഇത് ഒരു കെണിയിൽ വരുന്നു: AI-ക്ക് കോഡിൽ നിന്ന് അത് എന്തുചെയ്യുമെന്ന് അനുമാനിക്കാൻ കഴിയും, പക്ഷേ എന്തുകൊണ്ടാണ് ഇത് അങ്ങനെ ചെയ്തതെന്ന് പലപ്പോഴും അറിയില്ല.

ഈ യൂണിറ്റിൽ, നിങ്ങൾ എങ്ങനെ README, കോഡ് കമൻ്റ്, ഡോക്‌സ്ട്രിംഗ് (ഓരോ ഫംഗ്‌ഷൻ/ക്ലാസ്സിനും എഴുതിയ കമൻ്റ് ബ്ലോക്ക്), API ഡോക്യുമെൻ്റ്, AI ഉപയോഗിച്ച് ചേഞ്ച്‌ലോഗ് എന്നിവ എങ്ങനെ നിർമ്മിക്കാമെന്ന് പഠിക്കും; ഡോക്യുമെൻ്റേഷൻ്റെ ഏറ്റവും മൂല്യവത്തായ ഭാഗം എങ്ങനെ മാനുഷികമായി സംരക്ഷിക്കാം: "എന്തുകൊണ്ട്."

"എന്ത്", "എന്തുകൊണ്ട്" എന്നിവ തമ്മിലുള്ള വ്യത്യാസം

ഡോക്യുമെൻ്റേഷനിൽ രണ്ട് തലങ്ങളുണ്ട്. ആദ്യത്തേത് എന്താണ്/എങ്ങനെ: "ഈ ഫംഗ്ഷൻ ഒരു ലിസ്റ്റ് അടുക്കുന്നു", "ഇൻസ്റ്റാൾ ചെയ്യാൻ ഈ കമാൻഡ് പ്രവർത്തിപ്പിക്കുക". ഇവ കോഡിൽ നിന്നും ഘടനയിൽ നിന്നും വേർതിരിച്ചെടുക്കാൻ കഴിയും; AI ഇവിടെ മികച്ചതാണ്. രണ്ടാമതായി, എന്തുകൊണ്ട്: "എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഈ സേവനം സിൻക്രണസ് എന്നതിലുപരി അസമന്വിതമാക്കിയത്", "എന്തുകൊണ്ടാണ് ഈ പരിധി മൂല്യം 30 സെക്കൻഡ്", "എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഈ ലൈബ്രറി മറ്റൊന്നിൽ നിന്ന് തിരഞ്ഞെടുത്തത്". ഇവ കോഡിൽ എഴുതിയിട്ടില്ല; ഇത് ഡിസൈൻ തീരുമാനങ്ങൾ, നിയന്ത്രണങ്ങൾ, മുൻകാല വേദന എന്നിവയുടെ ഉൽപ്പന്നമാണ്.

"എന്തുകൊണ്ട്" എന്ന് AI-ക്ക് അറിയില്ല; ഏറ്റവും മികച്ചത്, ഇത് ന്യായമായ ഒരു ഊഹം ഉണ്ടാക്കുന്നു-അത് അപകടകരമാണ്, കാരണം തെറ്റായ കാരണം ഒരു കാരണവുമില്ലാത്തതിനേക്കാൾ മോശമാണ്. അതിനാൽ തൊഴിൽ വിഭജനം വ്യക്തമാണ്: AI "എന്ത്/എങ്ങനെ," നിങ്ങൾ "എന്തുകൊണ്ട്" എന്ന് ചേർക്കുന്നു. കോഡിന് പറയാൻ കഴിയാത്തത് പറയുന്ന അഭിപ്രായമാണ് ഏറ്റവും മൂല്യവത്തായ അഭിപ്രായം.

നുറുങ്ങ്: കോഡ് തന്നെ വ്യക്തമായി പറയുന്നത് ഒരു കമൻ്റിലൂടെ ആവർത്തിക്കരുത് (i = i + 1 // i ഒന്നായി വർദ്ധിപ്പിക്കുക). AI ചിലപ്പോൾ ഇത്തരം അനാവശ്യ കമൻ്റുകൾ ഉണ്ടാക്കുന്നു; അവ ഇല്ലാതാക്കി, "എന്തുകൊണ്ട്" അഭിപ്രായങ്ങൾക്കായി നിങ്ങളുടെ ഊർജ്ജം വിനിയോഗിക്കുക.

ഘട്ടം ഘട്ടമായി: AI ഉപയോഗിച്ചുള്ള ഡോക്യുമെൻ്റേഷൻ ജനറേഷൻ

1. ടാർഗെറ്റ് പ്രേക്ഷകരെ വ്യക്തമാക്കുക. "ഒരു ഡവലപ്പർ ഇപ്പോൾ ആരംഭിക്കുന്നു," "ഈ API ഉപയോഗിക്കുന്ന ബാഹ്യ ടീം," "ഭാവി ഞാൻ" - പ്രേക്ഷകർ ഭാഷയ്ക്കും ആഴത്തിനും ടോൺ സജ്ജമാക്കുന്നു.
2. ഉറവിടം നൽകുക. പ്രോംപ്റ്റിലേക്ക് പ്രസക്തമായ കോഡ്, നിലവിലുള്ള README, ഉദാഹരണ ഉപയോഗം എന്നിവ ചേർക്കുക. ഒരു ഉറവിടമില്ലാത്ത രേഖ കെട്ടിച്ചമയ്ക്കാനുള്ള ക്ഷണമാണ്.
3. അടിച്ചേൽപ്പിക്കുന്ന ഘടന. README എന്നതിനായുള്ള സ്റ്റാൻഡേർഡ് വിഭാഗങ്ങൾ (ഉദ്ദേശ്യം, ഇൻസ്റ്റാളേഷൻ, ഉപയോഗം, കോൺഫിഗറേഷൻ, സംഭാവന), ഡോക്‌സ്‌ട്രിംഗിനായുള്ള പ്രോജക്റ്റ് ഫോർമാറ്റ്.
4. "എന്തുകൊണ്ട്" സ്പെയ്സുകൾ അടയാളപ്പെടുത്തുക. "എന്തുകൊണ്ട്" കുറിപ്പ് ഇവിടെ ആവശ്യമാണ്" എന്ന് യുക്തി അറിയാത്ത തീരുമാനങ്ങൾ അടയാളപ്പെടുത്താൻ AI-യോട് ആവശ്യപ്പെടുക; അപ്പോൾ നിങ്ങൾ ആ ശൂന്യത പൂരിപ്പിക്കുക.
5. സ്ഥിരീകരിക്കുക. യഥാർത്ഥത്തിൽ ഇൻസ്റ്റലേഷൻ ഘട്ടങ്ങൾ പ്രവർത്തിപ്പിക്കുക; സാമ്പിൾ കോഡ് പരീക്ഷിക്കുക. പ്രവർത്തിക്കാത്ത ഒരു README, README-യെക്കാൾ മോശമാണ്.

മൂന്ന് മിനി കേസുകൾ

കേസ് 1 - README ഓൺബോർഡിംഗ് ത്വരിതപ്പെടുത്തി. ഒരു ഓപ്പൺ സോഴ്സ് ടൂളിൻ്റെ README കാണുന്നില്ല; പുതിയ സംഭാവകർ ശരാശരി 2 മണിക്കൂർ ഇൻസ്റ്റാളേഷനുമായി ബുദ്ധിമുട്ടി. ടീം ഇൻസ്റ്റാളേഷൻ സ്ക്രിപ്റ്റുകളും പാക്കേജ്.json-ഉം AI-ക്ക് നൽകുകയും ഒരു ഘടനാപരമായ README ഡ്രാഫ്റ്റ് ചെയ്യുകയും ചെയ്തു, തുടർന്ന് ഒരു ക്ലീൻ മെഷീനിൽ സ്റ്റെപ്പുകൾ സ്വയം പ്രവർത്തിപ്പിക്കുകയും കാണാതായ രണ്ട് ഡിപൻഡൻസികൾ ചേർക്കുകയും ചെയ്തു. തുടർന്നുള്ള സംഭാവനകൾക്കുള്ള ഇൻസ്റ്റാളേഷൻ സമയം ശരാശരി 25 മിനിറ്റായി കുറഞ്ഞു.

കേസ് 2 - ഉണ്ടാക്കിയ "എന്തുകൊണ്ട്" കെണി. ഒരു ഡെവലപ്പർ AI-യോട് ഒരു ടൈംഔട്ട് മൂല്യത്തിന് അടുത്തായി ഒരു അഭിപ്രായം ചോദിച്ചു (ടൈംഔട്ട്=30). "ഉയർന്ന നെറ്റ്‌വർക്ക് ലേറ്റൻസി സഹിക്കാൻ" AI ന്യായമായതും എന്നാൽ തെറ്റായതുമായ ഒരു ന്യായീകരണം എഴുതി; ഒരു ഡൗൺസ്ട്രീം സേവനത്തിൻ്റെ കരാർ 30 സെക്കൻഡ് പരിധി ആയിരുന്നു യഥാർത്ഥ കാരണം. തെറ്റായ വ്യാഖ്യാനം തുടർന്നുള്ള ഒരു ഡെവലപ്പറെ അനാവശ്യമായി മൂല്യം വർദ്ധിപ്പിക്കാൻ ഇടയാക്കി, ഇത് ഒരു സംഭവത്തിലേക്ക് നയിച്ചു. പാഠം: കോഡ് ഉടമ ന്യായീകരണം പരിശോധിക്കണം.

കേസ് 3 - ഡോക്‌സ്ട്രിംഗ് സ്റ്റാൻഡേർഡ് ഓട്ടോമേറ്റഡ് ആയി. 40 ഫംഗ്‌ഷനുകളുള്ള ഒരു ഓക്സിലറി മൊഡ്യൂളിന് ഡോക്‌സ്‌ട്രിംഗുകൾ ഇല്ലായിരുന്നു. AI-ക്ക് പ്രോജക്റ്റ് ഫോർമാറ്റ് (ഗൂഗിൾ ശൈലി) നൽകുകയും ഓരോ ഫംഗ്‌ഷനുമുള്ള പാരാമീറ്റർ, റിട്ടേൺ, എക്‌സ്‌പ്‌ഷൻ വിവരണങ്ങൾ എന്നിവ നിർമ്മിക്കുകയും ചെയ്തു; ഡെവലപ്പർ ഇവ അവലോകനം ചെയ്യുകയും ചില തെറ്റായ തരത്തിലുള്ള പ്രഖ്യാപനങ്ങൾ പരിഹരിക്കുകയും ചെയ്തു. 40 ഫംഗ്‌ഷനുകൾ ഡോക്യുമെൻ്റ് ചെയ്യുന്നത് അര ദിവസത്തിൽ നിന്ന് ഒരു മണിക്കൂറായി കുറഞ്ഞു.

പകർത്താവുന്ന നാല് ടെംപ്ലേറ്റുകൾ

ഘടനാപരമായ README ഡ്രാഫ്റ്റ്:

ടാർഗെറ്റ് പ്രേക്ഷകർ: {{ഉദാ. പുതിയ സംഭാവകൻ}}.ചുവടെയുള്ള ഫയലുകളെ അടിസ്ഥാനമാക്കി ഒരു ഡ്രാഫ്റ്റ് README എഴുതുക. വിഭാഗങ്ങൾ: ഉദ്ദേശ്യം, സവിശേഷതകൾ, ആവശ്യകതകൾ, ഇൻസ്റ്റാളേഷൻ, പ്രവർത്തനം, കോൺഫിഗറേഷൻ, ടെസ്റ്റിംഗ്, സംഭാവന. യഥാർത്ഥ ഫയലുകളിൽ നിന്ന് ഇൻസ്റ്റലേഷൻ/റണ്ണിംഗ് കമാൻഡുകൾ എക്സ്ട്രാക്റ്റ് ചെയ്യുക; ഫിറ്റിംഗ്. നിങ്ങൾക്ക് ഉറപ്പില്ലാത്ത സ്ഥലങ്ങൾ "[VERIFY]" ഉപയോഗിച്ച് അടയാളപ്പെടുത്തുക. ഉറവിടം: {{package.json / സ്ക്രിപ്റ്റുകൾ / സാമ്പിൾ കോഡ്}}

ഡോക്‌സ്ട്രിംഗ്/എപിഐ റഫറൻസ്:

{{പ്രോജക്റ്റ് ശൈലി: Google/NumPy/JSDoc}} ഫോർമാറ്റിൽ ഈ ഫംഗ്‌ഷനുകളിലേക്ക് ഡോക്‌സ്ട്രിംഗ് എഴുതുക: ഹ്രസ്വ സംഗ്രഹം, പരാമീറ്ററുകൾ (തരം + അർത്ഥം), മടക്കം, ഒഴിവാക്കലുകൾ, 1 ചെറിയ ഉദാഹരണം. കോഡ് വ്യക്തമായി പറയുന്നത് ആവർത്തിക്കരുത്. "എന്തുകൊണ്ട്" ആവശ്യമുള്ള ഡിസൈൻ തീരുമാനങ്ങളെ "[എന്തുകൊണ്ട് ആവശ്യമാണ്]" എന്ന് അടയാളപ്പെടുത്തുക, കെട്ടിച്ചമച്ച ന്യായീകരണം എഴുതരുത്.{{code}}

"എന്തുകൊണ്ട്" എന്ന കമൻ്റിനുള്ള സ്‌പെയ്‌സ് നീക്കം ചെയ്യുക:

ഈ കോഡിൽ, അടുത്ത ഡെവലപ്പർ "എന്തുകൊണ്ടാണിത്?" (മാന്ത്രിക സംഖ്യകൾ, അസാധാരണമായ തീരുമാനങ്ങൾ, പരിഹാരങ്ങൾ). ഓരോന്നിനും ഒരു അഭിപ്രായം SKELETON നൽകുക, എന്നാൽ യുക്തി ശൂന്യമായി വിടുക; ഞാൻ ന്യായീകരണം പൂരിപ്പിക്കും.{{code}}

ചേഞ്ച്ലോഗ്/പിആർ പ്രസ്താവന:

ചുവടെയുള്ള വ്യത്യാസത്തിൽ നിന്ന് ഒരു {{ചേഞ്ച്ലോഗ് എൻട്രി / പിആർ വിവരണം}} എഴുതുക. ഫോർമാറ്റ്: എന്താണ് മാറിയത് (ഉപയോക്തൃ ഭാഷയിൽ), എന്തുകൊണ്ട് (പ്രശ്നം: {{...}}), ബ്രേക്കിംഗ് ചേഞ്ച് (എന്തെങ്കിലും ഉണ്ടെങ്കിൽ), അത് പരീക്ഷിച്ചിട്ടുണ്ടോ. ടാർഗെറ്റ് പ്രേക്ഷകരിലേക്ക് സാങ്കേതിക പദപ്രയോഗം ക്രമീകരിക്കുക.{{diff}}

ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്

ദുർബലമായത്: "ഈ പ്രോജക്റ്റിനായി ഒരു README എഴുതുക."

ശക്തം: "ടാർഗെറ്റ് പ്രേക്ഷകർ: ഒരു ഡെവലപ്പർ ഈ റിപ്പോ ആദ്യമായി ക്ലോൺ ചെയ്യുന്നു. അറ്റാച്ച് ചെയ്‌ത പാക്കേജ്.json, docker-compose.yml, സ്‌ക്രിപ്‌റ്റുകൾ/ഫോൾഡർ എന്നിവയെ അടിസ്ഥാനമാക്കി, ഉദ്ദേശ്യം, ആവശ്യകതകൾ, ഇൻസ്റ്റാളേഷൻ, ഓപ്പറേഷൻ, ടെസ്റ്റിംഗ്, സംഭാവന വിഭാഗങ്ങൾ എന്നിവയ്‌ക്കൊപ്പം ഒരു ഡ്രാഫ്റ്റ് README എഴുതുക. ഈ ഫയലുകളിൽ നിന്ന് എവിടെയും കമാൻഡുകൾ എക്‌സ്‌ട്രാക്റ്റ് ചെയ്യരുത്, അവയിൽ നിന്ന് കമാൻഡുകൾ മാർക്ക് അപ്പ് ചെയ്യരുത്. [പരിശോധിക്കുക]."

ശക്തമായ പതിപ്പ് പ്രേക്ഷകർക്ക്, ഉറവിടം, ഘടന, "ഇത് ഉണ്ടാക്കുക, അടയാളപ്പെടുത്തുക" നിയമം എന്നിവ നൽകുന്നു; അതിനാൽ പ്രമാണം യഥാർത്ഥ ഫയലുകളെ അടിസ്ഥാനമാക്കിയുള്ളതും പരിശോധിക്കേണ്ട സ്ഥലങ്ങൾ വ്യക്തമായി കാണാവുന്നതുമാണ്.

പ്രമാണ തരം

AI നന്നായി പ്രവർത്തിക്കുന്നു

മനുഷ്യൻ ചേർക്കുന്നു/പരിശോധിക്കുന്നു

README ഇൻസ്റ്റാളേഷൻ

ഘട്ടം രൂപരേഖ

ഘട്ടങ്ങൾ പ്രവർത്തിപ്പിച്ച് സ്ഥിരീകരിക്കുക

ഡോക്‌സ്ട്രിംഗ്/എപിഐ

ഘടന, പരാമീറ്റർ, തരം

ശരിയായ തരവും "എന്തുകൊണ്ട്"

കോഡ് അഭിപ്രായം

"അവൻ എന്താണ് ചെയ്യുന്നത്" എന്നതിൻ്റെ സംഗ്രഹം

"എന്തുകൊണ്ടാണിത്" ന്യായീകരണം

ചേഞ്ച്ലോഗ്/പിആർ

ആദ്യ ഡ്രാഫ്റ്റ്

ആഘാതവും കൃത്യതയും

വാസ്തുവിദ്യാ തീരുമാനം (ADR)

അസ്ഥികൂടം

യഥാർത്ഥ തീരുമാനങ്ങളും വിട്ടുവീഴ്ചകളും

ഡോക്യുമെൻ്റേഷന് പരിപാലനം ആവശ്യമാണ്

ഒരു ഡോക്യുമെൻ്റിൻ്റെ ഏറ്റവും അപകടകരമായ വശം അത് തെറ്റാണെങ്കിലും ശരിയാണെന്ന് തോന്നുന്നതാണ്. കോഡ് മാറുകയും പ്രമാണം അപ്ഡേറ്റ് ചെയ്യാതിരിക്കുകയും ചെയ്യുമ്പോൾ, അത് വായനക്കാരനെ സജീവമായി തെറ്റിദ്ധരിപ്പിക്കുന്നു. AI അപ്‌ഡേറ്റ് ചെയ്യുന്നത് എളുപ്പമാക്കുന്നു: ഒരു വ്യത്യാസം നൽകി "ഈ മാറ്റം പ്രമാണത്തിൻ്റെ ഏത് ഭാഗങ്ങളെയാണ് ബാധിക്കുന്നത്?" നിങ്ങൾ ചോദിച്ചേക്കാം. എന്നാൽ ഇത് കാലികത ഉറപ്പാക്കുന്ന പ്രക്രിയയാണ് - ഡോക്യുമെൻ്റേഷൻ അപ്‌ഡേറ്റ് കോഡ് മാറ്റത്തിൻ്റെ ഭാഗമാക്കുക (PR-ൻ്റെ സ്വീകാര്യത മാനദണ്ഡം). AI ത്വരിതപ്പെടുത്തുന്നു; ടീം അച്ചടക്കം കെട്ടിപ്പടുക്കുന്നു.

മുന്നറിയിപ്പ്: ഒരു README-ലെ ഇൻസ്റ്റാളേഷൻ ഘട്ടങ്ങൾ പരിശോധിക്കാതെ പ്രസിദ്ധീകരിക്കരുത്. "ഒരുപക്ഷേ പ്രവർത്തിക്കാം" എന്ന ഡോക്യുമെൻ്റിന് ഒരു പുതിയ ഡെവലപ്പറുടെ ആദ്യ ദിനം നശിപ്പിക്കാനും വിശ്വാസത്തെ ഇല്ലാതാക്കാനും കഴിയും. വൃത്തിയുള്ള അന്തരീക്ഷത്തിൽ പടികൾ സ്വയം പ്രവർത്തിപ്പിക്കുക.

സാധാരണ തെറ്റുകൾ

• AI-ക്ക് അനുയോജ്യമാക്കുന്നതിന് "എന്തുകൊണ്ട്" ലഭിക്കുന്നു. ന്യായീകരണമില്ലാത്തതിനേക്കാൾ മോശമാണ് തെറ്റായ ന്യായീകരണം; കോഡ് ഉടമ ഡിസൈൻ കാരണം എഴുതണം.
• ഇൻസ്റ്റലേഷൻ ഘട്ടങ്ങൾ പരിശോധിക്കുന്നില്ല. പ്രവർത്തിക്കാത്ത README വിശ്വാസത്തെ നശിപ്പിക്കുന്നു.
• കോഡ് ആവർത്തിക്കുന്ന അനാവശ്യ കമൻ്റ്. യഥാർത്ഥ "എന്തുകൊണ്ട്" വ്യാഖ്യാനങ്ങളെ മറച്ചുവെക്കുന്ന, ശബ്ദമുണ്ടാക്കുന്നു.
• ടാർഗെറ്റ് പ്രേക്ഷകരെ വ്യക്തമാക്കുന്നില്ല. ആർക്കാണ് ഇത് എഴുതിയതെന്ന് വ്യക്തമല്ലാത്ത ഒരു പ്രമാണം തുടക്കക്കാർക്കോ വിദഗ്‌ദ്ധർക്കോ ഒരു പ്രയോജനവുമില്ല.
• പ്രക്രിയയിൽ നിന്ന് അപ്ഡേറ്റ് വേർതിരിക്കുന്നു. ഡോക്യുമെൻ്റ് കോഡ് ഉപയോഗിച്ച് അപ്‌ഡേറ്റ് ചെയ്തില്ലെങ്കിൽ അത് പെട്ടെന്ന് തെറ്റിദ്ധരിപ്പിക്കുന്നതാണ്.

ചുരുക്കത്തിൽ

ഡോക്യുമെൻ്റേഷനിൽ നിന്ന് മെക്കാനിക്കൽ ഭാരത്തിൻ്റെ ഭൂരിഭാഗവും AI എടുക്കുന്നു: പെട്ടെന്നുള്ള ഡ്രാഫ്റ്റുകൾ README, docstring, API റഫറൻസ്, ചേഞ്ച്ലോഗ്, PR വിവരണങ്ങൾ. എന്നാൽ ഏറ്റവും മൂല്യവത്തായ പാളിയായ "എന്തുകൊണ്ട്" അത് അറിയാൻ കഴിയില്ല, അത് ഉണ്ടാക്കുന്നത് അപകടകരമാണ്. തൊഴിൽ വിഭജനം വ്യക്തമാണ്: AI ഉൽപ്പാദിപ്പിക്കുന്നത് "എന്ത്/എങ്ങനെ," നിങ്ങൾ "എന്തുകൊണ്ട്" ചേർക്കുന്നു. പ്രേക്ഷകരെ വ്യക്തമാക്കുക, ഉറവിടങ്ങൾ നൽകുക, ഘടന ചുമത്തുക, അനുയോജ്യമായ സ്ഥലങ്ങൾ അടയാളപ്പെടുത്തുക, ഓരോ ഇൻസ്റ്റാളേഷൻ ഘട്ടവും സ്വയം പ്രവർത്തിപ്പിച്ച് പരിശോധിച്ചുറപ്പിക്കുക. ഡോക്യുമെൻ്റേഷൻ കോഡ് മാറ്റത്തിൻ്റെ അവിഭാജ്യ ഘടകമാക്കുക.

ആപ്ലിക്കേഷൻ ടാസ്ക്

ഡോക്യുമെൻ്റേഷൻ നഷ്‌ടമായതോ കാലഹരണപ്പെട്ടതോ ആയ ഒരു മൊഡ്യൂൾ അല്ലെങ്കിൽ ചെറിയ പ്രോജക്‌റ്റ് തിരഞ്ഞെടുക്കുക. ആദ്യം "ഘടനാപരമായ README ഡ്രാഫ്റ്റ്" (അല്ലെങ്കിൽ ഡോക്‌സ്ട്രിംഗ്) ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് AI-ൽ നിന്ന് ഒരു ഔട്ട്‌ലൈൻ സൃഷ്ടിക്കുക; ഉറവിടവും ടാർഗെറ്റ് പ്രേക്ഷകരും നൽകുന്നത് ഉറപ്പാക്കുക. തുടർന്ന് AI അടയാളപ്പെടുത്തിയ ഓരോ പോയിൻ്റിലൂടെയും പോകുക [പരിശോധിക്കുക] അല്ലെങ്കിൽ [എന്തുകൊണ്ട് ആവശ്യമാണ്]: യഥാർത്ഥത്തിൽ സജ്ജീകരണ ഘട്ടങ്ങൾ പ്രവർത്തിപ്പിച്ച് നിങ്ങളുടെ സ്വന്തം അറിവോടെ ഡിസൈൻ "whys" പൂരിപ്പിക്കുക. എത്ര ഘട്ടങ്ങൾ പരിഹരിക്കണമെന്നും എത്ര "എന്തുകൊണ്ട്" നിങ്ങൾ ചേർത്തിട്ടുണ്ടെന്നും ശ്രദ്ധിക്കുക.

ചെക്ക്ലിസ്റ്റ്

• [ ] ഡോക്യുമെൻ്റേഷനിൽ, "എന്ത്/എങ്ങനെ", "എന്തുകൊണ്ട്" എന്നീ ലെയറുകളെ ഞാൻ വേർതിരിക്കുന്നു.
• [ ] "എന്തുകൊണ്ട്" എന്ന് ഞാൻ AI നിർമ്മിക്കുന്നില്ല, ഞാൻ അത് സ്വയം ചേർക്കുന്നു.
• [ ] ഞാൻ പ്രോംപ്റ്റിന് ടാർഗെറ്റ് പ്രേക്ഷകരെയും യഥാർത്ഥ ഉറവിട ഫയലുകളും നൽകുന്നു.
• [ ] AI അടയാളപ്പെടുത്തിയ [VERIFY] പോയിൻ്റുകൾ വ്യക്തിപരമായി എക്‌സിക്യൂട്ട് ചെയ്‌ത് ഞാൻ പരിശോധിക്കുന്നു.
• [ ] കോഡ് ആവർത്തിക്കുന്ന അനാവശ്യ കമൻ്റുകൾ ഞാൻ ഒഴിവാക്കുന്നു.
• [ ] ഞാൻ ഡോക്യുമെൻ്റേഷൻ അപ്ഡേറ്റ് കോഡ് മാറ്റത്തിൻ്റെ ഭാഗമാക്കുകയാണ്.