كيف تبدأ بتصميم نظام كبير؟[مغلق]

Question

لقد قيل لي أنني سأكون المطور الوحيد وراء نظام جديد كبير.من بين أمور أخرى، سأقوم بتصميم واجهة المستخدم ومخطط قاعدة البيانات.

أنا متأكد من أنني سأتلقى بعض التوجيهات، لكني أود أن أكون قادرًا على التخلص من جواربهم.ما الذي يمكنني فعله في هذه الأثناء للاستعداد، وما الذي يجب أن أضعه في الاعتبار عندما أجلس على جهاز الكمبيوتر الخاص بي وأدرس المواصفات؟

بعض الأمور التي يجب أن نضع في اعتبارنا:أنا طالب جامعي في أول وظيفة برمجة حقيقية لي.سأستخدم جافا.لقد قمنا بالفعل بإعداد SCM مع الاختبار الآلي، وما إلى ذلك... لذلك لا تمثل الأدوات مشكلة.

Answer 1

هل تعرف الكثير عن OOP؟إذا كان الأمر كذلك، فابحث في Spring وHbernate للحفاظ على تنفيذك نظيفًا متعامد.إذا فهمت ذلك، فيجب أن تجد TDD طريقة جيدة للحفاظ على تصميمك مضغوطًا وخفيفًا، خاصة وأن لديك "اختبارًا آليًا" قيد التشغيل.

تحديث:بالنظر إلى العدد الكبير من الإجابات، لم أستطع أن أختلف أكثر.في مجال Java على وجه الخصوص، يجب أن تجد الكثير من المرشدين/الموارد حول كيفية إنشاء تطبيقك باستخدام الكائنات، ليس نهجا يركز على قاعدة البيانات.عادةً ما يكون تصميم قاعدة البيانات هو الخطوة الأولى لموظفي Microsoft (وهو ما أقوم به يوميًا، ولكني أستخدم برنامج استرداد، Alt.Net).إذا واصلت التركيز على ما تحتاج إلى توصيله إلى العميل وسمحت لـ ORM الخاص بك بمعرفة كيفية الحفاظ على العناصر الخاصة بك، فيجب أن يكون تصميمك أفضل.

Answer 2

هذا يبدو كثيرًا مثل وظيفتي الأولى.مباشرة بعد تخرجي من الجامعة، طُلب مني تصميم قاعدة البيانات وطبقة منطق الأعمال، بينما يتولى أشخاص آخرون الاهتمام بواجهة المستخدم.في هذه الأثناء كان المدير ينظر من فوق كتفي، غير راغب في التخلي عن ما كان طفله والذي أصبح الآن طفلي، ويدس إصبعه فيه.وبعد ثلاث سنوات، كان المطورون يهربون من الشركة، وكان لا يزال أمامنا X أشهر قبل أن نبيع أي شيء فعليًا.

الخطأ الكبير كان في كونك طموحًا للغاية.إذا كانت هذه هي وظيفتك الأولى، فأنت سوف ارتكاب الأخطاء وأنت سوف تحتاج إلى تغيير كيفية عمل الأشياء لفترة طويلة بعد كتابتها.كان لدينا جميع أنواع الميزات التي جعلت النظام أكثر تعقيدًا مما ينبغي، سواء على مستوى قاعدة البيانات أو في واجهة برمجة التطبيقات (API) التي قدمها للمطورين الآخرين.في النهاية، كان الأمر برمته معقدًا للغاية بحيث لا يمكن دعمه مرة واحدة وتوفي للتو.

لذلك نصيحتي:

1. إذا لم تكن متأكدًا من إمكانية تولي مثل هذه المهمة الكبيرة بمفردك، فلا تفعل ذلك.أخبر أصحاب العمل، واطلب منهم العثور على شخص ما أو توظيفه لتعمل معه ويمكنه مساعدتك.إذا كانت هناك حاجة إلى إضافة أشخاص إلى المشروع، فيجب أن يتم ذلك بالقرب من البداية وليس بعد أن تسوء الأمور.

2. فكر جيدًا في الغرض من المنتج، ثم قم بتغليفه حتى النهاية أبسط مجموعة من المتطلبات التي يمكنك التفكير فيها.إذا كان الأشخاص الذين يقدمون لك المواصفات ليسوا تقنيين، فحاول أن ترى ما كتبوه وما الذي سيعمل بالفعل ويكسب المال.التحدث مع العملاء ومندوبي المبيعات، وفهم السوق.

3. ليس هناك عيب في الاعتراف بأنك مخطئ.إذا اتضح أن النظام بأكمله يحتاج إلى إعادة كتابة، لأنك ارتكبت بعض الأخطاء في نسختك الأولى، فمن الأفضل الاعتراف بذلك في أقرب وقت ممكن حتى تتمكن من الوصول إليه.في المقابل، لا تحاول إنشاء بنية يمكنها توقع كل الاحتمالات المحتملة في نسختك الأولى، لأنك لا تعرف ما هي كل حالات الطوارئ وسوف تخطئ في فهمها.اكتب مرة واحدة مع الحرص على التخلص منها والبدء من جديد - قد لا تضطر إلى ذلك، قد تكون النسخة الأولى جيدة، لكن اعترف بذلك إذا فعلت ذلك.

Answer 3

أنا أيضًا لا أتفق مع البدء بقاعدة البيانات.قاعدة البيانات هي ببساطة قطعة أثرية لكيفية استمرار كائنات عملك.لا أعرف ما يعادله في Java، لكن .Net لديه أدوات ممتازة مثل دون سرعة الصوت التي تسمح لتصميم قاعدة البيانات الخاصة بك بالبقاء سلسًا أثناء التكرار من خلال تصميم كائنات العمل الخاصة بك.أود أن أقول أولاً وقبل كل شيء (حتى قبل اتخاذ قرار بشأن التقنيات التي سيتم تقديمها) ركز على العملية وحدد الأسماء والأفعال الخاصة بك ...ثم قم بالبناء من تلك التجريدات.مهلا، إنه يعمل بالفعل في "العالم الحقيقي"، تمامًا كما علمتك OOP 101!

Answer 4

قبل البدء في البرمجة، قم بتخطيط مخطط قاعدة البيانات الخاصة بك - كل شيء آخر سوف يتدفق من ذلك.إن الحصول على قاعدة بيانات صحيحة بشكل معقول في وقت مبكر سيوفر عليك الوقت والصداع لاحقًا.

Answer 5

الشيء الرئيسي هو القدرة على تجريد تعقيد النظام بحيث لا تتورط فيه بمجرد أن تبدأ.

• قم أولاً بقراءة المواصفات كقصة (تصفحها).لا تتوقف عند كل المتطلبات لتحليلها هناك وبعد ذلك.سيسمح لك ذلك بالحصول على صورة شاملة للنظام دون الكثير من التفاصيل.عند هذه النقطة ستبدأ في تحديد المكونات الوظيفية الرئيسية للنظام.ابدأ في وضع هذه الأشياء جانبًا (استخدم أداة الخريطة الذهنية إذا أردت).

• ثم خذ كل مكون وابدأ في تفجيره (وربط كل التفاصيل بالمتطلبات الواردة في مستند المواصفات).افعل ذلك لجميع المكونات، حتى تغطي جميع المتطلبات.

• الآن، يجب أن تبدأ في النظر إلى العلاقات بين المكونات، وما إذا كان هناك تكرار للميزات أو الوظائف عبر المكونات المختلفة (والتي يمكنك بعد ذلك سحبها لإنشاء مكونات مساعدة، أو ما شابه ذلك).في الوقت الحالي، سيكون لديك خريطة تفصيلية جيدة لمتطلباتك في ذهنك.

• الآن، يجب أن تفكر في تصميم قاعدة البيانات، ومخططات ER، وتصميم الفئة، وDFDs، والنشر، وما إلى ذلك.

المشكلة في القيام بالخطوة الأخيرة أولاً هي أنه يمكنك التورط في تعقيد نظامك دون الحصول على فهم شامل في المقام الأول.

Answer 6

أفعل ذلك في الاتجاه المعاكس.أجد أن القيام بذلك بمخطط قاعدة البيانات أولاً يجعل النظام عالقًا في تصميم قائم على البيانات يصعب استخلاصه من الثبات.نحاول القيام بتصميمات نماذج المجال أولاً وثم قاعدة مخطط قاعدة البيانات على تلك.

