मुझे एक लोकप्रिय ढांचे का उपयोग करने की आवश्यकता क्यों है?

Question

मैं कई वर्षों से एक PHP डेवलपर रहा हूं, मेरे बेल्ट के नीचे कई टूल के साथ; उपकरण जिन्हें मैंने या तो स्वयं विकसित किया है, या उपयोग में आसान समाधान जिन्हें मैंने विश्वास करना सीखा है।

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

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

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

संपादित करें: यहां कुछ उत्तरों को देखते हुए, क्या मुझे शायद अपने टूलसेट को अपने स्वयं के रूपरेखा के रूप में पैकेजिंग करने, कुछ दस्तावेज लिखने और ट्यूटोरियल पोस्ट करने पर विचार करना चाहिए? अगर मैं दूसरों के ढांचे को लेने में संकोच कर रहा हूं, तो इसे खोलना और इससे अधिक आंखें प्राप्त करना मेरे अपने कौशल/उपकरण को बेहतर बनाने में मदद करता है?

Answer 1

फ़्रेमवर्क कई फायदे हैं:

• आप सब कुछ लिखने के लिए नहीं है। आपके मामले में, यह एक सहायता से कम है क्योंकि आपके पास अपना खुद का ढांचा है जिसे आपने पिछले कुछ वर्षों में जमा किया है।

• फ्रेमवर्क चीजों को करने के मानकीकृत और परीक्षण किए गए तरीके प्रदान करते हैं। जितने अधिक उपयोगकर्ता एक दिए गए ढांचे के हैं, उतने अधिक किनारे के मामलों का सामना किया गया है और इसके लिए कोड किया गया है। आपका स्वयं का कोड उसी तरह से कड़ी मेहनत कर सकता है, या नहीं।

• दूसरों को एक मानक ढांचे के साथ एक परियोजना पर भर्ती किया जा सकता है और उस ढांचे के साथ प्रलेखन, उदाहरण और अनुभव तक पहुंच प्राप्त हो सकती है। आपके स्वयं के स्निपेट पूरी तरह से प्रलेखित हो सकते हैं या नहीं हो सकते हैं या उपयोग के उदाहरण हो सकते हैं ... लेकिन अधिक संभावना नहीं है कि दूसरों को शुरुआत में उनके साथ सहजता हो।

संपादित करें:

के साथ अपने स्वयं के फ्रेमवर्क पैकेजिंग के अपने विचार के संबंध

, सार्वजनिक उपभोग के लिए यह सफाई के लाभ दूसरों के लिए इसका इस्तेमाल करने के लिए हो रही है के लाभ से भी बड़ा हो सकता है।

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

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

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

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

Answer 2

आप एक बिंदु हो सकता है .... लेकिन मैं कई की शक्ति को कम नहीं होगा, के रूप में मैं चिंतित bb समाधान का उपयोग करने हूँ एक उदाहरण के रूप phpBB के रूप में दूर है। क्यूं कर? क्योंकि उनके समर्थन बोर्डों पर कई हजारों पोस्ट हैं और इसका उपयोग करने वाले बहुत से लोग जानकार हैं और लोगों को समस्याओं का समाधान करने में मदद कर सकते हैं।

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

Answer 3

एक चीज जिसे आप खो देंगे, वह सभी मान्यताओं में से एक है जो लोकप्रिय ढांचे में जाती है।

आपके दिनचर्या में लोकप्रिय पुस्तकालयों का एक ही एक्सपोजर नहीं होता है।

Answer 4

मुझे लगता है कि मुख्य कारण यह है कि जब आप एक सामान्य ढांचे का उपयोग करते हैं, तो बहुत से लोग हैं जो आपके उत्पाद से तत्काल परिचित हैं।

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

Answer 5

फ्रेमवर्क कोड अच्छी तरह से परीक्षण और अपेक्षाकृत मुक्त बग होने की संभावना है। इसका उपयोग करके आप एक ही काम करने के लिए अपने स्वयं के कोड का समय परीक्षण/रखरखाव बचाते हैं।

और किसी भी समय बचाया गया अच्छा है। आलस्य प्रोग्रामिंग में भुगतान करता है।

Answer 6

मैं मानता हूं कि आपको अपने स्वयं के कस्टम ढांचे का उपयोग करना चाहिए। न केवल आपके लिए समझना आसान है, बल्कि यह नौकरी सुरक्षा में सबसे अच्छा प्रदान करता है!

Answer 7

तीन कारणों से मैं तुरंत के बारे में सोच सकते हैं:

