ජාල ඉංජිනේරුවෙකුගේ යථාර්ථය (නූඩ්ල්ස් සහ... ලුණු සමඟ?)
මෑතකදී, ඉංජිනේරුවන් සමඟ විවිධ සිදුවීම් සාකච්ඡා කරන විට, මම සිත්ගන්නා රටාවක් දුටුවෙමි.
මෙම සාකච්ඡා වලදී, "මූල හේතුව" යන ප්රශ්නය නොවරදවාම මතු වේ. විශ්වාසවන්ත පාඨකයන් මා සතුව ඇති බව දන්නවා ඇති මත . බොහෝ සංවිධානවල, සිදුවීම් විශ්ලේෂණය සම්පූර්ණයෙන්ම මෙම සංකල්පය මත පදනම් වේ. ඔවුන් හේතු-ඵල සම්බන්ධතා හඳුනා ගැනීම සඳහා විවිධ ශිල්පීය ක්‍රම භාවිතා කරයි . මෙම ක්‍රම ඊනියා "සිදුවීම්වල රේඛීයත්වය" අවිවාදිත ප්‍රවාදයක් ලෙස උපකල්පනය කරයි.
ඔබ මෙම අදහස අභියෝගයට ලක් කරන විට සහ සංකීර්ණ පද්ධති තුළ රේඛීයත්වය සහනදායී ලෙස රැවටිලිකාර බව පෙන්වා දෙන විට, සිත් ඇදගන්නාසුළු සාකච්ඡාවක් උපදී. "මූල හේතුව" පිළිබඳ දැනුම පමණක් අපට සිදුවන්නේ කුමක්ද යන්න තේරුම් ගැනීමට ඉඩ සලසන බව ආරවුල් දැඩි ලෙස අවධාරනය කරයි.
මම සිත්ගන්නා රටාවක් දුටුවෙමි: සංවර්ධකයින් සහ devops මෙම අදහසට වෙනස් ලෙස ප්‍රතිචාර දක්වයි. මගේ අත්දැකීමට අනුව, සංවර්ධකයින් මූල හේතුව වැදගත් වන බවට තර්ක කිරීමට වැඩි ඉඩක් ඇති අතර සිදුවීම් වලදී හේතු-සහ-ඵල සම්බන්ධතා සැමවිටම ස්ථාපිත කළ හැකිය. අනෙක් අතට, සංකීර්ණ ලෝකයක් සෑම විටම රේඛීයත්වයට අවනත නොවන බව DevOps බොහෝ විට එකඟ වේ.
මම නිතරම කල්පනා කළේ ඇයි මේ? කුමක් ද කරයි ක්‍රමලේඛකයින් "මූල හේතුව මිථ්‍යාවක්" යන අදහස විවේචනය කිරීමටද? විදේශීය නියෝජිතයෙකු හඳුනා ගන්නා ප්රතිශක්තිකරණ පද්ධතියක් වැනි. devops කරන අතරතුර ඔවුන් මේ ආකාරයෙන් ප්‍රතිචාර දක්වන්නේ ඇයි වෙනුවට නැඹුරු මෙම අදහස සලකා බලන්න
මට සම්පූර්ණයෙන්ම විශ්වාස නැත, නමුත් මට මේ ගැන අදහස් කිහිපයක් තිබේ. එය මෙම වෘත්තිකයන් ඔවුන්ගේ දෛනික වැඩ කටයුතු කරගෙන යන විවිධ සන්දර්භයන්ට අදාළ වේ.
සංවර්ධකයින් බොහෝ විට තීරණාත්මක මෙවලම් සමඟ වැඩ කරයි. ඇත්ත වශයෙන්ම, සම්පාදක, සම්බන්ධක, මෙහෙයුම් පද්ධති - මේ සියල්ල සංකීර්ණ පද්ධති වේ, නමුත් ඒවා නියත ප්‍රතිපලයක් ලබා දෙන බවට අපි පුරුදු වී සිටිමු, අපි ඒවා නියතිවාදී යැයි සිතමු: අපි එකම ආදාන දත්ත ලබා දෙන්නේ නම්, අපි සාමාන්‍යයෙන් අපේක්ෂා කරන්නේ මෙම පද්ධති වලින් එකම ප්රතිදානය . ප්රතිදානය ("දෝෂය") සමඟ ගැටළුවක් තිබේ නම්, සංවර්ධකයින් විසින් ආදාන දත්ත විශ්ලේෂණය කිරීමෙන් එය විසඳයි (පරිශීලකයාගෙන් හෝ සංවර්ධන ක්‍රියාවලියේදී මෙවලම් කට්ටලයකින්). ඔවුන් "දෝෂයක්" සොයමින් පසුව ආදාන දත්ත වෙනස් කරයි. මෙය "දෝෂය" නිවැරදි කරයි.
මෘදුකාංග සංවර්ධනයේ මූලික උපකල්පනය: එකම ආදාන දත්ත විශ්වසනීයව සහ නියත වශයෙන්ම එකම ප්රතිදානය නිපදවයි.
ඇත්ත වශයෙන්ම, නිර්ණය නොවන ප්‍රතිඵලයක්ම දෝෂයක් ලෙස සලකනු ලැබේ: අනපේක්ෂිත හෝ වැරදි ප්රතිදානය ප්‍රතිනිෂ්පාදනය නොකළහොත්, සංවර්ධකයින් විසින් පරීක්ෂණ තොගයේ අනෙකුත් කොටස් (මෙහෙයුම් පද්ධතිය, ජාලය, ආදිය) වෙත ව්‍යාප්ත කිරීමට නැඹුරු වේ. අඩු වැඩි වශයෙන් නියත වශයෙන්ම, එකම ආදාන දත්ත සමඟ එකම ප්‍රතිඵලය නිපදවීම... සහ එය එසේ නොවේ නම්, එවිට මෙය තවමත් දෝෂයක් ලෙස සැලකේ. එය දැන් මෙහෙයුම් පද්ධතියක් හෝ ජාල දෝෂයකි.
ඕනෑම අවස්ථාවක, අධිෂ්ඨානවාදය යනු බොහෝ ක්‍රමලේඛකයින් විසින් කරන ලද මූලික, පාහේ අනුමත කළ උපකල්පනයකි.
නමුත් දෘඪාංග පිරිමැසීමට හෝ වලාකුළු API සොයා ගැනීමට දවස ගත කරන ඕනෑම devops පිරිමි ළමයෙකුට, සම්පූර්ණයෙන්ම නිර්ණායක ලෝකයක් පිළිබඳ අදහස (සියලු යෙදවුම් සිතියම්ගත කිරීමට පවා හැකි තාක්!) ඉතා කෙටි සංකල්පයකි. පැත්තකින් තිබ්බත් , පළපුරුදු ඉංජිනේරුවන් මේ ලෝකයේ අමුතුම දේවල් දැක ඇත. ඒක උන් දන්නවා , පරිසරයේ ඇති මිලියන ගණනක් වෙනත් සාධක ගැන සඳහන් නොකරන්න.
එබැවින් පළපුරුදු ඉංජිනේරුවන්ට සෑම සිදුවීමකටම එකම මූල හේතුවක් ඇති බවට සැක කිරීම පහසු වන අතර, "පහක් ඇයි" වැනි ශිල්පීය ක්‍රම නිවැරදිව (සහ නැවත නැවතත්!) එම මූල හේතුවට තුඩු දෙනු ඇත. ඇත්ත වශයෙන්ම, මෙය ඔවුන්ගේම අත්දැකීමට පටහැනියි, එහිදී ප්‍රහේලිකා කෑලි ප්‍රායෝගිකව එතරම් පිළිවෙලට නොගැලපේ. එමනිසා, ඔවුන් මෙම අදහස වඩාත් පහසුවෙන් පිළිගනී.
ඇත්ත වශයෙන්ම, මම සංවර්ධකයින් බොළඳ, මෝඩ, හෝ රේඛීයත්වය රැවටිලිකාර විය හැකි ආකාරය තේරුම් ගැනීමට නොහැකි බව නොකියමි.
නමුත් මෙම විවාදයන්හි සංවර්ධකයින්ගේ පොදු ප්‍රතික්‍රියාව බොහෝ විට නියතිවාදයේ සංකල්පයට සම්බන්ධ බව මට පෙනේ. සමස්තයක් වශයෙන් ඔවුන්ට හොඳින් සේවය කරයි එදිනෙදා වැඩවලදී. ඉංජිනේරුවන්ට ඔවුන්ගේ යටිතල ව්‍යුහය මත ෂ්‍රොඩිංගර්ගේ බළලුන් අල්ලා ගැනීමට සිදුවන බැවින් ඔවුන්ට නියත නිර්ණයවාදයක් හමු නොවේ.
මෙය නිරීක්ෂණය කරන ලද සංවර්ධක ප්‍රතික්‍රියා සම්පූර්ණයෙන් පැහැදිලි නොකරනු ඇත, නමුත් අපගේ ප්‍රතික්‍රියා බොහෝ සාධකවල සංකීර්ණ මිශ්‍රණයක් බව ප්‍රබල මතක් කිරීමකි.
අපි තනි සිදුවීමක් සමඟ කටයුතු කළත්, මෘදුකාංග බෙදා හැරීමේ නල මාර්ගයක් සමඟ සහයෝගයෙන් කටයුතු කළත්, හෝ පුළුල් ලෝකය පිළිබඳ හැඟීමක් ඇති කිරීමට උත්සාහ කළත්, මෙම සංකීර්ණත්වය මතක තබා ගැනීම වැදගත්ය.
මූලාශ්රය: www.habr.com