Legacy Code കാലപ്പഴക്കത്തിനനുസരിച്ച് കൂടുതൽ മോശമാകുന്നു

Legacy code കാലപ്പഴക്കത്തിനനുസരിച്ച് മെച്ചപ്പെടുകയല്ല ചെയ്യുന്നത്. അത് കൂടുതൽ മോശമായിക്കൊണ്ടിരിക്കും.

കഴിഞ്ഞ ആഴ്ച, ഒരു ബഗ് (bug) പരിഹരിക്കാൻ ഞാൻ മൂന്ന് മണിക്കൂർ ചിലവഴിച്ചു. അത് വെറും 20 മിനിറ്റ് കൊണ്ട് തീരേണ്ടതായിരുന്നു. 2019-ലെ ഒരു വാലിഡേഷൻ മോഡ്യൂളിലായിരുന്നു (validation module) പ്രശ്നം. "അത് പ്രവർത്തിക്കുന്നുണ്ട്" എന്നതുകൊണ്ട് എല്ലാവരും അത് അവഗണിച്ചു. എന്നാൽ അത് പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നില്ല. ആ ഫയലിനുള്ളിൽ 2020-ലെ ഒരു TODO കമന്റ് ഞാൻ കണ്ടെത്തി.

പലരും legacy code-നെ ഒരു ഓപ്ഷണൽ കടം പോലെയാണ് കാണുന്നത്. സമയം കിട്ടുമ്പോൾ അത് വീട്ടാം എന്ന് അവർ കരുതുന്നു. എന്നാൽ legacy code ഒരു പൂപ്പൽ പോലെയാണ്. അത് പടർന്നുപിടിക്കും. നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ മറ്റ് ഭാഗങ്ങളെയും അത് മലിനമാക്കും. നിങ്ങൾ എത്രത്തോളം അത് അവഗണിക്കുന്നുവോ, അത്രത്തോളം അത് വൃത്തിയാക്കാൻ കൂടുതൽ ചിലവ് വരും.

ഇത് ഒരു മോശം ചക്രം സൃഷ്ടിക്കുന്നു:

• നിങ്ങൾ കുഴപ്പപ്പെട്ട ഒരു പ്രോജക്റ്റ് ഏറ്റെടുക്കുന്നു.
• നിങ്ങളുടെ ഫീച്ചർ പ്രവർത്തിപ്പിക്കാൻ നിങ്ങൾ ഒരു if സ്റ്റേറ്റ്‌മെന്റ് കൂടി ചേർക്കുന്നു.
• ആറ് മാസത്തിന് ശേഷം മറ്റൊരാൾ ഇതേ കാര്യം ചെയ്യുന്നു.
• ഒരു വർഷത്തിന് ശേഷം, ആ ഫയലിൽ 800 വരികളുണ്ട്, എന്നാൽ ഒരു ടെസ്റ്റും ഇല്ല.

ഈ "പ്രവർത്തിക്കുന്ന" കോഡിന് മറഞ്ഞിരിക്കുന്ന ചിലവുകളുണ്ട്:

• വികസന വേഗത കുറയുന്നു. കോഡ് എഴുതുന്നതിനേക്കാൾ കൂടുതൽ സമയം കോഡിന്റെ പശ്ചാത്തലം (context) മനസ്സിലാക്കാൻ നിങ്ങൾ ചിലവഴിക്കുന്നു.
• ബഗുകൾ വർദ്ധിക്കുന്നു. ഒരു കാര്യം ശരിയാക്കാൻ ശ്രമിക്കുമ്പോൾ മറ്റൊന്ന് തകരാറിലാകുന്നു.
• Onboarding പ്രയാസകരമാകുന്നു. എല്ലാടത്തും ലോജിക് ആവർത്തിച്ചു വരുന്നത് എന്തുകൊണ്ടാണെന്ന് മനസ്സിലാക്കാൻ പുതിയ ഡെവലപ്പർമാർ ബുദ്ധിമുട്ടുന്നു.

ഈ അപകടസൂചനകൾ ശ്രദ്ധിക്കുക:

• ഉപയോഗശൂന്യമായതോ തെറ്റായതോ ആയ കമന്റുകൾ.
• വ്യത്യസ്ത ഫയലുകളിൽ ആവർത്തിച്ചു വരുന്ന business logic.
• Circular dependencies-ഉം ഉയർന്ന coupling-ഉം.

എല്ലാം വീണ്ടും എഴുതാൻ (rewrite) ശ്രമിക്കരുത്. പൂർണ്ണമായ റീറൈറ്റുകൾ 80% സമയത്തും പരാജയപ്പെടുന്നു. ബിസിനസ് പുതിയ ഫീച്ചറുകൾക്കായി കാത്തിരിക്കുമ്പോൾ, നിലവിലുള്ളവ വീണ്ടും നിർമ്മിക്കാൻ നിങ്ങൾ മാസങ്ങൾ ചിലവഴിക്കുന്നു.

Characterization tests ഉപയോഗിച്ച് incremental refactoring നടത്തുക:

• നിലവിലെ പെരുമാറ്റം (behavior) എങ്ങനെയാണോ, അത് ടെസ്റ്റുകളിലൂടെ രേഖപ്പെടുത്തുക, അത് വിചിത്രമാണെങ്കിൽ പോലും.
• ആ പെരുമാറ്റം മാറ്റാതെ തന്നെ refactor ചെയ്യുക.
• കോഡ് വായിക്കാൻ എളുപ്പമാകുന്നതുവരെ ഇത് ആവർത്തിക്കുക.
• അതിനുശേഷം മാത്രം യഥാർത്ഥ ടെസ്റ്റുകൾ ഉപയോഗിച്ച് പെരുമാറ്റത്തിൽ മാറ്റം വരുത്തുക.

കെണികളിൽ വീഴാതിരിക്കാൻ ഈ നിയമങ്ങൾ പാലിക്കുക:

• ടെസ്റ്റുകൾ ഇല്ലാതെ ഒരിക്കലും refactor ചെയ്യരുത്.
• Refactor ചെയ്യുമ്പോൾ പെരുമാറ്റത്തിൽ മാറ്റം വരുത്തരുത്. ഒരു ബഗ് ഒരുപക്ഷേ ക്ലയന്റ് ആശ്രയിക്കുന്ന, രേഖപ്പെടുത്താത്ത ഒരു ഫീച്ചർ ആയിരിക്കാം.
• മാറ്റങ്ങളില്ലാത്ത കോഡിനെ തൊടാതെ വിടുക. ഒരു മോഡ്യൂൾ മൂന്ന് വർഷമായി മാറ്റമില്ലാതെ തുടരുകയും പ്രശ്നങ്ങളൊന്നും ഉണ്ടാക്കാതിരിക്കുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, അതിൽ ഇടപെടരുത്.

നിങ്ങൾ ഇടയ്ക്കിടെ ഉപയോഗിക്കുന്ന കോഡിൽ മാത്രം നിങ്ങളുടെ ഊർജ്ജം കേന്ദ്രീകരിക്കുക.

Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h