क्या आप के साथ जाते समय अपने कोड को संकलित करने में कोई लाभ है?


183

मेरे पास हाल ही में एक नौकरी का साक्षात्कार था जिसमें उन्होंने मुझे कुछ वास्तविक कोड लिखने के लिए एक घंटे का समय दिया। यह एक बड़ी राशि नहीं थी, शायद 100 से कम लाइनें। लगभग 45 मिनट के बाद, मैंने संकलित किया, इसे चलाया, और इसे काम करने के लिए मिला। हो सकता है कि मैंने 5-10 मिनट का समय कंपाइल एरर और कुछ मामूली बग्स में बिताया हो, लेकिन कुल मिलाकर यह बहुत सहज था। (संयोग से, मुझे उनसे एक प्रस्ताव मिला।)

हालाँकि, मुझे जो अचरज हुआ, वह यह कि मैंने पूरा कोड सौंपने के बाद, साक्षात्कारकर्ता ने मुझे बताया कि केवल एक चीज जो मैंने गलत की थी, "मैं साथ नहीं जाने के रूप में संकलन नहीं कर रहा था"। मैंने उनसे पूछा कि अंतर क्या है, और उन्होंने कहा कि "यदि आपने कोड पूरा कर लिया है और आपने समय पर संकलन नहीं किया है तो आपने क्या किया होगा"।

मेरी समझ में यह एक अमान्य तर्क है, क्योंकि कोड की दी गई लंबाई के लिए "संकलन करने के लिए कोड प्राप्त करना" में आम तौर पर संकलन त्रुटियों की एक निरंतर संख्या को ठीक करना शामिल है और काफी निरंतर मात्रा में समय लगता है, जो आपके बाद ऐसा ही होना चाहिए कोड लिखना समाप्त करें, या यदि आप इसे अपने कोडिंग समय के साथ इंटरलेवे करते हैं। यदि कुछ भी, लापता अर्धविरामों की खोज के लिए आपके कोडिंग में व्यवधान डालना संभवत: आपकी दक्षता के लिए हानिकारक होगा। अत्यधिक परिस्थितियों को छोड़कर जब मैं व्युत्पन्न कक्षाओं में वर्चुअल फ़ंक्शंस जैसी चीज़ों पर किनारे-मामलों के अस्पष्ट प्रयोग कर रहा हूं, तो यह अपेक्षा करना उचित लगता है कि किसी अनुभवी डेवलपर द्वारा लिखा गया कोड समसामयिक टाइपिंग त्रुटि, और यहां तक ​​कि माइनस को संकलित करेगा। अगर यह नहीं है, यह '

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

वह भी प्रासंगिक क्यों है? मेरी राय में और मेरे अनुभव में, कोड संकलन का एक टुकड़ा अनिवार्य रूप से यादृच्छिक है, जिसमें अर्धविराम गायब हैं या नहीं जैसे चीजें शामिल हैं, और अंतर्निहित कार्यक्रम की शुद्धता के साथ बहुत कम है। (मेरे लिए, संकलन पर ध्यान केंद्रित करना, व्याकरण की जांच करने के लिए प्रूफरीडिंग के बिना एक वर्तनी-जांच के माध्यम से एक लेख चलाने जैसा है)।

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

वैसे भी, ये हाल ही में हुई कुछ घटनाएं हैं, लेकिन सामान्य तौर पर मैंने कई डेवलपर्स को अपने कोड को संकलित करने के बारे में बात करते हुए सुना है क्योंकि वे साथ जाते हैं, और अभी तक कोई भी मुझे ऐसा करने का लाभ नहीं बता पाया है। जैसा कि आप साथ चलते हैं, मैं आपके कोड के परीक्षण के लाभों को समझता हूं , लेकिन संकलन क्यों?

तो मेरा सवाल यह है: क्या कुछ ऐसा है जो मैंने याद किया? क्या वास्तव में आपके साथ जाते हुए संकलन करने का कोई लाभ है? या सॉफ्टवेयर समुदाय द्वारा प्रचारित इस प्रकार का मिथक है जिसे आपको अपने कोड को बार-बार संकलित करना होगा?


54
या तो वह, या कि मेरी आदतें उन लोगों द्वारा बुरी आदतों को कहा जा रहा है जिनके पास अलग-अलग आदतें हैं।
CaptainCodeman

9
@DocBrown यदि अंतिम लक्ष्य एक सही उत्पाद है, तो तुलना मान्य है। एक प्रोग्राम जो "रन" करता है, गलत तरीके से चलने वाले प्रोग्राम से बेहतर नहीं है। आप अपने व्याकरण की गलतियों को ठीक करने के लिए वर्तनी जांच की अपेक्षा से अधिक आपके लिए अपने कोड की जांच करने की उम्मीद नहीं कर सकते।
CaptainCodeman

7
चाहे आपके वर्कफ़्लो को परेशान करना बहुत ही व्यक्तिपरक हो और भाषा पर निर्भर करता हो, पर्यावरण का निर्माण, प्रोजेक्ट की आकार / जटिलता आदि। आईएमओ को बड़ी विरासत परियोजनाओं पर एक मुद्दा बनने की संभावना है।
pjc50

64
मैं ओपी से पूरी तरह सहमत हूं। मैं समझ नहीं पा रहा हूं कि किसी व्यक्ति के काम की आदतों के बारे में निर्णय कैसे किया जा सकता है, उदाहरण के लिए जब वह कंपाइलर शुरू करने के लिए उपयोग करता है। केवल एक चीज जो मायने रखती है, वह है प्रयासों का आउटपुट। क्या यह सही है? क्या यह बनाए रखने योग्य है? क्या यह अपेक्षित समय सीमा में चलता है? इसे लागू करने में कितना समय लगा? ये दिलचस्प सवाल हैं। बाकी सब बीएस की मनमानी है। यदि इंटरव्यू लेने वाला 2 घंटे का सही कोड लिखता है, जो पहली कोशिश पर संकलन करता है, तो समस्या कहां है? सिर्फ इसलिए कि साक्षात्कारकर्ता इसे अलग तरीके से करता है? हे भगवान।
JensG

