🧘🏽 😟 💚 सार देखने की क्षमता 👩🏼‍💼 👨‍🔬 ✖️

मेरा बेटा, कई लड़कों की तरह, कारों को पसंद करता है। इसके अलावा, वे जितने बड़े और असामान्य हैं, उतना ही अधिक उन्हें पसंद किया जाता है। जब हम सड़क पर चलते हैं, और एक टो ट्रक या एक स्नोप्लो पास से गुजरता है, तो वह हमेशा मेरा हाथ खींचता है, एक ऐसी वस्तु की ओर इशारा करता है जो उसे दिलचस्पी देती है और कहती है: "पिताजी, ब्रा-आर!"। वह ऐसा इसलिए कहता है क्योंकि वह एक वर्ष का है और उपरोक्त दो शब्द उसकी शब्दावली का 40% बनाते हैं। फिर भी, सामान्य तौर पर, विचार स्पष्ट है - कार पर ध्यान देना। आइए विचार करें कि 8-10 वर्ष की आयु का बच्चा अपने सहकर्मी से कैसे कहेगा। "वाह, देखो क्या शानदार कार है?", हुह। विचार समान है, लेकिन ध्यान दें - दो के बजाय छह शब्द। और अंत में, कल्पना कीजिए कि उनके दिवंगत तीस के दशक में एक आदमी कैसे कहेगा: “अरे, देखो, यह 2008 फेरारी कैलिफ़ोर्निया है जिसमें 454 हॉर्स पावर का V4 इंजन और 7-स्पीड ऑटोमैटिक ट्रांसमिशन है! यह 3.9 सेकंड में सैकड़ों तक पहुँच जाती है! ” हां, पहले से ही अधिक विवरण हैं, लेकिन अगर आप कार मैकेनिक या फेरारी के प्रशंसक नहीं हैं, तो आपको सबसे अधिक संभावना नहीं है और यह महत्वपूर्ण नहीं है। मुख्य विचार "वाह, एक शांत कार देखो!" या "पिताजी, br-r!" के समान है। लेकिन यह पहले से ही 30 शब्दों में व्यक्त किया गया है।

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

हम किस बारे में बात कर रहे हैं

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

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

पैटर्न

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

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

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

उपकरण

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

खराब कोड उदाहरण

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

क्या कारण हैं? मैं उन सभी को कॉल करने के लिए नहीं मानता, लेकिन यहां एक है। आइए इसके स्रोत से एक फ़ाइल देखें।
NppBigSwitch.cpp

हम इस कोड के कुछ हिस्सों पर करीब से नज़र डालेंगे।

'परिवर्तनशील नाम' की अवधारणा की गलतफहमी।

Macro m = _macro;

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

गलतफहमी संस्करण नियंत्रण प्रणाली

 /* case NPPM_ADDREBAR : { if (!lParam) return FALSE; _rebarTop.addBand((REBARBANDINFO*)lParam, false); return TRUE; } case NPPM_UPDATEREBAR : { if (!lParam || wParam < REBAR_BAR_EXTERNAL) return FALSE; _rebarTop.reNew((int)wParam, (REBARBANDINFO*)lParam); return TRUE; } case NPPM_REMOVEREBAR : { if (wParam < REBAR_BAR_EXTERNAL) return FALSE; _rebarTop.removeBand((int)wParam); return TRUE; } */

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

कार्यक्रम की गति अधिक महत्वपूर्ण है, और प्रोग्रामर की गति कहां है, इसकी गलतफहमी

 LRESULT Notepad_plus::process(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) { ... //  1800   ... }

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

अमूर्त 'ध्वज', 'स्थिर', 'जादू संख्या' की गलतफहमी।

 nmdlg->Items[i] = 0xFFFFFFFF; // indicate file was closed ... if ((lParam == 1) || (lParam == 2)) ... long view = MAIN_VIEW; view <<= 30; return view|i;

0xFFFFFFFF, 1, 2 और 30 क्या है? अरे हाँ, 0xFFFFFFFF - मतलब फ़ाइल बंद कर दी गई है। क्या अद्भुत टिप्पणी है, यह कितना स्पष्ट है! यह, जाहिरा तौर पर, बहुत तेज़ और सुविधाजनक था कि संख्याओं को कोड में छोड़ दिया जाए - आखिरकार, यह संकलन करता है। समझाने का समय नहीं है, चलो आगे, है ना?

एनकोडिंग पर अमूर्तता का अभाव

  case COPYDATA_FILENAMESA : { char *fileNamesA = (char *)pCopyData->lpData; CmdLineParams & cmdLineParams = pNppParam->getCmdLineParams(); #ifdef UNICODE WcharMbcsConvertor *wmc = WcharMbcsConvertor::getInstance(); const wchar_t *fileNamesW = wmc->char2wchar(fileNamesA, CP_ACP); loadCommandlineParams(fileNamesW, &cmdLineParams); #else loadCommandlineParams(fileNamesA, &cmdLineParams); #endif break; } case COPYDATA_FILENAMESW : { wchar_t *fileNamesW = (wchar_t *)pCopyData->lpData; CmdLineParams & cmdLineParams = pNppParam->getCmdLineParams(); #ifdef UNICODE loadCommandlineParams(fileNamesW, &cmdLineParams); #else WcharMbcsConvertor *wmc = WcharMbcsConvertor::getInstance(); const char *fileNamesA = wmc->wchar2char(fileNamesW, CP_ACP); loadCommandlineParams(fileNamesA, &cmdLineParams); #endif break; } } return TRUE; }

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

ऑपरेटिंग सिस्टम UI प्राइमेटिव पर अमूर्त परत का अभाव

 ::MoveWindow(_rebarTop.getHSelf(), 0, 0, rc.right, _rebarTop.getHeight(), TRUE); ... ::SendMessage(_statusBar.getHSelf(), WM_SIZE, wParam, lParam);

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

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

अच्छा कोड उदाहरण

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

आइए Qt लाइब्रेरी हेडर फ़ाइलों में से एक को देखें।

qpdfwriter.h

 #ifndef QPDFWRITER_H #define QPDFWRITER_H #include <QtCore/qobject.h> #include <QtGui/qpagedpaintdevice.h> QT_BEGIN_NAMESPACE class QIODevice; class QPdfWriterPrivate; class Q_GUI_EXPORT QPdfWriter : public QObject, public QPagedPaintDevice { Q_OBJECT public: explicit QPdfWriter(const QString &filename); explicit QPdfWriter(QIODevice *device); ~QPdfWriter(); QString title() const; void setTitle(const QString &title); QString creator() const; void setCreator(const QString &creator); bool newPage(); void setPageSize(PageSize size); void setPageSizeMM(const QSizeF &size); void setMargins(const Margins &m); protected: QPaintEngine *paintEngine() const; int metric(PaintDeviceMetric id) const; private: Q_DISABLE_COPY(QPdfWriter) Q_DECLARE_PRIVATE(QPdfWriter) }; QT_END_NAMESPACE #endif

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

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

निष्कर्ष

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

एक अच्छी प्रोग्रामिंग है।