الشفافية المرجعية في البرمجة الوظيفية Referential transparency in functional programming

بسم الله و الحمد لله و الصلاة و السلام على رسول الله و بعد...
من أهم مميزات البرمجة الوظيفية functional programming ما يسمى بالشفافية المرجعية Referential transparency.
لفهم الشفافية المرجعية فينبغي علينا أن نستوعب مفهوما آخر يسمي التأثير أو التأثر الجانبي side effect للبرنامج, و أي برنامج يتفاعل مع العالم الخارجي, كأن يستقبل بيانات من المستخدم, أو يكتب بيانات في ملف, أو يغير في بعض البيانات التي هي مشاع بين أجزاء البرنامج الأخرى (و التي بدورها تمثل حالة state البرنامج الكلي) ...إلخ, فيعتبر له تأثير أو تأثر جانبي.
يمكن اعتبار البرنامج أو العبارة البرمجية expression ذو شفافية مرجعية إذا أمكن استبداله يقيمته من غير أن تتغير النتيجة النهائية, أو بعبارة أخرى إذا أعطَى نفس المخرجات عندما تُعطى له نفس المدخلات. مثال: العملية الرياضية (5 * 5) يمكن استبدالها بـ (25) من غير "تأثير جانبي" على البرنامج, فهي ذات شفافية مرجعية, أما إذا كان لدينا برنامج جزئي function - و ليكن اسمه GetInput(), يأخذ بيانات من المستخدم ليعرض النتيجة بناء على ما أدخله المستخدم, فهذا البرنامج ليس له شفافية مرجعية لأنه عند إعطائه نفس المدخلات (في حالتنا هذه لا شيء) نحصل على نتائج مختلفة تتبع ما أدخله المستخدم؛ فالبرنامج في هذه الحالة له "تأثر جانبي".
لم أفهم بالضبط سبب تسمية هذا المفهوم بالشفافية المرجعية, لكن أخمن أن السبب هو أن البرنامج متى استُدعي من أي مكان سيعطي نفس النتيجة طالما أخذ نفس المدخلات, فالمرجع هنا (البرنامج) فيه شفافية, و لا يتأثر يمن استدعاه... ليتنا نطبق هذا المفهوم في حياتنا السياسية :)
و السلام...

ترجمة كتاب 97 مسألة ينبغي أن يعرفها كل مبرمج 97 things every programmer should know--1

* مقدمة
بسم الله و الحمد لله و الصلاة و السلام على رسول الله و بعد...

فكتاب 97 مسألة ينبغي أن يعرفها كل مبرمج فيه فوائد متفرقة, على طريقة صيد الخاطر, كتبها مبرمجون كثر. و من مراجعات الكتاب على موقع أمازون بدى لي أن الكتاب جيد , و يفيد أكثر المبرمجين المبتدئين.
و الجميل في الكتاب أنه يمكن قراءته كاملا من على موقعه, و الأجمل أن هناك مسائل أخرى - على نفس الموقع أيضا - فيها زيادة فائدة, و ليست مطبوعة في الكتاب.
فأحببت أن أترجم الكتاب (و إن شئت فاعتبره تلخيصا أيضا) لكن بالطبع أتصرف في الترجمة و لا أتقيد فيها بالحَرْفية ...و لا حول و لا قوة إلا بالله.
و الآن, مع المسألة الأولى...

1- لا تؤجل عمل اليوم إلى الغد
مهما بدا في الوقت متسع لإنهاء المهمة التي أنت بصددها, سيأتي عليك لحظات - و لابد - تشعر فيها بضيق الوقت. و عندها سينبغي عليك أن تختار بين أمرين - لا ثالث لهما - إما أن تفعل الشيء الصحيح أو أن تفعل الشيء السريع. الخيار الثاني يبدو أكثر جاذبية, خاصة إذا علمت من نفسك القدرة على العودة و فعل الشيء الصحيح ثانية عندما يتاح لك الوقت. لكن المشكلة هنا أنه عندما يأتي الوقت الذي كنت تظن أنك قادر على إعادة الأمور إلى نصابها فيه, ستكون مشغولا بأمور أخرى, و هكذا تظل تؤجل إلى أن يصبح قرار التصحيح مكلفا للغاية.
و من يفعل ذلك يشبه حاله من اقترض قرضا ربويا, فإنه يستفيد منه على المدى القصير, لكن عليه أن يدفع فائدة ربوية زيادة على ما اقترضه, و كلما تأخر في السداد, زادت عليه الفوائد الربوية, و ربما يسجن في النهاية إن تعسر في السداد!
فحاول ما أستطعت ألا تضع نفسك في مثل هذا الموقف, فإن اضررت إليه اضطرارا, كأن تكون ملتزما بموعد تسليم مثلا, فحاول أن تعود لتفعل الشيء الصحيح في أسرع وقت ممكن قبل أن تسوء الأمور. وقيد (سجّل) ما ينبغي عليك فعله حتى لا يتوه في غياهب النسيان.
- يمكن قراءة النص الأصلي من هنا.

