यह कुछ ऐसा है जिसके बारे में मैं तब से सोच रहा हूँ जब से मैंने इस जवाब को विवादास्पद प्रोग्रामिंग राय में पढ़ा है :
आपका काम खुद को काम से बाहर रखना है।
जब आप अपने नियोक्ता के लिए सॉफ़्टवेयर लिख रहे हों, तो आपके द्वारा बनाया गया कोई भी सॉफ़्टवेयर इस तरह से लिखा जाए कि उसे किसी भी डेवलपर द्वारा उठाया जा सके और उसे न्यूनतम मात्रा में प्रयास के साथ समझा जा सके। यह अच्छी तरह से डिज़ाइन किया गया है, स्पष्ट रूप से और लगातार लिखा गया है, साफ-सुथरा स्वरूपित, स्वरूपित, प्रलेखित है जहाँ इसकी आवश्यकता है, रोज़ाना अपेक्षित रूप से बनाता है, रिपॉजिटरी में जाँच की जाती है, और उचित रूप से संस्करणबद्ध किया जाता है।
यदि आप एक बस की चपेट में आते हैं, नौकरी से निकाल दिया जाता है, या नौकरी से निकल जाता है, तो आपके नियोक्ता को एक पल की सूचना पर आपकी जगह लेने में सक्षम होना चाहिए, और अगला व्यक्ति आपकी भूमिका में कदम रख सकता है, अपना कोड उठा सकता है और ऊपर उठ सकता है और एक सप्ताह के भीतर शीर्ष पर चल रहा है। यदि वह ऐसा नहीं कर सकता है, तो आप बुरी तरह विफल रहे हैं।
दिलचस्प बात यह है कि मैंने पाया है कि उस लक्ष्य ने मुझे मेरे नियोक्ताओं के लिए अधिक मूल्यवान बना दिया है। जितना अधिक मैं डिस्पोजेबल होने का प्रयास करता हूं, उतना ही मूल्यवान मैं उनके लिए बन जाता हूं।
और यह इस तरह के एक के रूप में अन्य सवालों में थोड़ा चर्चा की गई है , लेकिन मैं इसे फिर से ऊपर लाने के लिए चर्चा करना चाहता था एक अधिक बिंदु रिक्त " यह एक कोड गंध है !! " बिंदु से - जो वास्तव में कवर नहीं किया गया है! गहराई में अभी तक।
मैं दस साल से एक पेशेवर डेवलपर हूं। मेरे पास एक नौकरी है जहां कोड को अच्छी तरह से लिखा गया था जिसे किसी भी अच्छे नए डेवलपर द्वारा अपेक्षाकृत जल्दी से उठाया जा सकता है, लेकिन उद्योग में ज्यादातर मामलों में, ऐसा लगता है कि बहुत ही उच्च स्तर का स्वामित्व (व्यक्तिगत और टीम के स्वामित्व दोनों) है आदर्श। अधिकांश कोड आधारों में दस्तावेज़ीकरण, प्रक्रिया और "खुलेपन" की कमी प्रतीत होती है, जो एक नए डेवलपर को उन्हें लेने और जल्दी से उनके साथ काम करने की अनुमति देगा। हमेशा बहुत सारे अलिखित छोटे ट्रिक्स और हैक होते हैं जो केवल उस व्यक्ति को जानते हैं जो कोड आधार को बहुत अच्छी तरह से जानता है ("मालिक") इसके बारे में जानता होगा।
बेशक, इसके साथ स्पष्ट समस्या यह है: क्या होगा यदि व्यक्ति क्विट करता है या "बस से टकरा जाता है"? या टीम स्तर पर: क्या होगा यदि पूरी टीम को उनकी टीम के लंच पर बाहर जाने पर फूड पॉइज़निंग हो जाती है, और वे सभी मर जाते हैं? क्या आप नए यादृच्छिक डेवलपर्स के एक नए सेट के साथ टीम को अपेक्षाकृत दर्द रहित तरीके से बदल पाएंगे? - मेरी पिछली कई नौकरियों में, मैं ऐसा बिल्कुल भी नहीं सोच सकता। सिस्टम इतनी चालाकी और हैक्स से भरे हुए थे कि आपको " बस जानना होगा ", कि आपके द्वारा किराए पर ली गई कोई भी नई टीम लाभदायक व्यवसाय चक्र (जैसे, नए स्थिर रिलीज) की तुलना में अधिक समय लेगी ताकि चीजों को फिर से प्राप्त किया जा सके। संक्षेप में, मुझे आश्चर्य नहीं होगा कि यदि उत्पाद को छोड़ना होगा।
जाहिर है, एक बार में एक पूरी टीम को खोना बहुत दुर्लभ होगा। लेकिन मुझे लगता है कि इस सब में एक और अधिक सूक्ष्म और भयावह बात है - यही वह बिंदु है जो मुझे इस धागे को शुरू करने के लिए सोच रहा है, जैसा कि मैंने पहले इन शर्तों पर चर्चा नहीं की है। मूल रूप से: मुझे लगता है कि कोड स्वामित्व के लिए एक उच्च आवश्यकता अक्सर तकनीकी ऋण का एक संकेतक है । यदि सिस्टम में प्रक्रिया, संचार, अच्छा डिज़ाइन, बहुत सारी छोटी-छोटी तरकीबें और हैक की कमी है, तो आपको "बस पता होना चाहिए", आदि - इसका आमतौर पर मतलब है कि सिस्टम उत्तरोत्तर गहरे और गहरे तकनीकी ऋण में हो रहा है।
लेकिन बात यह है - कोड स्वामित्व को अक्सर किसी परियोजना और कंपनी के लिए "निष्ठा" के रूप में प्रस्तुत किया जाता है, क्योंकि आपके काम के लिए "जिम्मेदारी लेने" का एक सकारात्मक रूप है - इसलिए यह एकमुश्त रूप से इसकी निंदा करता है। लेकिन एक ही समय में, समीकरण के तकनीकी ऋण पक्ष का अर्थ है कि कोड आधार उत्तरोत्तर कम खुला हो रहा है, और इसके साथ काम करना अधिक कठिन है। और विशेष रूप से जैसे ही लोग आगे बढ़ते हैं और नए डेवलपर्स को उनकी जगह लेनी पड़ती है, तकनीकी ऋण (यानी रखरखाव) की लागत बढ़ने लगती है।
तो एक अर्थ में, मुझे वास्तव में लगता है कि यह हमारे पेशे के लिए एक अच्छी बात होगी यदि कोड के स्वामित्व की आवश्यकता के उच्च स्तर को खुले तौर पर नौकरी की गंध (लोकप्रिय प्रोग्रामर कल्पना में) के रूप में देखा गया। इसके बजाय इसे काम में "जिम्मेदारी और गर्व" के रूप में देखा जा रहा है, इसे "अपने आप को लुभाने और तकनीकी ऋण के माध्यम से कृत्रिम नौकरी की सुरक्षा" के रूप में अधिक देखा जाना चाहिए।
और मुझे लगता है कि परीक्षण (सोचा प्रयोग) मूल रूप से होना चाहिए: क्या होगा यदि व्यक्ति (या वास्तव में, पूरी टीम) कल पृथ्वी के चेहरे को गायब कर दे। क्या यह एक बड़ी घटना होगी - संभवतः परियोजना के लिए घातक - या हम नए लोगों को लाने में सक्षम होंगे, उन्हें डोकोस को पढ़ने और फाइलों की मदद करने और कुछ दिनों के लिए कोड के साथ खेलने में मदद मिलेगी - और फिर वापस आ जाएं कुछ हफ्तों में व्यापार (और एक या एक महीने में पूर्ण उत्पादकता पर वापस)?