ශුන්‍ය-දෝෂ ක්‍රමලේඛකයෙකු වන්නේ කෙසේද? [වසා ඇත]


168

මගේ ලොක්කා නිතරම මට පවසා ඇත්තේ හොඳ ක්‍රමලේඛකයෙකුට ඔහු හෝ ඇය වෙනස් කරන කේතය විශ්වාසදායක, නිවැරදි සහ තරයේ ස්වයං සත්‍යාපනය බව සහතික කිරීමට හැකි විය යුතු බවයි; ඔබගේ වෙනස්වීම් වලට හේතු වන සියලු ප්‍රති results ල සහ බලපෑම් ඔබ සම්පූර්ණයෙන්ම වටහා ගත යුතුය. නැවත නැවතත් පරීක්‍ෂා කිරීමෙන් මම මේ ආකාරයේ ක්‍රමලේඛකයෙකු වීමට උපරිම උත්සාහයක් ගත්තෙමි, නමුත් දෝෂ තවමත් පවතී.

මම ශුන්‍ය-දෝෂ ක්‍රමලේඛකයෙකු විය හැක්කේ කෙසේද සහ මගේ කේතයේ සෑම චරිතයක්ම බලපාන්නේ කෙසේද සහ දැන ගන්නේ කෙසේද?


මා හැර අන් කිසිවෙකු පළමු වරට පරිපූර්ණ කේතයක් නිර්මාණය නොකරයි. නමුත් මා සිටින්නේ එක් කෙනෙක් පමණි. - තාක්ෂණික කථාව: ලිනස් ටොවල්ඩ්ස්, ගූගල්, 2007 අගෝස්තු 15 izquotes.com/quote/273558
ජෙන්ස්


0-දෝෂ වැඩසටහන්කරණය වැනි දෙයක් නොමැත. එයට හේතුව තේරුම් ගැනීමට ගණිත ian ගොඩෙල් කියවන්න.
මයිකල් මාටිනස්

එය වැරදි ඉලක්කයකි, බලන්න: yegor256.com/2015/06/18/good-programmers-bug-free.html
yegor256

Answers:


364

කිසිසේත් කේත නොකරන්න.

ඔබට ශුන්‍ය දෝෂ ක්‍රමලේඛකයෙකු විය හැකි එකම ක්‍රමය එයයි.

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


73
+1 පසු විපරම: නැතහොත් ඔබට කේතීකරණ නොවන (ඇත් දළ කුළුණ) ගෘහ නිර්මාණ ශිල්පියෙකු විය හැකි අතර තවමත් විශාල මුදලක් ගෙවිය හැකිය! ඒක තමයි හොඳම.
මාටින් වික්මන්

26
වැරදි කිරීම මනුෂ්‍යයෙකි, ඔබේ දෝෂ දිව්‍යමය ලෙස නිවැරදි කිරීමට.
වෝඩ් මියුලර්ට්

11
මම නිතරම සම-සේවකයෙකු සමඟ ලොක්කාගේ ප්‍රසාදය දිනා ගත්තෙමි. ඇය එය කළේ කෙසේද? සරල, ඇය තමාට අවශ්‍ය නැති දෝෂ වෙනත් කෙනෙකුට පවරා දුන් අතර සෑම විටම පහසුම / කුඩාම අංගයන් ලබා ගත්තාය.
ටෝබි

46
එය මුලින් කීවේ කවුදැයි මම නොදනිමි, නමුත්, "නිදොස්කරණය යනු දෝෂ ඉවත් කිරීමේ ක්‍රියාවලිය නම්, ක්‍රමලේඛනය ඒවා දැමීමේ ක්‍රියාවලිය විය යුතුය."
ru ස් ඇල්ඩර්මන්

8
ඊටත් වඩා හොඳයි: කිසිම දෙයකට වගකීම භාර නොගෙන ලොක්කෙකු වී ඔබේ යටි පතුල් කාලකණ්ණි බවක් ඇති කරන්න.
biziclop

123

සුළු නොවන වැඩසටහනක් සඳහා ශුන්‍ය දෝෂ කළ නොහැක.

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

මෙම මෘදුකාංගය දෝෂ රහිත ය. මිනිසා පරිපූර්ණ කර ඇති තරමට එය පරිපූර්ණයි. මෙම සංඛ්‍යාලේඛන සලකා බලන්න: වැඩසටහනේ අවසාන අනුවාද තුන - පේළි 420,000 ක් දිග - එක් දෝෂයක් පමණි. මෙම මෘදුකාංගයේ අවසාන අනුවාද 11 හි දෝෂ 17 ක් තිබුණි.

ගෝලීය ස්ථානගත කිරීමේ චන්ද්‍රිකා සමඟ සැරිසැරීමට ෂටලයට අවසර දීම සඳහා මෘදුකාංගය වැඩිදියුණු කිරීම, වැඩසටහනේ 1.5% ක් හෝ කේත පේළි 6,366 ක් ඇතුළත් වෙනසක්. එම එක් වෙනසක් සඳහා පිරිවිතර පිටු 2500 ක් ධාවනය වන අතර එය දුරකථන පොතකට වඩා er නකමකි. වත්මන් වැඩසටහන සඳහා පිරිවිතරයන් වෙළුම් 30 ක් පුරවා පිටු 40,000 ක් ධාවනය කරයි.


3
කළ නොහැකි දෙයක් නොවේ. නමුත් බොහෝ දුරට ඉඩක් නැත.
බිලී ඔනේල්

36
FB දෝෂ රහිත යැයි ඔබ සිතන්නේ කුමක් ද? ෆේස්බුක් හි ආරක්ෂාව සහ රහස්‍යතා ආකෘතිය එක් විශාල දෝෂයකි. උදාහරණයක් ලෙස, ආරක්ෂක දුර්වලතා හේතුවෙන් ෆේස්බුක් ලොක්කන්ගේ ෆේස්බුක් ගිණුම පසුගිය සතියේ හැක් කරන ලදී.
ස්ටීවන් සී

6
Ala ඉලේන් ෆේස්බුක් හි දර්ශනය වන්නේ “වේගයෙන් ගොස් දේවල් කඩන්න” ( geek.com/articles/news/… ) සහ ඔවුන් සතුව අසංඛ්‍යාත දෝෂ ( facebook.com/board.php?uid=74769995908 ) ඇත. මා තුළට. ට්විටර් වෙනස් නොවේ, නිතර පහතට වැටීම සඳහා ප්‍රසිද්ධයි ( Engineering.twitter.com/2010/02/anatomy-of-whale.html ) සහ “follow bug” ( status.twitter.com/post/587210796/… ).
යෙව්ගනි බ්‍රික්මන්

