Mohamed Lahlah

الأعضاء
  • المساهمات

    6
  • تاريخ الانضمام

  • تاريخ آخر زيارة

السُّمعة بالموقع

2 Neutral
  1. على مدار الأشهر القليلة الماضية، نشرت بعض المقالات الّتي تستكشف النقاط الأساسية الثلاث في تحولك الرقمي وهي المنتج والعملية والناس، وذلك لتمكينك من الانتقال من نموذج عمل مُحسن للموارد استنادًا إلى النفقات الرأسمالية (CAPEX) إلى نموذج مُحسن للسوق استنادًا إلى النفقات التشغيلية (OPEX). ومن الأمثلة على الانتقال من CAPEX إلى OPEX هو استخدام خدمات أمازون السحابية AWS بدلًا من إنشاء بنية تحتية من الصفر والتي ستُخدّم المشروع. ومن بين الفوائد الأخرى، يساعدك إتحاد الأشخاص والعمليات والمنتجات على رفع قيم العمل الأساسية، مثل زيادة قيمة الأعمال Business Value، مثل: زيادة قيمة الموظف، وقيمة العميل وقيمة الموارد وكثير من هذه القيم التي لا تقاس مباشرة بالقيم النقدية، بالإضافة إلى تقليل أوقات دورة التسليم، وتمكين الجميع من التعلم والتكيّف وتطوير مستواهم بشكل مستمر. يركز المهندسون (مثلي) عادة على المنتجات والأدوات والتقنيات. إذا أردنا النجاح في الانتقال إلى DevOps، فمن المهم أن ندرك أنه لا يمكنك شراء أو تركيب DevOps! المنتجات هي أدوات داعمة، وليست الحل السحري للأمر، فهي تتيح لك التركيز على النتائج، مثل الأتمتة، والتطابق، والموثوقية، والقدرة على الصيانة، وتمكين الميزات أو تعطيلها بشكل تدريجي، و تصور الخطوات اللازمة للانتقال من إنشاء المنتج إلى تسليمه إلى العميل النهائي أو ما يسمى flow of value. عندما نتحدث عن العملية، فإننا غالبًا ما نتجه نحو الأتمتة لرفع قيمة الكفاءة والاستقرار والثبات. ومن المهم أيضا تضمين أهداف الاحتفال بالنجاح سواءً كفريق أو منظمة، والتركيز على الجودة انطلاقًا من تصوّرها وتخيلها وانتهاءً بتحقيقها على أرض الواقع، وإنشاء عملية إدارة التغيير بحيث تكون سريعة الاستجابة وخفيفة، واحتضان البنيات المترابطة بشكل خفيف (loosely coupled architectures) لتمكين التطوير، والسعي إلى إصدار عدة مميزات جديدة في اليوم. إن جوهر هذا التحول هو تحول الناس وثقافتهم وليس المنتجات أو العمليات أو حتى حجم المنظمة. يحتاج الناس لأن يدركوا أهمية التحول وأن يعتنقوا فكرة DevOps، وأن يفهموا كيف ستتأثر مهامهم ووظائفهم، ويجب عليهم تحمل مسؤولية أدوارهم المنوطة إليهم في هذا التحول. ويجب عليهم أيضًا أن يدركوا أن DevOps لا تقتصر على التنمية والعمليات، حتى وإن كان اسمها بحد ذاته يدل على ذلك ويستبعد أصحاب المصلحة الآخرين.إنك تحتاج إلى إزالة جميع العوائق والمفاهيم الخاطئة داخل مؤسستك والتي تمنع من الانتقال إلى DevOps، وأن تجمع بين كلّ أصحاب المصلحة ومن جميع الأقسام في الشركة، بما في ذلك أقسام التطوير وخدمات البيانات والعمليات والأمان والأعمال إلى أن يتم تحقيق التحول إلى DevOps. ترجمة -وبتصرف- للمقال Breaking down walls between people, process, and products لصاحبه Willy-Peter Schaub
  2. إذا كنت مهتما بتعلم البرمجة، فعلى الأرجح أنك رأيت هذا الاقتباس من قبل: في الحقيقة لا أبالغ إن قلت أن البرمجة أصبحت من أهم المهارات في عصرنا الحالي، وذلك لأنها دخلت في جميع مجالات حياتنا سواءً كنا ندرك ذلك أم لا فانطلاقًا من الهواتف المحمولة ومرورًا بالمنازل والشاشات الذكية وانتهاءً بالسيارات ذاتية القيادة. كل شيء من حولنا لم نكن لنراه بهذا الشكل لولا البرمجة، فأنا على سبيل المثال أكتب وأعدل هذا الموضوع من خلال برنامج بُرمج عبر لغة برمجة وأنت تقرأه على الإنترنت باستخدام برنامج (المتصفح) وربما رأيته على مواقع التواصل الاجتماعي وكُلها برامج أيضًا. ومما لا شك فيه أن تعلم البرمجة أصبح ضرورة مُلحة في هذا العصر بل إن تعلمك لها سيزيد من فرصك بشكل كبير في الحصول على عمل. ولقد تحدثنا في مقالٍ سابق عن كيفية تعلم البرمجة والدخول إلى هذا المجال من أوسع أبوابه (إن كنت حديث عهدٍ في البرمجة أو تخطط للبدء بها، فننصحك بقراءته قبل إكمال هذا المقال) وسوف نتحدث في هذا المقال عن أكثر المهارات صعوبةً في احتراف البرمجة ألا وهي «حل المشاكل». حل المشكلات وارتباطها بالبرمجة لطالما وقفنا حائرين أمام مشكلةٍ ما ونسأل أنفسنا ماهي الطريقة الصحيحة للخروج من هذا المأزق؟ هل ستكون طريقة الحلّ التي أتبعها مشابهة للطريقة التي يتبعها المبرمجين المحترفين؟ كيف أستطيع أن أفكر مثلما يفكر المبرمجين المحترفين؟ في البداية وقبل الخوض في التفاصيل دعنا نُعرف البرمجة بحد ذاتها ولنذهب للمقال السابق ونلقي نظرة سريعة عليها: نلاحظ أن التعريف السابق صحيح ولكنه مُقْتضَب ولا يقدم لنا المعنى الكامل والدقيق للبرمجة لذا لابدّ لنا من تعريفٍ أكثر دقة وموضوعية يساعدنا في فهم هذا المقال. يعرف موقع HackerRank في تقريره عن مهارات المطورين بعام 2018: نستنتج مما سبق أن البرمجة تعتمد اعتمادًا أساسيًا على التفكير المنطقي والرياضي والقدرة على حلّ المشاكل وإن لغات البرمجة ما هي إلا وسيلة للتخاطب مع الحاسوب. إذن الأمر كله يتعلق بتطوير قدرتك في حلّ المشاكل وجعل هذه العملية سهلة وسلسة بنفس الوقت لذا فاسمح لي بأن آخذك معي برحلة صغيرة في هذا المقال نتعرف فيها على أهمية حلّ المشاكل وضرورتها في مشوارك البرمجي. لماذا حلّ المشاكل مهم؟ تأتي أهمية حل المشاكل من كونها من أكثر المهارات المطلوبة عالميًا فوفقًا لتقرير أصدره موقع HackerRank جاء فيه: احتلت مهارة حلّ المشاكلالمرتبة الأولى بنسبة 94.9% لأكثر مهارة مطلوبة لأصحاب الشركات سواء الصغيرة منها أو الكبيرة. وعلى الصعيد العملي، إن عملية بناء أي شيء من الصفر سواء أكانت آلة معينة أو أي مُنتج جديد ستواجه الكثير من المشاكل في البداية، فعلى سبيل المثال بناء خدمات أمازون السحابية (AWS)، والّتي جاءت حلًا لمشكلة النفقات العالية للبنية التحتية لتجارتها الإلكترونية بالإضافة إلى الوقت الطويل الّتي تحتاجه في عملية البناء والذي شكل تحدي كبير في إمكانية توسع الشركة، إلى أن جاء آندي جاسي كبير مستشاري جيف بيزوس في ذلك الوقت والذي استطاع إيجاد حلّ لهذه المشكلة ولم يتوقف عند ذلك الحد وإنما أختار تحويل هذا الحلّ إلى خط أعمال جديد تحت أسم خدمات أمازون السحابية والّتي بلغت عائداتها السنوية لعام 2018 قيمة تناهز 25 مليار دولار. نجد من التجربة السابقة أنه حصلت مشكلة فأُوجِد لها حلًا وأثناء خلق حل للمشكلة ظهرت الكثير من المشاكل الأخرى لتقع في سلسلة من المشاكل لا تنتهي. وبعد حلّ جميع المشاكل سيصبح المنتج جاهزًا للعمل، أي أن دورة حياة أي منتج سواءً أكان برمجيًا أو ماديًا ستحتوي على المشاكل، وبناءً على ذلك تكون مهارة حل المشاكل اللَبِنَة الأساسية في بناء مشوارك البرمجي، والّتي يجب علينا الإهتمام بها عند الإقدام على تعلّم البرمجة. تكون طريقة تعاملنا مع المشاكل غير منظمة وعشوائية في أغلب الأحيان، فمعظمُ المبرمجين الجُدد يَبْدَؤُونَ بحلّ أي مشكلة تُواجهُهُم بالطريقة التالية: جرّب أي حلّ للمشكلة. إذا لم ينجح الحلّ الأول حاول أن تجرّب أي حلّ آخر. إذا لم يفلح الحلّ كرر الخطوة الثانية إلى أن تصل إلى الحلّ. لا يحصل هذا الأمر مع المبرمجين فقط، وإنما يحصل مع أي شخص يواجه مشكلة ولا يستعن على حلها بالتحليل والتفكير المنطقي. في الحقيقة، قد يحالفك الحظ أحيانًا ويتم حلّ المشكلة ولكن كن حذرًا! فهذه هي الطريقة الأسوأ لحلّ المشكلات بل وإنها ستهدر وقتك بشكل كبير لذا من الأفضل استخدام طريقة منظمة توصلنا للحلّ، واسمح لي بأن أشاركك طريقة شاملة توصلك إلى حلّ أي مشكلة قد تواجهك. بناء خطة حلّ شاملة إن خطة الحلّ الشاملة هي مجموعة من الخطوات الَّتي تتبعها لحلّ أي مشكلة تواجهك، حيث تكون هذه الخطة عامة وتخصص بحسب المشكلة، وهي ليست تعليمات ثابتة وإنما مبادئ ننطلق منها جميعًا، وكلٌ منا يطبقها بأسلوبه الخاص، وفي نهاية المطاف إذا انطلقنا جميعًا من نفس المبادئ، فسنصل حكمًا على نفس جودة الحلّ أيضًا. إن هذه الخطة مؤلفة من عدة أجزاء ويناقش كلّ جزء فيها جانبًا معينًا من المشكلة إلى أن نصل للحلّ، وهي على الشكل التالي: 1. فهم المشكلة إن فهمنا للمشكلة المطروحة هي الخطوة الأكثر صعوبة في طريقنا لحلّها، بل إن أكثر المشاكل تأتي صعوبتها من عدم تمكننا من فهم عميق لها. ولكن متى تعلم بأنك استطعت فهم المشكلة؟ إذا كنت قادرًا على شرحها بكلمات واضحة وسهلة بحيث يستطيع أي شخص فهمها عندها تكون بالفعل قد فهمت المشكلة. هل تذكر عندما كنت عالقًا في مشكلة وبدأت بشرحها فوجدت أخطاء منطقية كثيرة لم تكن قد انتبهت لها من قبل؟ أغلب المبرمجين قد مروا بهذه الحالة من قبل، لذلك من الأفضل دومًا أن تكتب المشكلة الَّتي تواجهك باستخدام مخططات الحالة (State diagram وهي نوع من المخططات الَّتي تستخدم لتوصيف سلوك نظام ما) أو بأن تخبر شخص آخر عن المشكلة سواءً أكان زميل لك في الشركة أو عضو في الفريق أو أي شخص أخر. شاع بين المبرمجين استخدام البطة المطاطية في شرح أجزاء المشكلة لها لفهمها وإيجاد حل لها. يعد أسلوب البطة المطاطية في تنقيح الأخطاء من أكثر الأساليب سهولة وبساطة، إذ يضع المبرمج بطةً بجوار حاسوبه، وعند مواجهته لأي مشكلة يشرع في شرح الشيفرة البرمجية للبطة وما هي النتيجة المرتقبة من الشيفرة وموازنتها مع النتيجة الحالية وغالبًا ما يجد الخطأ أثناء شرحه. وخلاصة لهذه الخطوة أنقل إليك مقولة ألبرت أينشتاين: 2. تحليل المشكلة إن تقسيم المشكلة يلعب دورًا مهمًا في طريقك لإيجاد الحلّ، لذا حاول أن تقسّمها إلى أجزاء صغيرة ثمّ حُلّ كلَّ جزء منها على حدة ويُنصح في البداية بحلّ أسهل جزء منها ومن ثمّ الأصعب فالأصعب وهكذا إلى أن يتمّ حلّ جميع أجزائها، وبعدها إجمع هذه الأجزاء مع بعضها للحصول على الحلّ النهائي للمشكلة الأصلية (الكبيرة). منذ فترة كنا بصدد برمجة إضافة لمتصفح غوغل كروم بهدف تسهيل مهمة لموقع ما، فقررنا تجربة هذه الطريقة وبدأنا بتقسّيم المهمة على أجزاء ثم عملنا على حلّ كل جزء منها، وبعدها جمعنا هذه الأجزاء مع بعضها بعضًا لبناء الإضافة، وبالفعل كان العمل بهذه الطريقة سهلًا جدًا ومريحًا كما لم نعهده من قبل. في بعض الأحيان عندما تواجه شيفرات برمجية كتبها مبرمجون لا يتبعون مبادئ SOLID (وهي مجموعة من العادات والمبادئ الَّتي يتبعها المبرمجون للحصول على شيفرة برمجية قابلة للصيانة وسهلة التعديل والتكيف مع متطلبات المشروع المتغيرة)، وغالبًا ما تكون شيفرات أولئك المبرمجين غيرمفهمومة ومتشابكة ويطلق عليها اسم Spaghetti code (تكون هذه الشيفرات ذات بنية معقدة ومتشابكة وصعبة القراءة وغير مرتبة أي تكون مثل المعكرونة ملتوية ومتشابكة) ولنفرض أنه طُلبَ منك تعديل هذه الشيفرة أو إضافة وظائف جديدة إليها،عندها حتمًا ستواجه العديد من المشاكل في عملية تقسيم المشكلة ومعرفة أي جزء من الشيفرة البرمجية المُسبب للخطأ لذا كان الحصول على شيفرات برمجية مرنة وقابلة للتعديل هي الأرضية المشتركة بين العديد من تقنيات تبسيط الشيفرات البرمجية مثل مبادئ SOLID أو مبدأ MVC والذي ينص على تقسيم الوحدات من حيث طبيعة مهمتها إلى ثلاثة أقسام (Model-View-Controller) والبرمجة كائنية التوجه OOP (Object-Oriented Programming)، إذ أن جميعهم يهدفون إلى فصل الأكواد إلى أقسام ليسهل تطويرها وتنقيحها وصيانتها. 3. إعداد خطة للحل بعد أن فهمت وحللت المشكلة، يأتي دور وضع الخطة المناسبة للحلّ بحيث تغطي كافة الجوانب والتفاصيل للمشكلة، ولا تشرع في الحلّ من دون خطة (على أمل أن تجد الحلّ بطريقة ما) لأن المفتاح الرئيسي للوصول للحلّ هي الخطة الواضحة والمنظمة والتي تضمن وصولنا للحلّ النهائي. أعط لنفسك وقتًا لتحلّيل المشكلة وربط المعلومات المدخلة إلى البرنامج ونوعها والمعلومات الَّتي ستظهر كخرج للبرنامج وفهم سياقها وللحصول على خطة جيدة يجب عليك الإجابة على السؤال التالي: إذا أُعطي للبرنامج الدخل س، ما هي الخطوات اللازمة للحصول على الخرج ع؟ إن إجابتك على هذا السؤال سوف يحدد ماهي الخطوات اللازمة لحلّ المشكلة ومن ثَمَّ تقوم بترتيبها في خطة واضحة ومنظمة من أجل الحصول على الخرج الذي تريده. 4. مواجهة حالة السكتة البرمجية ماذا لو فرضنا أنك لم تستطع حلّ أي جزء من المشكلة، ولا حتى الأجزاء السهلة منها (وهذا قد يحدث في بعض الأحيان)، إن كثير من المبرمجين يقعون في هذه الحالة فلا يستطيعون أن يُحرزوا أي تقدم يذكر في تطوير الشيفرة البرمجية وهذا أشبه ما يمكن بالسكتة الدماغية (حيث لا يستطيع المريض القيام بأي حركة)، في الحقيقة إن هذه الحالة طبيعية جدًا ومعظمنا قد تعرض لها في بداية مشواره والاختلاف الوحيد هو أن المبرمج المحترف لديه فضول أكثر حول المشكلة ومعرفة سبب حدوثها بدلًا من أن يكون منزعجًا أو غاضبًا منها. وفي هذه الحالة هنالك حلّين يمكنك تجربتهما للخروج من هذا المأزق: 1-4. تنقيح الأخطاء (Debug) ليس المقصود هنا الأخطاء الكتابية في صياغة اللغة (Syntax errors) مثل نسيان فاصلة منقوطة أو أي خطأ في استخدام المتغيرات أو الدوال أو ما شابه ذلك من أخطاء والَّتي تقوم باكتشافها أي بيئة تطوير متكاملة (IDE وهي عبارة عن محرر شيفرة برمجية مدمج مع نظام ذكي لإكمال الكود ومصحح أخطاء). وبالطبع ليست أيضًا الأخطاء الّتي تظهر أثناء التنفيذ (Runtime Errors) والّتي تكون عادة نتيجة لفشلٍ في فتح ملف ما أو محاولة القسمة على صفر أو مثل هذه الأخطاء، وإنما المقصود هنا هو أخطاء المنطق البرمجي (Logic errors) الّتي ينفِّذ فيها البرنامج أمرًا غير الَّذي بُرمج من أجله، لذا من الأفضل أن تحاول أن تفحص الشيفرة البرمجية سطرًا سطرًا لعلك تجد هذا الخطأ، أوإذا كنت تعمل على لغاتٍ مثل (C++, C) والّتي تدعم استخدام المُنقِّح Debugger (الذي يراقب عمل البرنامج ويتحكم في تنفيذه بطريقة تستطيع فيها إيقاف تنفيذ البرنامج أو حتى تغييره في أي موضع من الشيفرة وذلك من خلال مجموعة من الأدوات الّتي يقدمها المُنقِّح، مثل: GNU Debugger) فيمكنك استخدامه لإيجاد الخطأ ومن ثَمّ إصلاحه. ملاحظة : من المنهجيات البرمجية الجيدة هي كتابة تعليقات توضيحية قبل كلّ دالة (Function) أو صنف (Class) برمجي وخُصوصًا تلك الأجزاء المعقدة منها لأن ذلك سوف يساعدك كثيرًا في عملية مراجعة الشيفرة البرمجية وتنقيحها. 2-4. مراجعة وتقييم الحلّ في كثير من الأحيان عند مواجهتنا للمشاكل وخصوصًا للكبيرة منها قد نضيع في التفاصيل الصغيرة للمشكلة الَّتي نواجهها وننسى المشكلة الرئيسية ولذلك من الأفضل دومًا أن نسأل أنفسنا هل هذه هي الطريقة الأفضل للحلّ؟ هل هنالك حلًّا عموميًا أفضل من الموجود؟ هل الشيفرة البرمجية أمثلية؟ هل الحلّ يخرق معايير الجودة المطلوبة؟ ارجع خطوة إلى الوراء وحاول أن تراها من منظور مختلف، وحتمًا ستلاحظ العديد من المشاكل التي غفلت عنها أثناء انشغالك بالتفاصيل الصغيرة. ملاحظة : هنالك طريقة أخرى يتبعها بعض المبرمجين لإعادة تقييم الحلّ وهي حذف الشيفرة البرمجية الخاطئة بالكامل وإعادة كتابتها من جديد فكثير ما يأخذ ذلك وقتًا أقل من تتبع المشكلة ذاتها وحلها. 5. البحث عن حلول عبر الإنترنت إن أغلب المشاريع البرمجية تكون متشابهة بكثيرٍ من الوظائف والخصائص، ونادرًا ما نرى مشروع ذو أفكارٍ جديدة بالكامل لذا فإن أي مشكلة برمجية تواجهها قد واجهها عدد كبير من المبرمجين من قبلك وأوجدوا لها حلولًا وشاركوها مع غيرهم، وكل ما عليك فعله هو أن تتعلم كيف تبحث عن المشكلة. وبالطبع صديقنا stackoverflow والذي يعد من أشهر منصات مشاركة الحلول البرمجية الّذي يقدم لك الحلّ الَّذي أجمع عليه أغلب، المبرمجين، ويوجد العديد من المنصات الأخرى المشابهة مثل AskUbuntu وهو النسخة العربية من موقع stackoverflow والكثير غيرهم، وحتى لو أنك قد حللت المشكلة أنصحك بتصفح الحلول الموجودة لأنك سوف تتعلم طرقًا أُخرى لحلّها قد تكون أسهل وأفضل بكثير من الحلّ الَّذي وصلت اليه. إلى الآن نكون قد ناقشنا الخطوة الأولى من الطريقة الشاملة لحلّ المشاكل والآن لننتقل إلى الخطوة الثانية. التدرب على هذه الخطة إن أي مهارة جديدة تحتاج إلى تدريبٍ مُمنهجٍ ومستمرٍ حتى تتقنها. لذا لا بدّ لك من وضع خطة واضحة للتدريب وتخصيص زمن محدد وثابت تقضيه في صقل تلك المهارة.يمكنك البدء مثلًا بتخصيص ساعة للتدريب يوميًا لمدة شهر كامل، وبعدها توازن نفسك مع ما كنت عليه في السابق من سرعةٍ في تحديد المشكلة وجودةٍ الحل المطروح والوقت الإجمالي لحل المشكلة وبكل تأكيد ستلاحظ تحسنًا واضحًا في أدائك. وقد تساءل نفسك كيف يمكنني التدرب على حلّ المشاكل؟ في الحقيقة هنالك طريقة مفيدة جدًا أنصحك بها لتكوين قاعدة صلبة تنطلق منها، وهي على الشكل التالي. 1. التدرب على المسائل البرمجية تعد المسابقات البرمجية سواءً على مستوى الجامعة أو على مستوى القطر أو حتى على مستوى العالم مثل مسابقة ACM ICPC من أفضل الفرص للتدريب في مجال البرمجة وصقل هذه المهارة بل وتعتبر دفعة كبيرة لك في رحلتك كمبرمج ولمستقبلك المهني أيضًا، إذ تبادر العديد من الشركات العالمية لِضمّ أولئك المنافسين المتميزين إليها بعد أن أثبتوا بالفعل أنهم النخبة في مجالهم. فإن كنت تخطط للانضمام إلى هذه المسابقة فلا تتردد وبادر بالتحضير لها من الآن. ويقدم لنا الكاتب Steven Halim في كتابه Competitive Programming بعض الفوائد الَّتي نجنيها من التدرب على حلّ المشاكل البرمجية في المسابقات. السرعة في كتابة الشيفرة البرمجية كتابة الشيفرة البرمجية بسرعة في المسابقات يوفر لك الكثير من الوقت للتفكير في بقية المشاكل واختبارها لذلك نرى أغلب المبرمجين يتدربون على سرعة الكتابة على لوحة المفاتيح لينصب تركيزهم على حلّ المشكلة فقط، ولذلك من المنطقي أن تفضل الشركات الموظفين الَّذين سَبق إن شاركوا في المسابقات البرمجية لمعرفتها بسرعة إنتاجيتهم وقدرتهم على تطوير وإيصال منتج برمجي بسرعة عالية بِالْمُوازنة مع أقرانهم ممن لم يشاركوا في المسابقات. العصف الذهني وحصر الخوارزميات الممكنة لا بدّ من تحسين قدرتك على تحديد نوع المسألة بسرعة وأن تمتلك المعرفة الكافية بالخوارزميات لتتمكن من تطبيقها مباشرة على المسألة المطروحة، لذلك ينبغي على المبرمج الَّذي ينوي الانضمام إلى المسابقة أن يتمكن من جميع الخوارزميات الشائعة في المسائل البرمجية. العمل الجماعي وروح الفريق تعتمد المسابقة البرمجية على ترتيب الفرق بحسب عدد المسائل الَّتي أجابوا عليها، والوقت الَّذي استهلكوه لحلّ كُلَ مشكلة، وعدد الحلول الخاطئة الَّتي أُرسلت للحكم. وانطلاقًا من ذلك تكون فوائد العمل كفريق واحد متعددة منها إمكانية توزيع المسائل على كلّ عضو في الفريق بحيث يزداد العدد الكلي للمسائل المحلولة بتوزيعها بين بعضهم بعضًا، ومناقشة حلّ كلّ مسألة وبذلك ينقص عدد الحلول الخاطئة الَّتي قد تُرسل للحكم، وحُكمًا سينقص الوقت المستغرق لحلّ المسائل. وعلى الصعيد العملي أيضًا نجد أن طبيعة عمل المبرمجين سواءً في الشركات الصغيرة أو الكبيرة، يُطلب منهم العمل كفريق واحد، فعلى سبيل المثال منذ فترة طَلَبَ مني أحد العملاء بناء موقع ويب، وكنت عندها قد أنتهيت من بناء فريقي البرمجي. وبالفعل بدأنا العمل على الموقع و قسّمنا العمل على أجزاء فعكف كلُّ واحد منا على تطوير جزئه الخاص من الموقع، إذ استلمتُ جزء الواجهات الخلفية، وقام أحد أعضاء الفريق باستلام الواجهات الأمامية، والآخَر استلم بناء تطبيق للهواتف الّتي تعمل بنظام أندرويد وفي نهاية الأسبوع جمعنا كل الأجزاء مع بعضها بعضًا وأنهينا المشروع بوقتٍ قياسي لم نكن لنستطيع بلوغهُ لو أننا لم نعمل كفريقٍ واحد، ولذا فإن انضمامك إلى المسابقة البرمجية يجعلك تتدرب على العمل ضمن فريق قبل أن تواجهها في سوق العمل في حال أردت العمل مع أي شركة مستقبلًا. المرونة العصبية إن تدريبك المستمر على المسائل البرمجية سيؤدي إلى زيادة منطقة الحصين (المنطقة المسؤولة عن الذاكرة والتوجيهات) في الدماغ وهذا ما أثبتته الباحثة اليانور ماجواير من كلية لندن الجامعية عندما أجرت دراسة على سائقي الأجرة في مدينة لندن فقاموا بإجراء فحص بالرنين المغناطيسي الوظيفي fMRI لأدمغة السائقين الذين قضوا قرابة عامين من التدريب في سبيل تعلم كيفية التنقل في منعطفات المدينة وذلك من أجل الحصول على رخصة القيادة ومقارنتها بصور لأدمغة رجال أصحاء من نفس العمر ولا يعملون كسائقي أجرة فتبين أن منطقة الحصين أصبحت أكبر لدى السائقين، كما لاحظوا أنه كلما أمضى سائق الأجرة فترة أطول في التدريب، زاد حجم الحصين، وذلك استجابة إلى الخبرة الّتي يكتسبها السائق. والآن تخيل معي ما سيحدث في حال تدربك على حل المشاكل لمدة عام أو أكثر، سيصبح حلّك للمشاكل البرمجية عادة سهلة ومسلية خلاف ما كانت عليه من صعوبة وتعقيد. يوجد العديد من المواقع الَّتي تقدم المسائل البرمجية مثل HackerRank أو موقع TopCoder والكثير غيرهم. 2. التدرب باستخدام الألعاب نعم أنت لم تخطئ القراءة إنها الألعاب! تعد الألعاب أداة قوية جدًا لتنمية المهارات العقلية والقدرات الدماغية على التفكير والتذكر وربط المعلومات ببعضها بعضًا، حيث أن غالبية الألعاب تحتاج لتجميع المعلومات وتنظيمها بحيث تستطيع الاستفادة منها وجعلها مفتاحًا للحلّ، بل إن الركيزة الأساسية الَّتي تشترك بها كافة الألعاب هي حلّ المشاكل! بالتأكيد نحن لا نقصد هنا ألعاب الفيديو فقط وإنما ألعاب الذكاء أيضًا مثل : لعبة الشطرنج، والألغاز الرياضية، ولعبة سودوكو، ولعبة Go، والكثير من الألعاب الَّتي تندرج تحت هذا السياق تعد ألعاب مفيدة. فعند محاولتك حلّ الألغاز في Saw أنت فعليًا تقوم بحلّ المشاكل (ولكن بإطار مختلف). وتساعدنا أيضًا في انشاء سيناريوهات للحلّ وهذه المهارة مفيدة في عالم البرمجة في حال تعثرت في أسلوب حلّ معين فتغير سيناريو الحلّ وتبدأ من جديد. في الحقيقة إن الشيء المشترك بين جميع الناس الناجحين هي اكتسابهم لعادات يومية لحلّ المشاكل الصغيرة على سبيل المثال بيتر تيل (أحد مؤسسي شركة باي بال والمصنف كرابع أغنى شخص على مستوى العالم لعام 2014 بميزانية تفوق $2.2 بليون دولار) صرح بشكل رسمي أنه يلعب الشطرنج يوميًا بل وشارك في بطولات الشطرنج مرات عديدة، وإيلون ماسك (رائد الأعمال والرئيس التنفيذي لعدة شركات مثل: سبيس إكس لتصنيع مركبات الفضاء وتسلا لصناعة السيارات الكهربائية وغيرها)أكد بأنه يلعب ألعاب الفيديو والكثير غيرهم كرسوا جزءًا من وقتهم اليومي لتنمية مهارة حلّ المشاكل. ولكن يجب أن تكون حذرًا في إدارة وقت اللعب ويُفضل أن تختار الأوقات المناسبة للعب ووضع مدة زمنية مخصصة لها، وذلك لأن الهدف ليس إضاعة الوقت والتسلية فقط وإنما التدرب على حل المشاكل ولكي لا ينتهِ بك المطاف إلى قضاء اليوم بأكمله على الألعاب. الخلاصة اعتقد أنك قد كونت فكرة جيدة عن أهمية حلّ المشاكل وضرورتها في مشوارك البرمجي وكيفية بناء خطة حلّ شاملة انطلاقًا من فهم المشكلة وتحليلها ومرورًا بإعداد خطة مخصصة لكلّ مشكلة وتقسيم المشكلة إلى أجزاء ليسهل حلّها ومواجهة حالة السكتة البرمجية وكيفية التغلب عليها من خلال تنقيح الأخطاء أو مراجعة وتقييم الحلّ، وأهمية البحث عن حلول على الإنترنت لنفس المشكلة وانتهاءً بالأسلوب الصحيح للتدرب على حل المشاكل وما هي أفضل الوسائل لتحقيق ذلك سواءً بالانضمام إلى المسابقات البرمجية أو بالتدرب بإستخدام الألعاب. وختامًا، لا تتوقع أن تصبح مبرمجًا محترفًا في غضون أسبوعٍ أو شهر واحد فهذا ضرب من الخيال بل ستحتاج لحلّ الكثير من المشاكل لبناء قاعدة معرفية صلبة تمكنك من مواجهة أي مشكلة مهما كانت صعوبتها وعندها بالتأكيد سوف تستحق لقب مبرمج محترف.
  3. إن الحصول على اسم نطاق جيد لن يؤدي في كثير من الأحيان إلى زيادة عدد الزيارات إلى موقعك فحسب، بل سيسهل أيضًا تذكره - وهذا يجلب المزيد من الزيارات أيضًا. هناك كثير من الأشياء التي يجب على مصمم المواقع أن بفكر بها عندما يصمم موقع. وخصوصًا إن كانت لديه المسؤولية الكاملة عن الموقع، فيجب عليه أن يأتي باسم نطاق جيد للموقع. على الرغم من أن الكثيرين يعتقدون أن اختيار اسم جيد ليس بتلك الأهمية، إلا أن اسم النطاق مهم مثل اسم شركتك أو موقع الويب أو صفحة فيس بوك. إن العثور على اسم نطاق مثالي ليس سهلًا على الإطلاق في يومنا الحالي. كثير من النطاقات التي من الممكن أن تفكر بها إما أن تكون مستخدمة من قِبل شركة أخرى أو شخص ما اشتراها للربح أو حتى في الأعمال التجارية. غالبًا ما يمضي خبراء الويب وقتًا في العثور على اسم نطاق مناسبٍ أكثر من الوقت في تصميم هوية أو موقع ويب. العلامة التجارية تعد العلامة التجارية مفهوما مهما جدًا بالنسبة للأعمال. يوجد لكل شركة علامة تجارية، تمثل اسمها وشعارها ومخطط ألوانها وهويتها البصرية. ومع ذلك، لا نجد أن كل العلامات التجارية معروفة. وهذا هو الفرق في الوعي بالعلامة التجارية. تعتمد الشركة التي لديها وعي بالعلامة التجارية على قدرة عملائها على تذكر علامتهم التجارية والتعرف عليها في ظروف مختلفة وربطها بعناصر علامتها التجارية. وهو يتعلق برضى العملاء عن أحد المنتجات وإدراك المنتجات فور رؤيتهم للعلامة التجارية. إنه الفرق بين كوكا كولا وشركة كولا بلا اسم. أو الفرق بين منتج شركة Apple ومنتج شركة غير معروف اسمها. قبل 10 سنوات لم يكن الموضوع بهذا الحجم كما هو عليه الآن، إلّا أن اليوم إن كنت تملك شركة وتريد علامة تجارية قوية ، فإن المعرفة الأساسية في اختيار اسم نطاق لموقعك يعتبر مهمًا جدًا، كما هو الحال مع عنوان مكتبك. وحيث يمكّن الأشخاص من العثور عليك والاتصال بك. الامتدادات (Extensions) إن أكثر الامتدادات استخدامًا في العالم هي الامتدادات الثلاثة التالية com. و net. و org.. يبدو اسم النطاق مع واحدة من هذه الامتدادات مثاليًا لأي نوع من الأعمال. فاستخدام أحد الامتدادات المجانية مثل TK. قد لا يكون ناجحًا جدًا. في كثير من الأحيان لا يستطيع الزوار تذكر موقعك، لذلك هم يحاولون استخدام اسم شركتك مع هذه الامتدادات الثلاثة المشهورة. وهذا ما أفعله في كثير من الأحيان ، لذا أني أفترض أن إحدى الشركات التي سأكون مهتمًا بالتعامل معها، أو أن أحد مواقع الويب التي سأكون مهتمًا بزيارتها سيكون له واحد من هذه الامتدادات الثلاثة. وكما قلت للتو أن هذه الامتدادات ذات شعبية كبيرة، لذا يتوقع الزوار أن تستخدم الشركات هذه الامتدادات الثلاثة فقط. يقدم بعض مقدمي خدمات حجز النطاقات عروضًا لمن يشتري الامتدادات الثلاثة سيحصل على خصم. لذا فإن حصولك على الامتدادات الثلاثة سيكون مفيد جدًا لك في المستقبل - تعدّ هذه الخطوة ذكية جدًا وستضعك في موضع الصدارة. من الميزات الأخرى لاستخدام الامتدادات الثلاثة (أو واحد منها) أن أسعارهم رخيصة جدًا. ومدعومين في جميع أنحاء العالم ومن الصعب العثور على مقدم خدمات حجز النطاقات لا يبيعها. بالتأكيد أن لا أقول أنه يجب عليك أن تملك واحدًا منهم. الشريك المؤسس لووردبريس Matt Mullenweg لديه واحد من أروع أسماء النطاقات ألا وهو www.ma.Tt. نعم، لديه امتداد غريب إلا أنه يتوافق مع إسمه بشكل مثالي. إذا تمكنت من العثور على شيء ذكي مثل هذا الامتداد، فاحصل عليه مباشرة، ولكن فكر في حقيقة أن الأشخاص الذين لا يعرفون الكثير عن الويب لا يعرفون عن وجود شيء آخر غير امتدادات com. و net. و org.. وينبغي أن يكون هذا الجزء غذاء لأفكارك. ومع ذلك، يعدّ اختيار امتداد لاسم النطاق واحدًا من أسهل المهام في إنشاء علامة تجارية قوية. ولكن انتظر! هناك الكثير من الأمور التي يجب عليك متابعتها أيضًا. الموقع بالتحدث عن الإمتدادات، يعدّ الموقع شيء آخر يجب عليك التفكير فيه. إنه يعتمد بشكل كبير على نوع أعمالك والغرض منها. ويعتمد كثيرًا على الجمهور والسوق وسلوكهم. إذا كان لديك شركة دانماركية تستهدف الدنماركيين فقط، فإن وجود موقع ويب ينتهي في com. لن يكون له داعٍ لأننا نستطيع الحصول على امتداد سهل التمييز مثل dk.. جميع البلدان لديها امتدادات نطاق (Top-level Domain). وبالتأكيد dk. ليس هو الخيار الوحيد المتوفر. يُستخدم رمز البلد TLD في أغلب الأحيان للشركات والأفراد في البلد المَعني. ويكيبيديا لديها قائمة طويلة وكاملة من TLDS في جميع أنحاء العالم. من السهل ملاحظة أن بعض هذه الامتدادات يتطلب إما تسجيل شركة في البلد أو على الأقل الحصول على تصريح إقامة، لذلك فإن التسجيل عليها ليس بتلك السهولة، وخصوصًا إن كنت تتطلع أن تفعل مثلما فعل Matt في امتداد موقعه. وهو أيضا خيار للشركات التي تستهدف الدول التي لا تستخدم الأبجدية الإنجليزية، مثل الدول الآسيوية، أو العربية، أو روسيا. وتسمى IDNs (أسماء النطاقات الدولية Internationalized Domain Names) ويجب أن تستخدمها فقط لاستكمال عنوان com. (أو أي TLD آخر) وإلا فإنه سيكون مربكًا للزائرين الذين لغتهم الرئيسية الإنجليزية أو أحد الأبجديات المستخدمة في أوروبا أو أمريكا. خدع وحِيَل لقد تحدثنا عن الخدع قبل قليل وهي الأشياء الذكية التي تقوم بها لدمج اسم النطاق مع الامتداد. صدق أو لا تصدق أنه يوجد على الإنترنت أدوات مخصصة لمساعدتك في إيجاد تركيبات ممكنة لاسم موقعك وامتداده! يعدّ موقع Domai.NR من أفضل الخيارات المتوفرة للاستخدام في هذا المجال، لأنه يعطيك العديد من الخيارات في بحث بسيط. تستعمل الناس هذه الخدع ليست لأنها رائعة فحسب، بل لأنه في أغلب الأحيان يكون الأسم المناسب لشركتهم مأخوذ بالفعل وهذا محبط جدًا، وإنه يحدث في كثيرٍ من الأحيان . لأن العثور على اسم مناسب ليس سهلًا إلى هذه الدرجة. لذلك أحيانًا قد ترغب في الإطلاع على بعض الخدع. قبل الشراء رائع، الآن وجدت اسم النطاق الذي تبحث عنه وأنت مستعدٌ لشرائه. لا، أنت لست مستعد! لقد نسيت شيئًا ما. وهو تتأكد من أن اسم النطاق الخاص بك لا يؤدي بك إلى مشاكل قانونية مع شركات أخرى. تأكد من أنه ليس هنالك شركة أخرى مشابهة تقوم بنفس الأعمال التي تقوم بها. مايكروسوفت (Microsoft) ضد ميكروايسوفتيس (MikeRoweSoftis) النزاع الأكثر شعبية بشأن انتهاك اسم النطاق. حدث هذا قبل عشر سنوات تقريبًا وكانت قضية دسمة لوسائل الإعلام عندما كان مصمم المواقع الشاب مايك رو ينازع اسم نطاقه مع العملاق الأميركي بسبب تشابه اسم النطاق الخاص به مع اسم نطاق شركة مايكروسوفت. إن التقدم بطلب العلامة التجارية هو أمر تقوم به الشركات الضخمة، بما أنهم يعرفون أن مواقعهم ستكون ذات شعبية قوية بطبيعة الحال، لكن هذا أمر مكلف للغاية. وخصوصًا إذا كنت في البداية، لذا فقد ترغب في حماية اسمك بطريقة أخرى وترك فكرة شراء علامتك التجارية لوقت لاحق. بعض التقنيات التي يمكنك استخدامها تسمى الشراء بالجملة. يفضل العديد من الأفراد شراء الكثير من النطاقات ذات الأسم نفسه والامتدادات المختلفة، وإعادة توجيههم جميعًا إلى الموقع الرئيسي. خدمات Whois من الأخطاء التي يرتكبها العديد من الأفراد هي تسجيل نطاقاتهم ضمن خدمة الخصوصية WHOIS. وهذه الطريقة خطيرة للغاية، على الرغم من أنها تبدو مفيدة عندما تسمع بها لأول مرة. ولكن ماذا يحدث إذا قمت بتسجيل نطاقك ضمن خدمة خصوصية WHOIS هو أن تفاصيل الاتصال الخاصة بك مخفية. بدلاً من أن تملئ الحقول بالمعلومات الخاصة بك يجب عليك أن تملئ الحقول بالمعلومات الخاصة بالمزود الذي اشتريت من عنده. ولكن لماذا يعدّ هذا الشيء خطير؟ لأنه وفقًا لسياسات ICANN ، يكون الاسم في تفاصيل WHOIS للذي يملك النطاق (في هذه الحالة اسم الشركة الّتي اشتريت منها النطاق). هذا يعني أنه إذا تم اختراق موقعك، فلديك فرصة ضئيلة لإثبات أن النطاق هو ملكك بالفعل. إذا كان اسم المخترق في السجلات، فهو في الواقع يمتلك النطاق الذي دفعته مقابله. لذلك حتى لو كنت ترغب في حماية اسم نطاقك، لا أنصحك أن تفعل ذلك باستخدام هذه الخدمات، لأنها خطيرة جدًا. الخاتمة يمكن أن يؤدي امتلاك اسم نطاق جيد إلى تحسين تجربة المستخدم على موقع الويب الخاص بك. حتى لو كانت اليوم العديد من زيارات موقع الويب تأتي من محركات البحث والإحالات، إلا أن وجود اسم سهل للتذكر سيكون دائمًا مفيدًا. ومن المحتمل أن ينخفض نسبة الأشخاص الذين ينسون كيفية العثور عليك. ضع في حساباتك أن نطاقات المستوى الأعلى (Top-level domains) يمكن أن تساعدك في تصدر نتائج محرك البحث. وذلك لأنه يتم فهرسة ‎.com دومًا بشكل أسرع وأفضل من ‎.ru. إن قضاء الوقت في التفكير في كل التفاصيل والعثور على اسم النطاق الصحيح هو أمر سيستغرق الكثير من الوقت. ترجمة -وبتصرف- للمقال Essential Tips for Registering a New Domain Name
  4. كيف شَكّل نموذج الشلال (Waterfall)، والنموذج المرن (Agile)، وغيرها من أُطر التطوير الشكل الحالي DevOps؟ إليك ما اكتشفناه. إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟ هذه المقالة ليست مقاربة منهجية، لذا فإن كنت تبحث عن نصيحة أو مناقشة حول أفضل المنهجيات المتبعة لهندسة البرمجيات، فيمكنك التوقف عن القراءة هنا. لأننا في هذا المقال سنبحث في التسلسل التاريخي للمنهجيات منذ نشأتها إلى وقتنا الحالي وسنتعرف كيف أصبحت DevOps في مقدمة التحولات الرقمية في يومنا الحالي. لقد تطورت DevOps عبر الكثير من التجربة والخطأ، مع سعي الشركات للاستجابة لطلبات العملاء وتحسين الجودة والصمود في السوق مع ازدياد التنافسية بشكل متصاعد. ومما يزيد هذا التحدي صعوبةً هو انتقال الاقتصاد العالمي القائم على المنتجات إلى الاقتصاد العالمي القائم على الخدمات والذي أدى اتصال الناس بطرق جديدة. أصبحت دورة حياة تطوير البرمجيات المبنية على الخدمات والخدمات المصغرّة متزايدة التعقيد، كلًا من المتصلة ببعضها بعضًا و المجمعّة. لذا فإن DevOps دفعت للتطور بشكل أسرع وأكبر من أي وقت مضى، وإن سرعة التغيير هذه ستمحو المنهجيات التقليدية الأبطأ مثل نموذج الشلال (waterfall). بالتأكيد نحن لا نقلل من شأن نموذج الشلال فالعديد من المنظمات لديها أسباب وجيهة للاستمرار في استخدامه. لذا ينبغي على المنظمات الواعية أن تهدف إلى الابتعاد عن العمليات أو المنهجيات التي تُهدر الوقت، وإن الكثير من الشركات الناشئة تمتلك ميزة تنافسية على الشركات التي تستخدم نهجًا تقليديًا في عملياتها اليومية. والجدير بالذكر أن أغلب النماذج الحالية من نموذج التصميم الرشيق (Lean) ونموذج (Kanban) ونموذج التصميم المستمر (Continuous) ونموذج التصميم المرن (agile) تتتبع مبادئ وعمليات تعود إلى أوائل الأربعينات، لذا لا يمكن أن ندعي DevOps أنها فكرة جديدة كليًا. دعنا نعود بالزمن لبضع سنوات وننظر إلى نماذج تطوير البرمجيات مثل نموذج الشلال، والنموذج الرشيق، والنموذج المرن. يوضح الشكل التالي المخطط الزمني لتطور دورة حياة تطوير البرمجيات. (تذكر أننا لا نبحث عن أفضل طريقة ولكننا نحاول فهم المنحى الذي أحدث تأثيرًا إيجابيًا على هندسة البرمجيات والتي قمنا بتجميعها منذ 67 عامًا والتطور الذي حصل على مرِّ هذه السنوات حتى وصولنا لعقلية DevOps). نموذج الشلال التقليدي (Waterfall) من وجهة نظرنا، تأتي أقدم الممارسات من نموذج الشلال، الذي قُدم لأول مرة من قبل الدكتور وينستون دبليو رويس في ورقة نشرت في السبعينيات. يؤكد نموذج الشلال على النهج التقدم المنطقي والتتابعي من خلال مراحل جمع المتطلبات والتحليل وصياغة الشيفرة البرمجية والاختبار وهذه المراحل في إتجاه واحد أي يجب عليك إكمال كل مرحلة على حدة، وذلك باستكمال جميع المعايير المطلوبة في المرحلة وبعدها تستطيع أن تبدأ بالمرحلة التالية. يفيد نموذج الشلال في المشاريع التي تحتاج إلى تسلسلات صارمة والتي لها مجال مفصل ويمكن التنبؤ به أو المشاريع التي القائمة على الأحداث. وخلافا للاعتقاد السائد، فإنه يسمح أيضا للفرق بتجربة وإجراء تغييرات في التصميم في وقت مبكر خلال مرحلة جمع المتطلبات ومرحلة التحليل، ومراحل التصميم. نموذج التصميم الرشيق (Lean) رغم أن التصميم الرشيق يعود إلى عام 1450 في مدينة البندقية، إلا أننا سنبدأ عندما قامت تويوتا بإنشاء نظام إنتاج تويوتا، الذي طوره المهندسون اليابانيون بين عامي 1948 و 1972. ونشرت تويوتا وصفًا رسميًا للنظام في عام 1992. يستند نموذج التصميم الرشيق إلى خمسة مبادئ: القيمة ومجرى القيمة والتدفق والسحب والكمال. ويكمن جوهر هذا النهج في فهم ودعم تدفق قيم فعال والتخلص من العمليات التي لا تضيف قيمة وتعدّ هدرًا وضياعًا وتقديم قيمة مستمرة للمستخدم. ويهدف أيضًا لإسعاد المستخدمين بدون انقطاع. نموذج Kaizen تعتمد kaizen على التحسينات الإضافية وتتكون دورة حياة kaizen المراحل التالية: التخطيط ->التنفيذ->التحقق->التصحيح. وتهدف عقلية kaizen للتوجه للتحسين المستمر. طُوّر مفهوم kaizen في الأصل لتحسين تدفق وعمليات خط التجميع، وهو يضيف أيضًا قيمة عبر سلسلة التوريد. وكان نظام إنتاج تويوتا واحدًا من أوائل المنفذين لنموذج kaizen والتحسين المستمر. يعمل كل من kaizen و DevOps معا بشكل جيد في البيئات التي ينتقل فيها سير العمل من التصميم إلى الإنتاج. يركز kaizen على مجالين: التدفق (هو التوجه نحو تدفق المواد والمعلومات) العملية (وهي تعني تحسين وضعية عمل الشخص) التسليم المستمر (Continuous Delivery) وقد ألهمت kaizen تطوير العمليات والأدوات لأتمتة الإنتاج. وقد تمكنت الشركات من تسريع الإنتاج وتحسين الجودة والتصميم والبناء والاختبار والتسليم عن طريق تقليل مصادر الهدر (بما في ذلك الثقافة والعقلية) والتوجه نحو الأتمتة قدر الإمكان وذلك باستخدام الآلات والبرمجيات والروبوتات. كما أن معظم فلسفة kaizen تنطبق أيضا على الممارسات التجارية والبرمجيات غير المحدودة ونشر التسليم المستمر لمبادئ وأهداف DevOps. نموذج التصميم المرن (Agile) ظهر بيان تطوير البرمجيات المرنة في عام 2001، والذي كتبه مجموعة من الشبان الطموحين النهج المتبع في التطوير. إن النموذج المرن لا يقوم على إهمال الحيطة والحذر، أو كسر خطط التصميم، أو بناء برمجية بخشونة أو بشكل عشوائي. وإنما هو أن تكون قادر على الإنشاء والاستجابة للتغييرات. يعتمد نموذج المرن على اثني عشر مبدأً والتي تقدر الأفراد والتعاون فيما بينهم والبرمجيات الصالحة للاستعمال والتعاون مع العملاء، والاستجابة للتغيير. النموذج المرن المنضبط (Disciplined Agile Delivery) ومنذ أن ظل البيان المرن ثابتًا لمدة 20 عامًا، بحث العديد من الممارسين للنموذج عن طرق لإضافة خيارات إضافية ومخصصة إلى النهج. بالإضافة إلى ذلك، يركز البيان المرن بشكل كبير على التطوير، لذا تكونت الحاجة الماسّة إلى الحلول بدلًا من الشيفرات البرمجية أو البرمجيات وخصيصًا في بيئة التطوير السريعة اليوم. شارك سكوت أمبلر وماركس بريز في تأليف عملية تسليم المرنة المنضبطة وإطار عمل مرن ومنضبط، استنادًا إلى خبرتهما في شركة Rational و IBM والمنظمات التي تحتاج فيها الفرق إلى مزيد من الخيارات المتاحة أو الشركات التي لم تكن ذات خبرة بما يكفي لتنفيذ المنهجية الرشيقة (lean)، أو حيث لا يتناسب دورة حياة البرمجية مع سياق النهج. تأتي أهمية النموذج المرن النضبط أو ما يعرف DAD (اختصارًا للعبارة Disciplined agile delivery) و DA (اختصارًا للعبارة Disciplined agile) من أنه يسمح لنا باتخاذ قرارت حول العمليات بشكل مبسط من أجل تقديم حلول تدريجية ومتكررة. ويعتمد DAD على العديد من ممارسات تطوير البرمجيات المرنة (Agile)، بما في ذلك ممارسات Scrum، وممارسات نموذج الرشيق (Lean)، وغيرها. إن الاستخدام المكثف للنمذجة الرشيقة وإعادة تحليل، بما في ذلك تشجيع الأتمتة من خلال نموذج التطوير القائم على الاختبار TDD (اختصارًا للعبارة Test-driven Development)، والتصميم الرشيق مثل Kanban و XP و Scrum و Rup من خلال اختيار واحدة من خمس دورات حياة رشيقة، وإدخال مفاهيم هيكلية المالك (Architecture Owner)، يكتسب الممارسين لنموذج المرن مجموعة من الأفكار وطرق التفكير وعمليات وأدوات لتحقيق DevOps بنجاح. نموذج DevOps وعلى المدى الذي يمكننا أن نجمع فيه، ظهرت DevOps خلال سلسلة من DevOpsDays في بلجيكا في عام 2009، لتصبح الأساس للعديد من التحولات الرقمية. يعرّف مدير DevOps الأساسي في شركة مايكروسوفت Donovan Brown نموذج DevOps بأنه والآن لنعود إلى سؤالنا الأصلي: إذا أردت أن تحلل حمض DevOps النووي، فما الذي ستعثر عليه في تقرير أسلافها؟ إننا ننظر إلى التاريخ الذي يعود إلى 80 و48 و26 و17 عامًا، ولكن في وقتنا الحالي إن البيئة اليومية سريعة الإيقاع وغالبًا ما تكون مضطربة. بطبيعتنا نحن البشر نختبر ونجرب باستمرار ونتعلم ونتكيّف ونورّث نقاط القوة ونحل نقاط الضعف تيمّنًا بجيناتنا الوراثية. يمكنك استخدام القياس عن بعد الذي تجمعه من مشاهدة الحل الخاص بك في الإنتاج وذلك لإدارة التجارب، وتأكيد الفرضيات، وترتيب أولويات الأعمال المتراكمة لديك. بمعنى آخر، يرث Devops من مجموعة متنوعة من الأطر والمنهجيات التي أثبتت جدارتها وتطورها، ويمكّنك من تحويل ثقافتك، واستخدام المنتجات كأدوات مساعدة، والأهم من ذلك، إرضاء عملائك. إن كنت مرتاحًا مع نموذج التصميم الرشيق أو المرن، فإنك حتمًا ستستمتع بفوائد DevOps. وإن كنت تستخدم نموذج الشلال فإن عقلية DevOps ستساعدك كثير في تعزيز التطوير. نموذج eDevOps في عام 2016، صاغ Brent Reed مصطلح eDevOps (لا توجد له مراجع في Google أو ويكيبيديا حتى هذه اللحظة)، وهو يُعرف بأنه "طريقة للعمل (Way of Work) التي تجلب التحسين المستمر في الشركة بسلاسة، من خلال الأشخاص والعمليات والأدوات. وجد برانت أن النموذج المرن فشل في شركات تقنية المعلومات فالشركات التي اعتمدت تفكيرًا رشيقًا كانت لا تحقق قيمة (Value) للعملاء ولم تحقق أيضًا التركيز والسرعة التي توقعوها خبراء النموذج المرن الموثوق بهم في مجال تكنولوجيا المعلومات. وعندما شعر بالإحباط لرؤية "برج عاجي" تم فيه فصل فريق خدمات تقنية المعلومات المستقل عن فرق الدعم في مجال الهندسة والتطوير والعمليات ومكتب المساعدة، عندها طبق معرفته السابقة بنموذج التسليم الرشيق المنضبط (DAD)، وأضاف بعض الأهداف والتطبيقات العملية لمجموعة أدوات DAD، من ضمنها: التركيز على الثقافة ودفعها من خلال عقلية التحسين المستمر (Kaizen)، والجمع بين الناس حتى عندما يكونون في غرفة واحدة. السرعة من خلال الأتمتة (TDD + إعادة تحليل كل شئ ممكن)، إزالة الهدر واعتماد نهج TOGAF، أو JBGE (وهو جيد إلى حدٍ ما) من أجل التوثيق تقديم القيمة (Value) من خلال النمذجة (نمذجة التصميم) و (shift left) لتمكين الكشف عن الأنماط المتضاربة أثناء المشاركة من خلال أنماط التعاون في مستودع رقمي أكثر تنوعا واستراتيجيا حديث باستخدام خبرته مع AI في IBM، صمم برنت نموذج eDevOps الذي يقوم بشكل متزايد بأتمتة لوحات التحكم لأغراض القياس وصنع القرار بحيث يتم التحسين المستمر من خلال النشر المستمر (أتمتة العمليات من مرحلة التطوير إلى مرحلة الإنتاج) لجلب الإمكانيات الحقيقية لأي منظمة. إن برنامج التحول الفعال إلى eDevOps الذي يُبنى على التحول المنضبط إلى DevOps يُمكننا من القيام بما يلي: تحويل نظام الأعمال إلى Bizdevops) DevOps). تحويل نظام الأمن إلى SecDevOps) DevOps). تحويل نظام المعلومات إلى DataDevOps) DevOps). تقديم خدمات تقنية مترابطة بشكل خفيف والتي تجمع بين جميع أصحاب المصلحة. بناء حلول قابلة للاستخدام كل أسبوعين أو أسرع. جمع وقياس وتحليل وعرض وأتمتة الرؤية القابلة للتنفيذ من خلال عمليات DevOps من المفهوم من خلال الاستخدام المباشر للإنتاج. تحسين مستمر امتثالًا بنموذج Kaizen ونموذج الرشيق منضبط. المرحلة التالية في تطوير DevOps في النهاية هل تعدّ DevOps مجموعة من العبارات الطنانة والأفكار التقنية التي تُلقى على الشركات؟ سوف ندرك بكل تأكيد مع مرور الوقت كيف DevOps سيتقدم ويتطور. ومع ذلك، فإن حمض DevOps النووي يجب أن يستمر في النضج وأن يُنقح، ويجب أن يفهم المطورون أنه ليس الحل السحري ولا علاج لكل الأمراض والحلّ لكل المشاكل. إذن ما هي العلاقة بين DevOps وبقية النماذج السابقة DevOps != Agile != Lean Thinking != Waterfall DevOps != Tools !=Technology إن DevOps تحتوي على ممارسات من النموذج المرن (Agile) ونموذج التصميم الرشيق (Lean) ونموذج الشلال (Waterfall). ترجمة -وبتصرف- للمقال Analyzing the DNA of DevOps لصاحبيه Willy-Peter Schaub و Brent Aaron Reed