კოდის კითხვა რთულობის მიზნით

Grep კანდიდატებს პოულობს. კითხვა მათ დადასტურებს. როდესაც გახსნით კანდიდატი ფაილს, წაიკითხავთ ერთი შეკითხვით: ამ ოპერაციის ღირებულება იზრდება შენატანის ზომით?

MOAD-0001-ისთვის, დადასტურების ოქროვანი:

1. იპოვე გარე loop. რა უზღვარი ზღვარი მის განმეორება რაოდენობის?
2. იპოვე შიგა ოპერაცია (.contains, .indexOf, 'in'). რა მონაცემთა სტრუქტურა აკეთებს მას?
3. ეს მონაცემთა სტრუქტურა იზრდება იმავე შენატანით, რომელი მართავს გარე loop-ს?
4. თუ კი: ღირებულება არის O(N²), სადაც N = შენატანის ზომა. დადასტურებული დეფექტი.
5. თუ არა: შიგა სტრუქტურა შეზღუდულია (config, enum, მცირე მუდმივი). ცრუ დადებითი.

გრაფის მოგზაურობა N კვანძების ნახვისას, checked visited სია თითოეულ ნაბიჯზე: loop და შიგა მონაცემთა სტრუქტურა იზრდება N-ით. დადასტურებული.

მოთხოვნის დამკვეთელი ის ნებადართული IP-ების 5 ადმინის ჩამონათვალი: allowlist ოდესმე არ იზრდება მოთხოვნის ტომით. ცრუ დადებითი.

იგივე ოქროვანი გვრცელდება თითოეულ MOAD-ზე: დაა თითოეულ იდ გარე დრივერი, დაა შიგა სტრუქტურა, შევკითხე, ორივე სკალირებს ერთად.

აფეთქების ქულა: აღმოჩენების პრიორიტეტი

ყველა დადასტურებული დეფექტი არ ღირს დაუყოვნებელი პატჩი. MOAD ბიბლიოთეკაში 10,000 downstream dependents აქვს უმაღლესი surge score ვიდრე იგივე MOAD პირადი შიგა ხელმეუფლებაში.

აფეთქების ქულა = speedup × in-degree. Speedup: რამდენი უფრო სწრაფად მუშაობს pach-ი ტიპიკურ ოქროს სკალაზე? In-degree: რამდენი downstream პაკეტი ან მომსახურება იმსახურებს fix-ს ავტომატურად, როდესაც upstream merge გაკეთდა?

დადასტურებული MOAD-0001 Apache Maven-ის დამოკიდებულების ამოსახლსში, 50,000 კვანძის გრაფებზე, 1,000+ downstream Maven plugins-ის ჩანასახით, რომელი იმსახურებს ცვლილებებს ავტომატურად: surge score ძალიან მაღალი. ეს fix-ი მდებარეობს თქვენი რიგის წინ.

დადასტურებული MOAD-0001 ერთი მომხმარებლის CLI ხელმეუფლებაში რომელს თან არ ჰყავს დამოკიდებულები: surge score ახლოს ნულთან. ღირს ფიქსი, მაგრამ არა მოხელე.

Workaholic vs. glutton კვანძები. კვანძი მაღალი betweenness-ით და მაღალი speedup-ით არის workaholic: იგი აკეთებს კრიტიკულ ნაკადს და flush გააკეთებს downstream რიგებს, როდესაც განბლოკება მოხდა. Patch-ი მხოლოდ ის შემდეგ, რომ დადასტურეთ downstream capacity. კვანძი მაღალი out-degree-ით და დაბალი speedup-ით არის glutton: ის აზიდის ყველაფერი რაც მას ენიჭება და არ იგრძნობს ტკივილს. Patch-ი workaholic-ი პატრიოტი infrastructure scale-ის MOAD-0005-ის (thundering herd) შექმნის გარეშე.

Scan to Merge: MOAD Pipeline

დადასტურებული დეფექტი მაღალი surge score-ით გადის pipeline-ში. თითოეულ ეტაპი აზიდის საბეჭდი. კვამლი უკვე სხვა სცენაში არის.

scan    → candidate list (grep output, static analysis results)
ticket  → defect description (MOAD number, location, complexity analysis)
patch   → code change (data structure swap, primitive adoption)
test    → unit test (O(1) proof: time the fix at N=100 and N=10,000)
UNDF    → public disclosure post (undefect.com, public domain)
disclose → CVE or CWE reference if security-relevant
PR      → upstream pull request with patch + test + UNDF link
merge   → maintainer acceptance; fix propagates via version bump

