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