നിങ്ങളുടെ PR-കൾ വലുതാകാനുള്ള യഥാർത്ഥ കാരണം
ശീലത്തിന്റെ ഭാഗമായി വലിയ pull requests അയച്ചിരുന്ന ഒരു കമ്പനിയിൽ ഞാൻ ഒരിക്കൽ ജോലി ചെയ്തിരുന്നു. ഒരു PR ആഴ്ചകളോളം തുറന്നു കിടന്നേക്കാം. അത് റിവ്യൂ ചെയ്യാൻ ഒരു സബ്സിസ്റ്റം മുഴുവൻ മനസ്സിൽ ഉൾക്കൊള്ളേണ്ടി വരും. ബഗുകൾ (Bugs) കുന്നുകൂടി. ഡെഡ്ലൈനുകൾ തെറ്റിപ്പോയി. ഒടുവിൽ സിസ്റ്റത്തിന്റെ വലിയൊരു ഭാഗം ഞങ്ങൾക്ക് വീണ്ടും നിർമ്മിക്കേണ്ടി വന്നു, കാരണം ആർക്കും അത് സുരക്ഷിതമായി മാറ്റാൻ കഴിയില്ലായിരുന്നു.
എഞ്ചിനീയർമാർ മോശക്കാരായിരുന്നില്ല. അവർ ബുദ്ധിയുള്ളവരും കഠിനാധ്വാനം ചെയ്യുന്നവരും ആയിരുന്നു. എന്നാൽ വളരെ വിരസമായ ഒരു കാരണത്താലാണ് PR-കൾ വലുതായത്.
ജോലിയെ എങ്ങനെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കാമെന്ന് ആരും അവർക്ക് പഠിപ്പിച്ചു കൊടുത്തിരുന്നില്ല.
വലിയ PR-കളെ നമ്മൾ പലപ്പോഴും അച്ചടക്കത്തിന്റെ പ്രശ്നമായാണ് കാണുന്നത്. "ചെറിയ PR-കൾ ഉണ്ടാക്കിയാൽ മതി" എന്ന് നമ്മൾ പറയും. 1,500 മാറ്റങ്ങളും 150 മാറ്റങ്ങളും തമ്മിലുള്ള ഏക വ്യത്യാസം ഇച്ഛാശക്തി (willpower) മാത്രമാണെന്ന രീതിയിലാണ് നമ്മൾ പെരുമാറുന്നത്.
ഇത് ഇച്ഛാശക്തിയുടെ പ്രശ്നമല്ല. വലിയ ജോലികളെ ചെറിയ, സ്വതന്ത്രമായ ഭാഗങ്ങളായി തിരിക്കുന്നത് ഒരു നൈപുണ്യമാണ് (skill). മിക്ക ആളുകളും ഇത് പഠിച്ചിട്ടില്ല. ഒരു ടിക്കറ്റിൽ "add billing" എന്ന് പറയുമ്പോൾ, അത് ഒറ്റ ജോലിയായി തോന്നും. ഒരു PR എവിടെ അവസാനിക്കുന്നുവെന്നും അടുത്തത് എവിടെ തുടങ്ങുന്നുവെന്നും തിരിച്ചറിയുന്നതാണ് പ്രയാസകരമായ ഭാഗം.
ഞാനും വലിയ PR-കൾ അയക്കാറുണ്ടായിരുന്നു. "പണി കഴിഞ്ഞു" (done) എന്നാൽ പ്രശ്നം മുഴുവൻ ഒന്നിച്ച് പരിഹരിച്ച് റിവ്യൂവിനായി അയക്കുക എന്നാണ് ഞാൻ കരുതിയിരുന്നത്. ചെറിയവയാണ് നല്ലത് എന്ന് പഠിച്ചെടുക്കാൻ വർഷങ്ങൾ എടുത്തു.
ചെറിയ PR-കൾ എന്റെ രീതികളെല്ലാം മാറ്റിമറിച്ചു:
- റിവ്യൂവർമാർക്ക് കൂടുതൽ ബഗുകൾ കണ്ടെത്താൻ കഴിയുന്നു. ഒരു മനുഷ്യന് ഏകദേശം 200 മാറ്റങ്ങളെക്കുറിച്ച് വിശകലനം ചെയ്യാൻ കഴിയും. എന്നാൽ 2,000 മാറ്റങ്ങൾ വിശകലനം ചെയ്യാൻ അവർക്ക് കഴിയില്ല. അവർ വെറുതെ ഒന്ന് കണ്ണോടിച്ചു പാസാക്കി കളയും.
- മെർജുകൾ (Merges) വേഗത്തിലാകുന്നു. PR-കൾ ക്യൂവിൽ കുടുങ്ങിക്കിടക്കുന്നത് ഒഴിവാകുന്നു.
- എനിക്ക് അമിതമായ സമ്മർദ്ദം അനുഭവപ്പെടുന്നത് നിന്നു. ഓരോ ഘട്ടത്തിലും ഒരു കാര്യത്തിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ എനിക്ക് കഴിഞ്ഞു.
- ഞാൻ മികച്ചൊരു പ്ലാനർ ആയി മാറി. ജോലിയെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കണമെങ്കിൽ അതിന്റെ ഘടന മനസ്സിലാക്കേണ്ടതുണ്ട്.
സിസ്റ്റങ്ങളെ ഞാൻ ലെഗോ (Lego) കട്ടകളായി കാണാൻ തുടങ്ങി. അവ പരസ്പരം ഘടിപ്പിക്കാവുന്ന ചെറിയ കഷണങ്ങളാണ്. ഒരിക്കൽ നിങ്ങൾ ആ കട്ടകളെ കാണാൻ തുടങ്ങിയാൽ, ജോലിയെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കുന്നത് സ്വാഭാവികമായി തോന്നും.
എന്റെ ഇപ്പോഴത്തെ ടീം ചെറിയ PR-കളാണ് അയക്കുന്നത്. അതിന്റെ ഫലങ്ങൾ വ്യക്തമാണ്:
- ഞങ്ങളുടെ ശരാശരി മെർജ് സമയം 1.5 ദിവസമാണ്.
- മാറ്റങ്ങൾ എളുപ്പത്തിൽ മനസ്സിലാക്കാൻ കഴിയുന്നതുകൊണ്ട് ബഗുകൾ വേഗത്തിൽ കണ്ടെത്താനും പരിഹരിക്കാനും ഞങ്ങൾക്ക് കഴിയുന്നു.
- ഞങ്ങളുടെ ഡെലിവറി സമയം കൃത്യമാണ്.
ജോലിയെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കുന്നത് പരിശീലിപ്പിക്കേണ്ട ഒരു നൈപുണ്യമാണ്. ഒരു നിയമം കൊണ്ട് മാത്രം വലിയ PR-കളെ പരിഹരിക്കാൻ കഴിയില്ല. ആ കട്ടകളെ (bricks) തിരിച്ചറിയാൻ ആളുകളെ പഠിപ്പിച്ചാലേ അത് സാധ്യമാകൂ.
AI ഈ നൈപുണ്യത്തെ കൂടുതൽ അനിവാര്യമാക്കുന്നു.
പണ്ട്, 2,000 വരി കോഡ് എഴുതാൻ വലിയ പരിശ്രമം ആവശ്യമായിരുന്നു. ആ പ്രയാസം PR-കൾ ചെറുതായി നിലനിർത്താൻ സഹായിച്ചിരുന്നു. എന്നാൽ AI ആ പ്രയാസം ഇല്ലാതാക്കി. ഒരു പ്രോംപ്റ്റിലൂടെ (prompt) നിങ്ങൾക്ക് വലിയ മാറ്റങ്ങൾ നിർമ്മിക്കാൻ കഴിയും.
ആ പരിശ്രമം ഇല്ലാതായില്ല. അത് റിവ്യൂവർലേക്ക് മാറി എന്ന് മാത്രം. കോഡ് എഴുതുന്ന ആൾക്ക് ഇതിൽ വലിയ നഷ്ടമില്ല, എന്നാൽ റിവ്യൂവർ അതിന്റെ മുഴുവൻ വിലയും നൽകേണ്ടി വരുന്നു.
ഒരു എഴുത്തുകാരൻ എത്രത്തോളം ജോലി ചെയ്തു എന്ന് വലുപ്പം (size) സൂചിപ്പിക്കുന്നില്ലെങ്കിൽ, റിസ്ക് എത്രത്തോളമുണ്ടെന്നും വലുപ്പം കൊണ്ട് നിങ്ങൾക്ക് അധികം മനസ്സിലാക്കാൻ കഴിയില്ല. ഏതെല്ലാം ഭാഗങ്ങൾക്കാണ് നിങ്ങളുടെ ഏറ്റവും ശ്രദ്ധാപൂർവ്വമായ പരിശോധന വേണ്ടതെന്ന് നിങ്ങൾ തീരുമാനിക്കണം.
ഓരോ ചെറിയ ഘടകങ്ങളെയും (bricks) കാണാൻ നിങ്ങളുടെ ടീമിനെ പഠിപ്പിക്കുക. എഞ്ചിനീയറിംഗിലെ ഏറ്റവും ഫലപ്രദമായ ശീലമാണിത്.
ഏതെല്ലാം PR-കൾക്ക് ആഴത്തിലുള്ള പരിശോധന (deep review) വേണമെന്നും ഏതെല്ലാം വേഗത്തിൽ പാസാക്കാമെന്നും നിങ്ങളുടെ ടീം എങ്ങനെയാണ് തീരുമാനിക്കുന്നത്?
സ്രോതസ്സ്: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi