الفرق بين الـ Monorepo والـ Multirepo 💯
.
.
تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines.

المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡

هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟

كل طريقة لها ميزاتها وعيوبها، واختيارك ممكن يحسن شغلك بنسبة كبيرة أو يعقد حياتك لو اختارت الغلط.

تعال نوضح الفرق بينهم وامتى تختار الطريقة المناسبة...

———

📌 أولًا: يعني إيه Monorepo؟

الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد.

يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد.

———

📍 مميزات الـ Monorepo:

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

- إعادة استخدام الكود (Code Reusability): لو في مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من موديول، تقدر تعمله بسهولة من غير duplication.

- تنسيق أفضل بين الفرق: كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts).

- تكامل أفضل بين الأدوات: زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository.

———

📍 عيوب الـ Monorepo:

- الحجم الكبير للـ repo: مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds.

- التعقيد في إدارة الصلاحيات: صعب تقول إن فلان يقدر يشتغل على جزء معين بس من غير ما يشوف الباقي.

- مشاكل مع الـ Tools: لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build.

———

📌 ثانيًا: يعني إيه Multirepo؟

على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو موديول من المشروع يكون في Repository خاص به. يعني كل موديول بيبقى مستقل بذاته وكأنه مشروع لوحده.

———

📍 مميزات الـ Multirepo:

- كل موديول ليه حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق.

- تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه.

- لو فيه موديول أو خدمة مش مرتبط بشكل مباشر، مش محتاج تبني كل المشروع، بس تبني الجزء اللي محتاجه.

- كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل.

———

📍 عيوب الـ Multirepo:

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

- تعقيد في التنسيق بين الفرق: التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules.

- تكامل معقد للـ CI/CD: عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض.

- صعوبة في إدارة التغييرات الكبيرة: لو عندك تغيير ضخم بيأثر على أكتر من موديول، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده.

———

📌 امتى تختار مين؟

✅ اختر Monorepo لو:

1- مشروعك عبارة عن مجموعة modules مرتبطة ببعضها.

2- عندك فريق صغير أو متوسط.

3- بتحتاج تعمل تغييرات بشكل متكرر على أكتر من موديول في نفس الوقت.

4- الأدوات اللي بتستخدمها بتدعم إدارة monorepos بشكل كويس.


✅ اختر Multirepo لو:

1- مشروعك كبير جدًا ومعقد، وكل جزء فيه مستقل تمامًا.

2- بتحتاج تتحكم في الصلاحيات على مستوى كل موديول.

3- عندك فرق مختلفة كل فريق شغال على موديول خاص به.

4- عايز تتجنب المشاكل اللي بتسببها أحجام الـ repos الكبيرة.

———

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

وفقكم الله لكل خير 🌿

دورة مجانية بعنوان: Power BI 101

تهدف هذه الدورة إلى التعرف على أساسيات Power BI، بدءًا من استيراد البيانات، إلى تمثيل البيانات وإنشاء التقارير وdashboard.

ستساعدك الدورة على اكتساب المهارات اللازمة لتمثيل البيانات وإنشاء تقارير فعّالة باستخدام Power BI.

https://satr.codes/course/OC6sfVMdl9/view

الـ MVC

نمط الـ MVC، أو Model-View-Controller، يعتبر من أشهر الأنماط المستخدمة في هندسة البرمجيات، وبيساعد على تنظيم الكود بشكل يخلي عملية تطوير وصيانة البرامج أبسط وأسهل.

———

طيب يعني إيه MVC؟ 🤔

الـ MVC بيتكون من 3 مكونات أساسية:

✅ الـ Model: الجزء ده هو اللي بيتعامل مع البيانات. الـ Model بيقوم بتخزين البيانات، معالجة البيانات، والتواصل مع قواعد البيانات.

ممكن تعتبره زي المسئول عن "المنطق" أو "الشغل" اللي بيحصل في التطبيق. مثلًا لو عندك تطبيق بيعرض قائمة بالمنتجات، فالـ Model هو اللي هيجيب البيانات دي من قاعدة البيانات ويجهزها.

✅ الـ View: وده المسئول عن كل اللي المستخدم بيشوفه قدامه على الشاشة. هو المسئول عن عرض البيانات اللي جهزها الـ Model.

يعني مثلًا لو عندك صفحة بتعرض المنتجات، فالـ View هو اللي بيحدد إزاي المنتجات هتظهر (الألوان، الشكل، الترتيب... إلخ).

✅ الـ Controller: وده الوسيط اللي بيعمل التنسيق بين الـ Model والـ View.

بمعنى تاني، هو اللي بيستقبل طلبات المستخدمين، زي لما تضغط على زرار أو تدخل بيانات في فورم، وبعدين يوجه الطلب للـ Model علشان يعالج البيانات، وفي الآخر يرجع البيانات دي للـ View علشان يعرضها.

———

مثال بسيط 🛠

تخيل إنك فاتح موقع للتسوق وعايز تشوف قائمة المنتجات:

⚡️ أول حاجة بتضغط على زرار "عرض المنتجات" – هنا الـ Controller بيستقبل الطلب ده.

⚡️ بعد كده، الـ Controller بيروح للـ Model علشان يجيب البيانات من قاعدة البيانات (قائمة المنتجات).

⚡️ الـ Model بيدور في قاعدة البيانات ويجيب المنتجات.

⚡️ بعد ما الـ Model يجهز البيانات، بيرجّعها للـ Controller اللي بدوره يبعتها للـ View.

⚡️ وأخيرًا، الـ View بيعرض المنتجات على الشاشة بالشكل المناسب اللي المستخدم يقدر يشوفه ويتفاعل معاه.

