قبل أن تكتب الشيفرة البرمجية، فكر كيف تكتبها! - الجزء الأول

بسم الله الرحمن الرحيم

الحمد لله ربّ العالمين، يُحب من دعاه خفياً، ويُجيب من ناداه نجيّاً، ويزيدُ من كان منه حيِيّاً، ويكرم من كان له وفيّاً، ويهدي من كان صادق الوعد رضيّاً، الحمد لله ربّ العالمين.

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

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

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

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

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

هذه النقاط تجعل المطورين يصابون باليأس أو يشعرون بالحقد على هذه المفاهيم، كيف يمكن الوصول إليها وكيف يمكن تطبيقها، وما هي سبل تعلمها والوصول إلى الأفضل فيها...؟!، لكن يغيب عنهم أن من سار على هذا الطريق سيكون بكل تأكيد أفضل ممن لم يبدأ بعد، وأن هذه المهارة ستتطور تدريجيا مع الزمن…(وفي حديثنا هنا، نريد أن نستثني وجود شخص متخصص بال Architecture)، لأننا نتحدث عن مفهوم مهم يجب على المطورين فهمه واستيعابه…

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

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

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

بناءا على ما سبق، ينبغي عليك أن تحترم نفسك كمطور تطبيقات وأن لا تحتال على غيرك، وهذا يقودنا إلى الفقرة الثانية وهي: 

إن كثير من المطورين يكذبون على أنفسهم أو يحتالون عليها في مخادعة واضحة أن كتابة شيفرة برمجية بدون تخطيط لتسريع سير العمل هو أمر جيد!، بل على العكس تماما، هو أمر سيء جدا ولا يسرع من سير المشروع بتاتا!، وهذه الجزئية بالذات تكون نابعة عادة من نقطتين، إما أن الشركة لم تعطي الوقت الحقيقي لذلك أو تجاهلت طلبات المطورين في العمل واستخدام ال unit test مثلا أو رفدهم بكمية من المسؤوليات الغير مقبولة!، وإما أن هناك كسل أو جهل عند المطورين بأهمية كتابة شيفرة برمجية حقيقة، وفي كلا الحالتين، فالجميع هنا خاسر…، فحتى لو كانت الذريعة هي أن السوق لا ينتظر، فإن أول إصدار سيلحقه إصدار آخر لأن السوق لا ينتظر...، والخسارة التي سينالها من يفكر في هذا التفكير هي خسارة أُسية، أي تتضاعف مع كل إصدار!

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

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

.
.
.

التتمة في الجزء الثاني إن شاء الله

أنيس أبوحميد

03-02-2022

2nees.com