මගේ ලොක්කා මගෙන් ඉල්ලා සිටින්නේ කුඩා කාර්යයන් ලිවීම නවතා සියල්ල එකම ලූපයකින් කරන්න

රොබට් සී. මාටින් විසින් ක්ලීන් කෝඩ් නමින් පොතක් කියවා ඇත්තෙමි . මෙම පොතේ කුඩා කාර්යයන් ලිවීම, නම් ප්‍රවේශමෙන් නම් තෝරා ගැනීම වැනි කේත පිරිසිදු කිරීමට බොහෝ ක්‍රම මම දැක ඇත්තෙමි. එය මා කියවා ඇති පිරිසිදු කේතය පිළිබඳ වඩාත්ම සිත්ගන්නා පොතකි. කෙසේ වෙතත්, අද මගේ ලොක්කා මෙම පොත කියවීමෙන් පසු මම කේත ලිවීමට කැමති නැත.

ඔහුගේ තර්ක විය

• කුඩා කාර්යයන් ලිවීම වේදනාවක් වන්නේ කේතය කරන්නේ කුමක්දැයි බැලීමට එක් එක් කුඩා ශ්‍රිතයට යාමට එය බල කරන බැවිනි.
• ප්‍රධාන ලූපය පේළි 300 ට වඩා වැඩි වුවද සෑම දෙයක්ම ප්‍රධාන විශාල පුඩුවක් තුළට දමන්න, එය කියවීමට වේගවත් වේ.
• ඔබට කේත අනුපිටපත් කිරීමට අවශ්‍ය නම් පමණක් කුඩා කාර්යයන් ලියන්න.
• විවරණයේ නම සමඟ ශ්‍රිතයක් ලියන්න එපා, ඉහත අදහස් දැක්වීම සමඟ ඔබේ සංකීර්ණ කේත රේඛාව (පේළි 3-4) තබන්න; ඒ හා සමානව ඔබට අසමත් වූ කේතය කෙලින්ම වෙනස් කළ හැකිය

මෙය මා කියවූ සියල්ලටම විරුද්ධ ය. ඔබ සාමාන්‍යයෙන් කේත ලියන්නේ කෙසේද? එක් ප්‍රධාන විශාල පුඩුවක්, කුඩා කාර්යයන් නොමැත?

මා භාවිතා කරන භාෂාව ප්‍රධාන වශයෙන් ජාවාස්ක්‍රිප්ට් ය. පැහැදිලිව නම් කර ඇති මගේ කුඩා කාර්යයන් මකා දමා සියල්ල විශාල ලූපයකට දමා ඇති බැවින් මට දැන් කියවීමට අපහසුය. කෙසේ වෙතත්, මගේ ලොක්කා මේ ආකාරයට කැමතියි.

එක් උදාහරණයක් නම්:

// The way I would write it
if (isApplicationInProduction(headers)) {
  phoneNumber = headers.resourceId;
} else {
  phoneNumber = DEV_PHONE_NUMBER;
}

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

// The way he would write it
// Take the right resourceId if application is in production
phoneNumber = headers.resourceId ? headers.resourceId : DEV_PHONE_NUMBER;

උදාහරණයක් ලෙස මා කියවා ඇති පොතේ අදහස් දැක්වීම් පිරිසිදු කේත ලිවීමට අපොහොසත් යැයි සලකනු ලබන්නේ ඔබ කුඩා කාර්යයන් ලියන්නේ නම් ඒවා යල්පැන ඇති අතර බොහෝ විට යාවත්කාලීන නොවන අදහස් වලට මග පාදයි (ඔබ ඔබේ කේතය වෙනස් කරන අතර අදහස් දැක්වීම නොවේ). කෙසේ වෙතත් මා කරන්නේ අදහස් දැක්වීම මකා දමා විවරණයේ නම සමඟ ශ්‍රිතයක් ලිවීමයි.

හොඳයි, මම යම් උපදෙසකට කැමතියි, පිරිසිදු කේත ලිවීමට වඩා හොඳ කුමන ක්‍රමය / පුහුණුවද?

කේත උදාහරණ පළමුව ගැනීම. ඔබ කැමති:

if (isApplicationInProduction(headers)) {
  phoneNumber = headers.resourceId;
} else {
  phoneNumber = DEV_PHONE_NUMBER;
}

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

ඔබේ ලොක්කා එය මෙසේ ලියයි:

// Take the right resourceId if application is in production
phoneNumber = headers.resourceId ? headers.resourceId : DEV_PHONE_NUMBER;

මගේ මතය අනුව, දෙදෙනාම ගැටළු ඇත. මම ඔබේ කේතය කියවන විට, මගේ ක්ෂණික සිතුවිල්ල වූයේ “ඔබට ifඑය ත්‍රික ප්‍රකාශනයකින් ප්‍රතිස්ථාපනය කළ හැකිය ” යන්නයි. එවිට මම ඔබේ ලොක්කාගේ කේතය කියවා "ඔහු ඔබේ ක්‍රියාකාරිත්වය විවරණයක් මගින් ප්‍රතිස්ථාපනය කළේ ඇයි?"

ප්‍රශස්ත කේතය මේ දෙක අතර ඇති බව මම යෝජනා කරමි:

phoneNumber = isApplicationInProduction(headers) ? headers.resourceId : DEV_PHONE_NUMBER;

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

එය ඔබට ලෝක දෙකෙහිම හොඳම දේ ලබා දෙයි: සරල කරන ලද පරීක්ෂණ ප්‍රකාශනයක් සහ අදහස් දැක්වීම පරීක්ෂණාත්මක කේතයකින් ප්‍රතිස්ථාපනය වේ.

කේත නිර්මාණය පිළිබඳ ඔබේ ලොක්කාගේ අදහස් සම්බන්ධයෙන්:

කුඩා කාර්යයන් ලිවීම වේදනාවක් වන්නේ කේතය කරන්නේ කුමක්දැයි බැලීමට සෑම කුඩා කාර්යයක් සඳහාම එය බල කරන බැවිනි.

ශ්‍රිතය හොඳින් නම් කර ඇත්නම්, එය එසේ නොවේ. isApplicationInProductionස්වයං දෘශ්‍යමාන වන අතර එය කරන්නේ කුමක්දැයි බැලීමට කේතය පරීක්ෂා කිරීම අවශ්‍ය නොවිය යුතුය. ඇත්ත වශයෙන්ම ප්‍රතිවිරුද්ධ දෙය සත්‍යය: කේතය පරීක්ෂා කිරීමෙන් ශ්‍රිත නාමයට වඩා අභිප්‍රාය අඩු බව හෙළි වේ (ඔබේ ලොක්කාට අදහස් දැක්වීමට සිදු වන්නේ එබැවිනි).

ප්‍රධාන ලූපය පේළි 300 ට වඩා වැඩි වුවද සෑම දෙයක්ම ප්‍රධාන විශාල පුඩුවක් තුළට දමන්න, එය කියවීමට වේගවත් වේ

එය පරිලෝකනය කිරීම වේගවත් විය හැකි නමුත් කේතය සැබවින්ම "කියවීමට" නම්, එය ඔබේ හිස තුළ effectively ලදායී ලෙස ක්‍රියාත්මක කිරීමට ඔබට හැකි විය යුතුය. කුඩා කාර්යයන් සමඟ එය පහසු වන අතර පේළි 100 ක දිගකින් යුත් ක්‍රම සමඟ එය ඇත්තෙන්ම දුෂ්කර ය.

ඔබට කේත අනුපිටපත් කිරීමට අවශ්‍ය නම් කුඩා කාර්යයන් පමණක් ලියන්න

මම එකඟවෙන්නේ නැහැ. ඔබේ කේත උදාහරණයෙන් පෙන්නුම් කරන පරිදි, කුඩා, හොඳින් නම් කරන ලද කාර්යයන් කේත කියවීමේ හැකියාව වැඩි දියුණු කරන අතර උදා: ඔබ "කෙසේද" ගැන උනන්දුවක් නොදක්වන සෑම විටම භාවිතා කළ යුතුය, ක්‍රියාකාරී කොටසක "කුමක්ද" පමණි.

