मैं 30 वर्षों से प्रोग्रामिंग कर रहा हूं। और प्रोग्रामिंग में मेरा रास्ता Z80 और 6502 माइक्रोप्रोसेसरों से आधुनिक मशीनों तक फैला है, प्रोग्रामिंग भाषाओं से जैसे कि BASIC, असेंबली, C, C ++ से Tcl, पर्ल, लिस्प, ML, कोसम या आर्क, रूबी, गो वगैरह।
यहाँ मैं प्रोग्रामिंग में क्या सीखा की एक सूची है:
0. प्रोग्रामिंग एक शिल्पकार की नियति है, वैज्ञानिक या इंजीनियर नहींप्रोग्रामिंग विज्ञान या इंजीनियरिंग की तुलना में एक शिल्प की तरह अधिक है। यह उपकरण का उपयोग करने की क्षमता में व्यक्त कौशल और अनुभव का एक संयोजन है। शिल्पकार आवश्यक उपकरण का चयन करता है (और यदि आवश्यक हो, तो अपना खुद का बनाता है) और उनका उपयोग करना सीखता है।
मेरे लिए, यह एक शिल्प है। मेरा मानना है कि सर्वश्रेष्ठ प्रोग्रामर, बिल्डरों या भौतिकविदों के बजाय घड़ी बनाने वालों के करीब हैं। बेशक, इस पाठ में तर्क और गणित का उपयोग करने की शक्ति में विज्ञान या इंजीनियरिंग जैसा दिखता है, लेकिन ज्यादातर मामलों में आप सिर्फ उपकरण उठाते हैं और कुछ बनाते हैं।
यदि आप इस तथ्य को ध्यान में रखते हैं कि प्रोग्रामिंग एक शिल्प है, तो यह तुरंत स्पष्ट हो जाता है कि अनुभव, आपके उपकरण और अंतर्ज्ञान कितने महत्वपूर्ण हैं।
1. ईमानदारी सबसे अच्छी रणनीति हैजब आप कोड लिखते हैं, तो कभी-कभी यह एक बैसाखी लिखने और वास्तव में क्या हो रहा है, इसकी सही समझ के बिना कार्यक्रम को काम करने के लिए लुभाता है। एक क्लासिक उदाहरण है जब आप एपीआई कॉल डालने का निर्णय लेते हैं, क्योंकि यह जादुई रूप से बग को हटा देता है; या जब प्रिंटफ़ डालने के बाद प्रोग्राम क्रैश हो जाता है।
दोनों ही मामलों में, आत्म-धोखा स्पष्ट है। आपको खुद से पूछना होगा: "क्या मैं समझता हूं कि मेरा कार्यक्रम एक्स क्यों बनाता है?"। यदि नहीं, तो परेशानी का इंतजार करें। एक प्रोग्रामर के रूप में आपका कार्य यह समझना है कि क्या हो रहा है क्योंकि कंप्यूटर वही करता है जो उसे बताया जाता है, और न कि आप जो सोचते हैं वह करना चाहिए।
ईमानदारी के लिए परिश्रम की आवश्यकता होती है। जब आपका कार्यक्रम क्या करता है और क्यों आता है, तो आपको सावधानीपूर्वक और सावधानीपूर्वक रहना होगा।
2. सरलीकरण, सरलीकरण, सरलीकरणटोनी होर ने एक बार कहा था: “प्रोग्रामिंग के लिए दो दृष्टिकोण हैं। पहला कार्यक्रम को इतना सरल बनाना है कि जाहिर तौर पर इसमें कोई त्रुटि नहीं है। और दूसरा इसे इतना जटिल बनाना है कि इसमें कोई स्पष्ट त्रुटियां न हों। पहला कहीं अधिक जटिल है। ”
सरलीकृत करें, रीफैक्टरिंग करें, हटाएं।
मैं होर के कथन को फिर से लिखूंगा: "हर बड़े और जटिल कार्यक्रम के अंदर एक छोटा, सुरुचिपूर्ण कार्यक्रम होता है जो बिल्कुल वैसा ही करता है।"
यह "
शिथिल युग्मित ईंटों " के दर्शन के समान है। जहां कार्यक्रम को छोटे भागों में तोड़ना बेहतर होता है जो एक दूसरे के साथ बातचीत करके एक ठोस मोनोलिथ का निर्माण करते हैं। उदाहरण के लिए, यूनिक्स इस दृष्टिकोण के हिस्से में अपनी सफलता का श्रेय देता है।
3. डिबगर्स बैसाखी, प्रोफाइलर हैं - नहींमैं लगभग कभी भी डिबगर का उपयोग नहीं करता। मैं अपने कार्यक्रम लिखता हूं ताकि वे सभी आवश्यक जानकारी लॉग इन करें जो कि यह समझने के लिए उपयोग किया जा सकता है कि क्या हो रहा है। ज्यादातर मामलों में, मैं समझ सकता हूं कि डिबगर की मदद के बिना लॉग फ़ाइल पर कोड के साथ क्या गलत है।
डिबगर का उपयोग शायद ही कभी किया जाता है क्योंकि यह आपको कम सोचने की अनुमति देता है। अधिकांश लोग, जब वे बग ढूंढते हैं, डिबगर को खोलते हैं और ब्रेकपॉइंट, चर मान और मेमोरी की दरार में डुबकी लगाते हैं। इस तरह के एक शक्तिशाली उपकरण के जादू के तहत गिरना आसान हो सकता है, लेकिन अगर आप भविष्य में थोड़ा दिमाग लगाते हैं तो यह भुगतान करेगा। यदि आपका कार्यक्रम इतना जटिल है कि आपको डिबगर की आवश्यकता है, तो आपको फिर से बिंदु 2 का संदर्भ लेना चाहिए।
(हालांकि, मेरे सबसे सम्मानित प्रोग्रामर में से एक, जॉन ओस्टरहॉट, विंडोज डिबगर में सारा दिन बिताते हैं)।
प्रोफाइलर्स के लिए, वे बहुत उपयोगी होते हैं यदि आपको प्रदर्शन का मूल्यांकन करने की आवश्यकता होती है। आप यह सोचकर कभी नहीं रुकेंगे कि प्रोफाइलर आपको क्या दिलचस्प परिणाम देता है।
4. डुप्लीकेशन का भुगतान करना होगाअपने आप को दोहराएं नहीं! कोड में, सब कुछ केवल एक बार करें।
यह पैरा नंबर 2 से समझा जाता है, लेकिन यहां एक विशेष मामला है। यहां तक कि आपके द्वारा डुप्लिकेट किए गए कोड का एक छोटा टुकड़ा भी भविष्य में समस्याओं को जन्म देगा जब आप एक संस्करण को बदलते हैं और दूसरे को ठीक करना भूल जाते हैं।
5. भाषाओं में अवैध होकुछ लोग सिर्फ एक भाषा से प्रभावित होते हैं और सोचते हैं कि यह भाषा किसी भी चीज़ के लिए उपयुक्त है। ऐसा सोचना एक गलती है। सभी अवसरों के लिए कोई भाषा नहीं है।
मुख्य बात यह है कि किस समस्या के लिए उपयोग करने के लिए इसके उपकरणों में से कौन सी भाषाएं हैं। इसलिए, अधिक उपकरण रखना बेहतर है। विभिन्न भाषाओं का प्रयास करें, उन पर कुछ लिखें।
उदाहरण के लिए, आपको पायथन या एमएल का उपयोग करने के लिए अधिक उपयोग नहीं करना पड़ सकता है, लेकिन आप सूची की समझ के साथ काम करेंगे और उनकी शक्ति को महसूस करेंगे। या गो के साथ खेलें और देखें कि कैसे प्रतिस्पर्धी अनुप्रयोगों के साथ काम करना है। या क्या आप पर्ल के साथ काम करते हैं और वास्तव में लचीली स्ट्रिंग हैंडलिंग की शक्ति की सराहना करते हैं। अंत में, तेजी से गतिशील वेब पेज बनाने के लिए PHP सीखें।
मुझे भाषाओं के बीच युद्ध से नफरत है। ये युद्ध हारे हुए लोगों के लिए हैं, क्योंकि संक्षेप में, इसके बारे में बहस करने के लिए कुछ भी नहीं है। उदाहरण के लिए, मेरे हाथों में PHP एक आपदा है, जबकि दूसरे हाथों में यह एक कोकिला की तरह गाएगा। यही बात C ++ पर लागू होती है।
6. एक कार्यक्रम बनाने की तुलना में इसे अभी बनाना आसान हैयह आइटम आइटम नंबर 2 से निकटता से संबंधित है। छोटे और निर्माण शुरू करो। जब आप किसी समस्या को हल करते हैं, तो शुरू से अंत तक वास्तुकला को डिजाइन करने के बजाय छोटे ब्लॉकों (संभवतः कुछ हिस्सों के लिए स्टब्स बनाना) के साथ शुरू करना बहुत आसान है।
जब आप शुरू से अंत तक वास्तुकला का निर्माण करते हैं, तो आप 1) इसे गलत करते हैं 2) कुछ बड़े और जटिल के साथ समाप्त होता है, जहां परिवर्तन करना बहुत मुश्किल होगा। दूसरी ओर, यदि आप छोटे ब्लॉकों का उपयोग करते हैं जो एक-दूसरे के साथ बातचीत करते हैं, तो जब आप महसूस करते हैं कि आपने बहुत शुरुआत में गलती की थी, तो रिफैक्टिंग करना सरल होगा।
कारण यह है कि यह पता लगाने का कोई तरीका नहीं है कि सही वास्तुकला क्या दिखना चाहिए। केवल दुर्लभ मामलों में हम कह सकते हैं कि कार्यक्रम पर बाहरी प्रभाव क्या होंगे। आप कह सकते हैं कि आप आने वाले टीसीपी ट्रैफ़िक की प्रकृति को जानते हैं जो आपके मेल सर्वर प्रक्रियाओं, उपयोगकर्ताओं की संख्या, या जो आपने स्पैम के बारे में कभी नहीं सुना है। एक रास्ता या दूसरा, बाहर से कुछ ऐसा होगा जो आपकी सभी धारणाओं को पूरी तरह से नष्ट कर देता है, और यदि इन धारणाओं का संबंध एक बड़े, अत्यधिक जुड़े और जटिल प्रणाली से है, तो आपके पास बड़ी समस्याएं हैं।
7. जानें कि परतें कैसे काम करती हैंमेरा मानना है कि यह जरूरी है कि आप सीपीयू से उस भाषा पर जाएं, जिसे आप समझने के लिए उपयोग करते हैं कि क्या हो रहा है। परतों को समझना बहुत महत्वपूर्ण है (क्या यह समझ रहा है कि जावा के मामले में, सी कोड को किस रूप में संकलित किया गया है, जेवीएम को समझना और यह कैसे काम करता है)।
यह प्रदर्शन के मुद्दों या डिबगिंग समस्याओं से निपटने में बहुत मदद करता है। मेरी स्मृति में, एक मामला तब सामने आता है जब एक ग्राहक ने हमें एक दुर्घटनाग्रस्त विंडोज 2000 का स्क्रीनशॉट भेजा, जिसमें स्मृति और रजिस्टरों के एक छोटे टुकड़े की स्थिति दिखाई दी। क्लाइंट द्वारा इंस्टॉल किए गए प्रोग्राम के संस्करण को जानने के बाद, हम, केवल इस रिपोर्ट पर, एक पॉइंटर के साथ समस्या को पहचानने में सक्षम थे, और सबसे महत्वपूर्ण रूप से इसके कारण।
8. मैं इतना युवा नहीं हूं कि सब कुछ जान सकूंमुझे सीखने के लिए बहुत कुछ है। मैं शायद ही कुछ भाषाओं को जानता हूं, हालांकि उन्हें सीखने की इच्छा है (एर्लैंग, क्लोजर)। मैंने दूसरों का उपयोग किया है, लेकिन मैं उन्हें इतना अच्छी तरह से नहीं जानता (जावास्क्रिप्ट)। और ऐसी चीजें भी हैं जिन्हें मैं कठिनाई (संन्यासी) के साथ समझता हूं।
पीएस मुझ पर आरोप लगाया गया कि मैंने परीक्षण के बारे में कुछ नहीं कहा। यह जोड़ने योग्य है कि मेरी राय में किसी भी कोड के लिए परीक्षण की आवश्यकता होती है जिसे आपको कुछ समय के लिए निपटाना पड़ता है। शायद मुझे एक और 30 साल का कार्यक्रम करने की आवश्यकता है और मुझे इस सवाल का जवाब मिल जाएगा कि "क्या इकाई परीक्षण सॉफ्टवेयर की गुणवत्ता में सुधार करते हैं?"। मैंने यूनिट परीक्षणों के साथ या बिना कोड लिखा था, और मुझे अभी भी सही उत्तर नहीं पता है, हालांकि मैं यूनिट परीक्षणों का उपयोग करने के लिए अधिक इच्छुक हूं।