———

ليه تستخدم الـ MVC؟ 🤷‍♂️

📌 تنظيم الكود: بيخلي الكود منظم أكتر، بحيث تقدر تفصل منطق العمل (الـ Model) عن العرض (الـ View) وعن التحكم (الـ Controller)، وبالتالي لو عايز تعدل في جزء معين، بتعدل عليه من غير ما تأثر على الأجزاء التانية.

📌 سهولة التطوير والصيانة: كل مكون في الـ MVC بيشتغل بشكل مستقل، فلو في مشكلة في العرض (الـ View) مش لازم تلمس الكود الخاص بالبيانات (الـ Model) أو التحكم (الـ Controller).

📌 إعادة استخدام الكود: بما إن الكود متقسم ومنظم، ممكن تعيد استخدام أجزاء معينة منه في مشاريع تانية.

———

نمط الـ MVC هيسهل عليك الدنيا خصوصًا لو شغال على مشاريع كبيرة ومعقدة لأنه بيفصل بشكل واضح بين الأدوار المختلفة لكل مكون في التطبيق.

ده هيوفر عليك وقت ومجهود وهتقدر تعمل تعديل في التطبيق بتاعك بكل سهولة.

بالتوفيق يا بطل 💪🏻

الفرق بين AOT Compiler و JIT Compiler في Angular 💡
.
.
طبعًا أنت عارف إن المتصفح مبيفهمش غير لغة واحدة في الآخر، وهي الـ JavaScript. يعني مهما كتبت كود بلغة زي TypeScript أو حتى HTML وCSS، لازم في النهاية الكلام ده كله يتحول لـ JavaScript عشان المتصفح ينفذه ويطلع الموقع على الشاشة.

وده بيحصل عن طريق حاجة اسمها الـ Compiler (أو الـ Transpiler في بعض الحالات زي TypeScript). ولكن في Angular، الـ compilation ده ممكن يحصل بطريقتين مختلفتين، وكل طريقة لها مميزات وعيوب.

———

https://www.linkedin.com/posts/dev-alisamir_angular-devabrguide-typescript-activity-7305272573439713280-pq-Q

الفرق بين Dependency Injection و Inversion of Control 💡

لما تتعمق شوية في مجال السوفتوير هتسمع عن مصطلحات زي Dependency Injection و Inversion of Control، وفيه ناس بتتلخبط بينهم وبتفكر إنهم حاجة واحدة. خلينا نوضح الفرق بطريقة بسيطة تفهمك الفكرة كويس...

———

📍 إيه هو Inversion of Control (IoC)؟

خلينا نبدأ بـ Inversion of Control أو زي ما بنختصرها IoC. المفهوم ده ببساطة بيقول إن بدل ما الكود بتاعك هو اللي يتحكم في كل حاجة بنفسه (يعني هو اللي بيعمل الكائنات (Objects) اللي هيشتغل بيها ويعتمد عليها)، بيكون فيه جهة تانية هي اللي بتعمل ده وتدير الموضوع.

يعني الكود بتاعك مش بيهتم بأنه "ينشئ" الـ dependencies (الكائنات اللي بيعتمد عليها)، بل بيستقبلها جاهزة.

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

———

📍 إيه حكاية Dependency Injection؟

هنا بقى ييجي دور الـ Dependency Injection. ده ببساطة أسلوب أو طريقة لتطبيق مفهوم الـ Inversion of Control.

بدل ما الكود بتاعك هو اللي يقول "أنا محتاج الكائن ده أو المكون ده عشان أشتغل"، حاجة تانية (زي الـ framework أو الـ container) بتكون مسؤولة عن إنها "تضخ" الكائنات دي لك في الوقت المناسب.

———

📌 مثال يوضح الفرق:

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

لكن لو في نظام ذكي في العربية هو اللي بيتحكم ويوصل لها البنزين من غير ما أنت تتدخل، يبقى ده Inversion of Control، لأنك سبت السيطرة للنظام إنه يدير الموضوع.

أما Dependency Injection، فهو الآلية اللي بيتم بيها توصيل البنزين للعربية. يعني هي دي الطريقة اللي البنزين بيوصل بيها لعربيتك عشان تمشي.

———

📌 طب ليه بنهتم بالحاجات دي في البرمجة؟

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

لكن لما تخلي Dependency Injection مسؤول عن توصيل الـ dependencies، هتقدر تعدل على الكود أو تستبدل أي جزء بسهولة من غير ما تبقى محتاج تغييرات كبيرة.

———

الخـلاصـة ✅

الـ Inversion of Control: هو المفهوم اللي بيقول إنك تسيب التحكم في الـ dependencies لجهة خارجية.

الـ Dependency Injection: هو طريقة لتطبيق المفهوم ده عن طريق توصيل الـ dependencies للكود بتاعك بشكل أوتوماتيكي.

بالتالي، IoC هو الفكرة الكبيرة اللي بتحكم الموضوع، وDependency Injection هو الأداة اللي بتطبق الفكرة دي.

بالتوفيق يا بطل ⚡️

Our Digital Hubs 🌐

DevGuide | Telegram

https://t.me/the_developer_guide

DevGuide | YouTube

https://www.youtube.com/@The_Dev_Guide

DevGuide | LinkedIn

https://www.linkedin.com/company/dev-guide

DevGuide | Discord

https://discord.gg/nTgfYng5q2

DevGuide | Facebook

https://www.facebook.com/TheDeveloperGuide

DevJobs | Telegram

https://t.me/devsjobs

DevJobs | WhatsApp

https://whatsapp.com/channel/0029Va5wYTe1noz1SKCNcv45

DevJobs | LinkedIn

https://www.linkedin.com/showcase/developersjobs