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

السلام عليكم

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

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

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

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 مثل إسم خدمة ويب أو إجراء ضمنها أو حتى باراميتر وذلك لأنه إتفاق يجب عدم اﻹخلال به مع برامج أخرى تستخدم هذه اﻷسماء لتنفيذ تلك الدوال فإذا تم التغيير في هذه اﻷسماء فإن البرنامج المستفيدة من هذه الخدمات سوف تتوقف. كذلك عند كتابة مكتبة يتم استخدامها في أكثر من نظام أو منشورة في النت، فإن تغيير الدوال يجعل البرامج المعتمدة عليها ينتج عنها خطأ في حالة إعادة ترجمتها.

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

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

مبدأ الوظيفة الواحدة في البرمجة

السلام عليكم

هذه مقالة أخرى من سلسلة المباديء الصحيحة للبرمجة والتي تقع تحت دائرة هندسة البرمجيات. وتتكلم عن مبدأ الوظيفة أو المسؤولية الواحدة لوحدة الكود single responsibility principle.

الفكرة ببساطة هي أن يكون للوحدة من الكود هدف واحد من كتابتها، مثلاً أن تكون وحدة متخصصة في قراءة البيانات من قاعدة البيانات العلائقية، مثلاً نسميها access unit وأخرى متخصصة في واجهة المستخدم فنسميها presentation unit او class أو حتى Layer حسب التقسيم المتبع وحجم الوحدة المتخصصة. بهذا نكون قد جعلنا لكل وحدة سبباً واحداً للتغيير، مثلاً إذا كانت المهمة تغيير في واجهة المستخدم لايؤثر ذلك على طريقة قراءة المعلومات من قاعدة البيانات، وهذا يجعل الكود أسهل تعديلاً.

نأخذ مثال لإجراء به أكثر من وظيفة ثم نقوم بتصحيحه. والمثال مكتوب بلغة برمجة إفتراضية وليست من اللغات المعروفة، مهمته قراءة بيانات من جدول في قاعدة بيانات ثم عرضها في المتصفح:

function ReadAndDisplayTable
{
  connection = Connection("localhost", "MyData", "user", "password")

  dataset = connection.query("select * from students")

  html.print("<table><tr><th>ID</th><th>Name</th></tr>")
  for record in dataset
  {
    html.print("<tr>")
    html.print("<td>", record["id"], "</td>")

    html.print("<td>", record["name"], "</td>")
    html.print("</tr></table>")
  }
  connection.close

}

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

التصحيح هو أن نقوم بفصلهما  في إجرائين منفصلين، واﻷفضل أن تكون وحدات مختلفة، مثلاً كل واحد في مكتبة منفصلة أو class منفصلة تجمع نوع متشابه من الوظائف:

function ReadTable: Dataset
{
  connection = Connection("localhost", "MyData", "user", "password")

  dataset = connection.query("select * from students")
  connection.close
  retrn dataset
}

function displayTable(dataset: Dataset)
{

  html.print("<table><tr><th>ID</th><th>Name</th></tr>")

  for record in dataset
  {
    html.print("<tr>")
    html.print("<td>",record["id"],"</td>")
    html.print("<td>",record["name"],"</td>")
    html.print("</tr></table>")
  }
}

بهذه الطريقة يكون لدينا إجراء لقراءة البيانات فقط (readTable) وآخر لكتابته (displayTable) ونحقق أيضاً إعادة استخدام الكود، حيث يمكن استخدام اﻹجراء readTable في أي مكان آخر ليس له علاقة بإظهار البيانات في المتصفح، مثلاً لقرائتها ثم إرسالها بالبريد، كذلك يمكن نداء إجراء الكتابة في المتصفح بعد قراءة البيانات من ملف في القرص الصلب مثلاً.

هذه الطريقة تضمن كتابة كود واضح القراءة، سهل التعديل والصيانة، ومتعدد الإستخدام.

إضافة:
مبدأ الوظيفة الواحدة يُساهم في تسهيل اﻹختبار، حيث يمكن اختبار هذه الوحدة البرمجية بمعزل عن باقي الوحدات

الكتب كبديل للتلفاز

السلام عليكم ورحمة الله

مازلت إلى الآن – بفضل الله- متمسك بفكرة اﻹستغناء عن التلفاز من أجل أن يتربى أبنائي في بيئة مختلفة، بيئة علمية، وعملية ليس فيها أي إضاعة للوقت ، ليس فقط للأطفال، بل حتى لنا – نحن الكبار-  حيث أننا نحتاج إلى استغلال كل اﻷوقات في اﻷشياء المهمة فقط.

التلفاز يأخذ وقت كبير جداً من الناس منذ القدم، وعدم وجوده يترك فراغاً كبيراً لابد من ملائه بأشياء مفيدة، وليس شيئاً واحدا، حيث أن اﻷشياء المفيدة ربما يمل منها الناس، لذلك لابد من توفر أشياء متعددة يتنقل الشخص بينها للاستفادة من هذا الوقت الثمين.

