ഞാൻ എന്തുകൊണ്ട് കോഡ് എഴുതുന്നത് നിർത്തി ഡിസൈൻ ചെയ്യാൻ തുടങ്ങി
സോഫ്റ്റ്വെയർ ഡെവലപ്മെൻ്റ് എന്നാൽ ഫീച്ചറുകൾ എഴുതുക എന്നാണ് ഞാൻ കരുതിയിരുന്നത്. എൻ്റേറ്റികൾ (entities) നിർമ്മിക്കുക, കൺട്രോളറുകൾ (controllers) ഉണ്ടാക്കുക, ഡാറ്റാബേസുകൾ ബന്ധിപ്പിക്കുക എന്നിവയാണ് എൻ്റെ ജോലി എന്ന് ഞാൻ വിശ്വസിച്ചു.
ഒരു സമീപകാല പ്രോജക്റ്റ് എൻ്റെ കാഴ്ചപ്പാട് മാറ്റിമറിച്ചു. കോഡിംഗ് എന്നത് പരിഹാരത്തിൻ്റെ ഒരു ഭാഗം മാത്രമാണെന്ന് ഞാൻ മനസ്സിലാക്കി. ഒരു വരി കോഡ് പോലും എഴുതുന്നതിന് മുമ്പാണ് യഥാർത്ഥ ജോലി നടക്കുന്നത്.
നിങ്ങൾ ആർക്കിടെക്ചർ (architecture) തീരുമാനിക്കണം. അത് എന്തുകൊണ്ട് അനുയോജ്യമാകുന്നു, അതിൻ്റെ ചിലവ് എത്രയാണ്, അത് ഏതൊക്കെ റിസ്കുകൾ പരിഹരിക്കുന്നു എന്നിവ നിങ്ങൾ ചോദിക്കണം.
എൻ്റെ പ്രധാന പാഠങ്ങൾ ഇവയാണ്:
• ആർക്കിടെക്ചർ ഉൽപ്പന്നത്തിൻ്റെ ഘട്ടത്തിന് അനുയോജ്യമായിരിക്കണം. മൈക്രോസർവീസസ് (microservices), കുബർനെറ്റീസ് (Kubernetes), സങ്കീർണ്ണമായ ഇവൻ്റ് ക്യൂകൾ (event queues) എന്നിവ ഉടൻ തന്നെ ഉപയോഗിക്കാൻ തോന്നാം. ഞങ്ങളുടെ പ്രോജക്റ്റിനായി, ഞങ്ങൾ ഒരു സിംഗിൾ പ്രോസസ്സിലുള്ള ലെയേർഡ് ആർക്കിടെക്ചർ (layered architecture) ആണ് തിരഞ്ഞെടുത്തത്. ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റത്തിൻ്റെ (distributed system) ബുദ്ധിമുട്ടുകൾ ഇല്ലാതെ തന്നെ ഉത്തരവാദിത്തങ്ങൾ വേർതിരിക്കാൻ ഇത് ഞങ്ങളെ അനുവദിച്ചു. തുടക്കത്തിൽ ലളിതമായ രീതിയാണ് പലപ്പോഴും നല്ലത്.
• ചില തീരുമാനങ്ങൾ ഇപ്പോൾ ലാഭകരമായിരിക്കാം എന്നാൽ പിന്നീട് വലിയ ചിലവ് വരുത്തിയേക്കാം. ഞങ്ങൾ ആദ്യ ദിവസം മുതൽ തന്നെ ഞങ്ങളുടെ ഡാറ്റാ മോഡലിൽ ഒരു TenantId ചേർത്തു. ഞങ്ങൾക്ക് ഒരു ക്ലയൻ്റ് മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ എങ്കിലും, ഇത് ഭാവിയിൽ ഒരു SaaS മോഡലിലേക്ക് മാറുന്നത് എളുപ്പമാക്കി. മൾട്ടി-ടെനൻസി (multi-tenancy) ചേർക്കാൻ നിങ്ങൾ വൈകിയാൽ, മൈഗ്രേഷൻ ഒരു പേടിസ്വപ്നമായി മാറും.
• ഡിസൈൻ ഭാവിയിലെ വഴിമുട്ടലുകൾ ഒഴിവാക്കുന്നു. പ്രോഗ്രാമിംഗ് ഒരു പെട്ടെന്നുള്ള പ്രശ്നത്തിന് പരിഹാരം കാണുന്നു. എന്നാൽ ഡിസൈൻ ഭാവിയിലേക്കുള്ള വാതിലുകൾ അടയ്ക്കാതെ ഒരു പ്രശ്നത്തിന് പരിഹാരം
ഒരു പ്രോഗ്രാമറും ഡിസൈനറും തമ്മിലുള്ള വ്യത്യാസം "എന്തുകൊണ്ട്" (why) എന്ന കാര്യമാണ്.
ഒരു പ്രോഗ്രാമർ ചോദിക്കുന്നു: "ഇത് എങ്ങനെ പ്രവർത്തിപ്പിക്കാം?" ഒരു ഡിസൈനർ ചോദിക്കുന്നു: "ഈ പ്രത്യേക പ്രശ്നത്തിന് എന്തുകൊണ്ടാണ് ഇത് ശരിയായ പരിഹാരമാകുന്നത്?"