يعني إيه Solution Architect؟ وليه القرار أغلى من الكود

الـ AI بقى بيكتب الكود. تكتبله جملة، يرجعلك بـ API شغالة (الـ API يعني الباب اللي البرامج التانية بتكلم منه السيستم). طب لو الكود بقى بالسهولة دي، مين اللي بيقرر السيستم نفسه يتبني إزاي؟ ومين بيدفع التمن لو القرار طلع غلط؟

أنا محمد عطية، Solution Architect. والسؤال ده هو شغلي، وهو السبب إن القناة والمدونة دي موجودين.

يعني إيه Solution Architect؟

ببساطة: أنا اللي بصمّم السيستم قبل ما سطر كود يتكتب. والتصميم ده بيجاوب على تلات أسئلة. خلّينا ناخد مثلًا تطبيق توصيل أكل:

• يتقسّم لإيه؟ جزء للطلبات، وجزء للدفع، وجزء بيتابع المندوب على الخريطة. كل جزء ليه شغلانة واحدة، وفريق يقدر يفهمه ويعدّل فيه لوحده.
• أجزاءه بتكلم بعض إزاي؟ لما الدفع ينجح، جزء الطلبات يستنى رد جزء التوصيل قبل ما يقول للعميل «تمام»؟ ولا يسيبله رسالة ويكمّل، والتوصيل يشوفها لما يفضى؟ الأولى أبسط، بس لو التوصيل وقع، الطلبات هتقف معاه.
• هيستحمل قد إيه؟ الساعة اللي قبل الفطار في رمضان، لما ناس كتير جدًا بتطلب في نفس الوقت. السيستم لازم يتصمّم على اليوم ده، مش على يوم عادي الساعة 11 الصبح.

Customer ──▶ Orders ──┬──▶ Payments
                      └──▶ Delivery tracking

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

الـ architecture أصلًا يعني إيه؟

سنة 2003 كتب Martin Fowler مقال في مجلة IEEE Software اسمه «Who Needs an Architect?»، ونقل فيه تعريف من Ralph Johnson: الـ architecture هي الفهم المشترك اللي عند أشطر developers في الفريق لتصميم السيستم، يعني اتقسّم لأجزاء إزاي، والأجزاء دي بتكلم بعض إزاي. هما نفس أول سؤالين فوق.

وبعدين Fowler وصل لتعريف أبسط: الـ architecture هي «things that people perceive as hard to change»، يعني الحاجات اللي الناس شايفة إن تغييرها صعب.

مثلًا: تغيّر اسم function في الكود؟ دي حاجة سهلة ومش architecture. لكن شكل الجداول في الـ database (الـ schema)؟ Fowler بيقول إن الناس فاكرة إنه لازم يتظبط من الأول، لأن تغييره صعب، خصوصًا بعد ما السيستم يشتغل والناس تستخدمه. وبيحكي إن زميل ليه عمل طريقة تخلّي تغيير الـ schema ونقل الداتا سهل، فالـ schema بطّل يبقى architecture أصلًا. وده في رأي Fowler من أهم شغل الـ architect: يقلّل الحاجات اللي ما ينفعش ترجع فيها.

ليه القرار بقى أغلى من الكود؟

أدوات زي Claude Code (أداة من Anthropic) بتكتب الكود من وصف بالكلام العادي. وGitHub نفسها بتقول في توثيق Copilot (أداة GitHub اللي بتقترح كود وانت بتكتب) إن الكود اللي بيطلع ممكن يبان سليم وهو غلط، أو مش اللي كنت تقصده، وإن المراجعة عليك انت.

يعني الـ AI خلّى الجزء السهل في التغيير أرخص وأسرع. لكن الحاجات الصعبة في التغيير، اللي Fowler بيسميها architecture، فضلت زي ما هي. مثلًا: لو طلبت من الـ AI يعمل الطلبات والتوصيل بحيث كل واحد يستنى رد التاني، هيكتبها صح وبسرعة. والمشكلة مش هتبان غير يوم الزحمة، بعد ما الكود اتكتب واشتغل والناس بتطلب.