9
यह भी उल्लेख किया जाना चाहिए कि कुछ भाषाओं और IDE (Java / [Eclipse | NetBeans | etc], C # / Visual Studio, ...) के लिए, IDE पहले से ही वास्तविक समय में पृष्ठभूमि में सब कुछ संकलित कर रहा है, जैसा कि आप टाइप करते हैं, प्रभाव आपको एक तत्काल प्रतिक्रिया लूप देता है जैसे कि आपने गलती की है। एक उम्मीद है कि आईडीई डेवलपर्स के पास इस संकलन के रूप में कुछ अनुसंधान का समर्थन होगा-आप दृष्टिकोण पर जाते हैं।
ओगरे Psalm33

जवाबों:


223

क्या वास्तव में आपके साथ जाते हुए संकलन करने का कोई लाभ है?

वहाँ है। यह आपको एक छोटा फीडबैक लूप देता है - जो सामान्य तौर पर, जब डिजाइनिंग (यूआई, सॉफ्टवेयर लिखना, विजुअल डिजाइन आदि ...) अच्छी बात है।

एक छोटी प्रतिक्रिया लूप का मतलब है कि आप त्रुटियों को जल्दी से ठीक कर सकते हैं, इससे पहले कि वे ठीक करने के लिए अधिक महंगा हो जाएं।

अपने उदाहरण को उधार लेने के लिए, आप सी-लाइक भाषा में कोडिंग कर रहे थे और }कार्यक्रम के बीच में कहीं भूल गए थे ।

यदि आप कथन लिखने के बाद संकलित करते हैं, तो आप काफी निश्चित हो सकते हैं कि आपने केवल संकलन त्रुटि पेश की है और इसे कुछ सेकंड्स में ठीक कर सकते हैं।

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


अब, हां, अंतिम परिणाम समान है, लेकिन आपने सिंटैक्टिकल मुद्दों पर अच्छी मात्रा में समय बर्बाद किया है जो कि कंपाइलर आपकी सहायता करने के लिए है - एक समय की मात्रा जो आपके साथ जाते समय संकलित करने में काफी कम हो सकती है।


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

12
@CaptainCodeman - मैं कहूंगा कि कुछ संकलन त्रुटियां हैं जिनके लिए आपको बहुत सारे कोड के माध्यम से खुदाई करने की आवश्यकता होगी। यह बड़े कोडबेस और बड़े बदलाव सेट के लिए अधिक सच है।
ऊदबिलाव

29
कभी-कभी कंपाइलर आपको संकेत के बजाय एक पहेली देता है, जैसे कि जीसीसी टेम्पलेट त्रुटियां।
pjc50

14
@ pjc50: बिल्कुल (जो अगले संकलन से पहले एक बार में बहुत अधिक चीजें नहीं बदलकर संभालना आसान है, इसलिए आपको पता है कि आपने आखिर में क्या बदला है)।
डॉक ब्राउन

21
विचार सिर्फ यादृच्छिक द्वारा संकलित करने का नहीं है। यह प्रत्येक महत्वपूर्ण कदम पर संकलित करने के लिए है, जब आप उम्मीद करते हैं कि यह अभी भी ठीक से काम करेगा। उदाहरण के लिए, मैं यह सुनिश्चित करने के लिए परीक्षण करने के लिए संकलन करूंगा कि ऑब्जेक्ट्स ठीक से बनाए / हटाए जा रहे हैं, या यह सुनिश्चित करने के लिए कि इवेंट्स को मेरे द्वारा बनाए गए नए वर्ग में ठीक से निकाल दिया जा रहा है। यदि मैं एक क्लास बनाता हूं और इसे किसी तरह से अपने प्रोग्राम में हुक करता हूं, तो मैं यह सुनिश्चित करना चाहता हूं कि मैंने अपने ऐप पर अधिक सामान हुक करने से पहले इसे सही तरीके से किया। छोटे ऐप्स के साथ कम महत्वपूर्ण, बड़े लोगों के लिए महत्वपूर्ण।
thebluefish

108

संकलन परीक्षण का एक रूप है, विशेष रूप से भाषाओं में जो हस्केल या एमएल जैसे प्रकारों का व्यापक उपयोग करते हैं । अन्य भाषाओं में यह एक सिंटैक्टिक स्कैन है जो आपको थोड़ा बताता है।

यह कहने के बाद कि, "आप जाते हैं" संकलन मुझे एक बहुत स्थितिजन्य आदत लगती है। साक्षात्कारकर्ता के निजी पूर्वाग्रह की तुलना में अधिक बार संकलन के लिए आपको "चिकोटी" होने के लिए समान रूप से चिह्नित किया जा सकता है। ऐसा लगता है कि नाइटपैकिंग है; कोई भी नहीं स्वीकार करने के लिए है कि एक साक्षात्कार है पसंद करती है aced परीक्षण; यह वेतन वार्ता के पैमानों को बताता है।