تتطلب عرض الشرائح هذه للجافا سكريبت.

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

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

أدعو سكان الخرطوم ومن زارها بزيارة مكتبة الدار السودانية للكتب، وهي أكبر مكتبة في الشرق اﻷوسط وأفريقيا، والتي تكلمت عنها في تدوينة سابقة.

كل الأوقات مهمة

السلام عليكم ورحمة الله stopwatch

لعل العنوان هذه المرة يغني عن ذكري لأسباب تأخري وانقطاعي عن الكتابة، حيث أصبح الوقت هو من أهم الموارد لدي. وأريد نصيحة القراء ومن حولهم بأهمية الوقت. لا أقول لكم أدركوا اﻷوقات في الشباب قبل الهرم فحسب، لكن أقول لكم أدركوا أوقاتكم وأوقات أبنائكم منذ الصغر.

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

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

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

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

اختلاف نسبة النجاح بين شخص وآخر تعود إلى حد كبير إلى نجاح كل منهم لإدارته للوقت بصورة جيدة، فكل الناس لديهم تقريباً نفس المورد بالنسبة للوقت، فكما قال رسول الله صلى الله عليه وسلم ( أعمار أمتي ما بين الستين والسبعين، وأقلهم من يجوز ذلك) وهذا يعني أن اﻷعمار متقاربة، لكن ليس كل إنسان يستطيع التميز في هذا العمر القصير.

لا اريد أن أنصح الناس أن لا يضيعوا أوقاتهم في الفراغ وماليس به فائدة، هذه النصيحة تجاوزناها بفضل الله، اﻵن نحن في زمن السرعة وزيادة قيمة الوقت بصورة لا متناهية، فأنصح الناس أن لا يضيعوا أوقاتهم في اﻷعمال اﻷقل إنتاجاً، فلابد من زيادة التحدي بعد كل فترة لإنجاز أكبر في كل عام عن العام الذي سبقه، وإلا فنحن نقف في نفس النقطة لا نتحرك عنها.

لأهمية الوقت لا أريد تضييع أوقات القراء، فالموضوع ذو شجون، وأتمنى أن تكون الفكرة قد وصلت.

رحلتي إلى موريتانيا

السلام عليكم ورحمة الله

في نهاية الشهر الماضي سافرت في رحلة عمل إلى دولة موريتانيا، إلى مدينة نواكشوط، لفترة قصيرة، وقد كانت أول رحلة لي إلى غرب أفريقيا، بل إلى أقصى غرب أفريقيا، إلى شاطيء المحيط اﻷطلسي.

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

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

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

CIMG0017

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

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

ليبلغن هذا الأمر ما بلغ الليل والنهار، ولا يترك الله بيت مدر ولا وبر إلا أدخله الله هذا الدين بعز عزيز أو بذل ذليل، عزاً يعز الله به الإسلام، وذلاً يذل به الكفر

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

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

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

النزهة الوحيدة التي قمنا بها كانت بعد صلاة الجمعة إلى المحيط ، مع أنها كانت قصيرة جداً إلا أن المحيط كان لايوصف ولا يشبه البحر اﻷحمرالذي رأيته بضع مرات

تتطلب عرض الشرائح هذه للجافا سكريبت.

لست من كثيري اﻷسفار خصوصاً خارج بلدي، لكن رؤية مكان جديد وبعيد يأتي معه إحساس أن كل مكان آخر هو عالم في حد ذاته.

نسيت أن أذكر أن الجو كان عليلاً، مشبعاً بالرطوبة، في اﻷيام اﻷولى كان شديد البرد بالصباح والليل لكنه أخذ في اﻹعتدال في اﻷيام اﻷخيرة. كذلك فلا توجد مباني عالية تحجب الهواء أو رؤيتنا للسماء.

مبدأ البساطة في البرمجة

السلام عليكم ورحمة اللهscrew_driver

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

بساطة اﻷدوات، والتصميم، وبساطة اﻵلات، بل وحتى بساطة العبارات، والخطب، والمقالات، والنظريات، وغيرها من اﻷشياء الملموسة وغير الملموسة في حياتنا هي من المفاهيم التي تهدف وتحقق الآتي:

  1. اختيار الآلية الأبسط لتحقيق هدف ما
  2. اﻷكثر بساطة هو اﻷكثر إعتماداً
  3. البساطة تقلل التكلفة اﻹبتدائية وتكلفة التعديل والتطوير وتكلفة التشغيل
  4. البساطة تسّهل فهم اﻵخرين للأمر المراد تنفيذه ومشاركتهم في إنجازه

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

auto-feed_screwdriver

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

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

البساطة تساهم في الفهم السريع لأعضاء الفريق لآلية الحل وبالتالي تسمح لهم بالمساهمة الفعلية واﻹستمرار واﻹنتشار بهذا المشروع بدلاً من أن يكون لغزاً محتكراً لصاحب الفكرة فقط.

