أفضل الممارسات لإدارة التعقيد/تصور المكونات في برنامجك؟

Question

نحن نبني أدوات لاستخراج المعلومات من الويب.لدينا عدة قطع مثل

• زحف البيانات من الويب
• استخراج المعلومات بناءً على القوالب وقواعد العمل
• تحليل النتائج في قاعدة البيانات
• تطبيق قواعد التطبيع والتصفية
• الخ، الخ.

تكمن المشكلة في استكشاف المشكلات وإصلاحها والحصول على "صورة عالية المستوى" جيدة لما يحدث في كل مرحلة.

ما هي التقنيات التي ساعدتك على فهم وإدارة العمليات المعقدة؟

• استخدم أدوات سير العمل مثل Windows Workflow Foundation
• قم بتغليف الوظائف المنفصلة في أدوات سطر الأوامر واستخدم أدوات البرمجة النصية لربطها معًا
• اكتب لغة خاصة بالمجال (DSL) لتحديد الترتيب الذي يجب أن تحدث به الأمور على المستوى الأعلى.

مجرد فضول حول كيفية التعامل مع نظام يحتوي على العديد من المكونات المتفاعلة.نود توثيق/فهم كيفية عمل النظام على مستوى أعلى من التتبع من خلال كود المصدر.

Answer 1

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

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

نصائح جيدة:

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

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

Answer 2

انا استخدم شركة AT&T الشهيرة جراففيز, ، إنه بسيط ويقوم بالعمل بشكل جيد.إنها نفس المكتبة التي يستخدمها Doxygen أيضًا.

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

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

Answer 3

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

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

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

Answer 4

لن أستخدم أيًا من الأدوات التي ذكرتها.

تحتاج إلى رسم مخطط عالي المستوى (أحب القلم الرصاص والورق).

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

سأفكر في استخدام قوائم انتظار متعددة لـ

• عناوين URL للزحف
• الصفحات التي تم الزحف إليها من الويب
• المعلومات المستخرجة بناء على القوالب وقواعد العمل
• النتائج التي تم تحليلها
• النتائج التطبيعية والمصفاة

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

• زاحف الويب
• مستخرج البيانات
• محلل
• التطبيع والتصفية

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

يمكن تغذية قائمة الانتظار الأخيرة إلى برنامج آخر يقوم بالفعل بنشر كل شيء في قاعدة بيانات للاستخدام الفعلي.

Answer 5

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

نحن نفضل النص لأنه الأكثر تنوعًا وسهل التحديث.يعد هذا مشكلة كبيرة - فليس كل شخص خبيرًا (أو حتى محترفًا) في Visio أو Dia، وقد يشكل ذلك عائقًا أمام تحديث المستندات.نكتب المواصفات على موقع wiki حتى نتمكن من الربط بسهولة بين كل مواصفات (بالإضافة إلى تتبع التغييرات) والسماح بالسير غير الخطي عبر النظام.

للحصول على حجة من السلطة، يوصي جويل بالمواصفات الوظيفية هنا و هنا.

Answer 6

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

Answer 7

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

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

• العمليات (يعمل كل مكون في مساحة ذاكرة معزولة)
• المواضيع (كل مكون يعمل على موضوع منفصل)
• الاتصال (تتواصل المكونات من خلال قناة واحدة بسيطة لتمرير الرسائل)

لقد قمت بكتابة أنظمة معالجة مجمعة إلى حد ما والتي تبدو مشابهة لنظامك باستخدام:

تتم إدارة كل خرائط مكون إلى .NET القابلة للتنفيذ القابلة للتنفيذ من خلال التواصل الآلي (جميعها على نفس الجهاز) من خلال Tibco Rendezvous

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

Answer 8

أحب استخدام NDepend لإجراء هندسة عكسية لقاعدة أكواد .NET المعقدة.تأتي الأداة مع العديد من ميزات التصور الرائعة مثل:

الرسم البياني للتبعية:

مصفوفة التبعية:

تصور مقياس الكود من خلال التخطيط الشجري: