नामकरण खोज नहीं है
अब आप सात MOAD पैटर्न को जानते हैं। नाम जानना महत्वपूर्ण है: यह आपको एक पैटर्न को पहचानने देता है जब आप इसे देखते हैं। लेकिन एक नियंत्रित पाठ में पहचान उस खोज से अलग है जो आप कभी खोले गए कोडबेस में करते हैं।
एक कोडबेस अपने दोषों को लेबल नहीं करता है। एक तलछटी MOAD के साथ एक टिप्पणी नहीं आती जो कहती है // O(N²) — इसे ठीक करो। एक गड़गड़ाती भीड़ अपने आप को कैश मिस भगदड़ के रूप में घोषित नहीं करती है। आप इसे एक विशिष्ट प्रश्न को ध्यान में रखते हुए कोड पढ़कर खोजते हैं: कौन सी डेटा संरचना इन मानों को रखती है, और किस लूप के अंदर इसके विरुद्ध कौन सी संचालन चलती है?
खोज एक कौशल है जो पहचान से अलग है। पहचान कहती है: हां, वह पैटर्न MOAD-0001 है। खोज कहती है: मुझे इस कोडबेस में सभी जगहें खोजने दें जहां वह पैटर्न मौजूद हो सकता है, चाहे मैं पूरा कोड देख सकूं या केवल एक प्रतीक का नाम।
पहली स्कैन
पहला पास grep का उपयोग करता है। प्रत्येक MOAD का एक आधार है: एक डेटा संरचना या API जिसकी उपस्थिति, कुछ संचालन के पास, एक संकेत है जो जांच के लायक है।
MOAD-0001 (तलछटी): एक लूप में List.contains
# Signal: membership test on a list variable inside a loop
grep -rn '.contains(' src/ | grep -v HashSet | grep -v TreeSet
grep -rn 'visited =' src/ | grep -v set | grep -v Set
MOAD-0002 (परस्पर उलझन): चरणों में साझा परिवर्तनशील ध्वज
# Signal: static mutable field written by one subsystem, read by another
grep -rn 'static ' src/ | grep -v final | grep -v class | grep -v void
MOAD-0003 (रिसाव संदर्भ): पूल किए गए एक्सीक्यूटर में ThreadLocal
# Signal: ThreadLocal.set() without guaranteed ThreadLocal.remove()
grep -rn 'ThreadLocal' src/
grep -rn 'ThreadLocal.set' src/ -l
MOAD-0004 (लॉग किया गया रहस्य): लॉग आउटपुट में HTTP हेडर
# Signal: log call with headers variable near auth endpoints
grep -rn 'log.*header' src/
grep -rn 'Authorization' src/ --include='*.log'
MOAD-0005 (गड़गड़ाती भीड़): बिना समन्वय के कैश मिस
# Signal: cache.get() + null check + cache.put() without lock
grep -rn 'cache.get' src/ -A4 | grep 'cache.put'
ये पैटर्न उम्मीदवार पैदा करते हैं, पुष्टि किए गए दोष नहीं। हर उम्मीदवार को छंटनी की जरूरत है: आसपास के कोड को पढ़ें, डेटा संरचना के प्रकार की पुष्टि करें, यह पुष्टि करें कि संचालन पैमाने पर चलता है।
जटिलता के लिए कोड पढ़ना
Grep उम्मीदवार खोजता है। पढ़ना उन्हें पुष्टि करता है। जब आप एक उम्मीदवार फ़ाइल खोलते हैं, तो आप एक प्रश्न के साथ पढ़ते हैं: क्या इस संचालन की लागत इनपुट आकार के साथ बढ़ती है?
MOAD-0001 के लिए, पुष्टि प्रोटोकॉल:
1. बाहरी लूप खोजें। यह कितनी बार पुनरावृत्त होता है?
2. आंतरिक संचालन (.contains, .indexOf, 'in') खोजें। यह किस डेटा संरचना के विरुद्ध चलता है?
3. क्या वह डेटा संरचना उसी इनपुट के साथ बढ़ता है जो बाहरी लूप को चलाता है?
4. यदि हां: लागत O(N²) है जहां N = इनपुट आकार। पुष्टि किया गया दोष।
5. यदि नहीं: आंतरिक संरचना सीमाबद्ध है (कॉन्फ़िगरेशन, enum, छोटा स्थिरांक)। झूठा सकारात्मक।
एक ग्राफ ट्रैवर्सल N नोड्स का दौरा करना, हर कदम पर एक visited सूची की जांच करना: लूप और आंतरिक डेटा संरचना दोनों N के साथ बढ़ते हैं। पुष्टि किया गया।
एक अनुरोध हैंडलर 5 व्यवस्थापक IPs की अनुमति सूची की जांच कर रहा है: अनुमति सूची कभी अनुरोध वॉल्यूम के साथ नहीं बढ़ता है। झूठा सकारात्मक।
एक ही प्रोटोकॉल प्रत्येक MOAD पर लागू होता है: बाहरी ड्राइवर की पहचान करें, आंतरिक संरचना की पहचान करें, पूछें कि क्या दोनों पैमाने पर एक साथ बढ़ते हैं।
सर्ज स्कोर: अपनी खोजों को प्राथमिकता देना
सभी पुष्टि किए गए दोष तत्काल पैच के लायक नहीं हैं। 10,000 डाउनस्ट्रीम आश्रित के साथ एक लाइब्रेरी में एक MOAD का सर्ज स्कोर निजी आंतरिक उपकरण में समान MOAD से अधिक है।
सर्ज स्कोर = गति × इन-डिग्री। गति: विशिष्ट उत्पादन पैमाने पर पैच कितना तेजी से चलता है? इन-डिग्री: कितने डाउनस्ट्रीम पैकेज या सेवाएं स्वचालित रूप से अपस्ट्रीम विलय होने पर सुधार प्राप्त करेंगे?
Apache Maven की निर्भरता समाधानकर्ता में एक पुष्टि किए गए MOAD-0001, 50,000 नोड्स के ग्राफ पर चल रहा है, 1,000+ डाउनस्ट्रीम Maven प्लगइन्स के साथ जो स्वचालित रूप से परिवर्तन प्राप्त करते हैं: सर्ज स्कोर बहुत अधिक है। यह पैच आपकी कतार के सामने है।
एक कर्मचारी-उपयोगकर्ता CLI उपकरण में एक पुष्टि किए गए MOAD-0001, कोई आश्रितों के साथ: सर्ज स्कोर के पास शून्य है। पैच के लायक, लेकिन जरूरी नहीं।
वर्कहोलिक बनाम लालची नोड्स। उच्च बेटवीनेस & उच्च गति वाला एक नोड एक वर्कहोलिक है: यह महत्वपूर्ण प्रवाह संभालता है & डाउनस्ट्रीम कतारें निकाल देगा। इसे केवल डाउनस्ट्रीम क्षमता की पुष्टि करने के बाद पैच करें। उच्च बाहर-डिग्री & कम गति वाला एक नोड लालची है: यह सब कुछ खपत करता है और कोई दर्द नहीं महसूस करता है। वर्कहोलिक को पैच करना डाउनस्ट्रीम क्षमता को चरणबद्ध करने के बिना बुनियादी ढांचे के पैमाने पर MOAD-0005 (गड़गड़ाती भीड़) बनाता है।
स्कैन से विलय तक: एक MOAD पाइपलाइन
एक पुष्टि किए गए दोष एक उच्च सर्ज स्कोर के साथ एक पाइपलाइन के माध्यम से चलता है। प्रत्येक चरण एक कलाकृति का उत्पादन करता है। कोई भी चरण वैकल्पिक नहीं है।
scan → उम्मीदवार सूची (grep आउटपुट, स्थिर विश्लेषण परिणाम)
ticket → दोष विवरण (MOAD नंबर, स्थान, जटिलता विश्लेषण)
patch → कोड परिवर्तन (डेटा संरचना स्वैप, आदिम गोद लेना)
test → यूनिट परीक्षण (O(1) प्रमाण: N=100 और N=10,000 पर पैच को समय दें)
UNDF → सार्वजनिक प्रकटीकरण पोस्ट (undefect.com, सार्वजनिक डोमेन)
disclose → CVE या CWE संदर्भ यदि सुरक्षा-प्रासंगिक है
PR → अपस्ट्रीम पुल अनुरोध पैच + परीक्षण + UNDF लिंक के साथ
merge → रक्षक स्वीकृति; पैच संस्करण बम्प के माध्यम से प्रसारित होता है
प्रत्येक कलाकृति अगले चरण को खिलाती है। एक परीक्षण के बिना एक पैच सत्यापित नहीं किया जा सकता है। एक प्रकटीकरण के बिना एक परीक्षण पैच को फोर्क में फंसाता है। एक अपस्ट्रीम PR के बिना एक प्रकटीकरण पैच को फोर्क में फंसाता है।
एक MOAD पोस्ट (UNDF) सबसे अधिक इंजीनियर छोड़ने वाला चरण है। वे दोष को ठीक करते हैं, एक PR सबमिट करते हैं, और अपने आप को पूरा माना जाता है। लेकिन एक नामित पोस्ट के बिना एक पैच का अर्थ है कि भविष्य के हर इंजीनियर जो एक ही पैटर्न का सामना करता है उसे समस्या और पैच दोनों को स्वतंत्र रूप से फिर से खोजना चाहिए। एक MOAD पोस्ट ज्ञान लूप को बंद करता है: यह पैटर्न का नाम देता है, पहचान विधि दिखाता है, & पैच को जोड़ता है। भविष्य के शोधकर्ता पैटर्न के नाम को खोजकर पैच खोजते हैं।
पैमाने पर ग्रह पैच। व्यापक रूप से उपयोग की जाने वाली लाइब्रेरी में एक एकल MOAD-0001 पैच हर प्रकल्प में प्रसारित होता है जो इसे आयात करता है। एक MOAD पोस्ट यह सुनिश्चित करता है कि उन प्रकल्पों में इंजीनियर जो कभी भी उस लाइब्रेरी को अपग्रेड नहीं करेंगे अभी भी पैच सीखते हैं। दोनों पथ समानांतर में चलते हैं।
एक दोष टिकट लिखना
एक अच्छा दोष टिकट पाँच प्रश्नों का उत्तर देता है:
1. कहाँ: सटीक फ़ाइल, क्लास, फ़ंक्शन, और पंक्ति श्रेणी
2. क्या: डेटा संरचना प्रकार और इसके विरुद्ध संचालन
3. क्यों: जटिलता विश्लेषण (O(N²) या बदतर, N परिभाषित)
4. प्रभाव: कौन से इनपुट सबसे खराब स्थिति को ट्रिगर करते हैं, और किस पैमाने पर
5. सुधार: डेटा संरचना या आदिम को प्रतिस्थापित करने के लिए
एक टिकट जो सभी पाँचों का उत्तर देता है आत्मनिर्भर है: एक रक्षक जिसने आपका विश्लेषण कभी नहीं पढ़ा है आपकी खोज को पुनरुत्पादित कर सकता है और आपके पैच को सत्यापित कर सकता है। जो टिकट (3) या (4) को छोड़ते हैं, रक्षक को मर्ज करने से पहले आपकी जटिलता विश्लेषण दोहराने की आवश्यकता होती है। यह घर्षण विलय की संभावना को कम करता है।
विश्वसनीयता यौगिक। एक पहला PR जिसमें एक स्पष्ट टिकट, एक अच्छी तरह से लक्षित पैच, & एक बेंचमार्क परीक्षण शामिल है को मर्ज किया जाता है। दूसरा PR एक ही लेखक से कम घर्षण के साथ समीक्षा की जाती है। तीसरा PR उस रक्षक द्वारा समीक्षा की जाती है जिसने पहले दो को मर्ज किया। खुले स्रोत में प्रतिष्ठा कलाकृतियों का एक खाता है: प्रत्येक स्वीकृत पैच अगले के लिए विश्वास अर्जित करता है।
एक वास्तविक उम्मीदवार को पढ़ना
यहाँ Python में एक वास्तविक MOAD-0001 उम्मीदवार है। इसे पढ़ें और छंटनी प्रोटोकॉल पूरा करें।
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
छंटनी के प्रश्न:
1. `seen` कौन सी डेटा संरचना है?
2. लाइन 6 पर इसके विरुद्ध कौन सा संचालन चलता है?
3. क्या `seen` इनपुट आकार के साथ बढ़ता है?
4. क्या लूप जो पुनरावर्ती कॉल को चलाता है भी इनपुट आकार के साथ बढ़ता है?
5. क्या यह एक पुष्टि किया गया MOAD-0001 है या एक झूठा सकारात्मक?
आपका पैच
एक पुष्टि किए गए दोष एक उच्च सर्ज स्कोर के साथ एक पूर्ण पैच की जरूरत है: कोड सुधार, एक परीक्षण जो सुधार साबित करता है, & एक MOAD पोस्ट रूपरेखा।
परीक्षण एक प्रदर्शन परीक्षण होना चाहिए, एक सुधार परीक्षण नहीं। एक सुधार परीक्षण सुधार से पहले और बाद में पास होता है — यही बात है; आउटपुट नहीं बदलता है। एक प्रदर्शन परीक्षण दो इनपुट आकार पर सुधार साबित करता है:
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')
सुधार से पहले, समय n के साथ द्विघाती रूप से बढ़ता है। सुधार के बाद, यह रैखिक रूप से बढ़ता है। दोनों को प्रिंट करें और अपने PR विवरण में संख्या शामिल करें।
एक MOAD पोस्ट रूपरेखा शामिल है: पैटर्न नाम, आधार (Python निर्भरता समाधानकर्ता), पहचान विधि (grep for in seen जहाँ seen [] के रूप में शुरू होता है), सुधार, & आपके PR का एक लिंक। पोस्ट undefect.com पर सार्वजनिक डोमेन के रूप में जाता है। भविष्य के इंजीनियर 'Python सूची सदस्यता लूप में धीमा' को खोजेंगे इसे खोजेंगे।