जो मुझे पता है उसके मार्ग का अनुसरण करें, फिर सही कोडिंग प्रथाओं को लागू करने का प्रयास करें, या अच्छी कोडिंग प्रथाओं के साथ शुरू करें और इस तरह से अपने तरीके से ठगने की कोशिश करें?


9

सबसे पहले, मैं यह कहना चाहता हूं कि मैं अपने शौक के रूप में प्रोसेडुरल प्रोग्रामिंग करने का आदी हूं - मैं कुछ भाषाओं में OOP सीखने की कोशिश कर रहा हूं, और सिद्धांत को समझता हूं , सिर्फ अभ्यास नहीं।

मेरे पास एक पालतू-परियोजना है जिसे मैं निर्माण करना चाहता था, विशेष रूप से एक डेटाबेस बैकएंड के साथ पीएचपी में (किसी को परवाह नहीं है)। मेरा मुख्य कारण ऐप का किसी भी डिवाइस पर उपयोग किया जाना था, इसलिए एक WebApp तार्किक पसंद की तरह लग रहा था।

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

मैंने मुख्य रूप से प्रूफ-ऑफ-कॉन्सेप्ट के लिए, एक अन्य प्रोग्राम (माइक्रोसॉफ्ट एक्सेस) में ऐप बनाने के लिए, और वेब पार्ट को छोड़कर केवल कुछ ही घंटों में अपने मुख्य लक्ष्यों को पूरा करने का निर्णय लिया।

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


2
यह मुश्किल है कि आप कोई भी बात न करें। सभी चरणों में आपका कोड पठनीय होगा या कोई भी इसे नहीं छूएगा। प्रक्रियात्मक पर OOP का उपयोग करें क्योंकि यह सही या लोकप्रिय नहीं है। इसका उपयोग करें क्योंकि आवश्यकताओं में परिवर्तन होता है और वे कैसे बदलते हैं इसका पूर्वानुमान लगाना कठिन है। आप कर सकते हैं सबसे कम मान्यताओं का उपयोग करें।
कैंडिड_ओरेंज

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

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

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

1
OOP मूल रूप से सरल या अमूर्त इंटरफेस के पीछे के राज्य परिवर्तनों को बदलने के बारे में है ... जो कि प्रक्रिया को अनुरोध करने वाले स्टेटलेस सर्वर लिखने के लिए वास्तव में अच्छा नहीं है । आप जिस तरह का काम करना चाहते हैं, उसके लिए ओओ भाषाओं का उपयोग करना ओओ प्रोग्रामिंग की तुलना में कार्यात्मक प्रोग्रामिंग की तरह बहुत अधिक है, यही कारण है कि आप उन ट्यूटोरियल को लागू करने के लिए कठिन पाते हैं।
मैट टिम्मरमैन

जवाबों:


12

सर्वोत्तम प्रथाएं ज्यादातर सुझाव और प्रस्ताव हैं जो अनुभव से एकत्रित परियोजनाओं को आसान बनाने में मदद करने के लिए * सक्षम हैं।

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

किसी भी मामले में, सबसे महत्वपूर्ण बात यह है कि मेरे लिए एक सॉफ्टवेयर परियोजना में सबसे महत्वपूर्ण बात यह है ... अच्छी तरह से ... इसे समाप्त करें, इसे जहाज करें ... संक्षेप में इसे काम करें!

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

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

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

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

सौभाग्य


4
"एक सॉफ्टवेयर परियोजना में सबसे महत्वपूर्ण सबसे महत्वपूर्ण बात यह है ... अच्छी तरह से ... इसे खत्म करो, इसे जहाज करो ... संक्षेप में इसे काम करो!" - मैं इसे पर्याप्त नहीं कर सकता। बहुत से लोग इस बिंदु को याद करते हैं कि यह उनका ध्यान पूरे समय होना चाहिए।
ivan_pozdeev

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

3
"* सक्षम" का क्या अर्थ है?
रॉबर्ट हार्वे

1
@RobertHarvey Testable, Maintainable, Portable, Reusable आदि मूल रूप से जो भी विशिष्ट गुणवत्ता (ies) एक के लिए लक्ष्य होगा। बस यह कि वे ऐसे शब्द हैं जो "फिक्स" के बाद के फिक्स के साथ समाप्त होते हैं। मुझे लगता है कि मैं सिर्फ आलसी हो गया जब एक पहलू के लिए अनुकूलन बहुत बार इसका मतलब होता है अन्य पहलुओं पर समझौता करना इसलिए मैं बहुत विशिष्ट होने से बचता हूं ताकि मुख्य बिंदु से स्पर्शरेखा को आकर्षित करने के लिए आकर्षित न हो।
न्यूटॉपियन