විවරණයේ නම සමඟ ශ්‍රිතයක් ලියන්න එපා, ඉහත අදහස් දැක්වීමක් සමඟ ඔබේ සංකීර්ණ කේත රේඛාව (පේළි 3-4) තබන්න. මේ ආකාරයට ඔබට අසමත් වූ කේතය කෙලින්ම වෙනස් කළ හැකිය

මට ඇත්තටම මේ කාරණය පිටුපස ඇති හේතුව තේරුම් ගත නොහැකිය. විශේෂ Exp ආරම්භක ට්විටර් ගිණුම විසින් උපහාසාත්මක ලෙස ලියා ඇති බව දැකීමට මා බලාපොරොත්තු වන කාරණය එයයි . අදහස් වලට මූලික අඩුපාඩුවක් ඇත: ඒවා සම්පාදනය / අර්ථ නිරූපණය නොකෙරෙන අතර ඒකකය පරීක්ෂා කළ නොහැක. කේතය වෙනස් වන අතර අදහස් දැක්වීම තනි වන අතර ඔබ හරි දේ නොදැන සිටියි.

ස්වයං ලේඛනගත කිරීමේ කේතයක් ලිවීම දුෂ්කර වන අතර අතිරේක ලියකියවිලි (අදහස් දැක්වීමේ ස්වරූපයෙන් පවා) සමහර විට අවශ්‍ය වේ. නමුත් අදහස් දැක්වීම කේතීකරණ අසමත් වීමක් බව "බොබ් මාමාගේ" මතය බොහෝ විට සත්‍ය වේ.

ඔබේ ලොක්කාට පිරිසිදු කේත පොත කියවා ඔබේ කේතය සෑහීමකට පත්වීම සඳහා කියවීම අඩු කිරීමට විරුද්ධ වන්න. අවසානයේදී, ඔබට ඔහුව වෙනස් කිරීමට ඒත්තු ගැන්විය නොහැකි නම්, ඔබට පෙළගැස්විය යුතුය, නැතහොත් වඩා හොඳ කේත කළ හැකි නව ලොක්කෙකු සොයා ගත යුතුය.

තවත් ගැටළු තිබේ

කේත දෙකම හොඳ නැත, මන්දයත් දෙකම මූලික වශයෙන් නිදොස් කිරීමේ පරීක්ෂණ නඩුවකින් කේතය පුපුරවා හරින බැවිනි . කුමන හේතුවක් නිසා හෝ ඔබට තවත් දේවල් පරීක්ෂා කිරීමට අවශ්‍ය නම් කුමක් කළ යුතුද?

phoneNumber = DEV_PHONE_NUMBER_WHICH_CAUSED_PROBLEMS_FOR_CUSTOMERS;

හෝ

phoneNumber = DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY;

ඔබට තවත් ශාඛා එකතු කිරීමට අවශ්‍යද?

සැලකිය යුතු ගැටළුව නම් ඔබ මූලික වශයෙන් ඔබේ කේතයේ කොටසක් අනුපිටපත් කිරීමයි, එබැවින් ඔබ සත්‍ය කේතය පරික්ෂා නොකරයි. නිදොස් කිරීමේ කේතය පරීක්ෂා කිරීම සඳහා ඔබ දෝශ නිරාකරණ කේතය ලියයි, නමුත් නිෂ්පාදන කේතය නොවේ. එය අර්ධ වශයෙන් සමාන්තර කේත පදනමක් නිර්මාණය කිරීමක් වැනිය.

නරක කේත වඩාත් දක්ෂ ලෙස ලිවිය යුතු ආකාරය ගැන ඔබ ඔබේ ලොක්කා සමඟ වාද කරයි. ඒ වෙනුවට, ඔබ කේතයේ ආවේනික ගැටලුව විසඳිය යුතුය.

යැපුම් එන්නත් කිරීම

ඔබේ කේතය පෙනිය යුතු ආකාරය මෙයයි:

phoneNumber = headers.resourceId;

මෙහි කිසිදු ශාඛාවක් නොමැත, මන්ද මෙහි තර්කනයට කිසිදු අතු බෙදීමක් නොමැත. වැඩසටහන ශීර්ෂයෙන් දුරකථන අංකය ඇද ගත යුතුය. කාලය.

ඔබට ප්‍රති DEV_PHONE_NUMBER_FROM_OTHER_COUNTRYresult ලයක් ලෙස ලබා ගැනීමට අවශ්‍ය නම් , ඔබ එය දැමිය යුතුය headers.resourceId. එය කළ හැකි එක් ක්‍රමයක් වන්නේ headersපරීක්ෂණ අවස්ථා සඳහා වෙනත් වස්තුවක් එන්නත් කිරීමයි (මෙය නිසි කේතයක් නොවේ නම් සමාවන්න, මගේ ජාවාස්ක්‍රිප්ට් කුසලතා මඳක් මලකඩ වේ):

function foo(headers){
    phoneNumber = headers.resourceId;
}

// Creating the test case
foo({resourceId: DEV_PHONE_NUMBER_FROM_OTHER_COUNTRY});

headersඑය සේවාදායකයකුගෙන් ඔබට ලැබෙන ප්‍රතිචාරයක කොටසක් යැයි උපකල්පනය කිරීම : ඉතා මැනවින් ඔබට සම්පූර්ණ පරීක්ෂණ සේවාදායකයක් ඇත, එය headersපරීක්ෂණ අරමුණු සඳහා විවිධ වර්ග ලබා දෙයි . මේ ආකාරයෙන් ඔබ සත්‍ය නිෂ්පාදන කේතය පරික්ෂා කර ඇති අතර නිෂ්පාදන කේතය මෙන් ක්‍රියා කළ හැකි හෝ නොවිය හැකි අර්ධ අනුපිටපත් කේත නොවේ.

මේ සඳහා "නිවැරදි" හෝ "වැරදි" පිළිතුරක් නොමැත. කෙසේ වෙතත්, මෘදුකාංග පද්ධති සැලසුම් කිරීම සහ සංවර්ධනය කිරීම පිළිබඳ වසර 36 ක වෘත්තීය පළපුරුද්ද මත පදනම්ව මම මගේ මතය ඉදිරිපත් කරමි ...

1. "ස්වයං ලේඛන කේතය" වැනි දෙයක් නොමැත. මන්ද? මන්ද එම ප්‍රකාශය සම්පූර්ණයෙන්ම ආත්මීය ය.
2. අදහස් කිසි විටෙකත් අසාර්ථක නොවේ. දේ වන්නේ අසාර්ථක සියලු දී තේරුම් ගත නොහැකි බව කේතය තොරව අදහස්.
3. එක් කේත කොටසක අඛණ්ඩ කේත පේළි 300 ක් නඩත්තු බියකරු සිහිනයක් වන අතර එය දෝෂ වලට ගොදුරු වේ. එවැනි බ්ලොක් එකක් නරක සැලසුම හා සැලසුම් කිරීම දැඩි ලෙස පෙන්නුම් කරයි.

ඔබ සපයා ඇති ආදර්ශයට කෙලින්ම කථා කිරීම ... isApplicationInProduction()තමන්ගේම පුරුද්දට යොමු කිරීම කළ යුතු හොඳම (er) දෙයයි. අද එම පරීක්ෂණය හුදෙක් "ශීර්ෂයන්" පරීක්ෂා කිරීමක් වන අතර එය ත්‍රිමාණ ( ?:) ක්‍රියාකරුවෙකු තුළ හැසිරවිය හැකිය . හෙට, පරීක්ෂණය වඩාත් සංකීර්ණ විය හැකිය. මීට අමතරව, "headers.resourceId" යෙදුමේ "නිෂ්පාදන තත්ත්වය" සමඟ පැහැදිලි සම්බන්ධයක් නොමැත; මම එවැනි තත්ත්වය සඳහා ටෙස්ට් තර්ක කරන්නට අවශ්ය යටින් පවතින දත්ත decoupled කළ යුතු කියා මාර්ග කවෙර්ද; සබ්මැරීනයක් මෙය කරනු ඇති අතර ත්‍රිකෝණයක් සිදු නොවේ. මීට අමතරව, සම්පත් නිෂ්පාදනයක් "නිෂ්පාදනයේ" පරීක්ෂණය වන්නේ ඇයිද යන්න ප්‍රයෝජනවත් ප්‍රකාශයක් වනු ඇත .