सभी बिल्ड सिस्टम तेज नहीं हैं। मैं एक (C ++) परियोजना जहां पर काम किया मेक 30 सेकंड बस बिताते थे स्टेट 'टिंग सब कुछ तय करता है कि इसे बनाने या नहीं करने के लिए आवश्यक है, और सबसे फ़ाइलें कुछ मिनटों के लिए ले निर्माण करने के लिए यदि आप परिवर्तन कर दिया था होगा। हम हर 10-15 मिनट की तुलना में अधिक बार ऐसा करने के लिए अनिच्छुक थे। कोई संदेह नहीं है जब पंच कार्ड के अपने डेक लेने और उन्हें एक अलग इमारत में ले जाने के संकलन शामिल का एक उपाख्यान की आपूर्ति करेगा ...

संकलित करें जब आपको लगता है कि आपने अपने सिर में एक पूर्ण वैचारिक इकाई की है और इसे मान्य करने के लिए तैयार हैं। वर्कफ़्लो के आधार पर सप्ताह में एक बार या एक बार।


25
जब आप अपने पंच कार्डों को लोड करने के लिए sysops पर ले जाते हैं, तो सुनिश्चित करें कि आपने कभी उन्हें कभी नहीं छोड़ा क्योंकि उन्हें सही क्रम में वापस लाना एक वास्तविक पिटा है! आह, उन दिनों के लिए जब एक आवश्यक डिबगिंग उपकरण एक लोचदार बैंड था।
gbjbaanb

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

हम्म। केवल यह कहना चाहता हूं कि एक अच्छी तरह से लिखी गई सी ++ फाइल को संकलन के लिए कुछ सेकंड से अधिक नहीं लेना चाहिए। यदि यह लंबा है, तो यह खराब कोड के लिए एक गंध है। और अगर यह इतना बड़ा है कि समस्याएँ हैं, तो मैं तर्क दूंगा कि आवेदन बहुत अखंड है। "मेरे" को कभी भी समस्या नहीं हुई, और लिनक्स संकलित करते समय भी नहीं।
१०:४२ पर डेटलाइन

2
जब मैंने छोड़ा था तो यह 1.5 मिलियन LOC था। ध्यान दें कि लिनक्स C C ++ नहीं है; टेम्प्लेट gcc में धीमे प्रतीत होते हैं, और यदि आपने कुछ चतुर और उपयोगी किया है जो कि संकलन के लिए धीमा हो जाता है, तो संकलक को रूपरेखा बनाने का कोई आसान तरीका नहीं है कि वह क्या है।
pjc50

21
@gbjbaanb मुझे लगता है कि यह कहना बेहतर होगा "उन दिनों जब स्रोत नियंत्रण एक लोचदार बैंड था।" ;)
जेसनमैकर

35

तो मेरा सवाल यह है: क्या कुछ ऐसा है जो मैंने याद किया?

हां: आपका दिमाग कंपाइलर नहीं है। जबकि एक संकलक प्रति सेकंड n संदर्भ स्विच कर सकता है, आपका मन नहीं कर सकता। एक दिन में आपके दिमाग में आने वाले संदर्भ स्विच की संख्या कोड आधार के साथ अनुभव / परिचितता जैसे कई कारकों पर निर्भर करती है कि आप मानसिक रूप से डूबे हुए हैं, आप कोड में कितने साफ हैं, कोड कितना साफ है, आप कितनी जटिल समस्या से निपट रहे हैं, आप कितने थके हुए हैं, अगर आप बार-बार बाधित होते हैं या शोर-शराबे के माहौल में होते हैं, आदि।

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

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

क्या वास्तव में आपके साथ जाते हुए संकलन करने का कोई लाभ है?

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

यदि आप बहुत कम पुनरावृत्तियों में संकलित करते हैं (यह मानता है कि संकलन प्रक्रिया को थोड़े समय के लिए अनुकूलित किया गया है) "ज़ोन" से बाहर आए बिना संकलन त्रुटियों को ठीक करना संभव है।

या सॉफ्टवेयर समुदाय द्वारा प्रचारित इस प्रकार का मिथक है जिसे आपको अपने कोड को बार-बार संकलित करना होगा?

यह सॉफ्टवेयर कम्यूनिटी द्वारा भी प्रचारित किया जाता है, लेकिन इसके पीछे इसके अच्छे कारण हैं।

मेरी समझ में यह एक अमान्य तर्क है, क्योंकि कोड की दी गई लंबाई के लिए "संकलन करने के लिए कोड प्राप्त करना" में आम तौर पर संकलन त्रुटियों की एक निरंतर संख्या को ठीक करना शामिल है और इसमें काफी समय लगता है

यह मुझे ऐसा लगता है जैसे आपके पास मध्यम से बड़ी विरासत कोड आधारों (सैकड़ों या हजारों स्रोत फ़ाइलों) के रखरखाव में बहुत कम (से नहीं) अनुभव है। यह वह जगह है जहां यह रवैया (यानी "जैसा कि आप जाते हैं") सबसे अधिक मदद करेगा, और यही वह जगह है जहां आप इस तरह की आदत बनाते हैं।

मुझे लगता है कि जिन लोगों ने आपको देखा था, वे एक समान निष्कर्ष निकालते हैं ("आपको बड़े कोड आधारों में कोई अनुभव नहीं है")।


1
"संकलन और परिवर्तन दस" - बहुत सारी परिस्थितियाँ जहाँ यह कोशिश करने के लिए सबसे छोटी सार्थक इकाई है; जैसे कि एक फ़ंक्शन और उसके सभी कॉल साइटों में एक नया पैरामीटर जोड़ना।
pjc50

