التوزيع بأولوية الميزات

إنه لمن المهم لمطور التطبيقات أن يتعلّم توزيع ملفاته ومجلداته جيداً حتّى إذا ما أراد العودة من أجل تتبّع المشكلات Debugging أو تطوير تطبيقه أن يعرف بسرعةٍ مكان الملفات وما تحويه من أكواد..


ما أودّ طرحه في هذا المقال الصغير هو درسٌ صغير في كيفية توزيع الملفات بناءً على أن الميزات تأتي بدايةً ثم تحتها يقعُ ما يقع من التوزيع , وإنّ هذه الطريقة تعلمتها من صديقي والمشرف عليّ أثناء فترة التدريب الميداني “مصعب” فراقت لي , واستأثرتها على غيرها , وعملتُ بها من بعد ذلك..


بدايةً وكما هو معروفٌ هناكَ 3 مذاهب شائعة في توزيع الملفات وهي :

  • واجهة View - نموذج الواجهة Viewmodel- نموذج Model وتدعى اختصاراً بـ”نون” MVVM

  • واجهة - متحكّم Controller - نموذج , وتدعى اختصاراً بـ”مون” MVC

  • وأما الأخيرة وهي ما يدعى بالبنية المثالية Clean Architecture , وهذا يحوي بداخله 3 طبقات وهي “ طبقة الواجهة - طبقة المنطق Domain - طبقة البيانات Data , وبداخل كل طبقة توزيعات تختلف.


إذن بعد أن اطلعنا على المذاهب الثلاث الشائعة الاستخدام , كيف لنا أن نوفق بينها لنطبق مفهوم أولوية الميزات؟

إننا لو أخذنا مثالاً على تقسيمة الملفات في نون لوجدناها تتبع التقسيم التالي على سبيل المثال:

- واجهة > الصفحة_الأولى > الصفحة_الثانية > الصفحة_الثالثة - واجهة النموذج > نموذج_الواجهة_للصفحة_الأولى > نموذج_الواجهة_للصفحة_الثانية > نموذج_الواجهة_للصفحة_الثالثة - النماذج > نموذج_لصفحة_الأولى > نموذج_لصفحة_الثانية > نموذج_لصفحة_الثالثة

إنّ كل صفحةٍ من هذه الصفحات تمثّل ميزةً في تطبيقنا بحد ذاته , فيمكن أن نعتبر الصفحة الأولى هي صفحة تسجيل الدخول مثلاً وهي ميزةٌ من الميزات , ونرى هنا أن الميزات تأتي ثانياً , ففي المقام الأول يأتي مذهب التقسيم ثم تحته هذه الميزات.


إن الطريقة التي تعلمتها وهي بوضع الميزات قبل كل شيءٍ ساعدتني كثيراً , وإن أول ما نبدأ بهِ في هذا الصدد أننا نقسّم المجلدات إلى مجلدين رئيسيين “قد يتبعهما بعض المجلدات أيضاً” وهما “ الميزات Features و المُشْتَرَكَات Common”.


في مجلد الميزات نضع الميزات ثم بداخل كلّ ميزةٍ أو خاصيةٍ من خواصّ التطبيق نضع بداخلها البنية المثالية وبداخل كلّ طبقة نتبع التقسيمة المعتادة إمّا نون أو مون.


وفي مجلد المُشْتَرَكَات نضعُ ما اشترك بين كل الصفحات من مكونّات Components أو معترضات ساعي البريد API Interceptor أو غيرها ..


وإليك التقسيمة النهائية لمشروعٍ يحوي صفحة تسجيل دخولٍ باستخدام هذه الطريقة بجانب طريقة المون والبنية المثالية:


- مشتركات > الشبكة > معترض_ساعي_البريد > كاشف_الأخطاء > العناصر المشتركة > زر_مدوّر > خانة_إدخال - ميزات > التحقق > تسجيل دخول > ساعي البريد API > ساعي_البريد_لتسجيل_الدخول > النماذج > نموذج_بيانات_تسجيل_الدخول > المنطق > الحالات > حالة_تسجيل_الدخول > المتحكّمات > متحكّم_تسجيل_الدخول > الواجهة > عناصر تسجيل الدخول > شعار_التطبيق > زر_أحمر > واجهة_تسجيل_الدخول

كما ترى يميّز هذه الطريقة التقسيم المنظّم لكل العمل , فحتّى إذا ما بدأت العمل وأردت العودة إلى جزءٍ معيّن يمكنك العودة إليه وفهم آلية عمل التطبيق من خلاله.


يعيب هذه الطريقة كما ترى أيضاً التداخل Nested , ولعلّ هذا العيب بسبب دمج طريقتين أو مذهبين من المذاهب المختلفة وادراجهم تحت مفهومٍ ثالث.


على كلٍّ لستُ هنا من أجل المفاضلةِ بين الطرق عامةً , بل إني كتبت المقال لأرشدكَ إلى طريقةٍ أحذوها مطلعاً إياكَ عليها وعلى ما تحوي من أمور , وإن اختيار الطريقة في المحصّلة عندك لا عندي , وما ترتاح إليه أنت , وما يتطلبهُ مشروعك من عمل , فلا صحيح وخاطئ بين هذه الطرق , إنما هي تفضيلاتٌ تختلف بين هذا وذاك.


وللأسئلة أدعوكَ لمتابعتي على حسابي في تويتر

Join