كيف تختار بين الويب والتطبيق الأصلي ومتعدد المنصات وبدون كود

لمن هذا الدليل وكيف تستخدمه

هذا الدليل للمؤسسين وأصحاب المنتجات وقادة الأعمال الذين لديهم فكرة لمنتج ويب أو جوال ويحتاجون إلى قرار في كيفية بنائه. لا يلزمك أن تكون تقنيًا، لكن يلزمك أن تعرف لمن المنتج وما الذي يجعل الإصدار الأول ناجحًا.

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

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

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

ابدأ من المشكلة وأكبر المخاطر

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

المخاطر الأربعة

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

حوّل الخطر إلى اختبار

لكل خطر اكتب أرخص تجربة تقلّله. للطلب قد تكون صفحة هبوط وقائمة انتظار وبضع محادثات. وللاستخدام نموذج أولي قابل للنقر تجربه مع مستخدمين حقيقيين. وللأمن نمذجة تهديدات للمسارات الأساسية. ثم اسأل: هل يسمح لي الأسلوب الذي أدرسه بإجراء هذه التجربة بسرعة وبكلفة قليلة؟

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

الخيارات مشروحة

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

الويب المتجاوب وتطبيقات الويب التقدمية

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

حدوده في الوصول إلى الجهاز ومستوى الصقل. المتصفحات تتيح قدرات متزايدة، لكن الدعم يختلف باختلاف المتصفح ونظام التشغيل، وقد قدّمت أجهزة آيفون تاريخيًا قدرات أقل من هواتف أندرويد. تحقق من الدعم الحالي لكل ميزة تعتمد عليها، كالإشعارات والعمل في الخلفية والبلوتوث والوصول إلى الملفات. نبني هذه المنتجات بـ Next.js وReact وTypeScript: راجع تطوير المواقع وتطوير Next.js ومنصات SaaS.

التطبيقات الأصلية لنظامي iOS وأندرويد

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

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

متعدد المنصات بـ Flutter أو React Native

تتيح الأطر متعددة المنصات لفريق واحد أن يكتب معظم التطبيق مرة واحدة وينشره على iOS وأندرويد. يرسم Flutter (بلغة Dart) واجهته بمحرك رسم خاص به، فتظهر الشاشات متطابقة في كل مكان. أما React Native (بـ JavaScript أو TypeScript) فيحوّل مكوّناتك إلى عناصر الواجهة الأصلية للمنصة، ويناسب الفرق التي تعمل أصلًا بـ React. وكلاهما يصل إلى الشيفرة الأصلية حين تحتاجها ميزة ما.

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

بدون كود وقليل الكود

تتيح منصات بدون كود تجميع المنتج من لبنات مرئية ببرمجة قليلة أو بدونها. أما قليل الكود فيضيف إمكانية كتابة شيفرة حين تنتهي اللبنات. من الأدوات التي نعمل بها Webflow للمواقع التسويقية ومواقع المحتوى، وBubble وFlutterFlow لتطبيقات الويب والجوال، وAirtable وZapier للبيانات والأتمتة. ويشرح المسرد معنى بدون كود.

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

الشراء والإعداد

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

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

المعايير التي تحسم القرار

عشرة معايير تفرّق بين الخيارات. قيّم أهمية كل معيار لمنتجك (عالية أو متوسطة أو منخفضة) قبل أن تنظر في أي خيار، وإلا انحازت المعايير إلى ما تفضّله مسبقًا.

ثلاث قواعد لاستخدام الجدول

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

امنح الأمن وزنًا إضافيًا

الأمن هو المعيار الذي تؤجله الفرق في الغالب، ولا يمكن إضافته في النهاية كما يُغيَّر لون. فمكان البيانات، وطريقة تسجيل الدخول، وما تكشفه الواجهة، وطريقة إصدار التحديثات، كلها تتبع الأسلوب المختار. تضع تطبيقات الجوال الشيفرة على أجهزة لا تتحكم بها، لذلك يجب أن تبقى الأسرار وقرارات الثقة على الخادم. وتواجه تطبيقات المتصفح هجمات من نوع آخر، مثل البرمجة النصية عبر المواقع (XSS). وتنقل منصات بدون كود والمنصات المشتراة بعض الواجبات إلى المزوّد وتترك غيرها عليك، فاقرأ أين يقع كل خط. ويشرح دليل تطوير التطبيقات الآمنة المنهج.

مقارنة الخيارات جنبًا إلى جنب

استخدم هذه الجداول مرشّحًا أوليًا لا حكمًا نهائيًا. فهي تصف السلوك المعتاد، وتختلف المنتجات والفرق.

ماذا تعني الكلفة فعلًا

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

ستة سيناريوهات افتراضية

هذه الحالات متخيَّلة لأغراض الشرح. ليست عملاء ولا دراسات حالة. وكل واحدة منها تُظهر كيف تقود الأسئلة نفسها إلى إجابات مختلفة.

سوق للدروس الخصوصية يختبر الطلب

تخيّل مؤسسًا يريد ربط الطلاب بمدرّسين خصوصيين. المجهول هنا: هل سيجد الطرفان بعضهما ويدفعان عبر المنصة؟

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

شركة توصيل بتطبيق للسائقين

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