9
චලනය වන ඉලක්ක කණු අමතක නොකරන්න. ඔබගේ PerfectProgram 1.0 හි ඇති අංගයක් 2.0 හි දෝෂයක් විය හැකිය
කාලෝස්

4
OdesCodesInChaos: න්‍යාය පවසන්නේ ඔවුන්ගේ හැසිරීම ඔප්පු කිරීමට නොහැකි වැඩසටහන් පවතින බවයි . සියලුම වැඩසටහන් වල හැසිරීම ඔප්පු කළ නොහැකි බව එය නොකියයි . පොදු වැඩසටහන් වලින් බහුතරයක් ඔප්පු කළ හැකි ආකාරයේ ඒවා යැයි මම අනුමාන කරමි. “නතර කිරීමේ ගැටලුව නිසා මගේ කේතය දෝෂ රහිතව පැවතිය නොහැක” යනුවෙන් ප්‍රකාශ කිරීම න්‍යායේ වැරදි යෙදුමකි.
එන්ඩොලිත්

98

"සීරෝ-බග් ක්‍රමලේඛකයා" යනු නිහ silent ගායකයෙකු මෙන් ඔක්සිමොරොන් ය, නමුත් පසුගිය අවුරුදු 60 ක් හෝ ඊට වැඩි වැඩසටහන් මඟින් ආසවනය කළ ප්‍රාර්ථනාවන් කිහිපයක් නිපදවා ඇති අතර එමඟින් ඔබ වඩා හොඳ ක්‍රමලේඛකයෙකු වනු ඇත:

  • නිහතමානී වන්න - ඔබ වැරදි කරන අතර. නැවත නැවතත්.
  • ඔබේ හිස් කබලේ සීමිත ප්‍රමාණය ගැන හොඳින් දැනුවත් වන්න. සම්පූර්ණ නිහතමානීව කර්තව්‍යයට එළඹෙන්න, වසංගතය වැනි දක්ෂ උපක්‍රම වලින් වළකින්න. [එඩ්ජර් ඩිජ්ක්ස්ට්‍රා]
  • සංයුක්ත පිපිරීමට එරෙහිව සටන් කරන්න
  • විකෘති තත්වයෙන් මිදෙන්න (හැකි සෑම විටම). ඔව්, ක්‍රියාකාරී වැඩසටහන් ඉගෙන ගන්න.
  • හැකි කේත මාර්ග ගණන අඩු කරන්න
  • ආදාන සහ ප්‍රතිදාන අවකාශයේ (ඔබේ ක්‍රියාකාරිත්වයේ) ප්‍රමාණය තේරුම් ගන්න (විශාලත්වය), සහ 100% පරීක්ෂණ ආවරණයක් වෙත ළංවීම සඳහා ඒවා අඩු කිරීමට උත්සාහ කරන්න
  • ඔබේ කේතය ක්‍රියාත්මක නොවන බව සැමවිටම උපකල්පනය කරන්න - වෙනත් ආකාරයකින් එය ඔප්පු කරන්න!

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

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

AtMatthieu M.: පරීක්‍ෂණයෙන් ඔප්පු වන්නේ ඔබ බලාපොරොත්තු වන ආකාරයට දේවල් ක්‍රියාත්මක වන බවයි. සියලු අයිතම ඔබ බලාපොරොත්තු වන ආකාරයට ක්‍රියාත්මක වන බව ඔබට ඔප්පු කළ හැකි නම්, එතැන් සිට ඔබ බලාපොරොත්තු නොවූ ආදාන හැසිරීම සමඟ කටයුතු කරන බව ඔප්පු වේ. එම හැසිරීම කුමක්ද සහ එය කුමක් විය යුතුද යන්න ඔබ ඇණ ගැසූ පසු, ඔබ ඒ සඳහා නව පරීක්ෂණයක් ලියයි. එය දැන් ඔබ අපේක්ෂිත හැසිරීමේ කොටසකි.
deworde

1
worddeworde: පරීක්‍ෂා කිරීමේ අදහස මට වැටහී ඇත, කෙසේ වෙතත් වැදගත් අවස්ථාවන් හැරුණු විට, මා විසින් සිදු කරන ලද සැබෑ කාර්යයන් බහුතරයක් පරිපූර්ණ ලෙස පරීක්‍ෂා කළ නොහැකි විය, මන්දයත් හැකි සංයෝජන ගණන ඉතා විශාල නිසා (සහ මම එකතු නොකරමි කාල ගැටළු). එබැවින්, නිකේතන තත්වයන් හැරුණු විට, පරීක්ෂණ පමණක් දුර ගොස් ඇත (අවම වශයෙන් නාමික නඩුව සමත් දැයි පරීක්ෂා කිරීම තවමත් ප්‍රයෝජනවත් වේ!)
මැතිව් එම්.

"වසංගතය වැනි දක්ෂ උපක්‍රම වලින් වළකින්න" - මෙය පමණක් මෙම හොඳ පිළිතුර ලබා දෙනු ඇත. එය මෙන් - එය විශිෂ්ටයි.
BЈовић

25

TDD

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

TDD ප්රවේශය අවම වශයෙන් ප්රතිලාභ දෙකක් වත් ලබා දෙයි.

  • සියලුම කේත ලියා ඇත්තේ විශේෂිත අංගයක් නිරාකරණය කිරීම සඳහා වන අතර එමඟින් අනවශ්‍ය අධි නිෂ්පාදනයක් නොමැත.
  • ඔබ පවතින කේත රේඛාවක් වෙනස් කරන සෑම විටම, ඔබ අංගයක් බිඳ දැමුවහොත් ඔබට දන්වනු ලැබේ

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

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

TDD හි හොඳ සංවර්ධන කණ්ඩායම් විසින් අඩුපාඩු සහිතව කේතය ලබා දෙන බව මම විශ්වාස කරමි.


19

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

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


1
+1. විකෘති සහෝදරියගේ වචන වලින්, ඔබ නොදන්නා දේ ඔබට රිදවිය හැකිය / ඔබට නොපෙනෙන දේ ඔබව කෑගසයි.
ඉංජිනේරු