بالنسبة لتطوير البرامج فإنها اصبحت معقدة، فإبتداءً بأنظمة التشغيل إلى لغات البرمجة وحتى المتصفحات، ناهيك عن عدم ذكر العتاد وماوصل إليه من تطور. كلها أصبح فيها تعقيد، مثلاً المتصفحات أصبح بها مترجمات للغات برمجة مثل جافا سكريبت. والإتجاه اﻵن هو للبساطة، بأن تطرق المثلى لكتابة البرامجكون لدينا لغات أبسط، وأنظمة أبسط ومحركات قواعد بيانات أبسط. نعني أبسط من ناحية التصميم الداخلي وحتى من حيث اﻹمكانات. فيمكن لأدوات ذات إمكانات أقل أن تنافس اﻷدوات المعقدة. وهناك مفهموم أو نظرية في هندسة البرمجيات قرأتها مؤخراً أعجبتني كثيراً  تقول worse is better، أي اﻷسواء هو اﻷفضل، ويُعنى باﻷسواء هو اﻷقل ميزات. فإذا كُنت تريد كتابة نص بسيط فإن اﻷفضل هو اﻷدوات الأبسط مثلاً nano في نظام لينكس أو Notepad بدلاً من كتابة ذلك النص باستخدام أدوات أعقد مثل حزمة office، نكتب بها سطر أو سطرين نصيين ثم نبحث كيف نقوم بتحويله إلى شكل مقروء لكل اﻷنظمة. أما إذا كتبناه بتلك اﻷدوات البسيطة فالناتج هو ملف نصي يمكن قرائته في كل أنظمة التشغيل وكل المعماريات ويمكن قرائته كذلك بجميع لغات البرمجة. تخيل أنك مبرمج وتم إرسال بيانات مرجعية لإعتمادها في برنامج ما، فأيهما تختار: أن تكون تلك البيانات في شكل ملف word أم excel تحتاج لمكتبة لقرائته وقراءة نسقه المعقد ثم اسنتباط المعلومات اﻷساسية منه، أم تتمنى أن يكون ملفاً نصياً بسيطاً خالياً من أي نسق يستطيع عمل برنامج لقرائته طالب في بداية طريقة لدارسة لغة برمجة.

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

في دورة حياة أي برنامج، يبدأ بسيطاً ثم يتعقد ليلبي كافة اﻹحتياجات للزبائن المختلفين، فإذا زاد تعقيده من ناحية تصميمه الداخلي يشيخ ذلك البرنامج ويُحال للتعاقد لأن التطوير فيه يزيد صعوبة وبالتالي تزيد ميزانية تطويره، فيكون الحل هو عمل بديل له بطريقة أبسط بتصميم نظيف clean design. فإذا بدأت بنظام بتصميم ومتطلبات معقدة فإنك بذلك تحيله إلى المعاش مبكراً. أما إذا بدأ بسيطاً وحافظ على هذه البساطة فهذا يزيد من عمره التشغيلي ويكون قليل المشاكل البرمجية ولديه فرصة أكبر ليعمل على نطاق أوسع من المستفيدين – على اﻷقل المستفيدين الذين يحبون البساطة-.

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

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

التطور الطبيعي للمبرمج: العام السادس

السلام عليكم ورحمة اللهprogramming

بفضل الله هذا هو العام السادس للإجابة على سؤال ماهو التطور الطبيعي للمبرمج والذي طرحته عام 2011.

عام 2015 كان مثل سابقه فيه توجه أكثر للإدارة مع اﻹستمرار في تطوير البرامج والإشراف على بعضها، مع زيادة التركيز على تسويق بعض منتجاتنا.

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

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

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

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

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

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

في الآونة اﻷخيرة أصبح لدي شغف حول الشبكات بدأت بمشكلة في أحد برامج الويب التي طورناها حيث حدث اختناق في الشبكة، فقمت بشراء كتاب عن الشبكات اسمه the art of computer networking وهو كتاب رائع تكلمت عنه في تدوينة سابقة. لكن هذا العام طلب مني المبرمجون أن أقوم بتدريسهم الشبكات بشكل عملي حيث لايرغبون في حضور كورس أكاديمي مطول وهم لديهم خبرة جيدة في الشبكات لكنهم يريدون تطويرها، فقمت بعقد ورشة ليوم واحد تجمع بين العملي واﻷكاديمي، حيث قمنا بتغطية مفهوم الشبكات وطبقات الـTCP  والفرق بين البروتوكولات المختلفة، و وظيفة كل طبقة، ثم قمنا بعمل تجارب عملية إبتداءً بتوصيل جهازين بكيبل، ثم استخدام switch للربط بين اﻹجهزة ثم استخدام router وربط أكثر من شبكة وعمل NAT و port forwarding، ثم انتهت عن الكلام عن الـ socket وعمل تجارب محادثة بين جهازين.

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

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