शुरुआती लोगों के लिए प्रोग्रामिंग में डार्क साइड, जिसमें php भी शामिल है

छह साल की प्रोग्रामिंग के बाद, आप अपनी गलतियों को देखते हैं। बेशक, गलतियाँ विशुद्ध रूप से उनकी अपनी हैं, लेकिन उन्हें ज्ञान से बाहर किया गया था। और दुर्भाग्य से अज्ञान को ज्ञान के साथ लिया जाता है।

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

हंगेरियन नोटेशन का सार इस तथ्य से उबलता है कि पहचानकर्ता नाम पूर्व-निर्दिष्ट उपसर्गों से पहले एक या एक से अधिक वर्णों से युक्त होते हैं।

प्रोग्रामिंग पर पुस्तकों में, मैंने पढ़ा है कि आपको हंगरी संकेतन का उपयोग करने और डेटा प्रकार द्वारा उपसर्ग बनाने की आवश्यकता है : int iData; ।
लेकिन एक माइनस है: प्रकार बदलते समय, आपको चर का नाम बदलने की आवश्यकता होती है।

यह ऐसी सहमति है जो अंततः भविष्य के प्रोग्रामर को आकार देने में उन मूलभूत गलतियों को कर सकती है।

अंधेरा पक्ष

आखिरी हैब्रतोपिक जेडी पथ: एक्ट 2 ने प्रोग्रामिंग और प्रोग्रामर के अंधेरे पक्ष पर अपने विचारों को प्रकाशित करने के लिए प्रेरणा दी।
उस विषय के लेखक कहते हैं:

अंधेरा पक्ष। ऐसा नहीं है कि आपको अपने आप को गूंगा या स्मार्ट नहीं मानना ​​चाहिए, तथ्य यह है कि आपको अपने बारे में उच्च राय नहीं रखनी चाहिए।

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

अच्छा चलो चलते हैं।

विलंब

जब कोई परिणाम नहीं होता है

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

परिणाम प्राप्त करने की इच्छा में, मैंने विजुअल बेसिक में भी महारत हासिल करने की कोशिश की। एक पुस्तक के कुछ अंश:

दृश्य विकास के वातावरण और पहले के प्रोग्रामिंग टूल के बीच का अंतर यह है कि प्रोग्रामर के बजाय, वे प्रोग्राम के सबसे अक्सर सामना किए गए और उबाऊ भागों को "लिखते हैं", इस प्रकार इसे दिलचस्प और रचनात्मक कार्य के लिए मुक्त करते हैं। कभी-कभी, यदि कार्य सरल होता है, तो ऐसा होता है कि कंप्यूटर पूरे प्रोग्राम को पूरी तरह से बनाता है। एक अन्य विशेषता - विज़ुअल बेसिक और अन्य समान वातावरण में काम करने वाला एक प्रोग्रामर तथाकथित ऑब्जेक्ट प्रोग्रामिंग से बच नहीं सकता है, जिसने हाल के वर्षों में प्रोग्रामिंग दुनिया पर विजय प्राप्त की है।

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

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

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

आईएमएचओ: प्रोग्रामिंग में (शुरुआत में) शुरू में एक बात चुनना और कम से कम थोड़ा सा हासिल करना महत्वपूर्ण है, अन्यथा आप एक भाषा से भाषा में, एक आईडीई से एक आईडीई तक, या एक फ्रेमवर्क से फ्रेमवर्क तक एक लंबी छलांग लगा सकते हैं।

दुनिया को फिर से लिखना

विफलताओं और राहत के बाद, मैं वेब के लिए प्रोग्रामिंग में रुचि रखने लगा। मैंने php4 पर एक पुस्तक पढ़ी और, बहुत कम से कम, "साइट्स" लिखना शुरू कर दिया। बेशक, मैंने मूल रूप से स्क्रिप्ट्स को शासित और जोड़ दिया और इसे "साइटों" में एकीकृत कर दिया।

