स्वचालित कोड जनरेटर [बंद]


13

मेरे सहयोगियों में से एक स्वचालित कोड जनरेटर का उपयोग करना पसंद करता है, जो बड़ी मात्रा में कोड बनाता है जो खराब दस्तावेज है और बनाए रखने के लिए बहुत कठिन है।

निर्माण के लिए कम समय के लिए रखरखाव में परेशानी के लायक एक कोड जनरेटर का उपयोग करने की लागत है?

जवाबों:


10

चलो फिर से वर्णन करें कि:

क्या एक अच्छा स्वचालित कोड जनरेटर की कीमत इसके लायक है?

हाँ।

क्या एक घटिया स्वचालित कोड जनरेटर की लागत है जो बाकी सभी के लिए अधिक काम करता है लेकिन यह इसके लायक है?

बिलकुल नहीं। खराब कोड के लिए कोई बहाना नहीं है। यदि कोई चतुर होना चाहता है और स्वचालित कोड पीढ़ी का उपयोग करना चाहता है, तो उन्हें यह सुनिश्चित करने के लिए समय लेना चाहिए कि उत्पन्न कोड अच्छा कोड है। अन्यथा, इसका क्या मतलब है? यह केवल हिरन को हिरन के नीचे धकेल रहा है और जब कोड उत्पादन की बात आती है, तो हिरन को उस डेवलपर को रोकना चाहिए जिसने इसे लिखा था।


16
मैं आपकी दूसरी बात से असहमत हूं। उत्पन्न कोड को केवल इतना अच्छा होना चाहिए ताकि यह काम करे और प्रदर्शन / सुरक्षा या कोई अन्य समस्या पैदा न करे। चूंकि आपको कभी भी हाथ से उत्पन्न कोड को बनाए नहीं रखना चाहिए, इससे कोई फर्क नहीं पड़ता कि यह आपके सामान्य कोडिंग मानकों पर निर्भर नहीं है।
हेला

4
आपके लिए असहमत होना ठीक है। हालाँकि, यदि आप एक कोड जनरेटर बनाने के लिए समय लेने जा रहे हैं, तो कोड को सुंदर बनाने के लिए समय क्यों न निकालें? एक बार उत्पन्न होने के बाद, मुझे नहीं पता कि इसे किसने बनाया है, इसे कैसे बनाया गया है, और न ही इसका इरादा तब तक है जब तक यह सभी भागों के रूप में पठनीय / बनाए रखने योग्य नहीं है। कभी-कभी जनरेटर केवल पूर्ण-तैयार उत्पाद के बजाय एक प्रारंभिक बिंदु बनाने के लिए होते हैं।
गेहूं

1
इसके अलावा, यदि कोड की पीढ़ी आपके बिल्ड का हिस्सा है (यानी यह प्रत्येक बिल्ड को फिर से जेनरेट करता है) तो यह "सुंदर" कोड का उत्पादन करने के लिए उतना अर्थ नहीं रखता है। लेकिन अगर आप एक बार कोड जनरेट करने जा रहे हैं और वह यह है, तो यह एक अलग कहानी है।
डीन हार्डिंग

5
हेला, आपको कभी भी हाथ से उत्पन्न कोड को बनाए नहीं रखना चाहिए, लेकिन जब दिन आता है कि आपको नई / बदलती आवश्यकताओं के कारण उस कोड को बदलने की आवश्यकता है, तो आपको कोड स्पष्ट और समझदार होने की आवश्यकता है ताकि आप आसानी से जनरेटर में आवश्यक बदलाव कर सकें , और फिर से उत्पन्न।
कार्सन 63000

6
बनाए गए कोड को रखरखाव के लिए पर्याप्त नहीं होना चाहिए, लेकिन इसे डीबगिंग के लिए और सत्यापन के लिए पर्याप्त रूप से समझदार होना चाहिए।
हपरनिकेतेस

23

एक जनरेटर द्वारा उत्पन्न कोड को कभी भी हाथ से बनाए नहीं रखना चाहिए। यदि इसे बदलने की आवश्यकता है, तो जनरेटर और / या इसकी सेटिंग्स को फिर से चालू और चलाना होगा। ध्यान में रखते हुए, यह कोई फर्क नहीं पड़ता कि जब तक परिणामस्वरूप कोड समझ में नहीं आता है और जब तक पीढ़ी तंत्र स्वयं क्रिस्टल स्पष्ट नहीं होता है तब तक यह अनिर्दिष्ट है। (इस तथ्य को दस्तावेज़ित करना सुनिश्चित करें कि कोड उत्पन्न होता है, और जहां जनरेटर है और यह कैसे काम करता है।)