"පැහැදිලිව නම් කරන ලද කුඩා කාර්යයන්" සමඟ නොයැවීමට වගබලා ගන්න. පුරුද්දක් ලෙස "හුදෙක් කේතයට" වඩා අදහසක් වටහා ගත යුතුය. මම ආමොන් යෝජනාව සහය phoneNumber = getPhoneNumber(headers)සහ එම එක් getPhoneNumber()සමග "නිෂ්පාදනය තත්ත්වය" පරීක්ෂණය කළ යුත්තේisApplicationInProduction()

අවශ්‍යතාවයෙන් ඔබ්බට ආයතන ගුණ නොකළ යුතුය. ”

- ඔකෑම්ගේ රේසර්

කේතය හැකි තරම් සරල විය යුතුය. දෝෂයන් සංකීර්ණ අතර සැඟවීමට කැමතියි, මන්ද ඒවා හඳුනා ගැනීමට අපහසුය. ඉතින් කේතය සරල කරන්නේ කුමක් ද?

කුඩා ඒකක (ලිපිගොනු, කාර්යයන්, පන්ති) හොඳ අදහසකි . ඔබට එකවර තේරුම් ගත යුතු දේවල් අඩු බැවින් කුඩා ඒකක තේරුම් ගැනීමට පහසුය. සාමාන්‍ය මිනිසුන්ට කළ හැක්කේ වරකට සංකල්ප 7 ක් පමණි. නමුත් ප්‍රමාණය හුදෙක් කේත රේඛාවලින් මනිනු නොලැබේ . කේතය “ගොල්ෆ් කිරීම” (කෙටි විචල්‍ය නම් තෝරා ගැනීම, “දක්ෂ” කෙටිමං ගැනීම, හැකි තරම් කේත තනි පේළියකට බිඳ දැමීම) මගින් මට හැකි තරම් කුඩා කේතයක් ලිවිය හැකිය, නමුත් අවසාන ප්‍රති result ලය සරල නොවේ. එවැනි කේත තේරුම් ගැනීමට උත්සාහ කිරීම කියවීමට වඩා ප්‍රතිලෝම ඉංජිනේරු විද්‍යාව වැනි ය.

ශ්‍රිතයක් කෙටි කිරීමට එක් ක්‍රමයක් නම් විවිධ උපකාරක ක්‍රියාකාරකම් උකහා ගැනීමයි. එය ස්වයං අන්තර්ගත සංකීර්ණතාවයක් උකහා ගන්නා විට එය හොඳ අදහසක් විය හැකිය . හුදකලා කිරීමේදී, එම සංකීර්ණතාව සම්බන්ධ කිරීමට නොහැකි ගැටළුවකට කාවැද්දීමට වඩා කළමනාකරණය කිරීමට (සහ පරීක්ෂා කිරීමට!) වඩා සරල ය.

නමුත් සෑම ක්‍රියාකාරී ඇමතුමකටම සංජානන පොදු කාර්යයක් ඇත : මගේ වර්තමාන කේත කොටස තුළ ඇති කේතය තේරුම් ගැනීමට මට අවශ්‍ය නැත , එය පිටතින් ඇති කේතය සමඟ අන්තර්ක්‍රියා කරන්නේ කෙසේද යන්න තේරුම් ගත යුතුය . ඔබ උපුටා ගත් ශ්‍රිතය නිස්සාරණයට වඩා ශ්‍රිතයට වඩා සංකීර්ණ බවක් හඳුන්වා දෙන බව පැවසීම සාධාරණ යැයි මම සිතමි . ඔබේ ලොක්කා අදහස් කළේ “ කුඩා කාර්යයන් [වේදනාවක්] නිසා කේතය කරන්නේ කුමක්දැයි බැලීමට සෑම කුඩා ශ්‍රිතයක් තුළටම යාමට එය ඔබට බල කරයි. ”

සමහර විට, දිගු කම්මැලි කාර්යයන් තේරුම් ගැනීමට ඇදහිය නොහැකි තරම් සරල විය හැකිය, ඒවා පේළි සිය ගණනක් දිග වුවත්. මෙය ආරම්භක හා වින්‍යාස කේතයන්හි සිදු වේ, උදා: ඇදගෙන යාමේ සංස්කාරකයක් නොමැතිව අතින් GUI එකක් සාදන විට. ඔබට සාධාරණ ලෙස උකහා ගත හැකි ස්වයං අන්තර්ගත සංකීර්ණතාවයක් නොමැත. නමුත් ආකෘතිකරණය කියවිය හැකි නම් සහ අදහස් කිහිපයක් තිබේ නම්, සිදුවෙමින් පවතින දේ අනුගමනය කිරීම ඇත්තෙන්ම අපහසු නැත.

තවත් බොහෝ සංකීර්ණ ප්‍රමිතික තිබේ: විෂය පථයක විචල්‍ය ගණන හැකි තරම් කුඩා විය යුතුය. එයින් අදහස් කරන්නේ අප විචල්‍යයන්ගෙන් වැළකී සිටිය යුතු බවයි. එයින් අදහස් වන්නේ අප සෑම විචල්‍යයක්ම අවශ්‍ය කුඩාම විෂය පථයට සීමා කළ යුතු බවයි. ඒවායේ අඩංගු අගය අප කිසි විටෙකත් වෙනස් නොකරන්නේ නම් විචල්‍යයන් ද සරල වේ.

ඉතා වැදගත් මෙට්‍රික් එකක් වන්නේ චක්‍රීය සංකීර්ණතාවයි (මැකේබ් සංකීර්ණතාව). එය කේත කැබැල්ලක් හරහා ස්වාධීන මාර්ග ගණන මනිනු ලබයි. එක් එක් කොන්දේසි සහිතව මෙම සංඛ්‍යාව on ාතීය ලෙස වර්ධනය වේ. සෑම කොන්දේසි සහිත හෝ පුඩුවක්ම මාර්ග ගණන දෙගුණ කරයි. ලකුණු 10 ට වඩා වැඩි ලකුණු ප්‍රමාණයක් සංකීර්ණ බවට යෝජනා කිරීමට සාක්ෂි තිබේ. මෙයින් අදහස් කරන්නේ ලකුණු 5 ක් ඇති ඉතා දිගු ශ්‍රිතයක් ලකුණු 25 ක් සහිත ඉතා කෙටි හා function න ශ්‍රිතයකට වඩා හොඳ විය හැකි බවයි. වෙනම ශ්‍රිතවලට පාලන ප්‍රවාහය උකහා ගැනීමෙන් අපට සංකීර්ණතාව අඩු කළ හැකිය.

ඔබේ කොන්දේසිය මුළුමනින්ම උපුටා ගත හැකි සංකීර්ණ කැබැල්ලකට උදාහරණයකි:

function bigFatFunction(...) {
  ...
  phoneNumber = getPhoneNumber(headers);
  ...
}

...

function getPhoneNumber(headers) {
  return headers.resourceId ? headers.resourceId : DEV_PHONE_NUMBER;
}

මෙය තවමත් ප්‍රයෝජනවත් වීමේ අද්දර පවතී. මෙම කොන්දේසිය ඉතා කොන්දේසි සහිත නොවන නිසා එය සැලකිය යුතු ලෙස සංකීර්ණතාව අඩු කරයිදැයි මට විශ්වාස නැත . නිෂ්පාදනයේදී, එය සෑම විටම එකම මාවතකට යනු ඇත.

