एक कार्यक्रम को अपने दिमाग में रखना

अगस्त 2007

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

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

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

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

यहां तक कि सर्वश्रेष्ठ प्रोग्रामर भी हमेशा अपने काम पर काम कर रहे पूरे कार्यक्रम को अपने दिमाग में लोड नहीं करते हैं। लेकिन कुछ ऐसी चीजें हैं जो आप इसमें मदद कर सकते हैं:

विचलनों से बचें। विचलन कई प्रकार के कार्यों के लिए खराब हैं, लेकिन प्रोग्रामिंग के लिए विशेष रूप से खराब हैं, क्योंकि प्रोग्रामर अक्सर उस विवरण की सीमा पर काम करते हैं जिसे वे संभाल सकते हैं।

एक विचलन का खतरा इस पर निर्भर करता है कि यह आपके दिमाग को कितना बिखेर देता है, न कि यह कितना लंबा होता है। एक प्रोग्रामर कार्यालय छोड़कर एक सैंडविच लेने जा सकता है बिना अपने दिमाग में कोड खो दिए। लेकिन गलत प्रकार का व्यवधान आपके दिमाग को 30 सेकंड में साफ कर सकता है।

अजीब बात यह है कि अनुसूचित विचलन अनुसूचित विचलनों से बदतर हो सकते हैं। यदि आप जानते हैं कि आपके पास एक घंटे में एक बैठक है, तो आप कुछ कठिन पर काम करना शुरू भी नहीं करते।

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

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

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

आप एक शक्तिशाली भाषा के प्रभाव को बॉटम-अप प्रोग्रामिंग नामक एक शैली का उपयोग करके बढ़ा सकते हैं, जहां आप कई स्तरों में कार्यक्रम लिखते हैं, जिनमें निचले स्तर उन पर ऊपर वाले स्तरों के लिए प्रोग्रामिंग भाषाओं के रूप में कार्य करते हैं। यदि आप इसे सही तरह से करते हैं, तो आपको केवल सबसे ऊपरी स्तर को अपने दिमाग में रखना होगा।

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

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

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

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

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

यदि आप एक परियोजना पर कई लोगों को काम करना चाहते हैं, तो इसे घटकों में विभाजित करें और प्रत्येक को एक व्यक्ति को दें।

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

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

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

यह केवल सच नहीं है कि संगठन व्यक्तिगत प्रतिभा पर निर्भर रहने की अवधारणा से नफरत करते हैं, बल्कि यह एक तर्कसंगत है। यह हमारे वर्तमान संगठन की अवधारणा का हिस्सा है।

शायद हम ऐसे संगठन को परिभाषित कर सकते हैं जो व्यक्तियों के प्रयासों को एक साथ लाता है, लेकिन उन्हें आपसी भागीदार होने की आवश्यकता नहीं है। संभवतः बाजार ऐसा ही एक संगठन का रूप है, हालांकि यह अधिक सटीक होगा कि बाजार को एक विकृत मामला - जैसे कि संगठन संभव नहीं होने पर मिलता है - के रूप में वर्णित किया जाए।

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

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

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

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