حرب البيانات والذكاء الاصطناعي: رؤية منظمة

البيانات هي السلاح الأقوى

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


---

الصراع بين القوى العظمى

الصين: تعيش في عالم رقمي معزول عن بقية العالم، وتهدف إلى حماية شعبها وخصوصياته من الهيمنة الغربية. إطلاق أدوات مثل DeepSeek ليس حباً في الخدمة المجانية، بل لضمان السيطرة المحلية على البيانات ومنع تدفقها إلى الخارج.

الغرب: يعتمد على شركات مثل OpenAI التي تمتلك مخزوناً ضخماً من البيانات يجمع معلومات مفيدة وضارة عبر السنين.



---

التكنولوجيا والحروب الحديثة

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

الاختراق المستمر: كل فرد الآن مخترق بطريقة ما عبر الهواتف الذكية. الجوال الذي تملكه وتدفع ثمنه بنفسك قد يكون بوابة لعدوك لجمع بياناتك أو التأثير عليك.



---

التوازن بين الفائدة والتكلفة

في إدارة المشاريع الكبرى، يتم دراسة التوازن بين التكلفة والفائدة. استخدام البيانات والذكاء الاصطناعي يتبع نفس المبدأ:

هل الاستثمار في التكنولوجيا يحقق أرباحاً أكبر من التكاليف؟

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



---

الأزمات التقنية: المستقبل القادم

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


---

التهديدات المستقبلية

الذكاء الاصطناعي كأداة هيمنة: الشركات التي تعتمد على الذكاء الاصطناعي بشكل كلي أو جزئي ستكتسب قوة اقتصادية وسياسية ضخمة.

الهجمات الرقمية: بدلاً من الحروب التقليدية، يمكن استخدام الذكاء الاصطناعي والبيانات كقنابل رقمية لضرب الخصوم بفعالية.



---

الخلاصة

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

Gpt

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

تشتغل backend ؟
تستخدم framework مثل لارافل ؟
في تعديل على database ؟

لا تعدل على ملفات المجريشن القديمه... افعل ميجريشن جديد عشان لا تضيع وقت على زميلك.
مثلا في حاله تعديل اسم عمود status الى is_active في جدول اليوزر:

php artisan make:migration rename_status_to_is_active_in_users_table

وتكتب الكود الي بيكون:

