നിങ്ങൾക്ക് മനസ്സിലാകാത്ത എന്തെങ്കിലും വികസിപ്പിക്കാൻ സമ്മതിക്കരുത്

2018-ന്റെ തുടക്കം മുതൽ, ഞാൻ ടീമിലെ ലീഡ്/ബോസ്/ലീഡ് ഡെവലപ്പർ സ്ഥാനം വഹിക്കുന്നു - നിങ്ങൾക്കാവശ്യമുള്ളത് അതിനെ വിളിക്കൂ, എന്നാൽ മൊഡ്യൂളുകളിൽ ഒന്നിന്റെയും ജോലി ചെയ്യുന്ന എല്ലാ ഡെവലപ്പർമാരുടെയും പൂർണ ഉത്തരവാദിത്തം എനിക്കാണ് എന്നതാണ്. അതിൽ. ഞാൻ കൂടുതൽ പ്രോജക്ടുകളിൽ ഏർപ്പെട്ടിരിക്കുന്നതിനാലും തീരുമാനങ്ങൾ എടുക്കുന്നതിൽ കൂടുതൽ സജീവമായി ഏർപ്പെട്ടിരിക്കുന്നതിനാലും ഈ സ്ഥാനം എനിക്ക് വികസന പ്രക്രിയയിൽ ഒരു പുതിയ കാഴ്ചപ്പാട് നൽകുന്നു. അടുത്തിടെ, ഈ രണ്ട് സാഹചര്യങ്ങൾക്ക് നന്ദി, ധാരണയുടെ അളവ് കോഡിനെയും ആപ്ലിക്കേഷനെയും എത്രമാത്രം ബാധിക്കുന്നുവെന്ന് എനിക്ക് പെട്ടെന്ന് മനസ്സിലായി.

ഞാൻ പറയാൻ ആഗ്രഹിക്കുന്ന കാര്യം, കോഡിന്റെ ഗുണനിലവാരവും (അവസാന ഉൽപ്പന്നവും) കോഡ് രൂപകൽപ്പന ചെയ്യുകയും എഴുതുകയും ചെയ്യുന്ന ആളുകൾ അവർ ചെയ്യുന്ന കാര്യങ്ങളെക്കുറിച്ച് എത്രമാത്രം ബോധവാന്മാരാണ് എന്നതുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു എന്നതാണ്.

നിങ്ങൾ ഇപ്പോൾ ചിന്തിക്കുന്നുണ്ടാകാം, "നന്ദി, ക്യാപ്. തീർച്ചയായും, നിങ്ങൾ പൊതുവായി എന്താണ് എഴുതുന്നതെന്ന് മനസ്സിലാക്കുന്നത് നന്നായിരിക്കും. അല്ലാത്തപക്ഷം, നിങ്ങൾ ഒരു കൂട്ടം കുരങ്ങുകളെ വാടകയ്‌ക്കെടുക്കുകയും അനിയന്ത്രിതമായ കീകൾ അടിച്ച് അത് ഉപേക്ഷിക്കുകയും ചെയ്യാം. കൂടാതെ താങ്കൾ പറഞ്ഞത് തികച്ചും ശരിയാണ്. അതനുസരിച്ച്, നിങ്ങൾ എന്താണ് ചെയ്യുന്നതെന്ന് പൊതുവായ ഒരു ധാരണ ആവശ്യമാണെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നത് ഞാൻ നിസ്സാരമായി കാണുന്നു. ഇതിനെ ധാരണയുടെ പൂജ്യം ലെവൽ എന്ന് വിളിക്കാം, ഞങ്ങൾ ഇത് വിശദമായി വിശകലനം ചെയ്യുന്നില്ല. നിങ്ങൾ കൃത്യമായി എന്താണ് മനസ്സിലാക്കേണ്ടതെന്നും അത് നിങ്ങൾ ദിവസവും എടുക്കുന്ന തീരുമാനങ്ങളെ എങ്ങനെ ബാധിക്കുന്നുവെന്നും ഞങ്ങൾ വിശദമായി പരിശോധിക്കും. ഈ കാര്യങ്ങൾ ഞാൻ മുൻകൂട്ടി അറിഞ്ഞിരുന്നെങ്കിൽ, അത് എനിക്ക് പാഴായ സമയവും സംശയാസ്പദമായ കോഡും ലാഭിക്കുമായിരുന്നു.

