സോഫ്റ്റ്വെയർ നിർമ്മാണം ഒരു പൊതുവേദിയിലെ പ്രകടനം പോലെ തോന്നാം. ലോഞ്ചുകൾക്കും സ്ക്രീൻഷോട്ടുകൾക്കും ചേഞ്ച്ലോഗ് പോയിന്റുകൾക്കും ഇന്റർനെറ്റ് വലിയ പ്രാധാന്യം നൽകുന്നു. അതിനാൽ ഒരു ഡെവലപ്പർ ഒരു ദിവസം മുഴുവൻ ഒരു പ്രോജക്റ്റിനായി ചിലവഴിച്ചിട്ടും പുറമെ കാണിക്കാൻ ഒന്നുമില്ലെങ്കിൽ, ആ ദിവസം പാഴായെന്ന് കരുതുന്ന പ്രവണതയുണ്ട്. Food Blog Platform-ന്റെ ഏറ്റവും പുതിയ ഡെവ് ലോഗ് ഇതിന് വിപരീതമാണ് തെളിയിക്കുന്നത്. പ്രദർശിപ്പിക്കാൻ പുതിയ റെസിപ്പികളോ, പുനർരൂപകൽപ്പന ചെയ്ത കാർഡുകളോ, ഉപയോക്താക്കൾക്ക് ക്ലിക്ക് ചെയ്യാൻ പുതിയ ബട്ടണുകളോ ഉണ്ടായിരുന്നില്ല. പകരം, നിലവിലുള്ള കോഡ് പരിശോധിക്കുകയും കൂടുതൽ മെച്ചപ്പെട്ട രീതിയിൽ വീണ്ടും ക്രമീകരിക്കുകയും മാത്രമാണ് ചെയ്തത്.
ദീർഘകാല പ്രോജക്റ്റുകളെ നിലനിർത്തുന്ന ഈ അദൃശ്യമായ ജോലിയാണ് ഇതിന്റെ അടിസ്ഥാനം.
ഫീച്ചറുകൾ പ്രശസ്തി നേടുന്നു; റീഫാക്റ്ററിംഗ് (Refactoring) പ്രോജക്റ്റിനെ മുന്നോട്ട് നയിക്കുന്നു
ഒരു ഫുഡ് ബ്ലോഗ് പ്ലാറ്റ്ഫോം പരിപാലിക്കുമ്പോൾ, അതിന്റെ ഉപരിതലം ലളിതമായി തോന്നും. ഉപയോക്താക്കൾ റെസിപ്പികൾ പോസ്റ്റ് ചെയ്യുന്നു, ഫോട്ടോകൾ അപ്ലോഡ് ചെയ്യുന്നു, കാറ്റഗറി അനുസരിച്ച് തിരയുന്നു. എന്നാൽ ഇതിന് പിന്നിൽ ഇമേജ് പൈപ്പ്ലൈനുകൾ (image pipelines), ചേരുവകളും നിർദ്ദേശങ്ങളും തമ്മിലുള്ള ഡാറ്റാബേസ് ബന്ധങ്ങൾ, സെർച്ച് ഇൻഡക്സുകൾ, കാഷിംഗ് ലെയറുകൾ (caching layers) എന്നിവ കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്. കാലക്രമേണ, പെട്ടെന്നുള്ള പരിഹാരങ്ങൾ (quick fixes) കുമിഞ്ഞുകൂടുന്നു. മൂന്ന് വ്യത്യസ്ത ഫയലുകളിൽ കോപ്പി ചെയ്ത ഒരു ഹെൽപ്പർ ഫംഗ്ഷൻ, പത്ത് പോസ്റ്റുകൾക്ക് മാത്രം അനുയോജ്യമായിരുന്ന എന്നാൽ ആയിരം പോസ്റ്റുകൾ എത്തുമ്പോൾ വേഗത കുറയുന്ന ഒരു ഡാറ്റാബേസ് ക്വറി, അഞ്ചു തവണയുള്ള അടിയന്തര മാറ്റങ്ങൾ കാരണം കുഴപ്പത്തിലായ CSS എന്നിവ ഇതിന് ഉദാഹരണങ്ങളാണ്.
റീഫാക്റ്ററിംഗ് എന്നാൽ ഈ കുഴപ്പങ്ങളെ നേരിട്ട് അഭിമുഖീകരിക്കുക എന്നാണ് അർത്ഥം. ഒരു റെസിപ്പി എഡിറ്റിംഗ് ഫോമും അഡ്മിൻ ഡാഷ്ബോർഡും ഒരേ വാലിഡേഷൻ ലെയറിൽ (validation layer) നിന്ന് വിവരങ്ങൾ എടുക്കുന്ന രീതിയിൽ ഡ്യൂപ്ലിക്കേറ്റ് ലോജിക് ഏകീകരിക്കുക എന്നതാകാം ഇതിന്റെ അർത്ഥം. അല്ലെങ്കിൽ, ഓരോ തവണ പേജ് റീലോഡ് ചെയ്യുമ്പോഴും കോംപ്രഷൻ റൂട്ടീൻ പ്രവർത്തിക്കുന്നതിന് പകരം, ഇമേജ് പ്രോസസ്സിംഗ് ലളിതമാക്കുക എന്നതാകാം. അല്ലെങ്കിൽ, പിന്നീട് പുതിയ കണ്ടന്റ് ടൈപ്പുകൾ ചേർക്കുമ്പോൾ ആറ് വ്യത്യസ്ത ഡയറക്ടറികളിലൂടെ തിരയേണ്ടി വരാത്ത രീതിയിൽ കോഡ്ബേസ് പുനഃക്രമീകരിക്കുക എന്നതാകാം.
ഇതൊന്നും യൂസർ ഇന്റർഫേസിൽ (user interface) കാണാൻ കഴിയില്ല. സൈറ്റിൽ വരുന്ന ഒരാൾക്ക് "query optimized" എന്നോ "component decoupled" എന്നോ ഉള്ള ബാനറുകൾ കാണാൻ കഴിയില്ല. എന്നാൽ സൈറ്റ് വേഗത്തിൽ ലോഡ് ചെയ്യപ്പെടുമ്പോൾ അവർ അത് അനുഭവിക്കും. ഒരു പുതിയ ഫീച്ചർ ആവശ്യപ്പെട്ടതിന് ശേഷം മൂന്നാഴ്ചയ്ക്ക് പകരം മൂന്ന് ദിവസത്തിനുള്ളിൽ ലഭ്യമാകുമ്പോൾ അവർ അത് ശ്രദ്ധിക്കും. ഡെവലപ്പർ ഇന്ന് പുതിയ കഴിവുകൾ (capabilities) ഒന്നും ചേർത്തില്ല. പകരം, കോഡ്ബേസുമായി പോരാടാതെ പുതിയ ഫീച്ചറുകൾ ചേർക്കാൻ പാത ഒരുക്കുകയാണ് ചെയ്തത്.
ക്ലീൻ കോഡ് (Clean Code) ഭാവിയിലെ പരാജയങ്ങൾക്കെതിരെയുള്ള ഒരു നിക്ഷേപമാണ്
ഒരു മാസത്തിൽ കൂടുതൽ നീണ്ടുനിൽക്കുന്ന എല്ലാ പ്രോജക്റ്റുകളിലും തടസ്സങ്ങൾ (friction) ഉണ്ടാകുന്നു. ഒരു ഐഡിയ പരിശോധിക്കാൻ നിങ്ങൾ ഒരു പ്രോട്ടോടൈപ്പ് നിർമ്മിക്കുന്നു. പിന്നീട് ഉപയോക്താക്കൾ വരുന്നു. തുടർന്ന് നിങ്ങൾക്ക് ഒരു ഓതന്റിക്കേഷൻ ലെയറും (authentication layer), മോഡറേഷൻ ക്യൂവും (moderation queue), മൊബൈൽ ലേഔട്ടും ആവശ്യമായി വരുന്നു. ഇവ ഓരോന്നും നിലവിലുള്ള ഘടനയിലേക്ക് കൂട്ടിച്ചേർക്കപ്പെടുന്നു. കൃത്യമായ പരിപാലനം ഇല്ലെങ്കിൽ, ഓരോ പുതിയ മുറിയും പ്ലാൻ കാണാത്ത വ്യത്യസ്ത വ്യക്തികൾ രൂപകൽപ്പന ചെയ്ത ഒരു വീട് പോലെ ആ ആർക്കിടെക്ചർ മാറും.
ടെക്നിക്കൽ ഡെബ്റ്റ് (Technical debt) എന്നത് അച്ചടക്കമില്ലായ്മയുടെ ഫലമല്ല. മറിച്ച്, ഒരു പ്രോജക്റ്റ് വേഗത്തിൽ പുറത്തിറക്കാൻ വേണ്ടി എടുക്കുന്ന വിട്ടുവീഴ്ചകളുടെ സ്വാഭാവികമായ ഫലമാണ്. നിങ്ങളുടെ കോഡ് അപൂർണ്ണമാണ് എന്നതല്ല അപകടം. മറിച്ച്, ഒരു വേരിയബിൾ മാറ്റിയാൽ മറ്റ് മൂന്ന് ഫീച്ചറുകൾ തകരുന്ന രീതിയിൽ കോഡ് ഏറെക്കാലം മാറ്റമില്ലാതെ വിടുക എന്നതാണ് അപകടം. സെർച്ച് ബാറിൽ തൊടാൻ പോലും നിങ്ങൾ ഭയപ്പെട്ടേക്കാം, കാരണം കഴിഞ്ഞ തവണ അത് പരീക്ഷിച്ചപ്പോൾ ടാഗ് സിസ്റ്റം തകരാറിലായിട്ടുണ്ടാകാം. ഡാറ്റാബേസ് സ്കീമ (database schema) പരിഹരിക്കാൻ മണിക്കൂറുകൾ എടുക്കുമെന്ന് അറിയാവുന്നത് കൊണ്ട് നിങ്ങൾ ഒരു മീൽ-പ്ലാനർ വിഡ്ജറ്റ് ചേർക്കുന്നത് മാറ്റിവെച്ചേക്കാം.
ഒരു ദിവസം റീഫാക്റ്ററിംഗിനായി ചിലവഴിക്കുന്നത്, പലിശ ഭാരമാകുന്നതിന് മുമ്പ് ആ കടം വീട്ടുന്നതുപോലെയാണ്. ചെറിയ പ്രശ്നങ്ങൾ വലിയവയായി മാറുന്നത് ഇത് തടയുന്നു. Food Blog Platform അതിന്റെ അടുത്ത പ്രധാന ഫീച്ചർ ചേർക്കുമ്പോൾ, ഡെവലപ്പർക്ക് തകരാറിലാകാൻ സാധ്യതയുള്ള കോഡുകൾക്കിടയിലൂടെ വളഞ്ഞുപുളഞ്ഞു പോകേണ്ടി വരില്ല. അവർ പുതിയ ലോജിക് എഴുതും, അത് ഒരു ക്ലീൻ ഇന്റർഫേസിലേക്ക് ചേർക്കും, തുടർന്ന് മുന്നോട്ട് പോകും. ഇതാണ് ഇതിന്റെ ആദായം (return on investment).
ചെറിയ ചുവടുകൾ, യഥാർത്ഥ പഠനം
സോഫ്റ്റ്വെയർ ഡെവലപ്മെന്റിനെക്കുറിച്ച് ഒരു മിഥ്യയുണ്ട്; പുരോഗതി എന്നത് പെട്ടെന്നുണ്ടാകുന്ന വലിയ കണ്ടുപിടുത്തങ്ങളോ അല്ലെങ്കിൽ രാത്രിയൊഴുക്കിന് എല്ലാം മാറ്റിയെഴുതുന്ന കോഡിംഗ് സെഷനുകളോ ആണെന്ന് അത് പറയുന്നു. എന്നാൽ യഥാർത്ഥ ഡെവലപ്പർമാർ പറയും അത് വെറും സങ്കല്പം മാത്രമാണെന്ന്. യഥാർത്ഥ പുരോഗതി എന്നത് ഒരു ചൊവ്വാഴ്ച ഉച്ചയ്ക്ക് മൂന്ന് ഫംഗ്ഷനുകൾ ചെറുതാക്കിയതും, ആവശ്യമില്ലാത്ത ഒരു ഡിപെൻഡൻസി (dependency) നീക്കം ചെയ്തതും, അടുത്ത വായനക്കാരന് എളുപ്പത്തിൽ മനസ്സിലാകുന്ന രീതിയിൽ ഒരു വേരിയബിൾ പേര് മാറ്റിയതുമായ ചെറിയ മാറ്റങ്ങളാണ്.
Food Blog Platform-ന്റെ ഡെവ് ലോഗ് ഈ താളം കൃത്യമായി പകർത്തുന്നു. സോഫ്റ്റ്വെയർ നിർമ്മാണം എന്നത് ചെറിയതും സ്ഥിരവുമായ മെച്ചപ്പെടുത്തലുകളെക്കുറിച്ചാണ്. ഓരോ വെല്ലുവിളികളിൽ നിന്നും നിങ്ങൾ പഠിക്കുന്നു. ഒരു പ്രത്യേക മോഡ്യൂൾ മറ്റൊരു മോഡ്യൂളിനെ അമിതമായി ആശ്രയിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് മനസ്സിലാക്കുക എന്നതാകാം ഇന്നത്തെ വെല്ലുവിളി. അല്ലെങ്കിൽ രണ്ടാഴ്ച മുമ്പ് എടുത്ത ഒരു ഷോർട്ട്കട്ട് ലാഭിക്കുന്നതിനേക്കാൾ കൂടുതൽ സമയം ഇപ്പോൾ നഷ്ടപ്പെടുത്തുന്നു എന്ന് തിരിച്ചറിയുക എന്നതാകാം. ഓരോ കമ്മിറ്റും (commit) പ്രോജക്റ്റിനെ മെച്ചപ്പെടുത്തുന്നു, അത് പുതിയവ സൃഷ്ടിക്കുന്നതിനേക്കാൾ കൂടുതൽ പഴയവ നീക്കം ചെയ്യുമ്പോൾ പോലും.
ഈ സമീപനം നിങ്ങളുടെ പ്രചോദനത്തെയും സംരക്ഷിക്കുന്നു. വലിയ തോതിലുള്ള റീറൈറ്റുകൾ (rewrites) തളർത്തുന്നതും അപകടസാധ്യതയുള്ളതുമാണ്. പഴയ പ്രശ്നങ്ങൾ പരിഹരിക്കുമ്പോൾ അവ പുതിയ ബഗുകൾ (bugs) ഉണ്ടാക്കാൻ കാരണമാകും. ക്രമാനുഗതമായ റീഫാക്റ്ററിംഗ് (Incremental refactoring) ചെയ്യുക.