قصة تطور لغات البرمجة
في يومٍ من الأيام، كان الحاسوب لا يفهم سوى لغة واحدة فقط... لغة الأصفار والآحاد.
كان المبرمج يجلس لساعات طويلة يكتب:
01010110 00110010 11001010...
وكان أي خطأ بسيط يعني أن البرنامج لن يعمل.
ثم جاء من قال:
«"لماذا لا نعطي هذه الأرقام أسماء يسهل تذكرها؟"»
فولدت لغة التجميع (Assembly)، وأصبح المبرمج يكتب:
MOV AX, 5
ADD AX, 3
وأصبح الأمر أسهل، لكن ما زال قريبًا جدًا من لغة الحاسوب.
مرت السنوات، وظهر سؤال جديد:
«"لماذا لا نكتب بلغة أقرب إلى لغة الإنسان؟"»
فولدت اللغات عالية المستوى مثل C وJava وPython، وأصبح بإمكان المبرمج أن يكتب:
total = price * quantity
ويترك للمترجم مهمة تحويلها إلى لغة الآلة.
لكن رحلة التطور لم تتوقف.
ظهر الذكاء الاصطناعي، وقال للمبرمج:
«"لا تكتب لي الكود... فقط أخبرني بما تريد."»
فأصبح بإمكانك أن تقول:
«"أنشئ نظامًا لإدارة مدرسة يحتوي على الطلاب والمعلمين والدرجات ولوحة تحكم."»
فيقوم الذكاء الاصطناعي بتحليل الفكرة، وتصميم قاعدة البيانات، وبناء الواجهة، وكتابة الـ Backend والـ APIs والاختبارات، ثم يترجم كل ذلك حتى يصل في النهاية إلى لغة الآلة.
ثم جاء التطور الأكبر...
لم يعد الإنسان بحاجة حتى إلى الكتابة.
أصبح بإمكانه أن يتحدث فقط.
فيقول:
«"أنشئ صفحة تسجيل دخول، واجعل التصميم حديثًا، وأضف تسجيل الدخول بحساب Google، واربطها بقاعدة بيانات PostgreSQL."»
فيستمع الحاسوب إلى الصوت باستخدام Speech-to-Text، ثم يحول الكلام إلى نص، ويفهم المعنى باستخدام نماذج الذكاء الاصطناعي، ويخطط للنظام، ويكتب الكود، ويختبره، ثم يشغله.
وهكذا أصبحت رحلة البرمجة:
- 0 و1
- ثم Assembly
- ثم لغات عالية المستوى
- ثم البرمجة الوصفية
- ثم البرمجة باللغة الطبيعية
- وأخيرًا... البرمجة بالصوت.
وربما في المستقبل لن نقول للحاسوب ماذا يفعل فقط، بل سيفهم الهدف من تلقاء نفسه ويقترح أفضل الحلول، ليصبح دور المبرمج هو التفكير، والتحليل، والإبداع، بينما يتولى الذكاء الاصطناعي تنفيذ التفاصيل التقنية.
المهندس ✍️ طارق العُمري
في يومٍ من الأيام، كان الحاسوب لا يفهم سوى لغة واحدة فقط... لغة الأصفار والآحاد.
كان المبرمج يجلس لساعات طويلة يكتب:
01010110 00110010 11001010...
وكان أي خطأ بسيط يعني أن البرنامج لن يعمل.
ثم جاء من قال:
«"لماذا لا نعطي هذه الأرقام أسماء يسهل تذكرها؟"»
فولدت لغة التجميع (Assembly)، وأصبح المبرمج يكتب:
MOV AX, 5
ADD AX, 3
وأصبح الأمر أسهل، لكن ما زال قريبًا جدًا من لغة الحاسوب.
مرت السنوات، وظهر سؤال جديد:
«"لماذا لا نكتب بلغة أقرب إلى لغة الإنسان؟"»
فولدت اللغات عالية المستوى مثل C وJava وPython، وأصبح بإمكان المبرمج أن يكتب:
total = price * quantity
ويترك للمترجم مهمة تحويلها إلى لغة الآلة.
لكن رحلة التطور لم تتوقف.
ظهر الذكاء الاصطناعي، وقال للمبرمج:
«"لا تكتب لي الكود... فقط أخبرني بما تريد."»
فأصبح بإمكانك أن تقول:
«"أنشئ نظامًا لإدارة مدرسة يحتوي على الطلاب والمعلمين والدرجات ولوحة تحكم."»
فيقوم الذكاء الاصطناعي بتحليل الفكرة، وتصميم قاعدة البيانات، وبناء الواجهة، وكتابة الـ Backend والـ APIs والاختبارات، ثم يترجم كل ذلك حتى يصل في النهاية إلى لغة الآلة.
ثم جاء التطور الأكبر...
لم يعد الإنسان بحاجة حتى إلى الكتابة.
أصبح بإمكانه أن يتحدث فقط.
فيقول:
«"أنشئ صفحة تسجيل دخول، واجعل التصميم حديثًا، وأضف تسجيل الدخول بحساب Google، واربطها بقاعدة بيانات PostgreSQL."»
فيستمع الحاسوب إلى الصوت باستخدام Speech-to-Text، ثم يحول الكلام إلى نص، ويفهم المعنى باستخدام نماذج الذكاء الاصطناعي، ويخطط للنظام، ويكتب الكود، ويختبره، ثم يشغله.
وهكذا أصبحت رحلة البرمجة:
- 0 و1
- ثم Assembly
- ثم لغات عالية المستوى
- ثم البرمجة الوصفية
- ثم البرمجة باللغة الطبيعية
- وأخيرًا... البرمجة بالصوت.
وربما في المستقبل لن نقول للحاسوب ماذا يفعل فقط، بل سيفهم الهدف من تلقاء نفسه ويقترح أفضل الحلول، ليصبح دور المبرمج هو التفكير، والتحليل، والإبداع، بينما يتولى الذكاء الاصطناعي تنفيذ التفاصيل التقنية.
المهندس ✍️ طارق العُمري
يسعدني أنني أكملت تسجيلي في مؤتمر RCOY MENA 2026 🌍
المؤتمر الإقليمي للشباب حول المناخ في الشرق الأوسط وشمال أفريقيا، الذي تنظّمه فرص خضراء ومدد للتنمية ومنتدى الشباب العربي للعمل المناخي، في سلطنة عُمان.
بانتظار تجربة ملهمة مع شباب من مختلف أنحاء المنطقة. سجّلوا أنتم أيضًا!
📅 آخر موعد للتقديم: 7 أغسطس 2026
🔗 https://forms.gle/uTrfmBtJgn56p2NL7
#ننتظرك_في_مسقط
#Rcoy_Mena_2026
Happy to share that I have completed my registration for RCOY MENA 2026 🌍
The Regional Conference of Youth on Climate for the Middle East and North Africa, organized by Foras Khadra, Madad for Development and the Arab Youth Summit for Climate Action, in the Sultanate of Oman.
Looking forward to an inspiring experience with young people from across the region. Register too!
📅 Deadline: 7 August 2026
🔗 https://forms.gle/uTrfmBtJgn56p2NL7
#ننتظرك_في_مسقط
#Rcoy_Mena_2026
المؤتمر الإقليمي للشباب حول المناخ في الشرق الأوسط وشمال أفريقيا، الذي تنظّمه فرص خضراء ومدد للتنمية ومنتدى الشباب العربي للعمل المناخي، في سلطنة عُمان.
بانتظار تجربة ملهمة مع شباب من مختلف أنحاء المنطقة. سجّلوا أنتم أيضًا!
📅 آخر موعد للتقديم: 7 أغسطس 2026
🔗 https://forms.gle/uTrfmBtJgn56p2NL7
#ننتظرك_في_مسقط
#Rcoy_Mena_2026
Happy to share that I have completed my registration for RCOY MENA 2026 🌍
The Regional Conference of Youth on Climate for the Middle East and North Africa, organized by Foras Khadra, Madad for Development and the Arab Youth Summit for Climate Action, in the Sultanate of Oman.
Looking forward to an inspiring experience with young people from across the region. Register too!
📅 Deadline: 7 August 2026
🔗 https://forms.gle/uTrfmBtJgn56p2NL7
#ننتظرك_في_مسقط
#Rcoy_Mena_2026
تنظيم النظام في طبقات مستقلة
Layered Architecture
تعد Layered Architecture أو المعمارية الطبقية من أكثر الأنماط المعمارية استخدامًا في تطوير تطبيقات الويب والأنظمة المؤسسية، وتعتمد على تقسيم النظام إلى طبقات، بحيث تكون لكل طبقة مسؤولية محددة وتتواصل مع الطبقة المجاورة لها فقط.
يساعد هذا الأسلوب على تنظيم الكود، وفصل المسؤوليات، وتسهيل تطوير النظام وصيانته مع نمو المشروع.
لماذا تعد Layered Architecture مهمة؟
تجعل النظام أكثر تنظيمًا ووضوحًا.
تسهل صيانة الكود وإضافة الميزات الجديدة.
تفصل بين واجهة المستخدم، ومنطق الأعمال، والوصول إلى البيانات.
تسهل اختبار كل طبقة بشكل مستقل.
تزيد من قابلية إعادة استخدام المكونات.
تدعم العمل الجماعي بين فرق التطوير.
الطبقات الأساسية
تختلف الطبقات حسب المشروع، لكن غالبًا تتكون من:
1. Presentation Layer
مسؤولة عن التفاعل مع المستخدم، وعرض البيانات، واستقبال المدخلات، مثل صفحات الويب أو تطبيقات الهاتف.
2. Business Logic Layer
تحتوي على قواعد العمل (Business Rules)، وتعالج الطلبات، وتطبق السياسات والعمليات الخاصة بالنظام.
3. Data Access Layer
تتولى التعامل مع قواعد البيانات، وتنفيذ عمليات الإضافة، والتعديل، والحذف، والاستعلام، دون أن تعرف تفاصيل واجهة المستخدم.
4. Database Layer
تمثل قاعدة البيانات التي يتم فيها تخزين واسترجاع البيانات بشكل دائم.
كيف تعمل؟
عندما يرسل المستخدم طلبًا:
1. تستقبل Presentation Layer الطلب.
2. ترسله إلى Business Logic Layer لمعالجته.
3. إذا احتاج إلى بيانات، تتواصل Business Logic Layer مع Data Access Layer.
4. تقوم Data Access Layer بالوصول إلى قاعدة البيانات.
5. تعود النتائج عبر نفس الطبقات حتى تصل إلى المستخدم.
بهذا يبقى لكل طبقة دور واضح ومحدد.
مزايا Layered Architecture
سهولة فهم هيكل المشروع.
تقليل ترابط المكونات (Low Coupling).
زيادة ترابط كل طبقة داخليًا (High Cohesion).
سهولة استبدال أو تطوير إحدى الطبقات دون التأثير الكبير على البقية.
مناسبة لمعظم تطبيقات الأعمال (Business Applications).
التحديات
رغم بساطتها، إلا أن لها بعض التحديات:
قد تؤدي إلى انخفاض بسيط في الأداء بسبب مرور الطلب عبر عدة طبقات.
قد تصبح بعض الطبقات كبيرة جدًا إذا لم تُقسم بشكل جيد.
ليست الخيار الأمثل لبعض الأنظمة الموزعة أو ذات الأداء العالي جدًا.
متى نستخدم Layered Architecture؟
تعد مناسبة عندما:
تطور تطبيقات الويب أو تطبيقات سطح المكتب.
تبني أنظمة إدارية أو مؤسسية.
يعمل على المشروع أكثر من مطور.
تحتاج إلى بنية واضحة وسهلة الصيانة.
أما في الأنظمة المعقدة جدًا أو المبنية على الخدمات المستقلة، فقد تكون أنماط مثل Microservices أو Clean Architecture أكثر ملاءمة.
العلاقة مع مبادئ التصميم
تعتمد Layered Architecture على العديد من مبادئ هندسة البرمجيات، منها:
Separation of Concerns (SoC): فصل المسؤوليات بين الطبقات.
High Cohesion: لكل طبقة وظيفة محددة.
Low Coupling: تقليل الاعتماد المباشر بين الطبقات.
Dependency Inversion Principle (DIP): يمكن تطبيقه لتقليل اعتماد الطبقات على تفاصيل التنفيذ.
الخلاصة
تعد Layered Architecture نقطة البداية المثالية لبناء أنظمة منظمة وقابلة للصيانة. فهي تمنح المشروع هيكلًا واضحًا يسهل فهمه وتطويره مع مرور الوقت، مما يجعلها من أكثر الأنماط المعمارية شيوعًا في عالم البرمجيات.
تذكر دائمًا: عندما يعرف كل جزء من النظام مسؤوليته ويتواصل مع الطبقة المناسبة فقط، يصبح النظام أكثر استقرارًا، وأسهل في التطوير، وأكثر قابلية للتوسع.
المهندس ✍️ طارق العُمري
Layered Architecture
تعد Layered Architecture أو المعمارية الطبقية من أكثر الأنماط المعمارية استخدامًا في تطوير تطبيقات الويب والأنظمة المؤسسية، وتعتمد على تقسيم النظام إلى طبقات، بحيث تكون لكل طبقة مسؤولية محددة وتتواصل مع الطبقة المجاورة لها فقط.
يساعد هذا الأسلوب على تنظيم الكود، وفصل المسؤوليات، وتسهيل تطوير النظام وصيانته مع نمو المشروع.
لماذا تعد Layered Architecture مهمة؟
تجعل النظام أكثر تنظيمًا ووضوحًا.
تسهل صيانة الكود وإضافة الميزات الجديدة.
تفصل بين واجهة المستخدم، ومنطق الأعمال، والوصول إلى البيانات.
تسهل اختبار كل طبقة بشكل مستقل.
تزيد من قابلية إعادة استخدام المكونات.
تدعم العمل الجماعي بين فرق التطوير.
الطبقات الأساسية
تختلف الطبقات حسب المشروع، لكن غالبًا تتكون من:
1. Presentation Layer
مسؤولة عن التفاعل مع المستخدم، وعرض البيانات، واستقبال المدخلات، مثل صفحات الويب أو تطبيقات الهاتف.
2. Business Logic Layer
تحتوي على قواعد العمل (Business Rules)، وتعالج الطلبات، وتطبق السياسات والعمليات الخاصة بالنظام.
3. Data Access Layer
تتولى التعامل مع قواعد البيانات، وتنفيذ عمليات الإضافة، والتعديل، والحذف، والاستعلام، دون أن تعرف تفاصيل واجهة المستخدم.
4. Database Layer
تمثل قاعدة البيانات التي يتم فيها تخزين واسترجاع البيانات بشكل دائم.
كيف تعمل؟
عندما يرسل المستخدم طلبًا:
1. تستقبل Presentation Layer الطلب.
2. ترسله إلى Business Logic Layer لمعالجته.
3. إذا احتاج إلى بيانات، تتواصل Business Logic Layer مع Data Access Layer.
4. تقوم Data Access Layer بالوصول إلى قاعدة البيانات.
5. تعود النتائج عبر نفس الطبقات حتى تصل إلى المستخدم.
بهذا يبقى لكل طبقة دور واضح ومحدد.
مزايا Layered Architecture
سهولة فهم هيكل المشروع.
تقليل ترابط المكونات (Low Coupling).
زيادة ترابط كل طبقة داخليًا (High Cohesion).
سهولة استبدال أو تطوير إحدى الطبقات دون التأثير الكبير على البقية.
مناسبة لمعظم تطبيقات الأعمال (Business Applications).
التحديات
رغم بساطتها، إلا أن لها بعض التحديات:
قد تؤدي إلى انخفاض بسيط في الأداء بسبب مرور الطلب عبر عدة طبقات.
قد تصبح بعض الطبقات كبيرة جدًا إذا لم تُقسم بشكل جيد.
ليست الخيار الأمثل لبعض الأنظمة الموزعة أو ذات الأداء العالي جدًا.
متى نستخدم Layered Architecture؟
تعد مناسبة عندما:
تطور تطبيقات الويب أو تطبيقات سطح المكتب.
تبني أنظمة إدارية أو مؤسسية.
يعمل على المشروع أكثر من مطور.
تحتاج إلى بنية واضحة وسهلة الصيانة.
أما في الأنظمة المعقدة جدًا أو المبنية على الخدمات المستقلة، فقد تكون أنماط مثل Microservices أو Clean Architecture أكثر ملاءمة.
العلاقة مع مبادئ التصميم
تعتمد Layered Architecture على العديد من مبادئ هندسة البرمجيات، منها:
Separation of Concerns (SoC): فصل المسؤوليات بين الطبقات.
High Cohesion: لكل طبقة وظيفة محددة.
Low Coupling: تقليل الاعتماد المباشر بين الطبقات.
Dependency Inversion Principle (DIP): يمكن تطبيقه لتقليل اعتماد الطبقات على تفاصيل التنفيذ.
الخلاصة
تعد Layered Architecture نقطة البداية المثالية لبناء أنظمة منظمة وقابلة للصيانة. فهي تمنح المشروع هيكلًا واضحًا يسهل فهمه وتطويره مع مرور الوقت، مما يجعلها من أكثر الأنماط المعمارية شيوعًا في عالم البرمجيات.
تذكر دائمًا: عندما يعرف كل جزء من النظام مسؤوليته ويتواصل مع الطبقة المناسبة فقط، يصبح النظام أكثر استقرارًا، وأسهل في التطوير، وأكثر قابلية للتوسع.
المهندس ✍️ طارق العُمري
موقع رهيب يجمع أكثر من 2 مليون Skill للذكاء الاصطناعي، كلها مصنفة حسب الوظيفة والاستخدام، مع واجهة عربية تسهّل الوصول لأي مهارة بدقائق.
بصراحة، كمية الشغل اللي انعملت في جمع هذا العدد الضخم وتنظيمه وتصنيفه مشروع عملاق بحد ذاته.
رابط الموقع
https://skillsmp.com/ar/
بصراحة، كمية الشغل اللي انعملت في جمع هذا العدد الضخم وتنظيمه وتصنيفه مشروع عملاق بحد ذاته.
رابط الموقع
https://skillsmp.com/ar/
SkillsMP
Agent Skills Marketplace | Codex & Claude Skills | SkillsMP
تصفح 2M+ من Agent Skills من مستودعات GitHub العامة، بما فيها Codex Skills وClaude Skills. ابحث وقارن وافحص المصادر قبل التثبيت.
فصل البيانات عن الواجهة ومنطق التحكم
MVC
يعد MVC (Model-View-Controller) من أشهر الأنماط المعمارية في تطوير البرمجيات، ويهدف إلى فصل مسؤوليات التطبيق إلى ثلاثة مكونات رئيسية: النموذج (Model)، والعرض (View)، والمتحكم (Controller). يساعد هذا الفصل على تنظيم الكود، وتسهيل صيانته، وتحسين قابلية تطويره.
ظهر هذا النمط لأول مرة في سبعينيات القرن الماضي، ولا يزال مستخدمًا على نطاق واسع في تطبيقات الويب وسطح المكتب، كما تعتمد عليه العديد من أطر العمل الشهيرة.
مكونات MVC
1. Model
يمثل البيانات ومنطق الأعمال (Business Logic)، ويتولى التعامل مع قواعد البيانات، والتحقق من صحة البيانات، وتنفيذ العمليات الأساسية للنظام.
2. View
تمثل واجهة المستخدم، وهي المسؤولة عن عرض البيانات للمستخدم واستقبال المدخلات، دون أن تحتوي على منطق الأعمال.
3. Controller
يعمل كحلقة وصل بين Model وView، حيث يستقبل طلبات المستخدم، ويستدعي العمليات المناسبة في Model، ثم يرسل النتائج إلى View لعرضها.
كيف يعمل MVC؟
عند تنفيذ عملية داخل التطبيق، يكون تدفق العمل كالتالي:
1. يرسل المستخدم طلبًا عبر View.
2. يستقبل Controller الطلب ويحلله.
3. يستدعي Controller العمليات المناسبة في Model.
4. يعالج Model الطلب ويتعامل مع قاعدة البيانات عند الحاجة.
5. يعيد Model النتائج إلى Controller.
6. يرسل Controller البيانات إلى View لعرضها للمستخدم.
بهذا يصبح لكل مكون دور واضح ومحدد.
لماذا يعد MVC مهمًا؟
يفصل بين واجهة المستخدم ومنطق الأعمال.
يجعل الكود أكثر تنظيمًا وسهولة في الفهم.
يسهل اختبار التطبيق وصيانته.
يسمح بتطوير كل مكون بشكل مستقل.
يدعم إعادة استخدام المكونات وتقليل التكرار.
مزايا MVC
تنظيم هيكل المشروع.
سهولة إضافة ميزات جديدة.
تحسين التعاون بين فرق التطوير.
تقليل ترابط المكونات (Low Coupling).
زيادة ترابط كل مكون داخليًا (High Cohesion).
التحديات
رغم مزاياه، إلا أن MVC قد يواجه بعض التحديات:
قد يصبح Controller كبيرًا إذا احتوى على منطق أعمال كثير.
يحتاج إلى تنظيم جيد في المشاريع الكبيرة.
قد لا يكون الخيار الأمثل للتطبيقات ذات البنية المعمارية المعقدة جدًا.
أشهر أطر العمل التي تستخدم MVC
يعتمد العديد من أطر العمل على هذا النمط، منها:
ASP.NET MVC
Laravel
Ruby on Rails
Spring MVC
CodeIgniter
بينما تستخدم بعض الأطر الحديثة مفاهيم مستوحاة من MVC مع تعديلات تناسب احتياجاتها.
العلاقة مع مبادئ التصميم
يعتمد MVC على مجموعة من مبادئ هندسة البرمجيات، منها:
Separation of Concerns (SoC): فصل البيانات، والعرض، والتحكم.
High Cohesion: لكل مكون مسؤولية محددة.
Low Coupling: تقليل الاعتماد بين المكونات.
Single Responsibility Principle (SRP): يؤدي كل مكون وظيفة واحدة رئيسية.
الخلاصة
يعد MVC من أكثر الأنماط المعمارية نجاحًا وانتشارًا، لأنه يوفر طريقة واضحة لتنظيم التطبيقات وفصل مسؤولياتها. وعند تطبيقه بالشكل الصحيح، يصبح النظام أكثر قابلية للصيانة، وأسهل في الاختبار، وأكثر مرونة في التطوير.
تذكر دائمًا: عندما تفصل البيانات عن الواجهة ومنطق التحكم، فإنك تبني تطبيقًا أكثر تنظيمًا واستقرارًا، وقادرًا على النمو دون أن يتحول إلى كود معقد يصعب إدارته.
المهندس ✍️ طارق العُمري
MVC
يعد MVC (Model-View-Controller) من أشهر الأنماط المعمارية في تطوير البرمجيات، ويهدف إلى فصل مسؤوليات التطبيق إلى ثلاثة مكونات رئيسية: النموذج (Model)، والعرض (View)، والمتحكم (Controller). يساعد هذا الفصل على تنظيم الكود، وتسهيل صيانته، وتحسين قابلية تطويره.
ظهر هذا النمط لأول مرة في سبعينيات القرن الماضي، ولا يزال مستخدمًا على نطاق واسع في تطبيقات الويب وسطح المكتب، كما تعتمد عليه العديد من أطر العمل الشهيرة.
مكونات MVC
1. Model
يمثل البيانات ومنطق الأعمال (Business Logic)، ويتولى التعامل مع قواعد البيانات، والتحقق من صحة البيانات، وتنفيذ العمليات الأساسية للنظام.
2. View
تمثل واجهة المستخدم، وهي المسؤولة عن عرض البيانات للمستخدم واستقبال المدخلات، دون أن تحتوي على منطق الأعمال.
3. Controller
يعمل كحلقة وصل بين Model وView، حيث يستقبل طلبات المستخدم، ويستدعي العمليات المناسبة في Model، ثم يرسل النتائج إلى View لعرضها.
كيف يعمل MVC؟
عند تنفيذ عملية داخل التطبيق، يكون تدفق العمل كالتالي:
1. يرسل المستخدم طلبًا عبر View.
2. يستقبل Controller الطلب ويحلله.
3. يستدعي Controller العمليات المناسبة في Model.
4. يعالج Model الطلب ويتعامل مع قاعدة البيانات عند الحاجة.
5. يعيد Model النتائج إلى Controller.
6. يرسل Controller البيانات إلى View لعرضها للمستخدم.
بهذا يصبح لكل مكون دور واضح ومحدد.
لماذا يعد MVC مهمًا؟
يفصل بين واجهة المستخدم ومنطق الأعمال.
يجعل الكود أكثر تنظيمًا وسهولة في الفهم.
يسهل اختبار التطبيق وصيانته.
يسمح بتطوير كل مكون بشكل مستقل.
يدعم إعادة استخدام المكونات وتقليل التكرار.
مزايا MVC
تنظيم هيكل المشروع.
سهولة إضافة ميزات جديدة.
تحسين التعاون بين فرق التطوير.
تقليل ترابط المكونات (Low Coupling).
زيادة ترابط كل مكون داخليًا (High Cohesion).
التحديات
رغم مزاياه، إلا أن MVC قد يواجه بعض التحديات:
قد يصبح Controller كبيرًا إذا احتوى على منطق أعمال كثير.
يحتاج إلى تنظيم جيد في المشاريع الكبيرة.
قد لا يكون الخيار الأمثل للتطبيقات ذات البنية المعمارية المعقدة جدًا.
أشهر أطر العمل التي تستخدم MVC
يعتمد العديد من أطر العمل على هذا النمط، منها:
ASP.NET MVC
Laravel
Ruby on Rails
Spring MVC
CodeIgniter
بينما تستخدم بعض الأطر الحديثة مفاهيم مستوحاة من MVC مع تعديلات تناسب احتياجاتها.
العلاقة مع مبادئ التصميم
يعتمد MVC على مجموعة من مبادئ هندسة البرمجيات، منها:
Separation of Concerns (SoC): فصل البيانات، والعرض، والتحكم.
High Cohesion: لكل مكون مسؤولية محددة.
Low Coupling: تقليل الاعتماد بين المكونات.
Single Responsibility Principle (SRP): يؤدي كل مكون وظيفة واحدة رئيسية.
الخلاصة
يعد MVC من أكثر الأنماط المعمارية نجاحًا وانتشارًا، لأنه يوفر طريقة واضحة لتنظيم التطبيقات وفصل مسؤولياتها. وعند تطبيقه بالشكل الصحيح، يصبح النظام أكثر قابلية للصيانة، وأسهل في الاختبار، وأكثر مرونة في التطوير.
تذكر دائمًا: عندما تفصل البيانات عن الواجهة ومنطق التحكم، فإنك تبني تطبيقًا أكثر تنظيمًا واستقرارًا، وقادرًا على النمو دون أن يتحول إلى كود معقد يصعب إدارته.
المهندس ✍️ طارق العُمري
❤1
خلّونا اليوم نتكلم عن بديل قريب من فكرة Claude Code… بس هذي المره “حق الغلابه” 😄
معانا ومعاكم Qwen Code🔥
أكيد أغلبكم يعرف نماذج Qwen , بصراحة صارت من أقوى النماذج الفترة الأخيرة، خصوصاً في البرمجة 👨💻
الميزة الحلوة؟
تقدر تستخدم Qwen Code مجاناً عن طريق تسجيل الدخول (OAuth)، ويعطيك تقريباً 1000 طلب في اليوم— يعني تشتغل عليه طول اليوم وانت مرتاح بدون ما تدفع 💰❌
والصراحة الأداة رهيبة وعملية جداً، خصوصاً لو أنت من الناس اللي يحبوا التيرمنال 👇
🚀 مميزات Qwen Code:
✨ شغل على التيرمنال (Terminal-first)
مصمم يشتغل كامل من التيرمنال — سريع وخفيف وما فيه تعقيد
🤖 Agent ذكي للبرمجة
يفهم مشروعك كامل، يشرح لك الكود، يعدّل عليه، ويساعدك تبني features بسرعة
🔗 يدعم أكثر من مزود (Multi-Provider)
تقدر تربطه مع:
* OpenAI
* Anthropic
* Gemini
* Alibaba Cloud
🆓 خيار مجاني ممتاز
1000 طلب يومياً باستخدام Qwen OAuth
📂 يفهم المشاريع الكبيرة
تقدر تسأله:
- ايش يسوي المشروع؟
- اشرح لي الـ structure
- عدل هذا الكود
⚙️ Headless Mode
تشغّله في السكربتات أو CI/CD بدون واجهة
🧩 قابل للتوسعة (Skills & SubAgents)
تقدر تضيف له قدرات خاصة وتبني workflow كامل
⚡مفتوح المصدر
تقدر تعدل عليه وتبني فوقه اللي تبغاه
لو حد جربه قبل أو عنده تجربة، شاركونا 👇
معانا ومعاكم Qwen Code🔥
أكيد أغلبكم يعرف نماذج Qwen , بصراحة صارت من أقوى النماذج الفترة الأخيرة، خصوصاً في البرمجة 👨💻
الميزة الحلوة؟
تقدر تستخدم Qwen Code مجاناً عن طريق تسجيل الدخول (OAuth)، ويعطيك تقريباً 1000 طلب في اليوم— يعني تشتغل عليه طول اليوم وانت مرتاح بدون ما تدفع 💰❌
والصراحة الأداة رهيبة وعملية جداً، خصوصاً لو أنت من الناس اللي يحبوا التيرمنال 👇
🚀 مميزات Qwen Code:
✨ شغل على التيرمنال (Terminal-first)
مصمم يشتغل كامل من التيرمنال — سريع وخفيف وما فيه تعقيد
🤖 Agent ذكي للبرمجة
يفهم مشروعك كامل، يشرح لك الكود، يعدّل عليه، ويساعدك تبني features بسرعة
🔗 يدعم أكثر من مزود (Multi-Provider)
تقدر تربطه مع:
* OpenAI
* Anthropic
* Gemini
* Alibaba Cloud
🆓 خيار مجاني ممتاز
1000 طلب يومياً باستخدام Qwen OAuth
📂 يفهم المشاريع الكبيرة
تقدر تسأله:
- ايش يسوي المشروع؟
- اشرح لي الـ structure
- عدل هذا الكود
⚙️ Headless Mode
تشغّله في السكربتات أو CI/CD بدون واجهة
🧩 قابل للتوسعة (Skills & SubAgents)
تقدر تضيف له قدرات خاصة وتبني workflow كامل
⚡مفتوح المصدر
تقدر تعدل عليه وتبني فوقه اللي تبغاه
لو حد جربه قبل أو عنده تجربة، شاركونا 👇
❤1
الأساس الذي تقوم عليه تطبيقات الويب الحديثة
Client–Server Architecture:
تعد Client–Server Architecture أو معمارية العميل والخادم من أقدم وأكثر الأنماط المعمارية استخدامًا في تطوير البرمجيات، وتعتمد على تقسيم النظام إلى طرفين رئيسيين: العميل (Client) الذي يرسل الطلبات، والخادم (Server) الذي يستقبلها ويعالجها ثم يعيد النتائج.
تعتمد معظم تطبيقات الويب، وتطبيقات الهواتف الذكية، والأنظمة المؤسسية، والخدمات السحابية على هذا النموذج، حيث يتم فصل واجهة المستخدم عن عمليات المعالجة وتخزين البيانات.
مكونات Client–Server Architecture
1. Client (العميل)
يمثل الطرف الذي يتفاعل معه المستخدم، مثل:
متصفح الويب.
تطبيق الهاتف المحمول.
تطبيق سطح المكتب.
يقوم العميل بإرسال الطلبات إلى الخادم وعرض النتائج للمستخدم، دون تنفيذ العمليات المعقدة الخاصة بالنظام.
2. Server (الخادم)
يمثل الطرف المسؤول عن:
معالجة الطلبات.
تنفيذ منطق الأعمال (Business Logic).
إدارة قواعد البيانات.
المصادقة والتفويض (Authentication & Authorization).
إعادة الاستجابة المناسبة إلى العميل.
قد يكون الخادم تطبيقًا واحدًا أو مجموعة من الخدمات الموزعة.
كيف تعمل Client–Server Architecture؟
يمر الطلب بالمراحل التالية:
1. يرسل العميل (Client) طلبًا إلى الخادم.
2. يستقبل الخادم الطلب ويحلله.
3. ينفذ الخادم منطق الأعمال المطلوب.
4. يتواصل مع قاعدة البيانات عند الحاجة.
5. يعيد الخادم استجابة (Response) إلى العميل.
6. يعرض العميل النتيجة للمستخدم.
يتم هذا التواصل غالبًا باستخدام بروتوكولات مثل HTTP أو HTTPS، بينما تُستخدم واجهات برمجية REST API أو GraphQL أو gRPC لتبادل البيانات بين الطرفين.
لماذا تعد Client–Server مهمة؟
فصل واجهة المستخدم عن منطق الأعمال.
تسهيل إدارة البيانات بشكل مركزي.
دعم عدد كبير من المستخدمين في الوقت نفسه.
تعزيز الأمان من خلال تنفيذ العمليات الحساسة على الخادم.
تسهيل تحديث النظام دون الحاجة إلى تعديل جميع أجهزة المستخدمين.
مزايا Client–Server Architecture
مركزية إدارة البيانات.
سهولة صيانة النظام وتحديثه.
تحسين الأمان.
دعم قابلية التوسع (Scalability).
إمكانية استخدام عدة أنواع من العملاء مع نفس الخادم، مثل تطبيق ويب وتطبيق هاتف يستخدمان واجهة برمجية واحدة.
التحديات
رغم انتشارها، تواجه هذه المعمارية بعض التحديات، منها:
الاعتماد على اتصال الشبكة.
احتمال تحول الخادم إلى نقطة فشل واحدة إذا لم تُستخدم آليات التكرار (Redundancy).
الحاجة إلى موازنة الأحمال (Load Balancing) عند زيادة عدد المستخدمين.
تعقيد إدارة البنية التحتية في الأنظمة الكبيرة.
متى نستخدم Client–Server؟
تعد مناسبة عندما:
تطور تطبيقات ويب أو تطبيقات جوال.
تحتاج إلى قاعدة بيانات مركزية.
ترغب في إدارة المستخدمين والصلاحيات من مكان واحد.
يتوقع أن يستخدم النظام عدد كبير من العملاء في الوقت نفسه.
العلاقة مع الأنماط المعمارية الأخرى
تعد Client–Server Architecture أساسًا للعديد من الأنماط الحديثة، مثل:
Layered Architecture لتنظيم الخادم إلى طبقات.
MVC لفصل الواجهة عن منطق التطبيق داخل الخادم.
Microservices لتقسيم الخادم إلى خدمات مستقلة.
Clean Architecture لتنظيم منطق الأعمال بعيدًا عن تفاصيل التنفيذ.
الخلاصة
تمثل Client–Server Architecture حجر الأساس لمعظم التطبيقات الحديثة، حيث توفر فصلًا واضحًا بين واجهة المستخدم والخادم المسؤول عن المعالجة وإدارة البيانات. وعند تصميمها بطريقة صحيحة، فإنها تمنح النظام مرونة عالية، وأمانًا أفضل، وقابلية كبيرة للتوسع.
تذكر دائمًا: العميل مسؤول عن التفاعل مع المستخدم، أما الخادم فهو العقل الذي يدير البيانات وينفذ منطق الأعمال، والتعاون بينهما هو ما يجعل التطبيقات الحديثة تعمل بكفاءة.
المهندس ✍️ طارق العُمري
Client–Server Architecture:
تعد Client–Server Architecture أو معمارية العميل والخادم من أقدم وأكثر الأنماط المعمارية استخدامًا في تطوير البرمجيات، وتعتمد على تقسيم النظام إلى طرفين رئيسيين: العميل (Client) الذي يرسل الطلبات، والخادم (Server) الذي يستقبلها ويعالجها ثم يعيد النتائج.
تعتمد معظم تطبيقات الويب، وتطبيقات الهواتف الذكية، والأنظمة المؤسسية، والخدمات السحابية على هذا النموذج، حيث يتم فصل واجهة المستخدم عن عمليات المعالجة وتخزين البيانات.
مكونات Client–Server Architecture
1. Client (العميل)
يمثل الطرف الذي يتفاعل معه المستخدم، مثل:
متصفح الويب.
تطبيق الهاتف المحمول.
تطبيق سطح المكتب.
يقوم العميل بإرسال الطلبات إلى الخادم وعرض النتائج للمستخدم، دون تنفيذ العمليات المعقدة الخاصة بالنظام.
2. Server (الخادم)
يمثل الطرف المسؤول عن:
معالجة الطلبات.
تنفيذ منطق الأعمال (Business Logic).
إدارة قواعد البيانات.
المصادقة والتفويض (Authentication & Authorization).
إعادة الاستجابة المناسبة إلى العميل.
قد يكون الخادم تطبيقًا واحدًا أو مجموعة من الخدمات الموزعة.
كيف تعمل Client–Server Architecture؟
يمر الطلب بالمراحل التالية:
1. يرسل العميل (Client) طلبًا إلى الخادم.
2. يستقبل الخادم الطلب ويحلله.
3. ينفذ الخادم منطق الأعمال المطلوب.
4. يتواصل مع قاعدة البيانات عند الحاجة.
5. يعيد الخادم استجابة (Response) إلى العميل.
6. يعرض العميل النتيجة للمستخدم.
يتم هذا التواصل غالبًا باستخدام بروتوكولات مثل HTTP أو HTTPS، بينما تُستخدم واجهات برمجية REST API أو GraphQL أو gRPC لتبادل البيانات بين الطرفين.
لماذا تعد Client–Server مهمة؟
فصل واجهة المستخدم عن منطق الأعمال.
تسهيل إدارة البيانات بشكل مركزي.
دعم عدد كبير من المستخدمين في الوقت نفسه.
تعزيز الأمان من خلال تنفيذ العمليات الحساسة على الخادم.
تسهيل تحديث النظام دون الحاجة إلى تعديل جميع أجهزة المستخدمين.
مزايا Client–Server Architecture
مركزية إدارة البيانات.
سهولة صيانة النظام وتحديثه.
تحسين الأمان.
دعم قابلية التوسع (Scalability).
إمكانية استخدام عدة أنواع من العملاء مع نفس الخادم، مثل تطبيق ويب وتطبيق هاتف يستخدمان واجهة برمجية واحدة.
التحديات
رغم انتشارها، تواجه هذه المعمارية بعض التحديات، منها:
الاعتماد على اتصال الشبكة.
احتمال تحول الخادم إلى نقطة فشل واحدة إذا لم تُستخدم آليات التكرار (Redundancy).
الحاجة إلى موازنة الأحمال (Load Balancing) عند زيادة عدد المستخدمين.
تعقيد إدارة البنية التحتية في الأنظمة الكبيرة.
متى نستخدم Client–Server؟
تعد مناسبة عندما:
تطور تطبيقات ويب أو تطبيقات جوال.
تحتاج إلى قاعدة بيانات مركزية.
ترغب في إدارة المستخدمين والصلاحيات من مكان واحد.
يتوقع أن يستخدم النظام عدد كبير من العملاء في الوقت نفسه.
العلاقة مع الأنماط المعمارية الأخرى
تعد Client–Server Architecture أساسًا للعديد من الأنماط الحديثة، مثل:
Layered Architecture لتنظيم الخادم إلى طبقات.
MVC لفصل الواجهة عن منطق التطبيق داخل الخادم.
Microservices لتقسيم الخادم إلى خدمات مستقلة.
Clean Architecture لتنظيم منطق الأعمال بعيدًا عن تفاصيل التنفيذ.
الخلاصة
تمثل Client–Server Architecture حجر الأساس لمعظم التطبيقات الحديثة، حيث توفر فصلًا واضحًا بين واجهة المستخدم والخادم المسؤول عن المعالجة وإدارة البيانات. وعند تصميمها بطريقة صحيحة، فإنها تمنح النظام مرونة عالية، وأمانًا أفضل، وقابلية كبيرة للتوسع.
تذكر دائمًا: العميل مسؤول عن التفاعل مع المستخدم، أما الخادم فهو العقل الذي يدير البيانات وينفذ منطق الأعمال، والتعاون بينهما هو ما يجعل التطبيقات الحديثة تعمل بكفاءة.
المهندس ✍️ طارق العُمري
شرفونا يا شباب 👍
زورونا وتابعوا أعمال فريقنا ومشاريعنا التقنية
نشارككم رحلتنا، إنجازاتنا، وأفكارنا القادمة
وجودكم ودعمكم هو دافعنا للاستمرار.
DemoSoft - ديموسوفت
#ديموسوفت
https://www.facebook.com/share/1JFt3Voo1D/
زورونا وتابعوا أعمال فريقنا ومشاريعنا التقنية
نشارككم رحلتنا، إنجازاتنا، وأفكارنا القادمة
وجودكم ودعمكم هو دافعنا للاستمرار.
DemoSoft - ديموسوفت
#ديموسوفت
https://www.facebook.com/share/1JFt3Voo1D/
Facebook
DemoSoft - ديموسوفت
DemoSoft - ديموسوفت. 12 likes · 3 talking about this. ديموسوفت DemoSoft
شركة برمجيات متخصصة في تطوير الحلول الرقمية، تقدم خدمات تطوير الأنظمة وتطبيقات الويب والموبايل، التصميم والمونتاج، التسويق...
شركة برمجيات متخصصة في تطوير الحلول الرقمية، تقدم خدمات تطوير الأنظمة وتطبيقات الويب والموبايل، التصميم والمونتاج، التسويق...
❤1
ما يثير اهتمامنا في هندسة البرمجيات ليس بناء الأنظمة فقط، بل الاتمتة والتكامل مع الذكاء الاصطناعي مثل تصميم Workflows قادرة على اتخاذ قرارات ذكية وتحسين تجربة المستخدم بشكل حقيقي.
في إحدى تجاربنا الأخيرة قمنا بتطوير
( نظام ذكي لإدارة شكاوى العملاء) يعتمد على الذكاء الاصطناعي لأتمتة دورة معالجة الشكوى من بدايتها وحتى تقديم الرد المناسب.
معمارية النظام تعمل كالتالي:
استقبال شكوى العميل عبر نموذج إلكتروني.
تحليل محتوى الشكوى باستخدام نموذج لغوي لفهم السياق والنية.
تصنيف الشكوى وتحديد مستوى الأولوية بشكل تلقائي.
توجيهها إلى القسم أو فريق الدعم المختص.
توليد رد ذكي مخصص يناسب محتوى الشكوى قبل إرسال رسالة التأكيد للعميل.
الهدف من هذا المشروع لم يكن مجرد أتمتة المهام، بل بناء نظام يساعد فريق الدعم على التركيز في حل المشكلات بدلاً من الأعمال الروتينية، مع تقليل زمن الاستجابة وتحسين جودة الخدمة.
هذه التجربة تؤكد أن الذكاء الاصطناعي لم يعد مجرد روبوت دردشة، بل أصبح مكوناً أساسياً في تصميم الأنظمة الحديثة، حيث يمكنه التحليل، واتخاذ القرار، وتوليد الردود، ودعم فرق العمل ضمن Workflow متكامل.
وهذه مجرد بداية، فما زالت هناك الكثير من الأفكار لتطوير وكلاء ذكاء اصطناعي (AI Agents) قادرين على إدارة عمليات أعمال كاملة بكفاءة عالية.
المهندس ✍️ طارق العُمري
#SoftwareEngineering #ArtificialIntelligence #AIAgents #WorkflowAutomation #CustomerSupport #LLM #n8n #BackendEngineering #SystemDesign #DigitalTransformation
في إحدى تجاربنا الأخيرة قمنا بتطوير
( نظام ذكي لإدارة شكاوى العملاء) يعتمد على الذكاء الاصطناعي لأتمتة دورة معالجة الشكوى من بدايتها وحتى تقديم الرد المناسب.
معمارية النظام تعمل كالتالي:
استقبال شكوى العميل عبر نموذج إلكتروني.
تحليل محتوى الشكوى باستخدام نموذج لغوي لفهم السياق والنية.
تصنيف الشكوى وتحديد مستوى الأولوية بشكل تلقائي.
توجيهها إلى القسم أو فريق الدعم المختص.
توليد رد ذكي مخصص يناسب محتوى الشكوى قبل إرسال رسالة التأكيد للعميل.
الهدف من هذا المشروع لم يكن مجرد أتمتة المهام، بل بناء نظام يساعد فريق الدعم على التركيز في حل المشكلات بدلاً من الأعمال الروتينية، مع تقليل زمن الاستجابة وتحسين جودة الخدمة.
هذه التجربة تؤكد أن الذكاء الاصطناعي لم يعد مجرد روبوت دردشة، بل أصبح مكوناً أساسياً في تصميم الأنظمة الحديثة، حيث يمكنه التحليل، واتخاذ القرار، وتوليد الردود، ودعم فرق العمل ضمن Workflow متكامل.
وهذه مجرد بداية، فما زالت هناك الكثير من الأفكار لتطوير وكلاء ذكاء اصطناعي (AI Agents) قادرين على إدارة عمليات أعمال كاملة بكفاءة عالية.
المهندس ✍️ طارق العُمري
#SoftwareEngineering #ArtificialIntelligence #AIAgents #WorkflowAutomation #CustomerSupport #LLM #n8n #BackendEngineering #SystemDesign #DigitalTransformation
شرفونا يا شباب 👍
زورونا وتابعوا أعمال فريقنا ومشاريعنا التقنية
نشارككم رحلتنا، إنجازاتنا، وأفكارنا القادمة
وجودكم ودعمكم هو دافعنا للاستمرار.
DemoSoft - ديموسوفت
#ديموسوفت
https://whatsapp.com/channel/0029VbDLAQLD8SDvkVQ4MN0I
زورونا وتابعوا أعمال فريقنا ومشاريعنا التقنية
نشارككم رحلتنا، إنجازاتنا، وأفكارنا القادمة
وجودكم ودعمكم هو دافعنا للاستمرار.
DemoSoft - ديموسوفت
#ديموسوفت
https://whatsapp.com/channel/0029VbDLAQLD8SDvkVQ4MN0I
👍2
كل ما الـ Codebase تكبر، مشكلة الـ Coding Agent مش دايمًا بتكون إنه مش عارف يكتب الكود...
أحيانًا المشكلة إنه مش عارف يوصل للكود الصح.
تخيل مشروع فيه آلاف الملفات، وطلبت من الـ Agent يعدّل نظام تسجيل الدخول.
ممكن يقضي جزء كبير من الـ Context وهو بيفتح ملفات، بيدور، وبحاول يفهم وين الكود المرتبط بالمهمة.
وهون فكرة Claude Context بتكون مفيدة.
الأداة بتعمل Index للـ Repository، وبعدها بتخلي الـ Agent يبحث في الكود باستخدام وصف طبيعي للمشكلة.
يعني بدل ما تدور على كلمات محددة، ممكن تسأله:
"وين الكود المسؤول عن Authentication؟"
وهو بستخدم Hybrid Search يجمع بين البحث النصي والـ Semantic Search عشان يوصل للأجزاء الأكثر ارتباطًا.
والـ Index كمان بيتحدث بشكل تدريجي، يعني مش كل تعديل بسيط معناه إعادة معالجة المشروع كامل.
حسب الـ Evaluation المنشور من المشروع نفسه، الطريقة قللت استهلاك الـ Tokens بحوالي 40% مع الحفاظ على جودة الـ Retrieval.
والأداة بتدعم Claude Code وCodex CLI وCursor وGemini CLI وCline وWindsurf وغيرها من أدوات الـ MCP.
الفكرة اللي عجبتني فيها:
كل ما مشروعك يكبر، مش بس بدك AI يعرف يكتب...
بدك AI يعرف وين يدور قبل ما يكتب.
.
https://github.com/zilliztech/claude-context?fbclid=IwdGRjcATlpcxjbGNrBOWlxnBkb2YBZXh0bgNhZW0CMTEAc3J0YwZhcHBfaWQMMzUwNjg1NTMxNzI4AAEeAB4nI3adTWnVxE6e0CAskRBwtcVKHpxC4RPidNFtQ_zO5G0_iJoRgW1OYgw_aem_dHwTtOr8xhMBJ5JOOq4M_Q
أحيانًا المشكلة إنه مش عارف يوصل للكود الصح.
تخيل مشروع فيه آلاف الملفات، وطلبت من الـ Agent يعدّل نظام تسجيل الدخول.
ممكن يقضي جزء كبير من الـ Context وهو بيفتح ملفات، بيدور، وبحاول يفهم وين الكود المرتبط بالمهمة.
وهون فكرة Claude Context بتكون مفيدة.
الأداة بتعمل Index للـ Repository، وبعدها بتخلي الـ Agent يبحث في الكود باستخدام وصف طبيعي للمشكلة.
يعني بدل ما تدور على كلمات محددة، ممكن تسأله:
"وين الكود المسؤول عن Authentication؟"
وهو بستخدم Hybrid Search يجمع بين البحث النصي والـ Semantic Search عشان يوصل للأجزاء الأكثر ارتباطًا.
والـ Index كمان بيتحدث بشكل تدريجي، يعني مش كل تعديل بسيط معناه إعادة معالجة المشروع كامل.
حسب الـ Evaluation المنشور من المشروع نفسه، الطريقة قللت استهلاك الـ Tokens بحوالي 40% مع الحفاظ على جودة الـ Retrieval.
والأداة بتدعم Claude Code وCodex CLI وCursor وGemini CLI وCline وWindsurf وغيرها من أدوات الـ MCP.
الفكرة اللي عجبتني فيها:
كل ما مشروعك يكبر، مش بس بدك AI يعرف يكتب...
بدك AI يعرف وين يدور قبل ما يكتب.
.
https://github.com/zilliztech/claude-context?fbclid=IwdGRjcATlpcxjbGNrBOWlxnBkb2YBZXh0bgNhZW0CMTEAc3J0YwZhcHBfaWQMMzUwNjg1NTMxNzI4AAEeAB4nI3adTWnVxE6e0CAskRBwtcVKHpxC4RPidNFtQ_zO5G0_iJoRgW1OYgw_aem_dHwTtOr8xhMBJ5JOOq4M_Q
GitHub
GitHub - zilliztech/claude-context: Code search MCP for Claude Code. Make entire codebase the context for any coding agent.
Code search MCP for Claude Code. Make entire codebase the context for any coding agent. - zilliztech/claude-context