عشرة أخطاء شائعة يقع بها مطورو الويب

منذ صياغة مصطلح شبكة الويب العالمية World Wide Web عام 1990، تحولت مواقع الويب من مجرد صفحات HTML ثابتة إلى تطبيقات متقدمة تؤدي وظائف فعالة ومعقدة للغاية. يتوفر بين أيدينا اليوم آلاف الموارد الرقمية والمطبوعة التي تشرح لنا بالتفصيل كيفية تطوير أنواع مختلفة من تطبيقات الويب. كما أن بيئات التطوير ذكية إلى الحد الذي يمكّنها من اكتشاف وإصلاح العديد من الأخطاء التي عانى المطورون فيما مضى كثيرًا لإصلاحها.

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

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

يتناول هذا المقال بعض المواضيع العامة المشتركة بين جميع مطوري الويب، مثل التحقق Validation والأمان Security وقابلية التوسع Scalability وتحسين محركات البحث SEO. وبالتأكيد فإنك لست مضطرًا إلى التقيد بالأمثلة الواردة في هذا المقال، فالهدف منها تقديم فكرة عن المشكلات المحتملة التي قد يواجهها مطورو الويب والانتباه لها عند تطوير موقعك.

الخطأ الأول: عدم التحقق من صحة المدخلات Validation

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

من العواقب الشائعة لهذا الخطأ هو حقن إس كيو إل SQL Injection، إذ يتواجد هذا الخطأ سنويًا في قائمة أواسب OWASP التي تحتوي على أهم 10 مخاطر في أمن تطبيقات الويب. لذا توفر معظم أطر عمل تطوير الواجهات الأمامية قواعد تحقق مميزة وسهلة الاستخدام، كما تستخدم معظم أطر عمل تطوير الواجهات الخلفية تعليقات توضيحية بسيطة لضمان التزام البيانات المقدمة بالقواعد المتوقعة.

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

الخطأ الثاني: الاستيثاق Authentication دون الحصول على تصريح Authorization

قبل أن نخوض عميقًا في شرح هذا الخطأ، لا بُدّ من شرح المصطلحين السابقين وتوضيح كل منهما:

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

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

{
    username:'elvis',
    role:'singer',
    token:'123456789'
}

عند تغيير كلمة المرور، يجري تطبيقك طلب من النوع POST كما يلي:

POST /changepassword/:username/:newpassword

في التابع ‎/‎changepassword‎، يمكنك التحقق من تسجيل دخول المستخدم وعدم انتهاء صلاحية المفتاح token، ومن ثم يمكنك إيجاد ملف تعريف المستخدم بناءً على المعامل :‎‎‏‏‏‏‎username‎ ومن ثم تغير كلمة مرور المستخدم.

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

في هذه المرحلة، من المهم التحقق من أن المستخدم الذي ينفذ الإجراء والمستخدم الذي تغيرت كلمة مرور حسابه هو الشخص نفسه، إذ يمكن التلاعب بالمعلومات الموجودة في المتصفح، ويمكن لأي مستخدم ذي خبرة تحديث اسم المستخدم username:'elvis'‎ بسهولة إلى اسم المستخدم username:'Administrator'‎ باستخدام أدوات المتصفح المضمّنة فيه.

لذا فإننا في هذه الحالة ركزنا فقط على الاستيثاق Authentication معتمدين على أن المستخدم قد قدم اعتماديات الأمان. يمكننا أيضًا إضافة التحقق من أنه لا يمكن تنفيذ تابع ‎/‎‎‎‎‎‎changepassword إلا من قِبل المستخدمين الذين تجاوزوا عملية الاستيثاق Authentication. ومع ذلك، ما تزال الخطوات غير كافية لحماية المستخدمين من محاولات الاختراق الضارة.

يجب أن تحرص على أن تتحقق من الهوية الفعلية للشخص الذي يقدم الطلب، وكذلك محتوى الطلب ضمن تابع ‎/changepassword‎‎ إضافةً إلى حصول المستخدم على التصريح Authorization المناسب للطلب، مع التأكد من أن المستخدم لا يمكنه تغيير سوى بياناته.

الاستيثاق Authentication والتصريح Authorization هما وجهان لعملة واحدة، لذا لا تعاملهما على نحو منفصل أبدًا.

الخطأ الثالث: عدم الجاهزية للتوسع

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

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

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

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

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

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

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