17

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

  • මෙය පහසු නැත. ඔබ රාත්‍රිය පුරා දියුණු නොවනු ඇත. එබැවින් අධෛර්යමත් නොවන්න.
  • අඩුවෙන් ලියන්න, වඩා දක්ෂ ලෙස ලියන්න. අඩු කේතය සාමාන්‍යයෙන් වඩා හොඳ කේතයකි. කල්තියා සැලසුම් කර නියම මෝස්තර රටා සැකසීමට උත්සාහ කිරීම ස්වාභාවිකය, නමුත් දිගු කාලීනව ඔබට අවශ්‍ය දේ ලිවීමෙන් කාලය ඉතිරි වන අතර දෝෂ වළක්වයි.
  • සංකීර්ණත්වය සතුරා ය. එය අපැහැදිලි සංකීර්ණ අවුලක් නම් අඩු නොවේ. කේත ගොල්ෆ් විනෝදජනක නමුත් එය තේරුම් ගැනීමට අපායක් වන අතර නිදොස් කිරීම වඩාත් නරක නිරයකි. ඔබ සංකීර්ණ කේතයක් ලියන සෑම විටම ඔබ ගැටළු සහිත ලෝකයකට විවෘත වේ. දේවල් සරල හා කෙටි කරන්න.
  • සංකීර්ණත්වය ආත්මීය ය. ඔබ වඩා හොඳ ක්‍රමලේඛකයෙකු බවට පත් වූ පසු වරක් සංකීර්ණ වූ කේතය සරල වේ.
  • අත්දැකීම් කාරණා. වඩා හොඳ ක්‍රමලේඛකයෙකු වීමට ක්‍රම දෙකෙන් එකක් වන්නේ පුහුණුවීමයි. පුහුණුව යනු ඔබ පහසුවෙන් ලිවිය යුතු වැඩසටහන් ලිවීම නොවේ, එය වැඩසටහන් ලිවීම ටිකක් රිදවන අතර ඔබ සිතීමට සලස්වයි.
  • වඩා හොඳ වීමට අනෙක් ක්‍රමය කියවීමයි. ඉගෙනීම සඳහා ක්‍රමලේඛනයේ දුෂ්කර මාතෘකා රාශියක් ඇති නමුත් ඔබට ඒවා කිසි විටෙකත් ක්‍රමලේඛනය මඟින් ඉගෙන ගැනීමට නොහැකි වනු ඇත, ඔබ ඒවා අධ්‍යයනය කළ යුතුය. ඔබ අමාරු දේවල් කියවිය යුතුය. ආපදා පිරිසිදු කිරීමෙන් ඔබට ඉගෙන ගැනීමට අවශ්‍ය නම් මිස කේතය ලිවීමෙන් එය නිවැරදිව ඉගෙන ගත නොහැක. ඔබ විශ්වාස නොකරන්නේ නම්, ගොකර් වැනි වීර කාව්‍යයන් දෙස බලන්න. ආරක්‍ෂාව නිවැරදිව කරන්නේ කෙසේදැයි ඉගෙන ගැනීමට ඔවුන් කාලය ගත කළ අතර, වැඩ කළ දෙයක් පමණක් නොව, එම අවුල කිසි විටෙකත් සිදු නොවනු ඇත.
  • බ්ලොග් කියවන්න. රසවත් බ්ලොග් ටොන් ගණනක් එහි ඇති අතර එය ක්‍රමලේඛනය දෙස බැලීමට හා සිතීමට නව හා රසවත් ක්‍රම ලබා දෙනු ඇත.
  • අපිරිසිදු විස්තර ඉගෙන ගන්න. ඔබගේ භාෂාවේ අපැහැදිලි කොටස් සහ යෙදුම් වැඩ පිළිබඳ සුළු තොරතුරු ඉතා වැදගත් වේ. සංකීර්ණ කේත ලිවීමෙන් වැළකී සිටීමට ඔබට උදව් වන රහස් ඔවුන් සතුව තිබිය හැකිය, නැතහොත් ඔබට වළක්වා ගත යුතු දෝෂ ඇති කොටස් විය හැකිය.
  • පරිශීලකයින් සිතන ආකාරය ඉගෙන ගන්න. සමහර විට ඔබේ පරිශීලකයින් උමතු වී ඇති අතර ඔබට නොතේරෙන සහ පුරෝකථනය කළ නොහැකි ආකාරයකින් ඔබේ යෙදුම සමඟ ක්‍රියා කරනු ඇත. ඔවුන් උත්සාහ කළ හැකි ආගන්තුක දේවල් දැන ගැනීමට සහ ඔබේ යෙදුමට එය හැසිරවිය හැකි බවට වග බලා ගැනීමට ඔබ ඔවුන්ගේ හිසට ඇතුල් විය යුතුය.

8

පුද්ගලිකව මම සිතන්නේ දෝෂ රහිත වැඩසටහන් සඳහා උත්සාහ කිරීම වඩා මිල අධික බව පෙනේ (කාලය හා මුදල් යන දෙකින්ම). බිංදුවට හෝ ශුන්‍යයට ආසන්න දෝෂයකට ලඟාවීම සඳහා, සංවර්ධකයින් හොඳින් පරීක්ෂා කර බැලිය යුතුය. පැච් සමාලෝචනය සඳහා ඕනෑම කේතයක් ඉදිරිපත් කිරීමට පෙර ප්‍රතිගාමී සියල්ල පරීක්ෂා කරයි. මෙම ආකෘතිය පිරිවැය .ලදායී යැයි මට පහර දෙන්නේ නැත. සංවර්ධකයින් නිසි කඩිසර පරීක්ෂණයක් පවත්වා ගැඹුරු පරීක්ෂාව QA කණ්ඩායම දක්වා තබන්න. මෙන්න හේතුව:

  • සංවර්ධකයින් පරීක්ෂා කිරීමේදී උරා බොයි. එය සත්‍යයක් වන අතර ඔබ එය දනී. (මම සංවර්ධකයෙක්!) හොඳ QA කණ්ඩායමක් සෑම විටම සංවර්ධකයින් කිසි විටෙකත් නොසිතන අද්විතීය අවස්ථා සොයා ගනී.
  • සංවර්ධකයින් කේතීකරණයේදී දක්ෂයි. ඔවුන් විශිෂ්ටත්වයට පත්වන දේ වෙත ආපසු යාමට ඔවුන්ට ඉඩ දෙන්න (සාමාන්‍යයෙන් ඔවුන් කෙසේ හෝ කිරීමට කැමති දේ.)
  • QA කණ්ඩායමට එක් වර්‍ගයකින් බහු සංවර්ධක කාර්යයන් හා සම්බන්ධ දෝෂ සොයාගත හැකිය.

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

සම වයස් සමාලෝචන සහ / හෝ පරීක්ෂාවකින් තොරව පළමු වරට සෑම විටම ඔවුන්ගේ කාර්යය නිවැරදිව ඉටු කරන වෘත්තීන් කීයක් නම් කළ හැකිද?


