الفرق بين المراجعتين ل"Refactoring/what is refactoring"
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الشيفرة النظيفة (Clean Code)}}</noinclude> تهدف عملية إعادة التصميم (refactoring) للتخلُّص من ال...') |
ط (تنسيق لا أكثر) |
||
| سطر 4: | سطر 4: | ||
== مميزات الشيفرة النظيفة == | == مميزات الشيفرة النظيفة == | ||
فيما يأتي بعضٌ مما يميز الشيفرة النظيفة: | فيما يأتي بعضٌ مما يميز الشيفرة النظيفة: | ||
| − | * واضحةٌ ومقروءةٌ للمبرمجين الآخرين | + | * '''واضحةٌ ومقروءةٌ للمبرمجين الآخرين''' |
إنّ ما يجعل الشيفرات أكثر تعقيدًا (بعيدَا عن الخوارزميّات فائقة التعقيد) هو اعتمادها على تسمية المتغيِّرات تسميةً ضعيفةً (غير منطقيّةٍ أو بدون معنى) أو احتوائها على أصناف (classes) وتوابع ضخمةٍ وكذلك الكثيرَ من الأعداد وما شابه، وهذا ما يجعل من الصعب التمكُّن منها. | إنّ ما يجعل الشيفرات أكثر تعقيدًا (بعيدَا عن الخوارزميّات فائقة التعقيد) هو اعتمادها على تسمية المتغيِّرات تسميةً ضعيفةً (غير منطقيّةٍ أو بدون معنى) أو احتوائها على أصناف (classes) وتوابع ضخمةٍ وكذلك الكثيرَ من الأعداد وما شابه، وهذا ما يجعل من الصعب التمكُّن منها. | ||
| − | * لا تكرار فيها | + | * '''لا تكرار فيها''' |
لأنّ أيّ تغييرٍ في جزءٍ مُكرَّرٍ سيتطلَّب -بلا شك- إجراء التغيير ذاته بكافّة النسخ المُكرَّرة عنه، وهذا ما يُبطِئ تطوير الشيفرة ويزيد من عُسر فهمها. | لأنّ أيّ تغييرٍ في جزءٍ مُكرَّرٍ سيتطلَّب -بلا شك- إجراء التغيير ذاته بكافّة النسخ المُكرَّرة عنه، وهذا ما يُبطِئ تطوير الشيفرة ويزيد من عُسر فهمها. | ||
| − | * بأقل عددٍ ممكنٍ من الأصناف (classes) والأجزاء البرمجيّة الأخرى القابلة للنقل | + | * '''بأقل عددٍ ممكنٍ من الأصناف (classes) والأجزاء البرمجيّة الأخرى القابلة للنقل''' |
إذ تحتاج الشيفرة الأقصر صيانةً أقل، وترد الأخطاء فيها بنسبةٍ أخفض، ولتكن القاعدة: "للحصول على شيفرة أكثر ضمانًا، أبقِها قصيرةً بسيطة". | إذ تحتاج الشيفرة الأقصر صيانةً أقل، وترد الأخطاء فيها بنسبةٍ أخفض، ولتكن القاعدة: "للحصول على شيفرة أكثر ضمانًا، أبقِها قصيرةً بسيطة". | ||
| − | * تجتاز الاختبارات المختلفة بنجاح | + | * '''تجتاز الاختبارات المختلفة بنجاح''' |
تُعدُّ الشيفرة رديئةً عندما تجتاز الاختبارات وعمليات التحقق بنسبة 95% فقط، فكيف سيكون الحال إذا كانت نسبة نجاحها 0%؟ | تُعدُّ الشيفرة رديئةً عندما تجتاز الاختبارات وعمليات التحقق بنسبة 95% فقط، فكيف سيكون الحال إذا كانت نسبة نجاحها 0%؟ | ||
| − | * سهلة ولا تحتاج الصيانة (maintenance) | + | * '''سهلة ولا تحتاج الصيانة (maintenance)''' |
== مصادر == | == مصادر == | ||
* [https://refactoring.guru/refactoring/what-is-refactoring صفحة توثيق الشيفرة النظيفة في موقع refactoring.guru] | * [https://refactoring.guru/refactoring/what-is-refactoring صفحة توثيق الشيفرة النظيفة في موقع refactoring.guru] | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
المراجعة الحالية بتاريخ 16:24، 17 يوليو 2018
تهدف عملية إعادة التصميم (refactoring) للتخلُّص من المتطلَّبات التقنيّة الزائدة، إذ تحوِّل كلَّ الفوضى المنتشرة في الشيفرة إلى شيفرةٍ نظيفةٍ (clean code) ذات تصميمٍ مُبسَّط، وهذا -لا بُدَّ- أمرٌ رائعٌ ولكن بالبداية؛ ما معنى أن تكون الشيفرة نظيفةً؟
مميزات الشيفرة النظيفة
فيما يأتي بعضٌ مما يميز الشيفرة النظيفة:
- واضحةٌ ومقروءةٌ للمبرمجين الآخرين
إنّ ما يجعل الشيفرات أكثر تعقيدًا (بعيدَا عن الخوارزميّات فائقة التعقيد) هو اعتمادها على تسمية المتغيِّرات تسميةً ضعيفةً (غير منطقيّةٍ أو بدون معنى) أو احتوائها على أصناف (classes) وتوابع ضخمةٍ وكذلك الكثيرَ من الأعداد وما شابه، وهذا ما يجعل من الصعب التمكُّن منها.
- لا تكرار فيها
لأنّ أيّ تغييرٍ في جزءٍ مُكرَّرٍ سيتطلَّب -بلا شك- إجراء التغيير ذاته بكافّة النسخ المُكرَّرة عنه، وهذا ما يُبطِئ تطوير الشيفرة ويزيد من عُسر فهمها.
- بأقل عددٍ ممكنٍ من الأصناف (classes) والأجزاء البرمجيّة الأخرى القابلة للنقل
إذ تحتاج الشيفرة الأقصر صيانةً أقل، وترد الأخطاء فيها بنسبةٍ أخفض، ولتكن القاعدة: "للحصول على شيفرة أكثر ضمانًا، أبقِها قصيرةً بسيطة".
- تجتاز الاختبارات المختلفة بنجاح
تُعدُّ الشيفرة رديئةً عندما تجتاز الاختبارات وعمليات التحقق بنسبة 95% فقط، فكيف سيكون الحال إذا كانت نسبة نجاحها 0%؟
- سهلة ولا تحتاج الصيانة (maintenance)