29/08/2010 16:58
هناك امور يتعلمها المرء من التعامل مع مشروع برمجي حقيقي لاول مرة، امور لم يكن يدركها من قبل ولا كانت تخطر له على بال!
ما اقصده بمشروع حقيقي هو مشروع ينتج عنه “منتج” نهائي تقدمه بشكل مباشر لزبائن (عملاء) او مستخدمين، يستخدمونه بشكل جاد لتحقيق غرض معين يحتاجونه بالفعل .. و ليس من باب التسلية و تجربة شيء جديد كما قد يفعل اصحابك اذا طلبت منهم ان يجربوا برنامجك.
هناك احتمال من اثنين: إما ان تقوم بتطوير المشروع بشكل سريع و متواصل، و بالتالي تحتاج لاصدار التحديثات باستمرار، او ان يكون المشروع بسيط نوعا ما و لا يحتاج تحديثا باستمرار، و انما تقوم بتطويره لعدة اشهر قبل اصدار اي تحديث جديد.
اذا كنت تقوم بتطوير موقع، او كما يسمونه هذه الايام web application فيجب ان يكون نمط عملك من النوع الاول، اي تطوير سريع و اصدار تحديثات و تحسينات باستمرار. و هذا هو النمط اللذي ستتعلم منه اكبر قدر من الدروس و العبر لانك ستكون تحت ضغط مستمر و لا يمكن ان تتعامل مع المشروع مثل ما تتعامل مع اي مشروع عادي تقوم بتحديثه مرتين او ثلاثة في السنة. و مع ذلك، فإن الافكار اللتي اريد التحدث عنها تصلح ايضا للمشاريع العادية اللتي قد لا تظن انها تحتاج سرعة كبيرة في اصدار التحديثات.
لنتفق اولا على بعض المصطلحات:
deploy: عند الحديث عن تطبيقات الويب، فإن هذا المصطلح يعني اطلاق المشروع (او تحديثه) على الموقع. يمكن ان نترجمها “إطلاق”.
productivity: كفائة المبرمج و سرعته في التطوير و التحديث و ادارة المشروع. عادة يسمونها “الانتاجية”، و لكني ساسميها “كفائة”، لان الفكرة تتمحور حول ان تكون كفوءا في التطوير و الادارة.
automation: اتمتة. اي تحويل المهام المضنية و المملة (العمليات الرتيبة الميكانيكية اللتي تشتت فكرك لانها تسترعي انتباهك) الى عملية سهلة يقوم بها الكومبيوتر باقل عدد ممكن من الخطوات، و يفضل ان تتم بخطوة واحدة، اي يكفي ان تكتب امرا واحدا (او تضغط زرا) ليقوم الكومبيوتر نيابة عنك بتنفيذ كل المهام المطلوبة لاتمام تلك العملية.
حين تعمل تحت ضغط كبير، و هنا لا اقصد الضغط اللذي قد يمارسه عليك شخص مزعج بالزنين على رأسك 24 ساعة في اليوم، بل اقصد الضغط الناتج عن ضرورة الاسراع في تنفيذ العمل لان هناك bug (علة) تؤثر على الموقع بشكل سلبي او لان هناك feature (خاصية) وعدت بها المستخدمين و تحتاج اصدارها في اقرب وقت ممكن، و ما الى ذلك. هذا النوع من الضغوط يتطلب منك ان تكون مبرمجا كفوءا، و لا يمكن ان تكون مبرمجا كفوءا اذا كانت ادارة المشروع تصيبك بالجنون.
ربما تكون مبرمجا كفوءا من ناحية انك وجدت الـ bug و اصلحتها على جهازك، و لكن هذا لا يكفي بالطبع، فجيب ان تطلق هذا التحديث اللذي اصلح هذه الـ bug و الا فإن مستخدمي الموقع لا زالوا يعانون من هذه العلة.
و ربما تكون مبرمجا كفوءا من ناحية انك تستطيع اضافة الخاصية الجديدة (الموعودة) في غضون اسبوع مع انها معقدة و تتطلب قدرا كبيرا من العمل الجاد، و لكن ايضا لا فائدة اذا لم تكن تستطيع اطلاق التحديثات بسرعة.
تخيل لو كنت في خضم العمل على خاصية جديدة و اكتشفت علة خطيرة في الموقع، ماذا تفعل؟
لكي تدير المشروع بكفائة يجب ان تكون قادرا على:
هناك امور ستجعل منك مبرمجيا غير كفوء:
اذا كنت لا تستطيع اطلاق التحديث اللذي قمت به لتلك العلة لانك تعمل في نفس الوقت على الخاصية الجديدة و هي غير جاهزة بعد و بالتالي لا تستطيع اطلاق التحديث لان المشروع ليس في حالة ثابته تسمح لك باطلاق التحديثات الجديدة، فانت لا تعمل بكفائة.
لنفرض انك تغلبت على هذه النقطة و انك تطور المشروع في اتجاهين متوازيين او انك تستخدم git و بالتالي يمكن اصلاح علة في نسخة سابقة من دون لخبطة النسخة الحالية.
هذا وحده لا يكفي، يجب ان تكون ايضا قادرا على اطلاق اي تحديث الى الموقع بسرعة و كفائة، و الا اصبت بالجنون! هل يمكنك ان تتخيل انك كلما اردت اطلاق اخر تحديث للموقع، يجب ان تقوم بعشرين خطوة ليس لاي منها علاقة بالاخرى؟ و كل خطوة قد تستغرق دقيقة الى خمس دقائق؟
مثلا، الخطوة الاولى: عمل compile
الخطوة الثانية: اعداد بعض الـ configurations
الخطوة الثالثة: اغلاق السرفر و وضع اشعار صيانة
الخطوة الرابعة: حذف الملفات السابقة من الموقع - يدويا - مع الاحتفاظ بالـ configurations
الخطوة الخامسة: مقارنة الـ configuration القديمة بالـ configuration الجديدة و التأكد من انك لم تنسى شيئا
الخطوة السادسة: رفع الملفات الجديدة الى السرفر و التأكد من وضع ملفات الـ configurations في مكانها الصحيح
الخطوة السابعة: القيام بتحديث قاعدة البيانات لكي تقوم بعمل الـ migrations المطلوبة
الخطوة الثامنة: تشغيل السرفر من جديد و ازالة اشعار الصيانة
هذا مثال فقط و ليس بالضرورة انه مثال واقعي، و لكنه قد يحدث كثيرا في الكثير من الشركات ذات الادارة العقيمة.
لا يمكن ان تكون مبرمجا كفوءا اذا كنت تحتاج لتنفيذ هذه الخطوات عند كل مرة تريد فيها ان تطلق اخر التحديثات للموقع! يجب ان يكون هناك امر واحد، اسمه مثلا deploy تقوم بتنفيذه من سطر الاوامر فيقوم بكل الخطوات اللازمة لاطلاق الموقع من دون ان تقوم انت شخصيا بعمل اي شيء.
ان لم يكن لديك هذا الامر فستصاب بالجنون و ستكره عملية اطلاق الموقع و ربما تكره عملية التطوير كلها من الاساس. تخيل، اااخ جائني bug report و يجب ان اصلح الموقع باسرع وقت!! يا للمصيبة، لا يكفي ان امضي ساعتين في محاولة اكتشاف العلة و اصلاحها بل يجب ان اقضي نصف ساعة لاعاني من كابوس اطلاق الموقع! تعرف شنو .. اصلاح العلة ليس مهما جدا .. خليهم ينتظروا للشهر الجاي حين اطلق النسخة الجديدة.
لان الخطوات المطلوبة لاطلاق الموقع مضنية و مزعجة بهذا الشكل، ستحاول تجنبها باكبر قدر ممكن، و ستقوم بالمباعدة بين عمليات الاطلاق باكبر قدر ممكن، و بدلا من التركيز على تطوير المشروع ستصبح منهمكا في ادارة امور سخيفة فقط من اجل ان تمر علية الاطلاق بسلاسة و امان.
اطلاق الموقع هو احدى العمليات المكررة اللتي ستواجهك كثيرا في عملك اليومي. هناك اعمال اخرى من هذا الصنف و قد تجد نفسك مضطرا للقيام بها عدة مرات في اليوم.
و لهذا و لكي تحافظ على قدراتك العقلية من الجنون، ستتخذ قرارا بعدم اطلاق اي تحدث الا مرة كل شهر، او كل شهرين .. او ربما كل اربعة اشهر!!
و لان عمليات الاطلاق متباعدة بهذا الشكل، ستلاحظ انك لا يمكن ان تحتمل وجود اي علل قاتلة قبيل الاطلاق لان هذه العلل ستبقى مع المستخدمين لفترة طويلة .. الى ان تقوم بالاصدار القادم، و اللذي بالمناسبة ربما سيصلح بعض العلل و لكنه سيقوم باضافة علل جديدة.
و زيادة في العقم .. لنتخيل انك لا تستخدم git ولا اي اداة لادارة نسخ متعددة من المشروع بشكل متوازي.
تخيل كيف ستكون عملية الادارة الان: كل خاصية جديدة تحمل معها مخاطرة باضافة علل جديدة الى البرنامج، و لنفرض انك تقوم باصدار جديد كل شهرين، فإنك لن تقوم بتطوير اي خاصية جديدة تستغرق اكثر من شهر، لانك ستمضي شهرا للتطوير و شهرا لاصلاح العلل و التاكد من ان البرنامج خالي من العلل الفادحة.
سياسات عقيمة من هذا النوع لها اسم عند الشركات الكبيرة: Quality Assurance
و ستكون في قاع الهاوية حينما تقنع نفسك ان هذه السياسات العقيمة هي اللتي تجعل منك مبرمجا “محترفا”
ماذا لو كنت تمتلك الادوات اللازمة لاتمتة كل الاعمال المضنية؟ سيكون بامكان ان تركز 100% (او 98%) من جهودك في تطوير المشروع بدلا من ان تشتت ذهنك في امور ثانوية.
سيكون بامكانك اطلاق تحديثات بشكل يومي، بل ربما عدة مرات في اليوم.
لن تخاف من وجود بعض العلل لانك تعرف ان تستطيع اطلاق تحديث يصلحها بسرعة فائقة!
تستطيع تطوير خواص جديدة بشكل سريع من دون ان تشعر بلخبطة بين النسخ المختلفة من المشروع.
منافسيك قد يستغرقون شهورا (!!!) في اطلاق خاصية بسيطة بينما يمكنك ان تقوم انت بتطويرها في غضون اسبوع.
يتحدث Paul Graham عن انه عندما كان يدير موقع viaweb كان يقوم باصلاح العلل و اطلاق التحديث للموقع اثناء الحديث مع الزبون على الهاتف! تخيل نفسك مكان الزبون، صادفت مشكلة في الموقع و قمت بالاتصال بالشركة و اخذت تشرح لهم المشكلة اللتي صادفتها و تطلب منهم ان يرشدوك الى حل او طريقة للالتفاف حول المشكلة. و بينما انت على الهاتف معهم يقولون لك “جرب ان تفعل ذلك الان مرة ثانية” .. و اذا بالمشكلة قد اختفت!!!
بينما شركة اخرى تواجه مشكلة مع منتجهم، فتتصل بالشركة و تطلب منهم حلا .. فيخبرونك انهم “يعملون” عليها و انهم سيصدرون حلا لها “قريبا”، و هذا القريبا يعني في الحقيقة “خلال شهرين او ثلاثة”.
يتحدث Paul Graham ايضا عن ان بعض منافسيهم كانوا يقومون ببهرجة دعائية كبيرة حول خاصية جديدة اضافوها لمنتجهم و يقومون باطلاق بيانات صحفية و عقد مؤتمرات و ارسال ايميلات .. و و .. و مع ان الخاصية الجديدة سخيفة و غير مهمة، و لكنه قد يقرر ان يضيفها هو ايضا الى موقعه .. على الاقل فقط لاغاضة منافسيه! و ذكر انه (هو و شريكه في المشروع) كانوا يقومون باضافة الخاصية نفسها الى منتجهم في غضون يوم او يومين!
لكي تصبح مبرمجا كفوءا هكذا لا يكفي ان تكون لديك المهارات البرمجية العادية من تحليل المشاكل و حلها و تتبع العلل و اصلاحها. يجب ان تكون لديك الادوات اللتي تقوم باتمتة المهام المضنية بحيث تكون قادرا على التركيز على المشروع نفسه بدل ان تدوخ في مشاكل ثانوية ليس لها علاقة بتطوير المشروع.
كل شيء في النهاية يدور حول الاتمتة. و كل الادوات اللتي تستخدمها هدفها النهائي هو اتمتة المهام المضنية، حتى و ان لم يكن ذلك واضحا لك.
محرر النصوص ماهو في الحقيقة الا اداة لاتمتة تحرير الملفات النصية. في السابق لم يكن هناك مثل هذه الادوات بل كان عليك ان تستخدم punch cards، اي تقوم بتخطيط البرنامج على الورق و من ثم ترجمته يدويا الى لغة الالة و كتابته بعد ذلك على punch card
الـ compiler ما هو الا اداة تقوم باتمتة عملية التحويل من لغة برمجية معينة الى لغة الالة.
الـ IDE ما هو الا اداة تقوم باتمتة عملية تجميع عدة ملفات نصية تكون مشروعا واحدا.
البعض لا يفهم الامور بهذا الشكل! البعض يظن ان Visual Studio هو مترجم للسي بلص بلص! و هذا بعيد عن الحقيقة تماما. Visual Studio هو اداة لادارة المشاريع و ليس compiler.
يمكنك ادارة المشاريع من دون VS، و لكنها عملية مضنية، اذ سيكون عليك ان تقوم بترجمة كل ملف على حدة و من ثم تجميع الناتج من العملية و تحويله الى ملف تنفيذي. VS مهمته هي اتمتة هذه العملية لكي يكون بامكانك التركيز على البرنامج بدلا من الانشغال بكيفية تجميع عدة ملفات الى برنامج واحد.
و العملية في الحقيقة تتطلب عدة خطوات لو كنت تريد القيام بها يدويا:
و لكن هذه العملية قد تستغرق وقتا طويلا، فلماذا تقوم بترجمة ملفات لم تقم بتغييرها اصلا؟ تحتاج فقط الى ترجمة الملفات اللتي تغيرت، فلهذا تصبح الخطوات:
لماذا تدوخ نفسك بهذه الاعمال اذا كان الكومبيوتر يستطيع ان يقوم بها نيابة عنك؟
اداة make على يونكس لها نفس المهمة، فلكي تقوم بتجميع البرنامج بخطوة واحدة (من دون الاستعانة بـ IDE) تقوم باعداد ملف Makefile بسيط يشرح علاقة الملفات ببعضها و من ثم تقوم بترجمة و تجميع البرنامج عن طريق امر واحد .. و هو make و عن طريقه يقوم الكومبيوتر بالبحث عن الملفات اللتي تغيرت ليعيد ترجمتها و من ثم يعيد عملية الربط linking بين الـ object files الناتجة عن عملية الـ compile
و هنا يظهر الفرق بين المبرمج الماهر — الهاكر، و بين مهندس البرمجيات.
مهندس البرمجيات ليس لديه هذا المفهوم لفكرة الـ automation، كل ما يعرفه انه تعلم عن شيء اسمه compiler و شيء اسمه IDE و لكنه لا يقوم بالربط بين وجود هذه الادوات و بين اتمتة عمليات مضنية. من وجهة نظهره ان هذه الادوات تقوم بشيء جديد كان مستحيلا في السابق!! وهو في الحقيقة واهم.
الـ compiler لا يقوم بشيء كان مستحيلا في السابق. الناس من قبل كانوا يخططون البرنامج على الورق ثم يقومون بترجمته الى لغة الالة يدويا، و ما يقوم به الـ compiler هو اتمتة هذه المهمة، فبدلا من ان تقوم بالتفكير في كيفية التعبير عن البرنامج بلغة الالة، يقوم الكومبايلر بهذه العملية نيابة عنك.
و كذلك الـ IDE لا يقوم بعمل شيء جديد كان مستحيلا في السابق، بل هو اداة تقوم باتمتة بعض العمليات المتعلقة بادارة المشاريع، و خصوصا عملية ربط ملفات المشروع مع بعضها لانتاج ملف تنفيذي في النهاية. و هو ليس امر مستحيل، بل يمكن القيام به بدون اي IDE على الاطلاق، كل ما تحتاجه هو عمل compile لكل ملف قمت بتغييره و من ثم عمل linking لكي تحصل على ملف تنفيذي (في العادة المشاريع الحقيقية تتطلب اكثر من ذلك و لهذا للـ IDE حدود، و هو في الحقيقة ليس بيئة تطوير متكاملة كما يوحي اسمه).
صحيح ان هذه الادوات لا تقوم بشيء جديد في حد ذاتها، و لكن وجودها و قيامها باتمتة المهام المضنية يفتح لك ابوابا جديدة لم تكن موجودة من قبل. فبدلا من ان تمضي نصف الوقت في تحويل البرنامج الى لغة الالة، يقوم الكومبايلر بالمهمة نيابة عنك لتركز انت في كتابة البرنامج.
و لكن الكثير من الناس لا يقومون ذهنيا بالربط بين الاتمتة و بين زيادة الكفائة، فيتوهمون ان هذه الاداة او تلك قامت باختراع جديد لم يكن ممكنا في السابق.
بينما الهاكر، على الجانب الاخر، يدرك هذه الفكرة جيدا، حتى لو لم يكن يدركها في وعيه .. فإنه يدركها في اللاوعي، و تجدها منعكسة دائما في تصرفاته. فاذا وجد نفسه يكرر القيام بنفس العملية مرات و مرات، يقوم بكتابة اداة تقوم بتلك العملية نيابة عنه. و لا يهمه في ذلك ان تكون لهذه الاداة واجهة رسومية جذابة — بل يهمه ان تكون فعالة و تقوم بعملها بشكل صحيح و على اكمل وجه. و هذا ينعكس في الفرق الرهيب بين لينوكس و ويندوز. لينوكس مليء بادوات تعمل من سطر الاوامر و تقوم بعمليات رهيبة لم تكن اصلا لتفكر في القيام بها لما يخالها من تعقيد. و الكثير من هذه الادوات موجهة نحو المطورين المهرة (الهاكرز)، فهم اصلا اللذين طوروها لكي تسهل لهم القيام باعمالهم و من ثم قاموا بنشرها لتعم الفائدة على اخوانهم الهاكرية. و تجد الهاكرية يحبون هذه الادوات و يكيلون لها الثناء و المديح، رغم ان بعضها قد يبدو معقدا بعض الشيء عند اول نظرة.
بينما في عالم الوندوز، لا تجد مثل هذه الادوات، بل تجد برامج ضخمة معقدة، مثل Visual Studio، يسمونها IDE، و هو اداة كبيرة من اصدار شركة تجارية، انتج بهدف بيعه الى شركات تجارية اخرى و التربح منه ماديا. صحيح ان اللذي نفذ هذه الاداة الضخمة هم في النهاية مبرمجون، و لكن السياقات اللتي قادت لانتاج هذه الاداة و الاهداف المرادة منها بعيدة كل البعد عن المبرمج. فجول ستوديو اداة للبيع و الاستهلاك: قبل ان تباع تقام لها حملة ترويج و بهرجة دعائية، قد يصاحبها كم من المصطلحات غير المفهومة لكي تشعرك بانك جاهل .. و في النهاية يراد منها ان تباع الى مستهلكين.
فالمبرمج هنا لا يقوم بعملية الاتمتة بنفسه .. فهي “معقدة جدا” بالنسبة له، بل ينتظر من يقوم بها نيابة عنه. و هذا يتم من دون وعي مباشر منه، لانه لا يفكر بطريقة “كيف اسرع عملي”، بل يفكر بطريقة “كيف اقوم بعملية كانت غير ممكنة من قبل”. مثلا، كيف اقوم بكتابة برنامج بلغة دوت نت؟ اكيد انا بحاجة الى “البرنامج العملاق” فجول ستوديو. فهو يعرف الكومبايلر، و يعرف الـ IDE، و ينظر اليها على انها اختراعات عظيمة لا يستطيع من دونها ان يعمل اي شيء! (كيف اذن كان الناس يبرمجون قبل اختراع هذه الادوات؟)
و لكن ماذا لو واجه عقبة بعد ذلك، و لم يجد لها برنامجا عملاقا لكي يحلها؟ سيضطر الى القيام بكل شي بشكل يدوي، و قد لا يخطر بباله ان يكتب سكربت صغير يقوم بالمهمة نيابة عنه. فهو حين يواجه مشكلة تتطلب منه القيام بمهمة “مملة”، فإن طريقة تفكيره لن تقوده الى اتمتة هذه العملية. لانه يفكر في الامور من ناحية الامكانية او عدم الامكانية! فإذن كان يستطيع القيام بمهمته عن طريق فتح برنامج رسومي و القيام بعشر خطوات من داخله، فإن هذا بالنسبة له كافي جدا، لانه يرى انه “يستطيع” القيام بالمهمة، و هو راضي جدا بهذا الامر، و لن يتململ من ان العملية مضنية او عقيمة، لانه “محترف” و عنده حس المسئولية، و يعرف ان لديه عملا و يجب ان ينجز، و يعرف ايضا ان التململ من صفات “الهواة” و هو لا يريد ان ينزل الى مستواهم. و لعله ايضا يرى ان الصبر على هذه الاعمال العقيمة امر ضروري لا مفر منه. (لاحظ ان هذه الصفات قد تبدو صفات حميدة: المسئولية، الصبر، الرضا!)
بينما الهاكر، يرى ان القيام بهذه المهام المضنية مضيعة للوقت و الجهد و تشتيت للفكر و الطاقة الذهنية، و سيحاول اتمتتها باي شكل ممكن.
و لهذا تجد الشركات الكبيرة مليئة بسياسات عقيمة، لان “المهندسين” فيها لا يفهمون انهم يجب ان يقوموا باتمتة الخطوات المطلوبة للقيام بالعمليات المهمة (مثل اطلاق الموقع) و اللتي تتسبب في تاخير المشروع اذا لم تدر بشكل جيد. فبدلا من ان يقوموا بتطوير ادوات تساعدهم على العمل بكفائة، يقومون بالتناقش مع الادارة و يخرجون بسياسات ادارية تقوم بوضع “خطط” لكي تتم العمليات المضنية على وجه سليم و باقل كمية ممكنة من المشاكل!!
و ربما اذا حالفهم الحظ سيجدون احدى الشركات اخرجت منتجا “عملاقا” ذو “واجهة رسومية جذابة” و قامت بحملة “دعائية” لترويج هذا المنتج. و قامت باختراع مصطلحات جديدة لكي تضفي هالة من القدسية على منتهجم. و طبعا ستجد انه مكلف و باهض الثمن! و رغم ان هناك بدائل عنه مفتوحة المصدر و مجانية، الا ان الشركة الكبيرة ستذهب مع المنتج ذو الواجهة الرسومية و المكلف الثمن، لان العاملين فيها لا يفهمون ان ما يحتاجونه هو مجرد اداة لاتمتة العمليات المضنية — بل يظنون انهم بحاجة الى برنامج ضخم و معقد، يظنون انهم بحاجة الى منتج يمكنهم من عمل شيء كان مستحيلا في السابق.
الامر ابسط مما يتخيلون بكثير.
كل ما يحتاجونه هي ادوات تقوم باتمتة المعليات المضنية لكي يستطيعوا ان يركزوا على تنفيذ عملهم بدلا من ان يجن جنونهم في تنفيذ تلك العمليات المضنية كل يوم.
