كود Buggy Rails: الأخطاء العشرة الأكثر شيوعًا التي يرتكبها مطورو ريلز

روبي أون ريلز ("ريلز") هو إطار عمل شائع مفتوح المصدر ، يعتمد على لغة برمجة روبي التي تسعى جاهدة لتبسيط وتبسيط عملية تطوير تطبيقات الويب.

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

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

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

تعتمد ريلز على بنية MVC. في مجتمع ريلز ، كنا نتحدث عن نموذج سمين ، وحدة تحكم نحيفة لفترة من الوقت الآن ، ومع ذلك فقد انتهكت العديد من تطبيقات ريلز الحديثة التي ورثتها هذا المبدأ. من السهل جدًا نقل منطق العرض (الذي يتم وضعه بشكل أفضل في المساعد) ، أو منطق المجال / النموذج ، في وحدة التحكم.

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

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

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

الخطأ الشائع الثاني: وضع الكثير من المنطق في العرض

يعد محرك قوالب Rails الجاهز ، ERB ، طريقة رائعة لبناء صفحات ذات محتوى متغير. ومع ذلك ، إذا لم تكن حريصًا ، فقد ينتهي بك الأمر قريبًا بملف كبير يتكون من مزيج من HTML و Ruby والذي قد يكون من الصعب إدارته وصيانته. هذا أيضًا مجال يمكن أن يؤدي إلى الكثير من التكرار ، مما يؤدي إلى انتهاكات لمبادئ DRY (لا تكرر نفسك).

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

 <h3> Welcome, <% if current_user %> <%= current_user.name %> <% else %> Guest <% end %> </h3>

أفضل طريقة للتعامل مع شيء كهذا هي التأكد من تعيين الكائن الذي يتم إرجاعه بواسطة current_user دائمًا ، سواء تم تسجيل دخول شخص ما أم لا ، وأنه يجيب على الطرق المستخدمة في طريقة العرض بطريقة معقولة (يشار إليها أحيانًا باسم null هدف). على سبيل المثال ، يمكنك تحديد current_user المستخدم الحالي في app/controllers/application_controller مثل هذا:

 require 'ostruct' helper_method :current_user def current_user @current_user ||= User.find session[:user_id] if session[:user_id] if @current_user @current_user else OpenStruct.new(name: 'Guest') end end

سيمكنك هذا بعد ذلك من استبدال مثال كود العرض السابق بهذا السطر البسيط من التعليمات البرمجية:

 <h3>Welcome, <%= current_user.name -%></h3>

زوجان من أفضل ممارسات Rails الإضافية الموصى بها:

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

الخطأ الشائع الثالث: وضع الكثير من المنطق في النموذج

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

كذلك ليس تماما.

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

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

لذا ، إذا كان المنطق لا يجب أن يسير في وجهات النظر ، ولا يجب أن يدخل في وحدات التحكم ، ولا يجب أن يدخل في النماذج ، حسنًا ، أين يجب أن يذهب؟

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

مع أخذ ذلك في الاعتبار ، بشكل عام ، فإن المنطق الوحيد الذي يجب أن يظل في نموذجك هو:

• تكوين ActiveRecord (على سبيل المثال ، العلاقات وعمليات التحقق من الصحة)
• طرق طفرة بسيطة لتغليف تحديث حفنة من السمات وحفظها في قاعدة البيانات
• الوصول إلى أدوات التضمين لإخفاء معلومات النموذج الداخلي (على سبيل المثال ، أسلوب full_name الذي يجمع بين حقول الاسم_الأول first_name last_name قاعدة البيانات)
• الاستعلامات المعقدة (أي التي تكون أكثر تعقيدًا من find البسيط) ؛ بشكل عام ، يجب ألا تستخدم طريقة where ، أو أي طرق أخرى لبناء استعلام مثلها ، خارج فئة النموذج نفسها

الخطأ الشائع الرابع: استخدام الفئات المساعدة العامة كأرض نفايات

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

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

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

الخطأ الشائع الخامس: استخدام الكثير من الجواهر

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

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

ضع في اعتبارك أن كل جوهرة تقوم بإدخالها في تطبيقك قد يكون لها بدورها تبعيات على جواهر أخرى ، وهذه بدورها قد يكون لها تبعيات على جواهر أخرى ، وما إلى ذلك. وبالتالي فإن إضافة الأحجار الكريمة الأخرى يمكن أن يكون لها تأثير مضاعف. على سبيل المثال ، ستؤدي إضافة جوهرة rails_admin إلى جلب 11 جوهرة أخرى إجمالاً ، بزيادة قدرها 10٪ عن تثبيت Rails الأساسي.

اعتبارًا من كتابة هذه السطور ، يتضمن تثبيت Rails 4.1.0 الجديد 43 جوهرة في ملف Gemfile.lock . من الواضح أن هذا أكثر مما تم تضمينه في Gemfile ويمثل جميع الأحجار الكريمة التي تجلبها حفنة من جواهر Rails القياسية باعتبارها تبعيات.

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

