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

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

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

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

اقترح الدكتور أيزنهاور مصفوفة جميلة تحدد القيمة الحقيقة التي يقوم عليها أي تطبيق، ويمكن تقسيم ما يقوم عليه التطبيق ليستمر بطريقة صحيحة إلى جزئين، وهما: 

السلوك (Behavior) = أكثر ما تهتم به الإدارة أو البيزنس

المعمارية (Architecture) = أكثر ما يجب أن يهتم به المطور

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

حسب مصفوفة آيزنهاور، فإن الأولويات بالترتيب هي:

1.  important وال urgent

2. important and not urgent

3. not important and urgent

4. not important and not urgent

إن أكثر ما يتسبب في المشاكل وتدمير أي تطبيق هو حدوث تغيير في ترتيب الأولويات بحيث ما تتغير عادة ال not important and urgent لتصبح في المركز الأول...، وهذه هي المصيبة الكبرى في غالب الأمر! إن ما يطلبه البيزنس عادة ما يكون تحت شعار "Urgent" وفي نفس الوقت يتم إهمال المعمارية مع أنها "Important"، وهذا يعني اهتمام بما يقدمه التطبيق أكثر من الاهتمام بطريقة بناءه…

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

فمثلا إضافة مزية urgent مثل ال raise hand على برنامج محادثة، يلزمه بناء معمارية تناسب وجود هذه المزية وهذا important، فإذا تم تجاوز هذا ال important لأجل ال urgent فإن إضافة ال Emoji سيشكل مشكلة أكبر فيما بعد، ومستوى تعقيد أكثر = وهذا يعني تكلفة أكبر!، في حين لو أخذت ال Important حقها وتلاها ال urgent، فإن النتيجة ستكون مفرحة لكلا الطرفين، المطورين والبيزنس...

حسنا، ماذا علي أن أفعل في حالة وجود صراع بين أكثر من قسم حول مزية ما؟

الجواب باختصار "عليك أن تقاتل حتى تنتصر"!، وبكل تأكيد القتال هنا ليس قتال أسلحة وأدوات، بل قتال عقول ومحاججات!

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

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

إضافات عامة على ما سبق (في المقال الأول والثاني): 

1. احذر من وجود تكرار في الشيفرة البرمجية، ولكن أيضا احذر من وجود شيفرة برمجية تظنها مكررة وهي غير مكررة!، وذلك مثل الخوارزميات!، أي أنك عندما تتحقق من شيفرة برمجية ما أنها مكررة أو غير مكررة، تأكد من السلوك والمعنى التي تطرحه، ومن ذلك أيضا مثلا ال sql query.

2. فصل الشيفرة البرمجية لطبقات يمكن أن يتم على مستوى ال Service أو على مستوى ال Binary، أو على مستوى ال Source level، بمعنى آخر على مستوى ال Execution أو على مستوى ال deployment، أو على مستوى الشيفرة البرمجية نفسها

3. اختيار المعمارية المناسبة للمشروع تختلف باختلاف الزمان والمكان والتقنيات المقترحة، واختيارها يكون بما يناسب المشروع، لا بما يشيع بين الناس لفظه، فمثلا كثير من الناس يتابع ويفتخر ببناء نظام micro-service، لكنه فعليا قد يكون مخطئا باختيار هذا الأسلوب!، الفكرة دوما باختيار المعمارية المناسبة والمتناسقة مع المشروع ونظرته المستقبلية، وينبغي العلم بأن كل أسلوب له ميزاته وسيئاته…، وهذا يرتب عليه أن تعرف المزايا التي تحتاجها، والمشاكل التي قد تطرأ معك وهل يمكن حلها وكم التكلفة المتحققة لذلك!

4. لا يجب إهمال معمارية الشيفرة البرمجية على أي حال من الأحوال، و المعماريات تتقاطع… 

أنيس أبوحميد

07-02-2022

2nees.com