നിങ്ങൾ താഴെ കോഡിന്റെ ഒരു വരി പോലും കാണില്ലെങ്കിലും, ഉയർന്ന നിലവാരമുള്ളതും പ്രകടിപ്പിക്കുന്നതുമായ കോഡ് എഴുതുന്നതിന് ഇവിടെ പറഞ്ഞിരിക്കുന്ന എല്ലാത്തിനും വലിയ പ്രാധാന്യമുണ്ടെന്ന് ഞാൻ ഇപ്പോഴും വിശ്വസിക്കുന്നു.

ധാരണയുടെ ആദ്യ തലം: എന്തുകൊണ്ട് ഇത് പ്രവർത്തിക്കുന്നില്ല?

ഡെവലപ്പർമാർ സാധാരണയായി അവരുടെ കരിയറിന്റെ തുടക്കത്തിൽ തന്നെ ഈ നിലയിലെത്തുന്നു, ചിലപ്പോൾ മറ്റുള്ളവരുടെ സഹായമില്ലാതെ പോലും - കുറഞ്ഞത് എന്റെ അനുഭവത്തിലെങ്കിലും. നിങ്ങൾക്ക് ഒരു ബഗ് റിപ്പോർട്ട് ലഭിച്ചുവെന്ന് സങ്കൽപ്പിക്കുക: അപ്ലിക്കേഷനിലെ ചില പ്രവർത്തനങ്ങൾ പ്രവർത്തിക്കുന്നില്ല, അത് പരിഹരിക്കേണ്ടതുണ്ട്. നിങ്ങൾ എങ്ങനെ മുന്നോട്ട് പോകും?

സ്റ്റാൻഡേർഡ് സ്കീം ഇതുപോലെ കാണപ്പെടുന്നു:

1. പ്രശ്‌നമുണ്ടാക്കുന്ന കോഡിന്റെ ഭാഗം കണ്ടെത്തുക (ഇത് എങ്ങനെ ചെയ്യാം എന്നത് ഒരു പ്രത്യേക വിഷയമാണ്, ലെഗസി കോഡിനെക്കുറിച്ചുള്ള എന്റെ പുസ്തകത്തിൽ ഞാൻ അത് കവർ ചെയ്യുന്നു)
2. ഈ സ്‌നിപ്പറ്റിൽ മാറ്റങ്ങൾ വരുത്തുക
3. ബഗ് പരിഹരിച്ചിട്ടുണ്ടെന്നും റിഗ്രഷൻ പിശകുകളൊന്നും സംഭവിച്ചിട്ടില്ലെന്നും ഉറപ്പാക്കുക

ഇനി നമുക്ക് രണ്ടാമത്തെ പോയിന്റിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം - കോഡിൽ മാറ്റങ്ങൾ വരുത്തുക. ഈ പ്രക്രിയയ്ക്ക് രണ്ട് സമീപനങ്ങളുണ്ട്. ആദ്യത്തേത് നിലവിലെ കോഡിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് പരിശോധിക്കുകയും പിശക് തിരിച്ചറിയുകയും അത് പരിഹരിക്കുകയും ചെയ്യുക എന്നതാണ്. രണ്ടാമത്തേത്: തോന്നലിലൂടെ നീങ്ങുക - ഒരു സോപാധിക പ്രസ്താവനയിലേക്കോ ലൂപ്പിലേക്കോ ചേർക്കുക, പറയുക, +1, ആവശ്യമുള്ള സാഹചര്യത്തിൽ ഫംഗ്ഷൻ പ്രവർത്തിക്കുന്നുണ്ടോയെന്ന് കാണുക, തുടർന്ന് മറ്റെന്തെങ്കിലും പരീക്ഷിക്കുക, അങ്ങനെ പരസ്യം അനന്തമായി.

ആദ്യത്തെ സമീപനം ശരിയാണ്. സ്റ്റീവ് മക്കോണൽ തന്റെ കോഡ് കംപ്ലീറ്റ് എന്ന പുസ്‌തകത്തിൽ വിശദീകരിക്കുന്നതുപോലെ (ഇത് ഞാൻ വളരെ ശുപാർശ ചെയ്യുന്നു), ഓരോ തവണയും ഞങ്ങൾ കോഡിൽ എന്തെങ്കിലും മാറ്റുമ്പോൾ, അത് ആപ്ലിക്കേഷനെ എങ്ങനെ ബാധിക്കുമെന്ന് നമുക്ക് ആത്മവിശ്വാസത്തോടെ പ്രവചിക്കാൻ കഴിയണം. ഞാൻ മെമ്മറിയിൽ നിന്ന് ഉദ്ധരിക്കുന്നു, പക്ഷേ നിങ്ങൾ പ്രതീക്ഷിച്ച രീതിയിൽ ഒരു ബഗ്ഫിക്സ് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾ വളരെ പരിഭ്രാന്തരാകുകയും നിങ്ങളുടെ മുഴുവൻ പ്രവർത്തന പദ്ധതിയും ചോദ്യം ചെയ്യുകയും വേണം.