සංකීර්ණත්වය කිසි විටෙකත් අතුරුදහන් විය නොහැක. එය මාරු කළ හැක්කේ වටේට පමණි. විශාල දේවල් කිහිපයකට වඩා බොහෝ කුඩා දේවල් සරලද? එය තත්වය මත බොහෝ සෙයින් රඳා පවතී. සාමාන්‍යයෙන්, නිවැරදි යැයි හැඟෙන සංයෝජනයක් තිබේ. විවිධ සංකීර්ණ සාධක අතර සම්මුතියක් ඇති බව සොයා ගැනීම ප්‍රතිභානය සහ අත්දැකීම් සහ වාසනාව අවශ්‍ය වේ.

ඉතා කුඩා කාර්යයන් සහ ඉතා සරල කාර්යයන් ලිවීමට දැන ගැනීම ප්‍රයෝජනවත් කුසලතාවකි, මන්ද ඔබට විකල්පයන් නොදැන තේරීමක් කළ නොහැකි බැවිනි. වර්තමාන තත්වයට ඒවා අදාළ වන්නේ කෙසේද යන්න ගැන නොසිතා නීති රීති හෝ හොඳම භාවිතයන් අන්ධ ලෙස අනුගමනය කිරීම සාමාන්‍ය ප්‍රති results ල සඳහා හොඳම, භාණ්ඩ-සංස්කෘතික වැඩසටහන් නරක අතට හැරේ .

ඔබේ ලොක්කා සමඟ මම එකඟ නොවන්නේ එතැනිනි. ඔහුගේ තර්ක වලංගු නොවේ, නමුත් පිරිසිදු කේත පොත වැරදිය. ඔබේ ලොක්කාගේ මාර්ගෝපදේශ අනුගමනය කිරීම වඩා හොඳය, නමුත් ඔබ මෙම ගැටළු ගැන සිතමින් සිටීම, වඩා හොඳ මාර්ගයක් සොයා ගැනීමට උත්සාහ කිරීම ඉතා යහපත්ය. ඔබ අත්දැකීම් ලබා ගන්නා විට, ඔබේ කේතය සඳහා හොඳ සාධකයක් සොයා ගැනීම ඔබට පහසු වේ.

(සටහන: මෙම පිළිතුර පදනම් වී ඇත්තේ ජිමී හොෆා විසින් රචිත වයිට්බෝඩ් හි සාධාරණ කේත බ්ලොග් සටහනේ අදහස් මත වන අතර එමඟින් කේතය සරල කරන්නේ කුමක් ද යන්න පිළිබඳ ඉහළ මට්ටමේ දැක්මක් ලබා දේ.)

රොබට් මාටින්ගේ ක්‍රමලේඛන විලාසය ධ්‍රැවීකරණය කරයි. “එතරම්” බෙදීම ඕනෑවට වඩා වැඩි වන්නේ ඇයිද යන්නත්, කාර්යයන් ටිකක් විශාල ලෙස තබා ගැනීම “වඩා හොඳ ක්‍රමය” වන්නේ මන්දැයි බොහෝ නිදහසට කරුණු සොයා ගන්නා බොහෝ ක්‍රමලේඛකයින්, පළපුරුදු අය පවා ඔබට හමුවනු ඇත. කෙසේ වෙතත්, මෙම "තර්ක" බොහෝ විට පැරණි පුරුදු වෙනස් කිරීමට සහ අලුත් දෙයක් ඉගෙන ගැනීමට අකමැති වීමේ ප්‍රකාශනයකි.

ඔවුන්ට ඇහුම්කන් දෙන්න එපා!

ප්‍රකාශන නාමයක් සහිත වෙනම ශ්‍රිතයකට කේත කැබැල්ලක් ප්‍රතිනිර්මාණය කිරීමෙන් ඔබට විවරණයක් සුරැකිය හැකි සෑම විටම එය කරන්න - එය බොහෝ විට ඔබේ කේතය වැඩි දියුණු කරනු ඇත. බොබ් මාටින් සිය පිරිසිදු කේත පොතේ සඳහන් පරිදි ඔබ එතරම් දුර ගොස් නැත, නමුත් නඩත්තු ගැටළු ඇති කළ අතීතයේ මා දුටු කේතයේ අතිමහත් බහුතරය ඉතා විශාල කාර්යයන් මිස කුඩා ඒවා නොවේ. එබැවින් ස්වයං විස්තර කරන නම් සමඟ කුඩා කාර්යයන් ලිවීමට උත්සාහ කිරීම ඔබ උත්සාහ කළ යුතු දෙයයි.

ස්වයංක්‍රීය ප්‍රතිචක්‍රීකරණ මෙවලම් ක්‍රම උපුටා ගැනීම පහසු, සරල හා ආරක්ෂිත කරයි. කරුණාකර, පේළි 300 ක් සමඟ කාර්යයන් ලිවීමට නිර්දේශ කරන පුද්ගලයින් බැරෑරුම් ලෙස නොසලකන්න - ඔබ කේත කළ යුතු ආකාරය පැවසීමට එවැනි පුද්ගලයින් අනිවාර්යයෙන්ම සුදුසුකම් නොලබයි.

ඔබගේ නඩුවේ: ඔබට දුරකථන අංකයක් අවශ්‍යයි. එක්කෝ ඔබට දුරකථන අංකයක් ලැබෙන්නේ කෙසේද යන්න පැහැදිලිය, පසුව ඔබ පැහැදිලි කේතය ලියයි. නැතහොත් ඔබට දුරකථන අංකයක් ලැබෙන්නේ කෙසේද යන්න පැහැදිලි නැත, එවිට ඔබ ඒ සඳහා ක්‍රමවේදයක් ලියයි.

ඔබගේ නඩුවේදී, දුරකථන අංකය ලබා ගන්නේ කෙසේද යන්න පැහැදිලි නැත, එබැවින් ඔබ ඒ සඳහා ක්‍රමවේදයක් ලියයි. ක්‍රියාත්මක කිරීම පැහැදිලිව පෙනෙන්නට නැත, නමුත් ඔබ එය වෙනම ක්‍රමයකට දමන්නේ ඒ නිසා ඔබට එය සමඟ ගනුදෙනු කළ යුත්තේ එක් වරක් පමණි. ක්‍රියාත්මක කිරීම පැහැදිලි නැති නිසා අදහස් දැක්වීමක් ප්‍රයෝජනවත් වේ.

“IsApplicationInProduction” ක්‍රමය අර්ථ විරහිත ය. ඔබගේ getPhonenumber ක්‍රමයෙන් එය ඇමතීමෙන් ක්‍රියාත්මක කිරීම තවදුරටත් පැහැදිලි නොවන අතර සිදුවන්නේ කුමක්දැයි සොයා ගැනීම දුෂ්කර කරයි.

කුඩා කාර්යයන් ලියන්න එපා. මනාව නිර්වචනය කර ඇති අරමුණක් ඇති කාර්යයන් ලියන්න.

පීඑස්. ක්‍රියාත්මක කිරීමට මම කිසිසේත් කැමති නැත. එය උපකල්පනය කරන්නේ දුරකථන අංකයක් නොමැති වීමෙන් අදහස් වන්නේ එය dev අනුවාදයක් බවයි. එබැවින් දුරකථන අංකය නිෂ්පාදනයේ නොමැති නම් ඔබ එය හසුරුවනවා පමණක් නොව අහඹු දුරකථන අංකයක් ආදේශ කරන්න. ඔබට ගනුදෙනුකරුවන් 10,000 ක් සිටින බව සිතන්න, 17 දෙනෙකුට දුරකථන අංකයක් නොමැති අතර, ඔබ නිෂ්පාදනයේ කරදරයක සිටී. ඔබ නිෂ්පාදනයේ හෝ සංවර්ධනයේ සිටීද යන්න කෙලින්ම පරික්ෂා කළ යුතුය, වෙනත් දෙයකින් උපුටා ගත් ඒවා නොවේ.

