Ձեր ստուգումներից քանիսն են գոնե մեկ անգամ False վերադարձրել:
Հոդվածի հեղինակը կիսվում է արտադրական հրահանգների վերլուծության համակարգի մշակման իր փորձով, որը հագեցած է վտանգավոր ձևակերպումների դետեկտորով: Շահագործման ընթացքում պարզվել է, որ որակի ստուգումներից շատերը աշխատում են սխալ կամ ընդհանրապես չեն արձագանքում խախտումներին: Խնդիրը ախտորոշելու համար ստեղծվել է հատուկ գործիք, որը միտումնավոր սխալներ է մտցրել փաստաթղթերի մեջ: Արդյունքները անսպասելի էին. ստուգումների կեսը ոչ մի խնդիր չի հայտնաբերել: Հետագա հետաքննությունը ցույց է տվել, որ ախտորոշիչ գործիքը նույնպես պարունակում էր սխալներ, ներառյալ կոնֆիգուրացիայի և արդյունքների սխալ հաշվարկի հետ կապված խնդիրներ: Հեղինակը ընդգծում է որակի վերահսկման գործիքների կանոնավոր ստուգման կարևորությունը, քանի որ նույնիսկ ստուգված կոդը կարող է թաքցնել «կույր կետեր», որոնք համակարգը դարձնում են անարդյունավետ: Այս դեպքը ծրագրավորողներին հիշեցնում է ստուգումների տրամաբանության մանրակրկիտ վերիֆիկացման և թեստային ծածկույթի կանոնավոր աուդիտի անհրաժեշտության մասին:
This is a summary. Read the full article at the original source:
HabrԿապակցված
Ես թույլ տվեցի AI-ին գրել իմ կոդի 100%-ը 30 օրվա ընթացքում. Ահա թե ինչ կոտրվեց։
Ծրագրավորողներից մեկը 30-օրյա փորձարկում է անցկացրել՝ հանձնարարելով արհեստական բանականությանը (AI) գրել իր նոր SaaS արտադրանքի կոդի 100%-ը: Թեև AI-ն հ…
Ես թույլ տվեցի մոդելին առաջարկել Postgres-ի ինդեքսներ, ապա ստիպեցի տվյալների բազային գնահատել դրանք
Ծրագրավորողը ստեղծել է գործիք՝ AI-ի կողմից առաջարկված Postgres ինդեքսները ստուգելու համար՝ դրանք անմիջապես տվյալների բազայում փորձարկելու միջոցով: Հաս…
Ստորագրության հավասարությունը վարքագծային հավասարություն չէ. զրոյական կախվածություններով միգրատորի ստեղծում
Հեղինակը քննարկում է Go նախագծերի կախվածությունները ստանդարտ գրադարան տեղափոխելու բարդությունները՝ ընդգծելով, որ ստորագրության հավասարությունը չի երաշ…