പറഞ്ഞ കാര്യങ്ങൾ സംഗ്രഹിക്കുന്നതിന്, കോഡിന്റെ ഗുണനിലവാരം കുറയ്ക്കാത്ത ഒരു നല്ല ബഗ് പരിഹരിക്കുന്നതിന്, കോഡിന്റെ മുഴുവൻ ഘടനയും നിർദ്ദിഷ്ട പ്രശ്നത്തിന്റെ ഉറവിടവും നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്.

ധാരണയുടെ രണ്ടാം തലം: എന്തുകൊണ്ടാണ് ഇത് പ്രവർത്തിക്കുന്നത്?

ഈ ലെവൽ മുമ്പത്തേതിനേക്കാൾ വളരെ കുറച്ച് അവബോധപൂർവ്വം മനസ്സിലാക്കുന്നു. ഞാൻ, ഒരു തുടക്കക്കാരനായ ഡെവലപ്പറായിരിക്കുമ്പോൾ, എന്റെ ബോസിന് നന്ദി പറഞ്ഞുകൊണ്ട് അത് പഠിച്ചു, തുടർന്ന് പുതുമുഖങ്ങൾക്ക് കാര്യത്തിന്റെ സാരാംശം ആവർത്തിച്ച് വിശദീകരിച്ചു.

ഈ സമയം, നിങ്ങൾക്ക് ഒരേസമയം രണ്ട് ബഗ് റിപ്പോർട്ടുകൾ ലഭിച്ചുവെന്ന് സങ്കൽപ്പിക്കുക: ആദ്യത്തേത് സാഹചര്യം എയെക്കുറിച്ചാണ്, രണ്ടാമത്തേത് സിനാരിയോ ബിയെക്കുറിച്ചാണ്. രണ്ട് സാഹചര്യങ്ങളിലും എന്തെങ്കിലും തെറ്റ് സംഭവിക്കുന്നു. അതനുസരിച്ച്, നിങ്ങൾ ആദ്യം ആദ്യത്തെ ബഗ് കൈകാര്യം ചെയ്യുക. ലെവൽ XNUMX മനസ്സിലാക്കുന്നതിനായി ഞങ്ങൾ വികസിപ്പിച്ച തത്ത്വങ്ങൾ ഉപയോഗിച്ച്, പ്രശ്‌നവുമായി ബന്ധപ്പെട്ട കോഡിലേക്ക് നിങ്ങൾ ആഴത്തിൽ കുഴിച്ചിടുക, സിനാരിയോ എ-യിൽ ആപ്ലിക്കേഷൻ പെരുമാറുന്ന രീതിയിൽ പ്രവർത്തിക്കാൻ ഇത് കാരണമാക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് കണ്ടെത്തുകയും നിങ്ങൾ ആഗ്രഹിക്കുന്ന ഫലം നൽകുന്ന ന്യായമായ ക്രമീകരണങ്ങൾ നടത്തുകയും ചെയ്യുക. . എല്ലാം നന്നായി പോകുന്നു.

തുടർന്ന് നിങ്ങൾ ബി സിനാരിയോയിലേക്ക് നീങ്ങുന്നു. ഒരു പിശക് പ്രകോപിപ്പിക്കാനുള്ള ശ്രമത്തിൽ നിങ്ങൾ രംഗം ആവർത്തിക്കുന്നു, പക്ഷേ-ആശ്ചര്യം! - ഇപ്പോൾ എല്ലാം ചെയ്യേണ്ടതുപോലെ പ്രവർത്തിക്കുന്നു. നിങ്ങളുടെ ഊഹം സ്ഥിരീകരിക്കാൻ, ബഗ് എയിൽ പ്രവർത്തിക്കുന്ന സമയത്ത് നിങ്ങൾ വരുത്തിയ മാറ്റങ്ങൾ നിങ്ങൾ പഴയപടിയാക്കുകയും ബഗ് ബി തിരികെ വരികയും ചെയ്യും. നിങ്ങളുടെ ബഗ്ഫിക്സ് രണ്ട് പ്രശ്നങ്ങളും പരിഹരിച്ചു. ഭാഗ്യം!