თითოეულ საბეჭდი აერთიანებს შემდეგი ეტაპს. patch test-ის გარეშე არ უძლებს გადამოწმება. test disclosure-ის გარეშე არ შეიძლება propagate კვამლ instances-თან. disclosure upstream PR-ის გარეშე strands fix fork-ში.

MOAD post (UNDF) არის ეტაპი უმეტესი ინჟინერი omit. ისინი patch defect, submit PR, და პირობა თავი დაასრულეთ. მაგრამ patch disclosure-ის გარეშე ნიშნავს ყველა მომავალი ინჟინერი რომელიც პატივ იგივე ნიმუშს განმეორებით აღმოჩენა ორივე პრობლემა და fix. MOAD post პლომბი ცოდნის loop: სახელი ნიმუში, აჩვენება detection მეთოდი, link patch. მომავალი მკვლელი პოვნა fix-ი ძებნით pattern name.

Planet patching at scale. single MOAD-0001 fix ფართოდ გამოყენებული ბიბლიოთეკა propagates ყველა პროექტი რომელი imports მას. MOAD post უსაფრთხოება ინჟინერი მოსახლე პროექტი რომელიც არასოდეს upgrade ბიბლიოთეკა მუშაობის აღმოჩენა fix. ორივე paths გაშვება parallel.

დეფექტი Ticket დაწერა

კარგი დეფექტი ticket პასუხი ხუთი შეკითხვა:

1. სადაც: ზუსტი file, class, function, და line range
2. რა: data structure ტიპი და operation against it
3. რატომ: complexity analysis (O(N²) or worse, with N defined)
4. Impact: რა inputs ტრიგერი worst-case behavior, და რა scale
5. Fix: data structure or primitive to substitute

ticket რომელი პასუხი ყველა ხუთი არის self-contained: maintainer რომელიც არასოდეს წაიკითხა თქვენი ანალიზი შეიძლება ხელახლა აღმოჩენა თქვენი finding და verify fix. Tickets რომელი skip (3) ან (4) require maintainer ხელახლა complexity analysis ფიქსი merge. რომ friction რედაქტორი merge вероятност.

Credibility compounds. პირველი PR რომელი includes მკაფიო ticket, good-targeted patch, benchmark test gets merged. მეორე PR დან იგივე author gets reviewed ნაკლები friction. მესამე PR gets reviewed maintainer რომელი merged პირველი ორი. Reputation open source არის ledger საბეჭდი: თითოეულ მიღებული patch earns trust შემდეგი.

რეალური კანდიდატი კითხვა

აქ არის რეალური MOAD-0001 კანდიდატი Python. წაიკითხეთ და complete triage protocol.

class DependencyResolver:
    def resolve(self, package, resolved=None, seen=None):
        if resolved is None:
            resolved = []
        if seen is None:
            seen = []
        if package in seen:
            return
        seen.append(package)
        for dep in self.registry.get_dependencies(package):
            self.resolve(dep, resolved, seen)
        resolved.append(package)
        return resolved

Triage შეკითხვა:

1. რა data structure არის `seen`?
2. რა operation გაშვება against it line 6?
3. `seen` grow input size?
4. loop რომელი drives recursive calls grow input size?
5. არის ეს confirmed MOAD-0001 ან false positive?

თქვენი Patch

დადასტურებული defect მაღალი surge score მოთხოვნის complete patch: code fix, test რომელი proves improvement, MOAD post outline.

test უნდა იყოს performance test, არა correctness test. correctness test passes before and after fix — ეს წერტილი; output არ შეცვლის. performance test ორი შენატანი sizes proves improvement:

import time

def build_graph(n):
    # n packages, each depending on the previous one
    return {f'pkg{i}': [f'pkg{i-1}'] if i > 0 else [] for i in range(n)}

for n in [100, 1000, 5000]:
    registry = build_graph(n)
    resolver = DependencyResolver(registry)
    start = time.perf_counter()
    resolver.resolve(f'pkg{n-1}')
    elapsed = time.perf_counter() - start
    print(f'n={n}: {elapsed:.4f}s')

Before fix, elapsed time grows quadratically n. After fix, grows linearly. Print both და include numbers PR description.

MOAD post outline covers: pattern name, substrate (Python dependency resolver), detection method (grep in seen სადაც seen starts როგორც []), fix, link PR. post goes undefect.com როგორც public domain. Future ინჟინერი searching 'Python list membership loop slow' will find it.