मैं इस प्रश्न को C ++ प्रोग्रामर के लिए डाल रहा हूँ क्योंकि: a) केवल C ++ प्रोग्रामर उदाहरणों की तकनीकी खूबियों का न्याय कर सकता है; b) केवल एक प्रोग्रामर को दूसरे प्रोग्रामर के स्वभाव के लिए एक फील होगा जो इस तरह कोड लिखता है।
मानव संसाधन और निदेशक जानते हैं कि वहाँ एक समस्या है क्योंकि वे क्षेत्र में सबूत देखते हैं। यह मेरा आह्वान है कि क्या हम प्रोग्रामर को प्रश्न में अधिक समय देते हैं। त्रुटियों में से कई एक बहुत ही बुनियादी स्तर पर हैं - मेरा सवाल (प्रोग्रामर के लिए) है कि क्या कोई है जो वरिष्ठ सी ++ डेवलपर बनने के लिए प्रोफेसरों को अपने वर्तमान कोड के नमूनों के आधार पर संदेह का लाभ दिया जाना चाहिए। गैर-प्रोग्रामर - यहां तक कि C ++ प्रोग्रामिंग के बाहर के लोग - इस पर कोई निर्णय नहीं ले सकते।
पृष्ठभूमि के लिए, मुझे एक अच्छी तरह से स्थापित कंपनी के लिए डेवलपर्स के प्रबंधन का काम सौंपा गया है। उनके पास एक एकल डेवलपर है जो अपने सभी C ++ कोडिंग (हमेशा से) में विशेषज्ञता रखता है, लेकिन काम की गुणवत्ता में कमी है। कोड समीक्षा और परीक्षण ने कई समस्याओं का खुलासा किया है, सबसे खराब स्मृति लीक में से एक। डेवलपर ने कभी भी लीक के लिए अपने कोड का परीक्षण नहीं किया है, और मुझे पता चला कि आवेदन केवल एक मिनट के उपयोग के साथ कई एमबी लीक कर सकते हैं। उपयोगकर्ता भारी मंदी की सूचना दे रहे थे, और उनका कहना था, "यह मेरे लिए कुछ भी नहीं है - अगर वे छोड़ देते हैं और फिर से शुरू करते हैं, तो यह सब फिर से होता है।"
मैंने उसे लीक का पता लगाने और उसका पता लगाने के लिए उपकरण दिए हैं, और कई घंटों तक उसके साथ बैठकर यह प्रदर्शित किया है कि उपकरण कैसे उपयोग किए जाते हैं, समस्याएँ कहाँ होती हैं और उन्हें ठीक करने के लिए क्या करना चाहिए। हम ट्रैक से 6 महीने नीचे हैं, और मैंने उसे एक नया मॉड्यूल लिखने का काम सौंपा है। इससे पहले कि यह हमारे बड़े कोड बेस में एकीकृत हो जाए, मैंने इसकी समीक्षा की, और पहले की तरह ही खराब कोडिंग की खोज करने के लिए इसे छोड़ दिया गया। जो हिस्सा मुझे समझ से बाहर लगता है वह यह है कि कुछ कोडिंग शौकिया तौर पर खराब है। उदाहरण के लिए, वह एक वर्ग (फू) चाहता था जो किसी अन्य वर्ग (बार) की वस्तु को आबाद कर सके। उन्होंने फैसला किया कि फू बार, जैसे उदाहरण के लिए होगा:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};
लेकिन (अन्य कारणों से) उन्हें फू के लिए एक डिफ़ॉल्ट निर्माणकर्ता की भी आवश्यकता थी और उनके प्रारंभिक डिजाइन पर सवाल उठाने के बजाय, उन्होंने इस रत्न को लिखा:
Foo::Foo() : m_bar(*(new Bar)) {}इसलिए हर बार जब डिफॉल्ट कंस्ट्रक्टर को बुलाया जाता है, तो एक बार लीक हो जाता है। मामलों को बदतर बनाने के लिए, फू 2 अन्य वस्तुओं के लिए ढेर से मेमोरी आवंटित करता है, लेकिन उसने विध्वंसक या कॉपी कंस्ट्रक्टर नहीं लिखा। इसलिए फू का हर आवंटन वास्तव में 3 अलग-अलग वस्तुओं को लीक करता है, और आप कल्पना कर सकते हैं कि जब फू की नकल की गई थी तो क्या हुआ था। और - यह केवल बेहतर हो जाता है - उसने तीन अन्य वर्गों पर एक ही पैटर्न दोहराया, इसलिए यह एक-बंद पर्ची नहीं है। इतने सारे स्तरों पर पूरी अवधारणा गलत है।
अगर यह कुल नौसिखियों से आया तो मुझे अधिक समझ होगी। लेकिन यह लड़का कई सालों से ऐसा कर रहा है और पिछले कुछ महीनों में इसने बहुत प्रशिक्षण और सलाह दी है। मुझे लगता है कि वह उस समय में से अधिकांश की समीक्षा या सहकर्मी के बिना काम कर रहा है, लेकिन मुझे लग रहा है कि वह बदल नहीं सकता है। तो मेरा सवाल यह है कि क्या आप किसी ऐसे व्यक्ति के साथ बने रहेंगे जो इस तरह का स्पष्ट कोड लिख रहा है?