الأخطاء العشرة الأكثر شيوعًا التي يرتكبها مطورو الويب: برنامج تعليمي للمطورين

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

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

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

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

الخطأ الشائع رقم 1: عدم اكتمال التحقق من صحة المدخلات

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

أحد العواقب الأكثر شيوعًا لهذا الخطأ هو حقن SQL وهو موجود في OWASP Top 10 عامًا بعد عام.

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

الخطأ الشائع رقم 2: المصادقة بدون تصريح مناسب

قبل المضي قدمًا ، لنتأكد من محاذاة هذين الحدين. كما هو مذكور في أكثر 10 ثغرات أمنية على الويب شيوعًا:

المصادقة: التحقق من أن الشخص (أو على الأقل يبدو كذلك) مستخدمًا معينًا ، نظرًا لأنه قدم بيانات اعتماد الأمان الخاصة به بشكل صحيح (كلمة المرور ، والإجابات على أسئلة الأمان ، ومسح بصمات الأصابع ، وما إلى ذلك).

التخويل: التأكيد على أن مستخدمًا معينًا لديه حق الوصول إلى مورد معين أو منحه إذنًا للقيام بعمل معين.

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

دعني أوضح هذه المشكلة بمثال:

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

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

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

 POST /changepassword/:username/:newpassword

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

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

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

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

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

Authentication Authorization وجهان لعملة واحدة. لا تعاملهم بشكل منفصل.

الخطأ الشائع رقم 3: غير جاهز للقياس

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

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

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

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

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

الخطأ الشائع الرابع: خطأ أو مفقود في تحسين محركات البحث

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

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

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

الخطأ الشائع رقم 5: الوقت أو المعالج الذي يستهلك الإجراءات في معالجات الطلبات

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

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

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

الخطأ الشائع رقم 6: عدم تحسين استخدام النطاق الترددي

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

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

1. تصغير كل JavaScript
2. تصغير جميع CSS
3. ضغط HTTP من جانب الخادم
4. تحسين حجم الصورة ودقتها

الخطأ الشائع رقم 7: عدم التطوير لأحجام الشاشات المختلفة

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

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

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

الخطأ الشائع رقم 8: عدم توافق المستعرضات المتقاطعة

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

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

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

الخطأ الشائع رقم 9: عدم التخطيط لقابلية النقل

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

يجب أن يكون إعداد التطبيق المثالي خاليًا من الصيانة:

1. تأكد من أن التطبيق الخاص بك يمكنه التحجيم والتشغيل في بيئة خادم متعددة متوازنة التحميل.
2. السماح بتكوين بسيط وواضح - ربما في ملف تكوين واحد.
3. تعامل مع الاستثناءات عندما لا يكون تكوين خادم الويب كما هو متوقع.

الخطأ الشائع رقم 10: أنماط مقاومة الراحة

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

اثنان من أكثر الأخطاء شيوعًا عند كتابة RESTful API هما:

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

2. عدم إرسال رموز حالة HTTP الصحيحة. أفضل مثال على هذا الخطأ هو إرسال رسائل خطأ برمز الاستجابة 200.

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

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

يمكن العثور هنا على نظرة عامة مفصلة على أكواد حالة HTTP القياسية.

يتم إحتوائه

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

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