ये अनगिनत प्रतिमान, अवधारणाएं, उपकरण और रूपरेखा

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

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

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

1. कोई ऐसी ट्रिक ईजाद करने की जरूरत नहीं है जहां इसे बस किया जा सके।

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

1.2। किसने कहा कि विरासत और पुनर्वित्त के लिए, वस्तुएं आवश्यक हैं? एक पदानुक्रमित फ़ाइल संरचना या पदानुक्रमित डेटाबेस प्रश्न काफी उपयुक्त हैं।

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

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

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

2. यदि आप कार्यक्षमता में विविधता चाहते हैं, तो टूलकिट को लंबे समय तक चुनें और ठीक करें।

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

3. साधनों का अनुचित और अनुचित उपयोग बुरे साधनों की तुलना में अधिक सामान्य है।

प्रत्येक भाषा और प्रौद्योगिकी में कार्यों की एक श्रृंखला होती है जिसके लिए यह आदर्श रूप से अनुकूल है, और अन्य कार्यों के लिए निश्चित रूप से समाधान के अपने पर्याप्त साधन हैं।

4. यह असंभव है और अमूर्तता की एक परत पर डेटा, तर्क और प्रतिनिधित्व को अलग करना आवश्यक नहीं है।

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

5. कोई सही कोड नहीं है, आपको कुछ हद तक बहुमुखी प्रतिभा के साथ संतुष्ट होना चाहिए।

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

6. कोई भी अतिवाद बुरा है।

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

7. प्रणाली का विकास इसकी सीमाओं की ओर जाता है।

विकास के लिए जानकारी सहित किसी भी प्रणाली को निर्णय लेने की आवश्यकता होती है, लेकिन प्रत्येक निर्णय न केवल कार्यक्षमता की उपस्थिति की ओर जाता है, बल्कि प्रतिबंधों के निर्माण के लिए भी होता है। इसलिए, जब धारणाएं और निर्णय लेते हैं (धारणाएं), हमेशा इस बारे में सोचें कि यह किस सीमा तक जाती है और क्या आप उनके लिए तैयार हैं।

वह सब है। मुझे उम्मीद है कि कोई इसे भविष्य के लिए करेगा।