7
प्रसंग स्विच। तुम मज़ाक कर रहे, है ना? यदि हम आपके कोड में सिंटैक्टिकल त्रुटियों को इंगित करने के लिए स्वचालित पृष्ठभूमि संकलन के बारे में बात करते हैं, तो यह ठीक है। लेकिन सबसे तेज़ संदर्भ स्विच आपको यह बताने में सक्षम नहीं होगा कि क्या एल्गोरिथ्म तर्क सही तरीके से लागू किया गया है या यदि एल्गोरिथ्म बिल्कुल उपयुक्त है। लेकिन यह वही है जो करीने से व्यवस्थित, त्रुटि मुक्त संकलित और तेजी से नष्ट होने के अलावा एक कामकाजी समाधान सेट करता है, लेकिन पूरी तरह से गलत कोड है।
JensG

5
@ जेन, नहीं, मैं मजाक नहीं कर रहा हूं। संकलन त्रुटियों को ठीक करने के लिए कोड पर सभी कूदने के बाद यह सुनिश्चित करता है कि आप उस समस्या के बारे में नहीं सोचते हैं जो आप वर्तमान में हल कर रहे हैं (आपको क्षेत्र से बाहर निकालता है)। यदि इसके बजाय, आप संकलित कर सकते हैं जैसा कि आप कोड लिखते हैं आप एल्गोरिथ्म की जांच पर काम कर सकते हैं - वाक्यविन्यास नहीं। संदर्भ स्विच को संभालने का सबसे तेज़ तरीका यह सुनिश्चित करना है कि आपको उनकी आवश्यकता नहीं होगी)। मेरी पोस्ट हालांकि एक आदर्श दुनिया मानती है (बड़े कोड आधारों और कम से कम अंतर-निर्भरताओं के तेजी से C ++ संकलन के साथ)।
utnapistim

1
@JensG जो एक तार्किक गिरावट प्रतीत होती है: यह संकलित कोड और चमकदार कोड के बीच चयन करने के बारे में नहीं है, बल्कि एक से अधिक बार संकलन के किसी भी संभावित लाभ के बारे में है।
जॉर्ग

1
मुझे संदेह है कि एकल वाक्य रचना त्रुटियों को ठीक करने के लिए कम समय के लिए एकाग्रता को दर्जनों बार तोड़ने का दावा एक बार तोड़ने और एक बार में एक दर्जन वाक्यविन्यास त्रुटियों को ठीक करने की तुलना में तेज है (आपके वास्तविक एल्गोरिथ्म के बारे में चिंतित होने के बाद)। यह निश्चित रूप से नहीं है कि कैसे कंप्यूटिंग में संदर्भ स्विच काम करते हैं (हम यहां सब के बाद थ्रूपुट के लिए अनुकूलन करने की कोशिश कर रहे हैं)। और मैं C ++ कोड के लगभग 500k LoC के साथ एक प्रोजेक्ट पर काम कर रहा हूं जो एक दशक से अधिक समय से विकसित हुआ है, इसलिए मुझे उम्मीद है कि हम अनुभवहीनता कार्ड अभी तक नहीं खींचेंगे?
वू

26

मुझे लगता है कि यहां थोड़ी बहुत पेशेवर स्नोबेरी है। निहितार्थ यह प्रतीत होता है "यदि आपको कभी भी नियमित रूप से संकलन करने की आवश्यकता नहीं है, तो आपने कभी भी उस चीज़ के साथ काम नहीं किया है जो जटिल है - कुछ और अनुभव प्राप्त करें और जब आप ठीक उसी तरह काम करना सीख लें, जैसा हम करते हैं।"

लेकिन जाहिर है कि इसका एक और पक्ष भी है। कुछ परियोजनाओं को संकलित करने के लिए एक उम्र लगती है। मैंने ऐसे रूपरेखाओं के साथ काम किया है जो मामूली संपादन के बाद भी संकलन करने में 30 मिनट या उससे अधिक समय लगाती हैं। अगर आपको कभी हेडर फाइल को एडिट करने की जरूरत हो तो स्वर्ग आपकी मदद करता है। पूर्ण पुनर्मिलन आमतौर पर रातोंरात किए जाते हैं, और यदि आप अपनी गलतियों को पकड़ने के लिए संकलक पर भरोसा कर रहे हैं, तो अभी भी दुर्लभ त्रुटियां हैं जो एक आंशिक निर्माण के दौरान पता नहीं चलेंगी। आप इन शर्तों के तहत हर 5 मिनट में फिर से संकलन नहीं करते हैं - जब तक आप आलसी महसूस नहीं कर रहे हैं

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

यदि आप निरंतर पुनर्मूल्यांकन के प्रशंसक नहीं हैं, तो आप अच्छी कंपनी में हैं। यहां देखें डोनाल्ड नथ:

आपके वास्तविक प्रश्न के रूप में, तत्काल संकलन और "यूनिट टेस्ट" का विचार मुझे शायद ही कभी अपील करता है, जब मैं पूरी तरह से अज्ञात वातावरण में अपना रास्ता महसूस कर रहा हूं और क्या काम करता है और क्या नहीं के बारे में प्रतिक्रिया की आवश्यकता है। अन्यथा, बहुत सारा समय उन गतिविधियों पर व्यर्थ होता है जिन्हें मुझे कभी भी प्रदर्शन करने या यहां तक ​​कि सोचने की आवश्यकता नहीं होती है।


यह सब कहा जा रहा है ... यदि आप एक संदर्भ में काम कर रहे हैं जहां संकलन एक नि: शुल्क कार्रवाई है, तो आप क्यों नहीं करेंगे? घर पर, व्यक्तिगत प्रोजेक्ट्स पर, मैं हर 30 सेकंड में लगभग एक बार ctrl-S को हिट करता हूं और एक IDE में लगभग अक्सर "कंपाइल" शॉर्टकट, जो वास्तविक समय में त्रुटि हाइलाइटिंग प्रदान करने के लिए कंपाइलर के फ्रंट एंड के माध्यम से कोड चलाता है। एक नि: शुल्क दोपहर का भोजन क्यों पास करें?


