वास्तुकला के सड़ने का एक कारक विकास लागत के साथ समझौता करना है

सड़ी हुई वास्तुकला की विशेषताएं हैं: बड़ी संख्या में विशेष हैंडलिंग, संगतता हैंडलिंग, गंभीर कपलिंग, और बोझ इतना अधिक कि वापस लौटना मुश्किल है। वास्तुकला धीरे-धीरे सड़ जाती है। सड़ी हुई वास्तुकला के साथ नई सुविधाएं विकसित करना कठिन होता है, बग ठीक करना मुश्किल होता है, एक छोटी सी चीज पूरे सिस्टम को प्रभावित करती है, जिससे परीक्षण और QA भी करना कठिन होता है। मैंने एक गैर-पेशेवर डेवलपर प्रेमी को पोस्ट करते देखा था कि मॉडल को कोड लिखते समय अमूर्त व्यवहार को सीमित करें, ताकि कोड समझने में आसान हो। जो कोड इंसानों के लिए समझने में आसान होता है, LLM के लिए भी समझने में आसान होता है, इसलिए तेजी से विकास किया जा सकता है और त्रुटियां कम हो सकती हैं। मुझे लगता है कि गैर-पेशेवर डेवलपरों के पास शायद छोटे इंजीनियरिंग प्रोजेक्ट होते हैं, और वे असेंबली लाइन जैसी तर्कशक्ति के आदी होते हैं; यदि पैमाने बढ़ाने की अपेक्षा है, तो सोच को असेंबली लाइन तक सीमित नहीं रखना चाहिए, बल्कि निर्माण श्रमिक की सोच अपनानी चाहिए। यदि 30 मंजिल की इमारत बनाने की योजना है, तो 10 मीटर गहरी नींव खोदनी होगी; यदि पानी और बिजली की आपूर्ति की अपेक्षा है, तो पानी और बिजली के लिए जगह आरक्षित करनी होगी। यह लक्ष्य-स्पष्ट डिज़ाइन है, इसके अलावा लक्ष्य-अस्पष्ट डिज़ाइन भी होता है, जैसे कि घर के किसी स्थान पर भविष्य में कोई उपकरण रखना है, लेकिन यह निश्चित नहीं है कि क्या, तो बस सॉकेट आरक्षित कर दें। सॉफ्टवेयर इंजीनियरिंग में डिज़ाइन का मार्गदर्शन करने के लिए पहले से ही SOLID सिद्धांत मौजूद हैं। कई बार सतही रूप से देखने पर, SOLID सिद्धांतों का पालन करते समय समान कार्यक्षमता प्राप्त करने के लिए अधिक फाइलें बनानी पड़ती हैं और अधिक कोड लिखना पड़ता है; अल्पकालिक परिणामों के लिहाज से, डिज़ाइन किए गए और नहीं किए गए डिज़ाइन में मालिक/परीक्षक और उपयोगकर्ता को लगभग कोई अंतर नहीं दिखता, डिज़ाइन का लाभ केवल दीर्घकाल में ही प्रकट होता है। एक अच्छी वास्तुकला सुविधाएं जोड़ने, बदलने और बग ठीक करने में आसान होती है, और कम समस्याएं पैदा करती है। डिज़ाइन के लिए सोच अक्सर सीधे सुविधा विकसित करने से अधिक होती है; डिज़ाइन में कणिकता (ग्रेन्युलैरिटी) पर विचार करना होता है, पूरे घर में सॉकेट पैनल को टाइल्स की तरह चिपका देना एक और बेतुका तरीका है। पहले मैं विकास चक्र पर विचार करते समय समझौता करता था, समय कम होने पर डिज़ाइन भी नहीं करता था, बस कुछ फ़ंक्शन जोड़ देता था, भविष्य की बात भविष्य में। अब AI की मदद से, हम डिज़ाइन की कणिकता को और छोटा कर सकते हैं, उत्पन्न कोड इंसानों को पढ़ने में अधिक कठिन लगेगा, लेकिन इंजीनियरिंग अधिक आसानी से बनाए रखी जा सकेगी। अधिक अमूर्तीकरण के बाद, खराब मॉडल वास्तव में इसे ठीक से संभाल नहीं पा सकते, इसलिए वर्तमान में सर्वश्रेष्ठ मॉडल का उपयोग करना सबसे अच्छा है। यदि केवल स्क्रिप्ट लिखी जा रही है, तो मॉडलों के बीच क्षमता का अंतर शायद बहुत स्पष्ट न हो। क्या AI ने डेवलपर्स के प्रवेश बाधा को कम किया है? मुझे इस पर संदेह है, क्योंकि नए डेवलपर्स का सीखने का मार्ग पहले से बिल्कुल अलग है, इसलिए बाधा ऊंची या नीची इस पर चर्चा करना शायद बेमानी है, क्योंकि हमें नहीं पता कि बाधा कहां ले जाई गई है।

• ←पिछला
• अगला→