لا توجد منتجات في سلة المشتريات.
يا أيها المبرمج: أنت إنسان مُحترف، تطور برامجك لتعمل بأفضل صورة و تبذل جهدك لتُتنتج أفضل البرامج بأقل الأخطاء، تحوّل كاسات القهوة إلى أسطر برمجية في ليالٍ حالكة.
و عندما يأتي الصباح تكون قد كتبت في داخل برنامجك شيئاً ما مثل هذه الشفرة البرمجية
ثُم يأتيك أحدهم ليطلب منك تعديلاً فتبدأ بقراءة شفرتك البرمجية و تُنادي…
يا للدهشة!!
أنا كتبتُ ذلك.
يا أيها المبرمج: حدث ما حدث فقط لأنك لم تقي نفسك شر الدهشة بإستخدام المقروئية.
ما هي المقروئية Readability
بدون أن أقودك عبر تعريفات رسمية كالعادة، بكل بساطة المقروئية هي قابلية القراءة 🙂 .
نعم، هي بهذه البساطة. المقروئية هي أن تكتب شفرة برمجية يستطيع المبرمجون الآخرون قرائتها.
إذا سهرتَ و كتبت مثل الشفرة البرمجية السابقة ليلاً، لم تستطع صباح اليوم التالي أن تفسر ما كتبته لأنك لم تستخدم المقروئية في شفرتك البرمجية.
في حقيقة الأمر هذا الأمر لم يحدث لك. بل حدث لي.
هذه الشفرة التي تراها أعلاه جزءٌ من برنامج بلغة الجافا طورته في عام 2009.
حاولت اليوم الإطلاع على الشفرة البرمجية، و كان أول ما شاهدته هو هذا الجزء من الشفرة البرمجية. حاولتُ فهم الهدف الذي تؤديه هذه الدالة دون أن أشاهد ما تبقى من أجزاء الصنف.
نعم، توقعك صحيح!
للدقة، لم أستطع فهم ما تفعله الدالة تماماً.
و لتفادي هذه المشكلة كان لا بد أن أرفع درجة المقروئية في شفرتي البرمجية، فاليوم لم أستطع أنا و بالتأكيد لن يستطيع غيري فهم هذه الشفرة البرمجية.
إنظر إلى ما طلبه الأستاذ و المبرمج أحمد حمزة في إحدى مقالاته على لينكدإن أن لا تحتوي الشفرات المصدرية على ارقام سحرية.
كان هذا لسبب بسيط و هنا أقتبس من مقالته
السؤال الذي سيطرحه اي مبرمج . لماذا 247 والي ماذا يرمز هذا الرقم
اذا طلبت منك صيانة الدالة اعلاه فانك ستواجه صعوبة في تغير الرقم اعلاه لانك لاتدري بالضبط ما هذا الرقم
5 خطوات لبداية تطبيق المقروئية في الشفرات البرمجية
هناك قواعد عامة يجب تطبيقها على الشفرة البرمجية حتى تُصبح قابلة للقراءة لجميع المبرمجين.
أعتبر أن هذه القواعد هي أقل ما تستطيع تطبيقه حتى نقول أن شفرتك البرمجية قابلة للقراءة.
لكن إنتبه:
لن تستطيع أبداً أن تحكم على شفرتك البرمجية أنها قابلة للقراءة و يكون حكمك صحيح دائماً.
لماذا؟
كما أن كُل شخص يستطيع فهم خطه، فإن كُل شخص يستطيع فهم شفرته البرمجية. إنها أفكارك يا أيها المبرمج، لذا قدرتُك على قراءة شفرتك البرمجية غيرُ مهمة، بل قُدرة المبرمجين الآخرين على قرائتها.
لذا فالأفضل دوماً حتى تحكم على شفرتك البرمجية أنها مقروءة، اعرضها على مبرمجين آخرين و استمع لآرائهم.
هذه نقاط لتُطبقها على شفرتك البرمجية لترفع درجة المقروئية
- أسماء المتغيرات و الدوال و الأصناف يجب أن تكون معبرة.
- إجعل الأصناف و الدوال قصيرة بما يكفي، تحاشى الأسطر التي لا تنتهي.
- إستخدم التعليقات لتوضيح مهام أجزاء برامجك و شرح منطق عمل البرنامج.
- لا تستخدم الإزاحة بشكل مفرط.
- إجعل شفراتك معيارية، بمعنى استخدام تنسيق واحد في كل مكان في برنامجك.
باتباعك لهذه النقاط البسيطة ستحدث تحولاً كبيراً في درجة مقروئية شفرتك البرمجية.
أنظر إلى الأخطاء التي وقعتُ فيها أثناء تطويري لذاك البرنامج القديم.
- إسم الدالة غير مكتمل و غير واضح تماماً، قد تكون check_attribute أو check_attack.
- تعريف المتغير id غير واضح أيضاً، ربطه بإسم الصنف أو الكائن المتعلق به قد يكون أوضح. مثل studentID.
- بعد البحث وجدت أن ss هو كائن من صنف، إستخدام هذه الأحرف المبهمة غير مفيد إطلاقاً في مقروئية البرنامج. بدلاً من ذلك وجب علي إستخدام إسم واضح مثل sort.
- يبدو أن الإرهاق في ذلك اليوم بلغة مبلغه، حيث أن من عادتي أن أكتب تعليقاً في نهايات الدوال، ولكن في ذاك اليوم لم أكمل التعليق!.
- ما هي مهمة الدالة المنطقة وماذا تفعل من إجراءات بصورة عامة، هذا ما يجب إيضاحه كتعليق قبل كتابة الدالة، هو ما لم أعره أدنى إهتمام في هذا الجزء من البرنامج.
إن كُنت ما زلت تقع في هكذا أخطاء حاول تفاديها إبتداءً من اليوم.
جدلية الإهتمام بالمقروئية
الإهتمام بالمقروئية لا تعود فائدته على المبرمجين الآخرين فقط. بل تعود إلى أمور أهم من ذلك.
في بيئات تطوير النظم التي يعمل فيها عدد كبير من المطورين تجد أن الجزء الواحد من البرنامج يعمل عليه مبرمجون مختلفون، بعد أن يُنهي كل مبرمج عمله في الجزء الذي يخصه تكون الخطوة التالية دمج هذه الشفرات البرمجية.
عملية الدمج هذه أحياناً تتأثر بدرجة كبيرة بدرجة مقروئية الشفرات البرمجية، فالتأكد من أن عملية الدمج تمت بصورة صحيحة و متابعة الأخطاء تضطر المبرمج إلى قراءة الشفرات البرمجية لمبرمجين مختلفين.
و هذا يعني أن خطأً واحداً في شفرة برمجية بمقروئية معدومة قد تكلف هذا المبرمج وقتاً طويلاً لإيجاد المشكلة أو حتى التأكد من أن الشفرة تعمل بصورة صحيحة.
هذا يعني أن نجاح النظم أحياناً يعتمد على درجة مقروئية الشفرات البرمجية، و قد يعني أيضاً أن سهولة و سرعة صيانة البرامج تعتمد على درجة مقروئية الشفرة البرمجية.
محاولة رفع درجة المقروئية في الشفرة البرمجية تُبطئ من سرعة إنتاج البرامج، ولكنها على الصعيد الآخر ستزيد من سرعة صيانة و تطوير الشفرة البرمجية مستقبلاً.
و كما يعلم أغلب المبرمجين، فإن هذا الأمر يكفي لأن يكون للمقروئية في الشفرة البرمجية شأن لا يُمكن تجاهله، فبإطلاعك على درجة المقروئية في الشفرة البرمجية في ثوان تستطيع التمييز بين المبرمج المُبتدئ و المبرمج المحترف.
ويبقى الإختلاف موجوداً، فبعض المُبرمجين يُفضل سرعة الإنتاج على رفع درجة المقروئية، و بعضهم يفضل العكس، و أرى أن بذل الجهد و الوقت في رفع درجة المقروئية يجب أن يتناسب طردياً مع أهمية البرنامج و إحتمالية العمل عليه مستقبلاً، أليس كذلك؟
ارى ان قابلية المقروئية و اختصار الاكواد يجب ان يجتمعا اليكون البرنامج سريع وواضح
كم من الوقت يستغرقه المبرمج اذا اهتم بالمقروءية بالمقارنة اذا لم يهتم بها؟
غير قابلة للقياس 🙂