നിങ്ങൾ ഇതൊന്നും കണക്കിലെടുത്തില്ല. സാഹചര്യം A-യിലെ പിശക് പരിഹരിക്കാനുള്ള ഒരു മാർഗം നിങ്ങൾ കണ്ടുപിടിച്ചു, അത് എന്തുകൊണ്ട് ബി സിനാരിയോയിൽ പ്രവർത്തിച്ചുവെന്ന് അറിയില്ല. ഈ ഘട്ടത്തിൽ, രണ്ട് ജോലികളും വിജയകരമായി പൂർത്തിയാക്കി എന്ന് ചിന്തിക്കുന്നത് വളരെ പ്രലോഭനകരമാണ്. ഇത് തികച്ചും യുക്തിസഹമാണ്: പിശകുകൾ ഇല്ലാതാക്കുക എന്നതായിരുന്നു പോയിന്റ്, അല്ലേ? എന്നാൽ ജോലി ഇതുവരെ പൂർത്തിയായിട്ടില്ല: നിങ്ങളുടെ പ്രവർത്തനങ്ങൾ എന്തുകൊണ്ടാണ് ബി സിനറിയോയിലെ പിശക് തിരുത്തിയതെന്ന് നിങ്ങൾ ഇപ്പോഴും കണ്ടെത്തേണ്ടതുണ്ട്. എന്തുകൊണ്ട്? കാരണം അത് തെറ്റായ തത്വങ്ങളിൽ പ്രവർത്തിക്കുന്നുണ്ടാകാം, അപ്പോൾ നിങ്ങൾ മറ്റൊരു വഴി തേടേണ്ടിവരും. അത്തരം കേസുകളുടെ രണ്ട് ഉദാഹരണങ്ങൾ ഇതാ:

• എല്ലാ ഘടകങ്ങളും കണക്കിലെടുത്ത്, പിശക് B- ന് അനുയോജ്യമായ പരിഹാരം അല്ലാത്തതിനാൽ, നിങ്ങൾ അറിയാതെ C എന്ന പ്രവർത്തനം തകർന്നിരിക്കാം.
• ഒരേ ഫംഗ്‌ഷനുമായി ബന്ധപ്പെട്ട് എവിടെയെങ്കിലും മൂന്നാമതൊരു ബഗ് ഒളിഞ്ഞിരിക്കാൻ സാധ്യതയുണ്ട്, കൂടാതെ B സാഹചര്യത്തിൽ സിസ്റ്റത്തിന്റെ ശരിയായ പ്രവർത്തനത്തിനായി നിങ്ങളുടെ ബഗ്ഫിക്‌സ് അതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഇപ്പോൾ എല്ലാം നന്നായി തോന്നുന്നു, പക്ഷേ ഒരു ദിവസം ഈ മൂന്നാമത്തെ ബഗ് ശ്രദ്ധിക്കപ്പെടുകയും പരിഹരിക്കപ്പെടുകയും ചെയ്യും. അപ്പോൾ ബി സാഹചര്യത്തിൽ പിശക് വീണ്ടും സംഭവിക്കും, അവിടെ മാത്രം ഉണ്ടെങ്കിൽ അത് നല്ലതാണ്.

ഇതെല്ലാം കോഡിൽ കുഴപ്പങ്ങൾ കൂട്ടിച്ചേർക്കുകയും ഒരു ദിവസം നിങ്ങളുടെ തലയിൽ വീഴുകയും ചെയ്യും - മിക്കവാറും ഏറ്റവും അനുയോജ്യമല്ലാത്ത നിമിഷത്തിൽ. എല്ലാം പ്രവർത്തിക്കുന്നതായി തോന്നുന്നത് എന്തുകൊണ്ടാണെന്ന് മനസിലാക്കാൻ സമയം ചെലവഴിക്കാൻ നിങ്ങളെ നിർബന്ധിക്കാൻ നിങ്ങളുടെ ഇച്ഛാശക്തി ശേഖരിക്കേണ്ടതുണ്ട്, പക്ഷേ അത് വിലമതിക്കുന്നു.

ധാരണയുടെ മൂന്നാം തലം: എന്തുകൊണ്ടാണ് ഇത് പ്രവർത്തിക്കുന്നത്?

