अँटीपॅटर्न

विरोधी नमुन्यांची ओळख

अँटी-पॅटर्न हे नमुन्यांच्या अगदी विरुद्ध आहेत. लक्षात ठेवा की डिझाइन पॅटर्न ही चांगल्या प्रोग्रामिंग पद्धतींची उदाहरणे आहेत, म्हणजेच काही समस्या सोडवण्यासाठी नमुने. परंतु अँटी-नमुने त्यांच्या पूर्ण विरुद्ध आहेत, म्हणजे, विविध समस्या सोडवताना केलेल्या चुकांचे नमुने.

चांगल्या प्रोग्रामिंग सरावाचा एक भाग म्हणजे अँटी-पॅटर्न टाळणे. असा विचार करू नका की हा इतका अनाकलनीय सैद्धांतिक कचरा आहे - या विशिष्ट समस्या आहेत ज्या जवळजवळ प्रत्येक विकसकाला आल्या आहेत. कोणाला जाणीव आहे, तो सशस्त्र आहे!

नवशिक्यांमध्ये सामान्य असलेले काही अँटी-नमुने पाहूया:

• जादूची संख्या आणि तार
• देव वर्ग
• अकाली ऑप्टिमायझेशन
• सायकलचा शोध
• युनिसायकलचा शोध

जादूची संख्या आणि तार

मॅजिक नंबर हा एखाद्या गोष्टीसाठी (बहुतेकदा डेटा आयडेंटिफिकेशन) कोडमध्ये वापरला जाणारा एक स्थिरांक असतो, ज्याची संख्या संबंधित टिप्पणीशिवाय अर्थ देत नाही. संख्यांमध्ये पूर्णपणे शब्दार्थ नाही.

जेव्हा तुमच्या प्रोजेक्टच्या कोडमध्ये संख्या दिसू लागतात, तेव्हा त्याचा अर्थ स्पष्ट होत नाही, हे खूप वाईट आहे. अशा कोडचा लेखक नसलेल्या प्रोग्रामरला ते कसे कार्य करते हे स्पष्ट करण्यात अडचण येईल. कालांतराने, जादूच्या संख्येसह कोडचा लेखक देखील त्याचे स्पष्टीकरण देऊ शकणार नाही.

संख्या कोड समजण्यास कठीण आणि रिफॅक्टर बनवतात. या त्रुटीची मुख्य कारणे म्हणजे विकासाची घाई आणि प्रोग्रामिंग सरावाचा अभाव. विकास सुरू करण्यापूर्वी अंकीय स्थिरांक वापरण्याची अट घालून हा अँटी-पॅटर्न अंकुरात टाकला पाहिजे.

या समस्येचे निराकरण करण्यासाठी, तुम्हाला एक व्हेरिएबल तयार करणे आवश्यक आहे ज्याचे नाव अंकीय स्थिरांकाचा हेतू स्पष्ट करेल आणि त्यास इच्छित मूल्य नियुक्त करा.

देव वर्ग

दैवी ऑब्जेक्ट एक विरोधी नमुना आहे जो OOP विकसकांमध्ये सामान्य आहे. अशी ऑब्जेक्ट बरीच फंक्शन्स घेते आणि / किंवा जवळजवळ सर्व डेटा संग्रहित करते. परिणामी, आमच्याकडे एक नॉन-पोर्टेबल कोड आहे, जो, शिवाय, समजणे कठीण आहे.

याव्यतिरिक्त, अशा कोडची देखभाल करणे खूप कठीण आहे, कारण संपूर्ण सिस्टम केवळ त्यावर अवलंबून असते. या त्रुटीची कारणे: विकासकाची अक्षमता, एका विकासकाने कामाचा मोठा भाग घेणे (विशेषतः जेव्हा कामाचे प्रमाण विकासकाच्या अनुभव पातळीपेक्षा जास्त असते).

विविध विकासक हाताळू शकतील अशा उपकार्यांमध्ये कार्ये मोडून या दृष्टिकोनाचा सामना करणे आवश्यक आहे.

अकाली ऑप्टिमायझेशन

अकाली ऑप्टिमायझेशन हे ऑप्टिमायझेशन आहे जे प्रोग्रामरकडे कोठे आणि कसे करावे याबद्दल माहितीपूर्ण निर्णय घेण्यासाठी आवश्यक असलेली सर्व माहिती असण्यापूर्वी केले जाते.

व्यवहारात कुठे अडचण येईल हे सांगणे कठीण आहे. प्रायोगिक परिणाम प्राप्त करण्यापूर्वी ऑप्टिमाइझ करण्याच्या प्रयत्नांमुळे कोडची जटिलता आणि त्रुटी दिसून येतील, परंतु कोणतेही फायदे होणार नाहीत.

कसे टाळावे? प्रथम, सुप्रसिद्ध आणि सिद्ध अल्गोरिदम आणि साधने वापरून स्वच्छ, वाचनीय, कार्यरत कोड लिहा. आवश्यक असल्यास, अडथळे शोधण्यासाठी प्रोफाइलिंग साधने वापरा. मोजमापांवर विसंबून राहा, अंदाज आणि गृहितकांवर नाही.

उदाहरणे आणि वैशिष्ट्ये

प्रोफाइल करण्यापूर्वी कॅशिंग. गणितीयदृष्ट्या योग्य अल्गोरिदमऐवजी जटिल आणि अप्रमाणित ह्युरिस्टिक्स वापरणे. नवीन, न तपासलेल्या फ्रेमवर्कची निवड जी लोड अंतर्गत गैरवर्तन करू शकते.