मैं असहमत हूँ कि संकलन करना नि: शुल्क है, ध्यान भंग करना महंगा है! लेकिन अन्यथा, अच्छा जवाब, धन्यवाद :)
CaptainCodeman

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

2
I hit ctrl-S about once every 30 seconds। मैं शायद दो बार बचता हूं अक्सर लोल। यह वास्तव में बुरी आदत है। कभी-कभी मैं कोड की एक पंक्ति के बीच में बचा सकता हूं, और फिर इसके अंत में फिर से बचा सकता हूं। जब भी मैं एक सेकंड के लिए सोचने के लिए रुकता हूं और टाइपिंग नहीं करता, तो मैं बचा लेता हूं।
क्रंचर

21

आपके जाते ही संकलन करने के गुण हैं। लेकिन मैं बहुत सहमत हूं कि कार्य पर बने रहना एक ठीक कोडिंग रणनीति है।

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

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


5
सिमेंटिक और सिटिक्टिक त्रुटियों के बीच संबंध को उजागर करने के लिए +1
डॉक ब्राउन

15

जैसा कि आप साथ चलते हैं, मैं आपके कोड के परीक्षण के लाभों को समझता हूं, लेकिन संकलन क्यों?

लेकिन जब आप अपने हिसाब से संकलन नहीं करेंगे तो आप अपने कोड का परीक्षण कैसे करेंगे?

चरम मामला परीक्षण-संचालित विकास (टीडीडी) है। यह स्पष्ट है कि टीडीडी आपकी रणनीति के साथ काम नहीं करता है, क्योंकि टीडीडी का अर्थ है, परीक्षण-परीक्षण, संकलन (असफल होना), लेखन-कोड, संकलित, रन-टेस्ट, फिक्स-बग, संकलक, फिर से संकलित करने का अत्यंत छोटा चक्र। -आग, रन-टेस्ट, और इतने पर ...

इसलिए हर कोई TDD नहीं करता, कम से कम हमेशा (मुझे भी, मैं मानता हूं)। अपनी वर्तमान रणनीति के साथ, आपको कभी भी टीडीडी की कोशिश करने का मौका नहीं मिलेगा। लेकिन यहां तक ​​कि जब आप टीडीडी नहीं कर रहे हैं, तो यह आपके कोड को नियमित रूप से परीक्षण करने के लिए अत्यधिक उपयोगी IMHO है - जब आप इसे नियमित रूप से संकलित नहीं करते हैं तो यह संभव नहीं है। और जब आपका परीक्षण विफल हो जाता है, तो आप इसे डिबग करने के लिए दौड़ रहे हैं (जो आपको यह समझने में मदद कर सकता है कि आपके द्वारा कुछ मिनट पहले लिखी गई अच्छी दिखने वाली एल्गोरिथ्म इतनी अच्छी व्यवहार नहीं करती है जितना आपने सोचा था कि इसे करना चाहिए)। और जितना अधिक कोड आप संकलन के बिना लिखते हैं, उतना ही अधिक कोड आप परीक्षण के बिना लिखते हैं, इसलिए अधिक संभावना यह होगी कि आप एक ऐसे मामले में भाग लेते हैं जहां आप यह अनुमान नहीं लगा सकते हैं कि समस्या को ठीक करने का समय "ओ (1)" है, जैसा कि आप ने लिखा।


1
मैं आपसे सहमत हूं, लेकिन मुझे लगता है कि एक कार्यक्रम को संकलित करने के बीच एक अंतर है क्योंकि आप इसे चलाना चाहते हैं, बनाम संकलित करना जब परीक्षण (या संकलन त्रुटियों को ठीक करने) के लिए कुछ भी सार्थक नहीं है।
CaptainCodeman

@CaptainCodeman: मुझे लगता है कि कोड की 100 लाइनें लिखते समय, लगभग हमेशा बहुत सारे छोटे हिस्से होने चाहिए, जिन्हें व्यक्तिगत रूप से अपने लिए परीक्षण किया जा सकता है। कोड की 100 पंक्तियों का आम तौर पर 4 और 15 कार्यों (या> 20, यदि आप बॉब मार्टिन की शैली में कोड करते हैं) के बीच कुछ है।
डॉक ब्राउन

5
@CaptainCodeman: TDD में परीक्षण करने के लिए "सार्थक कुछ भी नहीं" है। क्लासिक उदाहरण है कि आप एक नया वर्ग लिखना चाहते हैं (इसे फू कहते हैं) तो आप जो पहला काम करते हैं वह एक इकाई परीक्षण और लिखना है new Foo();जो स्पष्ट रूप से संकलन करने में विफल रहेगा क्योंकि आपने वर्ग परिभाषा नहीं लिखी है। TDD में यह एक संकलक को चलाने का एक वैध कारण है - यह साबित करता है कि आपकी इकाई परीक्षण काम कर रही है (असफल होकर)।
स्लीपबेटमैन

@slebetman: उस उपयोगी टिप्पणी के लिए धन्यवाद। मैं जोड़ना चाहूंगा कि IMHO यह TDD तक ही सीमित नहीं है। कोड की 100 पंक्तियाँ लिखते समय, बीच में परीक्षण करने के लिए हमेशा कुछ सार्थक होता है, यदि आप TDD करते हैं या नहीं।
डॉक ब्राउन

14

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

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

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

हालांकि, आपको इसके लिए चिह्नित नहीं करने के लिए, विश्वास को उचित ठहराना होगा, हालांकि। यदि आपने बिना किसी संकलन के कुछ लिखने में 45 मिनट का समय लगाया था, तो उसे डिबग करने के लिए एक और 45 मिनट की आवश्यकता थी, मैंने आपको बहुत भारी तौला होगा।


