Transcript
00:00:00क्या आप जानते हैं कि कुछ लोग सालों तक इस क्षेत्र में काम करने के बावजूद
00:00:04एक डेवलपर के रूप में आगे क्यों नहीं बढ़ पाते? इसके कई कारण हैं।
00:00:09और उनमें से एक कारण प्रोग्रामिंग के बुनियादी सिद्धांतों को न समझना है।
00:00:14ये सिर्फ कोई थ्योरी नहीं है जिसे आप एक बार सीखकर भूल जाएं। ये वो असल चीजें हैं जो वास्तव में आपको एक डेवलपर के रूप में तेजी से आगे बढ़ाएंगी।
00:00:19चलिए पहले सिद्धांत से शुरू करते हैं, बॉय स्काउट रूल। यह सिद्धांत अमेरिका के बॉय स्काउट्स से आया है।
00:00:25तो असल में, उनका एक सरल नियम है, कैंपग्राउंड को वैसा ही छोड़ो जैसा तुमने उसे पाया था, बल्कि उससे भी साफ।
00:00:31मुझे नहीं पता कि आप में से कितने लोग अंकल बॉब को जानते हैं, लेकिन वही हैं जिन्होंने इस अवधारणा को
00:00:36प्रोग्रामिंग समुदाय में लोकप्रिय बनाया, जो कि कोड को उससे थोड़ा साफ छोड़ने का अभ्यास है जितना आपने इसे पाया था।
00:00:41मौजूदा कोड बेस में बदलाव करते समय, कोड की गुणवत्ता अक्सर कम हो जाती है, जो
00:00:47तकनीकी कर्ज (technical debt) को बढ़ा सकती है। और तकनीकी कर्ज को निरंतर सुधार द्वारा कम किया जा सकता है,
00:00:52चाहे वह कितना ही छोटा क्यों न हो। उदाहरण के लिए, मान लीजिए कि आपको इस फंक्शन में
00:00:57मान बदलने का काम सौंपा गया है। आपने यह कर दिया, लेकिन आप देख सकते हैं कि वेरिएबल का नाम समझने लायक
00:01:03नहीं है। तो ज्यादातर डेवलपर्स की तरह, आप इसे अनदेखा कर सकते हैं और अपना काम सबमिट कर सकते हैं।
00:01:08लेकिन यदि आप इस सिद्धांत का पालन करते हैं, तो आप वेरिएबल का नाम बदलकर कुछ अधिक
00:01:12समझने योग्य रख देंगे। यह सिर्फ एक सरल उदाहरण है, सिर्फ वेरिएबल नाम ही नहीं, बल्कि अगर आपको कुछ भी ऐसा दिखे जिसे
00:01:18सुधारा जा सकता है, तो बस उसे सुधार दें। और यह छोटा सा कदम कोड बेस के लिए बहुत मूल्यवान होगा।
00:01:24दूसरा सिद्धांत, समय से पहले ऑप्टिमाइजेशन से बचें। इसका मतलब यह है कि
00:01:30कोड को तब तक तेज करने की कोशिश न करें जब तक कि वास्तव में इसकी आवश्यकता न हो। पहले, इसे काम करने योग्य बनाएं। फिर, यदि आवश्यक हो तो ऑप्टिमाइज़ करें।
00:01:36डोनाल्ड नुथ का एक प्रसिद्ध उद्धरण है, 'समय से पहले ऑप्टिमाइजेशन सभी बुराइयों की जड़ है',
00:01:42जो कि सच है क्योंकि प्रोग्रामर्स अक्सर अपना अधिकांश समय अपने प्रोग्राम के
00:01:47गैर-महत्वपूर्ण हिस्सों की गति के बारे में चिंता करने में बर्बाद कर देते हैं। ऐसा इसलिए है क्योंकि हर चीज को
00:01:51ऑप्टिमाइज़ करने का यह चलन सा बन गया है। यह सिद्धांत आपके कोड बेस को ऑप्टिमाइज़ करने के खिलाफ नहीं है। यह
00:01:57समझने के बारे में है कि किसे ऑप्टिमाइज़ करने की आवश्यकता है और सबसे महत्वपूर्ण बात, कब ऑप्टिमाइज़ करना है। और मुझे लगता है कि यह
00:02:03ज्यादातर डेवलपर्स की कमजोरी है क्योंकि मैंने लोगों को माइक्रोसर्विसेज का उपयोग करते देखा है जबकि उनके पास
00:02:08100 उपयोगकर्ता भी नहीं हैं या ऐसी किसी चीज के लिए कैशिंग जोड़ रहे हैं जिसकी जरूरत ही नहीं है। तीसरा सिद्धांत,
00:02:14मेंटेनर के लिए कोड लिखें, जिसका सीधा सा मतलब है कि जब आप कोड लिखें, तो आपको इसे इस तरह
00:02:19लिखना चाहिए कि भविष्य के डेवलपर्स जो आपके कोड को मेंटेन करेंगे, उन्हें इसे प्रबंधित करने और
00:02:23समझने में कठिनाई न हो। ऐसा इसलिए है क्योंकि आज जो कोड आप लिखते हैं, उसे अन्य डेवलपर्स या
00:02:29स्वयं आपके द्वारा मेंटेन किया जाएगा। यदि आप केवल इसे काम करने पर ध्यान केंद्रित करते हैं और स्पष्टता पर ध्यान नहीं देते हैं, तो भविष्य में यदि आपको
00:02:35कोड पर वापस आना पड़ा, तो आपको यह समझने में कठिनाई होगी कि क्या चल रहा है। बस इस
00:02:39उदाहरण को देखें। दोनों काम करते हैं और बिल्कुल समान कार्यक्षमता करते हैं। लेकिन आप किसे
00:02:45अपने कोड बेस में देखना पसंद करेंगे? तो निष्कर्ष यह है कि जब भी आप AI से कोड लिखें या जनरेट करें,
00:02:50हमेशा सुनिश्चित करें कि अपने काम को कमिट करने से पहले यह समझने में आसान और मेंटेन करने योग्य हो।
00:02:55तो हमारा चौथा सिद्धांत YAGNI है, जो 'You Aren't Gonna Need It' का छोटा रूप है।
00:03:01तो इस सिद्धांत का सीधा सा मतलब है कि आपको ऐसी कोई चीज नहीं बनानी चाहिए जिसकी आपको वास्तव में आवश्यकता नहीं है या सिर्फ इसलिए कि
00:03:06शायद भविष्य में इसकी आवश्यकता हो। क्योंकि अधिकांश डेवलपर्स को यह भविष्यवाणी करने की आदत होती है कि
00:03:10उन्हें भविष्य में क्या चाहिए हो सकता है। लेकिन ज्यादातर समय, उनका उपयोग कभी नहीं होता है और वे केवल प्रोजेक्ट में
00:03:16अतिरिक्त जटिलता जोड़ते हैं। इसे हमेशा याद रखें। यदि आप ऐसी चीज पर काम कर रहे हैं जिसकी भविष्य में आवश्यकता हो सकती है,
00:03:21तो आप अपना समय उस चीज को नहीं दे रहे हैं जिसकी आपको वर्तमान में आवश्यकता है। पांचवां सिद्धांत, सबसे सरल
00:03:27चीज करें जो संभवतः काम कर सके। तो इसका मतलब यह है कि जब भी आप किसी समस्या का सामना करें, हमेशा
00:03:32सबसे सरल समाधान चुनें जो वास्तव में काम करेगा। ज्यादा न सोचें। इसे ओवर-इंजीनियर न करें। बस खुद से पूछें,
00:03:38सबसे सरल चीज क्या है जो इसे अभी हल कर सकती है? यह विचार एक्सट्रीम
00:03:43प्रोग्रामिंग से आता है, जो हमें पहले कुछ सरल बनाने के लिए कहता है, फिर उसे बेहतर में
00:03:48रीफैक्टर करें। अधिकांश डेवलपर्स इसे नहीं समझते हैं, लेकिन वे अक्सर शुरुआत से ही
00:03:53परफेक्ट समाधान बनाने की कोशिश करते हैं, जो अंततः उनके समाधान को अत्यधिक जटिल बना देता है। इस सिद्धांत के साथ, आपको जल्दी
00:03:59काम करने वाला कोड मिलता है और भले ही आपको बाद में बदलना पड़े, यह आमतौर पर एक गलत जटिल डिज़ाइन को
00:04:04ठीक करने से आसान होता है। और मुझ पर भरोसा करें, एक डेवलपर के रूप में, यह महसूस करना कि आप किसी चीज को ओवर-इंजीनियर कर रहे हैं,
00:04:10बहुत महत्वपूर्ण है। तो ये पांच प्रोग्रामिंग सिद्धांत थे जिन्हें आपको
00:04:14तुरंत लागू करना शुरू कर देना चाहिए। इनके अलावा, अन्य सिद्धांत भी हैं जिन्हें मैंने
00:04:19इस वीडियो में कवर नहीं किया है। अगर यह मददगार था, तो मुझे कमेंट्स में बताएं और मैं इसका दूसरा भाग बनाऊंगा।
00:04:24अभी के लिए, बस इतना ही। अपना प्यार दिखाना न भूलें और मैं आप लोगों से अगले वीडियो में मिलूंगा।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video