ක්‍රියාවට නැංවීම එතරම් යහපත් නොවන බව නොසලකා හැරියද, මෙය අවම වශයෙන් තනි භාවිතයේ සුළු කාර්යයන් වියුක්ත කිරීමේ මට්ටමින් අවම වශයෙන් රසය පිළිබඳ ප්‍රශ්නයක් බව මම සටහන් කරමි.

රේඛා ගණන බොහෝ අවස්ථාවන්හි ප්‍රයෝජනවත් මෙට්‍රික් නොවේ.

ඉතා සුළු සුළු තනිකරම අනුක්‍රමික කේත (සැකසුම, හෝ ඒ හා සමාන දෙයක්) පේළි 300 (හෝ 3000) කලාතුරකින් ගැටළුවක් වේ (නමුත් වඩා හොඳ ස්වයංක්‍රීයව ජනනය කළ හැකි හෝ දත්ත වගුවක් හෝ වෙනත් දෙයක් විය හැකිය), පේළි 100 ක් කූඩු ලූප ගවුසියානු තුරන් කිරීම හෝ අනුකෘති ප්‍රතිලෝමයෙන් ඔබට සොයාගත හැකි කොන්දේසි සහ ගණිතයෙන් පිටවීම හෝ පහසුවෙන් අනුගමනය කළ නොහැකි තරම් විය හැකිය.

මට නම්, එය ප්‍රකාශ කිරීමට අවශ්‍ය කේත ප්‍රමාණය ඊට වඩා කුඩා නම් මිස ක්‍රියාත්මක කිරීමේ කේතයේ ප්‍රමාණය (මම වැරදි ලෙස එන්නත් කිරීම පහසුවෙන් කළ හැකි යැයි පැවසීමට හේතුවක් නොමැති නම්). තනි කොන්දේසියක් මෙම පනතට ගැලපෙන්නේ කලාතුරකිනි.

දැන් මම පැමිණියේ කුඩා හර කාවැද්දූ ලෝකයකින් වන අතර, එහිදී අප විසින් කොටස් ගැඹුර සහ ඇමතුම් / ආපසු යවන ශීර්ෂයන් වැනි කරුණු ද සලකා බැලිය යුතුය (මෙහි දී මෙහි දී යෝජනා කර ඇති කුඩා ක්‍රියාකාරිත්වයන්ට එරෙහිව නැවත තර්ක කරයි), මෙය මගේ සැලසුම පක්ෂග්‍රාහී විය හැකිය. තීරණ, නමුත් කේත සමාලෝචනයක් තුළ මම එම මුල් ශ්‍රිතය දුටුවහොත් එයට ප්‍රතිචාර වශයෙන් පැරණි විලාසිතාවේ පරිශීලක දැල්ලක් ලැබෙනු ඇත.

රස යනු සැලසුම් කිරීම ඉගැන්වීමට අපහසු වන අතර එය ඇත්ත වශයෙන්ම අත්දැකීම් සමඟ පමණක් වන අතර, එය ක්‍රියාකාරීත්වයේ දිග පිළිබඳ නීති දක්වා අඩු කළ හැකි බව මට විශ්වාස නැත, සහ චක්‍රීය සංකීර්ණතාවයට පවා මෙට්‍රික් එකක් ලෙස එහි සීමාවන් ඇත (සමහර විට ඔබ ඒවා විසඳා ගත්තද දේවල් සංකීර්ණ වේ).
පිරිසිදු කේතය සමහර හොඳ දේවල් සාකච්ඡා නොකරන බව මින් අදහස් නොකෙරේ, එය සිදු වන අතර, මේ දේවල් ගැන සිතා බැලිය යුතු නමුත් දේශීය චාරිත්‍රය සහ පවතින කේත පදනම කුමක් ද යන්න ද බර ලබා දිය යුතුය.

මෙම විශේෂිත උදාහරණය ඉතා සුළු විස්තරයක් ලෙස මට පෙනේ, පද්ධතියක් පහසුවෙන් තේරුම් ගැනීමට සහ නිදොස් කිරීමට ඇති හැකියාව කෙරෙහි වඩා වැදගත් වන බොහෝ ඉහළ මට්ටමේ දේවල් ගැන මම වඩාත් සැලකිලිමත් වෙමි.

සෑම දෙයක්ම එක විශාල පුඩුවක් තුළට දමන්න එපා, නමුත් මෙය නිතර නිතර නොකරන්න:

function isApplicationInProduction(headers) {
   return _.has(headers, 'resourceId');
}

විශාල ලූපයේ ඇති ගැටළුව නම්, එය බොහෝ තිරයන් පුරා විහිදෙන විට එහි සමස්ත ව්‍යුහය දැකීම දුෂ්කර ය. ඒ නිසා විශාල කැබලි, තනි වගකීමක් ඇති සහ නැවත භාවිතා කළ හැකි කුට්ටි ඉවත් කිරීමට උත්සාහ කරන්න.

ඉහත ඉතා කුඩා ක්‍රියාකාරිත්වයේ ගැටළුව නම්, පරමාණුකතාව සහ මොඩියුලරිටි සාමාන්‍යයෙන් හොඳ වුවත්, එය බොහෝ දුරට ගත හැකිය. ඔබ ඉහත ශ්‍රිතය නැවත භාවිතා කිරීමට නොයන්නේ නම් එය කේත කියවීමේ හැකියාව සහ නඩත්තු කළ හැකිය. සවිස්තරාත්මකව විග්‍රහ කිරීම සඳහා ඔබට විස්තරය පේළියේ කියවීමට වඩා ශ්‍රිතයට පනින්නට සිදු වන අතර, ක්‍රියාකාරී ඇමතුම විස්තරයට වඩා අඩු ඉඩක් ලබා නොගනී.

කරන ක්‍රම අතර සමබරතාවයක් ඇති බව පැහැදිලිය ඕනෑවට වඩා කරන හා ක්රම ඉතා සුළු . එක් ස්ථානයකට වඩා වැඩි ගණනකින් කැඳවනු ලැබුවහොත් මිස, මම කිසි විටෙකත් ඉහත පරිදි කුඩා ශ්‍රිතයක් කඩ නොකරමි, එවිට පවා මම ඒ ගැන දෙවරක් සිතමි, මන්ද නව තාර්කිකත්වය හඳුන්වා දීමේදී සහ ශ්‍රිතය එතරම් වැදගත් නොවන බැවිනි. තමන්ගේ පැවැත්මක් ඇති එවැනි යන්තම් වරෙන්තු.

ඔබට සැබවින්ම අවශ්‍ය වන්නේ මෙය බව පෙනේ:

phoneNumber = headers.resourceId || DEV_PHONE_NUMBER

මෙය කියවන ඕනෑම කෙනෙකුට මෙය ස්වයං පැහැදිලි කිරීමක් විය යුතුය: එය phoneNumberතිබේ resourceIdනම් එය සකසන්න , නැතහොත් DEV_PHONE_NUMBERඑය නොමැති නම් පෙරනිමිය .

ඔබ නම් සැබවින්ම පමණක් නිෂ්පාදනය කට්ටලයක් බව විචල්ය කිරීමට අවශ්ය, ඔබ මේ වෙන කොහෙද තීරණය කිරීම සඳහා තවත් වැඩි කැනෝනිකල් යෙදුම පුරා උපයෝගිතා ක්රමය (පරාමිතිය අවශ්ය නොවන බව) තිබිය යුතුය. එම තොරතුරු සඳහා ශීර්ෂ කියවීම තේරුමක් නැත.

මට මොට වීමට ඉඩ දෙන්න: ඔබේ පරිසරය (භාෂාව / රාමුව / පන්ති සැලසුම් ආදිය) “පිරිසිදු” කේතයට සැබවින්ම නොගැලපෙන බව මට පෙනේ. ඔබ හැකි සෑම ආකාරයකම කේත පේළි කිහිපයකින් මිශ්‍ර කරමින් සැබවින්ම එකිනෙකට සමීප නොවිය යුතුය. resourceId==undefඔබ නිෂ්පාදනයෙහි නොමැති බවත්, නිෂ්පාදන නොවන පද්ධතිවල පෙරනිමි දුරකථන අංකයක් භාවිතා කරන බවත්, සම්පත් "සමහර" ශීර්ෂයන් "තුළ සුරකින බවත්, එසේත් නැතිනම් තනි ශ්‍රිතයක් සතුව ඇති ව්‍යාපාර මොනවාද? මම උපකල්පනය කරනවාheaders HTTP ශීර්ෂයන්, එබැවින් ඔබ අවසාන පරිශීලකයාට කුමන පරිසරය ගැනද යන්න තීරණය කරන්න.

