क्या कोई नया ढांचा बनाने के लिए सामान्य नियम या सर्वोत्तम प्रथाएं हैं?

Question

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

मुझे इस परियोजना के प्रबंधन और प्रबंधन को संभालने के बारे में कुछ संदेह हैं: क्या इस तरह के प्रोजेक्ट को विकसित करने के लिए कुछ सामान्य नियमों का पालन करना, युक्तियां, सर्वोत्तम प्रथाओं या कुछ को ध्यान में रखना है?

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

Comments

क्या हम मान सकते हैं कि ईसीएम का मतलब उद्यम सामग्री प्रबंधन [प्रणाली] है?

— मार्क कैनलास

हां, मैं अल्फ्रेस्को के साथ काम कर रहा हूं

— एंड्रिया गिर्डी

Answer 1

पहले यहाँ फ्रेमवर्क सिन्ड्रोम सिंड्रोम से बचने के लिए मेरे 2 नियम हैं:

• एक मौजूदा की अनुपस्थिति, मेरी जरूरतों के 80% को कवर करती है और अंतिम 20% से मेल खाने योग्य है
• निकट निश्चितता है कि मैं इसे फिर से उपयोग करूंगा, दूसरे अनुप्रयोग में

आपके पास जाने के बाद, इसे देखें:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

Comments

मुझे लगता है कि यदि आप एक फ्रेमवर्क नहीं पा सकते हैं जो आपके 80/20 नियम को पूरा करता है या तो आप एक बहुत ही अनोखे डोमेन में काम कर रहे हैं या आप अपने डोमेन को अच्छी तरह से नहीं समझते हैं।

— ElGringoGrande

Answer 2

1) फीचर्स को केवल एक फ्रेमवर्क में जोड़ा जाना चाहिए, जब उन्हें वर्किंग कोड से निकाला जाए। दूसरे शब्दों में, अपने शांत नए ढांचे में अपने नए विचार को जोड़ने से पहले, सुनिश्चित करें कि यह वास्तव में एक वास्तविक, वास्तविक दुनिया एप्लिकेशन में दोहराव को कम करता है।

2) प्रलेखन, प्रलेखन, प्रलेखन।

3) प्रलेखन, प्रलेखन, प्रलेखन।

Answer 3

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

Answer 4

मैं पुस्तक फ्रेमवर्क डिज़ाइन दिशानिर्देशों का सुझाव दूंगा । यह कुछ साल पुराना है, लेकिन सिद्धांत सही हैं। इसमें एक टन पैटर्न है और फ्रेमवर्क बनाते समय आपके द्वारा किए जाने वाले निर्णयों के पीछे के तर्क को समझाता है।

Answer 5

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

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

3) खुद के लिए एक प्रोजेक्ट संक्षिप्त करें, जिसे आप प्राप्त करना चाहते हैं, यथार्थवादी लक्ष्य और समग्र प्राथमिकताएं।

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

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

Answer 6

मैं कही गई बातों से बहुत असहमत हूं और मुझे लगता है कि इसे और अधिक छोड़ दिया गया है इसलिए मैं खरोंच से शुरू करूंगा।

चंचल तरीके

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

व्यक्तियों और बातचीत से अधिक प्रक्रियाओं और टूल
कार्य सॉफ्टवेयर से अधिक व्यापक प्रलेखन
ग्राहक सहयोग से अधिक अनुबंध बातचीत
जवाब बदलने के लिए खत्म हो गया एक योजना निम्नलिखित

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

संचार

जो कोई भी ढांचा बना रहा है उसे जानना चाहिए:

1. यह कैसे उपयोग किया जाएगा: लक्ष्य आवेदन
2. इसे हल करने के लिए क्या समस्या है: लक्ष्य समस्या
3. इसका उपयोग कौन करेगा: लक्षित दर्शक