ثم هناك تصميم البنية التحتية:يجب أن يستقر الفريق على الاتفاقيات المتعلقة بكيفية تنظيم البرنامج أولاً وقبل كل شيء.ومن ثم نعمل معًا للاتفاق أولاً على تصميم للوظيفة المشتركة للنظام (على سبيل المثال، الأشياء التي يحتاجها الجميع مثل المثابرة والتسجيل وما إلى ذلك).يصبح هذا إطار النظام.

نعمل جميعًا على ذلك معًا أولاً قبل أن نقوم بتقسيم بقية الوظائف فيما بيننا.

Answer 7

لقد كانت تجربتي أن تطبيقات Java (.NET أيضًا) التي تعتبر قاعدة البيانات هي الأخيرة من المرجح أن يكون أداؤها سيئًا عند وضعها في بيئة الشركة.عليك أن تفكر حقًا في جمهورك.لم تقل ما إذا كان تطبيق ويب أم لا.وفي كلتا الحالتين، تعد البنية التحتية التي تقوم بتنفيذها مهمة عند التفكير في كيفية التعامل مع بياناتك.

بغض النظر عن المنهجية التي تفكر فيها، فإن كيفية الحصول على بياناتك وحفظها وتأثيرها على الأداء يجب أن تكون في مقدمة أولوياتك.

Answer 8

أقترح التفكير في كيفية استخدام هذا التطبيق.كيف سيعمل المستخدمون المستقبليون معها؟أنا متأكد من أنك تعرف على الأقل بعض الأشياء حول ما يحتاج هذا التطبيق للتعامل معه، ولكن نصيحتي الأولى هي "فكر في المستخدم وما يحتاج إليه".

ارسمه على ورق عادي، وفكر في مكان تقسيم الكود.تذكر عدم خلط المنطق مع رمز واجهة المستخدم الرسومية (خطأ شائع).بهذه الطريقة، سيتم إعدادك لتوسيع نطاق وصول تطبيقاتك في المستقبل إلى servlets و/أو التطبيقات الصغيرة أو أي نظام أساسي يأتي.قسم إلى طبقات حتى تتمكن من الاستجابة للتغييرات الكبيرة بشكل أسرع دون إعادة بناء كل شيء.يجب ألا ترى الطبقات أي طبقات أخرى غير الطبقات المجاورة لها.

ابدأ بالوظائف الأساسية الحقيقية.كل هذا الوقت الضائع (الذي سيجعل مشروعك يتأخر 4 أسابيع)، لن يكون ذا أهمية كبيرة للأغلبية الضائعة من المستخدمين.يمكن إضافته لاحقًا بمجرد التأكد من قدرتك على التسليم في الوقت المحدد.

بالمناسبة.على الرغم من أن هذا لا علاقة له بالتصميم، أود فقط أن أقول إنك لن تقوم بالتسليم في الوقت المحدد.قم بعمل تقدير واقعي لاستهلاك الوقت ثم قم بمضاعفته :-) أفترض هنا أنك لن تكون وحدك في هذا المشروع وأن الأشخاص سوف يأتون ويذهبون مع تقدم المشروع.قد تحتاج إلى تدريب الأشخاص في منتصف المشروع، أو الذهاب في إجازة أو يحتاجون إلى عملية جراحية وما إلى ذلك.

Answer 9

تقسيم النظام الكبير إلى أجزاء أصغر.ولا تظن أن الأمر معقد للغاية، لأنه في العادة ليس كذلك.من خلال التفكير المعقد للغاية فإنه يدمر أفكارك وفي النهاية التصميم.في مرحلة ما، تدرك أنه يمكنك القيام بنفس الشيء بشكل أسهل، ثم تقوم بإعادة تصميمه.

على الأقل كان هذا خطأي الكبير في التصميم.

أبقيها بسيطة!

Answer 10

لقد وجدت أفكارًا ثاقبة جدًا حول بدء مشروع كبير جديد، بناءً على

• الممارسات الجيدة المشتركة
• التطوير القائم على الاختبار
• والنهج العملي

في هذا الكتاب تزايد البرامج الموجهة للكائنات، مسترشدة بالاختبارات.

إنه لا يزال قيد التطوير، ولكن قد تكون الفصول الثلاثة الأولى هي ما تبحث عنه ويستحق القراءة.