එහි තනි කොටස් ක්‍රියාකාරීත්වයට සාධක කිරීම එම යටින් පවතින ගැටලුවට බොහෝ සෙයින් උපකාරී නොවේ.

සෙවිය යුතු සමහර මූල පද:

• විසන්ධි කිරීම
• සහජීවනය
• පරායත්ත එන්නත් කිරීම

කේතයේ වගකීම් වෙනස් කිරීමෙන් සහ නවීන රාමු භාවිතා කිරීමෙන් (ඔබේ පරිසරය / ක්‍රමලේඛන භාෂාව සඳහා තිබිය හැකි හෝ නොවිය හැකි) කේතයේ ශුන්‍ය රේඛා සමඟ ඔබට අවශ්‍ය දේ (වෙනත් සන්දර්භය තුළ) සාක්ෂාත් කරගත හැකිය.

ඔබගේ විස්තරයෙන් ("ප්‍රධාන" ශ්‍රිතයක කේත පේළි 300 ක්), "ශ්‍රිතය" (ක්‍රමය වෙනුවට) යන වචනය පවා ඔබ උපකල්පනය කිරීමට උත්සාහ කරන්නේ ඔබ සාක්ෂාත් කර ගැනීමට උත්සාහ කරන දෙයෙහි කිසිදු අර්ථයක් නොමැති බවයි. එම පැරණි පාසල් ක්‍රමලේඛන පරිසරය තුළ (එනම්, කුඩා ව්‍යුහයක් සහිත මූලික අත්‍යවශ්‍ය වැඩසටහන්කරණය, නිසැකවම අර්ථවත් පන්ති නොමැත, එම්වීසී හෝ සමහරක් වැනි පන්ති රාමු රටාවක් නොමැත), ඇත්ත වශයෙන්ම කිසිවක් කිරීමට තරම් වැදගත්කමක් නැත . මූලික වෙනස්කම් නොමැතිව ඔබ කිසි විටෙකත් සම්පූර්‍ණයෙන් ඉවත් නොවනු ඇත. අවම වශයෙන් ඔබේ ලොක්කා ඔබට කේත අනුපිටපත් වළක්වා ගැනීම සඳහා කාර්යයන් නිර්මාණය කිරීමට ඉඩ දෙන බව පෙනේ, එය හොඳ පළමු පියවරකි!

කේත වර්ගය මෙන්ම ඔබ හොඳින් විස්තර කරන ක්‍රමලේඛක වර්ගයද මම දනිමි. අවංකවම, එය සම සේවකයෙකු නම්, මගේ උපදෙස් වෙනස් වනු ඇත. නමුත් එය ඔබගේ ලොක්කා බැවින් ඔබට මේ ගැන සටන් කිරීම නිෂ් less ල ය. ඔබේ ලොක්කාට ඔබව අභිබවා යා හැකි බව පමණක් නොව, ඔබේ කේත එකතු කිරීම් ඇත්ත වශයෙන්ම "ඔබේ ක්‍රියාව" අර්ධ වශයෙන් කළහොත් පමණක් ඔබගේ කේත එකතු කිරීම වඩාත් නරක කේතයකට තුඩු දෙනු ඇත, ඔබේ ලොක්කා (සහ බොහෝ විට වෙනත් පුද්ගලයින්) පෙර මෙන් දිගටම කරගෙන යයි. ඔබ ඔවුන්ගේ ක්‍රමලේඛ ශෛලියට අනුගත වුවහොත් (ඇත්ත වශයෙන්ම මෙම විශේෂිත කේත පදනම මත වැඩ කරන විට පමණක්) අවසාන ප්‍රති result ලය සඳහා වඩා හොඳ විය හැකි අතර, මෙම සන්දර්භය තුළ එයින් උපරිම ප්‍රයෝජන ගැනීමට උත්සාහ කරන්න.

"පිරිසිදු" යනු කේත ලිවීමේ එක් ඉලක්කයකි. එය එකම ඉලක්කය නොවේ. තවත් වටිනා ඉලක්කයක් වන්නේ සාමූහිකත්වයයි . අවිධිමත් ලෙස කිවහොත්, සාමූහිකත්වය යනු ඔබේ කේතය තේරුම් ගැනීමට උත්සාහ කරන පුද්ගලයින්ට ඔබ කරන්නේ කුමක්දැයි බැලීමට තැනින් තැනට පැනීමට අවශ්‍ය නොවන බවයි. ත්‍රිමාණ ප්‍රකාශනයක් වෙනුවට හොඳින් නම් කරන ලද ශ්‍රිතයක් භාවිතා කිරීම හොඳ දෙයක් සේ පෙනේ, නමුත් ඔබ සතුව එවැනි කාර්යයන් කීයක් තිබේද සහ ඒවා පිහිටා ඇති ස්ථානය මත පදනම්ව, මෙම ක්‍රියාව කරදරයක් බවට පත්විය හැකිය. මිනිසුන් පැමිණිලි කරන්නේ නම්, ඔබ සවන් දිය යුතු යැයි පැවසීම හැර, ඔබ එම සීමාව පසු කර ඇත්දැයි මට කිව නොහැක, විශේෂයෙන් එම පුද්ගලයින්ට ඔබේ රැකියා තත්ත්වය ගැන යමක් පැවසුවහොත්.

කුඩා කාර්යයන් භාවිතා කිරීම සාමාන්‍යයෙන් හොඳ පුරුද්දකි. නමුත් ඉතා මැනවින් මා විශ්වාස කරන්නේ ශ්‍රිතයක් හඳුන්වාදීම මඟින් විශාල තාර්කික කුට්ටි වෙන් කළ යුතු බවයි. ඔබ දෙදෙනාම දුන් උදාහරණය කේතය දිගු කරන අතර සංවර්ධකයෙකුට කියවීමට වැඩි කාලයක් අවශ්‍ය වන අතර කෙටි විකල්පය මඟින් "resourceId"නිෂ්පාදනයේ පමණක් වටිනාකම පවතින බව පැහැදිලි නොකරයි . ඒ හා සමාන සරල දෙයක් එය සමඟ වැඩ කිරීමට උත්සාහ කරන විට අමතක කිරීමට පහසු සහ සංවර්‍ධනය කිරීම පහසුය, විශේෂයෙන් ඔබ තවමත් කේත රචනයට අලුත් නම්.

ඔබ නියත වශයෙන්ම ත්‍රිකෝණයක් භාවිතා කළ යුතු යැයි මම නොකියමි, මා සමඟ වැඩ කළ සමහර අය තරමක් දිගු කැමැත්තක් දක්වයි if () {...} else {...}, එය බොහෝ දුරට පුද්ගලික තේරීමකි. මම "එක් පේළියක් එක් දෙයකට ප්‍රවේශ වේ" යන්නට වැඩි කැමැත්තක් දක්වමි, නමුත් මම මූලික වශයෙන් කේත පදනම භාවිතා කරන ඕනෑම දෙයකට ඇලී සිටිමි.

තාර්කික චෙක්පත මඟින් රේඛාව දිග හෝ සංකීර්ණ නම්, අගය රඳවා තබා ගැනීම සඳහා හොඳින් නම් කරන ලද විචල්‍යයක් නිර්මාණය කිරීම ගැන සලකා බලන්න.

// NOTE "resourceId" not present in dev build, use test data
let isProduction = 'resourceId' in headers;
let phoneNumber = isProduction ? headers.resourceId : DEV_PHONE_NUMBER;