उदाहरण के लिए, यदि कोई कंपनी ASP .NET के साथ एक अंतिम एप्लिकेशन विकसित करने का इरादा कर रही थी, तो अपने प्रोग्रामर को यह "ऊपर से बताए बिना" इस रूपरेखा को बनाना "बताना मूर्खता होगी।" यदि प्रोग्रामर लक्ष्य एप्लिकेशन को नहीं जानते हैं तो वे इसे वेब-उन्मुख नहीं बना सकते हैं। यदि उन्हें समस्या का पता नहीं था, तो वे एक अलग उद्देश्य के लिए एक रूपरेखा बना सकते हैं। अगर वे दर्शकों को नहीं जानते थे कि वे C ++ में फ्रेमवर्क को प्रोग्राम कर सकते हैं। इन परिस्थितियों में से कोई भी परिणामी रूपरेखा को बेकार कर देगा।

अंदाज

कहने की जरूरत नहीं है, एक प्रोग्रामिंग शैली / प्रारूप स्थापित करें और इसके साथ रहें।

ई का है

1. मॉड्यूलरिटी : प्रोग्राम कोड का पुन: उपयोग करें, शाब्दिक रूप से नहीं।
2. दक्षता : आपका कोड पुन: उपयोग के लिए अभिप्रेत है। गति के लिए कोई भी अवरोधक गुणा हो जाता है।
3. रखरखाव : आप कई कार्यक्रमों को अद्यतन करने के लिए रूपरेखा को संपादित करने में सक्षम होना चाहते हैं, बिना कहा कार्यक्रमों को संशोधित करने के लिए।
4. प्रयोज्यता : क्या आवेदन वास्तव में हुप्स के माध्यम से कूदने के बिना आपके ढांचे का उपयोग कर सकते हैं?
5. व्यावहारिकता : यदि आपको ऐसा करने की आवश्यकता नहीं है, तो पहिया को फिर से मजबूत न करें। आपका ढांचा अन्य ढांचे पर निर्भर कर सकता है।
6. अतिरेक : अपवादों / त्रुटियों को पकड़ो। हर जगह। उन्हें सम्हालो। हर जगह। किसी भी कोड पर भरोसा न करें, लेकिन त्रुटियों को संभालने के लिए स्थानीय दायरे में, भले ही आपको पता हो कि यह करता है।

Comments

P.SE में आपका स्वागत है! मैं आपकी रूपरेखा में अपवादों को पकड़ने पर w / # 6 सहमत नहीं हूँ। मैं इस बात पर बड़ा विश्वास करता हूं कि फ्रेमवर्क एक पूर्ण ब्रैट होना चाहिए और अपवादों को फेंकना चाहिए और उन्हें पकड़ने के लिए प्रोग्रामर को छोड़ देना चाहिए ताकि वे फ्रेमवर्क का उपयोग करके उन्हें पकड़ सकें या (बेहतर अभी तक) अपने कोड को पुन: प्राप्त कर सकें ताकि अपवाद से बचने के लिए - कन्वेंशन कंफर्मेशन को बढ़ावा मिले।

— जारोड नेटल्स

Answer 7

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

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

मुझे इस परियोजना के प्रबंधन और प्रबंधन को संभालने के बारे में कुछ संदेह हैं: क्या इस तरह के प्रोजेक्ट को विकसित करने के लिए कुछ सामान्य नियमों का पालन करना, युक्तियां, सर्वोत्तम प्रथाओं या कुछ को ध्यान में रखना है?

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

मैं दूसरी रयान हेस की फ्रेमवर्क डिज़ाइन दिशानिर्देशों को पढ़ने के लिए सिफारिश करूंगा, भले ही पुस्तक स्वयं .NET .NET के ढांचे को विकसित करने के उद्देश्य से हो, क्योंकि सामान्य सलाह विशिष्ट कार्यान्वयन तकनीकों की परवाह किए बिना लागू होती है, जिन्हें आप उपयोग करना चुन सकते हैं।

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