وعشان كده رأيي إن الكود بقى أرخص حاجة في المشروع، والغالي هو القرار. كل قرار ليه تمن، والتمن ده غالبًا بيتدفع بعدين.

هتلاقي إيه هنا كل يوم؟

حلقة قصيرة كل يوم، وكل يوم ليه سلسلة:

• السبت، كتاب في دقيقة: فكرة واحدة قوية من كل فصل في كتاب، بالترتيب. الموسم الأول كتاب Designing Data-Intensive Applications، عن السيستمات اللي شغلها الأساسي الداتا.
• الحد، مفهوم في دقيقة: مكوّن أساسي في الـ System Design (تصميم السيستمات الكبيرة) بتشبيه بسيط.
• الاتنين، الـ AI بعين مهندس: أداة أو تقنية AI: بتشتغل إزاي، ونستخدمها صح إزاي.
• التلات، Pattern في دقيقة: الـ pattern يعني حل معروف لمشكلة بتتكرر. ومعاه الغلطة اللي الناس بتقع فيها وإزاي تتجنبها.
• الأربع، صمّم X: نصمّم سيستم حقيقي: المطلوب، الأجزاء، وأهم قرار فيه، زي تصميم الـ URL shortener.
• الخميس، ترند الأسبوع: repo (مشروع كود على GitHub) أو أداة طالعة اليومين دول: بتحل إيه، معمولة إزاي من جوه، وتستخدمها ولا لأ.
• الجمعة، Paper في دقيقة: ورقة بحثية غيّرت الصناعة: المشكلة اللي كانت قبلها، الفكرة، وأثرها النهارده.

وكل حلقة ليها مقال هنا في المدونة، فيه اللي ما لحقش يتقال في دقيقة. ويوم الجمعة فيه كمان «مقال الأسبوع»، أطول، عن موضوع من الأسبوع يستاهل عمق أكتر.

إزاي تعرف إن الكلام ده صح؟

• كل معلومة ليها مصدر أساسي: الكتاب نفسه، أو الورقة البحثية، أو الـ docs الرسمية (التوثيق اللي الشركة نفسها كاتباه). والمصادر في آخر كل مقال، زي المقال ده بالظبط.
• من غير hype: يعني من غير تهويل. مفيش «الأداة دي هتقضي على X»، وأي رقم بيجي بتاريخه ومصدره.
• مش هقولك تستخدم إيه: هقولك بتكسب إيه وبتدفع إيه، وإمتى الحاجة ما تنفعش. مثلًا مقال الـ Strangler Fig هنا (إزاي تبدّل سيستم قديم حتة حتة) فيه جزء كامل اسمه «إمتى ما تستخدموش». القرار في الآخر بتاعك، لأنك انت اللي عارف السيستم بتاعك.

رأيي

الـ AI مش هيخلّي الـ architect ملوش لازمة. هيخلّي كل developer محتاج يفكر زيه.

لما كتابة الكود تبقى أرخص، هتكتب كود أكتر وأسرع، وده معناه إنك هتاخد قرارات أكتر وأسرع. وFowler في نفس المقال بيقول إن أهم حاجة بيعملها الـ architect الكويس إنه يرفع مستوى الفريق، عشان الفريق نفسه يقدر ياخد القرارات الصعبة، بدل ما كل قرار يستنى شخص واحد.

وده اللي عايز أعمله هنا: مش أديك إجابات جاهزة، أديك الأسئلة اللي تسألها لنفسك قبل ما تطلب من الـ AI أي حاجة.

المصادر

• Martin Fowler، Who Needs an Architect?، IEEE Software، يوليو/أغسطس 2003.
• Anthropic، Claude Code overview.
• GitHub Docs، Copilot: responsible use of inline suggestions.
• GitHub Docs، Copilot: best practices.