എന്റെ സമീപകാല സ്ഥിതിവിവരക്കണക്ക് ഈ തലവുമായി കൃത്യമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, ഞാൻ ഈ ആശയത്തിലേക്ക് നേരത്തെ വന്നിരുന്നെങ്കിൽ ഒരുപക്ഷേ എനിക്ക് ഏറ്റവും കൂടുതൽ പ്രയോജനം ലഭിക്കുമായിരുന്നു.

ഇത് കൂടുതൽ വ്യക്തമാക്കുന്നതിന്, നമുക്ക് ഒരു ഉദാഹരണം നോക്കാം: നിങ്ങളുടെ മൊഡ്യൂൾ ഫംഗ്‌ഷൻ X-ന് അനുയോജ്യമാക്കേണ്ടതുണ്ട്. നിങ്ങൾക്ക് ഫംഗ്‌ഷൻ X-മായി പ്രത്യേകിച്ച് പരിചിതമല്ല, പക്ഷേ അതിനോട് പൊരുത്തപ്പെടുന്നതിന് നിങ്ങൾ F ഫ്രെയിംവർക്ക് ഉപയോഗിക്കണമെന്ന് നിങ്ങളോട് പറഞ്ഞു. X-മായി സംയോജിപ്പിക്കുന്ന മൊഡ്യൂളുകൾ അവനുമായി കൃത്യമായി പ്രവർത്തിക്കുന്നു.

നിങ്ങളുടെ കോഡിന്റെ ജീവിതത്തിന്റെ ആദ്യ ദിവസം മുതൽ എഫ് ചട്ടക്കൂടുമായി യാതൊരു ബന്ധവുമില്ല, അതിനാൽ അത് നടപ്പിലാക്കുന്നത് അത്ര എളുപ്പമായിരിക്കില്ല. ഇത് മൊഡ്യൂളിന്റെ ചില ഭാഗങ്ങളിൽ ഗുരുതരമായ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കും. എന്നിരുന്നാലും, നിങ്ങൾ സ്വയം വികസനത്തിലേക്ക് തിരിയുന്നു: കോഡ് എഴുതുക, പരിശോധന നടത്തുക, പൈലറ്റ് പതിപ്പുകൾ പുറത്തിറക്കുക, ഫീഡ്‌ബാക്ക് നേടുക, റിഗ്രഷൻ പിശകുകൾ പരിഹരിക്കുക, അപ്രതീക്ഷിതമായ സങ്കീർണതകൾ കണ്ടെത്തുക, യഥാർത്ഥത്തിൽ സമ്മതിച്ച സമയപരിധി പാലിക്കാതിരിക്കുക, കൂടുതൽ കോഡ് എഴുതുക, പരിശോധന നടത്തുക, ഫീഡ്‌ബാക്ക് ആശയവിനിമയം നടത്തുക, റിഗ്രഷൻ പിശകുകൾ ശരിയാക്കുന്നു - എഫ് ചട്ടക്കൂട് നടപ്പിലാക്കുന്നതിനായി ഇതെല്ലാം.

ഒരു ഘട്ടത്തിൽ, നിങ്ങൾ പെട്ടെന്ന് മനസ്സിലാക്കുന്നു - അല്ലെങ്കിൽ ആരിൽ നിന്ന് കേൾക്കാം - ഒരുപക്ഷെ ഫ്രെയിംവർക്ക് എഫ് നിങ്ങൾക്ക് ഫീച്ചർ X മായി ഒരു തരത്തിലും അനുയോജ്യത നൽകില്ല എന്ന്. ഒരുപക്ഷേ ആ സമയവും പ്രയത്നവും അതിനായി പൂർണ്ണമായും തെറ്റായി ചെലവഴിച്ചിരിക്കാം.

