التصميم والترميز - من الأعلى إلى الأسفل أم من الأسفل إلى الأعلى؟[مغلق]

Question

عند البرمجة، ما هو النهج الأفضل في تجربتك؟

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

Answer 1

وإليك ما أفعله:

فهم المجال أولا.فهم المشكلة التي يتعين حلها.تأكد من أنك والعميل (حتى لو كان هذا العميل أنت!) على نفس الصفحة فيما يتعلق بالمشكلة التي يجب حلها.

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

في تلك المرحلة، أكتب اختبارات للفصول التي لم يتم كتابتها بعد، ثم أقوم بتفصيل الفصول لاجتياز تلك الاختبارات.

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

هذه هي الطريقة التي أفعل بها ذلك، وقد نجح الأمر جيدًا بالنسبة لي.

Answer 2

أميل إلى التصميم من الأعلى إلى الأسفل والتنفيذ من الأسفل إلى الأعلى.

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

Answer 3

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

يعني "برنامج العمل عبر التوثيق الشامل" أن أول شيء تقوم بإنشائه هو أصغر شيء مفيد يمكنك تشغيله.قمة؟قاع؟لا.

---

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

ما لاحظته هو أن أسلوب Agile - القطع الصغيرة التي تنجح - يميل إلى تقسيم المشكلة إلى أجزاء يمكن استيعابها كلها مرة واحدة.لم يعد الاتجاه من أعلى إلى أسفل/من أسفل إلى أعلى مهمًا بنفس القدر.في الواقع، قد لا يهم على الإطلاق.

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

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

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

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

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

[استطراد.بالنسبة للمستخدمين المستنيرين، يحدد هذا التحليل المسميات الوظيفية وطرق العمل الجديدة.مع المستخدمين غير المطلعين، تبقى الوظائف القديمة ونكتب جبالًا من الوثائق لربط الوظائف القديمة بالبرامج الجديدة.]

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

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

مبدأ القيادة هو Agile - بناء شيء ناجح.التفاصيل موجودة في جميع أنحاء الخريطة - أعلى، أسفل، أمام، خلف، البيانات، العملية، الممثل، مجال الموضوع، قيمة الأعمال.

Answer 4

نعم.افعل كل تلك الأشياء.

قد يبدو الأمر ساخرًا (آسف، سأعود إلى النموذج)، ولكن هذه الحالة لا توجد فيها إجابة صحيحة.

Answer 5

وبطريقة رشيقة أيضًا، اكتب اختبارك (اختباراتك) أولاً!

إذن كل البرامج عبارة عن دورة مستمرة من

• الأحمر - يفشل الرمز في الاختبار
• الأخضر - الرمز يجتاز الاختبار
• Refactor - تحسينات التعليمات البرمجية التي تحافظ على النية.

العيوب والميزات الجديدة والتغييرات.كل ذلك يتبع نفس النمط.

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

امل ان يساعد.

Answer 10

تصميم من الخارج إلى الداخل.

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

Answer 11

أنا أتفق نوعًا ما مع جميع الأشخاص الذين يقولون "لا هذا ولا ذاك"، لكن الجميع يقع في مكان ما في الطيف.

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

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

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

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

Answer 12

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

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

Answer 13

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