السلام عليكم و رحمة الله تعالى و بركاته
التناغم مع البيرل
خمس قواعد يجب التقيد بها
كما قال داميان كونواي (Damian Conway)، العضو البارز في مجتمع البيرل، "دائما افترض أن الشخص الذي سوف يقوم بصيانة الكود الخاص بك، هو ذلك المريض نفسيا العنيف الذي يعرف أين تعيش".
كتابة و صيانة الكود البرمجي يمكن أن يكون إحدى أشقى الأعمال إذا لم تتقيد بالتهذيب في كتابة برنامجك. أحيانا، الطريقة التي تتخذها كحل تكون حقا ذات أهمية . غالبيتنا نملأ الجو صراخا بـ "ما هي" الطريقة و في المقابل لا نلتفت إلى "كيف". هذه الممارسة قد تتحول إلى مصدر لصداع الرأس كلما زاد حجم الكود. و هاهي بعض "المسكنات" أحسن التعليمات لتجنب مثل هذه الحالات.
Strict’ures‘
لنفترض حالة أين تتوه في برنامج ذو آلاف السطور. في إحدى هذه السطور تكون قد أخطأت في كتابة اسم متغير، لنقل، بدل كتابة friends_list@ تجعلها سهوا freinds_list@. قد لا تكون لك أي فكرة على أن الكود يعطيك نتائج خاطئة بسبب خطأ في التهجأة. إنها ليست عملية سهلة لمعرفة هذه الأخطاء (الحشرات). في بعض الأحيان يتوجب عليك أن تناضل لساعات مدققاُ في قاعدة البيانات، الملفات العازلة (file buffers) أو حتى مراجعة منطقك لإصلاح هذه الحشرة(1) البغيضة.
هذه الحالة يمكن تفاديها بسهولة باستعمال strict المفيدة. هي تفرض على المبرمج أن يعرِّف كل المتغيرات كمجموعة أو تتبع ترتيب استدعائها قبل استعمالها (المتغيرات). في الواقع، كل برنامج لا بد له من يبدأ بـ "use strict" و من المهم جدا أن يعرَّف كل متغير على أصغر نطاق ممكن، وبذلك تقليص النتائج "المفاجئة".
Modularising
نفاد الصبر جزء لا يتجزأ من سمات كل مبرمج. و كلما تم إسناد المهام، نغوص لتنفيذ المتطلبات و نبدأ برمجة الصفحات و الصفحات في كتلة واحدة/روتينية. إنها عادة سيئة، يجدر بك دائما تخصيص مدة زمنية لا بأس بها للتخطيط و تقسيم المهمة إلى جزيئات روتينية صغيرة و إعطائها اسم مفهوم، لأن ذلك هو الجزء الأهم.
عندها نصف عملك يكون قد تم، إذا تم القيام به بشكل صحيح. كتابة إجراء واحد للأكل، الرياضة و النوم إنها أيضا عادة سيئة. كل قطعة من الكود يجب أن تكون مخصصة للقيام بأمر واحد و بشكل صحيح. علاوة على ذلك، هذه الممارسة تجعل البرنامج أكثر قابلية للصيانة، و تصحيح الأخطاء و التحقق أكثر سهولة. مزيج من التوجيهات المسماة(2) أحسن بكثير من مصفوفة بسيطة إذا كان لديك أكثر من ثلاثة معايير لتمريرها إلى إجراء ثانوي(3). وهي تنفع في عدم الحاجة إلى تذكر ترتيب المعايير الممررة إلى الإجراء.
التوثيق
إنها فقط جعل الكود أسهل لقراءته. يمكن أن تتم بإعطاء المتغيرات، الإجراءات، الملفات، الخ، اسم ذو دلالة. و لا تولد ارتباك عند تسمية المتغيرات، الاسم يجب أن يعكس ما يحتويه.
ستؤدي إلى زيادة وضوح برنامجك، و في المقابل يقلل من الإرباك. كلما كانت الأخطاء جلية، تجعلك أقل احتمالا لارتكاب الغلطات. لأن الفكرة الأساسية من اللغة، سواء كانت منطوقة أو برمجية، هي التواصل، إذاُ اجعل برنامجك يفصح عن نفسه.
قليل من التهذيب
العرض له تأثير هائل. كل واحدة من الكتل المتداخلة يجب أن توضح بشكل منفرد. إذا كنت لا تريد أن تضيع الوقت على هذه اللمسات التجميلية، يمكنك استعمال Perl::Tidy الذي يمكن تحميله من CPAN. بحيث يقوم بتنسيق و تجميل الكود الخاص بك، ويمكن حتى تهيئتها وفقا للأسلوب الذي تفضله.
نقطة أخرى في هذا الموضوع هي تسمية المتغيرات و الإجراءات، كل الأسماء يجب أن تفسر نفسها بنفسها إلى أبعد حد، الكود يجب أن يقرأ كالنثر وليس كاللغز.
API / تصميم الوحدة
هذا كل شيء عن تصميم واجهة المبرمج، و هي تتطلب كلاُ من الخبرة و الإبداع. التصميم غير اللائق للـ API سينتهي إلى تدهور الفجائي للأداء و يضعف قابلية الصيانة للنظام. إحدى الممارسات الحسنة بخصوص تصميم API هي كتابة أكواد بسيطة التي تستعمل الوحدة قبل كتابة هذه الوحدة، لأنها ستساعد في معرفة "كيف ينبغي أن تعمل هذه الوحدة".
بعض الخصائص الجيدة للـ API هي: سهولة الاستعمال، سهولة التعلم، سهولة التوسع، صعوبة سوء الاستخدام، سهولة القراءة و صيانة الكود المستعمل لها، مناسبة للجمهور وقوية بما يكفي لتلبية الاحتياجات. البداية في تصميم API مع عدد قليل من المواصفات سيكون مثاليا، لأنه أكثر سهولة للتعديل.
و أوصي بشدة قراءة الكتاب "Perl Best Practices" لصاحبه Damian Conway قبل كتابة أي سطر برمجي.
- - - - - - - - - - - - - - - - - - - - - -
1- حشرة = bug
2- مزيج من التوجيهات المسماة = hash of named arguments
3- إجراء ثانوي = subroutine
- - - - - - - - - - - - - - - - - - انتهت الترجمة [مروان - الفريق العربي للبرمجة]
في كال كان هناك سوء ترجمة فيمكن للمسؤول عن القسم أن يعدل على الموضوع مع ما يتوافق مع الفهم الصحيح لجميع العرب
Flirt with Perl -- Five rules you should follow By: Arshad Mohamed The author is a Web2.0 developer currently working with Genseq, Malaysia as a developer for an online Health Reporting System. He has worked over four years as programmer/developer, and mostly uses Perl. His other expertise includes Ajax, MySQL, Linux, Apache and JavaScript |  |
:)