• المسار المقترح: تطبيق متعدد المنصات بـ Flutter أو React Native مع قاعدة بيانات محلية تتزامن لاحقًا، ولوحة تحكم على الويب لمنسّقي التوصيل.
• السبب: العمل دون اتصال والكاميرا أساسيان، لكن الشاشات شاشات أعمال عادية، فقاعدة شيفرة واحدة توفّر الجهد. راجع قطاع اللوجستيات.
• انتبه إلى: يختلف سلوك الموقع في الخلفية واستهلاك البطارية باختلاف مصنّع الجهاز، فاختبر على الهواتف الفعلية. وخطّط لكيفية حل التزامن حين يعدّل شخصان السجل نفسه.

تطبيق محفظة ومدفوعات

تخيّل شركة ناشئة تبني محفظة تحتفظ بالأرصدة وتحوّل المال بين الأشخاص.

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

مجموعة مطاعم بطلب إلكتروني وبرنامج ولاء

تخيّل مجموعة مطاعم تريد طلبًا إلكترونيًا وتتبعًا للتوصيل ونظام نقاط.

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

بوابة حجز وسجلات لعيادات

تخيّل مجموعة عيادات تريد أن يحجز المرضى مواعيدهم ويطلعوا على نتائجهم عبر الإنترنت.

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

أداة تفتيش لفريق المرافق

تخيّل فريق مرافق يريد استبدال قوائم الورق بنماذج وصور وتقرير يومي، لبضع عشرات من المستخدمين المعروفين.

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

لاحظ النمط. لم يبدأ أي من الأجوبة الستة بتقنية. بدأ كل جواب بالخطر، ثم القيد الذي لا يتحرك، ثم أرخص أسلوب يحترم الاثنين.

كيف تحدد نطاق الإصدار الأول وما الذي تؤجله

الإصدار الأول تجربة بواجهة مستخدم. مهمته أن يجيب عن أكبر مخاطرك، وكل ما لا يساعد في ذلك مرشح للتأجيل. هذه هي فكرة المنتج الأدنى القابل للتطبيق (MVP). وهي أكثر انضباطًا مما تبدو: الـ MVP ليس منتجًا رديء الجودة، بل منتج ضيّق النطاق.

طريقة لتحديد النطاق تنجزها في عصر يوم واحد

1. اكتب الوعد في جملة واحدة: من الذي يساعده المنتج، وفي أي مهمة، وما الذي يتغير له.
2. ارسم مسار المستخدم من أول زيارة إلى أول نجاح، واحتفظ بالخطوات اللازمة للوصول إليه فقط.
3. صنّف كل ميزة: ضرورية أو مستحسنة أو لاحقة. والضرورية هي التي يصبح الوعد بدونها غير صحيح.
4. سمِّ المقياس الواحد الذي يخبرك أن الإصدار الأول نجح، وحدد كيف ستجمعه.
5. قارن كل ميزة ضرورية بأكبر مخاطرك. فإن لم تقلّل الخطر فأنزلها درجة.
6. اكتب قائمة (ليس الآن) وشاركها مع الجميع. يقبل الناس التأجيل حين يرون ما أُجِّل.

ما تبنيه الآن وما يمكن تأجيله

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

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

التخطيط للخروج من الإصدار الأول

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

ما تحتفظ به أيًّا كان الأسلوب

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

علامات أن وقت الانتقال قد حان

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

أنماط الترحيل

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

أسئلة توجّهها لأي مزوّد

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

عن الأسلوب

• أيٌّ من هذه الأساليب لن توصي به لهذا المنتج، ولماذا؟
• ما أكبر خطر في خطتي، وكيف يقلّله عرضك؟
• ما الذي يدخل في الإصدار الأول، وما الذي أجّلتموه؟
• ما الذي سيدفعك إلى تغيير الأسلوب في منتصف الطريق؟

عن الملكية والخروج

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

عن الأمن والتسليم

• كيف تراجعون الأمن قبل البناء وقبل الإطلاق، وهل أستطيع الاطلاع على مثال من المخرجات؟
• أين تُخزَّن البيانات وتُعالَج، ومن يستطيع الوصول إليها؟
• كم مرة سأرى برمجيات تعمل فعلًا؟
• ما الذي يحدد الكلفة: النطاق أم الاستخدام أم عدد المقاعد أم الوقت؟ وما كلفة التشغيل بعد الإطلاق؟

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

قائمة مراجعة للقرار

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

1. سمّينا أكبر مخاطرنا (الطلب أو سهولة الاستخدام أو التوسع أو الأمن) وحددنا التجربة التي تقلّله.
2. نستطيع أن نقول في جملة واحدة لمن الإصدار الأول وكيف يبدو نجاحه.
3. رتّبنا المعايير وحددنا المتطلبات الإلزامية.
4. قارنّا كل ميزة جهاز نحتاجها بما يدعمه اليوم الويب ومتعدد المنصات وأدوات بدون كود.
5. نعرف شكل الميزانية: ما يُدفع في البداية، وما يتكرر، وما يكبر مع الاستخدام.
6. نعرف من سيصون المنتج بعد الإطلاق، ونتأكد أنه يعرف التقنية المختارة.
7. نعرف ما البيانات التي نحتفظ بها، وأين يجوز تخزينها، وما القواعد التي تنطبق، وسألنا مستشارين مؤهلين حيث لزم.
8. نعرف كيف سيجد المستخدمون المنتج: برابط أو بالبحث أو من متجر أو عبر نظام إدارة أجهزة الشركة.
9. لدينا قائمة (ليس الآن)، والإصدار الأول يناسب التجربة.
10. لدينا خطة خروج: بيانات قابلة للتصدير، وحسابات باسمنا، وعلامات تدل على أن وقت الانتقال حان.
11. طرحنا الأسئلة أعلاه على المزوّدين وحصلنا على الإجابات كتابةً.

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