क्रच प्रोग्रामर

जोएल स्पोलस्की द्वारा पोस्ट किया गया मूल ।

लेख ओवर-इंजीनियरिंग के लिए समर्पित है और जो लोग पुराने बैसाखी समाधानों को सिर्फ इसलिए पसंद करते हैं क्योंकि वे बहुत सरल हैं। कटौती के तहत अनुवाद।

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

आगे बढ़ो! मैं इंतजार कर रहा हूं।

नोट। पेरेव ।: काम पर कोडर - साक्षात्कार का एक संग्रह। जाने-माने प्रोग्रामर सवालों की एक ही सूची का जवाब देते हैं। एक साक्षात्कार - एक अध्याय। केवल 15 अध्याय।

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

एक बैसाखी प्रोग्रामर कहने से डरता नहीं है: "एकाधिक विरासत चूसता है। उसे बाहर फेंक दो। बस इसे फेंक दो। "

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

और यहाँ Zetsinski नेटस्केप के बारे में क्या कहते हैं: "हमें C ++ और मल्टीथ्रेडिंग का उपयोग नहीं करने जैसे समाधानों के साथ उत्पाद को समय पर जारी करने की अनुमति दी गई थी।"
बाद में उन्होंने नेटस्केप में एक ईमेल क्लाइंट लिखा, लेकिन स्क्रीन पर संदेशों को सीधे प्रदर्शित करने के लिए जिम्मेदार टीम ने अपने घटक को कभी जारी नहीं किया। “हमें खिड़की के केंद्र में एक बड़ी खाली आयत की आवश्यकता थी, जहाँ हम केवल पाठ प्रदर्शित कर सकते थे। लेकिन वे सैद्धांतिक रूप से परियोजना के करीब पहुंच गए, डोम / डीटीडी की ओर से चीजों को देखने की कोशिश कर रहे थे। "हम्म, ठीक है ... हमें केवल अमूर्तता की एक अतिरिक्त परत पेश करने की जरूरत है, और प्रतिनिधि को प्रतिनिधि को सौंपना है, जिसके बाद प्रतीक अंततः स्क्रीन पर दिखाई देगा।"

"ऐसा लगता है कि ओवर-इंजीनियरिंग आपको बहुत परेशान करती है," पीटर ने कहा।

"हाँ," Zawinski कहा। - दिन के अंत में, बस कमबख्त उत्पाद जारी करें! बेशक, इसे साफ करने के लिए कोड को फिर से लिखना शांत है, और तीसरी बार से यह वास्तव में अधिक सुंदर हो जाएगा। लेकिन वह लक्ष्य नहीं है। आप यहां कोड लिखने के लिए नहीं, बल्कि उत्पादों को जारी करने के लिए हैं!

मेरे हीरो

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

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

क्रच प्रोग्रामर व्यावहारिक होते हैं। Zawinski ने रिचर्ड गेब्रियल के अभिज्ञान को, " बदतर, बेहतर " कहा। 50% आदर्श समाधान जो लोगों के पास पहले से ही अधिक समस्याओं को हल करेगा और 99% आदर्श से अधिक समय तक जीवित रहेगा, जो किसी के पास नहीं है, क्योंकि यह आपकी प्रयोगशाला में झूठ बोल रहा है, जहां आप लानत चीज को असीम रूप से पॉलिश करते हैं। रिहाई एक विशेषता है। एक बहुत महत्वपूर्ण विशेषता। यह आपके उत्पाद में होना चाहिए।

एक सिद्धांत जो किसी भी बैसाखी प्रोग्रामर के लिए अच्छी तरह से जाना जाता है: कोई भी कोडिंग तकनीक जो सिर्फ थोड़ी ओवरकम्प्लीट है, वह आपके प्रोजेक्ट को दफन कर देगी। क्रच प्रोग्रामर C ++, टेम्प्लेट, मल्टीपल इनहेरिटेंस, मल्टीथ्रेडिंग, COM, CORBA और बहुत सारी अन्य तकनीकों से बचते हैं, जिनके एप्लिकेशन को उचित लगता है यदि आप इसके बारे में बहुत अधिक और लंबे समय तक सोचते हैं, लेकिन जो मानव दिमाग के लिए थोड़ा जटिल हैं।

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

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

विषय पर अतिरिक्त सामग्री:

जावा ऑवर इंजीनियरिंग ( क्लास फैक्टरी )
गणितज्ञ के लिए शर्म की बात है (दिमित्री Dolgov द्वारा एक शानदार नोट)