8

अक्सर संकलन करने के बारे में एक महत्वपूर्ण बात, अन्य उत्तरों से जहां तक ​​मैं देख सकता हूं, यह गायब है: यदि आप शायद ही कभी संकलन करते हैं और बड़ी संख्या में संकलक त्रुटियां प्राप्त करते हैं, तो उनमें से अधिकांश अर्थहीन हैं, क्योंकि वे पहली त्रुटि से उत्पन्न होते हैं। ऐसा इसलिए हो सकता है क्योंकि आपके पास गलत प्रकार, या टाइपो, या सादे वाक्यविन्यास त्रुटि थी जो कुछ घोषणा को अमान्य बनाता है।

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

नियमित बिल्ड के लिए जा रही एक और चीज है, जैसे ही आपके पास लिखित कोड का एक पूर्ण ब्लॉक होता है, जो संकलन करना शुरू कर देता है, कुछ भी आपको संकलित करने से रोकता है। आप तब और अधिक कोड लिखना जारी रख सकते हैं जब तक संकलन पूरा नहीं हो जाता है, तब तक आप नए संपादन सहेजते नहीं हैं। तो निर्माण के इंतजार में व्यावहारिक रूप से कोई समय बर्बाद नहीं हुआ है। यदि आप उस समय तक प्रतीक्षा करते हैं जब तक कि आप उस समय जो कुछ भी लिखने जा रहे हैं वह सब कुछ नहीं लिखा है, तो आपको बिना कुछ किए संकलन का इंतजार करना होगा। यह मूल रूप से पृष्ठभूमि में स्वचालित रूप से आधुनिक आईडीई क्या कर सकता है, इसका मैन्युअल संस्करण है।


दिलचस्प है, यह नियमित रूप से संकलन करने का एक अच्छा कारण है, भले ही संकलन धीमा हो । अच्छी बात।
sleske

3

एक पर्याप्त रूप से अनुभवी प्रोग्रामर के लिए संकलन कोड कभी भी अड़चन नहीं है।

एक बार जब आप किसी भाषा को अच्छी तरह से जान लेते हैं (जब आपको अब वाक्यविन्यास के बारे में नहीं सोचना पड़ता है और इसके बजाय केवल कार्यक्षमता के लिए कोड होता है) तो आप सरल वाक्य रचना त्रुटियों को नहीं करते हैं। जो आप करते हैं, वे आमतौर पर टाइपो या कॉपी-पेस्ट बग होते हैं, और उन्हें थोड़े से संकलन के साथ कम क्रम में साफ किया जा सकता है।

मैं नियमित रूप से संकलन के बिना पूरे दिन कोड लिखता हूं, फिर मैं संकलित करता हूं और सिंटैक्स त्रुटियों को ठीक करता हूं और कंपाइलर रिपोर्ट को चेतावनी देता हूं इससे पहले कि मैं अपना कोड (एक नोट के साथ कहता हूं कि "परीक्षण करने की आवश्यकता है!" )। मुझे कुछ ही मिनटों में C या C ++ कोड की 1,000+ लाइनों को साफ करने में कोई समस्या नहीं है।

दूसरी ओर डिबगिंग और परीक्षण होता है, जिसमें कुछ समय लगता है। सभी प्रकार के कारणों के लिए तर्क त्रुटियां उत्पन्न होती हैं और मुझे अभी तक एक कंपाइलर से मिलना है जो मुझे उस सबरूटीन के बारे में बताएगा जिसे मैं लिखना पूरी तरह से भूल गया हूं, या यह नोटिस करूंगा कि मेरा बाइनरी ट्री काम नहीं करता है क्योंकि मैं node->leftतब होना चाहिए जब यह होना चाहिए था node->right

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

ps - अगर मैं इसे पढ़कर आपको समीक्षा कोड देख रहा होता, तो मैं आपको मौके पर ही काम पर रख लेता। यही एक समर्थक हर बार करता है।


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

@ उत्तर आपके उत्तर के लिए धन्यवाद; यह जानना अच्छा है कि मैं इस तरह का एकमात्र कोड नहीं हूं!
CaptainCodeman

3
@ कैप्टेनकोडमैन मैं अच्छी तरह से जानता हूं कि कंपाइलर त्रुटियों की तुलना में लॉजिक एरर्स अधिक कपटी होते हैं। लेकिन यह एक संकलक के बारे में उसका दावा था कि आप लापता कोड के बारे में बताने में असमर्थ हैं जिसे मैं विवाद करना चाहता था। जब तक कि आप जानबूझकर गलत (या अधूरा) कोड लिख रहे हैं, जो संकलन करता है…, लेकिन यह तर्क उस तर्क को हरा देता है जो संकलक को नहीं पकड़ सकता है वह वास्तविक समस्या IMO है। हेक, मैं भी संकलक को उस लाइन पर ले जाने के लिए उपयोग करता हूं जहां मुझे अगली बार कुछ कोड लिखने की आवश्यकता है। लेकिन शायद मैं बहुत आलसी हूँ।
इयान गोल्डबी

1
@IanGoldby: आपने इस बिंदु को पूरी तरह से याद किया और मैं यहाँ तक कहूँगा कि आपने मेरे शब्दों को ट्विस्ट करने के लिए चुना। कंपाइलर आपको लापता कोड के बारे में चेतावनी नहीं दे सकता है उसी तरह मैं आपको यह नहीं बता सकता कि आप कल नाश्ते के लिए क्या खाएंगे। जानबूझकर वाक्यविन्यास त्रुटियों का परिचय इसलिए संकलक आपको याद दिलाएगा कि एक प्रोग्रामिंग तकनीक है; यह एक त्रुटि के रूप में योग्य नहीं है या संकलक मानसिक महाशक्तियों को नहीं देता है।
बराबर

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

