QA-യിൽ നിന്ന് ഒരു Component Architect ലേക്ക്
AI കോഡ് എഡിറ്ററുകൾ ഇപ്പോൾ മിക്ക ബോയിലർപ്ലേറ്റ് (boilerplate) കോഡുകളും കൈകാര്യം ചെയ്യുന്നു. ഇത് ഒരു അപകടകരമായ മിഥ്യ സൃഷ്ടിക്കുന്നു. AI കോഡ് എഴുതുകയും അത് കംപൈൽ ചെയ്യുകയും ചെയ്താൽ അത് പ്രവർത്തിക്കും എന്ന് ടീമുകൾ കരുതുന്നു.
ഈ രീതി ചെറിയ ഫീച്ചറുകൾക്ക് അനുയോജ്യമാണ്. എന്നാൽ ഡിസൈൻ സിസ്റ്റങ്ങളിൽ (design systems) ഇത് പരാജയപ്പെടുന്നു.
ഒരു ഡിസൈൻ സിസ്റ്റം കമ്പോണന്റ് എന്നത് ഒറ്റത്തവണ ഉപയോഗിക്കാനുള്ള ഒരു ഫീച്ചറല്ല. അതൊരു ഇൻഫ്രാസ്ട്രക്ചറാണ് (infrastructure). ഒരു ബട്ടണോ ഇൻപുട്ട് ഫീൽഡോ നൂറുകണക്കിന് ഉൽപ്പന്നങ്ങളിലായി ദശലക്ഷക്കണക്കിന് ഉപയോക്താക്കൾക്ക് സേവനം നൽകുന്നു.
നിങ്ങൾ എത്ര വേഗത്തിൽ കോഡ് എഴുതുന്നു എന്നതല്ല യഥാർത്ഥ നേട്ടം. മറിച്ച്, പരാജയങ്ങൾ എത്രത്തോളം മുൻകൂട്ടി കാണാൻ നിങ്ങൾക്ക് കഴിയുന്നു എന്നതാണ്.
നിങ്ങൾ ഒരു 'ബിൽഡർ' (builder) മൈൻഡ്സെറ്റിൽ നിന്ന് ഒരു 'ബ്രേക്കർ' (breaker) മൈൻഡ്സെറ്റിലേക്ക് മാറണം. TDD, BDD, Spec-Driven Development എന്നിവയിലൂടെയുള്ള ടെസ്റ്റിംഗ് ശീലമാക്കേണ്ടതുണ്ട്.
മിക്ക ടീമുകളും "Happy Path"-ന് വേണ്ടി നിർമ്മിക്കുന്നു. അവർ ഒരു Figma ഫയലുമായി പൊരുത്തപ്പെടുന്നു, അവിടെ അവർ നിർത്തുന്നു. എന്നാൽ കമ്പോണന്റുകൾ യഥാർത്ഥ ലോകത്തിലെ അനിശ്ചിതത്വങ്ങളെ അതിജീവിക്കണം.
കോഡ് എഴുതുന്നതിന് മുമ്പ് ഒരു ശക്തമായ ടീം കഠിനമായ ചോദ്യങ്ങൾ ചോദിക്കുന്നു:
- ഡിസൈനർമാർ: ഒരു ടെക്സ്റ്റ് സ്ട്രിംഗ് 400 ക്യാരക്ടറുകൾ നീളമുള്ളതാണെങ്കിൽ എന്ത് സംഭവിക്കും? UI തകരാറിലാകുമോ?
- എഞ്ചിനീയർമാർ: ഒരു ഉപയോക്താവ് ഒരു സെക്കൻഡിൽ പത്ത് തവണ ഒരു ടോഗിൾ ക്ലിക്ക് ചെയ്താൽ എന്ത് സംഭവിക്കും? സ്റ്റേറ്റ് (state) തെറ്റായിപ്പോകുമോ?
- അക്സസിബിലിറ്റി (Accessibility): കീബോർഡ് മാത്രം ഉപയോഗിച്ച് ഈ ഡ്രോപ്പ്ഡൗൺ ഒരു സ്ക്രീൻ റീഡർ എങ്ങനെ കൈകാര്യം ചെയ്യും?
AI ടൂളുകൾ കോഡിംഗിൽ മിടുക്കരാണെങ്കിലും അനുമാനങ്ങളിൽ (assumptions) പിന്നിലാണ്. അവ ദുർബലമായ (brittle) കമ്പോണന്റുകളാണ് നിർമ്മിക്കുന്നത്.
നിങ്ങളുടെ ജോലി സംരക്ഷിക്കാൻ ഈ വർക്ക്ഫ്ലോ ഉപയോഗിക്കുക:
- സ്പെക് (Tokens, Accessibility, API) നിർവചിക്കുക.
- അതിരുകൾ നിശ്ചയിക്കുന്നതിനായി ആദ്യം ടെസ്റ്റുകളും സ്റ്റോറികളും എഴുതുക.
- ആ അതിരുകൾക്കുള്ളിൽ കോഡ് നിർമ്മിക്കാൻ AI ഉപയോഗിക്കുക.
TDD ഈ പ്രക്രിയയെ തിരിച്ചിടുന്നു. പിന്നീട് ബഗുകൾ പരിഹരിക്കുന്നതിന് പകരം, നിങ്ങൾ മുൻകൂട്ടി അതിരുകൾ നിശ്ചയിക്കുന്നു. തുടർന്ന് AI ആ ടെസ്റ്റുകൾ പൂർത്തീകരിക്കുന്നു.
Behavior-Driven Development (BDD)-ഉം സഹായിക്കുന്നു. ഡിസൈനും എഞ്ചിനീയറിംഗും തമ്മിലുള്ള അകലം കുറയ്ക്കാൻ ഇത് മനുഷ്യഭാഷ ഉപയോഗിക്കുന്നു.
ഉദാഹരണം:
- ഒരു ഉപയോക്താവിന് സാവധാനത്തിലുള്ള കണക്ഷൻ ആണെന്ന് കരുതുക,
- അവർ സബ്മിറ്റ് ക്ലിക്ക് ചെയ്യുമ്പോൾ,
- ബട്ടൺ ഒരു ലോഡിംഗ് സ്റ്റേറ്റ് കാണിക്കുകയും ക്ലിക്കുകൾ ഡിസേബിൾ ചെയ്യുകയും വേണം.
ടെസ്റ്റിംഗ് വേഗത കുറയ്ക്കുമെന്ന് ചില നേതാക്കൾ ഭയപ്പെടുന്നു. ഇത് ഒരു തെറ്റാണ്.
ഒരു കമ്പോണന്റിന്റെ ചെലവിൽ ആദ്യഘട്ട കോഡിംഗ് വെറും 5% മാത്രമാണ്. ബാക്കി 95% മെയിന്റനൻസിനും (maintenance) ബഗുകൾ പരിഹരിക്കുന്നതിനുമാണ് ചെലവാകുന്നത്.
ഒരു ടെസ്റ്റിംഗ് മൈൻഡ്സെറ്റ് നിങ്ങൾക്ക് നൽകുന്നത്
QA-യിൽ നിന്ന് കമ്പോണന്റ് ആർക്കിടെക്റ്റിലേക്ക്: നിങ്ങളുടെ കോഡ് തകർക്കുന്നത് എന്തുകൊണ്ട് ലോകോത്തര ഡിസൈൻ സിസ്റ്റങ്ങളുടെ രഹസ്യമാകുന്നു?
ഭൂരിഭാഗം ഡെവലപ്പർമാരും കാര്യങ്ങൾ പ്രവർത്തിപ്പിക്കാനാണ് (make things work) നിർമ്മിക്കുന്നത്. എന്നാൽ QA എഞ്ചിനീയർമാർ കാര്യങ്ങൾ പരാജയപ്പെടാൻ (make things fail) വേണ്ടി നിർമ്മിക്കുന്നു. ഈ വ്യത്യാസമാണ് ഒരു നല്ല കമ്പോണന്റും ലോകോത്തര ഡിസൈൻ സിസ്റ്റം കമ്പോണന്റും തമ്മിലുള്ള വ്യത്യാസം.
ഞാൻ എന്റെ കരിയർ ആരംഭിച്ചത് QA (Quality Assurance) മേഖലയിലാണ്. വർഷങ്ങളോളം സോഫ്റ്റ്വെയറിലെ പിഴവുകൾ കണ്ടെത്താനും, അത് എങ്ങനെ തകരാറിലാകാം എന്ന് പരിശോധിക്കാനും ഞാൻ സമയം ചെലവഴിച്ചു. ഇന്ന് ഒരു കമ്പോണന്റ് ആർക്കിടെക്റ്റ് എന്ന നിലയിൽ, ആ പഴയ QA മനോഭാവമാണ് എന്റെ ഏറ്റവും വലിയ കരുത്ത് എന്ന് ഞാൻ തിരിച്ചറിയുന്നു.
QA മനോഭാവം: നിർമ്മാണത്തേക്കാൾ ഉപരിയായി പരിശോധന
ഒരു സാധാരണ ഡെവലപ്പർ ഒരു കമ്പോണന്റ് നിർമ്മിക്കുമ്പോൾ, അവരുടെ പ്രധാന ലക്ഷ്യം അത് ആവശ്യപ്പെട്ട ഫീച്ചറുകൾ കൃത്യമായി ചെയ്യുന്നുണ്ടോ എന്നതാണ്. "ഇത് വർക്ക് ആകുന്നുണ്ടോ?" എന്നതാണ് അവരുടെ ചോദ്യം.
എന്നാൽ ഒരു QA എഞ്ചിനീയറുടെ ചോദ്യം വ്യത്യസ്തമാണ്: "ഇത് എപ്പോഴാണ് പരാജയപ്പെടുക?" (When will this fail?).
ഈ ഒരു മാറ്റം ഡിസൈൻ സിസ്റ്റങ്ങളുടെ കാര്യത്തിൽ വളരെ നിർണ്ണായകമാണ്. ഒരു ഡിസൈൻ സിസ്റ്റം എന്നത് വെറും ബട്ടണുകളുടെയോ ഇൻപുട്ട് ഫീൽഡുകളുടെയോ ശേഖരമല്ല; അത് ഒരു വലിയ എക്കോസിസ്റ്റമാണ്. ഈ എക്കോസിസ്റ്റത്തിലെ ഓരോ കമ്പോണന്റും എത്രത്തോളം കരുത്തുറ്റതാണെന്ന് (robust) ഉറപ്പാക്കേണ്ടതുണ്ട്.
എഡ്ജ് കേസുകൾ (Edge Cases) ആണ് യഥാർത്ഥ പരീക്ഷണം
ഒരു കമ്പോണന്റ് സാധാരണ സാഹചര്യങ്ങളിൽ മികച്ച രീതിയിൽ പ്രവർത്തിച്ചേക്കാം. എന്നാൽ യഥാർത്ഥ വെല്ലുവിളി വരുന്നത് എഡ്ജ് കേസുകളിലാണ്:
- അതിപ്രസരമുള്ള ഡാറ്റ: ഒരു ടെക്സ്റ്റ് ഫീൽഡിൽ പ്രതീക്ഷിച്ചതിലും വലിയ അളവിൽ ഡാറ്റ വന്നാൽ കമ്പോണന്റ് എങ്ങനെ പ്രതികരിക്കുന്നു?
- അസാധാരണമായ സ്ക്രീൻ വലുപ്പങ്ങൾ: വളരെ ചെറിയ സ്ക്രീനുകളിലോ അല്ലെങ്കിൽ അമിതമായി വലുപ്പമുള്ള സ്ക്രീനുകളിലോ കമ്പോണന്റ് തകരാറിലാകുന്നുണ്ടോ?
- നെറ്റ്വർക്ക് പ്രശ്നങ്ങൾ: ഡാറ്റ ലോഡ് ആകാൻ വൈകുമ്പോൾ കമ്പോണന്റ് എങ്ങനെ കാണപ്പെടുന്നു?
- അപ്രതീക്ഷിത ഇൻപുട്ടുകൾ: ഉപയോക്താവ് തെറ്റായ ഡാറ്റ നൽകിയാൽ കമ്പോണന്റ് എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു?
ഒരു ആർക്കിടെക്റ്റ് എന്ന നിലയിൽ, ഞാൻ കമ്പോണന്റുകൾ നിർമ്മിക്കുന്നത് ഈ സാഹചര്യങ്ങളെ മുൻകൂട്ടി കണ്ട് ആണ്. കോഡ് എഴുതുന്നതിന് മുൻപ് തന്നെ, അത് എവിടെയൊക്കെ തകരാൻ സാധ്യതയുണ്ടെന്ന് ഞാൻ ചിന്തിക്കുന്നു.
തകർക്കുന്നതിലൂടെ നിർമ്മിക്കുക (Build by Breaking)
"Breaking your code" എന്നത് കോഡ് നശിപ്പിക്കുക എന്നല്ല അർത്ഥമാക്കുന്നത്. മറിച്ച്, നിങ്ങളുടെ കോഡിന്റെ പരിമിതികൾ പരീക്ഷിക്കുക എന്നതാണ്.
ഒരു കമ്പോണന്റ് നിർമ്മിച്ചു കഴിഞ്ഞാൽ, അതിനെ പരമാവധി പരീക്ഷിക്കുക. അതിനെ അപ്രതീക്ഷിതമായ സാഹചര്യങ്ങളിലേക്ക് തള്ളിവിടുക. അത് തകരുമ്പോൾ, നിങ്ങൾ ഒരു പുതിയ പാഠം പഠിക്കുകയാണ്. ആ തകർച്ച പരിഹരിക്കാൻ നിങ്ങൾ നടത്തുന്ന ശ്രമങ്ങളാണ് ആ കമ്പോണന്റിനെ ലോകോത്തര നിലവാരത്തിലേക്ക് എത്തിക്കുന്നത്.
ഡിസൈൻ സിസ്റ്റങ്ങളിൽ ഇത് വളരെ പ്രധാനമാണ്. കാരണം, ഒരു ചെറിയ കമ്പോണന്റിലെ പിഴവ് ആ സിസ്റ്റം ഉപയോഗിക്കുന്ന വലിയൊരു ആപ്ലിക്കേഷനെ മുഴുവൻ ബാധിച്ചേക്കാം.
ഉപസംഹാരം
QA-യിൽ നിന്ന് ആർക്കിടെക്റ്റിലേക്കുള്ള എന്റെ യാത്ര എന്നെ പഠിപ്പിച്ചത് ഒന്നുമാത്രമാണ്: മികച്ച ഡിസൈൻ സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്നത് കാര്യങ്ങൾ ശരിയായി പ്രവർത്തിപ്പിക്കാൻ മാത്രമല്ല, മറിച്ച് കാര്യങ്ങൾ തെറ്റായി പോകുമ്പോഴും അവ എങ്ങനെ പ്രതികരിക്കുന്നു എന്ന് നിയന്ത്രിക്കാനാണ്.
അതുകൊണ്ട്, അടുത്ത തവണ നിങ്ങൾ ഒരു കമ്പോണന്റ് നിർമ്മിക്കുമ്പോൾ, അത് എങ്ങനെ പ്രവർത്തിക്കും എന്ന് മാത്രം ചിന്തിക്കാതെ, അത് എങ്ങനെ തകരും എന്ന് കൂടി ചിന്തിക്കുക. ആ ചിന്താഗതിയാണ് നിങ്ങളെ ഒരു മികച്ച ആർക്കിടെക്റ്റ് ആക്കി മാറ്റുന്നത്.