الخطأ الرابع: عدم تحسين محركات البحث SEO بطريقة صحيحة

أحد أهم الأسباب وراء فشل تحسين صفحات الويب وملاءمتها مع سياسات تحسين محركات البحث SEO هو التضليل الذي يمارسه بعض الأشخاص الذين ينتحلون صفة خبراء تحسين محركات البحث.

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

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

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

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

الخطأ الخامس: التأخر في معالجة الطلبات

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

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

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

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

الخطأ السادس: عدم تحسين استخدام حيز النطاق التراسلي Bandwidth

تجري معظم عمليات التطوير والاختبار في بيئة تجريبية على شبكة محلية، لذلك عندما تعمل على تنزيل 5 صور خلفية يبلغ حجم كل منها 3 ميجابايت عبر شبكتك المحلية السريعة، فقد لا تكتشف أي مشكلة تتعلق بسرعة التحميل، ولكن عندما يبدأ المستخدمون بتحميل صفحة رئيسية بحجم 15 ميجابايت عبر شبكة 3G على هواتفهم الذكية، ستبدأ حينها بتلقي العديد من شكاوى العملاء.

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

تصغير minification كامل نصوص جافا سكريبت.
تصغير كامل نصوص CSS.
ضغط compression نصوص HTTP من الخادم.
تحسين حجم الصور ودقتها.

الخطأ السابع: عدم تهيئة التطبيق لأحجام شاشات مختلفة

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

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

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

لاستخدام إطار العمل بوتستراب Bootstrap بكفاءة عالية، يُفضَّل أن يكون لديك خبرة جيدة في كيفية التعامل مع لغات تطوير الويب الأساسية، مثل HTML و CSS و JavaScript، إضافةً إلى إدراك جيد لمفهوم التصميم المتجاوب. إذا لم يكن لديك معرفة كافية بها، فيمكنك التعرف عليها في المسار الأول من دورة تطوير واجهات المستخدم التي تقدمها أكاديمية حسوب.

الخطأ الثامن: عدم التوافق بين المتصفحات

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

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

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

الخطأ التاسع: عدم التخطيط لقابلية النقل Portability

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

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

من الخطأ افتراض أن بيئة تطوير التطبيق (خلال مرحلة برمجته) ستتوافق مع بيئة الإنتاج (بعد الانتهاء منه ونشره للمستخدمين)، والتطبيق المثالي هو التطبيق الذي يحتاج الحد الأدنى من الصيانة والإصلاح maintenance-free، لذلك:

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

الخطأ العاشر: استخدامات غير فعالة لواجهة RESTful API

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

لكن ثمة خطآن شائعان عند كتابة RESTful API، هما:

استخدام أفعال أو توابع HTTP Verbs خاطئة: كما هو الحال مثلًا عند استخدام طريقة الطلب GET لكتابة البيانات، إذ أن طريقة الطلب GET في بروتوكول HTTP تُستخدم فقط لجلب البيانات وليس للتعديل عليها، وهي مصممة لتكون ثابتة وآمنة، لذا فإنه بغض النظر عن عدد المرات التي تُستخدم فيها طريقة GET لاستدعاء البيانات من نفس المورد، فإن الاستجابة ستكون دائمًا هي نفسها، ويجب ألا يحدث أي تغيير في حالة التطبيق.
عدم إرسال رموز حالة status codes صحيحة: ومن أفضل الأمثلة على هذا الخطأ الشائع هو إرسال رسائل خطأ مع رمز إجابة 200، إذ يشير هذا الرمز في الأساس إلى أن كل شيء على ما يُرام.

HTTP 200 OK
 {
     message:'there was an error'
 }

يجب إرسال الرمز HTTP 200 OK عندما لا ينتج عن الطلب أي خطأ، أما في حالة وجود خطأ ما، فيجب إرسال الرموز 400، 401، 500 أو أي رمز حالة آخر مناسب للخطأ الذي حدث.

في الختام

يُعد تطوير الويب مصطلحًا واسعًا يمكن أن يشمل الكثير من المجالات، مثل تطوير المواقع الإلكترونية، أو خدمات الويب، أو تطبيقات الويب المعقدة.

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

ترجمة -وبتصرّف- للمقال The 10 Most Common Mistakes Web Developers Make: A Tutorial for Developers لصاحبه Demir Selmanovic.