කේත පදනම පේළි ශ්‍රිත 300 ක් දක්වා විහිදේ නම් එයට යම් උප කොට් ision ාශයක් අවශ්‍ය බව ද මම කියන්නට කැමැත්තෙමි. නමුත් තරමක් පුළුල් ආ ro ාත භාවිතා කිරීමට මම උපදෙස් දෙමි.

ඔබ දුන් කේත උදාහරණය, ​​ඔබේ ලොක්කා නිවැරදි ය. තනි පැහැදිලි රේඛාවක් එම අවස්ථාවේ දී වඩා හොඳය.

පොදුවේ ගත් කල, සංකීර්ණ තර්කනය කුඩා කැබලිවලට කැඩීම, නිරවද්‍යතාව, කේත නඩත්තු කිරීම සහ උප පංතිවල වෙනස් හැසිරීම් ඇති වීමට ඇති හැකියාව සඳහා වඩා හොඳය (සුළු වශයෙන් වුවද).

අවාසි නොසලකා හරින්න එපා: ශ්‍රිතය ඉහළින්, අපැහැදිලි කිරීම (අදහස් දැක්වීම් සහ ක්‍රියාකාරී නාමයෙන් ගම්‍ය වන දේ ක්‍රියා නොකරයි), සංකීර්ණ ස්පැගටි තර්කනය, මිය ගිය ශ්‍රිත සඳහා විභවය (වරෙක නිර්මාණය කරන ලද්දේ තවදුරටත් හැඳින්වෙන්නේ නැති අරමුණක් සඳහා ය).

දිගු කාර්යයන් සඳහා අවම වශයෙන් තර්ක දෙකක් වත් මට සිතිය හැකිය:

• එයින් අදහස් වන්නේ ඔබට එක් එක් පේළිය වටා සන්දර්භය විශාල ප්‍රමාණයක් ඇති බවයි. මෙය විධිමත් කිරීමේ ක්‍රමයක්: ඔබේ කේතයේ පාලන ප්‍රවාහ ප්‍රස්තාරය අඳින්න. ශ්‍රිත ප්‍රවේශය සහ ශ්‍රිත පිටවීම අතර සිරස් තලයේ (~ = රේඛාව), ඔබ එන සියලුම දාර දන්නවා . ශ්‍රිතය දිගු වන තරමට, එවැනි සිරස් වැඩි ගණනක් ඇත.

• බොහෝ කුඩා කාර්යයන් අදහස් කරන්නේ විශාල හා වඩා සංකීර්ණ ඇමතුම් ප්‍රස්ථාරයක් ඇති බවයි. අහඹු ශ්‍රිතයක අහඹු රේඛාවක් තෝරන්න, සහ "මෙම රේඛාව ක්‍රියාත්මක කරන්නේ කුමන සන්දර්භය තුළද?" යන ප්‍රශ්නයට පිළිතුරු සපයන්න. ඇමතුම් ප්‍රස්ථාරය වඩා විශාල හා සංකීර්ණ වන විට මෙය වඩාත් අපහසු වේ, මන්ද ඔබ එම ප්‍රස්ථාරයේ වැඩි සිරස් දෙස බැලිය යුතුය.

දිගු ක්‍රියාකාරිත්වයන්ට එරෙහිව තර්ක ද ඇත - ඒකක-පරීක්ෂණ හැකියාව උල්පත් මතකයට. එකක් සහ අනෙකක් අතර තෝරාගැනීමේදී ඔබේ අත්දැකීම් භාවිතා කරන්න ̶f̶o̶r̶c̶e̶.

සටහන: මම කියන්නේ නැහැ ඔබේ ලොක්කා හරි කියලා, ඔහුගේ ඉදිරිදර්ශනය මුළුමනින්ම වටිනාකමින් තොර විය හැකිය.

මම හිතන්නේ මගේ අදහස නම් හොඳ ප්‍රශස්තිකරණ පරාමිතිය ක්‍රියාකාරී දිග නොවේ. පහත දැක්වෙන කරුණු අනුව සිතීමට වඩා සුදුසු යැයි මම සිතමි: අනෙක් සියල්ලම එක හා සමාන බැවින්, ව්‍යාපාර තර්කනය සහ ක්‍රියාත්මක කිරීම යන දෙකෙහිම ඉහළ මට්ටමේ විස්තරයක් කේතයෙන් කියවීමට හැකිවීම වඩාත් සුදුසුය. (ඔබට අදාළ කේත ටිකක් සොයාගත හැකි නම් පහත් මට්ටමේ ක්‍රියාත්මක කිරීමේ තොරතුරු සෑම විටම කියවිය හැකිය.)

ඩේවිඩ් ආර්නෝගේ පිළිතුර ගැන අදහස් දක්වමින් :

කුඩා කාර්යයන් ලිවීම වේදනාවක් වන්නේ කේතය කරන්නේ කුමක්දැයි බැලීමට සෑම කුඩා කාර්යයක් සඳහාම එය බල කරන බැවිනි.

ශ්‍රිතය හොඳින් නම් කර ඇත්නම්, එය එසේ නොවේ. isApplicationInProduction ස්වයං දෘශ්‍යමාන වන අතර එය කරන්නේ කුමක්දැයි බැලීමට කේතය පරීක්ෂා කිරීම අවශ්‍ය නොවිය යුතුය. ඇත්ත වශයෙන්ම ප්‍රතිවිරුද්ධ දෙය සත්‍යය: කේතය පරීක්ෂා කිරීමෙන් ශ්‍රිත නාමයට වඩා අභිප්‍රාය අඩු බව හෙළි වේ (ඔබේ ලොක්කාට අදහස් දැක්වීමට සිදු වන්නේ එබැවිනි).

ප්‍රතිලාභ අගය යන්නෙන් අදහස් කරන්නේ කුමක්ද යන්න නමෙන් පැහැදිලි වේ , නමුත් එය කේතය ක්‍රියාත්මක කිරීමෙන් ඇතිවන බලපෑම් ගැන කිසිවක් නොකියයි (= කේතය කරන්නේ කුමක්ද ). නම් (පමණක්) අභිප්‍රාය පිළිබඳ තොරතුරු ගෙන එයි , කේතය මඟින් හැසිරීම පිළිබඳ තොරතුරු ගෙන එයි (අභිප්‍රායෙහි සමහර කොටස් අනුමාන කළ හැකිය).

සමහර විට ඔබට එකක්, සමහර විට අනෙකක් අවශ්‍ය වේ, එබැවින් මෙම නිරීක්‍ෂණය ඒක පාර්ශවීය විශ්වීය වලංගු තීරණ ගැනීමේ රීතියක් නිර්මාණය නොකරයි.

ප්‍රධාන ලූපය පේළි 300 ට වඩා වැඩි වුවද සෑම දෙයක්ම ප්‍රධාන විශාල පුඩුවක් තුළට දමන්න, එය කියවීමට වේගවත් වේ

එය පරිලෝකනය කිරීම වේගවත් විය හැකි නමුත් කේතය සැබවින්ම "කියවීමට" නම්, එය ඔබේ හිස තුළ effectively ලදායී ලෙස ක්‍රියාත්මක කිරීමට ඔබට හැකි විය යුතුය. කුඩා කාර්යයන් සමඟ එය පහසු වන අතර පේළි 100 ක දිගකින් යුත් ක්‍රම සමඟ එය ඇත්තෙන්ම දුෂ්කර ය.

ඔබේ හිසෙහි එය ක්‍රියාත්මක කළ යුතු බව මම එකඟ වෙමි. බොහෝ කුඩා ශ්‍රිතවලට එදිරිව එක් විශාල ශ්‍රිතයක ඔබට පේළි 500 ක ක්‍රියාකාරීත්වයක් තිබේ නම්, මෙය පහසු වන්නේ මන්දැයි මට පැහැදිලි නැත.