Schema::table('users', function (Blueprint $table) {
    $table->renameColumn('status', 'is_active
});

وال down يكون:

Schema::table('users', function (Blueprint $table) {      
    $table->renameColumn('is_active', 'status
});

عشان ال tree حق migrations ما تخرب عليكم + اي تعديل جديد في db ما يضطر فريق العمل يحذف الـ db ويفعل لها migration + seeder من جديد.

#مساعد

+ طبعا للتوضيح

ال migrations هو فقط زي tree للفريمورك عشان تعرف ايش الي تم انشاءة في db وايش الي تعدل

فيعني مش عيب او انها بلاده لو في مشروع وفيبه ملفات migrations كثير


هو اصلا دليل التقدم والتحسن... لانه انت لما تبرمج المشروع وتكتشف مشكله او نقص في db تضيفه
وهكذا...

وهذه الصورة تصف عدد ملفات الـ migrations في مشروع خاص بشركه... تقريبا 317 ملف
يعني لا تفكرو فيها كأسلوب عدد وانه لازم قليل مره (او كثير مره)

كله على حسب المشروع والتعديلات الي حصلت في DB

تطبيق الـ Change Data Capture (CDC) في Pinterest: نهج مبتكر لتحسين الأداء 🚀

الـ Change Data Capture (CDC) هو واحد من أهم الأساليب اللي بتساعد في تتبع التغييرات اللي بتحصل في قواعد البيانات بشكل لحظي. في شركة مثل Pinterest، كانت تقنية CDC حل عبقري ساعدهم في التعامل مع البيانات بشكل أكثر كفاءة وسرعة. خلونا نتكلم عن فكرة CDC بشكل أبسط ولماذا يعتبر من الأساسيات في التعامل مع البيانات.

إيش يعني CDC؟ 🤔

الـ CDC هو مجموعة من الأنماط اللي تتيح لك متابعة التغييرات في قاعدة البيانات، زي الإضافات (inserts) ✨، التحديثات (updates) 🔄، والحذف (deletes) ❌. الفكرة الأساسية في CDC هي إنه يلتقط التغييرات أول بأول في الوقت الفعلي ⏱، وده بيخلي التطبيقات قادرة على التعامل مع التحديثات بسرعة ودقة.

ليه الـ CDC مهم؟ 🤩

1. معالجة البيانات في الوقت الفعلي (Realtime):
من خلال CDC، ممكن النظام يتعامل مع البيانات بشكل فوري، وهو شيء مهم خصوصًا في التطبيقات اللي زي أنظمة الكشف عن الاحتيال 💳 أو محركات التوصية 🔍 اللي تحتاج معلومات حديثة طوال الوقت.


2. تكامل البيانات بين الأنظمة:
CDC بيسهل عملية التكامل بين الأنظمة المختلفة 🌐، يعني البيانات اللي بتتغير في نظام واحد، تقدر توصل لأنظمة تانية بسهولة، حتى لو كانت تستخدم قواعد بيانات مختلفة.


3. تقليل الحمل على الأنظمة المصدرية:
بدل ما يكون عندك حمل كبير من نقل البيانات كاملة، CDC بيكتفي بتتبع التغييرات فقط 📉، مما يعني أقل ضغط على النظام الأساسي وأداء أسرع.


4. التدقيق والامتثال:
مع CDC، تقدر تتابع كل التغييرات وتوثقها بشكل دقيق، وده مهم جدًا في حالات الـ Auditing والتأكد من الالتزام بالقوانين واللوائح 📝.



ليش اختاروا Pinterest CDC بدل من Binary Log Files؟ 🤔

1. التخصيص والمرونة:
CDC بيتيح لك تخصيص التغييرات اللي عايز تتابعها بشكل دقيق. على عكس Binary Log Files اللي بتسجل كل التغييرات، حتى لو مش كلها هتحتاجها.


2. التكامل بين الأنظمة:
CDC بيسمح بمتابعة التغييرات في الأنظمة المختلفة بكل سهولة 🌍، بينما Binary Log Files بتكون موجهة في العادة لنظام واحد.


3. تحسين الأداء:
من خلال CDC، أنت مش محتاج تتابع كل العمليات، بس التغييرات، وده بيقلل الضغط على الأنظمة ويحسن الأداء بشكل عام ⚡.


4. سهولة التكامل:
CDC بتخلي عملية دمج البيانات بين الأنظمة أسهل، وده بيخليها الخيار المثالي في بيئات العمل المتطورة والمليئة بالأنظمة المختلفة 💡.



الخلاصة 📝

Pinterest استخدموا CDC بشكل مبدع علشان يحققوا تحسين كبير في الأداء وتكامل البيانات بين الأنظمة المختلفة. بينما كانت Binary Log Files موجودة في البداية، لكن CDC أثبتت أنها أكثر كفاءة ومرونة في التعامل مع التغييرات في الوقت الفعلي.

بدلاً من القلق بشأن العدد، اسأل نفسي: هل هذه الملفات مرتبة ومُنظمة؟ هل تعكس الحاجة الحقيقية للعمل؟ إذا كانت الإجابة نعم، فأنت على الطريق الصحيح، بغض النظر عن العدد شكرًا لك 🌹

من أكبر التحديات الي ستواجهه في microservices
OpenTelemetry هو إطار عمل مفتوح المصدر يهدف إلى جمع ومراقبة بيانات التتبع (Tracing)، القياسات (Metrics)، وتسجيل الأحداث (Logging) في الأنظمة الموزعة مثل Microservices.

الصراحة في الأنظمة الموزعة التواصل بين الخدمات بيكون معقد، وهنا الصعوبة الحقيقية في تتبع الأخطاء وتحليل الأداء. وهنا يجي دور OpenTelemetry اللي يعطي رؤية كاملة للنظام من خلال:

1. تتبع الطلبات بين الخدمات (Distributed Tracing):
تقدر تتابع الطلب من أول ما يدخل للنظام لين ما ينتهي، وهذا يساعدك تكتشف أي مشاكل أو نقاط ضعف.


2. قياس الأداء (Metrics):
يوفر لك بيانات تفصيلية مثل استهلاك CPU، استخدام الذاكرة، وعدد الطلبات اللي تمر بالنظام.


3. تسجيل الأحداث (Logging):
كل الأحداث اللي تصير داخل النظام يتم تسجيلها لتحليلها لاحقًا.



أهم شيء يعجبني في OpenTelemetry هو إنه:

مرن وقابل للتكامل مع أي أداة: تقدر تربطه مع أدوات مثل Jaeger، Prometheus، أو حتى Grafana.

يدعم لغات كثيرة: مثل C#, Python, Java وغيرها، يعني ما في عذر لو بتشتغل بأي لغة.

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


فكرة النظام إنه يعطيك تحكم كامل، يخلّي التحليل والتتبع عملية واضحة، ويضمن لك أداء عالي. إذا كنت بتشتغل على أنظمة موزعة، أنصحك تبدأ تستخدم OpenTelemetry، لأنه فعلاً بيغيّر طريقة مراقبتك للنظام.

من أفضل الميزات لو بتستخدم GraghQL هي عمل loosely coupling بين مبرمج ا ل backend و frontend وهذه من المشاكل الي كان تعاني منها فيسبوك ناهيك عن بقيت الميزات بس هذه الي فعلا أعجبتني

الغامضين هم الأشخاص اللي غالباً ما يحتفظوا بكل شيء لأنفسهم وما يشاركوا مشاعرهم أو أفكارهم بشكل واضح وصريح. لما تجلس معهم، تحس كأن فيه حائط بينك وبينهم، وما يكون فيه أي تفاعل حقيقي.
سمات الأشخاص الغامضين في هذه الحالة:

الصمت الزائد: دائماً يفضلوا الاستماع فقط بدون إبداء رأي أو تعليق.

قلة التفاعل: ما يشاركوا في النقاشات، حتى لو كان الموضوع يخصهم أو مهم.

عدم الوضوح: لما تسألهم سؤال مباشر، تحصل إجابات مختصرة وغالباً ما تكون غامضة أو مبهمة.

انعدام المشاركة: لا يشاركوا أي تجارب شخصية أو أفكار تقدر تتعلم منها أو تتطور من خلالها.

عدم الحماس: يظهر عليهم عدم الاهتمام أو الاكتراث لأي شيء، سواءً عن نفسك أو عن المستقبل.

أثر الغموضيين عليك:

بيخلوك تحس بعدم الراحة أو الحرج.

يقللوا من مستوى الحماس أو الإيجابية في الجلسة.

أحياناً قد تشعر وكأنك تبذل مجهوداً كبيراً لتحريك الحديث أو النقاش.

كيف تتعامل معهم؟

حاول تستفسر بطريقة مهذبة ومباشرة عن وجهات نظرهم.

إذا لاحظت إنهم ما يقدموا أي قيمة إيجابية، فكّر في تقليل الوقت اللي تقضيه معاهم.

ركّز على بناء دائرة اجتماعية من أشخاص يشجعوك ويدعموك بدلاً من استنزاف طاقتك في محاولة فهمهم أو التعامل معهم.

ستواجها بشكل كبير

كوهيجن؟ كابلنج؟ أيش القصة؟
تخيل معي: انت حر مستقل، كل اللي تحتاجه داخل بيتك. أمورك مرتبة، عايش برضا وبانسجام مع نفسك، هذه نسميها Cohesion. 🏡
لكن لو حياتك مربوطة بجارك، كل ما تحتاج حاجة تسأل عليه، وتنتظر يساعدك تحل مشاكلك، هذه نسميها Coupling. 🔗

الدرس؟
خلّي بيتك مكتفّي بخيره (High Cohesion)، وقلل علاقتك بالجيران قدر المستطاع (Weak Coupling)، عشان لو غيرت بيتك، ما تضطر تبني الحارة كلها من جديد. 🚀💡

تطبيق في البرمجة: لو عندك function، خليها مستقلة. كل اللي تحتاجه تمرّره كـ parameters أو يكون داخلها local variables. 🛠️ لو عندك class، ما تعتمد كثير على classes ثانية. اجعل الكلاس يؤدي وظيفة واضحة ومحددة. 🧩 لو عندك system، حاول تقلل الـ dependencies على الأنظمة الأخرى. 🌐 مبدأ الحياة ببساطة:

✨ "You must be high cohesion and loosely coupled!" 💪

أخي المبرمج، خليني أشرح لك العلاقة بين Domain-Driven Design (DDD) وClean Architecture بشكل عبقري ومش ممل، ولو كنت في مقيل مع أصحابك في اليمن، ما بتحتاج غير قهوة مُرّة وهذا الكلام الجميل!
القصة تبدأ من عند التعقيد:
في DDD، قالوا لك إن التعقيد في البرمجيات ينقسم لنوعين:
1️⃣ تعقيد أساسي/طبيعي (Essential Complexity):
هذا التعقيد جاي من طبيعة المجال اللي تشتغل عليه (Domain). يعني مثلاً لو تشتغل على نظام مستشفيات، بيجيك التعقيد من قوانين البزنس، مثل إدارة المرضى، أوقات الأطباء، والمواعيد... يعني وجع راس طبيعي يخص مجال العمل نفسه.
2️⃣ تعقيد صناعي/عرضي (Accidental Complexity):
هذا النوع ماله دخل بالبزنس. هو نتيجة اختيارك لتصميم غير جيد أو استخدام تقنيات معقدة بلا داعي. يعني أنت اللي "تطبخ التعقيد" بيدك في الكود 😅.
💡 DDD قالت لك نصيحة ذهبية:
"افصل بين التعقيدين دول يا بطل. لا تخلي التفاصيل التقنية (اللي تتغير) تلخبط فهمك للبزنس (اللي ثابت نسبياً)."
المشكلة: كيف ننفذ الفكرة؟
هنا DDD أعطتنا الفكرة، لكنها ما شرحت "الطبخة". فقام المطورين وقالوا:
1️⃣ خلينا نستخدم الـ Layered Architecture، بس بنقسم الطبقات بشكل أوضح كالتالي:
Domain: فيه القواعد والقوانين الخاصة بالبزنس.
Infrastructure: يتعامل مع قواعد البيانات أو الأمور التقنية المتغيرة.
Service: هو الوسيط بين البزنس والتقنية.
Presentation: واجهة المستخدم.
2️⃣ بعدها ظهرت تصاميم معمارية زي:
Hexagonal Architecture (الشكل السداسي).
Onion Architecture (شكل البصل).
وبعدين دخل العم بوب مارتن (Uncle Bob) بالساحة وقال:
"اسمعوا يا جماعة، أنا عندي اسم أفضل ورؤية أوضح: Clean Architecture."
وترك بصمته الذهبية، لما قال:
"لما تنظر للتطبيق، لازم يكون البزنس واضح وضوح الشمس. البنية التقنية الداخلية؟ خليها وراء الكواليس!"
التقاء الأفكار
كل هذه المعماريات تشترك في فكرتين رئيسيتين:
1️⃣ فصل البزنس عن التفاصيل التقنية:
وهذا بالضبط اللي نادت به DDD.
2️⃣ استخدام الـ Dependency Injection (DI):
كل شيء في طبقة الـ Domain يعتمد على واجهات (Interfaces)، والتفاصيل التقنية (مثل قواعد البيانات) يتم تطبيقها في طبقة الـ Infrastructure. والربط يتم باستخدام DI.
يعني لو بكرة حبيت تغيّر قاعدة البيانات أو تضيف تقنية جديدة، التطبيق بيظل سليم بدون ما ينكسر.
💡 الخلاصة:
DDD عطتك الفكرة، وClean Architecture نفذتها بشكل عبقري. النتيجة؟
بدل ما تغرق في "تعقيد صناعي"، صار البزنس واضح والبنية التقنية مرنة.
تخيل المشهد:
لا بصل يحرقك ولا سداسي يدوّخك، كل شيء مرتب وحلو، وكأنك تشرب قهوتك المرة في قمة جبل!
وآختمها بالنكتة:
اليوم مدرس العلوم قال:
"اللي ما يعرف عناصر الجدول الدوري ما يكلمنيش خالص."
وأنا أقولك:
"اللي ما يعرف DDD، ما يكلمنيش أصلاً!" 😅

وعاد في Architecture  يستخدم بكثره بذات في microservices  يسمى  vertical  slice Architecture    مرن جدا ومناسب ل في بعض micro خالي بالك ليست انك كيف تنظم الملفات لا غلط فادح موضوع موضوع فصل وتسهيل لعمليات الاختبارات وغيرها انتبه ان اعتقادك فقط كيف تنظم الملفات وأن المعماريات هذه هي كيف تنظم الملفات انتبه

عم الحج معي

تمام يا حبيب أخوك، خلينا نوضح نقطة مهمة جدًا عن Vertical Slice Architecture، خصوصًا في Microservices، وكيف إنها مش مجرد "طريقة لتنظيم الملفات". الموضوع أعمق من كذا بكثير. لو كنت فاكر إن المعماريات كلها بس مجرد تنظيم ملفات، فإنت بتختصر فكرة كبيرة جدًا بشكل خاطئ. 😅
إيش هي Vertical Slice Architecture؟
Vertical Slice Architecture تركّز على تقسيم التطبيق بناءً على الميزات أو الوظائف (Features) بدلًا من الطبقات التقليدية.
كل "شريحة عمودية" (Vertical Slice) تشمل كل ما تحتاجه لتنفيذ ميزة معينة، من البداية (API) للنهاية (قاعدة البيانات).
بمعنى آخر:
بدل ما تقول "عندي طبقة للعرض، طبقة للمنطق، وطبقة للبيانات"، تقول:
"عندي شريحة عمودية اسمها إضافة مستخدم، وشريحة أخرى اسمها إدارة الطلبات".
ليه Vertical Slice Architecture مرنة ومثالية للـ Microservices؟
فصل المسؤوليات بشكل كامل:
كل شريحة مستقلة بنفسها وتتعامل مع ميزة واحدة. هذا يجعل الكود خالي من التداخل.
سهولة الاختبار (Testing):
كل شريحة يمكن اختبارها كوحدة منفصلة (Unit Testing أو Integration Testing) دون التأثير على بقية التطبيق.
تحسين القابلية للتوسع (Scalability):
لو احتجت توسّع ميزة معينة، تشتغل فقط على شريحتها بدون لمس باقي النظام.
تنظيم يعتمد على الـ Domain:
بدل ما تفكر في كيف أنظم الملفات؟، تفكر في كيف أنظم الميزات بناءً على طبيعة التطبيق؟.
توافق تام مع DDD:
لأنه يعكس الفكرة الأساسية في DDD بفصل التعقيد الأساسي (Essential Complexity) عن التعقيد الصناعي (Accidental Complexity).
مغالطة تنظيم الملفات
خليني أوضحها بشيء من التفصيل:
Vertical Slice Architecture مش مجرد طريقة لتنظيم الملفات.
لو فكرت فيها كأنها "فين أحط الفولدر ده؟"، فأنت ما فهمت الفكرة.
هي بالأصح منهجية كاملة لتصميم التطبيق بحيث كل شريحة تمثل مسار مستقل من العمل (Workflow).
الملفات قد تكون جزء صغير جدًا من التنفيذ، لكن الجوهر الحقيقي هو الفصل بين الشرائح بناءً على الوظائف والتدفق الوظيفي (Workflow).
كيف تنفذ Vertical Slice Architecture؟
كل شريحة هي وحدة متكاملة:
تحتوي على:
Endpoint/API أو Command/Query لتفعيلها.
منطق العمل (Business Logic).
وصول البيانات (Data Access).
كل هذا مدمج مع بعضه لشريحة معينة.
استخدام تقنيات CQRS:
عادةً يتم استخدام CQRS (Command Query Responsibility Segregation) مع Vertical Slice، حيث تكون الأوامر والاستعلامات مفصولة لكل شريحة.
مثال بسيط:
لو عندك ميزة اسمها "إضافة مستخدم"، الشريحة العمودية قد تحتوي:
ملف Command: مسؤول عن تنفيذ العملية.
ملف Handler: يحتوي منطق العمل الخاص بالعملية.
ملف Data Access: يتعامل مع قاعدة البيانات.
توضيح بأمثلة بسيطة
الطريقة التقليدية (Layered Architecture):
Controllers/ UserController.cs Services/ UserService.cs Repositories/ UserRepository.cs
Vertical Slice Architecture:
Features/ AddUser/ AddUserCommand.cs AddUserHandler.cs AddUserValidator.cs
الخلاصة
Vertical Slice Architecture مبنية على فصل المسؤوليات وتبسيط التطبيق من خلال تقسيمه بناءً على الوظائف بدلًا من الطبقات.
فهمك لهذا النمط كـ "طريقة لتنظيم الملفات" يعتبر خطأ فادح، لأن المعمارية تهدف لجعل الكود أكثر قابلية للتطوير، الفهم، والاختبار، وليس فقط ترتيب الملفات في الفولدرات.
ركز دائمًا على المفهوم الأساسي:

"كيف أفصل الوظائف في التطبيق بشكل يسهل العمل عليها مستقلًا عن بقية الأجزاء؟"

ختامًا، إذا كنت في مقيل مع أصحابك، قل لهم:
"لو ما تعرفش Vertical Slice Architecture، خلّيك في الكبسة وما تدخل في النقاش!" 😅

🛑🚦 مفقودات

العلاقات بين الكائنات: كيف تحوّل الكود إلى قصة؟
دعني أخبرك سرًا صغيرًا، العلاقات بين الكائنات في البرمجة تشبه العلاقات البشرية تمامًا. هناك تواصل مؤقت، وهناك صداقات طويلة الأمد، وهناك علاقات لا تنفصم أبدًا. والآن، لنضع هذا في سياق البرمجة الكائنية بأسلوب جديد يجعلك تشعر بأنك تحكي قصة حياتك!
1. Association (علاقة التعارف العابرة):
تخيّل أنك تتعرف على شخص في رحلة قصيرة، تتعاونان لإنجاز مهمة، ثم تودّعانه إلى الأبد.
هذه العلاقة البسيطة هي مثلما يحدث في البرمجة عندما "يتفاعل كائنان دون التزام مستقبلي".
🔹 مثال من الحياة البرمجية:
في نظام حجوزات السفر:
العميل (Customer) يتواصل مع الحجز (Booking) لإتمام عملية الحجز، لكن كلًّا منهما يمكن أن يستمر بدون الآخر.
🔑 النصيحة: استخدم Association عندما تحتاج إلى علاقة عابرة بدون مسؤوليات طويلة المدى.
2. Aggregation (علاقة "الاحتفاظ بالمسافة"):
تصوّر أن لديك مكتبة ضخمة مليئة بالكتب. يمكنك تغيير أو إزالة الكتب دون أن تتأثر المكتبة نفسها. هذه العلاقة هي "صداقات مرنة".
🔹 مثال من الحياة البرمجية:
في نظام المدارس:
المدرسة (School) تحتوي على مجموعة من المدرسين (Teachers)، لكن لو أُغلقت المدرسة، يمكن للمدرسين العمل في أماكن أخرى.
🔑 النصيحة: استخدم Aggregation عندما تحتاج إلى علاقة "has-a" مع استقلالية الطرفين.
3. Composition (علاقة "لا أستطيع العيش بدونك"):
تخيّل منزلك. إذا اختفى المنزل، ستختفي غرفه معه. إنها علاقة "حياة أو موت". الكائن الرئيسي يحدد مصير الكائن التابع.
🔹 مثال من الحياة البرمجية:
في نظام تصميم المنازل:
المنزل (House) يحتوي على غرف (Rooms). لو تم حذف المنزل، ستختفي الغرف تلقائيًا معه.
🔑 النصيحة: استخدم Composition عندما تكون دورة حياة الكائن التابع مرتبطة بالكامل بالكائن الرئيسي.
مفاجأة العلاقة المخفية:
هناك علاقة غير مكتوبة غالبًا ما نتجاهلها: علاقة التوازن.
عندما تبدأ في كتابة كودك، اسأل نفسك:
هل هذه العلاقة ضرورية أصلًا؟
ما تأثيرها على مرونة النظام؟
كيف ستؤثر على الاختبارات المستقبلية؟
نظرة جديدة على العلاقات:
لتجعل علاقاتك البرمجية مذهلة:
لا تجعل الكائنات "تتعلق ببعضها" أكثر مما يجب.
احترم دورة حياة كل كائن.
اكتب كودًا يحكي قصة منطقية، بحيث إذا قرأه شخص غريب عن المشروع، يستطيع فهمه كما لو كان يشاهد فيلمًا مشوقًا.
هل ترى كيف أصبحت العلاقات بين الكائنات لعبة فنية؟ اختر العلاقة المناسبة لتصميم كودك كأنك تختار شريك حياة!

نموذج 🛑🛑




العلاقات بين الكائنات: من الكود إلى الأبعاد الموازية
في عالم البرمجة الكائنية، تخيل أنك لست مبرمجًا، بل مهندسًا في محاكاة للأكوان. الكائنات ليست مجرد صفوف برمجية، بل هي عوالم متكاملة تربطها قوانين تشبه قوانين الفيزياء. اليوم، سأقدم لك العلاقات بين الكائنات كما لو كنت تكتب دستورًا لعالم موازٍ:
1. Association: الجسور بين الأكوان
تخيل أن الأكوان المختلفة يمكن أن تتواصل عبر جسور مؤقتة. الجسر ليس جزءًا من أي كون، لكنه وسيلة لمرور المعلومات.
🔹 التفسير البرمجي:
عندما يتفاعل كائنان دون أي التزام مستقبلي، فهذا جسر عابر بين الأكوان.
مثال:
العميل (Customer) يعبر الجسر للتواصل مع الحجز (Booking)، ثم يعود لعالمه الخاص.
🔑 القانون:
لا تترك الجسر مفتوحًا بعد انتهاء المهمة. حافظ على استقلالية الأكوان.
2. Aggregation: مدن تحت إدارة واحدة
تخيل مدنًا مستقلة، لكن لها حكومة مشتركة. الحكومة تستطيع إدارة المدن، لكن المدن تظل قائمة حتى لو انهارت الحكومة.
🔹 التفسير البرمجي:
عندما يحتوي كائن رئيسي على كائنات تابعة مستقلة عنه، يكون هذا اتحادًا إداريًا.
مثال:
المدرسة (School) تدير المدرسين (Teachers)، لكن المدرسين يظلون يعملون حتى لو اختفت المدرسة.
🔑 القانون:
اترك للمدن حريتها، ولا تفرض سيطرة مطلقة.
3. Composition: نظام الخلايا العضوية
تخيل كائنًا بيولوجيًا، حيث تكون الخلايا جزءًا لا يتجزأ من الجسم. إذا مات الجسم، تتحلل الخلايا تلقائيًا.
🔹 التفسير البرمجي:
عندما يكون الكائن التابع جزءًا لا يتجزأ من الكائن الرئيسي، فإنه يصبح جزءًا من دورة حياته.
مثال:
المنزل (House) يتكون من غرف (Rooms). إذا اختفى المنزل، تختفي الغرف.
🔑 القانون:
لا تفصل الخلايا عن الجسم، إلا إذا كنت تعيد بناء الكائن من جديد.
4. Inheritance: الجينات البرمجية
تخيل أنك تنشئ كائنًا يمكنه تمرير صفاته لأجيال قادمة. الوراثة هنا ليست مجرد انتقال للصفات، بل هي شكل من أشكال التطور.
🔹 التفسير البرمجي:
عندما يرث كائن صفات كائن آخر ويضيف عليها ميزاته الخاصة.
مثال:
المنتج الرقمي (DigitalProduct) يرث من المنتج الأساسي (Product) ويضيف ميزات التحميل.
🔑 القانون:
لا تنشئ شجرة جينية معقدة. حافظ على البساطة لتجنب الفوضى.
الختام: أنت خالق الأكوان البرمجية
في عام 2050، الكود ليس مجرد أداة، بل هو شكل من أشكال الفن والعلم معًا. عندما تصمم العلاقات بين الكائنات، فكر كأنك تبني عوالم متكاملة. كل قرار تتخذه هو قانون فيزيائي يؤثر على هذا العالم:
الجسور (Association) للتفاعل المؤقت.
المدن (Aggregation) للاستقلالية المنظمة.
الخلايا (Composition) للاندماج الكامل.
الجينات (Inheritance) للتطور المستمر.
تذكر، كودك ليس مجرد نص، بل كيان ينبض بالحياة!

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

١. تحقيق النتائج عبر الآخرين

يعني بدل ما تعمل كل شيء بنفسك، تتعلم تعطي مهمة، تراقب، تراجع، وتشجع فريقك ينفذ. هذا بيعلمك التفويض وإدارة الجهود بطريقة ذكية.

٢. التخطيط وتقسيم المهام

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

٣. مهارة الإنصات

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

٤. التواصل بوضوح

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

٥. التنظيم وإدارة الوقت

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

إذا كنت باحثًا قدمت إسهامًا علميًا مميزًا في مجالات الطب والصحة أو الهندسة والتكنولوجيا أو العلوم الأساسية أو الإنسانية والاجتماعية أو المياه والطاقة والغذاء أو الاقتصاد والإدارة، فرصتك الآن لتتقدم لجائزة مؤسسة عبد الحميد شومان للباحثين العرب في دورتها الـ43 لعام 2025، بقيمة 20 ألف دولار!

📅 آخر موعد لتقديم الطلبات: 31 آذار 2025
🌐 اعرف المزيد وتقدّم الآن عبر: https://bit.ly/3L3lB8c

الجائزة التي تستحقها العقول النابغة، جائزة عبد الحميد شومان للباحثين العرب!

#جائزة_عبد_الحميد_شومان #الباحثين_العرب