SyntaxHighlighter

الأحد، 1 مايو 2011

صنعة البرمجة – Software Craftsmanship

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

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

لذلك اجتاح عالم تطوير البرمجيات أساليب جديدة للإدارة تتحدى نظم الثورة الصناعية وتعيد للعامل البشري مركزيته. وكان هذا جليا في إعلان المبادئ للأجايل Agile Manifesto والذي قدم أفكرا ثورية لطرق تنظيم العمل إلا أن نجاحه الهائل في تقديم برمجيات بجودة أعلى أجبر شركات عريقة في الإدارة التقليدية إلى تبنى هذه الأساليب. ويقوم الأجايل على أربعة مبادي أساسية توضح الفلسفة العامة للإدارة والتطوير. هذه المبادئ هي http://agilemanifesto.org/iso/ar:

إننا نكشف النقاب عن طرق أفضل لتطوير البرمجيات
وذلك من خلال تطبيقها ومساعدة الآخرين على ذلك.
وعبر هذا العمل توصلنا إلى اعتبار:

الأفراد وتعاملهم فيما بينهم فوق المنظومات والأدوات
البرمجيات الصالحة للاستعمال فوق التوثيق الكامل
تعاون ومشاركة العميل فوق التفاوض حول العقد
الاستجابة للتغييرات فوق الالتزام بمخطط عمل محدد

ويعني ذلك أنه على الرغم من كون العناصر على الجانب الأيسر ذات قيمة،
فإننا نعطي قيمة أكبر للعناصر على الجانب الأيمن.

تفرع من هذه المبادئ العديد من منظومات العمل مثل Scrum و XP و KanBan والتي تختلف فيما بينها في عدد القواعد التي تحددها والأدوار التي تتطلبها إلا أنها تتفق فيما بينها على تعظيم التواصل والعمل في إطار يكون الفريق وحدة واحدة تتحدد أدوار الأفراد فيه على حسب الكفاءة وليس المسميات الوظيفية.

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

اختبار الوحدات Unit Testing وتعتبر هذه التقنية أساس لكتابة برامج قابلة للتعديل والارتقاء. تعتمد هذه التقنية على كتابة اختبارات أوتوماتيكية للوحدات المكونة للتطبيق. هذه الوحدات من الممكن أن تكون Class أو Method على سبيل المثال ويشترط أن يتم اختبار الوحدة معزولة عن الوحدات المرتبطة بها ، فعلى سبيل المثال في حال تطوير تطبيق للتجارة الإلكترونية فلا بد من تطوير الاختبارات بمعزل عن قاعدة البيانات وذلك لضمان سرعة التنفيذ وأيضا لضمان أن فشل الاختبار يدل على مشكلة في هذه الوحدة وليس في الوحدات المرتبطة. لا تهدف هذه الاختبارات لاستبدال مديري الجودة ولكنها تهدف في الأساس إلى العمل كمظلة أمان لضمان أن أي تغيير في هيكل البرنامج لا يؤثر على العمل المنطقي للوحدات. مما يشجع على التحسين المستمر لتصميم التطبيق الداخلي دون الخوف من أن التغييرات ستؤدي إلى فشل في أجزاء أخرى من التطبيق.
توجد العديد من المكتبات التي تساعد في كتابة هذه الاختبارات لكل منصة عمل فللدوت نت على سبيل المثال يوجد NUnit والتي تعتبر الأشهر ولكن يوجد أيضا مكتبات واعدة مثل xUnit و MBUnit وللجافا هناك المكتبة الأشهر JUnit

اختبارات التكامل الأوتوماتيكية Automated Integration Testing وتعتبر هذه الاختبارات المستوى الثاني من مظلة الأمان المطلوبة لتطبيق سريع للتغيرات وقد تستخدم فيها نفس الأدوات المستخدمة في اختبار الوحدات إلا أنه في الغالب يتم استخدام أدوات متخصصة مثل Selenium و WatiR و WatiN وهي كلها أدوات مفتوحة المصدر كما أن هناك حلول تجارية من مايكروسوفت وغيرها.

التكامل المستمر Continous Integration وهذه الممارسة في غاية الأهمية لتسهيل التعامل بين فرق العمل وتشجيع التكامل المستمر بين الأفراد. يعتمد نجاح هذه التقنية على وجود اختبارات وحدات وتكامل قوية تضمن جودة التطبيق ككل متكامل في كل الأوقات. إلا أنه يمكن استخدام هذه التقنية بدون اختبارات إلا أنها لن تكون بنفس الفاعلية. من الأدوات المهمة والمفتوحة المصدر للتكامل المستمر CruiseControl و CruiseControl.NET كما توجد أدوات تجارية مثل TeamCity و Team Foundation Server

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

هناك 5 تعليقات:

  1. لو ما فيش حد عايز يعلق أبتدي أنا. الكلام ده نظري وغير قابل للتحقيق عشان احنا شعب فراعنة ولازم حد يكون فوق دماغنا عشان نطلع شغل.

    ردحذف
  2. انا عايزه ارد
    انت مش محتاج حد يكون فوق دماغك عشان تطلع شغل فى انت عايز تعمل ايه
    انت عايز توصل لايه عايز تتعلم وتوصل لحاجه معينه ليك هدف عايز تحققه ده اللى انا اعرفه

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

    ردحذف
  4. لا فض فوك يا استاذ ياسر
    طبعاالكلام قابل للتحقيق و قد رأيت وجربت ذللك بنفيى مع أكثر من فريق تطوير

    ردحذف