8

टी एल; डॉ

तुम यह सब कभी नहीं जान पाओगे। वहाँ बहुत अधिक हमेशा गहराई है और हर व्यक्ति "बात" आप जान सकते हैं। सीखो जैसे तुम जाओ। "सर्वोत्तम प्रथाओं" को लागू करें जो आपको लगता है कि अब प्रासंगिक हैं। गलतियाँ करना। बस बहुत महंगी गलतियाँ करने से बचने की कोशिश करें । यदि आपकी परियोजना महंगी गलतियों को जन्म दे सकती है तो संरक्षक खोजें।


और अब लंबा जवाब ...

1. "वर्किंग सॉफ्टवेयर प्रगति का प्राथमिक माप है।" ( चंचल मैनिफेस्टो )

यदि आप अपने ज्ञान के किनारों को देख सकते हैं, तो यह भयानक है! किनारों का पीछा! सीखते रहो! लेकिन ध्यान में रखते हुए, आप हमेशा के लिए सीख और विश्लेषण कर सकते हैं

कुछ बनाएँ।


2. सीखें और गलतियाँ करें; लेकिन "बुरा" मत बनाओ।

अपने ज्ञान / कौशल की सीमाओं को आगे बढ़ाते रहें। आप गलतियाँ करेंगे । आप उनसे सीख सकते हैं। लेकिन, आपको लापरवाह होने की जरूरत नहीं है ।

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

यदि आप अपने लिए थोड़ा सीएलआई बना रहे हैं : तो यह काम कर लें लेकिन आप चाहते हैं।

यदि आप बैंक का वेब पोर्टल लिख रहे हैं: अपने आप को बहुत अनुभवी डेवलपर्स के साथ घेरें।


3. "सर्वोत्तम प्रथाओं" को उद्धरणों में लिखा जाना चाहिए और पलक के साथ बोला जाना चाहिए।

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

मुसीबत यह है, एक "सर्वोत्तम अभ्यास" कभी भी स्वयं सेवी नहीं होता है। "एंटीपैटर्न" वास्तव में और स्वयं के शैतानी नहीं हैं। और, यहां तक ​​कि एक "बदबू" केवल कभी-कभी सड़ांध से आती है। कभी कभी, कि बदबू सिर्फ एक फैंसी, स्वादिष्ट पनीर है ...

आप "निर्भरता इंजेक्शन" (DI) जैसी चीजों का अभ्यास नहीं करते क्योंकि "निर्भरता इंजेक्शन" व्यवसाय के लिए स्वाभाविक रूप से मूल्यवान है। किसी कार्यशील उत्पाद के निर्माण के लिए यह जरूरी नहीं है। यह कुछ ऐसा है जो आप शायद अपने अंतिम उत्पाद में चाहते हैं । लेकिन, यह भी हो सकता है कि आपके काम को बिना किसी लाभ के अधिक समय तक ले जाए ...

हम्म ...

तो, क्या आपको "सर्वोत्तम प्रथाओं का पालन करना चाहिए?" भले ही आप उन्हें न समझें? ... इर्र ... हां। मेरा मतलब है नहीं। लेकिन हां। लेकिन, केवल वही जो आपके और आपके सॉफ़्टवेयर और उसके उद्देश्य पर लागू होते हैं।

POAP का आह्वान करें ! (हाँ। मेरा ब्लॉग।)

सिद्धांत, पैटर्न और अभ्यास अंतिम उद्देश्य नहीं हैं।

इसलिए प्रत्येक का अच्छा और उचित अनुप्रयोग एक बेहतर, अधिक अंतिम उद्देश्य से प्रेरित और विवश है। आपको यह समझने की आवश्यकता है कि आप जो कर रहे हैं वह क्यों कर रहे हैं!

(पीओएपी पीओएपी से छूट नहीं है।)

इसलिए, आप पूरी तरह से DI की प्रत्येक बारीकियों को नहीं समझ सकते हैं, उदाहरण के लिए। लेकिन, यदि आप इरादे को समझते हैं, तो आपको पता चल जाएगा कि क्या आपको "DI" का उपयोग करना चाहिए, और आप संक्षेप में DI को बेहतर ढंग से समझ पाएंगे।

