VOL5: Package Managers & Database Cheatsheet
VOL5: Package Managers & Database Cheatsheet
في عالم تطوير واجهات المستخدم الحديث، أصبحت إعادة الاستخدام Reusability و التخصيص Customization من الجوانب الأساسية التي يتوجب على المطورين النظر فيها. مع تزايد تعقيد المشاريع و توسع نطاق التطبيقات، أصبح البحث عن أساليب فعالة لبناء مُكونات قابلة لإعادة الاستخدام و سهلة التخصيص أمرًا لا غنى عنه.
تتمتع مكتبة React بأنماط تصميم Design Patterns شائعة. دعونا نستعرض معًا في هذا المقال كيف يُمكننا الجمع بين إعادة الاستخدام و قابلية التخصيص باستخدام نمطي التصميم Render Props و Compound Pattern وكيف يُسهمان في بناء واجهات مستخدم مرنة.
هذا المقال سيكون مُقسم إلى جزأين حيث في الجزء الأول سنتطرق إلى الـ Compound Pattern، بينما في الجزء الثاني سنقوم بالتطرق إلى الـ Render Props.
Package Managers
الـ Package manager هو مساعد المبرمج المخلص في كل مشاريعه، فلو شغال Frontend هتلاقيك بتستخدم npm ولو شغال Backend فلكل لغة package manager بردو زي composer في PHP ولو شغال مع الذكاء الاصطناعي أو هندسة البيانات أو لغة python عامة فهتلاقيك بتستخدم pip
فخلونا نسأل سؤال وجودي ونقول ايه هي ال package ؟
ال package - الحزمة البرمجية - مصطلح عام بيشير لقطعة من الكود أو برنامج ممكن يكون كبير بحجم framework أو library زي Angular or React بستفيد منها في مهام متعددة وممكن يكون بيعمل مهمة واحدة بسيطة أنا محتاجها زي ال Date format مثلاً.
💡
الشاهد إنه برنامج جاهز بستفيد بيه بدل ما نعيد اختراع العجلة واستخدامها بيسرع عملية تطوير التطبيقات المختلفة.
طيب ليه استخدم package manager ؟
ما ممكن أنزلهم بنفسي وخلاص زي البرامج العادية
في الواقع لو عملت كدا هتقابلك مشاكل كتير زي:
Installation : تنزيل الـ packages مش زي بعضها, وكتير منها بيحتاج configuration معينة عشان تشتغل على الـ OS System بتاعك, فال package manager بيقولك متشغلش بالك بحوارات ال OS دي وقولي أنت عاوز تنزل برامج إيه وانا هنزلها من Repository معين من الانترنت وهعملها Configuration على نظام التشغيل بتاعك
Dependency Resolution: عدد الpackages اللي بتحتاجها غالبًا بيكون كبير وإدارة كل واحدة على حدة مهمة رخمة ومكلفة في الوقت, فتخيل محتاج تنزل أو تعمل update ل 50 برنامج مثلاً عشان تطبيقك يشتغل!!
Configuration Management and Uninstallation وضع الـ packages دي في المكان المناسب في نظام التشغيل وكذلك مسحها أو تحديثها
Architecture Testing
الـ Architecture Test مختلف شوية و هو نوع من ال Test بيستخدم فى التأكد من الحفاظ على ال Architecture نفسه للـ Software وملوش علاقة بالـ Application و الـ Business نفسه شغال ازاى، ولكن بيتأكد ان التيم كله بيراعى Architecture Rules و الـ High Level Decisions الخاصة بالـ Application مهم هنا كمان نأكد ان ال Architecture Test حاجه مفيده جدا و تأثيرها بيبان من اول يوم و يفضل مكمل معاك و محافظ على الكود بتاعك Clean, Consistent خاصة لو التيم بتاعك كبر و بقى عندك levels مختلفة، فكرة المحافظة على الكود هتبقى اسهل كتير
مثلا لو مستخدم Architecture فيه أكتر من layer زى الـ Clean Architecture أو الـ Onion أو الـ 3-Layers أو اى حاجه تانيه فبقدر أعمل Test للعلاقات بين الـ layers دى بالكود بتاعى
فمثلا لو عندى business layer مينفعش تكون معتمدة على Data layer ، فبقدر اتأكد من صحة العلاقة دى بال test بتاعى و فى الـ clean architecture مثلا العلاقة بين الـ core layer وباقى الـ layers التانيه وغيرها طبعا من العلاقات التانيه، كل دى قواعد اقدر اكتب لها Test بيتأكد منها.
Database Cheatsheet for System Design
لازم نكون عارفين ان اختيارنا للـ Database في الـ System اللي بنبنيه، هو قرار مش سهل وقرار هنبقى ملزمين بيه لفترة طويلة فلازم نختارها بعناية خصوصًا لو كمان الموضوع هيتضمن Budget وفلوس هتندفع.
عشان نسهل على نفسنا الاختيار هنحاول الأول نجاوب على السؤال ده:
هو ايه نوع الـ Data اللي محتاجين نخزنها في الـ System ؟
والاجابة هتكون حاجة من 3 واللي هنحاول سوا نبني Mind-Map في عقلنا عشان نسهل الاختيار علينا شوية:
Structured Data (Standard SQL Table Schema)
Semi-Structured Data (JSON, XML, etc..)
UnStructured Data (Blob)
بعد معرفتنا بنوع البيانات اللي هنخزنها، هنكون محتاجين نعرف حاجتين اتنين بس:
ايه هي الـ Use-Case أو هدفنا من تخزين البيانات
هل هنروح ناحية الـ Cloud ولا هيبقى اعتمادنا على الـ Open-Source والـ 3rd Party ؟
💡
وده لإن تحديد الهدف من التخزين هيفرق في اختيار الـ Database وهيخلينا نروح لنطاق أقل من الاختيار، واعتمادنا على الـ Cloud من عدمه كذلك هيسهل علينا الاختيار وهيضيق نطاق الاختيار.