8

ශුන්‍ය දෝෂ? ඔබට ලිස්ප් අවශ්‍ය බව පෙනේ (සංශයවාදී මාවත අනුගමනය කර සංගීත වීඩියෝවෙන් වළකින්න).

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

කේතය ඔබට හැකි තරම් සරල ලෙස තබා ගැනීමෙන් දෝෂ වළක්වා ගත හැකිය .

ඔබ කේත විශ්ලේෂණ මෙවලම් භාවිතා කරන බවට වග බලා ගන්න ( FindBugs , PMD සහ යනාදිය) - දැඩි සම්පාදක අනතුරු ඇඟවීම් සමඟ ඒකාබද්ධව - ඔබේ කේතය සමඟ ඇති සියලු ආකාරයේ ගැටළු හෙළි කරනු ඇත. ඔවුන් ඔබට පවසන දේ සැලකිල්ලට ගන්න, දෝෂයේ ස්වභාවය කුමක්දැයි වටහා ගැනීමට සැබවින්ම උත්සාහ කරන්න, ඉන්පසු ඔබේ දෝෂය නැවත හඳුන්වා දෙන ආකාරයට කේත කිරීම අස්වාභාවික යැයි හැඟෙන පරිදි ඔබේ ක්‍රමලේඛන මෝඩකම වෙනස් කිරීමට පියවර ගන්න.


3
සමහර විට දෝෂ එහි සැඟවුණු රාක්ෂයන් හා සමාන ය, මගේ නැවත නැවත පරීක්‍ෂා කිරීමේදී සහ ස්වයං කේත සමාලෝචනයේදී ඒවා සැඟවී ඇත ... නමුත් මම සම-සමාලෝචනය කළ විට, රාක්ෂයන් ඇදහිය නොහැකි ලෙස පෙනෙන බව මට පෙනී ගොස් හදිසියේම මා වෙතට පැන්නා. එය ඇත්තෙන්ම අමුතුයි. මිනිසාගේ 'ඇස' සහ 'මොළය' මත පමණක් පදනම්ව දෝෂ රහිත රේඛාව ස්පර්ශ කළ නොහැකි බව පෙනේ. සියලුම අවස්ථා සඳහා ඒකක පරීක්ෂණය ක්‍රියාත්මක කළ නොහැක. කේත විශ්ලේෂණ මෙවලම්? මම එය කිසි විටෙකත් භාවිතා කර නැත, මම එම ක්ෂේත්‍රය පිළිබඳ පර්යේෂණ කරන්නෙමි.
ඉලේන්

මම කියන්නේ ඔබට ඇඩා අවශ්‍යයි, නමුත් ලිස්ප් වඩාත් විනෝදජනකයි. ;-)
කක්ෂගත කිරීම

1
@ ඉලේන් මා වැඩ කරන ස්ථානය ජාවා පරිසරයක් වන අතර කේතය කණ්ඩායම සමඟ බෙදා ගත හැක්කේ එය ෆින්ඩ්බග්ස් සහ පීඑම්ඩී හරහා සමත් වී ඇත්නම් පමණි. නව කණ්ඩායම් සාමාජිකයින් අදියර පහක් පසු කරයි: ප්‍රතික්ෂේප කිරීම, කෝපය, කේවල් කිරීම, මානසික අවපීඩනය සහ පසුව පිළිගැනීම. පසුව ඔවුන් කිසි විටෙකත් ආපසු හැරී බලන්නේ නැත.
ගැරී රෝව්

@ ගැරී රෝව්, මට එම ප්‍රතික්‍රියා තේරෙනවා, lol, මම කවදා හෝ QA දෙපාර්තමේන්තුවක් ඇති සමාගමක සිට ඇති අතර, එහි සේවකයින් සතිපතා එම සතියේ නිපදවන ලද සියලුම කේත පරීක්ෂා කර බැලුවේ, කේතයේ සෑම පේළියක්ම රීතියට අනුකූලදැයි බැලීමටය. '(ඔවුන් Findbugs / PMD වැනි මෙවලම් භාවිතා කළේද යන්න ගැන මට කිසිම අදහසක් නැත), නමුත් එය ඔබ සිටින පියවරට මඳක් සමාන ය.
ඉලේන්

1
@ ගැරී: මගෙන් කිසිදු තර්කයක් නැත, නමුත් මා වැඩ කළ ස්ථාන කිහිපයක් විලාසිතාවේ උල්ලං lations නයන් දෝෂ සමානකම් ලෙස සලකයි. තවද ඔවුන් "සෑම පන්තියක්ම පැකේජය සහ පන්ති නම් අඩංගු ස්ථිතික ක්ෂේත්‍ර CLS_PKG සහ CLS_NAME ප්‍රකාශ කළ යුතුය" වැනි ශෛලීය නීති රීති වලට නැඹුරු විය. මම සාමාන්‍යයෙන් කේතීකරණ ප්‍රමිතීන්ට සහය දෙමි, නමුත් ඒවා ඒ වගේ දේවල් වලට බෙදෙන විට නොවේ!
ටීඑම්එන්

8

සියලුම "කිසිසේත් කේත නොකරන්න." පිළිතුරු සම්පූර්ණයෙන්ම කාරණය මග හැරී ඇත. එසේම, ඔබේ ලොක්කා නිසැකවම මෝඩයෙකු ලෙස නොපෙනේ!