सादृश्य: जबकि मेरे कंप्यूटर का प्रोसेसर हमेशा मशीन कोड निष्पादित कर रहा है, मुझे इसके बारे में कुछ भी जानने की आवश्यकता नहीं है जब तक कि मुझे पता है कि उच्च-स्तरीय भाषा और संकलक का उपयोग करके उस मशीन कोड को कैसे बनाया जाए। मैंने सुना है कि जीसीसी कभी-कभी सबपर मशीन कोड का उत्पादन करता है, लेकिन कौन परवाह करता है, जब तक यह पूरी तरह से काम करता है। डेटाबेस अमूर्त परतें DB इंजन के साथ संचालित करने के लिए SQL का उत्पादन करती हैं, लेकिन कौन परवाह करता है कि SQL कैसा दिखता है, जब तक कि अमूर्त परत स्पष्ट है और काम करती है?

जब ठीक से उपयोग किया जाता है, तो कोड जनरेटर निश्चित रूप से न केवल सृजन को बचा सकते हैं, बल्कि रखरखाव लागत भी।


4
समस्या तब बन जाती है, केवल एक व्यक्ति के पास उपकरण होता है, कोई और नहीं करता है, और इसलिए कोड को मैन्युअल रूप से बनाए रखना पड़ता है।
Mumbles

यह हिरन गुजर रहा है। सॉफ्टवेयर डेवलपर्स के रूप में, हमारा व्यवसाय कोड है - कोई फर्क नहीं पड़ता कि हम इसका उत्पादन कैसे करते हैं।
स्टीवन एवर्स

12
@ डेविड, यदि केवल एक व्यक्ति के पास उपकरण है, तो आपको एक से अधिक लोगों को शामिल करने वाली परियोजना के लिए इसका उपयोग नहीं करना चाहिए।
मैट ओलेनिक

2
@ मैट, बिल्कुल। जेनरेटर परियोजना का हिस्सा हैं (स्क्रिप्ट बनाने में तुलनीय) और इसे संस्करण नियंत्रण या इसी तरह के केंद्रीय भंडार में संग्रहित किया जाना चाहिए।
१as:

2
@SnOrfus: मुझे लगता है कि हमारा व्यवसाय काम करने वाले उत्पादों का उत्पादन करना है जो लोग उपयोग करने और खरीदने के लिए तैयार हैं। वहीं से हमारा वेतन आता है। कोड सिर्फ एक माध्यम है।
जूनस पुलकका

6

एक कोड जनरेटर एक प्रकार का कंपाइलर है। आपको इस बात की चिंता नहीं है कि कंपाइलर आउटपुट कितना सुंदर है, आप सिर्फ सोर्स कोड के साथ काम करते हैं। इसका उपयोग करना और फिर आउटपुट को हाथ से संशोधित करना मुश्किल है, इसे केवल मनुष्य द्वारा समझे जाने वाले रूप में खरोंच से लिखना और इसका मतलब है कि आप बहुत सारे काम के बिना फिर से कोड जनरेटर का उपयोग नहीं कर सकते हैं, क्योंकि आपको आवेदन करना होगा। समान रूप से समझ से बाहर कोड के समान परिवर्तन।

इसलिए, वे ठीक हो सकते हैं यदि वे निर्माण प्रक्रिया का हिस्सा हैं, और इस तरह से प्रलेखित है। जनरेटर के लिए इनपुट तब स्रोत कोड होता है, और जो भी यह उत्पादन करता है वह मध्यवर्ती परिणाम होता है, इसके साथ खिलवाड़ नहीं किया जाना चाहिए।

हालाँकि, अगर किसी का उपयोग करने के लिए एक अयोग्य कोड का उत्पादन किया जाता है जिसे स्रोत के रूप में उपयोग किया जाना है, तो उस व्यक्ति का बुरा कोड है। इससे कोई फर्क नहीं पड़ता है कि व्यक्ति यांत्रिक रूप से या हाथ से खराब कोड का उत्पादन कर रहा है, यह अभी भी बुरा कोड है, और आपको अभी भी इसके साथ एक गुणवत्ता की समस्या है।

इसलिए, आपको किसी भी अन्य डेवलपर के कोनों को काटने और खराब कोड लिखने के रूप में इसका इलाज करने की आवश्यकता है। मुझे नहीं पता कि आप अपनी दुकान पर इसे कैसे संभालते हैं।


3

अन्य उत्तरों की टिप्पणियों से ऐसा लगता है कि आप कोड जनरेटर के बजाय टीम मानकों के बारे में पूछ रहे हैं।

एक कोड जनरेशन टूल को प्रोजेक्ट में शामिल किया जाना चाहिए और इसे (जहां उपयुक्त हो) बिल्ड प्रोसेस का हिस्सा होना चाहिए। एक उदाहरण हमारी टीम पर होगा कि हम सबसोनिक 2.2 का उपयोग करते हैं जो हमने डेटाबेस ऑब्जेक्ट से बिल्ड पर कक्षाएं उत्पन्न की हैं।

ऐसा करने वाले एक्सई को परियोजना के हिस्से के रूप में एसवीएन में जांचा जाता है ताकि टीम के एक नए सदस्य को एसवीएन से नई परियोजना मिल सके और यह पता लगाने के बिना तुरंत निर्माण करें कि ये सभी डेटाबेस कक्षाएं कहां से आई हैं (इस उदाहरण में हम svn में उत्पन्न कोड को भी शामिल न करें)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.