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

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

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

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

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

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

auto-feed_screwdriver

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

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

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

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

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

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

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

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

Advertisements

اترك رد

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

WordPress.com Logo

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

صورة تويتر

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

Facebook photo

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

Google+ photo

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

Connecting to %s