ഓരോ പുതിയ പ്രോജക്റ്റും ഒരേ പ്രലോഭനമാണ് നൽകുന്നത്: എഡിറ്റർ തുറക്കുക, ഒരു ഫ്രെയിംവർക്ക് തിരഞ്ഞെടുക്കുക, ടൈപ്പ് ചെയ്യാൻ തുടങ്ങുക. MaxOS-ന്റെ സ്രഷ്ടാവായ Max Paardekam ആ ആകർഷണം ശക്തമായി അനുഭവിച്ചു. കുറച്ച് ആഴ്ചകൾക്ക് മുമ്പ്, ഈ പ്രോജക്റ്റ് അദ്ദേഹത്തിന്റെ കുറിപ്പുകളിൽ ചിതറിക്കിടന്ന ആശയങ്ങൾ മാത്രമായിരുന്നു. Cursor-നുള്ളിൽ മണിക്കൂറുകളോളം TypeScript എഴുതിക്കൊണ്ട് മസിൽ മെമ്മറിയും ഓട്ടോകംപ്ലീറ്റും ഉപയോഗിച്ച് വേഗത കൂട്ടുക എന്നതായിരുന്നു അദ്ദേഹത്തിന്റെ ആദ്യത്തെ പ്രേരണ. എന്നാൽ അദ്ദേഹം അതിനെ പ്രതിരോധിച്ചു. ആപ്ലിക്കേഷൻ കോഡിന് പകരം, അപൂർവ്വവും എന്നാൽ കൂടുതൽ ശ്രദ്ധ ആവശ്യമുള്ളതുമായ ഒന്ന് അദ്ദേഹം നിർമ്മിച്ചു: ഒരു പൂർണ്ണമായ ആർക്കിടെക്ചർ (architecture).
ആ തീരുമാനം ആദ്യം ഒരു തടസ്സമായി തോന്നി. ടൂളുകൾ തയ്യാറായപ്പോൾ നിന്നും ബോയിലർപ്ലേറ്റ് (boilerplate) സെക്കൻഡുകൾക്കുള്ളിൽ ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ, ബോക്സുകളും അമ്പടയാളങ്ങളും വരയ്ക്കാൻ സമയം ചെലവഴിക്കുന്നത് അസംബന്ധമായി തോന്നാം. എന്നാൽ MaxOS വെറുമൊരു Electron wrapper ആയി മാറാനല്ല ലക്ഷ്യമിടുന്നത്. വർഷങ്ങളോളം ഉപയോഗിക്കാനും, റീഫാക്റ്ററിംഗിനും (refactoring), വിപുലീകരണത്തിനും ശേഷവും നിലനിൽക്കുന്ന ഒന്ന് നിർമ്മിക്കുക എന്നതാണ് ലക്ഷ്യം. ഇത്തരത്തിലുള്ള ആയുസ്സുള്ള സിസ്റ്റങ്ങൾക്ക് വേഗത്തിലുള്ള തുടക്കത്തേക്കാൾ ആഴത്തിലുള്ള ഒന്ന് ആവശ്യമാണ്. ആദ്യത്തെ import statement എഴുതുന്നതിന് മുമ്പ് തന്നെ അവയ്ക്ക് വ്യക്തമായ ചിന്താഗതി ആവശ്യമാണ്.
എന്തുകൊണ്ട് IDE കാത്തിരിക്കാം
ആധുനിക ഡെവലപ്മെന്റ് എൻവയോൺമെന്റുകൾ പ്ലാനിംഗും എക്സിക്യൂഷനും തമ്മിലുള്ള വ്യത്യാസം ഇല്ലാതാക്കുന്നു. Cursor പോലുള്ള AI അസിസ്റ്റഡ് എഡിറ്ററുകൾ ഉപയോഗിച്ച് ഒരു കമന്റിൽ നിന്ന് തന്നെ മുഴുവൻ കമ്പോണന്റുകളും (components) നിർമ്മിക്കാൻ സാധിക്കും. ഇതിന്റെ ഫീഡ്ബാക്ക് വളരെ വേഗത്തിലാണ് ലഭിക്കുന്നത്, ഒരു UI രൂപപ്പെടുന്നത് കാണുന്നതിലൂടെ ലഭിക്കുന്ന ഡോപാമൈൻ ഹിറ്റ് (dopamine hit) ചെറുതല്ല. തന്റെ പ്രാരംഭ ഊർജ്ജം മിക്കവാറും TypeScript ഫയലുകൾ എഴുതാനായി ഉപയോഗിക്കുമെന്ന ധാരണയോടെയാണ് Paardekam തുടങ്ങിയത്. എന്നാൽ ക്രമേണ അദ്ദേഹം ആ സമയം ശുദ്ധമായ ഡിസൈൻ ജോലികൾക്കായി മാറ്റിവെച്ചു.
ഒരു സോളോ ബിൽഡറെ സംബന്ധിച്ചിടത്തോളം ഇതൊരു പ്രയാസകരമായ മാറ്റമാണ്. നിങ്ങൾ തന്നെയാണ് നിങ്ങളുടെ മുഴുവൻ എൻജിനീയറിംഗ് ടീമും എന്ന അവസ്ഥയിൽ, ഒരു ഡയഗ്രം ടൂളിലോ ടെക്സ്റ്റ് ഡോക്യുമെന്റിലോ ചെലവഴിക്കുന്ന ഓരോ മണിക്കൂറും പ്രോജക്റ്റ് പൂർത്തിയാക്കുന്നതിൽ നിന്നുള്ള നഷ്ടമായി തോന്നും. എന്നാൽ തുടക്കത്തിൽ എഴുതുന്ന കോഡുകൾ പലപ്പോഴും പുരോഗതിയാണെന്ന് തോന്നിപ്പിക്കുന്ന ഒരു ബാധ്യതയാണ്. ആദ്യ ദിവസങ്ങളിൽ എടുത്ത തീരുമാനങ്ങൾ പിന്നീട് ഓരോ പുതിയ ഫീച്ചർ ചേർക്കുമ്പോഴും തടസ്സമാകുമ്പോൾ, ഒരു പ്രോട്ടോടൈപ്പ് പ്രവർത്തിക്കുന്നത് കാണുന്നതിന്റെ ആവേശം പെട്ടെന്ന് ഇല്ലാതാകും. എഡിറ്ററിൽ നിന്ന് സ്വയം അകന്നുനിന്നതിലൂടെ, കാലക്രമേണ വലിയ മൂല്യം നൽകുന്ന ഒരൊറ്റ കാര്യം Paardekam നേടിയെടുത്തു: വ്യക്തത (clarity).
ഫീച്ചറുകളിലല്ല, സിസ്റ്റങ്ങളിലാണ് ചിന്തിക്കേണ്ടത്
ഈ ആഴ്ചകളിലെ ഏറ്റവും വലിയ മാറ്റം സാങ്കേതികമായിരുന്നില്ല, മറിച്ച് ചിന്താപരമായതായിരുന്നു. സോഫ്റ്റ്വെയർ ആർക്കിടെക്ചർ ഗൗരവമായി കാണുമ്പോൾ, നിങ്ങൾ ചോദിക്കുന്ന ചോദ്യങ്ങൾ തന്നെ മാറുന്നു. Paardekam പ്രോജക്റ്റിനെ ഒരു 'ഫീച്ചർ മൈൻഡ്സെറ്റോടെ' കാണുന്നത് നിർത്തി. ഒരു പ്രത്യേക കപ്പാബിലിറ്റി എങ്ങനെ ചേർക്കാം എന്നതിനെക്കുറിച്ചല്ല അദ്ദേഹം ചിന്തിച്ചത്. പകരം, ഭാവിയിൽ വരുന്ന ഏത് ഫീച്ചറുകളും എളുപ്പത്തിൽ ചേർക്കാൻ സഹായിക്കുന്ന അടിസ്ഥാന ഘടന ഏതാണ് എന്ന കഠിനമായ ചോദ്യമാണ് അദ്ദേഹം സ്വീകരിച്ചത്.
ആ വ്യത്യാസം വളരെ പ്രധാനമാണ്. ഒരു ഫീച്ചർ മൈൻഡ്സെറ്റ് സോഫ്റ്റ്വെയറിനെ ഒരു 'ടു-ഡൂ ലിസ്റ്റ്' (to-do list) പോലെ കാണുന്നു. നിങ്ങൾ ആദ്യം സെർച്ച്, പിന്നെ നോട്ടിഫിക്കേഷൻ, പിന്നെ എക്സ്പോർട്ട് ബട്ടൺ എന്നിങ്ങനെ ഓരോന്നായി ചെയ്യുന്നു. എന്നാൽ ഒരു സിസ്റ്റം മൈൻഡ്സെറ്റ് ചോദിക്കുന്നത്, സെർച്ച്, നോട്ടിഫിക്കേഷൻ, എക്സ്പോർട്ട് എന്നിവയ്ക്ക് എങ്ങനെ ഒരേ ഡാറ്റ മോഡലും, ഒരേ ഇവന്റ് ബസും (event bus), ഒരേ പെർമിഷൻ ലെയറും പങ്കിടാൻ കഴിയും എന്നാണ്. അതായത്, ആപ്ലിക്കേഷന്റെ വാചകങ്ങൾ എഴുതുന്നതിന് മുമ്പ് അതിന്റെ വ്യാകരണം (grammar) രൂപകൽപ്പന ചെയ്യുക എന്നാണ് ഇതിനർത്ഥം. ഇതിന് തുടക്കത്തിൽ കൂടുതൽ സമയം ആവശ്യമാണ്. എന്നാൽ ഇതിന്റെ ഫലം, ഭാവിയിലെ ജോലികൾ വെറും കൂട്ടിച്ചേർക്കലുകൾ എന്നതിലുപരി ഒരു സംയോജനം (composition) പോലെ അനുഭവപ്പെടും എന്നതാണ്.
പത്ത് വ്യത്യസ്ത ആപ്ലിക്കേഷനുകളിൽ സാധാരണയായി കാണപ്പെടുന്ന ഫംഗ്ഷനുകളെ സംയോജിപ്പിക്കാൻ ലക്ഷ്യമിടുന്ന MaxOS പോലുള്ള ഒരു പ്രോജക്റ്റിന് ഇത് വളരെ നിർണ്ണായകമാണ്. സിസ്റ്റമാറ്റിക് ആയ ചിന്താഗതിയില്ലാതെ നടത്തുന്ന ശക്തമായ സംയോജനം, തകരാറിലാകാൻ സാധ്യതയുള്ള ബന്ധങ്ങളുടെയും (brittle bridges) അസ്ഥിരമായ അവസ്ഥകളുടെയും (inconsistent state) ഒരു പേടിസ്വപ്നമായി മാറും. എന്നാൽ ശരിയായ രീതിയിൽ ചെയ്യുമ്പോൾ, വർക്ക്സ്പേസ് എന്നത് വെറും ടൂളുകളുടെ കൂട്ടമല്ല, മറിച്ച് ഒരു ഏകീകൃത ജീവിയെപ്പോലെ (single organism) പ്രവർത്തിക്കും.
ഓപ്പറേറ്റിംഗ് സിസ്റ്റമല്ല, വർക്ക്സ്പേസാണ് ലക്ഷ്യം
തന്റെ ലക്ഷ്യത്തിന്റെ പരിധികളെക്കുറിച്ച് Paardekam വ്യക്തതയോടെ സംസാരിച്ചിട്ടുണ്ട്. MaxOS വിൻഡോസിനോ (Windows) macOS-നോ പകരമാവില്ല. ഡ്രൈവറുകൾ, മെമ്മറി അലോക്കേഷൻ, അല്ലെങ്കിൽ ഹാർഡ്വെയർ അബ്സ്ട്രാക്ഷൻ ലെയറുകൾ എന്നിവ നിയന്ത്രിക്കാൻ ഇത് ശ്രമിക്കുന്നില്ല. ഇതിന്റെ ലക്ഷ്യം കൂടുതൽ വ്യക്തിപരമായ ഒന്നാണ്: വർക്ക്സ്പേസ് (workspace).
മിക്ക അറിവ് തൊഴിലാളികളും (knowledge workers) ചിതറിക്കിടക്കുന്ന ഒരു സാഹചര്യത്തിലാണ് ജോലി ചെയ്യുന്നത്. നിങ്ങൾ ഇമെയിൽ ക്ലയന്റിൽ നിന്ന് കലണ്ടറിലേക്കും, നോട്ട്സ് ആപ്പിൽ നിന്ന് ടെർമിനലിലേക്കും, ഡിസൈൻ ടൂളിൽ നിന്ന് മെസ്സേജിംഗ് പ്ലാറ്റ്ഫോമിലേക്കും മാറിക്കൊണ്ടിരിക്കുന്നു. ഓരോ മാറ്റത്തിലും തടസ്സങ്ങൾ ഉണ്ടാകുന്നു. സന്ദർഭങ്ങൾ (context) നഷ്ടപ്പെടുന്നു. ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ പ്രയാസമാകുന്നു. ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഒരു വേദി ഒരുക്കുന്നുണ്ടെങ്കിലും, അത് നാടകം സംവിധാനം ചെയ്യുന്നില്ല.
നിങ്ങളുടെ ജോലിയുടെ ഗതി മനസ്സിലാക്കുകയും വേഗത്തിൽ മുന്നോട്ട് പോകാൻ സഹായിക്കുകയും ചെയ്യുന്ന ഒരു ഏകീകൃത അന്തരീക്ഷമായി ഈ അനുഭവം മാറ്റാനാണ് MaxOS ലക്ഷ്യമിടുന്നത്. ഒരു പരമ്പരാഗത OS നിർമ്മിക്കുന്നതിൽ നിന്നും ഇത് തികച്ചും വ്യത്യസ്തമായ ഒരു എഞ്ചിനീയറിംഗ് വെല്ലുവിളിയാണ്. ഇതിന് വർക്ക്ഫ്ലോകളോട് (workflows) ആഴത്തിലുള്ള സഹാനുഭൂതിയും, പ്രവർത്തന പരിധികളുടെ കൃത്യമായ നിയന്ത്രണവും, ഉപയോക്താവ് ടൂളിനോട് പൊരുത്തപ്പെടുന്നതിന് പകരം ഉപയോക്താവിന്റെ ഉദ്ദേശ്യത്തിനനുസരിച്ച് മാറുന്ന ഇന്റർഫേസുകളും ആവശ്യമാണ്. ഒരു വർക്ക്സ്പേസ് മാറ്റുക എന്നാൽ ശീലങ്ങൾ മാറ്റുക എന്നാണ് അർത്ഥം. പുതിയൊരു സംവിധാനം പഠിച്ചെടുക്കുന്നതിനേക്കാൾ ഉപരിയായി, അത് പഴയതിനേക്കാൾ ആശ്വാസം നൽകുന്നു എന്ന് തോന്നുമ്പോൾ മാത്രമേ ശീലങ്ങൾ മാറൂ.
ശാന്തമായ ആ ആഴ്ചകളിൽ നിർമ്മിക്കപ്പെട്ടത്
Paardekam-ന്റെ ആർക്കിടെക്ചർ ഘട്ടം രണ്ട് വ്യക്തമായ ഫലങ്ങൾ നൽകി. ഒന്നാമതായി, വ്യക്തമായ ഒരു വിഷനും മിഷനും നിർവചിച്ചു. ഇത് വെറും മാർക്കറ്റിംഗ് തന്ത്രങ്ങളല്ല. ഒരു സോളോ ടെക്നിക്കൽ ഫൗണ്ടറെ സംബന്ധിച്ചിടത്തോളം, ഇത് പ്രോജക്റ്റിന്റെ വ്യാപ്തി (scope) കൃത്യമായി നിലനിർത്താൻ സഹായിക്കുന്നു. ഒരു ചാറ്റ് സൈഡ്ബാറോ പ്ലഗിൻ മാർക്കറ്റേസോ ചേർക്കണോ എന്ന തീരുമാനത്തിൽ നിങ്ങൾ എത്തുമ്പോൾ, ആ മിഷൻ സ്റ്റേറ്റ്മെന്റ് അത് സ്വീകരിക്കണോ അതോ ഒഴിവാക്കണോ എന്ന് തീരുമാനിക്കുന്നു. രണ്ടാമതായി, അദ്ദേഹം ഒരു സമ്പൂർണ്ണ പ്രോജക്റ്റ് ബ്ലൂപ്രിന്റ് പൂർത്തിയാക്കി.
പദ്ധതിയുടെ മുഴുവൻ രൂപരേഖയും തുടക്കം മുതൽ ഒടുക്കം വരെ കാണുന്നത് പ്രോജക്റ്റിന്റെ മനഃശാസ്ത്രപരമായ കാഴ്ചപ്പാട് തന്നെ മാറ്റിമറിച്ചു. നോട്ട്ബുക്കുകളിലെ ആശയങ്ങൾ വെറും സങ്കൽപ്പങ്ങൾ മാത്രമാണ്. എന്നാൽ ഒരു ബ്ലൂപ്രിന്റ് എന്നത് അനിവാര്യമായ ഒന്നായി അനുഭവപ്പെടുന്നു. പരിഹരിക്കാൻ ചെലവ് കുറഞ്ഞ ഘട്ടത്തിൽ തന്നെ ഇത് പിഴവുകൾ പുറത്തുകൊണ്ടുവരുന്നു. ഏറ്റവും വലിയ വെല്ലുവിളികൾ എവിടെയാണെന്ന് ഇത് വെളിപ്പെടുത്തുന്നു. ഈ ഘട്ടത്തിൽ, കോഡിനേക്കാൾ പ്രാധാന്യം കൃത്യമായ ഒരു ഡോക്യുമെന്റിനാണ്. കോഡ് പിന്നീട് മാറ്റം വരുത്താം (refactor); എന്നാൽ അവ്യക്തമായ ഒരു അടിസ്ഥാനം സാങ്കേതികമായ കടബാധ്യതയായി (technical debt) മാറുകയും, എത്ര രാത്രിയിരുന്ന് ഡീബഗ് ചെയ്താലും അത് പരിഹരിക്കാൻ കഴിയാത്ത അവസ്ഥയുണ്ടാകുകയും ചെയ്യും.
പേപ്പറിൽ നിന്ന് മോണോറെപ്പോയിലേക്ക് (Monorepo)
ആർക്കിടെക്ചർ പൂർത്തിയായതോടെ അടുത്ത ഘട്ടം ആരംഭിച്ചു. Paardekam ഇപ്പോൾ ഡോക്യുമെന്റുകളിൽ നിന്ന് കോഡിലേക്ക് മാറുകയാണ്, അതിന്റെ തുടക്കം മോണോറെപ്പോയുടെ (monorepo) ഇൻസ്റ്റാളേഷനിലൂടെയാണ്. ഈ മാറ്റം ഒരുതരം ആശങ്കയുമായിട്ടാണ് വരുന്നത്. ഒരു ബ്ലൂപ്രിന്റ് എന്നത് ഒരു വാഗ്ദാനമാണ്, എന്നാൽ ഒരു കോഡ്ബേസ് എന്നത് അതിന്റെ തെളിവാണ്. ഡിസൈൻ നടപ്പിലാക്കുമ്പോൾ (implementation) അത് വിജയിക്കുമോ എന്ന കാര്യത്തിൽ തനിക്ക് ആശങ്കയുണ്ടെന്ന് അദ്ദേഹം സമ്മതിച്ചിട്ടുണ്ട്. തിയറിയും ലൈബ്രറി വേർഷനുകളും, എഡ്ജ് കേസുകളും (edge cases), ക്രോസ് പ്ലാറ്റ്ഫോം പെരുമാറ്റങ്ങളും തമ്മിൽ കൂട്ടിമുട്ടുമ്പോൾ മാത്രം ഉണ്ടാകുന്ന അപ്രതീക്ഷിത വെല്ലുവിളികളെക്കുറിച്ചുള്ള ആരോഗ്യകരമായ ഒരു തിരിച്ചറിവാണ് ആ സത്യസന്ധത വെളിപ്പെടുത്തുന്നത്.
മോണോറെപ്പോ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് വെറുമൊരു git init പ്രക്രിയ മാത്രമല്ല. ലോജിക്കൽ ആർക്കിടെക്ചറിനെ പ്രതിഫലിപ്പിക്കുന്ന ഭൗതിക ഘടന (physical structure) ഇത് രൂപപ്പെടുത്തുന്നു. പാക്കേജുകൾ എവിടെ ഇരിക്കണം, അവ എങ്ങനെ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു, ലെയറുകൾ തമ്മിലുള്ള അതിർവരമ്പുകൾ എവിടെയാണ് എന്നിവ ആഴ്ചകളോളം നീണ്ട ആ പ്ലാനിംഗിന്റെ ഫലമായിരിക്കും. ഇത് ശരിയായി ചെയ്താൽ, ആദ്യത്തെ ഫോൾഡർ സ്ട്രക്ചറും ബിൽഡ് പൈപ്പ്ലൈനും ഭാവിയിലെ പ്രവർത്തനങ്ങൾക്ക് വഴികാട്ടിയാകും. എന്നാൽ തെറ്റായി ചെയ്താൽ, വർഷങ്ങളോളം പ്രോജക്റ്റിൽ പ്രവർത്തിക്കുന്ന ഓരോ ഡെവലപ്പറെയും അത് നിശബ്ദമായി ബുദ്ധിമുട്ടിക്കും.
യഥാർത്ഥ പാഠം
ആധുനിക സോഫ്റ്റ്വെയർ സംസ്കാരത്തിൽ നിലനിൽക്കുന്ന 'വേഗതയുടെ' (velocity) സംസ്കാരത്തിന് വിരുദ്ധമാണ് Paardekam-ന്റെ അനുഭവം. വേഗത്തിൽ പ്രോജക്റ്റുകൾ പുറത്തിറക്കാനും വളർച്ച കാണിക്കാനും സംഭാഷണങ്ങൾക്ക് പകരം കോഡിനെ മാത്രം ആശ്രയിക്കാനുമുള്ള വലിയ സമ്മർദ്ദമുണ്ട്. എന്നാൽ ചില പ്രോജക്റ്റുകൾ, പ്രത്യേകിച്ച് ദീർഘകാലം നിലനിൽക്കാൻ ഉദ്ദേശിച്ചുള്ളവ, ക്ഷമയ്ക്ക് അർഹമായ ഫലം നൽകുന്നു. വേരിയബിളുകൾ പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ വിഷൻ നിർവചിക്കാനും ബ്ലൂപ്രിന്റ് തയ്യാറാക്കാനും സിസ്റ്റം ഡിസൈൻ ചെയ്യാനുമുള്ള അച്ചടക്കം, കാലമെത്ര കഴിഞ്ഞാലും പ്രസക്തമായ ഒരു ഉപദേശമാണ്.
ഇപ്പോൾ നിങ്ങളുടെ കയ്യിൽ ഒരു ആശയമുണ്ടാവുകയും ഉടൻ തന്നെ എഡിറ്റർ തുറക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, കുറച്ചു ദിവസങ്ങൾ കൂടി ആസൂത്രിതമായ ഡിസൈനിനായി മാറ്റിവെക്കുന്നത് മാസങ്ങളോളം നീണ്ടുനിൽക്കുന്ന അനാവശ്യമായ പണികൾ ഒഴിവാക്കാൻ സഹായിക്കുമോ എന്ന് ചിന്തിക്കുക. ഒരു ആപ്പ് പ്രവർത്തിക്കുമ്പോൾ ലഭിക്കുന്ന ഡോപാമൈൻ (dopamine) പെട്ടെന്ന് ഇല്ലാതാകാം, എന്നാൽ നല്ലൊരു ആർക്കിടെക്ചർ നൽകുന്ന വ്യക്തത കാലക്രമേണ വർദ്ധിച്ചുകൊണ്ടേയിരിക്കും. നിങ്ങൾ എന്താണ് നിർമ്മിക്കുന്നത് എന്നും എന്തുകൊണ്ട് നിർമ്മിക്കുന്നു എന്നും കൃത്യമായി മനസ്സിലാക്കി തുടങ്ങുക. ടൈപ്പിംഗ് പിന്നീട് ചെയ്യാം.