𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗧𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀

നിങ്ങൾ എടുക്കുന്ന ഓരോ ഡിസൈൻ തീരുമാനവും മറ്റൊരു ഓപ്ഷനുള്ള വാതിൽ അടയ്ക്കുന്നു. സോഫ്റ്റ്‌വെയർ പ്രവർത്തിക്കുന്നത് ട്രേഡ്ഓഫുകളിലൂടെയാണ് (trade-offs). നിങ്ങൾ ബോധപൂർവ്വം ഈ തീരുമാനങ്ങൾ എടുക്കണം. ഇല്ലെങ്കിൽ, അബദ്ധവശാൽ നിങ്ങൾ അവ എടുക്കേണ്ടി വരും.

നിങ്ങൾ നേരിടുന്ന സാധാരണ ട്രേഡ്ഓഫുകൾ:

• ഫങ്ഷണാലിറ്റിയും പെർഫോമൻസും (Functionality vs Performance) ക്ലീൻ കോഡ് പലപ്പോഴും സാവധാനമേ പ്രവർത്തിക്കൂ. വേഗതയേറിയ കോഡ് പലപ്പോഴും വായിക്കാൻ പ്രയാസമായിരിക്കും. ദിവസം ഒരിക്കൽ മാത്രം നടത്തുന്ന ബാച്ച് പ്രോസസുകൾക്കായി (batch processes) വായിക്കാൻ എളുപ്പമുള്ള കോഡ് ഉപയോഗിക്കുക. ഓരോ റിക്വസ്റ്റിലും ആയിരക്കണക്കിന് തവണ പ്രവർത്തിക്കുന്ന പാത്തുകൾക്കായി ഒപ്റ്റിമൈസ് ചെയ്ത കോഡ് ഉപയോഗിക്കുക.

• ഫ്ലെക്സിബിലിറ്റിയും സിംപ്ലിസിറ്റിയും (Flexibility vs Simplicity) സങ്കീർണ്ണമായ അബ്സ്ട്രാക്ഷനുകൾ (abstractions) കോഡ് മനസ്സിലാക്കാൻ പ്രയാസമാക്കുന്നു. പ്രവർത്തിക്കുന്ന ഏറ്റവും ലളിതമായ കോഡ് എഴുതുക. പിന്നീട് വികസിപ്പിക്കാൻ കഴിയുന്ന രീതിയിൽ അത് നിർമ്മിക്കുക.

• സ്കെയിലബിലിറ്റിയും ചിലവും (Scalability vs Cost) വൻതോതിലുള്ള ട്രാഫിക്കിനായി ഡിസൈൻ ചെയ്യുന്നത് ഇപ്പോൾ കൂടുതൽ പണം ചിലവാക്കുന്നു. നിങ്ങളുടെ വളർച്ചാ നിരക്ക് അളക്കുന്നത് തീരുമാനമെടുക്കാൻ സഹായിക്കും. ഓരോ മാസവും നിങ്ങൾ 20% വളരുന്നുണ്ടെങ്കിൽ, ഭാവിയിലേക്ക് പ്ലാൻ ചെയ്യുക. മൂലധനം കുറവാണെങ്കിൽ, ചിലവുകൾ ശ്രദ്ധിക്കുക.

• സുരക്ഷയും ഉപയോഗക്ഷമതയും (Security vs Usability) അമിതമായ സുരക്ഷ ഉപയോക്താവിന്റെ അനുഭവം (user experience) തകർക്കാൻ ഇടയാക്കും. ഒരു അഡ്മിൻ ടൂളിനായി ഞങ്ങൾ ഒരിക്കൽ ഹാർഡ്‌വെയർ ടോക്കണുകൾ നിർബന്ധമാക്കിയിരുന്നു. ലോഗിൻ വിജയശതമാനം 98%-ൽ നിന്ന് 84%-ലേക്ക് കുറഞ്ഞു. അടിയന്തര സാഹചര്യങ്ങളിൽ എഞ്ചിനീയർമാർക്ക് ലോഗിൻ ചെയ്യാൻ കഴിയാതെയായി. ഞങ്ങൾ മൊബൈൽ പുഷ് നോട്ടിഫിക്കേഷനുകളിലേക്ക് മാറി. വിജയശതമാനം വീണ്ടും 96%-ലേക്ക് ഉയർന്നു. പരമാവധി സുരക്ഷയ്ക്ക് പകരം യുക്തിസഹമായ സുരക്ഷ ലക്ഷ്യമിടുക.

