5 കമ്മിറ്റുകളിൽ ഒരു മുയൽ ദ്വാരം

ഒരു "ക്വിക്ക് ഫിക്‌സിൻ്റെ" വശീകരണ ലാളിത്യം

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

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

കമ്മിറ്റ് 1: ദി പോയിൻ്റ് ഓഫ് നോ റിട്ടേൺ

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

കമ്മിറ്റ് 2: ഡിപൻഡൻസി ത്രെഡ് അഴിക്കുന്നു

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

കമ്മിറ്റ് 3: ആർക്കിടെക്ചർ ടെംപ്റ്റേഷൻ

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

കമ്മിറ്റ് 4 & 5: ദി ഡൊമിനോ ഇഫക്റ്റ്

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

• പ്രാരംഭ ബഗ്: ഒരൊറ്റ തീയതി തെറ്റായി പ്രദർശിപ്പിച്ചിരിക്കുന്നു.
• അവസാന ഫലം: ഒരു പുതിയ DateService ക്ലാസ്, 4 വ്യത്യസ്‌ത മൊഡ്യൂളുകളിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ, കൂടാതെ 3 തകർന്ന ടെസ്റ്റ് സ്യൂട്ടുകൾക്കുള്ള പരിഹാരങ്ങൾ.
• ചെലവഴിച്ച സമയം: 1.5 മണിക്കൂറിന് പകരം 1.5 ദിവസം.
• കാണാത്ത ചിലവ്: കാലതാമസം നേരിടുന്ന ഫീച്ചറുകൾ, മുഴുവൻ ടീമിനുമുള്ള സന്ദർഭ സ്വിച്ചിംഗ്, ഇൻ്റഗ്രേഷൻ റിസ്കുകൾ.

"മുയൽ ദ്വാരം കഴിവില്ലായ്മയുടെ ലക്ഷണമല്ല; അതിരുകൾ വ്യക്തമല്ലാത്ത ഒരു സംവിധാനത്തിൻ്റെ ലക്ഷണമാണിത്. ഒരു ബിസിനസ് ഫംഗ്ഷനിലെ മാറ്റം മറ്റൊന്നിൻ്റെ പുനർനിർമ്മാണത്തിന് നിർബന്ധിതമാകാത്ത മോഡുലാരിറ്റിയിൽ നിന്നാണ് യഥാർത്ഥ കാര്യക്ഷമത വരുന്നത്."

മെവയ്‌സിനൊപ്പം ഗാർഡ്‌റെയിലുകൾ നിർമ്മിക്കുന്നു

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

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

പതിവ് ചോദിക്കുന്ന ചോദ്യങ്ങൾ

ഒരു "ക്വിക്ക് ഫിക്‌സിൻ്റെ" വശീകരണ ലാളിത്യം

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

കമ്മിറ്റ് 1: ദി പോയിൻ്റ് ഓഫ് നോ റിട്ടേൺ

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

കമ്മിറ്റ് 2: ഡിപൻഡൻസി ത്രെഡ് അഴിക്കുന്നു

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

കമ്മിറ്റ് 3: ആർക്കിടെക്ചർ ടെംപ്റ്റേഷൻ

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

കമ്മിറ്റ് 4 & 5: ദി ഡൊമിനോ ഇഫക്റ്റ്

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