थोड़ी देर बाद मैंने कोड पढ़ना शुरू किया, मेरी गलतियों को देखते हुए और "OOP" के रूप में अपने बन्स के साथ php5 में महारत हासिल की। पहली बात मैंने नए पफ-पफ के लिए लिखी थी: एक डेटाबेस के साथ काम करने के लिए एक वर्ग, फिर एक और "कक्षाएं"।
परिणामस्वरूप, मुझे यह सोचने में बहुत समय लग गया कि इस साइट को "सोचने" के लिए, सबसे सरल साइट कैसे काम करेगी। लगभग हर बार मैंने कक्षाओं को फिर से लिखा / पूरक / सुधार किया।

सिद्धांत रूप में, मुझे पता था कि कुछ पुस्तकालय कक्षाओं (php5) और पुरानी php4 के रूप में मौजूद हैं। लेकिन तब मुझे सिर्फ अपनी जरूरत की हर चीज लिखने के विचार से मोह हो गया था।

जब सबसे छोटी परियोजना के लिए आप एक बार फिर से अपनी कक्षाओं को "फिर से" फिर से लिखना शुरू करते हैं, तो यह कैसे हो सकता है कि कोई शिथिलता न हो?

तनाव प्रबंधन

उन कारणों में से एक जो मुझे खुद को सब कुछ लिखने की प्यास के कारण भार के साथ संघर्ष था।
संकलित भाषाओं के प्रबल समर्थकों ने कीचड़ php डाला और इसकी हीनता और "सुस्ती" की ओर इशारा किया।

और अपने संकलक, सीएमएस, चौखटे, पुस्तकालयों, कक्षाओं को लिखने के प्रबल समर्थक - हर जगह और हमेशा प्रत्येक सार्वजनिक परियोजना में एक टन गंदगी और ब्रेक के उदाहरण डाले।

सच कहूं, तो 6 साल तक मुझे एक बार अपने आवेदन के साथ सर्वर ओवरलोड का सामना करना पड़ा। और सिर्फ इसलिए कि मैंने mysql के लिए यह किया है:
SELECT ...,... FROM ... WHERE in ( SELECT ...,... FROM ... WHERE in ( SELECT ...,... FROM ... WHERE in ) )
लोड को हटाने के लिए अलग से एक चयन का प्रदर्शन करना।

लेकिन मैंने पुराने साथियों की बात सुनी और उनकी सलाह का पालन किया: "भाषा सीखें, और फिर रूपरेखा का उपयोग करें", "अपनी रूपरेखा लिखें, क्योंकि एक अजनबी आपके विकास को सीमित करेगा" और इसी तरह ...

मोक्ष

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

समय के साथ, मैंने एक विशेष भाषा पर ध्यान केंद्रित करना शुरू किया और अगर कुछ काम नहीं किया, तो मैंने विधिपूर्वक पूछा। उदाहरण के लिए, जब मुझे क्यूटी में रुचि हो गई, मैंने सी ++ और ओओपी के बारे में पढ़ना शुरू कर दिया, और फिर पुस्तकालय के बारे में।

फिर भी, मैंने अपने लिए विभिन्न पुस्तकालयों और रूपरेखाओं की "शक्ति" की खोज की। उन्होंने बड़ी परियोजनाओं का उपयोग करना शुरू किया और उनके कोड को पढ़ा, जो उन्हें अध्ययन करने की अनुमति देता है।

मैंने परिस्थितियों में कोड लिखना और उपयोग करना शुरू कर दिया। यदि यह एक सरल साइट थी, तो आप इसे mysql के बिना php में लिख सकते थे, या CMS / sqlite फ़ाइलों का उपयोग कर सकते थे। एक व्यावसायिक वेबसाइट के लिए, mysql का उपयोग करना बेमानी हो सकता है।

"SQL के बिना" काम करने के प्रतिमान में धकेलने की कोशिश करने वाली एक बड़ी साइट, इसके विपरीत, परिणामों को नकारात्मक रूप से प्रभावित कर सकती है। पहले दो वर्षों में आलस्य और अल्पदृष्टि से मैंने परियोजनाओं को फिर से लिखा (पहले बिना SQL के, फिर SQL के साथ)।

आइए ईमानदार रहें: एक ज्ञात सॉफ्टवेयर को हैक करना संभव नहीं है, विशेष रूप से ट्रैफ़िक वाली साइट <1000 uniq / day।

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

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

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

डिज़ाइन पैटर्न (पैटर्न) के बारे में पढ़ना साइकिल का "आविष्कार नहीं" करने में बहुत मदद करता है।