𝗪𝗵𝘆 𝗘𝘃𝗲𝗿𝘆 𝗟𝗶𝗯𝗿𝗮𝗿𝘆 𝗡𝗲𝗲𝗱𝘀 𝗮 𝗥𝗲𝗮𝗹 𝗣𝗿𝗼𝗷𝗲𝗰𝘁

പല ലൈബ്രറി നിർമ്മാതാക്കളും ഒരു തെറ്റ് വരുത്താറുണ്ട്. ഉദാഹരണങ്ങൾ (examples) മാത്രം മതിയാകുമെന്ന് അവർ കരുതുന്നു.

ഉദാഹരണങ്ങൾ മാത്രം മതിയാകില്ല.

ഒരു ഫീച്ചർ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉദാഹരണങ്ങൾ തെളിയിക്കുന്നു. എന്നാൽ ഒരു ലൈബ്രറി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് തെളിയിക്കുന്നത് യഥാർത്ഥ പ്രോജക്റ്റുകളാണ്. ഇവ രണ്ടും രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്.

ഞാൻ ധാരാളം ഡെമോ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കാറുണ്ട്. സാമ്പിൾ വെബ്‌സൈറ്റുകൾ, APIs, കോംപോണന്റുകൾ എന്നിവ ഞാൻ നിർമ്മിക്കുന്നു. ഒരു ഡെമോയിൽ എല്ലാം തികഞ്ഞതായി തോന്നും. ഡെമോകൾ കാണിച്ചുതരുന്നത് ഏറ്റവും സുഗമമായ പാതയാണ് (happy path). അവ ആദർശമായ ഒരു പ്രവർത്തനരീതിയാണ് (ideal workflow) കാണിക്കുന്നത്.

ഡെമോകൾ നിയന്ത്രിത സാഹചര്യങ്ങളാണ്. അവയുടെ ആർക്കിടെക്ചർ ലളിതമാണ്. ആവശ്യകതകൾ (requirements) മുൻകൂട്ടി പ്രവചിക്കാവുന്നതാണ്.

യഥാർത്ഥ പ്രോജക്റ്റുകൾ വ്യത്യസ്തമാണ്.

ഒരു യഥാർത്ഥ പ്രോജക്റ്റിനായി നിങ്ങൾ ഒരു ലൈബ്രറി ഉപയോഗിക്കുമ്പോൾ നിയമങ്ങൾ മാറുന്നു. നിങ്ങൾ വെറുമൊരു പ്രദർശനമല്ല നടത്തുന്നത്, മറിച്ച് ഒരു പ്രശ്നപരിഹാരമാണ് നടത്തുന്നത്.

യഥാർത്ഥ പ്രോജക്റ്റുകൾ ഇവ കൊണ്ടുവരുന്നു:

  • കടുത്ത സമയപരിധികൾ (Tight deadlines)
  • മാറിക്കൊണ്ടിരിക്കുന്ന ആവശ്യകതകൾ (Changing requirements)
  • സങ്കീർണ്ണമായ ലേഔട്ടുകൾ (Complex layouts)
  • എഡ്ജ് കേസുകൾ (Edge cases)
  • മനുഷ്യസഹജമായ തെറ്റുകൾ (Human mistakes)

ഇവിടെയാണ് ഒരു ലൈബ്രറി അതിന്റെ യഥാർത്ഥ കരുത്ത് കാണിക്കുന്നത്. അതിന്റെ യഥാർത്ഥ ബലഹീനതയും ഇവിടെ വെളിപ്പെടുന്നു. ഒരു ഡെമോയിലല്ല, മറിച്ച് സമ്മർദ്ദഘട്ടങ്ങളിലാണ് ഒരു ലൈബ്രറി അതിന്റെ സ്വഭാവം വെളിപ്പെടുത്തുന്നത്.

യഥാർത്ഥ പ്രോജക്റ്റുകൾ നിങ്ങളുടെ അനുമാനങ്ങളെ (assumptions) വെളിപ്പെടുത്തുന്നു. ഒരു ആശയം കടലാസിൽ കാണാൻ മനോഹരമായിരിക്കാം. വികസന ഘട്ടത്തിൽ (development) അത് യുക്തിസഹമായി തോന്നാം. എന്നാൽ യാഥാർത്ഥ്യം മുന്നിലെത്തുമ്പോൾ കാര്യങ്ങൾ മാറും.