ඔවුන්ගේ කේතය කරන්නේ කුමක්දැයි නොදැන සිටි ක්‍රමලේඛකයින් මා කොපමණ වාරයක් දැක ඇත්දැයි මට මතක නැත. ඔවුන්ගේ එකම සංවර්ධන දර්ශනය අත්හදා බැලීම සහ දෝෂයක් ලෙස පෙනෙන්නට තිබුණි (බොහෝ විට ඒවා පිටපත් කිරීම / ඇලවීම / වෙනස් කිරීම). අත්හදා බැලීම් සහ දෝෂයන් සමහර ගැටලු විසඳීමට වලංගු ක්‍රමයක් වන අතර, බොහෝ විට ඔබට ගැටළු වසම විශ්ලේෂණය කර ඔබ භාවිතා කරන මෙවලම් පිළිබඳ ඔබේ අවබෝධය මත පදනම්ව නිශ්චිත විසඳුමක් යෙදිය හැකි අතර මඳක් විනය හා කඩිසරකම ඔබට නොලැබෙනු ඇත. ඔබ පළමු වරට එය යෙදවීමට පෙර ගැටලුව පමණක් නොව බොහෝ මුලික අවස්ථා (විභව දෝෂ) ද විසඳීය. කේතය දෝෂ රහිත බවට ඔබට සහතික විය හැකිද? ඇත්ත වශයෙන්ම නැත. නමුත් ඔබ හමු වූ හෝ ඔබ ගැන කියවන සෑම දෝෂයක් සමඟම ඊළඟ වතාවේ යමක් ලිවීමේදී / වෙනස් කිරීමේදී ඔබට සිතීමට අවශ්‍ය දේවලට එය එකතු කළ හැකිය. ඔබ මෙය කරන්නේ නම් දෝෂ රහිත කේත ලිවිය යුතු ආකාරය පිළිබඳ අත්දැකීම් රාශියක් ඔබට ලැබෙනු ඇත. - ගමනේ දී ඔබට උදව් කළ හැකි වඩා හොඳ ක්‍රමලේඛකයෙකු වන්නේ කෙසේද යන්න පිළිබඳ සම්පත් ටොන් ගණනක් තිබේ ...

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

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


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

7

අනෙක් අදහස් දැනටමත් නිවැරදිව පෙන්වා දී ඇති පරිදි, දෝෂ නොමැතිව සුළු නොවන මෘදුකාංගයක් නොමැත.

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

ඔබගේ සේවා වසම මත පදනම්ව, ඔබේ මෘදුකාංගය විධිමත් ලෙස සත්‍යාපනය කිරීමට උත්සාහ කළ හැකිය. විධිමත් ක්‍රම භාවිතා කිරීමෙන් ඔබේ මෘදුකාංගය පිරිවිතරයන්ට හරියටම ගැලපෙන බව ඔබට සහතික විය හැකිය.

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

එබැවින් "දෝෂ" පිළිබඳ ඔබේ අර්ථ දැක්වීම අනුව ඔබට විධිමත් සත්‍යාපනය කිරීමට උත්සාහ කළ හැකිය, නැතහොත් ඔබේ මෘදුකාංගයේ ඔබට හැකි තරම් දෝෂ සොයා ගැනීමට උත්සාහ කරන්න.


6

එක්කෝ "හෙලෝ වර්ල්ඩ්" ට වඩා සංකීර්ණ කිසිවක් ලියන්න එපා. නැතහොත් ඔබ එය සෑම විටම භාවිතා නොකරන ලෙස සෑම කෙනෙකුටම පැවසුවහොත්.

මෙම ඊනියා දෝෂ රහිත කේතයේ උදාහරණ කිහිපයක් ඔබේ ලොක්කාගෙන් විමසන්න.


5

මම අනෙක් අය සමඟ එකඟ වෙමි. මෙන්න මම ගැටලුවට එළඹෙන ආකාරය

  • පරීක්ෂකයෙකු ලබා ගන්න. එයට හේතුව ජොයෙල් පරීක්ෂණය බලන්න.
  • පුස්තකාල පුළුල් ලෙස භාවිතා කරන්න; බොහෝ විට නිදොස්කරණය කර ඇත. මම පර්ල් වෙනුවෙන් CPAN හි විශාල රසිකයෙක්මි.

1
… නමුත් ඔබ පුස්තකාල භාවිතා කරන්නේ නම්, ඔවුන්ගේ දෝෂවලට ඔබව ඇදගෙන යා නොහැකි බවට වග බලා ගන්න (නිදසුනක් ලෙස, මූලාශ්‍රය තිබීමෙන් ඔබට එය විගණනය කිරීමට හෝ අවශ්‍ය නම් දෝෂ නිවැරදි කිරීමට).
මිලේනෝමි

5

ඔබට ශුන්‍ය දෝෂ ක්‍රමලේඛකයෙකු වීමට උත්සාහ කළ හැකිය. මම කේත ලිවීමේදී ශුන්‍ය දෝෂ ක්‍රමලේඛකයෙකු වීමට උත්සාහ කරමි. කෙසේ වෙතත්, මම නැහැ

  • බහුවිධ පරීක්ෂණ ක්‍රමවේදයන් (ATDD හැර)
  • අපගේ මෘදුකාංගයේ විධිමත් සත්‍යාපන නිර්මාණය කරන්න
  • වෙනම QA කණ්ඩායමක් ඇත
  • කේත පදනමට කරන ලද සෑම වෙනස්කමක් පිළිබඳවම දැඩි විශ්ලේෂණයක් කරන්න
  • ආරක්ෂාව සහ පරෙස්සම් වීම කෙරෙහි වැඩි නැඹුරුවක් දක්වන භාෂාවක් භාවිතා කරන්න

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

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

මෘදුකාංගයේ අපේක්ෂිත භාවිතයට සහතික කිරීමේ මට්ටමට මම ගැලපේ. ඔබ කේතය ලියන්නේ නම් නාසා ෂටලය භාවිතා කරනු ඇත්තේ දෝෂ ඉවසීම සාධාරණ විය හැකිය. ඔබට අවශ්‍ය වන්නේ අතිරේක හා ඉතා මිල අධික භාවිතයන් සමූහයකි.


4

"ශුන්‍ය-දෝෂ" ක්‍රමලේඛකයෙකු වීමට හොඳ පළමු පියවර වන්නේ දෝෂ පිළිබඳ ඔබේ ආකල්පය වෙනස් කිරීමයි. "ඒවා සිදු වේ", "වඩා හොඳ QA සහ පරීක්ෂකයින් ලබා ගන්න" හෝ "සංවර්ධකයින් පරීක්‍ෂා කිරීමේදී උරා බොයි" යනුවෙන් පවසන දේ වෙනුවට: කියන්න:

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

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


2

එක අතෙකින් ඔබේ ලොක්කා හරි. දෝෂ බිංදුවට ළඟා වන මෘදුකාංගයක් ලිවිය හැකිය.

