Sunday, December 24, 2017

إعادة اختراع العجلة في البرمجيات

أصل المقالة دي كانت بوست  كتبته على الفيسبوك، بس حبيت أعيد نشره لتعم الفائدة...

- أول مهمة عمل استلمتها في أول شركة اشتغلت فيها كان مطلوب مني أكمل شغل حد كان بدأ فيه قبلي شوية صغيرين، فأنا بكل ثقة، و كعادة كل المبتدئين قليلي النضج، ما عجبنيش الشغل اللي معمول و هدّيته وبنيته من أول وجديد، وطبعا ده أخد وقت محترم عشان أخلصه.
المهم مديري الفني وقتها كان م. حسن فهمي - ربنا يجزيه عني خيرا - سابني أكمل الشغل لغاية الآخر و بعدين قال لي الآتي:
مش كل حاجة ما تعجبكش تهدها وتبنيها من أول وجديد.
وده كان أول درس عملي لي في البرمجة.
وقتها ما استوعبتش الدرس قوي عشان كنت لسه قليل الخبرة، بس الأيام بتعدي و بتعلم الدرس بالطريقة الصعبة.
- في سبعينيات القرن الماضي، واحد من رواد صناعة البرمجيات اسمه فريدريك بروكس، عمل كتاب اسمه The Mythical Man-Month بيتكلم فيه عن مشكل صناعة البرمجيات وقتها، و الكتاب ده يعتبر من كلاسيكيات الصناعة بتاعتنا وظريف جدا، أنصحكم تقرأوه. المهم الراجل حذر في الكتاب ده من حاجة غريبة جدا، ألا وهي تأثير النظام الثاني The second system effect، و خلاصة الكلام اللي قاله إنه لما يكون عندك برنامج فيه مشاكل و تيجي تعمله من أول وجديد غالبا البرنامج ده هايكون فاشل لأنك هاتحاول تعالج فيه كل المشاكل اللي قابلتك في المشروع الأول و المشاكل اللي متوقع تقابلك مستقبلا و بالتالي هاتهندسه بزيادة over-engineered!
الحقيقة لما قرأت الكلام ده أول مرة استوعبته كويس المرة دي عشان كنت مريت بتجارب عملية على مشروعات فشلت بتأثير النظام الثاني!
- طيب ليه المبرمجين بيحبوا يهدوا اللي معمول و يبنوه من أول وجديد على نظافة -زعموا-؟

فيه مثل عندنا بيقولك: مفيش صنايعي بيعجبه شغل صنايعي تاني. والكلام ده في صناعة البرمجيات له وجه للأسباب التالية:
1- غالبا كل برنامج اتعمل كان له سياق ومشاكل بيحاول يحلها و مبرمجين بخبرات معينة بيشتعلوا عليه ومش شرط أنت تكون ملم بالظروف و السياق ده، و لا عندك نفس الخبرة اللي كانت عند الناس اللي عملوا البرنامج، ربما خبرتك أكتر فتستحقر شغلهم، وربما أقل فتحس إنه خيال علمي.
2- البرنامج مش بيتوقف بعد أول طلعة، و بيفضل يتضاف فيه خصائص و حلول لمشكلات bug fixes و تعديلات بشكل مستمر. مع ضغط الوقت و قلة الخبرة و تغير مطاليب العملاء بتلاقي الدنيا بتعك منهم.
3- فيه خاصية من طبائع البرمجيات، أشار ليها جول سبولسكي - أحد مؤسسي موقع stackoverflow الشهير، و هي أن كتابة الكود أسهل من قراءته، والطبيعة دي بتسري حتى لو أنت بذات نفسك اللي كاتب الكود اللي مش عارف تقرأه ده!
4- فيه مشكلة بقى عند المبرمجين نفسهم لما بييجوا يقيموا برنامج مش هما اللي عاملينه، و هي معايير التقييم: فمثلا ما بيحطوش وزن للسياق اللي اتعمل فيه البرنامج - اللي اتكلمنا عنه في النقطة 1، أو بيقيموه حسب التقنيات الحديثة اللي هما بيعرفوها، و اللي ربما ما كانتش موجودة لما البرنامج اتعمل أول مرة، أو حسب أساليب التصميم الحديثة اللي ما كانتش موجودة برضو لما البرنامج اتعمل أول مرة.
4- في بقى مشكلة تانية عند بعض المبرمجين المطلعين، إنهم بيحبوا يعملوا الحاجة من أول وجديد عشان يجربوا كل حاجة جديدة عشان يكتبوها في سيرهم الذاتية، و على الرغم إن تجربة كل شيء جديد أحد أساليب التعلم اللي فادتني كتير على المستوى الشخصي، بس كانت مكلفة، لأني فشلت كتير بسبب الاعتماد على تقنيات غير ناضجة، أو تجربة حل برمجي للمشكلة الغلط! وكل ما بتزداد خبرتي الموضوع ده كان بيقل معايا.
- طبعا الحل الأمثل لما يكون عندي برنامج خربان بس شغال وله قمية عند العملاء إني أحسن فيه واحدة واحدة، وحتى لو هاعيد بناؤه من الصفر، فلازم ده مايكونش خبطة واحدة، بل يكون التغيير بطيئا ومع الوقت.
- فيه برنامج كنت شغال على النسخة التانية منه، زمايلي كانوا بيقولولي إنهم اكتشفوا في النسخة الأولى منه إن الفيجوال بيسك ما بيقبلش أكتر من 128 بارامتر في الفانكشن (لاحظ اكتشفوا، يعني فضلوا يجربوا لغاية لما فشلوا). و مشروع تاني مش كبير كان بياخد 160 جيجا رامات، و لما حسنوه وصل ل70 جيجا!!
طبعا النوعية دي من البرامج لازم تولع فيها و تنسى كل الهري اللي أنا قلته فوق ده، بس لو عرفت تظبطه بالتدريج يبقى أحسن 
يللا شير في الخير بقى 

No comments:

Post a Comment