التكنولوجيا
هندسة البرمجيات
أنظمة التحكم في الإصدارات
تخزين الأحداث
نمط المراقب
برمجة عن بُعد
تحسين الأعمال
في الآونة الأخيرة .. كثير من التغريدات تكلمت عن أنظمة الـ Version Control وعلى رأسهم نظام الـ Git
لكن أغلب هذه التغريدات تناولت الموضوع من جانبه التطبيقي والخاص بالمبرمجين فقط .. لكن كعادتنا .. رح نتكلم اليوم من مستوى أعلى شوي .. مستوى مهندس البرمجيات
#هندسة_البرمجيات #git #vcs
لكن أغلب هذه التغريدات تناولت الموضوع من جانبه التطبيقي والخاص بالمبرمجين فقط .. لكن كعادتنا .. رح نتكلم اليوم من مستوى أعلى شوي .. مستوى مهندس البرمجيات
#هندسة_البرمجيات #git #vcs
الـ Architecture اللي تعتمد عليه هذه الأنظمة عموماً مشتق من مبدأ الـ Observer Pattern واللي اعتمدنا عليه في إنشاء فكرة الـ Event-Sourcing واللي تعتبر حجر الأساس في بناء أنظمة الـ Version Control .. الموضوع مرتبط بشكل كبير وتكلمنا عنه من قبل في هذه السلسلة
ما أتوقع نحتاج نذكر القيمة اللي أضافتها هذه الأنظمة على آلية سير العملية البرمجية وكيف أتاحت الفرصة لوجود مصطلح البرمجة عن بعد أو الـ remote programming إنه ينتشر ويصير أسهل من قبل .. أنظمة الـ VCS تعدت فوائدها لتشمل الـ Business بشكل عام .. قللت علينا الوقت والتكاليف بشكل كبير
لكن خلونا نرجع لورا شويتين ? .. ونشوف التطور التقني اللي حصل على هذه الأنظمة من بدايتها إلى وقتنا الحالي .. واللي نقدر نلخصها في 4 فترات رئيسية .. بدأنا بطريقة يدوية بحيث نجمع فيها الملفات المختلفة من جميع المطورين وبعدها نحاول ندمجها مع بعض بحيث نضمن ما يكون في أي Conflicts
في داعي نتكلم على صعوبة هذه المهمة ؟ على فكرة .. كانت هذه المهمة مخصصة لأشخاص .. هذه هي وظيفتهم فقط .. جمع كل الملفات .. أدمجها مع بعض وحل مشاكل الـ conflicts .. وبعدها إرجع تأكد إنه كل الـ unit tests اللي كانت ناجحة قبل الدمج ناجحة بعده .. أقل ما يقال عنها طريقة بدائية جداً
مع بداية الفترة الثانية .. بدأنا نشوف أهم المشاكل اللي كنا نواجهها في الفترة الأولى ونشتغل على حلول لتفاديها .. أهم هذه المشاكل كانت بكل تأكيد .. مشكلة التجميع اليدوي للأكواد .. ومشكلة الـ Conflicts واللي كان صعب علينا نحلها في هذه الفترة ..
قدرنا نحل مشكلة التجميع اليدوي عن طريقة إنشاء Repository وحدة نجمع فيها كل ملفات المشروع .. ولكن واجهتنا مشكلة الـ Concurrency والحل الوحيد اللي كان متاح في هذه الفترة كان مبدأ الـ Lock .. ببساطة إذا كان في مبرمج شغال على ملف معين رح ينجحب هذا الملف عن باقي المبرمجين لحد ما يخلص
ومو بس هذه المشكلة .. كمبرمج مارح يكون عندك صلاحية إنك تشتغل (تقفل) أكثر من ملف واحد .. وهذه النقطة بالذات ساهمت في زيادة الوقت اللي يحتاجه المبرمج لإنهاء مشاكل بسيطة
نقدر نقول إننا تطورنا شوي عن المرحلة الأولى في فكرة الـ automation للتجميع .. لكن المشاكل بدأت تزيد للأسف
نقدر نقول إننا تطورنا شوي عن المرحلة الأولى في فكرة الـ automation للتجميع .. لكن المشاكل بدأت تزيد للأسف
قبل ما ندخل في المرحلة الثالثة .. معلومة على السريع .. الفكرة الرئيسية من وجود الـ Repository هي توحيد الـ Source of Truth لأي مشروع تقني .. وأي نظام VCS لازم يضمن " نظافة " هذا الـ Source من أي Conflict .. بحيث نكون جاهزين إننا نسوي Deploy للمشروع في أي وقت بدون أي مشاكل
لذلك فكرة الـ Lock صحيح كانت بدائية .. لكنها تعطينا الضمان بسلامة كل ملفات المشروع من أي مشكلة ممكن نواجهها وقت الـ Production .. لذلك كان من المهم على أي حل مستقبلي لتطوير الـ Concurrency إنه يوفرلنا هذه الميزة بشكل أساسي ..
فكرة الحل اللي قدمناه في المرحلة الثانية لمشكلة الـ Concurrency كانت غير مجدية وخصوصاً في المشاريع والفرق البرمجية الكبيرة .. لكن المرحلة الثالثة قدمتلنا حل نموذجي .. وكان يتمثل في فكرة (merge before commit) واللي أعطتنا الفرصة إننا نشتغل على أكثر من ملف بدون أي مشكلة
طيب .. أتوقع المرحلة الثالثة قدمت اللي نحتاجه وأكثر .. ليش نحتاج مرحلة رابعة ؟ السبب كان نظام الـ Git .. اللي عمل ثورة في عالم الـ VCS .. والسبب كان العمل على تطوير فكرة الـ Fork .. واللي سمحتلنا نتطور بشكل سريع في فكرة الـ Distributed Systems والـ Open-source Libraries
فكر فيها .. بفضل الـ Git .. تقدر الآن بضغطة زر تنسخ كل محتوى الـ Repository لـ Library معينة أو Framework معين بشكل مؤتمت .. ويصير عندك وتستخدمه في مشاريعك وتعدل عليه لو احتجت .. هذه النقطة هي اللي رجحت الكفة للـ Git قبل ما تبدأ تضيف باقي الأنظمة هذه الميزة
ذكرنا من قبل بأنه أنظمة الـ VCS مفيدة جداً في إدارة الفرق البرمجية وآلية سير المشروع لكن من المهم إختيار الـ Development Style الخاص بالـ VCS بحيث يستفيد منها الفريق بأفضل شكل .. إختيارك للـ Style رح يعتمد على عدة عوامل أهمها طبعاً حجم المشروع وأيضاً جودة الفريق التقني وغيرها
أول وأكثر Style مطبق هو الـ Git Flow Style .. واللي يعتمد على تقسيم الـ master branch إلى عدة sub-main branches بحسب إحتياج الفريق .. أشهرها الـ Develop branch – Testing branch .. غير طبعاً الـ Feature branches المشتقة من الـ Develop branch
بعد ما ينتهي المبرمج من الـ feature اللي شغال عليها .. يطلب Pull request للـ Develop branch .. ويكون في مبرمجين محددين هم الـ Authorized إنهم يوافقوا على إضافة هذه الـ Feature أو رفضها بعد إختبارها وتجربتها ..
المشكلة الرئيسية اللي رح تعاني منها في حال تطبيقك لهذه الفكرة هي الـ merge conflicts اللي رح تواجهها لما تبدأ ترفع التغييرات للـ master branch بعد فترة طويلة .. وخصوصاً إنه إحتمالية تغير نفس الملف من أكثر من مبرمج عالية جداً .. فممكن يضيع وقت طويل جداً في حل هذه الـ conflicts
لكن ما نقدر ننكر بأنه الـ quality رح تكون أفضل كون التغييرات مارح تضاف للـ master إلا بعد إختبارها والتأكد من سلامتها .. وبالتالي التحكم في جودة الـ Software رح تكون أسهل بكثير باستخدام هذا الـ style .. وبالتالي لو فريقك التقني مكون من مبرمجين مبتدئين .. رح يفيدك هذا الـ style
الـ style الثاني هو الـ Trunk-Based Style .. واللي يرتكز على تقليل الـ branches لأقل ما يمكن .. بحيث ما يكون عندك إلا master branch وأيضاً short-lived feature branches مشتقة من الـ master على طول .. بشرط ما يعيش الـ feature branch أكثر من يومين كحد أقصى
بمجرد إنتهاءك من الـ feature .. رح تقدر تسوي merge مع الـ master بشكل مباشر وبدون أي pull request وغالباً رح تكون الـ conflicts قليلة وبسيطة بسبب الفترة الزمنية القصيرة بين كل merge والثاني ..
هذا الـ style رح يساعدنا بشكل كبير في عملية إكتشاف الأخطاء بشكل أسرع ومعرفة مكانها بالضبط .. والسبب هي كمية التغييرات البسيطة اللي تصير بين كل merge .. بعكس الـ Git flow اللي غالباً رح يحتوي على تغييرات كبيرة وفي أكثر من ملف ورح تصعب عملية إكتشاف مكان المشكلة أكثر وأكثر
كل هذه المميزات وأكثر رح تساعدنا في زيادة سرعة تطوير السوفتوير بدون أي تعقيدات زائدة وخصوصاً لو كان فريقك التقني محترف ومتفاهمين بين بعضهم .. ولكن النقطة اللي ممكن نواجه فيها مشكلة هي الجودة واللي رح تكون إدارتها صعبة في ظل كمية الـ merges اللي تصير على الـ master في اليوم الواحد
أغلب الفرق التقنية تبدأ في هذا الـ style مع بداية أي مشروع جديد كونه عملية الـ delivering رح تكون أسرع .. وبمجرد ما يبدأ يكبر المشروع أكثر وأكثر .. يبدؤوا يعتمدوا أكثر على الـ Git flow style بحيث يكون عندهم تحكم أكبر بجودة المشروع وأيضاً بالتغييرات اللي رح تطرأ عليه
نهايةً .. رح تبقى مهمة إختيار الـ style المناسب للمشروع وللفريق التقني هي مهمة مهندس البرمجيات المسؤول عن إدارة الفريق التقني .. ومعرفة عيوب ومميزات كل style قبل إختياره .. واللي من الممكن تتغير كل فترة بحسب التغيرات اللي ممكن تحصل للفريق أو المشروع ?
#انتهى
#انتهى
جاري تحميل الاقتراحات...