الخطأ الشائع # 6: تجاهل ملفات السجل الخاصة بك

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

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

أحد الأمثلة التي غالبًا ما تقوم بتشغيلها يسمى مشكلة استعلام N + 1. في حين أن المشكلة مفهومة جيدًا ، فإن الطريقة الحقيقية الوحيدة لملاحظة حدوثها هي مراجعة استعلامات SQL في ملفات السجل الخاصة بك.

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

 def comments_for_top_three_posts posts = Post.limit(3) posts.flat_map do |post| post.comments.to_a end end

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

 Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:13 -0700 Processing by PostsController#some_comments as HTML Post Load (0.4ms) SELECT "posts".* FROM "posts" LIMIT 3 Comment Load (5.6ms) ELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 1]] Comment Load (0.4ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 2]] Comment Load (1.5ms) SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? [["post_id", 3]] Rendered posts/some_comments.html.erb within layouts/application (12.5ms) Completed 200 OK in 581ms (Views: 225.8ms | ActiveRecord: 10.0ms)

تتيح إمكانية التحميل الحثيث لـ ActiveRecord في ريلز تقليل عدد الاستعلامات بشكل كبير عن طريق السماح لك بتحديد جميع الارتباطات التي سيتم تحميلها مسبقًا . يتم includes عن طريق استدعاء طريقة include (أو preload ) على كائن Arel ( ActiveRecord::Relation ) الجاري بناؤه. باستخدام التضمينات ، includes ActiveRecord تحميل كافة الاقترانات المحددة باستخدام أقل عدد ممكن من الاستعلامات ؛ على سبيل المثال:

 def comments_for_top_three_posts posts = Post.includes(:comments).limit(3) posts.flat_map do |post| post.comments.to_a end end

عندما يتم تنفيذ الكود المعدّل أعلاه ، نرى في ملف السجل أنه تم جمع جميع التعليقات في استعلام واحد بدلاً من ثلاثة:

 Started GET "/posts/some_comments" for 127.0.0.1 at 2014-05-20 20:05:18 -0700 Processing by PostsController#some_comments as HTML Post Load (0.5ms) SELECT "posts".* FROM "posts" LIMIT 3 Comment Load (4.4ms) SELECT "comments".* FROM "comments" WHERE"comments "."post_id" IN (1, 2, 3) Rendered posts/some_comments.html.erb within layouts/application (12.2ms) Completed 200 OK in 560ms (Views: 219.3ms | ActiveRecord: 5.0ms)

أكثر كفاءة.

يُقصد بهذا الحل لمشكلة N + 1 فقط كمثال على نوع عدم الكفاءة الذي يمكن أن يوجد "تحت الغطاء" في طلبك إذا كنت لا تولي الاهتمام الكافي. الخلاصة هنا هي أنه يجب عليك التحقق من ملفات سجل التطوير والاختبار أثناء التطوير للتحقق من (ومعالجة!) أوجه القصور في الكود الذي يبني ردودك.

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

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

الخطأ الشائع السابع: عدم وجود الاختبارات الآلية

يوفر Ruby و Rails إمكانات اختبار آلية قوية بشكل افتراضي. يكتب العديد من مطوري Rails اختبارات معقدة للغاية باستخدام أنماط TDD و BDD ويستفيدون من أطر اختبار أكثر قوة مع أحجار كريمة مثل rspec و cucumber.

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

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

الخطأ الشائع الثامن: حظر المكالمات إلى الخدمات الخارجية

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

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

• وظيفة مؤجلة
• Resque
• الصديق

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

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

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

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

تنشئ ريلز تمثيلاً لمخططك الحالي في ملف يسمى db/schema.rb (افتراضيًا) والذي يتم تحديثه عادةً عند تشغيل عمليات ترحيل قاعدة البيانات. يمكن إنشاء ملف schema.rb في حالة عدم وجود عمليات ترحيل عن طريق تشغيل مهمة rake db:schema:dump . من الأخطاء الشائعة في ريلز التحقق من ترحيل جديد إلى مصدر الريبو الخاص بك ولكن ليس ملف schema.rb تم تحديثه وفقًا لذلك.

عندما تخرج عمليات الترحيل عن السيطرة وتستغرق وقتًا طويلاً للتشغيل ، أو لم تعد تُنشئ قاعدة البيانات بشكل صحيح ، يجب ألا يخاف المطورون من مسح دليل التهجيرات القديم ، وتفريغ مخطط جديد ، والمتابعة من هناك. سيتطلب إعداد بيئة تطوير جديدة بعد ذلك rake db:schema:load بدلاً من rake db:migrate التي يعتمد عليها معظم المطورين.

تمت مناقشة بعض هذه المشكلات في دليل ريلز أيضًا.

الخطأ الشائع رقم 10: فحص المعلومات الحساسة في مستودعات كود المصدر

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

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

ملخص البرنامج التعليمي

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

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