නමුත් ගැටළුව වන්නේ ශුන්‍ය-දෝෂ වැඩසටහන් ලිවීමේ පිරිවැය (පාහේ) ශුන්‍ය දෝෂ සහිත වීමයි. ඔබ මෙවැනි දේ කළ යුතුයි:

  • ඔබේ අවශ්‍යතා පිළිබඳ විධිමත් පිරිවිතර භාවිතා කරන්න. විධිමත්, Z හෝ VDM හෝ වෙනත් ගණිතමය ශබ්ද අංකනයක් භාවිතා කරන ආකාරයට.

  • ඔබේ වැඩසටහන පිරිවිතරයන් ක්‍රියාත්මක කරන බව විධිමත් ලෙස ඔප්පු කිරීමට ප්‍රමේයය ඔප්පු කිරීමේ ක්‍රම භාවිතා කරන්න.

  • දෝෂ සඳහා වන සෑම මාර්ගයක්ම පරීක්ෂා කිරීම සඳහා පුළුල් ඒකකයක්, ප්‍රතිගාමී සහ පද්ධති පරීක්ෂණ කට්ටල සහ පටි සාදන්න. (මෙය පමණක් ප්‍රමාණවත් නොවේ.)

  • ඇති බොහෝ අය (විධිමත් හා අවිධිමත්) අවශ්යතා, මෘදුකාංග (ආයාසයෙන්) සමාලෝචනය කරන්න. පරීක්ෂණ සහ යෙදවීම්.

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


1

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


1

දෝෂ රහිත වැඩසටහනක් කිරීමට පියවර මෙන්න:

  1. ඔබේ ක්‍රියාකාරීත්වය සඳහා නිශ්චිත පිරිවිතරයන් නොමැති නම් කිසි විටෙකත් කේතීකරණය ආරම්භ නොකරන්න.
  2. පරීක්‍ෂා නොකරන්න, නැතහොත් මෘදුකාංගයේ අඩුපාඩු හඳුනා ගැනීමට ඔබ පරීක්‍ෂා නොකරන්න.
  3. පරීක්ෂණ, සමාලෝචන සහ නිෂ්පාදනයේදී සොයාගත් අඩුපාඩු වලින් සියලු ෆීඩ්බැක් ක්‍රියාවලියකට යොදන්න. අඩුපාඩු සොයාගත් වහාම සියලු දෝෂ සහිත සංරචක සම්පූර්ණයෙන්ම ඉවතලන්න. ඔබගේ පිරික්සුම් ලැයිස්තු යාවත්කාලීන කර ඔබේ සංවර්ධකයින් නැවත පුහුණු කරන්න එවිට ඔවුන් නැවත එවැනි වැරදි නොකරනු ඇත.

පරීක්ෂණයෙන් ඔප්පු කළ හැක්කේ ඔබට දෝෂ ඇති බව පමණි, නමුත් වෙනත් ආකාරයකින් ඔප්පු කිරීම නිෂ් less ල ය. ප්‍රතිපෝෂණය සම්බන්ධයෙන් - ඔබ සතුව කාසි සාදන යන්ත්‍රයක් තිබේ නම් සහ සෑම 10s කාසියකම සාමාන්‍යයෙන් අඩුපාඩුවක් තිබේ. ඔබට එම කාසිය රැගෙන එය සමතලා කර නැවත යන්ත්‍රයට ඇතුළු කළ හැකිය. ප්‍රතිචක්‍රීකරණය කළ හිස් හිස් කාසිය එතරම් හොඳ නොවනු ඇත, නමුත් සමහර විට පිළිගත හැකිය. සෑම 100 දශකයේම කාසියක් නැවත වරක් මුද්දර දැමිය යුතුය. යන්ත්රය සවි කිරීම පහසු වේද?

අවාසනාවට මිනිසුන් යන්ත්‍ර නොවේ. හොඳ, අඩුපාඩු රහිත ක්‍රමලේඛකයෙකු බවට පත් කිරීම සඳහා ඔබ විසින් සිදු කරන ලද සෑම අඩුපාඩුවක් සඳහාම බොහෝ කාලයක්, පුහුණුවක් සහ පුනරාවර්තනයක් කළ යුතුය. බොහෝ විට ප්‍රායෝගිකව ඉගෙනීමට හා අදාළ කර ගැනීමට අපහසු වන විධිමත් සත්‍යාපන ක්‍රම පිළිබඳව සංවර්ධකයින් පුහුණු කළ යුතුය. මෘදුකාංග සංවර්ධනයේ ආර්ථික විද්‍යාව ද ඊට එරෙහිව කටයුතු කරයි - ක්‍රමලේඛකයෙකු වෙනත් සේවා යෝජකයෙකු වෙත පනිනවා දැකීම සඳහා අඩුපාඩුකම් කළ හැකි පුහුණුකරුවෙකු පුහුණු කිරීම සඳහා ඔබ වසර 2 ක් ආයෝජනය කරනවාද? ඔබට පරිපූර්ණ කාසි සාදන යන්ත්‍රයක් මිලදී ගත හැකිය, නැතහොත් තවත් කේත වඳුරන් 10 දෙනෙකු කුලියට ගෙන එකම පිරිවැයකින් පරීක්ෂණ පොකුරක් නිර්මාණය කළ හැකිය. මෙම පරිපූර්ණ ක්‍රියාවලිය ඔබේ “යන්ත්‍රය” ලෙස ඔබට වටහා ගත හැකිය, ඔබේ වත්කම - විශිෂ්ට සංවර්ධකයින්ගේ පුළුල් පුහුණුවක් සඳහා ආයෝජනය කිරීම සාර්ථක නොවේ.

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


පැහැදිලි පිරිවිතර සඳහන් කිරීම සඳහා +1. මෙය අවුරුදු 2 ක් පැරණි මාතෘකාවක් බව මම දනිමි, නමුත් දෝෂයක් ක්‍රමලේඛන අසමත්වීමකට සමාන යැයි උපකල්පනය කිරීම වැරදි බව පෙන්වා දීමට ඇති එකම පිළිතුර ඔබේ බව මම අවධාරණය කළ යුතුය.
බ්‍රැන්ඩන්

0

ආරක්ෂිතව වැඩසටහන: http://en.wikipedia.org/wiki/Defensive_programming

යමෙකු ක්‍රමලේඛනයේ සම්ප්‍රදායන් ආරක්ෂාකාරීව අනුගමනය කරන්නේ නම්, වෙනස්කම් පහසුවෙන් සොයාගත හැකිය. සංවර්ධනයේදී දැඩි දෝෂ වාර්තා හා ඩොක්සිජන් වැනි documentation න ලියකියවිලි සමඟ මෙය ඒකාබද්ධ කරන්න, ඔබේ කේත සියල්ලම කරන්නේ කුමක්ද යන්න හරියටම දැන ගැනීමට සහ ඉදිරියට එන ඕනෑම දෝෂ ඉතා කාර්යක්ෂමව නිවැරදි කිරීමට ඔබට හැකි විය යුතුය.


0

මෙය හොඳ දෙයක් වරදවා වටහා ගැනීමේ ප්‍රති result ලයක් විය හැකිද? පමණක් Generic බලපත්රය යටතේ අවසර ලබා ඇත boneheadedness ක්රමවේදය නොව,?

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