• एक प्रसिद्ध ढांचे अन्य डेवलपर्स अपनी परियोजना पर काम करने के लिए हो सकता है, जो
• एक प्रसिद्ध ढांचे पुस्तकों की तरह संसाधन होगा परिचित होंगे , चर्चा बोर्ड, और अन्य विशेषज्ञ जिन्हें अधिक जानकारी प्राप्त करने के लिए उपयोग किया जा सकता है
• प्रबंधकों के पास अक्सर "पहिया को पुन: पेश नहीं करना" दर्शन होगा। असल में, मौजूदा समाधानों ने शायद वही समस्याएं हल की हैं जिन्हें आप खोज लेंगे यदि आप अपना स्वयं का समाधान बनाते हैं।

उन सभी ने कहा, अभी भी आपके स्वयं के समाधान के लिए एक जगह हो सकती है। अगर किसी ने कुछ नया शुरू नहीं किया है, तो हमारे पास चुनने के लिए इतने सारे ढांचे (या स्क्रिप्टिंग भाषाओं) नहीं होंगे।

Answer 8

जैसा कि आप शायद जानते हैं: "समय पैसा है"। तो बहुत से सहायकों के साथ एक लोकप्रिय ढांचे का उपयोग करके, वेब पर बहुत से कोड उदाहरण और एक बड़े समुदाय जो आप कम समय में करते हैं।

कभी-कभी ढांचे का उपयोग करना ठीक है क्योंकि आप अधिक उत्पादक बन जाते हैं, लेकिन कुछ उन्नत और कठिन परियोजनाओं में ऐसा हो सकता है ताकि ढांचा आपके रास्ते में रहे और आपको कामकाज मिलना पड़े।

मुझे लगता है कि कोई निश्चित उत्तर नहीं है। आपको पेशेवरों और विपक्ष को संतुलित करना चाहिए और अपनी परियोजना के लिए सही निर्णय लेना चाहिए।

आमतौर पर मैं लोकप्रिय ढांचे को बहुत तेज़ी से अपनाता हूं लेकिन परियोजनाओं के महत्वपूर्ण हिस्सों में नहीं बल्कि समय में मैं उनका उपयोग बढ़ाता हूं।

Answer 9

मुझे लगता है कि यदि आपको ढांचे का उपयोग करने की आवश्यकता नहीं दिखाई देती है तो नहीं।

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

यदि आपके पास कुछ ऐसा काम है जो ढांचे का उपयोग करने की आवश्यकता नहीं देखता है तो मैं आपको जो महसूस करता हूं उसके साथ छड़ी कहूंगा। लेकिन, मैं अभी भी ढांचे के साथ अद्यतित रहूंगा।

Answer 10

आपके पास अनिवार्य रूप से आपके स्वयं के ढांचे हैं। इसलिए, यह आपके लिए समय बचाने वाला नहीं है, क्योंकि आपने पहले ही ढांचे को विकसित करने के लिए समय बिताया है। यदि आपके पास इसे बनाने के लिए नहीं है, तो यह निश्चित रूप से आपके लिए रोल करने के बजाय मौजूदा ढांचे का उपयोग करना आसान और तेज़ होगा।

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

इसके अलावा, अगर अपने ढांचे इतना हर किसी से बेहतर है elses ', आप समुदाय के लिए तुम्हारा खोलने पर विचार हो सकता;)

Answer 11

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

वह अकेला निवेश हो सकता है, जिसमें बग शामिल नहीं है जो बीच में पॉप अप कर सकता है। जब यह सब कुछ कहा जाता है, तो यह खुद को बनाने के बजाय एक और ढांचा सीखने में समय व्यर्थ हो सकता है।

आपने कोडइग्निटर का उल्लेख किया - मुझे व्यक्तिगत रूप से ऐसा लगता है कि यह एक सुंदर ढांचा है - इससे उससे अधिक नंगे नहीं मिलते हैं।

Answer 12

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

उदाहरण के लिए, मुझे यकीन है कि प्रमुख गेम डेवलपमेंट दुकानें तीसरे पक्ष के उपकरण, इंजन और ढांचे का उपयोग नहीं कर रही हैं, क्योंकि वे पर्याप्त नहीं हैं, लेकिन वे पहले से ही 80 के दशक या जो कुछ भी बना चुके हैं।

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

दूसरी बात यह है कि यदि आप कुछ बना सकते हैं, तो आप वास्तव में इसे समझते हैं। अन्यथा, आप नहीं करते हैं। अब, उन्हें उपयोग करने के लिए सामान को पूरी तरह से समझने की आवश्यकता नहीं है, जब तक कि वे "बस काम करें", लेकिन हम सभी जानते हैं कि यह कैसे जाता है ... :)

Answer 13

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

हालांकि

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