සරල රේඛා පේළි 500 ක ආන්තික අවස්ථාව අතිශයින්ම අතුරු ආබාධ සහිත කේතයක් යැයි සිතමු. බලපෑම A ට පෙර හෝ පසුව සිදුවන්නේ දැයි දැන ගැනීමට ඔබට අවශ්‍යය. පේළි අංක. බොහෝ කුඩා කාර්යයන් වලදී, ඇමතුම් ගසෙහි ප්‍රති where ල සිදුවන්නේ කොතැනදැයි ඔබට මතක තබා ගත යුතු අතර, ඔබට අමතක වූවා නම් ඔබට මෙම ගසේ ව්‍යුහය නැවත සොයා ගැනීම සඳහා සුළු කාලයක් ගත කළ යුතුය.

උපකාරක කාර්යයන්හි ඇමතුම් ගස හරහා ගමන් කරන විට, ඔබ ව්‍යාපාර තර්කනයේ සිට ක්‍රියාත්මක කිරීමේ තොරතුරු දක්වා ගිය විට තීරණය කිරීමේ අභියෝගයටද ඔබ මුහුණ දී සිටී. මම සාක්ෂි නොමැතිව කියා සිටිමි * ඇමතුම් ප්‍රස්ථාරය සරල වන තරමට මෙම වෙනස හඳුනා ගැනීම පහසුය.

(*) අවම වශයෙන් මම ඒ ගැන අවංක ය ;-)

නැවත වරක්, මම හිතන්නේ ප්‍රවේශයන් දෙකටම ශක්තීන් හා දුර්වලතා ඇත.

ඔබට කේත අනුපිටපත් කිරීමට අවශ්‍ය නම් කුඩා කාර්යයන් පමණක් ලියන්න

මම එකඟවෙන්නේ නැහැ. ඔබේ කේත උදාහරණයෙන් පෙන්නුම් කරන පරිදි, කුඩා, හොඳින් නම් කරන ලද කාර්යයන් කේත කියවීමේ හැකියාව වැඩි දියුණු කරන අතර [උදා] ඔබ “කෙසේද” ගැන උනන්දුවක් නොදක්වන සෑම අවස්ථාවකම භාවිතා කළ යුතුය, ක්‍රියාකාරී කොටසක “කුමක්ද” පමණි.

ඔබ කේතය කියවන අරමුණෙහි "කෙසේද" හෝ "කුමක්ද" යන්න ගැන ඔබ උනන්දු වන්නේද (උදා: සාමාන්‍ය අදහසක් ලබා ගැනීම එදිරිව. දෝෂයක් සොයා ගැනීම). ඔබ කේතය කියවන අරමුණ වැඩසටහන ලිවීමේදී ලබා ගත නොහැකි අතර විවිධ අරමුණු සඳහා ඔබ බොහෝ විට කේතය කියවනු ඇත; විවිධ තීරණ විවිධ අරමුණු සඳහා ප්‍රශස්ත කරනු ඇත.

එයින් කියැවුණේ, මම බොහෝ විට එකඟ නොවන ලොක්කාගේ දෘෂ්ටියේ කොටස මෙය බවයි.

විවරණයේ නම සමඟ ශ්‍රිතයක් ලියන්න එපා, ඉහත අදහස් දැක්වීමක් සමඟ ඔබේ සංකීර්ණ කේත රේඛාව (පේළි 3-4) තබන්න. මේ ආකාරයට ඔබට අසමත් වූ කේතය කෙලින්ම වෙනස් කළ හැකිය

මට ඇත්තටම මේ කාරණය පිටුපස ඇති හේතුව තේරුම් ගත නොහැකිය. [...] අදහස් වලට මූලික අඩුපාඩුවක් ඇත: ඒවා සම්පාදනය / අර්ථ නිරූපණය නොකෙරෙන අතර ඒකකය පරීක්ෂා කළ නොහැක. කේතය වෙනස් වන අතර අදහස් දැක්වීම තනි වන අතර ඔබ හරි දේ නොදැන සිටියි.

සම්පාදකයින් සමානාත්මතාවය සඳහා නම් පමණක් සංසන්දනය කරයි, ඔවුන් කිසි විටෙකත් ඔබට නොමඟ යවන දෝෂයක් ලබා නොදේ. එසේම, ඇමතුම් අඩවි කිහිපයක් විසින් යම් ශ්‍රිතයක් නමින් ආයාචනා කළ හැකි බැවින්, සමහර විට නමක් වෙනස් කිරීම වඩාත් දුෂ්කර හා දෝෂ සහිත වේ. අදහස් වලට මෙම ගැටළුව නොමැත. කෙසේ වෙතත්, මෙය තරමක් සමපේක්ෂනාත්මක ය; මෙය සැබවින්ම නිරාකරණය කිරීම සඳහා, ක්‍රමලේඛකයන්ට නොමඟ යවන අදහස් එදිරිව සහ නොමඟ යවන නම් යාවත්කාලීන කිරීමට වැඩි ඉඩක් තිබේද යන්න පිළිබඳ දත්ත අවශ්‍ය වනු ඇත, මට එය නැත.

මගේ මතය අනුව, ඔබට අවශ්‍ය ක්‍රියාකාරිත්වය සඳහා නිවැරදි කේතය:

phoneNumber = headers.resourceId || DEV_PHONE_NUMBER;

නැතහොත් ඔබට එය ශ්‍රිතයකට බෙදීමට අවශ්‍ය නම්, බොහෝ විට එවැනි දෙයක්:

phoneNumber = getPhoneNumber(headers);

function getPhoneNumber(headers) {
  return headers.resourceId || DEV_PHONE_NUMBER
}

නමුත් "නිෂ්පාදනයේ" සංකල්පය සමඟ ඔබට වඩාත් මූලික ගැටළුවක් ඇතැයි මම සිතමි. ඔබේ ක්‍රියාකාරිත්වයේ ගැටලුව isApplicationInProductionනම්, “නිෂ්පාදන” කාරණා වල පවතින එකම ස්ථානය මෙය බව අමුතු බවක් පෙනෙන්නට තිබීම සහ ඔබට පැවසීමට සම්පත් අයිඩී ශීර්ෂය තිබීම හෝ නොපැවතීම මත ඔබට සැමවිටම විශ්වාසය තැබිය හැකිය. පරිසරය කෙලින්ම පරීක්ෂා කරන පොදු isApplicationInProductionක්‍රමයක් හෝ getEnvironmentක්‍රමයක් තිබිය යුතුය . කේතය මෙසේ විය යුතුය:

function isApplicationInProduction() {
  process.env.NODE_ENV === 'production';
}

එවිට ඔබට දුරකථන අංකය ලබා ගත හැකිය:

phoneNumber = isApplicationInProduction() ? headers.resourceId : DEV_PHONE_NUMBER;

වෙඩි උණ්ඩ දෙකක් ගැන අදහස් දක්වන්න

• කුඩා කාර්යයන් ලිවීම වේදනාවක් වන්නේ කේතය කරන්නේ කුමක්දැයි බැලීමට එක් එක් කුඩා ශ්‍රිතයට යාමට එය බල කරන බැවිනි.
• ප්‍රධාන ලූපය පේළි 300 ට වඩා වැඩි වුවද සෑම දෙයක්ම ප්‍රධාන විශාල පුඩුවක් තුළට දමන්න, එය කියවීමට වේගවත් වේ.

බොහෝ සංස්කාරකවරුන් (උදා: IntelliJ) Ctrl- ක්ලික් කිරීම මඟින් ඔබට ශ්‍රිතයකට / පන්තියකට යාමට ඉඩ දෙනු ඇත. ඊට අමතරව, කේතය කියවීම සඳහා ඔබ බොහෝ විට ශ්‍රිතයක ක්‍රියාත්මක කිරීමේ තොරතුරු දැන ගැනීමට අවශ්‍ය නොවන අතර එමඟින් කේත කියවීම වේගවත් කරයි.

මම ඔබේ ලොක්කාට කියමි. ඔහු ඔබේ අවවාදයට කැමති වන අතර එය නායකත්වය ලෙස දකිනු ඇත. ආචාරශීලී වන්න.