ඔබට ඒවා සොයාගෙන ඒවා නිවැරදි කළ හැකි තාක් කල් දෝෂ සෑදීම හොඳයි (හේතුව තුළ, ඇත්ත වශයෙන්ම).


0

මෘදුකාංග පරීක්ෂණයේ මූලික සංකල්පවලින් එකක් නම්, වැඩසටහන පරිපූර්ණ බව ඔබට කිසි විටෙකත් සහතික විය නොහැක. ඔබට එය සදහටම වලංගු කළ හැකිය, නමුත් කිසි විටෙකත් වැඩසටහන සම්පුර්ණ බව ඔප්පු නොකරන්නේ එය සියලු ආදාන / විචල්‍ය සංයෝජනයන්ට එරෙහිව පරීක්ෂා කිරීමට පවා ඉක්මනින් නොහැකි බැවිනි.

ඔබේ ලොක්කා "ක්‍රමලේඛනය පිළිබඳ එතරම් අමාරු දේ නොතේරෙන අයෙකු මෙන් පෙනේ, එය යතුරු ලියනය කළ බැවින්"


0

අපි ලොකු මෘදුකාංග නිවාස උපකල්පනය නම් දන්නේ (දී මෙන් ම ඉහළ පෙළේ සංවර්ධකයින් ලබා ගැනීමට ආකාරය ශුන්ය දෝෂ ක්රමලේඛිකාව ) අපි මයික්රොසොෆ්ට් මෘදුකාංග බව අඩු කළ හැකි ද විය යුතුය දෝෂ තොරව. එහෙත් එය සත්‍යයට වඩා බොහෝ දුර බව අපි දනිමු.

ඔවුන්ගේ මෘදුකාංගය සංවර්ධනය කරන අතර ඔවුන් යම් මට්ටමක අඩු ප්‍රමුඛතා දෝෂ කරා ළඟා වූ විට ඔවුන් හුදෙක් නිෂ්පාදනය මුදා හැර ඒවා පසුව විසඳනු ඇත.

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

දෝෂ නොවැළැක්විය හැකියමිනිස් ස්වභාවය වැරදියට තේරුම් ගැනීම මෙන්ම .

දෝෂ නොමැති වීම 100% ආරක්ෂිත පද්ධතියක් තිබීම හා සමානයි. පද්ධතියක් 100% ආරක්ෂිත නම් එය තවදුරටත් ප්‍රයෝජනවත් නොවේ (එය බොහෝ විට කොන්ක්‍රීට් ටොන් හා ටොන් ගණනක් ඇතුළත පිහිටා ඇති අතර පිටතින් කිසිසේත් සම්බන්ධ නොවේ. රැහැන් රහිත හෝ රැහැන් රහිත නොවේ. එබැවින් පරිපූර්ණ ආරක්ෂිත පද්ධතියක් නොමැති සේම , සංකීර්ණ දෝෂ අඩු පද්ධතියක් නොමැත.


-1

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

මම හිතන්නේ ඔබට දෝෂ රහිත වැඩසටහන් ලිවිය හැකිය , නමුත් ඒවා සාමාන්‍යයෙන් ඔබ දැනටමත් 10 හෝ 12 වතාවක් ලියා ඇති වැඩසටහන් වේ. 13 වන වතාවේ ඔබ මුල සිටම එකම වැඩසටහන ලියන විට, ඔබ එය කරන්නේ කෙසේදැයි දැනටමත් දන්නවා: ඔබ ගැටලුව දන්නවා, ඔබ ශිල්පීය ක්‍රම දන්නවා, පුස්තකාල, භාෂාව දන්නවා ... ඔබ දකිනවා එය ඔබේ මනසෙහි . සියලු රටා ඇත, සෑම මට්ටමකම.

මම ක්‍රමලේඛනය උගන්වන නිසා මෙය ඉතා සරල වැඩසටහන් සමඟ මට සිදු වේ. ඒවා මට සරලයි, නමුත් සිසුන්ට අමාරුයි. මම කළු පුවරුවේ බොහෝ වාර ගණනක් කර ඇති ගැටළු වලට විසඳුම් ගැන කතා නොකරමි. ඇත්ත වශයෙන්ම මම ඒවා දන්නවා. මා අදහස් කළේ මා දන්නා සංකල්ප (මා උගන්වන සංකල්ප) භාවිතයෙන් යමක් විසඳන ~ 300-පේළි වැඩසටහන් ය. මම මෙම වැඩසටහන් කිසිදු සැලසුමකින් තොරව ලියන අතර ඒවා ක්‍රියාත්මක වන අතර, සියලු විස්තර මා දන්නා බව මට හැඟේ, මට කිසිසේත් TDD අවශ්‍ය නොවේ. මට සම්පාදක දෝෂ කිහිපයක් හෝ තුනක් ලැබේ (බොහෝ විට යතුරු ලියනය සහ වෙනත් දේ) සහ එය එයයි. කුඩා වැඩසටහන් සඳහා මට මෙය කළ හැකි අතර, වඩාත් සංකීර්ණ වැඩසටහන් සඳහා සමහර අයට එය කළ හැකි බව මම විශ්වාස කරමි. මම හිතන්නේ ලිනස් ටොවල්ඩ්ස් හෝ ඩැනියෙල් ජේ. බර්න්ස්ටයින් වැනි අයට එබඳු පැහැදිලි මනසක් ඇත, ඒවා ඔබට දෝෂ රහිත කෝඩරයකට ළඟා විය හැකි සමීපතමයා වේ. ඔබ නම්දේවල් ගැඹුරින් තේරුම් ගන්න මම හිතන්නේ ඔබට එය කළ හැකිය. මට මෙය කළ හැක්කේ මා කීවාක් මෙන් සරල වැඩසටහන් සඳහා පමණි.

මගේ විශ්වාසය නම්, ඔබ සැමවිටම ඔබේ මට්ටමට වඩා ඉහළින් වැඩසටහන් කිරීමට උත්සාහ කළහොත් (මම වසර ගණනාවක් ගත කළේ ඒ ආකාරයටමයි), ඔබ ව්‍යාකූල වී වැරදි කරනු ඇත. ගැටලුව අවසානයේදී ඔබ තේරුම් ගත් විට ඔබේ විසඳුම ක්‍රියාත්මක කළ නොහැකි බව ඔබ හදිසියේම වටහාගෙන ඇති අතර, ඔබේ ගැටලුව විසඳීම වළක්වා ගැනීමට හෝ කේතය භයානක වීමට ඉඩ ඇති පරිදි වෙනස්කම් ඉතා සංකීර්ණ කිරීමට සිදු වේ. TDD මෙම අවස්ථා සඳහා වේ, මම විශ්වාස කරමි. ඔබ විසඳන ගැටලුව විසඳා නොගන්නා බව ඔබ දන්නා අතර එම නිසා ඔබට ශක්තිමත් පදනමක් ඇති බව තහවුරු කර ගැනීම සඳහා සෑම තැනකම පරීක්ෂණ කරන්න. TDD අඩි 10,000 දර්ශනය විසඳන්නේ නැත. ඔබට සෑම විටම පරිපූර්ණ පිරිසිදු කේතයක් සහිත රවුම් වල ගමන් කළ හැකිය.

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

එබැවින් මගේ අවවාදය නම්: ඔබට දෝෂ රහිත වැඩසටහනක් ලිවීමට හැකි වන තෙක් ඔබ යමක් තේරුම් ගනී යැයි නොසිතන්න. ඔබ ගැඹුරින් දන්නා එම සංකල්ප දෙකක් එකම වැඩසටහනකට ඒකාබද්ධ කිරීමට උත්සාහ කරන්න. මට විශ්වාසයි ඔබට එය පළමු වරට ලැබෙනු ඇතැයි. ඉතා සුළු ක්‍රමයක් වන්නේ සුළු නොවන මෘදුකාංග නැවත ලිවීමයි, එය පළමු වරට විශාල උත්සාහයක් දැරූ දෙයක් (මම දැන් මෙය කරන්නේ ඇන්ඩ්‍රොයිඩ් යෙදුම් සමඟයි). මම නැවත ආරම්භ කරන සෑම අවස්ථාවකම මම යමක් වෙනස් කිරීම හෝ දේවල් එකතු කිරීම, ටිකක් විනෝදයක් එකතු කිරීම සඳහා වන අතර, මම ඔබට වඩා හොඳ සහ හොඳ සහ හොඳ තත්වයකට පත්වන බව ඔබට පැවසිය හැකිය ... සමහර විට දෝෂ රහිත නමුත් ඇත්තෙන්ම ආඩම්බර විය හැකිය.


-1

කේතකරණ ක්‍රියාවලියේදී imho දෝෂ සහ හදිසි, අද්භූත ඇල්ගොරිතම කෞතුක වස්තු දර්ශණය විය යුතුය : ඒවා කේතයේ පරිණාමය දිරිගන්වයි.
කෙසේ වෙතත් (සාමාන්‍යයෙන් යම් පරීක්ෂණයකින් පසුව) ප්‍රකාශයට පෙර භාවිතා කළ හැකි සෑම විචල්‍යයක්ම පරීක්ෂා කර බැලීමට, පෙනෙන සෑම තැනකම සෑම දෝෂයක්ම හැසිරවීමට - වැඩසටහන ශුන්‍ය දෝෂයක් බවට පත් කිරීමට ... සලකා බැලූ අංගයක් සඳහා ඉල්ලීමක් ලැබෙන තෙක් ඔබ වැඩසටහන් ගෘහ නිර්මාණ ශිල්පය ගැන සාකච්ඡා කරන විට කළ නොහැකි ය;)


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