ഒരിക്കൽ ഞാൻ ഉത്തരവാദിയായ ഒരു പ്രൊജക്‌റ്റിൽ ജോലി ചെയ്യുമ്പോൾ സമാനമായ ചിലത് സംഭവിച്ചു. എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചത്? കാരണം, X ഫംഗ്‌ഷൻ എന്താണെന്നും അത് Framework F-മായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്നും എനിക്ക് വേണ്ടത്ര ധാരണയില്ലായിരുന്നു. ഞാൻ എന്താണ് ചെയ്യേണ്ടത്? മറ്റ് മൊഡ്യൂളുകൾക്കായി ചെയ്‌തത് ആവർത്തിക്കുന്നതിനോ അല്ലെങ്കിൽ X ഫീച്ചർ ചെയ്യേണ്ടത് ഇതാണ് എന്ന അവരുടെ വാക്ക് എടുക്കുന്നതിനോ പകരം, ഉദ്ദേശിച്ച പ്രവർത്തനരീതി എങ്ങനെയാണ് ആവശ്യമുള്ള ഫലത്തിലേക്ക് നയിക്കുന്നതെന്ന് വ്യക്തമായി വിശദീകരിക്കാൻ വികസന ചുമതല ഏൽപ്പിക്കുന്ന വ്യക്തിയോട് ആവശ്യപ്പെടുക.

ഈ പ്രോജക്റ്റിന്റെ അനുഭവം, എന്തുകൊണ്ടാണ് ചില കാര്യങ്ങൾ ചെയ്യാൻ ഞങ്ങളോട് ആവശ്യപ്പെടുന്നത് എന്നതിനെക്കുറിച്ച് വ്യക്തമായ ധാരണ ലഭിക്കുന്നതുവരെ വികസന പ്രക്രിയ ആരംഭിക്കാൻ വിസമ്മതിക്കാൻ എന്നെ പഠിപ്പിച്ചു. പൂർണ്ണമായും നിരസിക്കുക. നിങ്ങൾക്ക് ഒരു ടാസ്ക് ലഭിക്കുമ്പോൾ, സമയം പാഴാക്കാതിരിക്കാൻ അത് ഉടനടി ഏറ്റെടുക്കുക എന്നതാണ് ആദ്യത്തെ പ്രേരണ. എന്നാൽ “ഞങ്ങൾ എല്ലാ വിശദാംശങ്ങളിലേക്കും കടക്കുന്നതുവരെ പ്രോജക്റ്റ് മരവിപ്പിക്കുക” എന്ന നയത്തിന് വലിയ ക്രമങ്ങളാൽ പാഴായ സമയം കുറയ്ക്കാൻ കഴിയും.

അവർ നിങ്ങളുടെ മേൽ സമ്മർദ്ദം ചെലുത്താൻ ശ്രമിച്ചാലും, ജോലി ആരംഭിക്കാൻ നിങ്ങളെ നിർബന്ധിക്കാൻ, ഇതിന്റെ യുക്തി നിങ്ങൾക്ക് മനസ്സിലായില്ലെങ്കിലും, ചെറുത്തുനിൽക്കുക. ആദ്യം, എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് അത്തരമൊരു ടാസ്ക് നൽകുന്നത് എന്ന് മനസിലാക്കുക, ഇത് ലക്ഷ്യത്തിലേക്കുള്ള ശരിയായ പാതയാണോ എന്ന് തീരുമാനിക്കുക. എനിക്ക് ഇതെല്ലാം കഠിനമായി പഠിക്കേണ്ടിവന്നു - എന്റെ ഉദാഹരണം ഇത് വായിക്കുന്നവർക്ക് ജീവിതം എളുപ്പമാക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

ധാരണയുടെ നാലാമത്തെ തലം: ???

പ്രോഗ്രാമിംഗിൽ എല്ലായ്‌പ്പോഴും കൂടുതൽ പഠിക്കാനുണ്ട്, മനസ്സിലാക്കാനുള്ള വിഷയത്തിന്റെ ഉപരിതലം മാത്രമാണ് ഞാൻ സ്‌ക്രാച്ച് ചെയ്‌തതെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. കോഡുമായി പ്രവർത്തിച്ച വർഷങ്ങളിൽ നിങ്ങൾ മറ്റ് ഏത് തലത്തിലുള്ള ധാരണകളാണ് കണ്ടെത്തിയത്? കോഡിന്റെയും ആപ്ലിക്കേഷന്റെയും ഗുണനിലവാരത്തിൽ നല്ല സ്വാധീനം ചെലുത്തിയ എന്ത് തീരുമാനങ്ങളാണ് നിങ്ങൾ എടുത്തത്? ഏത് തീരുമാനങ്ങളാണ് തെറ്റായി മാറുകയും നിങ്ങളെ വിലപ്പെട്ട ഒരു പാഠം പഠിപ്പിക്കുകയും ചെയ്തത്? അഭിപ്രായങ്ങളിൽ നിങ്ങളുടെ അനുഭവം പങ്കിടുക.

അവലംബം: www.habr.com