3

नहीं, जब तक आपने पर्याप्त मात्रा में कोड (और 'पर्याप्त राशि' कोडर और लिखे जाने वाले कोड पर निर्भर करता है) को संकलित करना अनुचित नहीं है।

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

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

संक्षेप में, यहाँ कोई सही उत्तर नहीं है - साक्षात्कारकर्ता गलत नहीं है, लेकिन न तो आप हैं। वह करें जो आपको उत्पादक बनाता है और यह भूल जाता है कि कोई भी आपको बताता है कि आप क्या करने वाले हैं। F7नियमित रूप से हिट करने की आपकी प्रवृत्ति की तुलना में कोडिंग के बारे में बहुत अधिक महत्वपूर्ण कारक हैं (या नहीं) बिल्कुल कोई परिणाम नहीं है।


आपका दूसरा पैराग्राफ अस्पष्ट है; आप इसे संपादित करना चाह सकते हैं, यह स्पष्ट करने के लिए कि "भयानक कोडर" नियमित रूप से संकलित होना चाहिए या नहीं। (क्या आपने "t" जोड़ा और "no" को "not" में बदल दिया?)
DougM

@ डगमग - टा बहुत।
gbjbaanb

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

2

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

कहा जा रहा है, मैं कोड की सबसे छोटी इकाई को संकलित करने और चलाने की कोशिश करूंगा जो वास्तव में एक परिणाम उत्पन्न कर सकता है। आधे घंटे पहले मैं कुछ खोज परिणामों को प्रिंट करने का साधन बना रहा था और मैंने इसे बेहतर दिखने के लिए परिणाम में बदलाव करते हुए आधा दर्जन परीक्षण प्रिंट (.pdf, पेपर नहीं) किए - प्रति 10 में लगभग 1 संकलन की दर लाइनों।


1

मेरी राय में और मेरे अनुभव में, कोड संकलन का एक टुकड़ा अनिवार्य रूप से यादृच्छिक है, जिसमें अर्धविराम गायब हैं या नहीं जैसे चीजें शामिल हैं, और अंतर्निहित कार्यक्रम की शुद्धता के साथ बहुत कम है। (मेरे लिए, संकलन पर ध्यान केंद्रित करना, व्याकरण की जांच करने के लिए प्रूफरीडिंग के बिना एक वर्तनी-जांच के माध्यम से एक लेख चलाने जैसा है)।

मेरा अनुभव बहुत अलग है: 5% से भी कम संकलन त्रुटियां जो मुझे मिलती हैं वे वाक्य रचना के बारे में हैं । मैं भाषा को अच्छी तरह से जानता हूं, जब मुझे त्रुटियां मिलती हैं तो यह ज्यादातर प्रकार की त्रुटियां होती हैं, मुझे बताती हैं कि शब्दार्थ सही नहीं हैं।

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

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

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

उन मामलों में आपको यह मानना ​​होगा कि आपने अभी तक जो कोड नहीं पढ़ा है, वह सही है, और समस्या होने पर आलस्य की जांच करें।

कोड की दी गई लंबाई के लिए "कोड संकलित करना" आम तौर पर संकलन त्रुटियों की एक निरंतर संख्या को ठीक करना शामिल है और समय की एक निरंतर निरंतर मात्रा लेता है, जो कोड लिखने के बाद आप इसे करते हैं, या यदि आप इंटरलेव करते हैं, तो ऐसा ही होना चाहिए यह आपके कोडिंग समय के साथ है।

संदर्भ-स्विचिंग आपके मस्तिष्क के लिए महंगा है, इसलिए जैसे ही आप उन्हें लिखते हैं, छोटी त्रुटियों को ठीक करना अधिक कुशल हो सकता है।

संपादित करें: मैं स्रोत नियंत्रण के साथ एक सादृश्य भी बना सकता हूं, जब एक पूरी टीम समान स्रोतों पर काम कर रही हो। आपके साथ जाते समय संकलन करना बार-बार कमिट करने जैसा है, यह अंत में बहुत दर्द होने से बचने में मदद करता है जब आपको सब कुछ मर्ज करना और सुलझाना पड़ता है।

आप कहते हैं कि आप अपने पाठ के तहत लाल रेखाओं जैसी चीज़ों को निष्क्रिय कर देते हैं। क्या आप भी ऐसा करते हैं जब ईमेल टाइप करते हैं या तकनीकी दस्तावेज लिखते हैं? फिर आपको गलतियों को ठीक करने के बजाय सभी पृष्ठों को फिर से पढ़ना होगा।

एक और फायदा यह है कि आपके कोड पर काम करते समय, यदि आप इसे हर समय संकलित या निकट-संकलित करते हैं, तो आप बहुत अधिक शब्दार्थ-आधारित आईडीई सुविधाओं (सुरक्षित नाम बदलने, रीफैक्टरिंग, एक प्रतीक का उपयोग करना ...) का लाभ उठा सकते हैं। ।

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


1
मैं आमतौर पर गुस्सा करने वाले कंपाइलर "फीचर्स" को ऑटो-फॉर्मेटिंग की तरह बंद कर देता हूं, आपके टेक्स्ट के नीचे लाल रेखाएं आ जाती हैं, आदि जैसे मुझे लगता है कि मैं इन डंबल डाउन फीचर्स के बिना ज्यादा प्रोडक्टिव हूं।
कैप्टनकोडमैन

1

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

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

फिर कोड लिखने का एक छोटा सा समय आता है जो संकलित करता है।

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