البرمجة الثنائية Pair Programming

* مقدمة
بسم الله و الحمد لله و الصلاة و السلام على رسول الله و بعد...
فالبرمجة الثنائية Pair Programming هي أن يجلس اثنان من المبرمجين على حاسب واحد ليكتبا برنامجا واحدا: أما أحدهما - و هو القائد driver - فيكتب البرنامج و أما الأخر - و هو المراجع أو المراقب observer - فيدقق فيما يُكتب و يتابع سير العمل. و يتبادل المبرمجان القيادة و المراجعة فيما بينهما من حين لآخر.
و البرمجة الثنائية هي إحدي الطرق المستخدمة في تطوير البرمجيات السريعة أو المرنة Agile Software Development و أحد أهم تطبيقات البرمجة القصوى Extreme programming في هندسة البرمجيات.

* إحصاءات [1]

• أظهرت دراسة سنة 1998 أن البرمجة الثنائية تقلل وقت البرمجة بنسبة 40% بينما تزيد مجهود المبرمجين بنسبة 60%.

• دراسة أخرى سنة 2000 أن البرمجة الثنائية تؤدي إلى تحسن في دقة البرنامج correctness و خلوه من الأخطاء و الثغرات البرمجية bugs بنسبة 15%, و كذلك أظهرت أن وقت البرمجة يقل بنسبة 20% إلى 40%, لكن في نفس الوقت تؤدي البرمجة الثنائية إلى زيادة في المجهود المبذول بنسبة 15% إلى 60%!

• أظهرت دراسة ثالثة سنة 2006 أن البرمجة الثائية نسبة إلى البرمجة الفردية تؤدي إلى تحسن ملحوظ في الإنتاجية إذا كان كلا المبرمجين مبتدئين. أما إذا كان كلا المبرمجين محترفين فإن هناك تحسن و لكن ليس بذات النسبة العالية.

• أظهرت دراسة رابعة سنة 2007 أن البرامج المعقدة تتحسن جودتها بنسبة 48% بتطبيق البرمجة الثنائية, و لكن لا يتأثر وقت الإنتاج. بينما البرامج البسيطة يقل وقت إنتاجها بنسبة 20% عند تطبيق البرمجة الثنائية و لكن لا يحدث تحسن ملحوظ في دقة البرنامج correctness.

• أظهرت دراسة خامسة سنة 2008 أن البرمجة الثنائية تظهر فائدتها القصوى عند تصميم البرامج (يعني التصميم الهندسي و ليس التصميم الفني)

• و في سنة 2007 أظهرت بعض التجارب أنه حتى بتطبيق أسلوب البرمجة الثنائية لا يمكن تنفيذ برامج دقيقة و رخيصة بسرعة؛ فالبرامج المعقدة تتطلب دائما مجهودا أكثر, و تنفيذ برامج بسيطة بسرعة دائما يؤثر على دقة و جودة هذه البرامج. و خلاصة هذه التجارب أن البرمجة الثنائية ليست دائمة هي الحل الأفضل لكل مشكلات البرمجة.

* المميزات

• البرامج الناتجة عند تطبيق أسلوب البرمجة الثنائية تُنفذ أسرع. و تكون أقصر, و أبسط, و أجود من ناحية التصميم الهندسي, و أكثر تنظيما مما يسهل تعديلها أو إصلاحها لاحقا, و تحتوي على أخطاء أو ثغرات برمجية bugs أقل, من نظيراتها الناتجة عن البرمجة الفردية.

• تتيح البرمجة الثنائية نقل الخبرات (سواء خبرات البرمجة العامة أو الخاصة بالبرنامج نفسه) بين المبرمجين.

• يمكن تطبيق البرمجة الثنائية بصورة خفيفة, حيث يمر كل مبرمج في فريق العمل على كل زملائه واحدا تلو الآخر ليعملا سويا بالطريقة الثنائية؛ و هذه الطريقة تفيد في نقل معلومات و خبرات الفريق بين بعضهم بعضا, و تقلل من تأثير ترك أحد المبرمجين للفريق.