മികച്ച തീരുമാനങ്ങൾ എങ്ങനെ എടുക്കാം:

  • നിങ്ങളുടെ ലക്ഷ്യത്തെക്കുറിച്ച് വ്യക്തത പുലർത്തുക.
  • ഊഹിക്കുന്നതിന് പകരം ഡാറ്റ അളക്കുക.
  • ലളിതമായ ഒരു പരിഹാരത്തിലൂടെ തുടങ്ങുക.
  • തെളിവുണ്ടെങ്കിൽ മാത്രം ഒപ്റ്റിമൈസ് ചെയ്യുക.
  • എന്തുകൊണ്ടാണ് ആ തീരുമാനം എടുത്തതെന്ന് രേഖപ്പെടുത്തുക (Document).

മൈക്രോസെക്കൻഡുകൾ ലാഭിക്കാനായി ഒരു JSON സീരിയലൈസർ (JSON serializer) ഒപ്റ്റിമൈസ് ചെയ്യാൻ ഞാൻ ഒരിക്കൽ ശ്രമിച്ചു. അത് 300 MB വരെ വർദ്ധിച്ച ഒരു മെമ്മറി ലീക്കിന് (memory leak) കാരണമായി. നെറ്റ്‌വർക്ക് I/O ആണ് യഥാർത്ഥ തടസ്സം (bottleneck) എന്ന് ഒരു പ്രൊഫൈലർ (profiler) കാണിച്ചുതന്നു. കോഡ് വീണ്ടും എഴുതുന്നതിന് മുമ്പ് എപ്പോഴും ഒരു പ്രൊഫൈലർ ഉപയോഗിക്കുക.

ടെക്നിക്കൽ ഡെബ്റ്റ് (Technical debt) എന്നത് യാഥാർത്ഥ്യമാണ്. ഇന്ന് എടുക്കുന്ന ഒരു ഷോർട്ട്കട്ട് നാളെ സമയം നഷ്ടപ്പെടുത്തും. കുഴപ്പപ്പെട്ട ഒരു സർവീസ് ഞങ്ങളുടെ കൈവശം വന്നപ്പോൾ, ഞങ്ങൾ വലിയൊരു റീറൈറ്റ് (rewrite) നടത്തിയില്ല. പകരം ചെറിയതും നിരന്തരവുമായ മാറ്റങ്ങളാണ് ഞങ്ങൾ വരുത്തിയത്. ഞങ്ങൾ ടെസ്റ്റ് കവറേജ് (test coverage) 30%-ൽ നിന്ന് 78%-ലേക്ക് ഉയർത്തി. ഇത് ബഗ് ഫിക്സ് ചെയ്യാനുള്ള സമയം 4 ദിവസത്തിൽ നിന്ന് 1.2 ദിവസമായി കുറച്ചു.

ട്രേഡ്ഓഫുകൾ ശാശ്വതമല്ല. നിങ്ങളുടെ തീരുമാനങ്ങൾ വീണ്ടും പരിശോധിക്കുക. നിങ്ങളുടെ ഒപ്റ്റിമൈസേഷനുകൾ ഇപ്പോഴും പ്രസക്തമാണോ എന്ന് പരിശോധിക്കുക. ബോധപൂർവ്വമായ തീരുമാനങ്ങൾ എടുക്കുന്നത് എല്ലാ കാര്യങ്ങളിലും ഇടത്തരമായ ഒരു സിസ്റ്റം ഉണ്ടാകുന്നത് ഒഴിവാക്കാൻ സഹായിക്കും.

Source: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Optional learning community: https://t.me/GyaanSetuAi