गलत परिस्थितियों में यह वास्तव में विनाशकारी हो सकता है। उदाहरण के लिए यदि कोई ग्राहक एक ऐसी परियोजना के लिए पूछता है जो आपको लगता है कि एक फ्रेमवर्क समाधान में फिट होगा और आप तदनुसार उद्धरण देंगे, तो 90% पूरा करने के बाद आपको गॉचा मिल जाएगा, तो आप वास्तव में क्रीक बन सकते हैं, खासकर यदि यह कुछ विशेषता है जो ग्राहक है आग्रह करता हूं (और यह हमेशा होता है)। ये मुद्दे उठते हैं क्योंकि यह शब्द हमेशा से स्पष्ट नहीं होता है जहां गॉथचास झूठ बोल सकता है, खासकर यदि आप एक ढांचे का उपयोग कर रहे हैं जो आप कम परिचित हैं (और आपको समय-समय पर) होना चाहिए।

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

Answer 14

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

क्या आपने देखा है कि जावा के लिए कितने वेब ढांचे हैं? दिन में वापस, यह किसी भी आधा सभ्य डेवलपर/वास्तुकार के लिए अपने स्वयं के कस्टम वेब ढांचे को लिखने के लिए फैशनेबल था। और दिन के अंत में, उनमें से 9 5% स्ट्रूट्स (उस समय सबसे लोकप्रिय जावा वेब ढांचे) के कस्टम कार्यान्वयन की तरह दिखते थे। इसलिए उन्होंने मूल रूप से एक स्ट्रैट्स क्लोन बनाया जो था: 1) मालिकाना; और 2) दस्तावेज और परीक्षण के साथ ही नहीं।

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

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

Answer 15

मैं यहां अनाज के खिलाफ जाऊंगा, और कहूंगा, आपको अपने स्वयं के कस्टम ढांचे का उपयोग करना चाहिए, यदि आप जो सॉफ्टवेयर बना रहे हैं वह आपके व्यवसाय का मूल है। जैसा कि जोएल कहता है, "Find the dependencies - and eliminate them"। यदि आप अपनी कंपनी के लिए सिर्फ एक छोटी वेबसाइट डाल रहे हैं, और आप व्यवसाय वेबसाइटों को बनाए नहीं रख रहे हैं, तो आगे बढ़ें और ढांचे का उपयोग करें। लेकिन जब वह वेबसाइट आपका व्यवसाय है, तो आपको नौकरी पाने के लिए किसी और से ढांचे पर निर्भर नहीं होना चाहिए।

Answer 16

क्या आप सार्वजनिक कोड के मुकाबले अपने कोड के साथ तेज़ी से और अधिक भरोसेमंद समस्याओं को हल कर सकते हैं?

यदि हां, तो अपने आप का उपयोग जारी रखें।

यदि नहीं, तो उस ढांचे को ढूंढें जो बेहतर काम करता है और उस परियोजना के लिए इसके साथ चलता है।

यह सब नीचे आता है जो करने के लिए codebase काम को बेहतर ढंग से किया जाता है (बेहतर ग्राहक द्वारा दिए गए मूल्य के लिए;।))

Answer 17

लाभ यह है कि यह पहले से ही लिखा गया है और कई लोगों को इसलिए कम होने की संभावना द्वारा परीक्षण किया गया है कर रहे हैं बग प्रवण

नुकसान यह है कि यह विशेष रूप से आपके आवेदन के लिए नहीं बनाया गया है और इसलिए अधिकतर खराब प्रदर्शन करेंगे।

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

Answer 18

नुकसान।

अधिकांश फ्रेम कार्य ऑब्जेक्ट उन्मुख नहीं हैं। (कोड इग्निटर कुछ प्रोमिस दिखाता है)

अधिकांश कोड शामिल किए गए हैं। समस्या को ट्रैक करने की कोशिश करना एक स्वेटर पर धागे को खींचना और सृजन को पूरी तरह से समझने के लिए पूरे परिधान को सुलझाना है।

अधिकांश फ्रेम कार्यों में खराब लिखित दस्तावेज हैं।

अधिकांश फ्रेम कार्य कई सारी चीज़ें करने का प्रयास करते हैं।

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

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

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

मोस्ट प्रोग्रामर फ्रेम काम को "हैक" करने के लिए प्राप्त करने के लिए प्राप्त करते हैं। इससे भविष्य के प्रोग्रामर अपने सिर खींच रहे हैं। यह फ्रेम कार्य को असंभवता "अपग्रेड" भी बनाता है।

मुझे अभी तक एक फ्रेम कार्य देखना है जो यूनिट परीक्षण लागू करता है। (आप कैसे जानते हैं कि आपने इसे तोड़ा नहीं है)।

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