• البرمجة الثنائية تساعد كلا المبرمجَين في التركيز و عدم تضييع وقت العمل. كما أن الناس عادة لا تقاطع من يظنون أنهم مجتمعون للعمل (كما في حالتنا حيث يجتمع اثنان من المبرمجين للعمل سويا) إلا للضرورة.

* العيوب

• بالرغم من أن البرمجة الثنائية تقلل من وقت تنفيذ البرنامج, إلا أنه بجمع وقتي المبرمجَين تكون محصلة الوقت المستغرق أعلى مما لو نفذ البرنامج مبرمج واحد. و هذا بالطبع بعني أن المجهود المبذول أكثر.

* متى تستخدمها؟

• عندما يكون البرنامج معقدا أو غير واضح المعالم أو يستلزم الكثير من الإبداع, فيتوقع تحسن في النتائج عند تطبيق البرمجة الثنائية.

• عند إدخال مبرمج جديد في الفريق, تكون هذه الطريقة مفيدة جدا في تسريع توافق فهم العضو الجديد للبرنامج و لطريقة عمل و تنظيم الفريق.

* متى تتجنبها؟

• عندما يكون البرنامج بسيطا و واضح المعالم لكلا المبرمجين, فإن تطبيق البرمجة الثنائية يؤدي إلى انخفاض في إنتاجية المبرمجين.

* نصائح

• قبل البدء, لا بد من تحديد هدف واضح يمكن إنهاؤه خلال ساعة أو ساعتين. و يفضل كتابته و كتابة الخطوط العريضة لتحقيقه.

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

• إذا كنت المراجع, فانتبه جيدا لما يكتبه زميلك, و حاول اكتشاف الأخطاء أو التغرات البرمجية bugs, و فكر في كيفية تبسيط و تحسين البرنامج. و لا تقاطع زميلك القائد كلما عنّ لك شيء - حتى لا تفقده تركيزه, بل دونه في ورقة, فإذا ما انتهي زميلك مما يكتب (على الأقل السطر الذي هو فيه), فأخبره عما عنّ لك. و ترفق بزميلك و لا تتهكم عليه إن بدا لك خطأ فيما يكتب. و تذكر أخيرا أن دور زميلك القائد ليس كتابة ما تمليه عليه حرفيا, فأخبره عما تريد و لا تشغل بالك بتفاصيل تحقيقه, فزميلك القائد مبرمج أيضا!

• تناقشا كثيرا حول الأفكار و البدائل و الثغرات المحتملة و كل ما من شأنه تحسين و تبسيط البرنامج. و يتبع حسنَ الكلام حسنُ الاستماع؛ فلا تنشغل عن زميلك - بالأكل مثلا - و هو يتحدث, بل أنصت جيدا لما يقول.
  

• إذا تاه أحدكما من الآخر فلم يعد يدري ما يحدث, فتوقفا ثم تأكدا أنكما تقفان على أرض واحدة (يعني عدتما لفهم بعضكما ثانية) ثم استكملا.

• في بعض الأحيان يكون من الأسهل أن يكتب المراجع جزءا في البرنامج بنفسه بدلا من أن يشرح وجهة نظره لزميله القائد ثم يقوم القائد بالكتابة, و لا بأس بذلك, بل يفضل أن يتبادل الزميلان الأدوار(القيادة و المراجعة) كل نصف ساعة أو ساعة مثلا؛ و بذلك لا يُرهق المراجع من كثرة التركيز, و لا يمل القائد من كثرة الكتابة.

• المبرمج الأقل علما بالبرنامج أو بلغة البرمجة (أو الأقل خبرة على العموم) يكون قائدا(يكتب على لوحة المفاتيح) أكثر من كونه مراجعا, فالمرء يتعلم من أصابعه أكثر مما يتعلم من عينيه!

* مصادر استفدت منها في كتابة هذه المقالة (مرتبة حسب الأهمية)

• مقالة البرمجة الثنائية على الويكيبيديا
  

• مقالة البرمجة الثنائية على الويكيهاو و هذه ترجمتها العربية

• مقالة للدكتورة هند خليفة في جريدة الرياض
  

---------------------------------------

[1] ملحوظة: النسب المقاسة بين وقت و مجهود مبرمج واحد أو اثنين لتنفيذ نفس البرنامج. و التغير في النسب تابع لتعقيد البرامج و خبرة المبرمجين.