التسميات في البرمجة

السلام عليكم

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

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

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

readConfigValue, getConfigValue, readConfigParameter, getConfigurationParameter

نلاحظ أنها واضحة وتتكون من ثلاث مقاطع، المقطع اﻷول read يعني أن هذه الدالة تقوم بالقراءة، والمقطع الثاني: Config يشرح الهدف الذي نريد قراءته، والمقطع الثالث Value يحدد بصورة أكثر دقة الناتج من الدالة  وهو قراءة القيمة لهذا الباراميتر.

أما إذا استخدمنا احد اﻷسماء التالية:

configValue, readX, getValue

نجد أن الإسم اﻷول: configValue ليس فيه الفعل الذي نريد تنفيذه وهو القراءة، لذلك يجد من يريد صيانة الكود أو التطوير فيه، يجد صعوبة فهم الغاية من هذه الدالة، واﻹسم الثاني readX لا يوضح ماذا نريد أن نقرأ، والإسم الثالث: getValue أيضاً لا يوضح أننا نريد القراءة من ملف اﻹعدادات.

كذلك فإن الشمولية في اﻹسم مهمة جداً، ويُفضل أن تكون مجردة قدر اﻹمكان، فإذا كانت الفئة أو الوحدة مثلاً المراد منها القراءة والكتابة من قاعدة البيانات فلا يصح أن نقوم بتسميتها DataReader فهي لا تشمل الكتابة  فالأفضل تسميتها DataReaderAndWriter أو الإكتفاء بالتسمية المجرة وهي DataClass أو DataManipulation أو Database. والتسمية المجردة لها فائدة في التطوير المستقبلي، مثلاً إذا كانت الدوال داخل تلك الوحدة البرمجية هي فقط دوال للقراءة فإن تسميتها DataReader يكون صحيحاً ما لم تتم إضافة دالة للكتابة، أما إذا تمت إضافة وظيفة الكتابة في قاعدة البيانات فلابد من تغيير اﻹسم، لكن إذا نسى المبرمج ذلك فإذن ذلك يقود إلى أن تصبح اﻷسماء غير مطابقة للوظائف ويبدأ البرنامج بالحيد من إتباعه للمباديء الصحيحة للبرمجة.

في آخر برنامج كنت اعمل عليه في الأيام الماضية وجدت أني أتوقف كثيراً في تسمية الفئات وتصنيفاتها المختلفة وكان الهدف أن لا أقوم بعمل أي خطأ في بداية التصميم وكتابة الكود، لكن هذا التأخير في وجود اﻷسماء المناسبة جعلني أفكر في أن السبب هو عدم فهمي الكامل للتحليل الصحيح للنظام. فاستنتجت أن التحليل الكامل ثم الفهم التام للنظام يجعل التصميم أسرع وبالتالي إيجاد أسماء للمكونات أسرع. مع أني لم أتأكد من هذه النظرية من مرجع ما، إلا أن هذا الإرتباط بين وضوح التحليل والتصميم الصحيح والتسميات اصبح يتضح لي أكثر فأكثر، حيث يكفي مراجعة اﻷسماء لأي برنامج لمعرفة هل هُناك خلل تصميمي ما أم أن البرنامج مكتوب بطريقة مطابقة للمباديء الصحيحة. هذه الفائدة لربط اﻷسماء بالمباديء تسهل لمن يقوم بمراجعة الكود من أجل تقيمه، فكلما كانت اﻷسماء مجردة فهي تعني أن المبرمج أو الفريق البرمجي قام باستخدام مبدأ التجريد، وكلما كانت اﻷسماء تدل على هدف واحد فهي تعني استخدام مبدأ الوظيفة الواحدة، فإذا كان اﻹسم يحتوي على أكثر من هدف مثل DatabaseAndConfiguration فهي تدل على تحميل الوحدة لأكثر من هدف، أما إذا كان اﻹسم هو Database ويحتوي على قراءة للإعدادات أيضاً من الملفات فهو يعني عدم شمولية اﻷسماء، لكن الشمولية تدل على عدم استخدام مبدأ الوظيفة الواحدة، لكن مع ذلك فإن اﻹسم الشامل أفضل في هذه الحالة لمن يريد تعديل الكود وفصل المهام عن بعضها، فيقوم بالتركيز على الوحدات التي تحتوي على أسماء لأكثر من وظيفة.

تعديل اﻷسماء أحياناً يكون سهل وذلك في اﻷجزاء الداخلية للبرامج، فيتم تعديل اﻷسماء لعدة حالات نذكر منها: الحالة اﻷولى إذا لم تكن دلالاتها صحيحة، في هذه الحال تكون ضمن عملية إعادة صياغة الكود، وذلك لتصحيح الهدف من تلك الوحدة البرمجية. والسبب الثاني هو توسعة الوظيفة، وكمثال ما ذكرناه سابقاً في الوحدة التي كان اسمها DataReader قمنا بتجريد إسمها إلى DataClass لإضافة وظيفة الكتابة مع القراءة في قاعدة البيانات. السبب الثالث هو التجريد لإعادة اﻹستخدام في برامج أخرى أو أجزاء أخرى. مثلاً إجراء للربط مع قاعدة البيانات المحاسبة كان اسمه AccountingDBConnection نقوم بتسميته إلى DatabaseConnection لإمكانية استخدامه مع أي برنامج وأي نظام آخر دون تحديد اسمه.

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

 من المباديء واﻷهداف للتي نحققها باستخدام طريقة صحيحة للتسمية هي:

  • سهولة قراءة وصيانة الكود
  • تحقيق التجريد
  • تحقيق وتسهيل إعادة اﻹستخدام
  • سهولة توقع وظيفة أي جزء من الكود
  • معرفة نقاط الضعف في أجزاء معينة من الكود مثلاً اﻷرتباط

Advertisements

اترك رد

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

WordPress.com Logo

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   / تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   / تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   / تغيير )

Google+ photo

أنت تعلق بإستخدام حساب Google+. تسجيل خروج   / تغيير )

Connecting to %s