ഒരു വർക്ക്ഫ്ലോ (workflow) അസ്വാഭാവികമായി തോന്നാം. ഒരു കോൺഫിഗറേഷൻ (configuration) ആവർത്തനസ്വഭാവമുള്ളതായി തോന്നാം. ഒരു API സ്വാഭാവികമല്ലാതാകാം. നിങ്ങളുടെ ഡിസൈൻ തെറ്റല്ല, പക്ഷേ അത് ഇതുവരെ യാഥാർത്ഥ്യവുമായി പൊരുത്തപ്പെട്ടിട്ടില്ല.

ഒരു നിർമ്മാതാവിന് ചെയ്യാൻ കഴിയുന്ന ഏറ്റവും നല്ല കാര്യം സ്വന്തം സോഫ്റ്റ്‌വെയറിന്റെ ഒരു ഉപയോക്താവ് (user) കൂടിയാവുക എന്നതാണ്. വെറുതെ ഡെമോകൾ മാത്രം നിർമ്മിക്കരുത്. നിങ്ങളുടെ ടൂളുകൾ ഉപയോഗിച്ച് വെബ്‌സൈറ്റുകളും ആപ്ലിക്കേഷനുകളും ബിസിനസ്സുകളും നിർമ്മിക്കുക. അവയെ ആശ്രയിക്കുക.

നിങ്ങൾ നിങ്ങളുടെ സോഫ്റ്റ്‌വെയറിനെ ആശ്രയിക്കുമ്പോൾ, നിങ്ങളുടെ കാഴ്ചപ്പാട് മാറുന്നു. നിങ്ങൾ ഒരു നിർമ്മാതാവിനെപ്പോലെ ചിന്തിക്കുന്നത് നിർത്തുകയും ഒരു ഉപയോക്താവിനെപ്പോലെ ചിന്തിക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു.

ഉപയോക്താക്കൾ ശ്രദ്ധിക്കുന്നത് ഇവയാണ്:

  • തടസ്സങ്ങൾ (Friction)
  • വ്യക്തത (Clarity)
  • ജോലികൾ പൂർത്തിയാക്കുക (Getting work done)

യഥാർത്ഥ കാര്യങ്ങൾ നിർമ്മിക്കുന്നത് നിങ്ങളുടെ ചോദ്യങ്ങളെ മാറ്റുന്നു. "നമ്മൾ എന്തൊക്കെ ഫീച്ചറുകൾ കൂട്ടിച്ചേർക്കണം?" എന്ന് നിങ്ങൾ ചോദിക്കുന്നത് നിർത്തുന്നു. പകരം നിങ്ങൾ ചോദിക്കുന്നത്:

  • എന്തുകൊണ്ടാണ് ഈ വർക്ക്ഫ്ലോ അസ്വാഭാവികമായി തോന്നുന്നത്?
  • എന്തുകൊണ്ടാണ് ഞാൻ ഒരേ കാര്യം ആവർത്തിക്കുന്നത്?
  • എന്തുകൊണ്ടാണ് ഇതിന് ഇത്രയധികം സമയം എടുത്തത്?

ഇത്തരം പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നത് ഏതൊരു ബ്രെയിൻസ്റ്റോമിംഗ് സെഷനേക്കാളും മികച്ച സോഫ്റ്റ്‌വെയർ സൃഷ്ടിക്കാൻ സഹായിക്കുന്നു.

ഓരോ ലൈബ്രറിക്കും ഒരു യഥാർത്ഥ പ്രോജക്റ്റ് ആവശ്യമാണ്. ഈ പ്രോജക്റ്റ് മാർക്കറ്റിംഗിന് വേണ്ടിയുള്ളതല്ല. ഇതൊരു പരീക്ഷണശാലയാണ്. യഥാർത്ഥ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഇത് ലൈബ്രറിയെ നിർബന്ധിക്കുന്നു. നിങ്ങളുടെ ഉപയോക്താക്കൾ കണ്ടെത്തുന്നതിന് മുമ്പ് തന്നെ ഇത് ബലഹീനതകൾ കണ്ടെത്തുന്നു.

നിങ്ങളുടെ ലൈബ്രറി തികഞ്ഞതാണെന്ന് തെളിയിക്കുക എന്നതല്ല ലക്ഷ്യം. മറിച്ച്, നിങ്ങളുടെ ലൈബ്രറിയെ മെച്ചപ്പെടുത്താനുള്ള ഒരു വഴി സൃഷ്ടിക്കുക എന്നതാണ് ലക്ഷ്യം.

Source: https://dev.to/stinklewinks/why-every-library-needs-a-real-project-1ae7