आप एक बड़ी प्रणाली को डिजाइन करना शुरू कैसे करते हैं?

Question

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

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

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

Answer 1

क्या आप ओओपी के बारे में बहुत कुछ जानते हैं? यदि ऐसा है, तो अपने कार्यान्वयन को साफ रखने के लिए वसंत और हाइबरनेट देखें और orthogonal। यदि आपको यह मिलता है, तो आपको अपने डिजाइन कॉम्पैक्ट और दुबला रखने के लिए टीडीडी का एक अच्छा तरीका मिलना चाहिए, खासकर जब से आपके पास "स्वचालित परीक्षण" चल रहा है और चल रहा है।

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

Answer 2

कोडिंग शुरू करने से पहले, अपने डेटाबेस स्कीमा की योजना बनाएं - बाकी सब कुछ उस से बह जाएगा। डेटाबेस को उचित रूप से सही तरीके से प्राप्त करना आपको बाद में समय और सिरदर्द बचाएगा।

Answer 3

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

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

हम सभी अपने आप में बाकी कार्यशीलताओं को विभाजित करने से पहले हम सभी पर पहले मिलकर काम करते हैं।

Answer 4

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

• पहले एक कहानी की तरह कल्पना पढ़ा (के माध्यम से यह स्कीम)। वहां और फिर इसका विश्लेषण करने के लिए हर आवश्यकता पर मत रोको। यह आपको बिना किसी विवरण के सिस्टम की समग्र तस्वीर प्राप्त करने की अनुमति देगा। इस बिंदु पर आप सिस्टम के प्रमुख कार्यात्मक घटकों की पहचान करना शुरू कर देंगे। इन्हें नीचे डालना शुरू करें (यदि आपको पसंद है तो एक दिमाग उपकरण का उपयोग करें)।

• फिर प्रत्येक घटक लें और इसे विस्फोट करना शुरू करें (और प्रत्येक विवरण को स्पेक दस्तावेज़ में आवश्यकताओं के साथ जोड़ना)। जब तक आप सभी आवश्यकताओं को कवर नहीं करते हैं, तब तक सभी घटकों के लिए ऐसा करें।

• अब, आपको घटकों के बीच संबंधों को देखना शुरू करना चाहिए, और क्या विभिन्न घटकों में सुविधाओं या कार्यों की पुनरावृत्तियां होनी चाहिए (जिन्हें आप उपयोगिता घटकों को बनाने के लिए बाहर खींच सकते हैं) या फिर।अब, आपके दिमाग में आपकी आवश्यकताओं का एक विस्तृत विस्तृत नक्शा होगा।

• अब, आप, आदि डेटाबेस, ईआर आरेख, कक्षा डिजाइन, DFDS, तैनाती को डिजाइन करने के बारे में सोच चाहिए

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

Answer 5

मैं डेटाबेस से शुरू करने के बारे में भी असहमत हूं। डीबी बस एक आर्टिफैक्ट है कि आपके व्यवसाय की वस्तुओं को कैसे जारी रखा जाता है। मुझे जावा में समकक्ष के बारे में पता नहीं है, लेकिन नेट में तारकीय उपकरण हैं जैसे SubSonic जो आपके डीबी डिज़ाइन को आपके व्यापार ऑब्जेक्ट डिज़ाइन के माध्यम से तरल पदार्थ के रूप में रहने की अनुमति देते हैं। मैं सबसे पहले और सबसे महत्वपूर्ण कहूंगा (प्रक्रियाओं पर ध्यान केंद्रित करने से पहले भी) प्रक्रिया पर ध्यान केंद्रित करें और अपने संज्ञाओं और क्रियाओं की पहचान करें ... फिर उन अवशेषों से बाहर निकलें। अरे, यह वास्तव में "वास्तविक दुनिया" में काम करता है, जैसे ओओपी 101 ने आपको सिखाया!

Answer 6

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

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

तो मेरी सलाह:

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

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

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

Answer 7

बड़े सिस्टम को छोटे टुकड़ों में विभाजित करें। और ऐसा नहीं लगता कि यह बहुत जटिल है, क्योंकि यह आमतौर पर नहीं होता है। बहुत जटिल सोचकर यह सिर्फ आपके विचारों और अंततः डिजाइन को बर्बाद कर देता है।कुछ बिंदु आपको बस एहसास है कि आप एक ही चीज़ को आसान बना सकते हैं, और फिर आप इसे फिर से डिजाइन कर सकते हैं।

कम से कम यह डिजाइन करने में मेरी बड़ी गलती रही है।

इसे आसान रखें!

Answer 8

यह मेरा अनुभव रहा है कि जावा एप्लिकेशन (.NET भी) जो पिछले समय डेटाबेस पर विचार करते हैं, कॉर्पोरेट वातावरण में रखे जाने पर खराब प्रदर्शन करने की अत्यधिक संभावना होती है। आपको अपने दर्शकों के बारे में वास्तव में सोचने की ज़रूरत है। आपने यह नहीं कहा कि यह एक वेब ऐप था या नहीं। किसी भी तरह से जिस आधार पर आप कार्यान्वित कर रहे हैं, वह महत्वपूर्ण है कि आप अपने डेटा को कैसे संभालें।

कोई फर्क नहीं पड़ता कि आप किस पद्धति पर विचार करते हैं, आप अपना डेटा कैसे प्राप्त करते हैं और कैसे सहेजते हैं और प्रदर्शन पर इसका प्रभाव आपकी # 1 प्राथमिकताओं में से एक के रूप में सही होना चाहिए।

Answer 9

मैं किताब Growing Object-Oriented Software, Guided by Tests में

• आम अच्छी प्रथाओं
• टेस्ट प्रेरित विकास
• और व्यावहारिक दृष्टिकोण

आधार पर एक नई बड़ी परियोजना शुरू करने के बारे में बहुत व्यावहारिक विचारों पाया,।

यह अभी भी विकास में है, लेकिन पहले 3 अध्याय जो आप खोज रहे हैं और आईएमएचओ पढ़ने के लायक हो सकते हैं।

Answer 10

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

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

वास्तविक कोर कार्यक्षमता के साथ शुरू करें। उस समय उपभोग करने वाले फ्लफ (जो आपकी परियोजना को 4 सप्ताह देर से बना देगा), उपयोगकर्ताओं के बेकार बहुमत के लिए ज्यादा मायने रखता नहीं है। एक बार जब आप सुनिश्चित हो जाएं कि आप समय पर पहुंच सकते हैं तो इसे बाद में जोड़ा जा सकता है।

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