ما هي معايير جودة البرمجة او المبرمج ؟

في الغالب الكود الجيد هو:

الذي يكون قابل للصيانه Maintainability

هو الذي يطبق معايير الحمايه بشكل جيد الSecure Code

الكود الأقل استهلاك لموارد النظام Most Efficient

هو الكود الذي لا يعيد اختراع العجلة ويستخدم ال libraries المتوفرة بقدر الإمكان

الصيانه هي من الأمور المهمه بالنسبة للمبرمج العادي :

وهي لها اكثر من مسار تستطيع عمله حتى يكون كودك أفضل، سواء جعلته أكثر مقروئية Readability أو يسهل العمل والاضافه عليه Extensible أو الذي يفحص مدخلاته جيداً Robustness Code والذي يسهل اختباره Testability..

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

وقد تصل للمقروئية الجيدة في حال اتبعت التسميات الجيدة والتي فيها الغالب لكل لغه Convention خاص بها ، وايضاً اذا استخدمت بعض ال Patterns لكي تحسن الAPI لديك، على سبيل المثال لماذا تقوم بعمل دالة بناء تستقبل 20 مدخل ؟ فلم لا تكبسلها Encapsulated مثلاً ؟ أو تستخدم Builder Pattern أو Static Factory ؟

من الطرق للوصول لل Maintainability هي عن جعل الدوال والكلاسات لديك مسؤولة عن شيء واحد فقط Single Responsibility وهكذا لن تكون مضطر لتغيير تلك الأمور الا لسبب واحد فقط..

ايضاً كلما حولت مشروعك لفكرة ال Modules ) Layers أو Packages أو Namespaces ) وقللت التداخل Coupling بين تلك الوحدات وأخفيت كل شي بقدر الامكان Hide Implementation كلما جعلته اكثر قابلية للصيانه ، لذلك نقول (لا تستخدم public الا عندما تحتاجها فقط):

بالنسبة للبقية Extensibility وال Testability ففي الغالب تستطيع الوصول لتلك الخصائص عندما تجعل مشروع يقوم على فكرة الInterface-Based Design ، بمعنى عندما تصمم كلاس يتعامل مع القاعدة اجعله يطبق Interface معينة، ويرجع Business Domain ما، والسبب أنك ربما قد تحتاج لجعل البرنامج يتعامل مع data source أخرى وهنا سوف تقوم بتطبيق نفس ال Interface وهكذا البرنامج سوف يتطور بدون تغيير، وفي نفس الوقت قد تقوم بعمل Mock للdata access هذه وتقوم باستخدمها في unit test حتى تتأكد من عمل الطبقة التي تتعامل مع هذه الdata access

لو نظرت اعلاه ستجد أننا استخدمنا OO Principles والحق يقال كلما استخدمتها بشكل جيد كلما وصلت لكود جيد أيضاً، والحقيقة المرة أن تطبيق الOO بشكل جيد صعب ويحتاج لدراسه (وأقصد كتابه كائنات تقوم بالBusiness مثلاً EbookParser أو TaskSchedular أو PaymentProcessor وليس فقط Employee أو Animal والخ من هذه ال Business Objects) فكثير ما يخطئ المبتدئين عندما يستخدموا OO Language ويقوموا بعمل بضعه Concept Objects ويظن أن هذه هي الOO ولكن الحقيقه هو أنه استخدم Objects ولكن ضمن سياق Procedural Logic