كيف يمكنني التخطيط لبرنامجي لتجنب الإفراط في إعادة الكتابة والترابط

Question

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

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

لقد حاولت وضع بعض الرسوم البيانية والإجمالية للمستويات/السائقين المعينين ، لكنني لست متأكدًا من كيفية تنظيمها حتى أتمكن طبقات.

أعتقد أن هذا هو سبب درجة CS؟ أنا مهندس كهربائي: P

Answer 1

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

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

Answer 2

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

إليك بعض الاقتراحات:

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

إنه يشبه إلى حد ما نصيحة مدرس الشطرنج الكلاسيكية: "اجلس على يديك" :-)

Answer 5

السائقين قابلة لنهج الطبقة.

يمكن أن يكون لسائقيك العديد من "الفصول":

• المدخلات فقط
• الإخراج فقط
• كلاهما أنا و O.

يجب أن يكون لديهم واجهة موحدة ، على سبيل المثال:

GetKnobLevel()
GetNextKeyboardButton

أو نهج آخر هو الحصول على شيء مثل

syscall(DRIVERNUMBER, command)

وضع المعلمات/النتائج في سجلات محددة.

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

هذا هو النموذج العقلي الذي أستخدمه:

---
Application
---
OS
---
Driver communicators
---
drivers
---
hardware

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

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

هذا هو قليلا من حل "المحركات الزائدة" ، أن نكون صادقين. ولكن ، في موقف يزداد فيه تعقيدك ، من الأسهل الحصول على هندسة ضيقة من أن يكون لديك هندسة فضفاضة.

إذا كنت تتواصل بين الطبقات ، فيمكنك استخدام متغير عالمي لكل "قناة" للاتصال ، والوصول إليه بطريقة منضبطة ، باستخدام وظائف فقط للوصول إليها.

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

هذا هو النهج الذي تفضله في عمل أنظامي المدمج ويعمل بشكل جيد بالنسبة لي.

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

Answer 6

في رأيي ، أهم جوانب الكود المعماري جيدًا درجة منخفضة من الاقتران و فصل الآثار الجانبية عن الدولة.

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

Answer 7

لا يجب أن تكون طيبة للغاية ، ولكن اقتباس من شهر الرجل الأسطوري يتبادر إلى الذهن: "خطط لرمي واحد بعيدا ؛ أنت على أي حال."

النتيجة الطبيعية هي "اجعلها تعمل. اجعلها صحيحة. اجعلها سريعة."

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