الفصل الثاني: الطريق إلى العملية
يوجد العديد من الطرق والنصائح التي يمكن أن تساعدنا في عملية تطوير البرامج أو بناء المشاريع، وقلما تجد من يتكلم عن هذه الطرق ولذلك سنقوم بالتطرق إليهم في هذا الفصل.
سنتحدث في هذا الفصل عن "ضرر التكرار" الذي نحذرك فيه من خطر تكرار المعلومات في برنامجك و "التعامد" الذي نحذر فيه من تقسيم المعلومة الواحدة في عدة أجزاء من البرنامج.
في "قابلية العكس" سنتحدث عن كيفية الحفاظ على برنامجك بشكل مستقر خلال نموه ، وفي "طلقات العلّام" سنتحدث عن كيفية جمع المعلومات، الاختبار وكتابة البرنامج في نفس الوقت. طلقات العلّام لا تغني عن "التصميم الأولي والملاحظات الصغيرة" التي تفيد في اختبار الهيكلية، والخوارزميات، والواجهات والأفكار للبرنامج ، وأخيراً كلنا نعمل في عالم محدود الوقت والإمكانيات لذلك يجب أن نعطيك أساسيات "التقييم".
هذه المبادىء ستفيدك كثيراً بتسريع التطوير، تسهيل العملية برمتها وتقوية مهاراتك.
* الفصل الأول: "ضرر التكرار"
كمبرمجين يجب علينا جمع وتنسيق المعلومات للبرنامج، ومن ثم تطبيق هذه المعلومات على هيئة شيفرة مصدرية لتخرج لنا على هيئة برنامج قابل للاستخدام.
ولكن المعطيات والمعلومات تتغير دائم سواء أردنا ذلك أم لا، والتحدي الحقيقي هو بتطبيق هذه التغييرات على برنامجك مما يجعل عملية التطوير تستغرق أضعاف المدة والتسبب بأخطاء كثيرة.
معظم الناس يعتقدون بأن صيانة البرنامج (تتبع الأخطاء والتجريب) تبدأ حين الانتهاء من البرنامج، ولكن هؤلاء الناس على خطأ لأنه كما ذكرنا المعلومات وخصائص البرنامج تتغير بشكل يومي وهذا مايجعل مرحلة الصيانة غير منفصلة عن كتابة البرنامج ويجب أن تكتب بشكل متوازي مع التطوير لا بعده.
عملية الصيانة تكشف لنا أخطاء البرنامج وثغراته ومن أخطر الأخطاء تكرار المعلومات في أجزاء البرنامج وهذا ما يقودنا إلى مبدأ (DRY).
النصيحة 11: (DRY) لا تكرر نفسك
بكلام آخر وجود الشيء نفسه في مكانيين مختلفين أو أكثر. فعندما تغير أحدهم يجب أن تتذكر كل الأماكن التي يوجد فيها هذا الشيء وتغيره في كل هذه الأماكن. بالطبع هذا ليس بالحل المناسب ولكن يجب أن نلغي هذا التكرار.
أسباب ظهور التكرار:
- التكرار الإجباري: المطور يجد نفسه مضطراً للتكرار إذ أن البرنامج يتطلب هذا.
- التكرار الإهمالي: المطور لا يدرك بأنه يكرر نفسه.
- التكرار الاستعجالي: المطور يكرر المعلومة كسلاً، كي لايضطر للتفكير بحل دائم.
- التكرار المتداخل بين المطورين: في حال وجود العديد من المطورين يظهر التكرار بينهم.
هذا مجرد ملخص لهذه الأسباب أما التفصيل:
- التكرار الإجباري: أحياناً تجد نفسك مضطراً لهذا فمثلاً برنامج يعمل على عدة منصات وأحياناً لغة البرمجة تضطرك للتكرار ولحل هذا النوع من التكرار يوجد عدة نصائح:
- تكرار المعلومات: عندما تكتب برنامج "مخدم-عميل" وبلغتين مختلفتين لكل جهة تجد نفسك مضطراً لتكرار نفس المعلومة في هاتين اللغتين والجهتين. ربما للتعامل مع قاعدة البيانات فكل لغة تتطلب شكلاً مختلفاً للتعامل معها والحل لهذه المشكلة هو بكتابة مولد بسيط للشيفرة المصدرية، فمواصفات الصنف الذي يتعامل مع قاعدة البيانات يتم تعبئته من قاعدة بيانات خاصة بهذا المولد مما يعطيك المجال لكتابة الصنف ذاته بمواصفات مختلفة في كل مرة (سنتطرق لهذا الموضوع بالتفصيل في آخر الفصل الثالث).
- التوثيق: التوثيق مهمة متعبة وغالباً ما نوثق علمنا بعد أن ننتهي من كتابة الشيفرة المصدرية. الطريقة الأسلم والأسهل هي بكتابة التوثيق على شكل تعليقات ثم كتابة الشيفرة المصدرية. هذه الطريقة تمنحك وقتاً للتفكير بكيفية تصميم البرنامج، فعند كتابة التوثيق ستفكر ببنية ما ومن ثم تراجعها بعد قراءتك للتوثيق حتى تصل للبنية الأفضل أما في حالة كتابتك للشيفرة المصدرية فوراً فغالباً لن تفكر ببنية البرنامج كثيراً بل ستبدأ بالكتابة فوراً. أيضاً يمكنك الاستعانة بأدوات جاهزة لتوليد المستندات برمجياً من تلك التعليقات وبهذه الحالة لن تضطر لكتابة المستندات من الصفر.
- لغات البرمجة: العديد من لغات البرمجة تتطلب تكرار الشيفرة المصدرية (مثلاً في السي C يوجد ملفات الهيدر التي نكتب فيها نفس أسماء التوابع والمتحولات). حل هذه المشكلة معقد نوعاً ما، أحياناً تجد بيئة تطوير تكتب ملفات الهيدر أتوماتيكياً ولكن في الحالات العادية تستطيع استغلال ملفات الهيدر للتعليق بشكل ملخص، وملفات الشيفرة المصدرية الرئيسية للتعليقات المفصلة.
- التكرار الإهمالي: في بعض الحالات لا تدرك بأنك تكرر نفس المعلومات ؛ والسبب هو أخطاء في تصميم بنية البرنامج، حل هذه المشكلة هو باستخدام البرمجة الكائنية ، وبمراجعة التصميم أكثر من مرة.
- التكرار الاستعجالي: غالباً عند الاقتراب من موعد التسليم نقوم بالاستعجال وبكتابة الكثير من الاختصارات، تضطر لنسخ بعض الشيفرات القديمة والتعديل عليها بسرعة. ربما هذه الطرق ستوفر عليك بعض الدقائق ولكن بالتأكيد ستكلفك أياماً في مابعد. ضع لنفسك خط أحمر ولاتتجاوزه بهذه الطريقة حتى ولو تأخرت في التسليم.
- التكرار المتداخل بين المطورين: أصعب نوع من أنواع التكرار هو الذي يحدث في فريق من المطورين، حيث يكتب أحدهم بعض التوابع ويقوم آخر بكتابة نفس هذه التوابع بدون أن يعلم أن الأول قد كتبهم. يوجد قصة طريفة لهذا التكرار وهو أن الأجهزة الحكومية في الولايات المتحدة الأمريكية خضعت لفحص (Y2K) واكتشفوا أكثر من 10 آلاف نسخة مختلفة من برنامج التحقق من رقم الضمان الاجتماعي! لحل هذه المشكلة يجب أن يكون لديك تحليل قوي وواضح للبرنامج، رئيس الفريق البرمجي يجب أن يكون خبيراً ، وأن يكون هناك تواصل دائم بين المطورين. ودائماً اكتب البرامج على أساس إعادة الاستخدام أي إعادة استخدامها في مشاريع لاحقة (هذا المبدأ مطبق في نظام التشغيل لينكس).
النصيحة 12: اجعل البرنامج قابل لإعادة الاستخدام.
* الفصل الثاني: التعامد
مفهوم التعامد في البرمجة مختلف عن المفهوم الهندسي، فهنا يعني استقلال الشيء عن غيره. أي التغيير في غيره لا يؤثر عليه. مثلاً تغيير قاعدة البيانات لا يؤثر بواجهات البرنامج والعكس أيضاً.
النصيحة 13: افصل العلاقات قدر الإمكان بين الأصناف أو التوابع الغير مرتبطة مع بعضها.
فوائد التعامد كثيرة ومنها:
- التأثيرات محدودة: لن تتفاجئ عند تغيرك لشيء ما في الغرب بخطأ في الشرق! هذا يجعل البرنامج منطقي والأخطاء غير المتوقعة قليلة.
- إعادة الاستخدام: من فوائد التعامد أننا نستطيع استخدام الأصناف أو التوابع في برامج كثيرة. فبما أن الصنف مستقل بذاته إذاً نستطيع صنع مكتبة صغيرة من هذه الأصناف المستقلة عن بعضها.
- التغيير على أحد الأصناف لايؤثر على صنف آخر، هذه الميزة توفر عليك ساعات من التعديلات والإصلاحات.
تصميم وتحليل البرنامج أساس كل شيء، والتصميم المتعامد هو الذي يعتمد على مبدأ الطبقات أو الأجزاء. وتصميم الطبقات تصميم قوي ومتين يعتمد على فصل كل طبقة خاصة بمهمة معينة لوحدها. ومن أشهر تصميم الطبقات تصميم MVC المتبع الآن في عالم الويب.
التعامد شيء مهم جداً في مشاريعك ويجب دائماً أن تسير على هذا المنهج وإلا ستتعرض لمشاكل أنت بغنى عنها!
* الفصل الثالث: قابلية العكس
في بعض الأحيان تعتمد على نظام قواعد بيانات معين وتبدأ بالتطوير بناء عليه ثم تفاجأ بنصف الطريق أن قرارك كان خاطئاً، إما أنه يوجد نظام أفضل أو النظام الحالي لم يعد يلبي متطلباتك من حيث الأداء أو الفعالية. ما الحل؟ هل تكمل بالمشروع مع إزالة بعض ميزات البرنامج التي لا تستطيع تطبيقها؟
الحل هو بالتغيير للأفضل وعدم أخذ القرارات السابقة على أنها دستور! حتى ولو أضعتم الكثير من الوقت على نظام قواعد البيانات الحالي فهذا ليس بعذر.
النصيحة 14: لا يوجد قرارات نهائية غير قابلة للتغيير
* الفصل الرابع: طلقات العلّام
يوجد طريقتين لإطلاق رصاصة في الظلام، الأولى هي بحساب الزوايا والأبعاد وسرعة الهواء ثم إطلاقها، او الطريقة الأسهل هي باستخدام طلقات العلّام (هي عبارة عن طلقات تحتوي على مادة الفسفور بحيث تترك خلفها خطاً ظاهراً لمسارها).
نفس الشيء ينطبق على تطوير المشاريع غير الواضحة أي التي لم تطور مثلها من قبل. فأنت تقوم بحساب كل شيء ولكن لا تدري هل ستصل في النهاية إلى نتيجة مرضية أم لا، لذلك نحن نفضل استخدام طلقات العلّام في هذه الحالة.
النصيحة 15: حاول دائماً استخدام طلقات العلّام لكشف الهدف
في إحدى المرات تعرضنا لتطوير برنامج من أعقد البرامج، فالبرنامج مخدم/عميل، فالمخدم كان عبارة عن بنية معقدة من قواعد البيانات المختلفة. واجهة العميل كانت مبنية بالـ (Object Pascal) وأيضاً عدة مكتبات سي (C). الاستعلامات كانت مخزنة على المخدم ببنية شبيهة بالـ (Lisp) ثم حولت للـ (SQL).
هذه كانت فرصتنا لاستخدام طلقات العلّام، قمنا ببناء إطار عمل لتلقين هذا البرنامج استعلامات مختلفة من قاعدة البيانات ومشاهدة كيفية معالجة البرنامج لها وعرضها في واجهة العميل. خلال شهر أزلنا معظم البنية القديمة واستبدلناها بآخرى جديدة مع الإبقاء على طلقات العلّام لمشاهدة النتائج.
* الفصل الخامس: التصميم الأولي والملاحظات الصغيرة
العديد من الصناعات تستخدم التصاميم الأولية. لعل أشهرها هي صناعة السيارات ففي البداء يقومون بعمل نموذج خشبي أو بلاستيكي ثم وبعد الكثير من التعديلات يقومون بتنفذ هذا النموذج. التصميم الأولي يخفف الكلفة ويسمح بإدخال الكثير من التعديلات.
التصميم الأولي في عالم البرامج هو بصناعة واجهة مستخدم بالرسام أو برسمها على ورقة ثم برمجتها وإضافة بعض التوابع البسيطة للتفاعل مع المستخدم وإضافة بعض البيانات التجريبية.
النصيحة 16: اصنع تصميماً أولياً لتتعلم منه
* الفصل السادس: أساسيات التقييم
كم من الوقت نحتاج لنقل 100 ميجابايب إلى جهاز موصول بالشبكة؟ كم من الوقت نحتاج لتحميل برنامج كبير من الإنترنت؟ كم شهراً نحتاج لإتمام المشروع؟
للوهلة الأولى تظن أن هذه الأسئلة عديمة النفع ولكن مع الأيام ستتعلم أن هذه الأسئلة مهمة جداً.
النصيحة 17: التقييم مهم لتجنب المفاجآت
التقييم يختلف من حالة لحالة، فمثلاً العدد الرياضي p إذا اردت إخبار قيمته لطفل صغير فتخبره بأن قيمته 3 أما عند حل مسألة رياضية فتضع القيمة 3.14 وفي حالة تصميم لصاروخ فبالتأكيد ستأخذ العدد p مع 12 خانة على يمين الفاصلة للدقة.
ماعلاقة هذا الشيء بتقييم المشاريع؟! له علاقة كبيرة فمثلاً عند تسليم مشروع صغير فيجب أن تضع المدة بدقة (مثلاً 12 يوم) أما عند تسليم مشروع كبير فتضع المدة بدقة قليلة (6 أشهر تقريبا) ً.
أهم شيء في التقييم هو أن تفهم المشروع جيداً وأيضاً عامل الخبرة يلعب دوراً كبيراً في التقييم فغالباً ماتحدث مفاجآت غير متوقعة أو أعطال مفاجأة فهنا عامل الخبرة يلعب دوره ويعلمك كيفية التعامل بشكل صحيح مع هذه المفاجآت.
معد التلخيص : خالد الحوراني
يوجد العديد من الطرق والنصائح التي يمكن أن تساعدنا في عملية تطوير البرامج أو بناء المشاريع، وقلما تجد من يتكلم عن هذه الطرق ولذلك سنقوم بالتطرق إليهم في هذا الفصل.
سنتحدث في هذا الفصل عن "ضرر التكرار" الذي نحذرك فيه من خطر تكرار المعلومات في برنامجك و "التعامد" الذي نحذر فيه من تقسيم المعلومة الواحدة في عدة أجزاء من البرنامج.
في "قابلية العكس" سنتحدث عن كيفية الحفاظ على برنامجك بشكل مستقر خلال نموه ، وفي "طلقات العلّام" سنتحدث عن كيفية جمع المعلومات، الاختبار وكتابة البرنامج في نفس الوقت. طلقات العلّام لا تغني عن "التصميم الأولي والملاحظات الصغيرة" التي تفيد في اختبار الهيكلية، والخوارزميات، والواجهات والأفكار للبرنامج ، وأخيراً كلنا نعمل في عالم محدود الوقت والإمكانيات لذلك يجب أن نعطيك أساسيات "التقييم".
هذه المبادىء ستفيدك كثيراً بتسريع التطوير، تسهيل العملية برمتها وتقوية مهاراتك.
* الفصل الأول: "ضرر التكرار"
كمبرمجين يجب علينا جمع وتنسيق المعلومات للبرنامج، ومن ثم تطبيق هذه المعلومات على هيئة شيفرة مصدرية لتخرج لنا على هيئة برنامج قابل للاستخدام.
ولكن المعطيات والمعلومات تتغير دائم سواء أردنا ذلك أم لا، والتحدي الحقيقي هو بتطبيق هذه التغييرات على برنامجك مما يجعل عملية التطوير تستغرق أضعاف المدة والتسبب بأخطاء كثيرة.
معظم الناس يعتقدون بأن صيانة البرنامج (تتبع الأخطاء والتجريب) تبدأ حين الانتهاء من البرنامج، ولكن هؤلاء الناس على خطأ لأنه كما ذكرنا المعلومات وخصائص البرنامج تتغير بشكل يومي وهذا مايجعل مرحلة الصيانة غير منفصلة عن كتابة البرنامج ويجب أن تكتب بشكل متوازي مع التطوير لا بعده.
عملية الصيانة تكشف لنا أخطاء البرنامج وثغراته ومن أخطر الأخطاء تكرار المعلومات في أجزاء البرنامج وهذا ما يقودنا إلى مبدأ (DRY).
النصيحة 11: (DRY) لا تكرر نفسك
بكلام آخر وجود الشيء نفسه في مكانيين مختلفين أو أكثر. فعندما تغير أحدهم يجب أن تتذكر كل الأماكن التي يوجد فيها هذا الشيء وتغيره في كل هذه الأماكن. بالطبع هذا ليس بالحل المناسب ولكن يجب أن نلغي هذا التكرار.
أسباب ظهور التكرار:
- التكرار الإجباري: المطور يجد نفسه مضطراً للتكرار إذ أن البرنامج يتطلب هذا.
- التكرار الإهمالي: المطور لا يدرك بأنه يكرر نفسه.
- التكرار الاستعجالي: المطور يكرر المعلومة كسلاً، كي لايضطر للتفكير بحل دائم.
- التكرار المتداخل بين المطورين: في حال وجود العديد من المطورين يظهر التكرار بينهم.
هذا مجرد ملخص لهذه الأسباب أما التفصيل:
- التكرار الإجباري: أحياناً تجد نفسك مضطراً لهذا فمثلاً برنامج يعمل على عدة منصات وأحياناً لغة البرمجة تضطرك للتكرار ولحل هذا النوع من التكرار يوجد عدة نصائح:
- تكرار المعلومات: عندما تكتب برنامج "مخدم-عميل" وبلغتين مختلفتين لكل جهة تجد نفسك مضطراً لتكرار نفس المعلومة في هاتين اللغتين والجهتين. ربما للتعامل مع قاعدة البيانات فكل لغة تتطلب شكلاً مختلفاً للتعامل معها والحل لهذه المشكلة هو بكتابة مولد بسيط للشيفرة المصدرية، فمواصفات الصنف الذي يتعامل مع قاعدة البيانات يتم تعبئته من قاعدة بيانات خاصة بهذا المولد مما يعطيك المجال لكتابة الصنف ذاته بمواصفات مختلفة في كل مرة (سنتطرق لهذا الموضوع بالتفصيل في آخر الفصل الثالث).
- التوثيق: التوثيق مهمة متعبة وغالباً ما نوثق علمنا بعد أن ننتهي من كتابة الشيفرة المصدرية. الطريقة الأسلم والأسهل هي بكتابة التوثيق على شكل تعليقات ثم كتابة الشيفرة المصدرية. هذه الطريقة تمنحك وقتاً للتفكير بكيفية تصميم البرنامج، فعند كتابة التوثيق ستفكر ببنية ما ومن ثم تراجعها بعد قراءتك للتوثيق حتى تصل للبنية الأفضل أما في حالة كتابتك للشيفرة المصدرية فوراً فغالباً لن تفكر ببنية البرنامج كثيراً بل ستبدأ بالكتابة فوراً. أيضاً يمكنك الاستعانة بأدوات جاهزة لتوليد المستندات برمجياً من تلك التعليقات وبهذه الحالة لن تضطر لكتابة المستندات من الصفر.
- لغات البرمجة: العديد من لغات البرمجة تتطلب تكرار الشيفرة المصدرية (مثلاً في السي C يوجد ملفات الهيدر التي نكتب فيها نفس أسماء التوابع والمتحولات). حل هذه المشكلة معقد نوعاً ما، أحياناً تجد بيئة تطوير تكتب ملفات الهيدر أتوماتيكياً ولكن في الحالات العادية تستطيع استغلال ملفات الهيدر للتعليق بشكل ملخص، وملفات الشيفرة المصدرية الرئيسية للتعليقات المفصلة.
- التكرار الإهمالي: في بعض الحالات لا تدرك بأنك تكرر نفس المعلومات ؛ والسبب هو أخطاء في تصميم بنية البرنامج، حل هذه المشكلة هو باستخدام البرمجة الكائنية ، وبمراجعة التصميم أكثر من مرة.
- التكرار الاستعجالي: غالباً عند الاقتراب من موعد التسليم نقوم بالاستعجال وبكتابة الكثير من الاختصارات، تضطر لنسخ بعض الشيفرات القديمة والتعديل عليها بسرعة. ربما هذه الطرق ستوفر عليك بعض الدقائق ولكن بالتأكيد ستكلفك أياماً في مابعد. ضع لنفسك خط أحمر ولاتتجاوزه بهذه الطريقة حتى ولو تأخرت في التسليم.
- التكرار المتداخل بين المطورين: أصعب نوع من أنواع التكرار هو الذي يحدث في فريق من المطورين، حيث يكتب أحدهم بعض التوابع ويقوم آخر بكتابة نفس هذه التوابع بدون أن يعلم أن الأول قد كتبهم. يوجد قصة طريفة لهذا التكرار وهو أن الأجهزة الحكومية في الولايات المتحدة الأمريكية خضعت لفحص (Y2K) واكتشفوا أكثر من 10 آلاف نسخة مختلفة من برنامج التحقق من رقم الضمان الاجتماعي! لحل هذه المشكلة يجب أن يكون لديك تحليل قوي وواضح للبرنامج، رئيس الفريق البرمجي يجب أن يكون خبيراً ، وأن يكون هناك تواصل دائم بين المطورين. ودائماً اكتب البرامج على أساس إعادة الاستخدام أي إعادة استخدامها في مشاريع لاحقة (هذا المبدأ مطبق في نظام التشغيل لينكس).
النصيحة 12: اجعل البرنامج قابل لإعادة الاستخدام.
* الفصل الثاني: التعامد
مفهوم التعامد في البرمجة مختلف عن المفهوم الهندسي، فهنا يعني استقلال الشيء عن غيره. أي التغيير في غيره لا يؤثر عليه. مثلاً تغيير قاعدة البيانات لا يؤثر بواجهات البرنامج والعكس أيضاً.
النصيحة 13: افصل العلاقات قدر الإمكان بين الأصناف أو التوابع الغير مرتبطة مع بعضها.
فوائد التعامد كثيرة ومنها:
- التأثيرات محدودة: لن تتفاجئ عند تغيرك لشيء ما في الغرب بخطأ في الشرق! هذا يجعل البرنامج منطقي والأخطاء غير المتوقعة قليلة.
- إعادة الاستخدام: من فوائد التعامد أننا نستطيع استخدام الأصناف أو التوابع في برامج كثيرة. فبما أن الصنف مستقل بذاته إذاً نستطيع صنع مكتبة صغيرة من هذه الأصناف المستقلة عن بعضها.
- التغيير على أحد الأصناف لايؤثر على صنف آخر، هذه الميزة توفر عليك ساعات من التعديلات والإصلاحات.
تصميم وتحليل البرنامج أساس كل شيء، والتصميم المتعامد هو الذي يعتمد على مبدأ الطبقات أو الأجزاء. وتصميم الطبقات تصميم قوي ومتين يعتمد على فصل كل طبقة خاصة بمهمة معينة لوحدها. ومن أشهر تصميم الطبقات تصميم MVC المتبع الآن في عالم الويب.
التعامد شيء مهم جداً في مشاريعك ويجب دائماً أن تسير على هذا المنهج وإلا ستتعرض لمشاكل أنت بغنى عنها!
* الفصل الثالث: قابلية العكس
في بعض الأحيان تعتمد على نظام قواعد بيانات معين وتبدأ بالتطوير بناء عليه ثم تفاجأ بنصف الطريق أن قرارك كان خاطئاً، إما أنه يوجد نظام أفضل أو النظام الحالي لم يعد يلبي متطلباتك من حيث الأداء أو الفعالية. ما الحل؟ هل تكمل بالمشروع مع إزالة بعض ميزات البرنامج التي لا تستطيع تطبيقها؟
الحل هو بالتغيير للأفضل وعدم أخذ القرارات السابقة على أنها دستور! حتى ولو أضعتم الكثير من الوقت على نظام قواعد البيانات الحالي فهذا ليس بعذر.
النصيحة 14: لا يوجد قرارات نهائية غير قابلة للتغيير
* الفصل الرابع: طلقات العلّام
يوجد طريقتين لإطلاق رصاصة في الظلام، الأولى هي بحساب الزوايا والأبعاد وسرعة الهواء ثم إطلاقها، او الطريقة الأسهل هي باستخدام طلقات العلّام (هي عبارة عن طلقات تحتوي على مادة الفسفور بحيث تترك خلفها خطاً ظاهراً لمسارها).
نفس الشيء ينطبق على تطوير المشاريع غير الواضحة أي التي لم تطور مثلها من قبل. فأنت تقوم بحساب كل شيء ولكن لا تدري هل ستصل في النهاية إلى نتيجة مرضية أم لا، لذلك نحن نفضل استخدام طلقات العلّام في هذه الحالة.
النصيحة 15: حاول دائماً استخدام طلقات العلّام لكشف الهدف
في إحدى المرات تعرضنا لتطوير برنامج من أعقد البرامج، فالبرنامج مخدم/عميل، فالمخدم كان عبارة عن بنية معقدة من قواعد البيانات المختلفة. واجهة العميل كانت مبنية بالـ (Object Pascal) وأيضاً عدة مكتبات سي (C). الاستعلامات كانت مخزنة على المخدم ببنية شبيهة بالـ (Lisp) ثم حولت للـ (SQL).
هذه كانت فرصتنا لاستخدام طلقات العلّام، قمنا ببناء إطار عمل لتلقين هذا البرنامج استعلامات مختلفة من قاعدة البيانات ومشاهدة كيفية معالجة البرنامج لها وعرضها في واجهة العميل. خلال شهر أزلنا معظم البنية القديمة واستبدلناها بآخرى جديدة مع الإبقاء على طلقات العلّام لمشاهدة النتائج.
* الفصل الخامس: التصميم الأولي والملاحظات الصغيرة
العديد من الصناعات تستخدم التصاميم الأولية. لعل أشهرها هي صناعة السيارات ففي البداء يقومون بعمل نموذج خشبي أو بلاستيكي ثم وبعد الكثير من التعديلات يقومون بتنفذ هذا النموذج. التصميم الأولي يخفف الكلفة ويسمح بإدخال الكثير من التعديلات.
التصميم الأولي في عالم البرامج هو بصناعة واجهة مستخدم بالرسام أو برسمها على ورقة ثم برمجتها وإضافة بعض التوابع البسيطة للتفاعل مع المستخدم وإضافة بعض البيانات التجريبية.
النصيحة 16: اصنع تصميماً أولياً لتتعلم منه
* الفصل السادس: أساسيات التقييم
كم من الوقت نحتاج لنقل 100 ميجابايب إلى جهاز موصول بالشبكة؟ كم من الوقت نحتاج لتحميل برنامج كبير من الإنترنت؟ كم شهراً نحتاج لإتمام المشروع؟
للوهلة الأولى تظن أن هذه الأسئلة عديمة النفع ولكن مع الأيام ستتعلم أن هذه الأسئلة مهمة جداً.
النصيحة 17: التقييم مهم لتجنب المفاجآت
التقييم يختلف من حالة لحالة، فمثلاً العدد الرياضي p إذا اردت إخبار قيمته لطفل صغير فتخبره بأن قيمته 3 أما عند حل مسألة رياضية فتضع القيمة 3.14 وفي حالة تصميم لصاروخ فبالتأكيد ستأخذ العدد p مع 12 خانة على يمين الفاصلة للدقة.
ماعلاقة هذا الشيء بتقييم المشاريع؟! له علاقة كبيرة فمثلاً عند تسليم مشروع صغير فيجب أن تضع المدة بدقة (مثلاً 12 يوم) أما عند تسليم مشروع كبير فتضع المدة بدقة قليلة (6 أشهر تقريبا) ً.
أهم شيء في التقييم هو أن تفهم المشروع جيداً وأيضاً عامل الخبرة يلعب دوراً كبيراً في التقييم فغالباً ماتحدث مفاجآت غير متوقعة أو أعطال مفاجأة فهنا عامل الخبرة يلعب دوره ويعلمك كيفية التعامل بشكل صحيح مع هذه المفاجآت.
معد التلخيص : خالد الحوراني
disqus