-1

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

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

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

මම හිතන්නේ කේතය පිළිබඳ හොඳ රසයක් ඇති වන අතර, එය ඔබට පුහුණුව හා සමාලෝචනය සමඟ වර්ධනය කළ හැකි අතර ඒ හා සමාන ගැටළු ඇති පුද්ගලයින් ගැන කියවිය හැකිය.

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


-2

මම ඔබ අදහස් කරන්නේ නම්: "කේතය ලිවීමේදී දෝෂ බිංදුව" -> එය හොඳ ඉලක්කයක් නමුත් එය කළ නොහැකි ය.

නමුත් ඔබ අදහස් කරන්නේ නම්: "භාර දුන් කේතයේ ශුන්‍ය දෝෂ" -> එය කළ හැකි අතර මම එවැනි පරිසරවල වැඩ කළෙමි.

ඔබට අවශ්‍ය වන්නේ: ඉතා ඉහළ කේතවල ගුණාත්මකභාවය සහ 100% ට ආසන්න පරීක්ෂණ ආවරණයක් (ඒකක පරීක්ෂණ + පිළිගැනීමේ පරීක්ෂණ + ඒකාබද්ධ කිරීමේ පරීක්ෂණ).

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

පළමුවෙන්ම ඔබට උසස් තත්ත්වයේ උනන්දුවක් දක්වන සහ ඒ සඳහා මුදල් ගෙවීමට කැමති ලොක්කෙකු අවශ්‍යය.


-3

ක්‍රමලේඛකයාගේ විසඳුම:

  • වැඩසටහන්කරණය නවත්වන්න.
  • යාන්ත්‍රික පරිගණකයක් සාදන්න.
  • යාන්ත්‍රික ඇඳුම් ඇඳීම ක්‍රියාත්මක නොවන පරිදි සෑම වසර 5 කට වරක් එය ප්‍රතිස්ථාපනය කරන්න.

පරිශීලකයාගේ විසඳුම:

  • පරිගණක භාවිතය නවත්වන්න.
  • සෑම දෙයක්ම අතින් කරන්න.
  • සෑම විටම දෙවන පුද්ගලයෙකුට ප්‍රති .ල දෙවරක් පරීක්ෂා කරන්න.

-3

ශුන්‍ය-දෝෂ ක්‍රමලේඛකයෙකු වීමට ඔබට ක්‍රමලේඛ / කේත කළ නොහැකි බව මම එකඟ වෙමි. දෝෂය හමුවීම හා සංවර්ධනය කිරීම සෑම ක්‍රමලේඛකයෙකුගේම ජීවිතයේ කොටසකි. පළපුරුදු සංවර්ධකයෙකුට කිව නොහැක, හදවතට අත තබන්න, ඔවුන්ගේ කේතයේ කිසි විටෙකත් දෝෂයක් හමු වී නොමැත.


-4

වෙනත් ඉංජිනේරුවෙකු සමඟ යුගල කරන්න. අසමත් පරීක්ෂණයක් ලියන්න. අසමත් වූ පරීක්ෂණය සමත් වීමට ඔබ ටයිප් කරන සෑම චරිතයක්ම අවශ්‍ය වේවා. ඔබේ කේතය සරල කිරීම සඳහා නැවත සකස් කරන්න. අසමත් වූ තවත් පරීක්ෂණයක් ලියන්න.

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.