और, एक बार जब आप उत्पाद जारी करते हैं, तो आप इस पर प्रतिबिंबित कर सकते हैं कि क्या डीआई (या जो भी) वास्तव में फायदेमंद था। यदि हां, तो लिखित में क्यों स्पष्ट करें। यदि नहीं, तो स्पष्ट रूप से लिखित में क्यों ...


बोनस पढ़ना / थोड़ा प्रासंगिक:

विश्लेषण पक्षाघात एक चीज है। आपको विश्लेषण करने और सीखने की जरूरत है; लेकिन, आपको सामान भी करवाना होगा। शेष राशि।

आप हमेशा एक चरवाहे कोडर की तरह महसूस कर सकते हैं


* यदि आप कुछ भी उल्लेखनीय करते हैं तो आप वास्तव में गलतियाँ करेंगे । लेकिन, आप इंसान हैं, मैं मानता हूं। इसलिए, हम आपको समय से पहले माफ कर देते हैं ... या, कम से कम मैं करता हूं। शायद। ... अच्छा ... हम देखेंगे।


7

मेरा प्रश्न यह है कि क्या मुझे जो पता है उसके मार्ग का अनुसरण करना चाहिए, फिर सही कोडिंग प्रथाओं को लागू करने का प्रयास करना चाहिए, या क्या मुझे अच्छी कोडिंग प्रथाओं के साथ शुरू करना चाहिए, और मेरे रास्ते को रोकने का प्रयास करना चाहिए?

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


6

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

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

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

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

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

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


एक प्रोग्रामर के रूप में जो केवल मेरे खाली समय में "मौज-मस्ती" के लिए कोड करता है, डेबियन सर्वर के बंद होने पर आप और अधिक मजबूत पर क्या विचार करेंगे?
कनाडाई ल्यूक

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

भाषा का चुनाव यहाँ अप्रासंगिक लगता है। वह अंतिम पैराग्राफ आपके अन्यथा अच्छे उत्तर के लिए बहुत कुछ नहीं जोड़ता है।
सांय

1
@ चक्र: यह उन्हीं कारणों के लिए प्रासंगिक है जो मैंने एक्सेस के अपने विवरण में उल्लिखित किए हैं। भाग को फिर से पढ़ें जो कहता है "सर्वश्रेष्ठ प्रथाओं को मोटे तौर पर डेवलपर को छोड़ दिया जाता है।"
रॉबर्ट हार्वे

स्नाइड टिप्पणी की कोई आवश्यकता नहीं है। PHP पर आपकी टिप्पणी पक्षपातपूर्ण और एक अन्यथा अच्छे बिंदु (आपके दूसरे से अंतिम पैराग्राफ) से विचलित और विचलित होती है। लेकिन हे ... यह तुम्हारा जवाब है।
साइफर

1

OOP को केवल एक और पैटर्न के रूप में समझें जिसे आप सही समय पर लागू कर सकते हैं। OOP एक ऐसा ढांचा नहीं है जो हर कार्य को व्यवस्थित रूप से हल कर सके। सॉफ्टवेयर इंजीनियरिंग में ऐसा कुछ मौजूद नहीं है।

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

वेब पर लेख, उद्योग के विशेषज्ञों के बयान और वरिष्ठ सहयोगियों से सलाह अच्छी तरह से गलत हो सकती है। मैंने इसे बहुत देखा है।

इसलिए मेरा सुझाव है कि आप अपनी समस्या को हल करने वाले सबसे सरल समाधान को लागू करें। इस प्रकार, यह आपके अंतरिक्ष में लोकप्रिय फ्रेमवर्क में से एक के उपयोग को शामिल करेगा। इस बाधा के भीतर आप स्वतंत्र रूप से चुन सकते हैं कि आपको किस तरह का कोड पसंद है। बस यह मत सोचो कि ऐसा करने का उनका तरीका आपके मामले के लिए उपयुक्त है ।

यह भी समझें कि कुछ तकनीकों की सिफारिश क्यों की जाती है। उदाहरण के लिए, OOP इनकैप्सुलेशन के बारे में है। आप अन्य तरीकों से इनकैप्सुलेट कर सकते हैं (प्रक्रियाएं एनकैप्सुलेशन के बारे में भी हैं)।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.