रेक, जिस पर कदम रखने लायक नहीं है

अनुवादक से: यह जोएल स्पोल्स्की के एक लेख का अनुवाद है। 2 साल बाद, यह लेख पहले से ही संयुक्त राज्य अमेरिका में ऑटोमोबाइल अधिकार प्राप्त करने में सक्षम होगा, और दो और के बाद - और न केवल वहां। हां, वह 14 साल की है (या 14 साल और 11 दिन की), लेकिन उसने प्रासंगिकता का एक भी ग्राम नहीं खोया है। मैं नियमित रूप से देखता हूं कि कैसे प्रोग्रामर (और खुद को, कई बार) इस रेक पर कदम रखने की कोशिश कर रहे हैं। तथ्य यह है कि मुझे उसका अनुवाद हैबे पर नहीं मिला, यह अच्छी तरह से संकेत दे सकता है कि मैं बुरी तरह से देख रहा था। कृपया मुझे LAN में अनुवाद त्रुटियों के बारे में सूचित करें



UPD: यह जोएल के लेखों के अनुवाद का पता लगाता है , जिसमें यह भी शामिल है, प्रोग्रामिंग पर जोएल के पेपर संस्करण में भी है



अंत में, नेटस्केप 6.0 का पहला सार्वजनिक बीटा जारी किया गया। संस्करण 5.0 मौजूद नहीं है। पिछले प्रमुख रिलीज, संस्करण 4.0, लगभग तीन साल पहले जारी किया गया था। तीन साल इंटरनेट की दुनिया में एक अविश्वसनीय रूप से लंबा समय है। इस समय, नेटस्केप बैठ गया और असहाय रूप से अपने बाजार में गिरावट को देखा।



रिलीज के बीच इतने लंबे इंतजार के लिए उनकी आलोचना करना मेरे लिए थोड़ा मुश्किल है। उन्होंने इसे उद्देश्य पर नहीं किया, है ना?



सच नहीं है! ठीक यही उन्होंने किया। और यह उन्होंने सबसे बड़ी रणनीतिक गलती की जो एक सॉफ्टवेयर कंपनी कभी भी कर सकती है।



उन्होंने खरोंच से कोड को फिर से लिखने का फैसला किया।



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



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



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



पढ़ना कोड लिखने की तुलना में कठिन है



यही कारण है कि कोड का पुन: उपयोग करना इतना मुश्किल है। यही कारण है कि टीम में हर किसी को स्ट्रिंग में विभाजित करने के लिए अपना स्वयं का कार्य है। वे अपने कार्यों को लिखते हैं क्योंकि अपने स्वयं के फ़ंक्शन को लिखना पुराने के काम को समझने की तुलना में आसान और अधिक मजेदार है।



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



क्यों गड़बड़ी?



"ठीक है," वह कहेगा, "इस समारोह को देखो। वह दो पेज लंबा है! लगभग सभी अनावश्यक है। हां, मुझे यह भी पता नहीं है कि इनमें से आधे एपीआई कॉल यहां क्यों हैं? "



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



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



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



इनमें से प्रत्येक बग के पाए जाने से पहले कार्यक्रम का उपयोग करने का वास्तविक समय सप्ताह बीत गया। एक प्रोग्रामर को पुन: पेश करने और उन्हें ठीक करने में कई दिन लग सकते हैं। अक्सर ऐसा होता है कि एक पैच कोड की सिर्फ एक पंक्ति होती है, या शायद एक-दो अक्षर भी होते हैं, लेकिन इन दोनों पात्रों में बहुत समय लगाया जाता है।



जब आप कोड को फेंक देते हैं और इसे फिर से लिखते हैं, तो आप इस सारे ज्ञान को फेंक देते हैं। ये सभी निश्चित कीड़े हैं। प्रोग्रामरों के काम के वर्ष।



आप बाजार में अपने लाभ को फेंक देते हैं। आप अपने प्रतिद्वंद्वियों को दो या तीन साल देते हैं, और यह, मेरा विश्वास करो, सॉफ्टवेयर विकास के संदर्भ में बहुत समय है।



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



यह कोड लिखने के लिए बड़ी मात्रा में धन का उपयोग है जो पहले से मौजूद है।



इसमें से कौन सा रास्ता? सभी खातों के अनुसार, नेटस्केप कोड वास्तव में खराब था। ठीक है, वह बुरा हो सकता है, लेकिन, आप जानते हैं क्या? यह वास्तविक कंप्यूटर सिस्टम की एक जंगली संख्या पर काफी अच्छी तरह से काम करता है।



जब प्रोग्रामर कहते हैं कि उनका कोड एक भयानक गड़बड़ है (और वे हमेशा कहते हैं कि), इसका मतलब आमतौर पर तीन प्रकार की समस्याएं होती हैं।



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



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



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



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



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