इस साक्षात्कारकर्ता ने मेरे उत्तर में दस शब्दों से आच्छादित चीज़ पर ध्यान केंद्रित किया। जो वास्तविक कार्य समय के 10 प्रतिशत या उससे कम का प्रतिनिधित्व करते हैं। विश्वसनीय और कामकाजी कोड का उत्पादन करने के लिए उस डेवलपर की क्षमता पर लगभग शून्य प्रभाव है।


यह काफी काम की बात है। मेरी राय में, एक अच्छा डेवलपर पूरे दिन कागज पर कोड लिखने में सक्षम होना चाहिए, और फिर दिन के अंत में इसे टाइप करें।
कप्तानकोडमैन

1

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

इन दिनों कंपनियां सिर्फ एक तैयार उत्पाद में दिलचस्पी नहीं रखती हैं। वे जानना चाहते हैं कि यह "नियंत्रण में" था। उनके लिए, "वहाँ आधा मजा मिल रहा है।"


इससे पहले कि 16 जवाबों में जो कुछ पोस्ट किया गया था, उस पर कुछ भी करने की पेशकश नहीं करता है
gnat

2
धन्यवाद, लेकिन हम किस तरह के नुकसान की बात कर रहे हैं? निश्चित रूप से, जब तक कि आपने कुछ कठोर नहीं किया है जैसे कि गलती से गलत भाषा में लिख दें तो आपको संकलन त्रुटियों के कारण कभी भी किसी कोड को फिर से लिखना नहीं पड़ेगा।
कैप्टनकोडमैन

@CaptainCodeman: यह कंपनियों को बेहतर महसूस कराता है, और "बीमा" का एक रूप है। यह कुछ ऐसा है जिसमें पैसा खर्च होता है, लेकिन ज्यादातर लोग (प्रबंधकों सहित) "रात में बेहतर नींद लेते हैं।"
टॉम औ

@gnat: जिस बिंदु को मैं बनाने की कोशिश कर रहा था वह यह था कि अधिकांश लाभ "कॉर्पोरेट" स्तर के लाभ थे, और यह कुछ ऐसा है जो प्रोग्रामर को करना चाहिए क्योंकि बॉस ने उसे बताया था, इसलिए नहीं कि प्रोग्रामर को लगता है कि यह सही है या गलत है।
टॉम ऑउ

"छोटी प्रतिक्रिया पाश" के पक्ष में अच्छी तरह से अंक पहले से ही बनाए गए हैं और यहां पहले ही जवाब में अच्छी तरह से समझाया गया है; मैं ईमानदारी से यह नहीं देखता कि कैसे "इन दिनों कंपनियों के बारे में नंगे पैंतरेबाज़ी करना" पहले से बताई गई बातों के लायक कुछ भी जोड़ता है
gnat

1

यहां अन्य उत्तर नौकरी पर अक्सर संकलन के लिए एक अच्छा बचाव माउंट करते हैं , लेकिन चूंकि आपका प्रश्न साक्षात्कारों के आसपास केंद्रित है , इसलिए मैं इसके कोण से निपटना चाहूंगा।

मेरे साक्षात्कार में, मैं इसके ठीक विपरीत करता हूं: उम्मीदवार एक कंपाइलर का उपयोग नहीं कर सकते। वे श्वेत बोर्ड पर छोटे कार्यक्रम लिखते हैं और फिर हम उनकी चर्चा करते हैं। मैंने पाया है कि बहुत सारे डेवलपर्स कंपाइलर (या दुभाषिया) का उपयोग बैसाखी के रूप में करते हैं, और यह समय की बहुत बड़ी बर्बादी भी है। अगर मैं आपको बहुत सारे पैसे दे रहा हूं और आप कंपाइलर के बिना भी सही ढंग से FizzBuzz नहीं लिख सकते हैं, तो आप इसे दीर्घकालिक आधार पर कभी नहीं काटेंगे, ऐसी समस्याओं पर काम करना जो खिलौना अभ्यास से 100 गुना अधिक कठिन हैं साक्षात्कार में। और फिर भी इन सरल अभ्यासों ने साक्षात्कार के किसी अन्य भाग की तुलना में अधिक उम्मीदवारों को मात दी।

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

मैं यह दावा नहीं कर रहा हूं कि मेरा दृष्टिकोण "एक सही तरीका" है, लेकिन इसने मुझे बहुत अच्छी तरह से सेवा दी है। इतने सारे सॉफ्टवेयर मेथोडोलॉजी जो एक बड़े अक्षर से शुरू होते हैं, साक्षात्कार के लिए "जनादेश" के बराबर संख्या में होते हैं। वे सब चारपाई हैं। आपको वह करने की जरूरत है जो आपके और आपके व्यवसाय के लिए काम करे।


0

बड़ी परियोजनाओं में, कई सबरूटीन्स के साथ, आप इन भागों का परीक्षण करना चाहते हैं, उन्हें बड़ी योजना में उपयोग करने से पहले, क्योंकि यह डीबग करना आसान है अगर आपको पता है कि कुछ हिस्से पहले से ही काम करते हैं।

इन छोटे टुकड़ों का परीक्षण करने के लिए, आपको संकलन करने की आवश्यकता है।

यह हो सकता है कि साक्षात्कारकर्ता इस स्थिति को एक छोटे से कार्यक्रम के साथ भ्रमित करता है जिसे इस तरीके से डिज़ाइन नहीं किया गया है।


0

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

शुरू से अंत तक इस तरह एक अज्ञात कोड आधार पढ़ना काफी अनुत्पादक हो सकता है (आप एक संकलक नहीं हैं), जबकि आवेदन को संकलित / चलाने से आपको जल्दी से एक बड़ी तस्वीर मिल जाएगी।


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