काय अडचण आहे

ऑप्टिमायझेशन अकाली आहे हे निर्धारित करणे सोपे नाही. आगाऊ वाढीसाठी जागा सोडणे महत्वाचे आहे. तुम्हाला सोल्यूशन्स आणि प्लॅटफॉर्म निवडण्याची आवश्यकता आहे जे तुम्हाला सहजपणे ऑप्टिमाइझ आणि वाढू देतात. तसेच कधीकधी अकाली ऑप्टिमायझेशन खराब कोडसाठी निमित्त म्हणून वापरले जाते. उदाहरणार्थ, ते O(n2) अल्गोरिदम घेतात कारण अल्गोरिदम O(n) अधिक कठीण असेल.

सायकलचा शोध

या अँटी-पॅटर्नचा अर्थ असा आहे की प्रोग्रामर एखाद्या समस्येचे स्वतःचे निराकरण विकसित करतो ज्यासाठी उपाय आधीच अस्तित्वात आहेत आणि बरेचदा यशस्वी आहेत.

विकसक स्वतःला हुशार समजतो, म्हणून तो त्याच्या पूर्ववर्तींचा अनुभव असूनही, प्रत्येक कार्यासाठी स्वतःचे निराकरण करण्याचा प्रयत्न करतो. बर्याचदा, यामुळे केवळ वेळेचे नुकसान होते आणि प्रोग्रामरची कार्यक्षमता कमी होते. सर्व केल्यानंतर, समाधान अजिबात आढळल्यास, suboptimal असण्याची शक्यता आहे.

अर्थात, आपण स्वतंत्र समाधानाची शक्यता पूर्णपणे नाकारू शकत नाही, कारण यामुळे कॉपी-पेस्ट प्रोग्रामिंग थेट मार्गाने होईल. विकसकाने त्याच्यासमोर दिसणारी कार्ये सक्षमपणे सोडवण्यासाठी, तयार उपाय वापरून किंवा स्वतःचा शोध लावण्यासाठी नेव्हिगेट करणे आवश्यक आहे.

बर्‍याचदा, या अँटी-पॅटर्नचे कारण म्हणजे वेळेची साधी कमतरता. आणि वेळ म्हणजे पैसा.

स्क्वेअर व्हील सायकलचा शोध

हा अँटी-पॅटर्न चाक पुन्हा शोधण्याशी अगदी जवळून संबंधित आहे - जेव्हा एखादा चांगला उपाय अस्तित्वात असेल तेव्हा आपले स्वतःचे वाईट समाधान तयार करा.

या अँटी-पॅटर्नला दुप्पट वेळ लागतो: प्रथम, तुमचा स्वतःचा उपाय शोधण्यात आणि अंमलात आणण्यासाठी आणि नंतर रीफॅक्टरिंग किंवा पुनर्स्थित करण्यात वेळ घालवला जातो.

प्रोग्रामरला कार्यांच्या विशिष्ट श्रेणींसाठी विविध उपायांच्या अस्तित्वाची जाणीव असणे आवश्यक आहे , त्यांचे फायदे आणि तोटे यांचे मार्गदर्शन केले पाहिजे.

प्रोग्रामर म्हणून तुम्हाला ज्या समस्यांना सामोरे जावे लागेल ते दोन भागांमध्ये विभागले जाऊ शकते:

• हुशार लोकांनी 30 वर्षांपूर्वी ही समस्या सोडवली
• हुशार लोकांनी 50 वर्षांपूर्वी ही समस्या सोडवली

तुमचा जन्म होण्याआधीच बहुतांश प्रोग्रामिंग समस्या यशस्वीरित्या सोडवल्या गेल्या आहेत . काहीही शोधण्याची गरज नाही - फक्त इतर लोकांच्या अनुभवाचा अभ्यास करा (यासाठी पुस्तके लिहिली आहेत).

2022 मध्ये, आम्ही खालील वाढदिवस साजरे करू शकतो:

• प्रोग्रामिंग भाषा
  • सी भाषा ५० वर्षांची झाली (१९७२)
  • जावा भाषा २७ वर्षांची झाली (१९९५)
  • पायथन 31 वर्षांचा (1991)
• जोडणी
  • इंटरनेट ३९ वर्षांचे (१९८३)
  • मोबाईल फोन 49 वर्षांचा झाला (1973)
  • पहिला एसएमएस 30 वर्षांपूर्वी (1992) पाठवण्यात आला होता.
• नमुने
  • MVC पॅटर्न 44 वर्षांचा झाला (1978)
  • 48 वर्षांपूर्वी (1974) SQL चा शोध लागला होता.
  • जावा बीन्सचा शोध २६ वर्षांपूर्वी (१९९६) लागला होता.
• लायब्ररी
  • हायबरनेटचा शोध २१ वर्षांपूर्वी (२००१) लागला होता.
  • 20 वर्षांपूर्वी (2002) वसंत ऋतुचा शोध लागला होता.
  • टॉमकॅट 23 वर्षांपूर्वी (1999) रिलीज झाला
• OS
  • युनिक्स 51 वर्षांपूर्वी (1971) प्रसिद्ध झाले.
  • विंडोजने 37 वर्षांपूर्वी (1985) दिवसाचा प्रकाश पाहिला होता.
  • Mac OS 21 वर्षांपूर्वी (2001) रिलीझ झाले

आणि या सर्व गोष्टी नुसत्या शोधल्या नव्हत्या, त्या त्या वेळी अतिशय सामान्य आणि संबंधित असलेल्या समस्यांवर उपाय म्हणून विकसित केल्या गेल्या.