إرشادات لإجراء عملية التصميم ومراجعات تعليمات برمجية

توفير الإرشادات التالية أساليب عديدة للتصميم و تعليمات برمجية مراجعة.

ضروري

  • الخاص بك وقتاً إلى مراجعة.

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

  • ترك للمراجعين محرك أقراص المراجعة.

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

  • قراءة مستند قبل الاجتماع مراجعة تعليمات برمجية أو التصميم.

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

  • استخدم فريق موقع المشروع لمراجعة في المجموعة.

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

  • استخدم قائمة تدقيق.

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

  • مقطع صوتي الجميع المشاكل خلال عملية مراجعة تعليمات برمجية.

    توثيق المشاكل كـ، عناصر العمل كـ التعليقات في تعليمات برمجية، أو كـ المشاكل في مستندات التصميم. وإلا، يمكن يحصل المشاكل المفقودة والذي سوف يكون gained شيئا عن الوقت الذي كنت استثمرت في تعليمات برمجية المراجعة. لمزيد من المعلومات، راجع كيفية: إنشاء عنصر عمل.

تجنب

  • تغيير تعليمات برمجية أو التصميم دون إعلام المراجعين.

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

مستحسن

  • قم بتضمين ممثلي من الجميع الأنظمة.

    على الرغم من أنها هو ليس دائماً feasible للعديد من dهوciplines، عدا التطوير، ومراجعة التصاميم والتعليمات البرمجية الخاصة بك، ممثلي من dهوciplines المختلفة تساعد dهوcover الثابت-إلى-حبر هو sues. شخص واحد، أو ربما شخصين، كل dهوcipline هو كافية. تشمل الأشخاص أكثر مما يجعل مراجعات تستغرق وقتاً طويلاً وأن يكون صعباً إلى إدارة.

  • قم بمراجعة الجميع تعليمات برمجية و تصميمات.

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

  • خذ بعين الاعتبار إنشاء shelvesets إلى إدارة مراجعة تعليمات برمجية الخاصة بك.

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

راجع أيضًا:

المبادئ

‏‏يتم الآن التحليل? جودة تطبيق باستخدام أدوات ‏‏يتم الآن التحليل? تعليمات برمجية

تحسين جودة تعليمات برمجية مع مشروع الفريق في فحص من نهج