എപ്പോൾ റീഫാക്ടർ (Refactor) ചെയ്യണം, എപ്പോൾ റീറൈറ്റ് (Rewrite) ചെയ്യണം എന്ന് ഞങ്ങൾ എങ്ങനെ തീരുമാനിക്കുന്നു
ഓരോ ഡെവലപ്പറും ഇങ്ങനെയൊരു ഘട്ടത്തിലൂടെ കടന്നുപോകാറുണ്ട്.
കോഡ്ബേസ് (codebase) സാവധാനത്തിലാണ് പ്രവർത്തിക്കുന്നത്. പുതിയ ഫീച്ചറുകൾ ചേർക്കാൻ ഒരുപാട് സമയമെടുക്കുന്നു. പുതിയതായി ജോലിക്കെത്തുന്നവർക്ക് സിസ്റ്റം മനസ്സിലാക്കാൻ ബുദ്ധിമുട്ടാണ്. ഒടുവിൽ ആരെങ്കിലും ഒരു പൂർണ്ണമായ റീറൈറ്റ് (rewrite) നിർദ്ദേശിക്കുന്നു.
ടീം സാധാരണയായി രണ്ട് ഗ്രൂപ്പുകളായി തിരിയും. ഒരു ഗ്രൂപ്പ് എല്ലാം പുതുതായി തുടങ്ങാൻ ആഗ്രഹിക്കുന്നു. മറ്റേ ഗ്രൂപ്പ് മുൻപ് നടന്ന റീറൈറ്റുകളുടെ പരാജയത്തെ ഭയപ്പെടുന്നു. രണ്ട് ഭാഗത്തിനും അവരുടേതായ ന്യായമായ കാരണങ്ങളുണ്ട്.
ഒരു റീറൈറ്റ് എന്നത് എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കുന്ന ഒരു മാന്ത്രിക വിദ്യയല്ല. ഇത് പലപ്പോഴും പ്ലാൻ ചെയ്തതിനേക്കാൾ കൂടുതൽ സമയമെടുക്കും. ഒരേസമയം രണ്ട് സിസ്റ്റങ്ങൾ പരിപാലിക്കേണ്ടി വരുന്ന അവസ്ഥയുണ്ടാകാം. പുതിയ വേർഷനിലും പഴയ തെറ്റുകൾ തന്നെ ആവർത്തിക്കാൻ പോലും സാധ്യതയുണ്ട്.
താഴെ പറയുന്ന പ്രത്യേക സാഹചര്യങ്ങളിൽ ഒരു റീറൈറ്റ് അർത്ഥവത്താണ്:
• ബിസിനസ്സിന് ആവശ്യമായ ഡാറ്റാ മോഡൽ (data model) അടിസ്ഥാനപരമായി തെറ്റാണ്. • ഉപയോഗിക്കുന്ന സാങ്കേതികവിദ്യ കാലഹരണപ്പെട്ടു, അതിന് സുരക്ഷാ അപ്ഡേറ്റുകൾ ലഭിക്കുന്നില്ല. • ബിസിനസ്സ് ആവശ്യങ്ങൾ വളരെയധികം മാറിയതിനാൽ പഴയ സിസ്റ്റം ഉപയോഗശൂന്യമായിരിക്കുന്നു. • നിലവിലെ ടീമിൽ ആർക്കും സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് അറിയില്ല.
അങ്ങനെയെങ്കിൽ പോലും, എല്ലാം ഒറ്റയടിക്ക് മാറ്റാൻ ശ്രമിക്കരുത്. ഒരു 'strangler fig pattern' ഉപയോഗിക്കുക. പഴയ സിസ്റ്റത്തോടൊപ്പം തന്നെ പുതിയ സിസ്റ്റം ഘട്ടം ഘട്ടമായി നിർമ്മിക്കുക.
മിക്കവാറും സമയങ്ങളിൽ, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ആവശ്യം റീഫാക്ടറിംഗ് (refactoring) ആണ്.
താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ റീഫാക്ടറിംഗ് ആണ് ശരിയായ തിരഞ്ഞെടുപ്പ്:
• വേഗത കുറവാണെങ്കിലും നിങ്ങൾക്ക് ഇപ്പോഴും ഫീച്ചറുകൾ ചേർക്കാൻ സാധിക്കുന്നുണ്ടെങ്കിൽ. • നിലവിലെ കോഡ് ടീമിന് കൃത്യമായി മനസ്സിലാകുന്നുണ്ടെങ്കിൽ. • പ്രശ്നങ്ങൾ ചില പ്രത്യേക മോഡ്യൂളുകളിൽ (modules) മാത്രമായി പരിമിതപ്പെട്ടിരിക്കുകയാണെങ്കിൽ. • പുതിയ ഫീച്ചറുകൾ പുറത്തിറക്കുന്നത് ബിസിനസ്സിന് നിർത്താൻ കഴിയില്ലെങ്കിൽ.
തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ്, കോഡ് എന്തുകൊണ്ടാണ് മോശമായതെന്ന് ചോദിക്കുക.
പ്രശ്നം ടെക്നിക്കൽ ഡെബ്റ്റ് (technical debt) ആണെങ്കിൽ, ഏറ്റവും മോശമായ ഭാഗങ്ങൾ റീഫാക്ടർ ചെയ്യുക. പ്രശ്നം കോഡ് റിവ്യൂകളുടെ കുറവോ അല്ലെങ്കിൽ മോശം പ്രവർത്തന സംസ്കാരമോ ആണെങ്കിൽ, ഒരു റീറൈറ്റ് കൊണ്ട് കാര്യമില്ല. പഴയ ശീലങ്ങളോടെ തന്നെ നിങ്ങൾ പുതിയൊരു കുഴപ്പവും ഉണ്ടാക്കുകയേയുള്ളൂ.
തീരുമാനമെടുക്കുന്നതിന് മുമ്പ് ഈ ചോദ്യങ്ങൾ ചോദിക്കുക:
• ഏറ്റവും മോശമായ ഭാഗങ്ങൾ ഒറ്റപ്പെട്ട രീതിയിൽ പരിഹരിക്കാൻ നമുക്ക് കഴിയുമോ? • നിലവിലെ ബിസിനസ്സ് ആവശ്യങ്ങൾക്ക് ഡാറ്റാ മോഡൽ അനുയോജ്യമല്ലേ? • എല്ലാം പുതുതായി തുടങ്ങുകയാണെങ്കിൽ നമുക്ക് നഷ്ടപ്പെടുന്ന അറിവുകൾ എന്തൊക്കെയാണ്? • ഒരു നീണ്ട മാറ്റം (transition) കൈകാര്യം ചെയ്യാൻ ബിസിനസ്സിന് ആവശ്യമായ സ്ഥിരതയുണ്ടോ?
എല്ലാം പുതുതായി തുടങ്ങുന്നത് നല്ലൊരു തോന്നലാണ്. എന്നാൽ റീറൈറ്റ് പൂർത്തിയാക്കുക എന്നതാണ് പ്രയാസകരമായ കാര്യം. മിക്കവാറും സമയങ്ങളിൽ, കൃത്യമായ ഒരു റീഫാക്ടറിംഗ് പ്ലാൻ പിന്തുടരുന്നതാണ് കൂടുതൽ സുരക്ഷിതവും ഫലപ്രദവും.
സ്രോതസ്സ്: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk