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

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

آلية تحميل صفحة الويب

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

على سبيل المثال، لنفرض أن لدينا موقع ويب بالهيكلية التالية:

.
├── index.html
├── package.json
└── statics
    ├── css
    │   ├── footer.css
    │   ├── header.css
    │   └── main.css
    ├── images
    │   ├── 1.jpg
    │   ├── 2.jpg
    │   ├── 3.png
    │   ├── 4.png
    │   └── 5.jpg
    └── js
        ├── foo.js
        ├── bar.js
        └── index.js

لعرض ملف index.html لهذا الموقع بشكل كامل، سيحتاج المتصفح لإرسال 12 طلب على النحو التالي:

• طلب واحد لتحميل ملف HTML
• ثلاثة طلبات لتحميل ملفات CSS
• ثلاثة طلبات لتحميل ملفات JavaScript
• خمسة طلبات لتحميل الصور 

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

أولًا: تحسين الصور

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

استخدام تنسيقات الصور الحديثة

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

سنستخدم في حالتنا أداة تسمى FFmpeg لتحسين الصور، حيث تتيح لنا هذه الأداة تحويل الصور محليًا باستخدام أمر بسيط. سنحتاج لتثبيت الأداة على حاسوبنا، في حال استخدام نظام التشغيل Mac سنثبتها من خلال مدير الحزم Homebrew من خلال الأمر التالي:

brew install ffmpeg

وفي حال استخدام نظام التشغيل ويندوز فيمكننا تثبيتها مباشرة من موقعها الرسمي أو تثبيتها باستخدام Winget كالتالي:

winget install --id=Gyan.FFmpeg  -e

بعد الانتهاء من عملية التثبيت، سنفتح الطرفية terminal وننتقل إلى دليل صور موقعنا باستخدام الأمر التالي:

cd /path/to/images

ثم نحول الصور للتنسيق webp باستخدام الأمر التالي:

for file in *.{jpg,png}; do ffmpeg -i "$file" -c:v libwebp -q:v 80 "$(basename "$file" .${file##*.}).webp"; done

وفي حال استخدام سطر الأوامر CMD في ويندوز، نستخدم الأمر التالي:

for %i in (*.jpg *.png) do ffmpeg -i "%i" -c:v libwebp -q:v 80 "%~ni.webp"

أما إذا كنا نستخدم PowerShell في ويندوز، فسنستخدم الأمر التالي:

Get-ChildItem -Path . | Where-Object { $_.Extension -match '\.jpg$|\.png$' } | ForEach-Object { ffmpeg -i $_.FullName -c:v libwebp -q:v 80 ($_.BaseName + ".webp") }

قد نحتاج إلى تعديل الأمر ليناسب حالتنا الخاصة:

• {jpg,png} لتحويل صيغ الصور jpg و png في المجلد
• c:v libwebp- يحدد للأداة FFmpeg ما هو الترميز المستخدم لصيغة WebP. لا حاجة لتغيير هذا الخيار
• q:v 80- يحدد مستوى ضغط للصور، يمكن تعديل القيمة بين 0 لأدنى جودة وأعلى ضغط، و 100 لأعلى جودة ودون ضغط

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

حجم ملف JPG  هنا هو 2.7 ميجابايت، بينما حجم ملف WebP هو 176 كيلوبايت بالرغم أن كلا الصورتين لهما نفس الأبعاد 4000 × 6000 بكسل ونفس الوضوح لكن تنسيق WebP تمكن من ضغط الصورة بشكل أكبر، لذا يُعد خياراً مثالياً للاستخدام على الويب وسيساعدنا في زيادرة سرعة تحميل الصفحات.

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

استخدام أحجام صور مختلفة لأحجام الشاشات المختلفة

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

تساعدنا أداة FFmpeg التي استخدمناها سابقًا على تحقيق ذلك، بعد إنتاج إصدارات الصور المختلفة علينا تضمين الصور في صفحة الويب باستخدام العنصر <picture> بدلاً من <img>. حيث يسمح العنصر <picture> بتحديد مصادر متعددة للصورة نفسها، ويتيح للمتصفح اختيار الصورة الأنسب تلقائيًا حسب حجم الشاشة.

<picture>
  <source media="(max-width: 600px)" srcset="small.webp" />
  <source media="(max-width: 1200px)" srcset="medium.webp" />
  <img src="large.webp" alt="example image" />
</picture>

إذا كان عرض الشاشة 600 بكسل أو أقل كحالة هاتف محمول ستُعرَض الصورة small.webp، وإذا كان العرض بين 601 بكسل و 1200 بكسل كحالة جهاز لوحي ستُعرَض الصورة medium.webp، وإذا لم يتحقق أي من الشروط السابقة أي كان عرض الشاشة أكبر من أكبر من 1200 بكسل فستُعرَض الصورة الصورة الافتراضية large.webp.

التحميل الكسول للصور Lazy Load

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

<picture>
  <source media="(max-width: 600px)" srcset="small.webp" />
  <source media="(max-width: 1200px)" srcset="medium.webp" />
  <img src="large.webp" alt="example image" loading="lazy" />
</picture>

لاحظ أننا جعلنا الصورة الكبيرة large.webp تُحمّل بشكل كسول من خلال ضبط الخاصية loading بالقيمة "lazy" في الوسم <img> لضمان أن المتصفح سيحمّل هذه الصورة فقط عندما يمرر المستخدم لأسفل ويصل لموقع هذه الصورة. لكن إذا كانت الصورة جزءًا أساسيًا من تصميم الصفحة وكنا نحتاج لعرضها فورًا عند تحميل الصفحة فمن الأفضل ضبط الخاصية loading بالقيمة "eager". لجعل المتصفح يحمّلها على الفور دون انتظار.

<picture>
  <source media="(max-width: 600px)" srcset="small.webp" />
  <source media="(max-width: 1200px)" srcset="medium.webp" />
  <img src="large.webp" alt="example image" loading="eager" />
</picture>

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

ثانيًا: تحسين ملفات CSS وجافا سكريبت

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

دمج ملفات CSS وتقليل حجمها

تتوفر عدة أدوات لتحقيق هذا الأمر مثل PostCSS فهو معالج CSS يمكنه دمج ملفات التنسيقات، وتقليل حجم كودها. كما يمكن تعزيزه بإضافات plugins مساعدة لتحسين الكود وحل مشكلات التوافق مع المتصفحات.

غالبًا ما يكون PostCSS جزءًا من أدوات تسمى مُجمِّعات الويب web bundlers تستخدم لتجميع ملفات الموقع المختلفة وسنتحدث عنها بالتفصيل لاحقًا، ومع ذلك، يمكننا استخدام PostCSS بشكل مستقل وتثبيته في مشروعنا باستخدام مدير الحزم npm كالتالي:

npm install postcss postcss-cli postcss-import postcss-preset-env cssnano --save-dev

بعدها علينا إنشاء ملف إعدادات PostCSS باسم postcss.config.js في الدليل الجذر لمشروعنا، ونحدد فيه ما هي الإضافات plugins التي نريد استخدامها لتحسين الكود.

module.exports = {
  plugins: [
    require("postcss-import"),
    require("postcss-preset-env"),
    require("cssnano"),
  ],
};

استخدمنا هنا الإضافات التالية:

• postcss-import لدمج ملفات CSS متعددة داخل ملف واحد
• postcss-preset-env لاستخدام خصائص CSS الحديثة والتأكد من توافقها مع المتصفحات
• cssnano لتقليص حجم ملفات CSS

بعدها ننشئ ملف CSS رئيسي باسم styles.css كي يستورد جميع التنسيقات الأخرى الضرورية:

├── index.html
├── package-lock.json
├── package.json
├── postcss.config.js
└── statics
    ├── css
    │   ├── footer.css
    │   ├── header.css
    │   ├── main.css
    │   └── styles.css
    ├── images
    └── js

يستورد الملف styles.css كافة ملفات التنسيقات كالتالي:

@import "./header.css";
@import "./main.css";
@import "./footer.css";

بعدها ندمج الملفات معًا في هذا الملف، ونضعه في المجلد dist/ ونصغّر حجمه باستخدام الأمر التالي:

npx postcss statics/css/styles.css -o dist/styles.css

وبهذا سيكون الملف جاهزًا للاستخدام في الموقع، كل ما علينا هو استيراد الملف dist/styles.css الناتج في مستند HTML كما يلي:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    <link rel="stylesheet" href="dist/styles.css" />
  </head>
  <body>
    . . .
  </body>
</html>

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

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    <link rel="stylesheet" href="dist/critical.css" />
  </head>
  <body>
    . . .
    <link rel="stylesheet" href="dist/non-critical.css" />
  </body>
</html>

مُجمِّعات الويب web bundlers

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

الأداة Webpack

يعد Webpack أداة مشهورة حاصلة على أكثر من 63 ألف نجمة على GitHub، فهو يساعدنا على تجميع ملفات مختلفة من أنواع متعددة مثل JavaScript و CSS في ملفات مُجمعّة يمكن للمتصفح تنفيذها بسرعة، كما يوفر لنا أدوات لمعالجة الصور. يمكن تثبيت Webpack في مشروعنا كما يلي:

npm install webpack webpack-cli --save-dev

لنفترض أن لدينا هيكل المشروع التالي، ولنوضح بشكل مبسط كيفية عمل Webpack في تجميع ملفات جافا سكريبت لهذا المشروع:

.

├── dist
├── index.html
├── package-lock.json
├── package.json
├── postcss.config.js   # إعدادات PostCSS
├── statics
│   ├── css
│   ├── images
│   └── js
│       ├── bar.js
│       ├── foo.js
│       └── index.js
└── webpack.config.js #  إعدادات Webpack

لدينا ثلاث ملفات جافا سكريبت في مشروعنا وهي: الملف foo.js:

export default function foo() {
  console.log("foo");
}

والملف bar.js:

export default function bar() {
  console.log("bar");
}

والملف index.js:

import foo from "./foo.js";
import bar from "./bar.js";

foo();
bar();

console.log("Hello, World!");

في هذه الحالة، سيكون الملف index.js هو نقطة الدخول لمشروعنا، أي سنحمّل هذا الملف أولاً ومن ثم نتبعه بتحميل الملفات المستوردة داخله. ولإنشاء ملف إعدادات Webpack، علينا إنشاء ملف webpack.config.js في الدليل الجذر لموقعنا، ونتأكد من أن خيار entry يشير إلى ملف index.js. سيكون ملف الإعدادات webpack.config.js كما يلي:

const path = require("path");

module.exports = {
  entry: "./statics/js/index.js",
  output: {
    filename: "bundle.js",
    path: path.resolve(__dirname, "dist"),
  },
};

الآن عند تنفيذ Webpack، سيبدأ بالبحث عن الملف index.js، ثم عن الملفين foo.js و bar.js ويجمع كل الأكواد في ملف واحد يسمى bundle.js. بعدها نستخدم الأمر التالي لتشغيل Webpack :

npx webpack --config webpack.config.js

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

(() => {
  "use strict";
  console.log("foo"), console.log("bar"), console.log("Hello, World!");
})();

يعالج Webpack ملفات جافا سكريبت فقط، ولكن يمكننا توسيع إمكانياته بتثبيت أدوات تحميل loaders مختلفة. على سبيل المثال، عند تحميل css-loader في Webpack سنتمكن من معالجة ملفات CSS، وعند تحميل postcss-loader ستوافق Webpack مع معالج PostCSS الذي استخدمناه سابقًا.

إضافة إلى Webpack، هناك العديد من أدوات تجميع الويب الشهيرة الأخرى نذكر منها Parcel و Esbuild و Rollup وكل منها يمتلك ميزات وخصائص فريدة. يعود اختيار الأداة المناسبة لاحتياجاتنا ومتطلبات مشروعنا.

الأداة Vite

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

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

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

الخاصيتان async و defer

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

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

<script src="path/to/script.js" async></script>
<script src="path/to/script.js" defer></script>

كلا الخيارين يوجهان المتصفح لتحميل كود جافا سكريبت في الخلفية. ويكمن الاختلاف بينهما هو أن الخاصية async تخبر المتصفح بتنفيذ هذا الكود فور تحميله، بينما تخبر الخاصية defer المتصفح بأن ينتظر حتى يكتمل تحليل الصفحة قبل تنفيذه.

في حال وجود عدة أكواد جافا سكريبت في صفحة الويب مع استخدام الخاصية defer فإنها ستحمّل جميع هذه الأكواد في الخلفية، ثم ستنفّذ بالترتيب الذي ظهرت به في الكود، أما إذا استخدمنا الخاصية async فسينفّذ السكربت الذي انتهى تحميله أولاً بغض النظر عن ترتيبه.

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

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

ثالثًا: تعزيز أداء صفحة الويب باستخدام تلميحات الموارد

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

تسمح لنا تلميحات الموارد بإخبار المتصفح بكيفية معالجة هذه الموارد وذلك باستخدام وسم <link> الذي نضعه في قسم الترويسة head من ملف HTML، هناك العديد من تلميحات الموراد المفيدة والتي سنشرحها تاليًا.

التلميح dns-prefetch

يساهم التلميح dns-prefetch في تحسين أداء الصفحة عن طريق إجراء عملية بحث مسبق لنظام أسماء النطاقات DNS لمورد خارجي قد يحتاجه المتصفح في المستقبل. فعندما يستخدم المتصفح هذا التلميح سيبدأ في معالجة اسم النطاق ويحوله لعنوان IP مناسب في الخلفية، مما يسرع الاتصال بالخادم عند الحاجة إليه لاحقًا، لاحظ الكود التالي:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>

    <link rel="dns-prefetch" href="https://style.example.com" />
  </head>
  <body>
    . . .
  </body>
</html>

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

من خلال تلميح المورد هنا سيعرف المتصفح بأن المستخدم قد يقوم ببعض الإجراءات التي ستتطلب منه البحث عن عنوان الـ IP الخاص بـالنطاق https://style.example.com. وبالنتيجة، يبدأ المتصفح في حل اسم النطاق في أقرب وقت ممكن ويخزن النتيجة محليًا. يسمح هذا التخزين المؤقت للمتصفح بسحب عنوان IP مباشرة من الذاكرة المؤقتة عندما يطلبه المستخدم.

التلميح preconnect

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

<link rel="preconnect" href="https://style.example.com" />

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

التلميح preload

يخبر التلميح preload المتصفح بكيفية تحميل الموارد لصفحة الويب الحالية.

<link rel="preload" href="path/to/script.js" as="script" />

تٌعطى الموارد المعرفة بـ href أولوية عالية وتُحمّل في أسرع وقت ممكن. كما يسمح تلميح preload بتحديد خاصية إضافية تسمى as كي نحدد نوع المورد ونوضح بأنه يتطلب ترويسات طلب request headers مختلفة أو سياسات أمان مختلفة. 

على سبيل المثال قد تحتاج الموارد من نوع script مثل أكواد جافا سكريبت لطريقة تعامل مختلف عن الموارد من نوع style مثل أكواد CSS أو الموارد من نوع image لضمان الأمان ومنع التعارضات. ولتحقيق أفضل تجربة مستخدم، يمكن تحديد الموارد الأساسية مثل تنسيقات CSS و أكواد جافا سكريبت الأساسية والخطوط والصور المهمة باستخدام التلميح preload لتحميلها بأولوية عالية عند التحميل الأولي للصفحة.

التلميح prefetch

<link rel="prefetch" href="path/to/style.css" as="style" />

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

التلميح prerender

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

<link rel="prerender" href="next_page.html" />

رابعًا: استخدم شبكة توصيل المحتوى CDN

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

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

هناك العديد من الشركات التي توفر خدمات CDN مثل CloudFlare و Amazon CloudFront و Google Cloud CDN، وتختلف عملية إعداد CDN حسب الشركة التي نختارها ويمكن الرجوع إلى الوثائق الرسمية لموفر الخدمة وإعدداها وفق ما يناسبنا.

خامسًا: إعداد التخزين المؤقت Caching

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

كما يحتوي مستند HTML على قسم <head>، الذي يستخدم لتخزين البيانات الوصفية metadata للصفحة، يحتوي كل طلب HTTP واستجابة HTTP أيضًا على ترويسة header وهي جزء من البيانات التي ترسل مع كل طلب أو استجابة بين المتصفح والخادم. ويمكن استخدام الترويسة Cache-Control في HTTP لإخبار المتصفح بكيفية تخزين الموارد مؤقتًا.

قد توجد طرق مختلفة لإضافة رؤوس HTTP مخصصة اعتمادًا على كيفية استضافة موقعنا الإلكتروني، على سبيل المثال إذا كنا نستخدم منصة سحابية لاستضافة موقعنا مثل  AWS Amplify، فيمكن إضافة هذه الرؤوس المخصصة في ملف إعدادات التطبيق customHttp.yml لزيادة سرعة تحميل الصفحات. كل ما علينا هو الانتقال إلى إعدادات التطبيق App settings ثم اختيار الرؤوس المخصصة custom headers وتحرير الملف customHttp.yml ليشمل إعدادات التخزين المؤقت المناسبة على النحو التالي:

customHeaders:
  - pattern: '**/*.js'
    headers:
      - key: Cache-Control
        value: 'public,max-age=31536000,s-maxage=86400,immutable'
  - pattern: '**/*.css'
    headers:
      - key: Cache-Control
        value: 'public,max-age=31536000,s-maxage=86400,immutable'
  . . .

في هذا المثال سنخزن ملفات جافا سكريبت و CSS في الذاكرة المؤقتة لزيادة سرعة تحميل الموقع وفق التالي:

• تعني public أن الملف يمكن تخزينه في ذاكرة التخزين المؤقت العامة مثل شبكة توصيل المحتوى CDN
• يحدد max-age=31536000 المدة التي يمكن فيها تخزين الملف في ذاكرة التخزين المؤقت للمتصفح مقدرة بالثواني
• يحدد s-maxage=86400 المدة التي يمكن فيها تخزين الملف في ذاكرة التخزين المؤقت العامة مثل CDN مقدرة بالثواني 
• تعني immutable أن محتوى الملف لن يتغير مع مرور الوقت فإذا كان لدينا ملف .htaccess في موقعنا، يمكن استخدام الأداة .htaccess Generator لإنشاء الكود المناسب بدلاً من كتابته يدويًا

سادسًا: استخدام بدائل Google Analytics

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

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

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

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

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

الخاتمة

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

ترجمة -وبتصرف- للمقال Top Website Optimization Tools in 2024

اقرأ أيضًا

• زيادة سرعة أداء المواقع باستخدام تقنية pre-fetching
• نصائح لتحسين أداء تطبيقات لارافيل
• كيفية استخدام شبكات توزيع المحتوى CDN لتحسين أداء مواقع ووردبريس
• مدخل إلى مُسرّع تطبيقات الويب Varnish Cache

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

تطور المعالجات الحاسوبية

أصبحت وحدة المعالجة المركزية Central Processing Unit -أو CPU اختصارًا- مكونًا أساسيًا في أنظمة الحواسيب منذ بداية سبعينيات القرن الماضي، فتطورت من مجرد آلات بسيطة لإجراء الحسابات والمعالجات الرياضية إلى معالجات متعددة النواة وبالغة التعقيد. فكان إصدار إنتل لمعالجها 4004 في عام 1971علامة فارقة لبداية حقبة وحدات المعالجات المركزية الحديثة ومهد الطريق للتطورات المتسارعة في قدرات المعالجة، ومع مرور الزمن أصبحت وحدات المعالجة المركزية CPUs أكثر تخصصًا وتعقيدًا حيث ظهرت ابتكارات مثل خطوط أنابيب تجزئة تنفيذ التعليمات Instruction pipelining ومتنبئ التعليمات التفرعية Branch Predictor و تقنية خيوط المعالجة الفائقة Hyper-threading وقد دفعت هذه التقنيات بحدود المعالجة الحاسوبية العامة إلى الأمام.

ثم ظهرت وحدة المعالجة الرسومية Graphics Processing Unit -أو GPU اختصارًا- في بداية التسعينيات لتلبي الطلب المتزايد على المعالجة الرسومية في ألعاب الفيديو ورسوميات الحواسيب. وعلى النقيض من وحدات المعالجات المركزية CPUs التي كانت مصممة لتنفيذ التعليمات على التسلسل sequential فقد صممت المعالجات الرسومية GPUs للتعامل مع الحسابات والعمليات على التوازي parallel من أجل تنفيذ المهام الرسومية المعقدة، وكان تقديم نيفيديا لمعالجها جيفورس GeForce 256 في عام 1999 بداية حقبة جديدة للعتاد المخصص للرسوميات القادر على تخفيف الحمل الحاسوبي عن وحدات المعالجات المركزية CPUs في مهام المعالجة الرسومية.

صُممت وحدات المعالجة المركزية والرسومية في البداية لأغراض مختلفة، لكن في السنوات الأخيرة بدأت قدراتهما وأدوارهما تتداخل مع بعضها البعض، فأصبحت وحدات المعالجة المركزية CPUs مدمجة مع قدرات المعالجة على التوازي، وصارت وحدات المعالجة الرسومية GPUs أكثر شمولًا وتنوعًا وظهرت لها تطبيقات أخرى غير الرسوميات مثل حل المسائل العلمية المعقدة وتطبيقات تعلم الآلة، كما حظت المعالجات الرسومية بشعبية كبيرة في السنوات الأخيرة نتيجة أدائها المبهر في أداء مهام الذكاء الاصطناعي وبالتحديد قدرتها على المعالجة المتوازية parallel computing فكانت الأداة المثالية لتدريب شبكات التعلم العميق وإجراء العمليات الحسابية على المصفوفات الضخمة التي تلعب دورًا أساسيًا في العديد من خوارزميات الذكاء الاصطناعي، مما دفع إلى اكتشافات علمية متقدمة في مجالات بحثية وتطبيقية مختلفة مثل الرؤية الحاسوبية Computer Vision ومعالجة اللغات الطبيعية Natural Language Processing والذكاء الاصطناعي التوليدي Generative AI.

ما هي وحدة المعالجة المركزية CPU

وحدة المعالجة المركزية CPU هي المكون الرئيسي في أجهزة الحواسيب، فهي تقوم بأغلب العمليات والمعالجة، ويشار إليها في سياقات كثيرة بعقل الحاسوب، وتنفذ وحدة المعالجة المركزية CPU التعليمات والحسابات وتنظم الأنشطة المختلفة للعتاد الحاسوبي. وتسود اليوم معالجات متعددة الأنوية multi-core processors قادرة على تنفيذ العديد من المهام في نفس الوقت مستغلة قدرات المعالجة المتوازية والمعماريات المتقدمة.

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

آلية عمل وحدة المعالجة المركزية CPU

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

وحدة التحكم Control unit 

تعد وحدة التحكم بمثابة مركز القيادة الخاص بوحدة المعالجة المركزية CPU، فهي تدير وتنسق كل العمليات الخاصة بوحدة المعالجة المركزية CPU.

وحدة الحساب والمنطق ALU‎

تجري في وحدة الحساب والمنطق Arithmetic Logic Unit -أو ALU اختصارًا- كل العمليات الحسابية والمنطقية مثل الجمع والطرح والمقارنة، فهي تشكل أساس القدرات الحسابية لوحدة المعالجة المركزية CPU.

السجلات Registers 

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

الذاكرة المخبئية Cache

الذاكرة المخبئية Cache هي ذاكرة مؤقتة صغيرة الحجم مبنية بداخل وحدة المعالجة المركزية وهي تتميز بسرعتها وتستخدم لتخزين البيانات والتعليمات التي يُحتمل استخدامها بشكل متكرر لتسريع المعالجة، ولكنها أقل سرعة من السجلات Registers وأكبر منها في الحجم.

الجلب Fetch

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

فك التشفير Decode

تأتي هذه الخطوة بعد جلب fetching التعليمة حيث يجري تفسيرها بواسطة وحدة المعالجة المركزية CPU، وتعمل وحدة التحكم Control Unit على فك تشفير العمليات وتحديد ما هي العمليات التي ينبغي تنفيذها، وما هي البيانات التي تحتاجها هذه العملية.

التنفيذ Execute  

تنفذ وحدة المعالجة المركزية CPU التعليمة، وقد يتطلب التنفيذ عمليات حسابية أو منطقية باستخدام وحدة الحساب والمنطق ALU، أو نقل بيانات خلال السجلات المختلفة، أو التفاعل مع أجزاء مختلفة من الحاسوب.

التخزين Store

إن كانت العملية المُنفذَّة تعيد نتيجة فسوف تحفظ هذه النتيجة في سجل register أو في الذاكرة، ويُحَدَّث عداد البرنامج program counter ليشير للتعليمة القادمة، لتبدأ نفس الحلقة في التكرار مجددًا.

ما هي وحدة المعالجة الرسومية GPU

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

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

آلية عمل وحدة المعالجة الرسومية GPU

تعمل وحدات المعالجة الرسومية GPUs بمبادئ مشابهة لتلك التي تتبعها وحدات المعالجة المركزية CPUs ولكنها مصممة ومحسنة لمهام المعالجة المتوازية، وهذا يجعلها الخيار الأنسب لعرض الرسوميات ولأنواع معينة من المهام. وسنشرح تاليًا آلية عمل وحدة المعالجة الرسومية GPU:

المعالجات متعددة التدفق SMs‎

تكافئ المعالجات متعددة التدفق Streaming Multiprocessors -أو SMs اختصارًا- الأنوية cores المستخدمة في وحدات المعالجة المركزية ولكن يحتوي كل معالج متعدد التدفق SM على وحدات معالجة أصغر ومتعددة ما يكسبه القدرة على التعامل مع تدفق كبير من البيانات حيث تُمكّن هذه المعمارية وحدات المعالجة الرسومية GPUs من التعامل مع العديد من المهام بنفس الوقت.

أنوية كودا CUDA Cores 

تقع هذه الأنوية بداخل وحدات معالجة التدفق SM، وهي المسؤولة عن المعالجة بداخلها، وهي أبسط من أنوية وحدة المعالجة المركزية CPU ولكنها توجد بأعداد أكبر بكثير، حيث قد يوجد في وحدة المعالجة الرسومية GPU آلاف منها.

وحدات رسم الخامة TMUs‎ 

تعمل وحدة رسم الخامة Texture Mapping Unit أو TMU اختصارًا على رسم الخامة أو السطح الخارجي للنماذج ثلاثية الأبعاد بسرعة كبيرة، وهي وظيفة فريدة توجد فقط في وحدات المعالجة الرسومية GPUs وليست موجودة في وحدات المعالجة المركزية CPUs.

ذاكرة الفيديو VRAM‎

تتشابه ذاكرة الفيديو Video Memory في الوظيفة مع ذاكرة الوصول العشوائي الخاصة بوحدة المعالجة المركزية CPU، ولكنها محسنَّة لمهام المعالجة الرسومية، وهي في الغالب أسرع وتمتلك معدل نقل بيانات أكبر من الذي تملكه ذاكرة RAM.

الجلب Fetch

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

فك التشفير Decode

تشابه هذه الوظيفة نظيرتها في وحدة المعالجة المركزية CPU والاختلاف بينهما هو تحسين هذه الوظيفة في GPU لتناسب مع المهام المتعلقة بمعالجة الرسوميات.

التنفيذ Execute

تختلف هذه الخطوة بشكلٍ جذري عن نظيرتها في وحدة المعالجة المركزية CPU، حيث تُنفِّذ وحدات المعالجة الرسومية GPUs العديد من التعليمات المتشابهة بشكل متزامن من خلال عدد كبير من أنوية كودا CUDA cores في عملية تسمى Single instruction Multiple Data -أو SIMD اختصارًا- والتي تعني إمكانية تنفيذ نفس التعليمة على عدة بيانات في نفس الوقت.

التخزين Store

تُحفظ النتائج عادة في ذاكرة الفيديو Video Random Access Memory -أو VRAM اختصارًا- ويسمح المستوى العالي من التوازي الذي توفره وحدات المعالجة الرسومية GPUs بتحقيق معدل نقل بيانات كبير جدًا من أجل تنفيذ المهام المتعلقة بالرسوميات.

مقارنة بين وحدة المعالجة المركزية CPU ووحدة المعالجة الرسومية GPU

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

الوظيفة الأساسية

صُمّمت وحدات المعالجة المركزية CPUs لتكون شاملة ومتعددة الأغراض وقادرة على التعامل مع طيف واسع من المهام بكفاءة عالية، فهي تتميز في المعالجة المتسلسلة sequential processing، كما أنها مُحسّنة لاتخاذ القرارات المعقدة، وتتحكم وحدة المعالجة المركزية CPU في العتاد الحاسوبي والتنسيق بين البرامج المختلفة لتشغيلها.

بنما كانت وحدات المعالجة الرسومية GPUs متخصصة في البداية في عرض الرسوميات graphics rendering، ولكنها تطورت مع الوقت لتصبح معالجات فائقة لها القدرة على المعالجة المتوازية parallel processors. وهي اليوم تشغّل التعليمات تمامًا كوحدات المعالجة المركزية CPUs ولكنها محسنة للتعامل مع الكثير من العمليات الحسابية المتزامنة. فوحدات المعالجة المركزية CPU متنوعة القدرات وشاملة المهام، في حين أن وحدات المعالجة الرسومية تتميز بالتخصص والتفوق في تنفيذ المهام القابلة للتقسيم إلى مهام كثيرة جدًا والتي تتميز بكونها مهام متشابهة ويمكن حسابها بشكل مستقل عن بعضها البعض.

المعالجة

تُنفِّذ وحدات المعالجة المركزية CPUs العمليات بشكل متتابع أو متسلسل، حيث تُنفِّذ التعليمات المعقدة واحدة تلو الأخرى وتستخدم تقنيات مخصصة مثل التنبؤ بالتعليمات المتفرعة أو الشرطية branch prediction أو التنفيذ غير المراعي للترتيب Out-of-Order Execution الذي يسمح بتنفيذ التعليمات بترتيب مختلف عن ترتيبها الأصلي في البرنامج لتحسين عملية المعالجة المتسلسلة، حيث تشبه وحدات المعالجة المركزية CPUs المدير المنظم فهي تنسق وتتعامل مع مهام متنوعة وتتخذ القرارات المعقدة بسرعة.

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

تصميم الهيكلية

تمتلك وحدات المعالجة المركزية CPUs في الغالب من 2 إلى 64 نواة معقدة التركيب ومزودة بذاكرة مخبئية Caches ووحدات تحكم Control units مخصصة ومعقدة، حيث صممت هذه المكونات لتحقق أقل معدل تأخير في الاستجابة low latency، فتستطيع كل نواة التعامل مع مهام متنوعة بشكل مستقل، فتولي هذه الهيكلية أهمية للتنوع في القدرات وسرعة الاستجابة لعدد واسع ومتنوع من المهام.

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

حالات الاستخدام

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

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

دمج وحدة المعالجة المركزية CPU مع وحدة المعالجة الرسومية GPU

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

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

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

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

ترجمة وبتصرف لمقالة ?What is the Difference Between CPU and GPU.

اقرأ أيضًا

• تعدد المهام Multitasking في الحواسيب
• وحدة المعالجة المركزية
• تعرف على وحدة المعالجة المركزية وعملياتها في معمارية الحاسوب
• استكشف مصطلحات الذكاء الاصطناعي التوليدي
• توليد النصوص باستخدام النماذج اللغوية الكبيرة LLMs

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

متطلبات مسبقة للعمل

نحتاج قبل إكمال هذا المقال إلى ما يلي:

• حساب على تطبيق تلغرام
• حساب جوجل مع إمكانية الوصول إلى تطبيق جداول بيانات جوجل Google Sheets
• معرفة مسبقة باستعمال Google Sheets، ويمكن الرجوع إلى مقال مقدمة إلى جداول بيانات جوجل Google Sheets
• معرفة أساسية بلغة جافاسكريبت، ويمكن الرجوع إلى مقال تعلم لغة جافا سكريبت JavaScript

التطبيق النموذجي لربط بوت تلغرام مع جداول بيانات جوجل

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

ملاحظة: استخدمنا هذا النموذج بغرض التعلم ونترك لكم تطبيق ما ستتعلمونه على نموذج البيانات المناسب لاحتياجاتكم.

الخطوة الأولى: إنشاء بوت تلغرام Telegram Bot

سنستعمل تطبيق تلغرام على الويب للسهولة، لذا سنفتح تطبيق تلغرام ويب ونسجل الدخول، ثم نبحث في حقل البحث عن BotFather وهو كبيرُ البوتات الذي سيساعدنا على إنشاء بوتات تلغرام وإدراتها. لنتبه إلى أن مُعرِّف كبير البوتات الرسمي هو ‎@botfather إذ ستظهر لنا عدة نتائج في حقل البحث:

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

سيطلب بعدها كبيرُ البوتات إدخال اسم مُعرِّف أو اسم المستخدم للبوت الجديد، وننتبه لأن هذا الاسم يجب أن ينتهي بالكلمة bot سواءً بالشكل usernameBot أو username_bot، وسنستخدم هنا الاسم MyIncomeAndExpensesBot:

ملاحظة: قد لا يقبل البوت بعض اقتراحات اسم المستخدم مثلًا عندما جربنا إدخال اسم المستخدم IncomeExpensesBot وIncomeAndExpensesBot لم يقبلهما لكونهما محجوزان مسبقً، لذا قد نحتاج لتعديل الاسم حتى نجد اسمًا متاحًا.
سينُشئ بعدها كبيرُ البوتات البوت الجديد ويرسل لنا رسالة يخبرنا فيها عن رابط الوصول للبوت ورمز الوصول إليه access token عبر طلبات HTTP:

لنحفظ هذا الرمز لأننا سنستعمله لاحقًا في التواصل مع هذا البوت.

تجربة التواصل مع بوت تلغرام الجديد

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

https://api.telegram.org/bot{access_token}/getMe    

إن سارت الأمور على ما يرام، فسنحصل على نتيجة مشابهة للنتيجة التالية تحوي تفاصيل البوت ورده علينا:

{    
  "ok": true,    
  "result": {    
    "id": 7666156735,    
    "is_bot": true,    
    "first_name": "إيرادات ونفقات",    
    "username": "MyIncomeAndExpensesBot",    
    "can_join_groups": true,    
    "can_read_all_group_messages": false,    
    "supports_inline_queries": false,    
    "can_connect_to_business": false,    
    "has_main_web_app": false    
  }    
}    

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

ضبط بوت تلغرام

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

سنذكر بعض هذه الأوامر:

•  ‎/mybots لعرض بوتات تلغرام الخاصة بنا
•  ‎/setname لتغيير اسم بوت تلغرام
• ‎/setdescription لضبط أو تغيير وصف البوت
• ‎/setuserpic لضبط أو تغيير صورة البوت

يمكن تجربة هذه الأوامر مع بقية الأوامر لتتعلم أكثر عن ضبط وإدارة بوتات تلغرام.

فهم آلية الربط والتواصل بين بوت تلغرام وجداول بيانات جوجل

قبل أن ننتقل إلى الخطوة التالية من مقالنا، من الضروري فهم آلية ربط بوت تلغرام مع جداول بيانات جوجل -أو أي خدمة أخرى مثلًا- حتى نفهم كيف سنكمل عملية الضبط.
لنتذكر أن هدف المقال إرسال رسالة بصيغة معينة إلى بوت تلغرام، ليقوم بدوره بتنفيذ أوامر محددة وظيفتها أخذ رسالتنا وإرسالها إلى جداول بيانات جوجل لتخزينها هناك، وبذلك يمكن تقسيم العملية إلى ثلاثة خطوات، الأولى إرسال الرسالة التي تحوي البيانات إلى البوت، و الثانية نقل البيانات، والثالثة تخزينها في وجهتها.
يمكننا التواصل مع البوت عبر آليتين : الأولى هي التواصل عبر الواجهة البرمجية APIs مباشرةً وسؤاله عما نريد، مثلًا يمكن إرسال طلب للواجهة البرمجية ‎/getMe لطلب معلومات عن البوت، أو الواجهة البرمجية ‎/getUpdates لطلب كافة الرسائل المرسلة إلى البوت وغيرها، ويمكنك الرجوع إلى توثيق واجهات بوت تلغرام البرمجية للاطلاع على القائمة الكاملة.
الآلية الثانية هي التواصل من خلال خطافات الويب Web Hooks أي أننا نطلب من البوت نفسه أن يتواصل معنا عند وقوع أحداث معينة، وسنجد في توثيق Update قائمة الأحداث المدعومة في بوت تلغرام،  حيث نحدد ما هي الأحداث التي نحتاجها بالضبط.

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

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

لننشئ جدول بيانات جديد في درايف لتخزين البيانات الواردة من بوت التلغرام برمجيًا بشكل مؤتمت، وذلك عبر إضافة توفرها جوجل وهي لغة برمجة تطبيقات جوجل Apps Scripts .

ما هي لغة Google Apps Scripts

تعد Google Apps Scripts لغة برمجة هدفها إدارة جميع تطبيقات جوجل كبريد Gmail وتخزين Drive وجداول بيانات جوجل Sheets وغيرها، وهي مبنية على لغة جافاسكربت ولاحقتها ملفاتها البرمجية هي ‎.gs وتوفر جوجل بيئة تطوير على السحابة Google Workspace تساعدنا على تنفيذ الأكواد التي نكتبها بهذه اللغة، أي لن نحتاج لبيئة تطوير لمعالجة وتنفيذ الملفات المكتوبة بهذه اللغة محليًا.

التحكم بجدول البيانات برمجيًا

بعد إنشاء جدول بيانات جديد وتسميته باسم الإيرادات والنفقات، يمكننا ربطه والتحكم به برمجيًا بسهولة عبر Apps Scripts من خيار الإضافات Extensions ثم برمجة تطبيقات Google كما في الصورة التالية:

سيُنشَأ ملف بلغة برمجة تطبيقات جوجل Apps Scripts ويُربط بملف جداول البيانات:

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

function getMe() {   
 const response = UrlFetchApp.fetch('https://api.telegram.org/bot7666156735:AAFlJYPgOzT5cTf8CfRx_5vf0GNuVmcvAuk/getMe');

 Logger.log(response.getContentText());    
}  

استعملنا الدالة UrlFetchApp.fetch لجلب محتوى رابط أو واجهة برمجية، ومررنا لها رابط الواجهة البرمجية ‎/getMe كاملًا مع رمز الوصول access token، ثم استعملنا Logger.log لطباعة الناتج.
نضغط على زر تنفيذ في الأعلى، وبما أننا ننفذ هذا السكربت لأول مرة فسيُطلَب منا إعطاءه صلاحيات محددة:

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

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

const token = '7666156735:AAFlJYPgOzT5cTf8CfRx_5vf0GNuVmcvAuk';    
const url = 'https://api.telegram.org/bot' \+ token;

function getMe() {    
 const response = UrlFetchApp.fetch(url \+ '/getMe');
 Logger.log(response.getContentText());  
}    

يمكن الآن استدعاء ‎/getUpdates بسهولة بكتابة دالة جديدة باسم getUpdates بالشكل التالي:

const token = '7666156735:AAFlJYPgOzT5cTf8CfRx_5vf0GNuVmcvAuk';    
const url = 'https://api.telegram.org/bot' \+ token;

function getMe() {`    
const response = UrlFetchApp.fetch(url \+ '/getMe');
Logger.log(response.getContentText());   
}

function getUpdates() {   
const response = UrlFetchApp.fetch(url \+ '/getUpdates');
Logger.log(response.getContentText());  
}    

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

نشر تطبيق ويب يصل بين بوت تلغرام وجداول بيانات جوجل

فهمنا سابقًا آلية التواصل التي سنطبقها والتي تتم بتواصل بوت التلغرام عبر خطاف ويب web hook مع خادم ويب كلما استلم البوت رسالة جديدة بعدها سيعمل خادم الويب على تخزين البيانات الواردة بعد معالجتها في جدول البيانات كما هو موضح بالصورة التالية:

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

لنشر المشروع، نضغط على زر النشر في الأعلى ثم نختار تطبيق ويب:

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

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

Script function not found: doGet    

توضح هذه الرسالة أن السكربت لا يحوي دالة باسم doGet لتنفيذها وهو طلب HTTP من النوع get لذا نضيف الدالة doGet إلى السكربت:

function doGet(e) {
 return HtmlService.createHtmlOutput("Hello " \+ JSON.stringify(e));   
} 

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

إن حدثنا الصفحة فسنرى ناتج تنفيذ الدالة doGet التالي:

Hello {"queryString":"","contentLength":-1,"contextPath":"","parameters":{},"parameter":{}}    

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

الخطوة الثالثة: ضبط خطاف الويب بين تطبيق الويب وبوت التلغرام

يمكن لتطبيق الويب الذي أنشأناه عبر لغة برمجة تطبيقات جوجل أن يستقبل ويعالج طلبات HTTP، وقد رأينا كيف أنه استقبل طلب GET ويمكنه أيضًا أن يستلم طلب POST أيضًا، فعبر ربط خطاف الويب بين تطبيق الويب وبوت التلغرام، سيرسل البوت طلب POST كلما استلم رسالة جديدة.
ولضبط خطاف الويب في بوت التلغرام، سنستعين بالواجهة البرمجية setWebhook التي تأخذ معاملًا باسم url وهو رابط تطبيق أو خادم الويب الذي ستُرسل إليه التحديثات الواردة من بوت التلغرام.
نُعرِّف في السكربت دالة جديدةًبالاسم setWebhook والتي سترسل طلبية إلى الواجهة البرمجية تلك مع رابط تطبيق الويب، ويمكن أن نحصل على رابط تطبيق الويب بالضغط على زر نشر في الأعلى ثم الضغط على خيار إدارة عمليات النشر ثم ننسخ عنوان URL للتطبيق ونضغه في السكريبت بالشكل التالي:

…    
const webAppUrl = "https://script.google.com/macros/s/AKfycbwkoaVQ6aIWp6R0Pz5Q1EkiIydaKMusCKI7hEUYtPWXau7SLiznaagiAHDqkfiLzhhyXw/exec";

function setWebhook() {   
 const response = UrlFetchApp.fetch(url \+ '/setWebhook?url=' \+ webAppUrl);

 Logger.log(response.getContentText());  
}    

نحصل بعد تنفيذ الدالة setWebhook وحفظ السكربت على الناتج التالي:

{"ok":true,"result":true,"description":"Webhook was set"}    

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

وللقيام بالمعالجة المطلوبة سنعرِّف دالة باسم doPost التي تعالج طلبيات POST المستقبلة، وسنجرب حاليًا إرسال بريد إلكتروني إلى حسابنا كلما استلمنا رسالة جديدة بالشكل التالي:

function doPost(e) {   
 GmailApp.sendEmail(Session.getEffectiveUser().getEmail(), "رسالة جديدة من بوت التلغرام", JSON.stringify(e, null, 4));
}

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

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

الخطوة الرابعة: إرسال رد على كل رسالة يرسلها بوت التلغرام

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

{
    "contextPath": "",
    "queryString": "",
    "contentLength": 295,
    "parameters": {},
    "parameter": {},
    "postData": {
        "contents": "{\"update_id\":412227169,\n\"
message\":{\"message_id\":39,\"from\":{\"id\":957260622,\"is_bot\":false,\"first_name\":\"Jamil\",\"username\":\"jBailony\",\"language_code\":\"en\"},\"chat\":{\"id\":957260622,\"first_name\":\"Jamil\",\"username\":\"jBailony\",\"type\":\"private\"},\"date\":1735667656,\"text\":\"Hi, this is my first message\"}}",
        "length": 295,
        "name": "postData",
        "type": "application/json"
    }
}

ما يهمنا هنا موجود ضمن postData في خاصية اسمها contents ولكنها بصيغة JSON لنفككها إلى كائن بالشكل التالية:

 const contents = JSON.parse(e.postData.contents);   

والناتج هو كالتالي:

{    
  "update_id": 412227169,    
  "message": {    
    "message_id": 39,    
    "from": {    
      "id": 957260622,    
      "is_bot": false,    
      "first_name": "Jamil",    
      "username": "jBailony",    
      "language_code": "en"    
    },    
    "chat": {    
      "id": 957260622,    
      "first_name": "Jamil",    
      "username": "jBailony",    
      "type": "private"    
    },    
    "date": 1735667656,    
    "text": "Hi, this is my first message"    
  }    
}    

يلزمنا مُعرِّف المحادثة id والرسالة نفسها التي وصلتنا:

 const contents = JSON.parse(e.postData.contents);   
 const id = contents.message.from.id;   
 const name = contents.message.from.first_name;  

نحتاج إلى المُعرِّفلأننا سنعتمد على الواجهة البرمجية ‎/sendMessage التي تحتاج إلى المعامل chat_id الذي هو مُعرِّف المحادثة السابق id. لنكتب الدالة sendMessage التي تعتمد على تلك الواجهة البرمجية بالشكل التالي:

function sendMessage(chatId, message) {
 const response = UrlFetchApp.fetch(${url}/sendMessage?chat_id=${chatId}\&text=${message});
 Logger.log(response.getContentText());  
}    

نلاحظ أن الواجهة البرمجية ‎/sendMessage تحتاج أيضًا إلى المعامل text الذي يمثِّل نص الرسالة المراد إرسالها.
لنستعملها الآن ضمن الدالة doPost بإرسال رد على الرسالة:

function doPost(e) {
 GmailApp.sendEmail(Session.getEffectiveUser().getEmail(), "رسالة جديدة من بوت التلغرام", JSON.stringify(e, null, 4));

 const contents = JSON.parse(e.postData.contents);
 const id = contents.message.from.id;
 const name = contents.message.from.first_name;
 const text = contents.message.text;

 sendMessage(id, `وصلتنا رسالتك، شكرًا لك يا ` + name);
}

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

ممتاز، كل شيء يعمل على ما يرام، وخطوتنا التالية هي إدخال المعلومات المستلمة ضمن جدول البيانات.

الخطوة الخامسة: حفظ البيانات المستلمة من بوت التلغرام في جدول البيانات

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

التعامل مع جداول بيانات جوجل عبر لغة Apps Script

سنعتمد على الواجهة SpreadsheetApp في التعامل مع جداول بيانات جوجل، ولنكتب بداية الدالة التالية التي وظيفتها إضافة سطر في جدول البيانات المرتبط بالشكل التالي:

function appendRow() {`    
 SpreadsheetApp.getActiveSheet().appendRow([1, 2, 3, 4]);  
}

إن حفظنا السكريبت ثم نفذنا الدالة appendRow فسنحصل على الناتج التالي:

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

const fileURL = 'https://docs.google.com/spreadsheets/d/1LZlRezLubnD_4mGZulQ7RUZ9-itRefmJNSsSizRh8iY/edit';

function appendRow() {  
 SpreadsheetApp.openByUrl(fileURL).appendRow([1, 2, 3, 4]);  
}    

أو يمكننا الاعتماد على مُعرِّف الملف الذي نستخلصه من رابط ملف جدول البيانات السابق بالشكل التالي فهذه الطريقة أفضل وأقصر:

const fileId = '1LZlRezLubnD_4mGZulQ7RUZ9-itRefmJNSsSizRh8iY';
function appendRow() {
 SpreadsheetApp.openById(fileId).appendRow([1, 2, 3, 4]);
}

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

const fileId = '1LZlRezLubnD_4mGZulQ7RUZ9-itRefmJNSsSizRh8iY';
const sheetName = "Sheet1";


function appendRow() {
 SpreadsheetApp.openById(fileId).getSheetByName("Sheet1").appendRow([1, 2, 3, 4]);
}

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

const fileId = '1LZlRezLubnD_4mGZulQ7RUZ9-itRefmJNSsSizRh8iY';
const sheetName = "Sheet1";

function appendRow() {
 const sheet = SpreadsheetApp.openById(fileId).getSheetByName("incomes");
 sheet.appendRow([5]);
 const lastValue = Number(sheet.getRange(sheet.getLastRow(), 1).getValue());
 sheet.appendRow([lastValue + 1]);
}

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

هذا يكفي لمقالنا الحالي، وسمكن استكشاف بقية الدوال والواجهات من التوثيق الرسمي.

إضافة البيانات المستلمة من بوت التلغرام إلى جدول البيانات

سنختار صيغة البيانات المرسلة من البوت إلينا حتى نعالجها ولتكن بالشكل التالي:

اقتباس

@مصاريف 123 شراء خضار

تمثِّل @ وما بعدها اسم الورقة ثم يليها رقم ثم يليها الوصف مباشرةً، ولنعتمد أنه إذا لم نحدد اسم الورقة فلتكن افتراضيًا ورقة المصاريف، ونأخذ هذه المعلومات ونضيفها في الورقة المحددة، لذا سنُعدِّل الدالة doPost والدالة appendRow بالشكل التالي:

function doPost(e) {
 GmailApp.sendEmail(Session.getEffectiveUser().getEmail(), "رسالة جديدة من بوت التلغرام", JSON.stringify(e, null, 4));


 const contents = JSON.parse(e.postData.contents);
 const id = contents.message.from.id;
 const name = contents.message.from.first_name;
 const text = contents.message.text;
 let sheetName = "مصاريف";
 let itemValue, itemName;


 if (/^@/.test(text)) {
   const textArray = text.slice(1).split(" ");
   sheetName = textArray[0];
   itemValue = textArray[1];
   itemName = textArray.splice(2).join(" ");
 } else {
   const textArray = text.split(" ");
   itemValue = textArray[0];
   itemName = textArray.shift().join(" ");
 }


 appendRow(sheetName, [new Date().toLocaleString(), itemValue, itemName]);
 sendMessage(id, `سجلت المبلغ والقيمة في جدول ${sheetName}، شكرًا لك!`);
}


function appendRow(sheetName, data) {
 const spreadSheet = SpreadsheetApp.openById(fileId);
 const sheet = spreadSheet.insertSheet(sheetName);
 sheet.appendRow(data);
}

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

تعمل عملية الربط بصورة صحيحة إلى الآن ولكن ماذا لو جربنا أن نرسل الرسالة مرة أخرى نفسها؟

الخطوة السادسة: التقاط الأخطاء ومعرفتها وحلها

إن جربنا إرسال نفس الرسالة للبوت @نفقات 10 شراء فواكه، لن يحصل أي شيء ولن يرد علينا البوت بأي رد، وهذا دليل بأنه حصل خطأ ولكن كيف سنعرفه ونحله؟ سنلتقط الخطأ أولًا عبر كتلة try/catch ونرسل داخل catch رسالة إلى البوت بالخطأ الحاصل بالشكل التالي:

const chatId = 957260622;


function doPost(e) {
 try {
   GmailApp.sendEmail(Session.getEffectiveUser().getEmail(), "رسالة جديدة من بوت التلغرام", JSON.stringify(e, null, 4));


   const contents = JSON.parse(e.postData.contents);
   const id = contents.message.from.id;
   const name = contents.message.from.first_name;
   const text = contents.message.text;
   let sheetName = "مصاريف";
   let itemValue, itemName;


   if (/^@/.test(text)) {
     const textArray = text.slice(1).split(" ");
     sheetName = textArray[0];
     itemValue = textArray[1];
     itemName = textArray.splice(2).join(" ");
   } else {
     const textArray = text.split(" ");
     itemValue = textArray[0];
     itemName = textArray.shift().join(" ");
   }


   appendRow(sheetName, [String(new Date().toLocaleString()), itemValue, itemName]);
   sendMessage(id, `سجلت المبلغ والقيمة في جدول ${sheetName}، شكرًا لك!`);
 } catch (e) {
   sendMessage(chatId, `حصل خطأ`);
   sendMessage(chatId, JSON.stringify(e?.message ?? e, null, 4));
 }
}

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

function sendMessage(chatId, message) {
 const response = UrlFetchApp.fetch(`${url}/sendMessage?chat_id=${chatId}&text=${encodeURIComponent(message)}`);
 Logger.log(response.getContentText());
}

نعيد نشر التطبيق ثم إرسال نفس الرسالة وحينها نحصل على الرد التالي من البوت:

تقول رسالة الخطأ بأن هنالك ورقة بنفس الاسم نفقات موجودة سابقًا ولا يمكن إنشاء ورقة جديدة بالاسم نفسه. عرفنا الآن سبب الخطأ ويمكننا حله بتعديل الدالة appendRow بالشكل التالي:

function appendRow(sheetName, data) {
 const spreadSheet = SpreadsheetApp.openById(fileId);
 const sheet = spreadSheet.getSheetByName(sheetName) ?  spreadSheet.getSheetByName(sheetName) : spreadSheet.insertSheet(sheetName);
 sheet.appendRow(data);
}

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

الشيفرة الكاملة للبوت

فيما يلي الشيفرة الكاملة للبوت بعد الانتهاء منه وتنفيذ كافة الخطوات

const token = '7666156735:AAFlJYPgOzT5cTf8CfRx_5vf0GNuVmcvAuk';
const url = 'https://api.telegram.org/bot' + token;
const webAppUrl = "https://script.google.com/macros/s/AKfycbwkoaVQ6aIWp6R0Pz5Q1EkiIydaKMusCKI7hEUYtPWXau7SLiznaagiAHDqkfiLzhhyXw/exec";
const fileId = '1LZlRezLubnD_4mGZulQ7RUZ9-itRefmJNSsSizRh8iY';
const chatId = 957260622;


function getMe() {
 const response = UrlFetchApp.fetch(url + '/getMe');
 Logger.log(response.getContentText());
}


function getUpdates() {
 const response = UrlFetchApp.fetch(url + '/getUpdates');
 Logger.log(response.getContentText());
}


function doGet(e) {
 return HtmlService.createHtmlOutput("Hello " + JSON.stringify(e));
}


function setWebhook() {
 const response = UrlFetchApp.fetch(url + '/setWebhook?url=' + webAppUrl);
 Logger.log(response.getContentText());
}


function appendRow(sheetName, data) {
 const spreadSheet = SpreadsheetApp.openById(fileId);
 const sheet = spreadSheet.getSheetByName(sheetName) ? spreadSheet.getSheetByName(sheetName) : spreadSheet.insertSheet(sheetName);
 sheet.appendRow(data);
}


function sendMessage(chatId, message) {
 const response = UrlFetchApp.fetch(`${url}/sendMessage?chat_id=${chatId}&text=${encodeURIComponent(message)}`);
 Logger.log(response.getContentText());
}


function doPost(e) {
 try {
   GmailApp.sendEmail(Session.getEffectiveUser().getEmail(), "رسالة جديدة من بوت التلغرام", JSON.stringify(e, null, 4));


   const contents = JSON.parse(e.postData.contents);
   const id = contents.message.from.id;
   const name = contents.message.from.first_name;
   const text = contents.message.text;
   let sheetName = "مصاريف";
   let itemValue, itemName;


   if (/^@/.test(text)) {
     const textArray = text.slice(1).split(" ");
     sheetName = textArray[0];
     itemValue = textArray[1];
     itemName = textArray.splice(2).join(" ");
   } else {
     const textArray = text.split(" ");
     itemValue = textArray[0];
     itemName = textArray.shift().join(" ");
   }


   appendRow(sheetName, [String(new Date().toLocaleString()), itemValue, itemName]);
   sendMessage(id, `سجلت المبلغ والقيمة في جدول ${sheetName}، شكرًا لك!`);
 } catch (e) {
   sendMessage(chatId, `حصل خطأ`);
   sendMessage(chatId, JSON.stringify(e?.message ?? e, null, 4));
 }
}

أفكار لتطوير البوت

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

تحليل الرسالة المستقبلة من البوت

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

إضافة قائمة أوامر للبوت

بعد فترة قد ننسى كيفية استعمال البوت ولا نريد أن تفتح الشيفرة البرمجية لذا يمكن أن نضيف قائمة أوامر commands للبوت عبر ‎/setcommands فيها مثلًا كيفية الاستعمال ليرد علينا البوت بكيفية الاستعمال وغيرها من الأوامر السريعة التي توسِّع عمل البوت وتسهِّل استخدامه.

تحسين تنسيق الرسالة المرسلة للبوت

أرسلنا في تطبيقنا رسالة نصية عادية text ولكن يمكننا الاستفادة من المعامل parse_mode في الواجهة البرمجية ‎/sendMessage لإرسال الرسالة بتنسيق مارك داون أو بتنسيق HTML، وللمزيد انظر التنسيقات المدعومة في التوثيق.

تحسين تنسيق جدول البيانات وتطويره

يمكنك إضافة جداول أو أوراق sheets مسبقة وتعديل تنسيقها بصيغة معينة، فنحن لم نركز في هذا المقال على تنسيق الجداول لأنه خارج نطاقنا- كما يمكنك أيضًا إضافة أعمدة أو صفوف جامعة sum أو متوسط حسابي average بحيث نربطها مع أمر في البوت يجلب لنا مجموع المصروف أو النفقات الكلية أو لشهر محدد مثلً،ا وهكذا نطور تطبيق المصاريف والنفقات أو نتوسع وتُطوِّر من التطبيق أكثر ليصبح تطبيق محاسبي يفيد المستخدم. كما يمكننا  إضافة أوامر تجلب لنا صورة عن مخططات شهرية مثلًا ثم إرسال هذه الصورة إلى البوت عبر الواجهة البرمجية ‎/sendPhoto وغيرها من الأفكار العديدة الأخرى.

ربط البوت مع ChatGPT

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

خاتمة

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

اقرأ أيضًا

• التعامل مع جداول البيانات والأوراق والنطاقات من خلال Apps Script
• أساسيات برمجة التطبيقات Apps Script باستخدام جداول بيانات جوجل
• بناء بوت Bot تلغرام باستخدام لارافيل وبوتمان BotMan
• برمجة الروبوت: الدليل الشامل

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

سنشرح في هذا المقال كيفية استخدام أداتي كروماتيك Chromatic وبلاي رايت Playwright في اختبار المواقع المرئي لضمان تناسق واجهات الموقع وخلوها من الأخطاء.

بالطبع لن تفيدنا أدوات الاختبارات الوظيفية مثل الاختبارات الشاملة end-to-end tests أو اختبارات الوحدات unit tests، فهي ممتازة في اختبار منطق صفحات الموقع وسلوكها، لكنه لا تستطيع اكتشاف الأخطاء في مظهر واجهة المستخدم UI، وذلك لأن الاختبارات الوظيفية عاجزة عن رؤية البكسلات pixels التي تخرجها واجهات المستخدم في مواقعنا.

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

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

آلية عمل الاختبار المرئي

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

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

يتمثل سير العمل في أداة كروماتيك Chromatic بأربع خطوات :

1. العرض السحابي Cloud Rendering: أداة كروماتيك واجهة المستخدم لديك في متصفح سحابي
2. أخذ لقطات: تأخذ كروماتيك لقطة عند كل اختبار، وتجري جميع الاختبارات بآن واحد لتوفير الوقت
3. المقارنة المؤتمتة: تولّد كروماتيك لقطات جديدة كلما حدّثنا الشيفرة البرمجية وتقارنها باللقطات المرجعية
4. المراجعة والتحقق: عندما ترصد كروماتيك تغييرات معنية تطلب مراجعتها للتأكد من أنها تغييرات متعمدة، وفي حال وجدت تغييرات غير متوقعة فإنها تفعّل إشعارات تنبهك حتى تسرع في معالجتها

دعنا نقدم مثالًا عمليًا عن هذه التقنية، سنختبر واجهة المستخدم لصفحة الويب التي شُرحت في مقال Dynamic Tooltip Reveal Animations. والتي تتوفر شيفرتها البرمجية على غيت هب. فهي مصمَّمة بتخطيط شبكي وتتضمن عناصر متنوعة، وعندما نمرر المؤشر فوق الروابط في المحتوى الرئيسي تظهر أدوات تلميح tooltips متحركة.

لفهم المشروع أكثر يمكن الحصول على الشيفرة البرمجية لهذه الصفحة وتشغيلها من خلال التعليمات التالية:

$ npx degit winkerVSbecks/PixelGooeyTooltip#starting-point PixelGooeyTooltip
$ cd PixelGooeyTooltip
$ npm install

كيف ندمج أداتي Chromatic و Playwright

يمكننا دمج أداة كروماتيك Chromatic بسلاسة مع أدوات الاختبار الرائجة مثل Storybook وPlaywright وCypress. سنستفيد من الدمج بين أداتي كروماتيك Chromatic وبلاي رايت Playwright لإجراء اختبارات مرئية على الصفحات الثابتة المكتوبة بلغة HTML مما يضمن استقرار التصميم عبر مختلف التغييرات، أما أداة ستوري بوك Storybook فهي الأداة المثلى لاختبار المواقع المبينة بالاعتماد على المكونات component- based حيث توفر بيئة متكاملة لاختبار وتوثيق واجهات المستخدم.

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

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

سير العمل

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

إعداد أداة بلاي رايت

لننفّذ الأمر التالي لإعداد أداة بلاي رايت:

$ npm init playwright@latest

سيضيف هذا الأمر أداة بلاي رايت إلى ملف package.json ويولّد ملف playwright.config.js وهو ملف الإعدادات الذي يتيح لنا تخصيص طريقة تشغيل الاختبارات، مثل المتصفحات المستهدفة، وطرق التعامل مع المهام المتزامنة، وخيارات أخرى. وينشئ مجلد باسم tests متضمنًا مثالًا بسيطًا للاختبار، كما سيضيف مجلد tests-examples لمزيد من الأمثلة.

كتابة اختبار شامل

سنعيد تسمية الملف tests/example.spec.js ليصبح tests/segmented-tooltip.spec.js ونعدّل محتوياته وفق الخطوات التالية كي يختبر عنوان الصفحة:

// tests/segmented-tooltip.spec.js

const { test, expect } = require('@playwright/test');

test('has title', async ({ page }) => {
  await page.goto('http://127.0.0.1:8080');
  await expect(page).toHaveTitle(/Segmented Tooltip Animation/);
});

ننفّذ الأمر . npx http-server لتشغيل الموقع على خادم تطوير محلي، ثم نشغل اختبارات بلاي رايت باستخدام الأمر:

$ npx playwright test

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

اختبار أدوات التلميح التي تنبثق عند تمرير المؤشر

أنجزنا في الفقرة السابقة اختبار للتحقق من عنوان الموقع، وسنضيف الآن اختبار آخر بأداة Playwright آخر كي يتحقق من مكان ظهور أحد أدوات التلميح tooltip التي تنبثق عند تمرير المؤشر فوق عنصر محدد.

// tests/segmented-tooltip.spec.js

const { test, expect } = require('@playwright/test');

test('has title', async ({ page }) => {
  await page.goto('http://127.0.0.1:8080');
  await expect(page).toHaveTitle(/Segmented Tooltip Animation/);
});

test('displays tooltip', async ({ page }) => {
  await page.goto('http://127.0.0.1:8080');
  await page.locator('css=.trigger').first().hover({ force: true });
  await expect(
    page.locator('css=#tooltip-1 .tooltip__content-desc.glitch')
  ).toHaveCSS('opacity', '1');
});

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

$ npx playwright test --ui

أصبحت اختباراتنا الشاملة تعمل، دعنا نرى الآن كيف سنستخدمها للاختبار المرئي.

إنشاء مشروع جديد

نحتاج للاشتراك بحساب كروماتيك مجاني باستخدام حسابنا في GitHub أو GitLab أو Bitbucket أو باستخدام البريد الإلكتروني، يمنحنا هذا الحساب 5000 لقطة مجانية في الشهر. نضغط بعدها على إضافة مشروع أو Add project ثم نتبع التعليمات لإنشاء مشروع جديد، وفي النهاية ننسخ المفتاح token الخاص بمشروعنا، وفق التالي:

إضافة كروماتيك إلى اختبارات بلايرايت

نحتاج بعدها لتثبيت الحزم الخاصة بأداة كروماتيك

$ npm install -D chromatic @chromatic-com/playwright

ثم نبدل أدوات الاختبار الخاصة ببلاي رايت بالأدوات الخاصة بكروماتيك وذلك بإضافة @chromatic-com/playwrightضمن الشيفرة وفق ما يلي:

// tests/segmented-tooltip.spec.js

// ➖ Remove this line
// import { test, expect } from '@playwright/test';
// ➕ Add this line
import { test, expect } from "@chromatic-com/playwright";

test('has title', async ({ page }) => {
  await page.goto('http://127.0.0.1:8080');
  await expect(page).toHaveTitle(/Segmented Tooltip Animation/);
});

test('displays tooltip', async ({ page }) => {
  await page.goto('http://127.0.0.1:8080');
  await page.locator('css=.trigger').first().hover({ force: true });
  await expect(
    page.locator('css=#tooltip-1 .tooltip__content-desc.glitch')
  ).toHaveCSS('opacity', '1');
});

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

إجراء اختبارات مرئية

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

$ npx playwright test

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

$ npx chromatic --playwright -t=<TOKEN>

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

✔ Started build 1
  → Continue setup at https://www.chromatic.com/setup?appId=...
✔ Build 1 auto-accepted
  → Tested 2 stories across 2 components; captured 2 snapshots in 17 seconds

ملاحظة التغيرات المرئية

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

/* css/tooltip.css */

.tooltip {
    --tt-width: 200px;
    --tt-height: 250px;
    --tt-columns: 3;
    --tt-rows: 4;
    --tt-bg-color: #FF6B6C; /* 👈 this one */
    --tt-text-color: #000; /* 👈 and this one */

  /* ... */

الآن لنشغل الاختبار مرة أخرى:

# First Playwright
$ npx playwright test
# Then Chromatic
$ npx chromatic --playwright -t=<TOKEN>

إذا كان هناك تغيير بصري، ستزودنا كروماتيك بموجز للتغيرات التي جرت، نضغط الرابط لمعاينتها.

✖ Found 1 visual change: Review the changes at https://www.chromatic.com/build?appId=...&number=3

يمكننا مراجعة التغيير عبر الرابط المقدم من Chromatic.

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

الاختبار المرئي للتصميم المتجاوب Responsive Design

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

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

// tests/segmented-tooltip.spec.js

// ...

test.use({
  viewport: { width: 800, height: 900 },
});

test('meta is hidden on smaller screens', async ({ page }) => {
  await page.goto('http://127.0.0.1:8080');
  for (const meta of await page.locator('css=.meta').all())
    await await expect(meta).toBeHidden;
});

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

تطوير الاختبارات المرئية

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

ترجمة -وبتصرّف- للمقال How to Visual Test Websites with Chromatic and Playwright.

اقرأ أيضًا

• شرح مفاهيم أساليب يتم إستخدامها للتأكد من سلامة البرامج المكتوبة من الأخطاء
• التصميم المتجاوب Responsive Design
• ما هو تصميم واجهة المستخدم UI
• مدخل إلى التكامل المستمر والنشر المستمر CI/CD

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

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

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

مشكلات استخدام معمارية REST

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

نمذجة نقاط الوصول بالاعتماد على الموارد

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

• getUsers() نقطة وصول تعيد لنا قائمة بكافة المستخدمين
• getCommentsByUserId(userId: string)‎‎‎ نقطة وصول تعيد قائمة بالتعليقات المرتبطة بمعرف مستخدم محدد.

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

const getUserWithComments = async (): Promise<User[]> => {
  // fetch a list of users
  let users = await getUsers();

  // new HTTP request for each user
  for(let i = 0; i < users.length; i++){
    const user = users[i];
    // loading comments from the server
    user.comments = await getCommentsByUserId(user.id);
  }

  return users;
}

نعم كما تتوقع، ستبطئ نقاط الوصول المعتمدة على الموارد من عملية عرض البيانات فتحميل كافة البيانات يستغرق وقتًا طويلًا، ويزيد الحمل على الخادم.

إرجاع الشكل الدقيق للبيانات المطلوبة

يمكن حل مشكلة زيادة حمل الخادم وبطء عرض البيانات بتنظيم نقاط الوصول بحيث تعيد البيانات الدقيقة التي يريد العميل التعامل معها بالضبط، بدل تحميل كافة البيانات. فقد يكون لديك نقطة وصول مثل ()getUsersWithComments تعيد المستخدمين مع تعليقاتهم من خلال استدعاء واحد فقط عبر بروتوكول HTTP.

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

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

هل GraphQL خيار مناسب؟

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

• الحاجة لإرسال بيانات أقل لمستخدمي الهواتف المحمولة
• الحاجة لوجود تواصل في الزمن الحقيقي بين الخادم والعميل لتحديث البيانات بشكل فوري
• نقص وجود وثائق واجهة برمجة التطبيقات API توضح كيفية استخدامها بشكل صحيح وبسبب وجود مثل هذه المشكلات عند التعامل مع معمارية REST ظهرت الحاجة لابتكار حلول أفضل مثل GraphQL

ما هي GraphQL؟

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

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

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

العلاقات في نماذج GraphQL

تُمثل النماذج في models في GraphQL العلاقات بين الكائنات، وتتيح لك الاستعلام عن البيانات المتشابكة بكفاءة عبر استعلام واحد. فعند تمكين العلاقات بين النماذج في GraphQL ستتضمن الاستعلامات معلومات عن العلاقات بين الكيانات وتمكنك من استرجاع كافة البيانات المطلوبة في طلب HTTP واحد ينتقل مرة واحدة ذهابًا وإيابًا.

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

المحللات Resolvers في GraphQL

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

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

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

إذا طورنا نظام GraphQL باستخدام إطار عمل NestJS على سبيل المثال، فيمكن في هذه الحالة تحديد الدوال المسؤولة عن حساب هذه المعلومات أو جلبها باستخدام دوال مسجلة على كمحللات Resolvers وتكمن فائدة المحللات في آلية تنفيذها، إذ لن تنفذ أي دالة مسجلة كمحلل Resolver حتى تستدعى في طلب GraphQL.

يعرض الكود التالي جزء من تطبيق يستخدم GraphQL وإطار عمل NestJS. وهو يعبر عن جزءًا من مخطط قاعدة البيانات UML السابق ويتضمن تعريفًا لصنف باسم Movie ومحلل Resolver لحقل التعليقات MovieComment يحدد أن الحقل الذي سيعاد هو بيانات التعليقات عن الفيلم بالاعتماد على المعرف id الخاص بكل فيلم.

@ObjectType()
export class Movie {
                @Field(() => Int)
                id: number;

                @Field(() => String)
                createdAt: Date;

                @Field(() => String)
                updatedAt: Date;

                @Field(() => String, {
                                nullable: false,
                                description: "User's title to the movie",
                                defaultValue: '',
                })
                title: string;

                @Field(() => String, {
                                nullable: true,
                                description: "User's description to the movie",
                })
                description: string;
}

@Resolver(() => Movie)
export class MovieResolver {
                constructor(private movieCommentService: MovieCommentService) {}

                @ResolveField('movieComment', () => [MovieComment])
                async getMovieComment(@Parent() movie: Movie) {
                                const { id } = movie;
                                return this.movieCommentService.getAllMovieCommetsByMovieId(id);
                }
}

` تكمن فائدة هذا الكود في توفير واجهة GraphQL تتيح للعميل الحصول على بيانات الفيلم وتعليقاته بشكل فعال، وبهذا يمكن للعميل الاستعلام عن الفيلم والتعليقات حوله في نفس الاستعلام دون الحاجة لطلب استعلامات متعددة.

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

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

فوائد استخدام GraphQL

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

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

يقدم استخدام GraphQL لك حلًا أفضل ويوفر تجربة تطوير محسنة والعديد من المميزات وأهمها:

• ميزة GraphQL Playground التي توفر بيئة تفاعلية لتجريب استعلامات GraphQL
• توفير مخطط مسبق التعريف Predefined schema
• إنشاء أنواع TypeScript تلقائيًا استنادًا إلى مخطط بيانات GraphQL
• التواصل في الزمن الحقيقي
• التكيف مع مختلف أنواع الأجهزة
• تنفيذ عدة استعلامات دفعة واحدة Batch query execution

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

ميزة بيئة العمل التفاعلية في GraphQL

توفر GraphQL ميزة البيئة التفاعلية Playground وهي بيئة تطوير متكاملة طورتها شركة Prisma لتوفر بيئة لتنفيذ وتجربة الاستعلامات بشكل فوري، كما توفر وثائق للواجهات البرمجية API لكافة الاستعلامات عن البيانات Queries وتعديلها Mutations واشتراكاتها Subscriptions.

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

المخطط مسبق التعريف Predefined Schema

عند فحص أنواع بيانات GraphQL، قد تلاحظ أن بعض الحقول تتضمن علامة تعجب ! وهي بمثابة ضمان بأن الخادم يجب أن يوفر نوع البيانات الصحيح ولا يمكنه إرجاع قيمة خالية null لهذا الحقل.

بإلقاء نظرة على الصورة المرفقة التي تستعلم عن حقول مثل User.id و User.createdAt، لن يرجع الخادم أبدًا قيمة null لهذه الحقول، وفي حال حدث هذا الأمر فستتلقى الخطأ التالي من عملية الاستعلام.

{
  "errors": [
    {
      "message": "Cannot return null for non-nullable field User.id.",
      "statusCode": 500
    }
  ],
  "data": null
}

وعند استخدام علامة التعجب الخارجية مع المصفوفات ![ ] كما في المثال التالي:

 movieCommentsUserLeft: [MovieComment!]!،

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

توليد أنواع TypeScript

من الفوائد الرئيسية لمخطط GraphQL تمكين المطورين من تحديد استعلامات GraphQL واستخدام المكتبات المفيدة، مثل مكتبة توليد الكود graphql-code-generator، التي تسمح بإنشاء أنواع TypeScript من المخطط من جانب الخادم. ويؤدي استخدام مكتبة توليد الكود إلى منع الكتابة اليدوية لواجهات TypeScript لجميع استجابات واجهة برمجة التطبيقات API، وإذا تغير المخطط من جانب الخادم، فيمكن إعادة إنشاء المخطط بالكامل باستخدام أمر واحد فقط.

في الصورة أدناه، نرى مثالًا على هذه الميزة. فعلى اليسار، يوجد استعلام launchesPast الذي يتوقع إرجاع جزء يسمى LaunchLast. وعلى اليمين، نرى أنواع TypeScript التي أنشأتها المكتبة graphql-code-generator.

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

التواصل في الزمن الحقيقي

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

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

التوافق مع مختلف أنواع الأجهزة

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

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

تنفيذ عدة استعلامات بنفس الوقت

تتيح لك واجهة برمجة التطبيقات GraphQL تنفيذ عدة استعلامات في وقت واحد عن طريق إرسال طلب HTTP واحد. على سبيل المثال في حال واجهة برمجة التطبيقات SpaceX، يمكنك تحديد عدة استعلامات مستقلة واسترجاع البيانات في طلب واحد كما في المثال التالي:

{
  launchesPast(limit: 3) {
    mission_name
    launch_date_local
    launch_site {
                                site_name
                }
  }
  historiesResult(limit: 3) {
    data {
      details
  }
    }
  missions(limit: 3) {
    name
    twitter
  }
}

سلبيات GraphQL

لا تخلو أي تقنية من بعض الجوانب السلبية. دعونا نلقي نظرة على بعض الاعتبارات التي تحتاج للانتباه لها عند استخدام معمارية GraphQL.

مشكلة N+1

عندما تبدأ في تعلم GraphQL، فإن أول مشكلة ستسمع عنها هي مشكلة N+1 ولتفهم كيفية حدوث هذه المشكلة لنأخذ المثال التالي حول واجهة برمجة التطبيقات SpaceX فإذا كنت تريد استرجاع الإصدارات السابقة من جدول واحد، وتريد الحصول على اسم الموقع لكل منها من جدول آخر باستخدام REST، قد تكون لديك نقطة وصول كما يلي:

route: '/launches/past',
method: 'GET',
queryParam: 'limit'

هذا يمكن أن يؤدي إلى الاستعلامات التالية في قاعدة البيانات:

SELECT * FROM launches limit = {limit};

-- pass the fetched launches.ids the the second query
SELECT * FROM launch_sites WHERE launch_id in (1, 2, 3);

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

  type Query {
launchesPast(limit: Int!): [Launch!]!
  }

  # from table launches
  type Launch {
    id: Int!
    mission_name: String
    launch_site: [Launch_sites!]!
  }

  # from table launch_sites
  type Launch_sites {
    id: Int!
    site_name: String
  }
}`

resolvers = {
  Query: {
    launchesPast: async (_: null, args: { limit: number })  => {
      return ORM.getAllLaunches(limit)
    }
  }
  Launch: {
   launch_site:  async (launchObj, args) => {
     return ORM.getLaunchSitesById(launchObj.id)
    }
  },
}

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

بمعنى آخر، تعالج GraphQL كل حقل من البيانات بشكل منفصل بناء على العلاقات بين الحقول، مما يتطلب تنفيذ استعلامات متعددة للحصول على المعلومات المطلوبة بشكل صحيح.

query LaunchesPastQuery($limit: Int!) {
  launchesPast(limit: $limit) {  # fetches Launch entities (1 query)
      id
      mission_name
      launch_site {       # fetches Sites for each Launch (N queries for N Launches)
                                                site_name           
                                }
    }
}                           # Therefore = N + 1 round trips

سيترجم الكود أعلاه إلى كود SQL الزائف التالي:

SELECT * FROM launches limit = {limit};

-- pass the fetched launches.ids the the second query
SELECT * FROM launch_sites WHERE launch_id in (1);
SELECT * FROM launch_sites WHERE launch_id in (2);
SELECT * FROM launch_sites WHERE launch_id in (3);

تتفاقم مشكلة N+1 بشكل أكبر في حال معمارية GraphQL إذ لا يمكن للعملاء أو الخوادم التنبؤ بمدى تكلفة الطلب حتى يتم تنفيذه. أما في معمارية REST، فيمكن التنبؤ بالكلفة نظرًا لوجود رحلة واحدة مطلوبة لكل نقطة وصول. في حين توجد نقطة وصول واحدة في GraphQL لكنها لا تملك دلالة على الحجم المحتمل للطلبات الواردة إليها.

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

تبعية المخطط مسبق التعريف

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

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

schema = `{
  type Query {
    launchesPast: [Launch!]!
  }

  # from table launches
  type Launch {
    id: Int!
    mission_name: String
  }
}`

resolvers = {
  Query: {
    launchesPast: async ()  => {
      const allLaunches = await ORM.getAllLaunches()
      allLaunches[3].id = null; // <-- will cause the query to fail

      return allLaunches;
    }
  }
}

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

Cannot return null for non-nullable field Launch.id

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

التعاودية المتداخلة Nested Recursion

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

authors {
  name
  books {
    title
    authors {
      name
      books {
        title
        authors {
          name
        }
      }
    }
  }
}

لاشك أن المشكلة الناجمة عن هذا المثال واضحة هنا، لذا يجب تصميم واجهة برمجة تطبيقات GraphQL بعناية لمنع تحميل بيانات متداخلة، كما ينصح باستخدام مكتبات مثل graphql-cost-analysis لتعيين حد الكلفة العظمى maximumCost لمخططك بالكامل وتحديد مقدار التعقيد complexity لكل عملية.

رموز حالة HTTP

عندما يواجه الخادم Apollo Server أخطاء معينة أثناء معالجة استعلامات GraphQL، ستتضمن الاستجابة التي يعيدها للعميل مصفوفة أخطاء تحتوي على كل خطأ وقع. وبالرغم من حدوث خطأ، فإن رمز الحالة لكل طلب سيكون دائمًا  200 مما يعني استلام الطلب  بنجاح. ومع ذلك، ستتضمن الحمولة المعادة returned payload قائمة بالأخطاء التي حدثت مع statusCode يساوي 500.

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

توسيع نطاق الخادم من خلال الاشتراكات

كما شرحنا سابقًا، تعتبر الاشتراكات Subscriptions في GraphQL ميزة مهمة للتواصل مع الخادم في الزمن الحقيقي، فهي تسمح لك بتلقي تحديثات فورية من الخادم عندما تحدث تغييرات. وهذه الميزة مفيدة بشكل خاص للتعامل مع الأحداث غير المتزامنة، مثل التحديثات أو التغييرات في البيانات.

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

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

متى أحتاج لخادم GraphQL؟

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

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

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

الخلاصة

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

ترجمة وبيتصرف لمقال  GraphQL: Everything You Need to Know لكاتبه Eduard Krivanek

اقرأ أيضًا

• مقدمة إلى GraphQL
• مدخل إلى المكتبة GraphQL واستعمالاتها في بناء تطبيقات الويب الحديثة
• فهم نظام النوع في GraphQL
• إعداد خادم GraphQL في بيئة Node.js

منذ صياغة مصطلح شبكة الويب العالمية 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 على تعزيز أداء تطبيقك بدرجة كبيرة، ولكي تتمكن من الحصول على هذا التعزيز، ستحتاج إلى إجراء بعض الحيل التي يستخدمها العديد من مطوري الويب الخبراء، ومن الأمثلة على هذه الحيل:

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

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

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

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

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

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

دورة تطوير واجهات المستخدم

ابدأ عملك الحر بتطوير واجهات المواقع والمتاجر الإلكترونية فور انتهائك من الدورة

اشترك الآن

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

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

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

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

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

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

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

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

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

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

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

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

1. استخدام أفعال أو توابع HTTP Verbs خاطئة: كما هو الحال مثلًا عند استخدام طريقة الطلب GET لكتابة البيانات، إذ أن طريقة الطلب GET في بروتوكول HTTP تُستخدم فقط لجلب البيانات وليس للتعديل عليها، وهي مصممة لتكون ثابتة وآمنة، لذا فإنه بغض النظر عن عدد المرات التي تُستخدم فيها طريقة GET لاستدعاء البيانات من نفس المورد، فإن الاستجابة ستكون دائمًا هي نفسها، ويجب ألا يحدث أي تغيير في حالة التطبيق.
2. عدم إرسال رموز حالة 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.

اقرأ أيضًا

• مدخل إلى OAuth 2
• ما أنواع الأخطاء التي تظهر على موقع إلكتروني، وكيف نتعامل معها؟
• الأخطاء الشائعة في تصميم المواقع الإلكترونية والتي تضر بتحسين محركات البحث
• الأخطاء القاتلة الواجب على مصممي مواقع الإنترنت تجنبها
• الاستيثاق عبر token authentication في تطبيق Node.js و React

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

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

ما سنفعله تاليًا هو شرح ما يحدث للبيانات عندما تُرسل بيانات  نموذج من العميل client (وهو عادة متصفح الويب) إلى الخادم server.

معمارية عميل-خادم

يعمل الويب وفق معمارية تسمى عميل-خادم لتبادل البيانات ويمكن تلخيصها على النحو التالي: يُرسل العميل طلبًا إلى الخادم (خادم ويب في أغلب اﻷحيان مثل Apache  أو Nginx أو IIS و Tomcat وغيرها) باستخدام بروتوكول HTTP، ثم يجيب الخادم على الطلب باستخدام نفس البروتوكول كما توضح الصورة التالية"

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

ملاحظة: لتطلع أكثر على آلية عمل معمارية عميل-خادم، اطلع على مقال أساسيات البرمجة في طرف الخادم.

كيفية إرسال البيانات في طرف العميل

يُعرّف العنصر <form> كيفية إرسال البيانات، وقد صممت جميع خاصياته كي تسمح لك بإعداد طلب اﻹرسال عندما ينقر المستخدم على زر اﻹرسال submit. وتُعد action و method أهم خاصيتين لتهيئة عملية إرسال الطلب وإليك شرحًا لكل منهما.

الخاصية action

تُعرِّف هذه الخاصية وجهة البيانات التي نرسلها، وتكون قيمتها عنوان URL مطلق أو نسبي صالح. وإن لم تخصص قيمة لهذه الخاصية ستُرسل الاستمارة إلى عنوان URL لصفحة الويب التي تضمها. تُرسل البيانات في المثال التالي إلى عنوان مطلق Absolute URL وهو  https://example.com:

<form action="https://example.com">…</form>

بينا نستخدم في هذا المثال عنوان نسبي Relative URL ﻹرسال البيانات إلى عنوان URL آخر ضمن نفس النطاق، أي أنه يعتمد على موقع المورد الحالي.

<form action="/somewhere_else">…</form>

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

<form>…</form>

ملاحظة: من الممكن تخصيص عنوان URL يستخدم النسخة اﻵمنة من بروتوكول HTTP (بروتوكول HTTPS). وعندها تُشفَّر البيانات مع بقية أجزاء الطلب حتى لو كانت الاستمارة ضمن صفحة غير آمنة تستخدم بروتوكول HTTP. لكن، ومن ناحية أخرى، إن كانت الاستمارة ضمن صفحة آمنة وكان عنوان URL الذي خصصته للخاصية action غير آمن (يستخدم HTTP) سيعرض المتصفح رسالة تحذير في كل مرة يحول فيها المستخدم إرسال الاستمارة لأن البيانات لن تكون مشفَّرة.

تُرسَل بيانات الاستمارة إن لم تكن ملفًا على شكل أزواج مكونة من اسم و قيمة name=value تربط بينها علامة &، ويجب أن تكون قيمة الخاصية action ملفًا على الخوادم التي تستطيع التعامل مع هذا النوع من الملفات وتتأكد من صلاحيتها. يستجيب الخادم بعد ذلك، وعادة ما يعالج البيانات ويحمّل عنوان URL الذي تحدده الخاصية action مسببًا إعادة تحميل الصفحة (أو تحديث الصفحة إن كانت موجودة، إن أشارت الخاصية action إلى نفس الصفحة). لكن كيف ترسل البيانات؟ يعتمد اﻷمر هنا على قيمة الخاصية method.

الخاصية method

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

ولفهم الاختلاف بين الطلبين السابقين، علينا معرفة آلية عمل بروتوكول HTTP. ففي كل مرة تحاول الحصول فيها على مورد من الويب، يرسل المتصفح طلبًا إلى عنوان URL. ويتكون هذا الطلب من قسمين:

1. ترويسة الطلب header تضم مجموعة من البيانات الوصفية العامة حول إمكانيات المتصفح.
2. جسم الطلب body الذي يضم البيانات الضرورية التي يحتاجها الخادم لمعالجة الطلب.

الطلب GET

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

<form action="http://www.foo.com" method="GET">
  <div>
    <label for="say">What greeting do you want to say?</label>
    <input name="say" id="say" value="Hi" />
  </div>
  <div>
    <label for="to">Who do you want to say it to?</label>
    <input name="to" id="to" value="Mom" />
  </div>
  <div>
    <button>Send my greetings</button>
  </div>
</form>

طالما أننا استخدمنا الطلب GET، سيكون عنوان URL كالتالي:

 www.foo.com/?say=Hi&to=Mom

وسيظهر في شريط عنوان المتصفح بهذا الشكل عند النقر على زر اﻹرسال:

لاحظ كيف ألحقت البيانات بعنوان URL على شكل أزواج اسم=قيمة تأتي بعد إشارة ? ويفصل بين كل زوج المحرف &. وقد مرنا في حالتنا البيانات التالية إلى الخادم:

• الاسم say قيمته Hi.
• الاسم to قيمته Mom.

سيدو عنوان URL عندها بالشكل:

GET /?say=Hi&to=Mom HTTP/2.0
Host: foo.com

ملاحظة: لن تُلحق البيانات إن لم يكن عنوان URL المخصص قادرًا على التعامل مع الاستعلامات (أن يكون ملفًا مثلًا).

الطلب POST

يختلف هذا الطلب قليلًا عن GET، ويستخدمه المتصفح ليطلب من الخادم استجابة تتعلق بالبيانات التي يرسلها ضمن جسم طلب HTTP: " مرحبًا! ألق نظرة على هذه البيانات وأعد نتيجة مناسبة". تلحق الاستمارة البيانات بجسم طلب HTTP عند استخدام POST، ولكي نميز الفرق، ألق نظرة على نفس استمارة المثال السابق لكن باستخدام الطلب POST:

<form action="http://www.foo.com" method="POST">
  <div>
    <label for="say">What greeting do you want to say?</label>
    <input name="say" id="say" value="Hi" />
  </div>
  <div>
    <label for="to">Who do you want to say it to?</label>
    <input name="to" id="to" value="Mom" />
  </div>
  <div>
    <button>Send my greetings</button>
  </div>
</form>

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

POST / HTTP/2.0
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&to=Mom

تشير الترويسة Content-Length إلى حجم جسم الطلب، والترويسة Content-Type إلى نوع المصدر الذي ترسله إلى الخادم، وسنناقش هاتين الترويستين لاحقًا.

ملاحظة:سيُستخدم الطلب GET إن لم يكن عنوان URL المخصص قادرًا على التعامل مع جسم الطلب (كأن يكون على الشكل :data مثلًا).

عرض طلبات HTTP

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

1. افتح نافذة أدوات مطوري ويب developer tools.

2. اختر "شبكة Network".

3. اختر "الكل All".

4. اختر الموقع الذي تريد وليكن "foo.com" في النافذة "اسم Name".

5. اختر "ترويسات Headers".

   يمكنك عندها الحصول على بيانات النموذج Form Data كما في لقطة الشاشة التالية:

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

1. لا تستخدم GET على اﻹطلاق إن أردت إرسال كلمة مرور (أو غيرها من البيانات الحساسة)، لأن هذه البيانات ستُعرض ضمن العنوان وهذا غير آمن.
2. يُفضّل استخدام POST إن احتجت إلى إرسال كمية كبيرة من البيانات. إذ تحدد بعض المتصفحات حجم عناوين URL، كما تحدد الخوادم أيضًا طول عناوين URL التي تقبلها.

كيف تستخلص البيانات في طرف الخادم

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

مثال على إرسال البيانات للخادم باستخدام لغة PHP صرفة

تقدم PHP بعض الكائنات العامة للوصول إلى البيانات في طرف الخادم. فلو افترضنا أنك استخدمت الطلب POST كما في المثال التالي، سيعرض هذا المثال البيانات المرسلة للمستخدم فقط. وبالطبع، يعود اﻷمر إليك فيما تفعله بهذه البيانات، فقد تعرضها أو تخزنها في قاعدة بيانات أو ترسلها ضمن بريد إلكتروني وهكذا..

<?php
  // الوصول إلى البيانات المستلمة باسمها $_POST يتيح لك المتغير العام
  //$_GET نستخدم المتغير GET وللوصول إلى البيانات المرسلة باستخدام الطلب
  $say = htmlspecialchars($_POST['say']);
  $to  = htmlspecialchars($_POST['to']);

  echo  $say, ' ', $to;
?>

يعرض هذا المثال صفحة ويب تضم البيانات التي أرسلناها، يضم ملف المثال نفس استمارة التمرين السابق وتكون قيمة الخاصية method هي POST وقيمة الخاصية action هي php-example.php. عند النقر على زر اﻹرسال، يُرسل المتصفح البيانات إلى الملف php-example.php الذي يضم الشيفرة التي عرضناها سابقًا، وستكون نتيجة تنفيذ هذه الشيفرة كالتالي:

ملاحظة: لن يعمل المثال السابق إن حملته ضمن المتصفح مباشرة، فلا يمكن للمتصفحات تفسير لغة PHP. لهذا عندما ترسل الاستمارة، سيعرض المتصفح تحميل ملف PHP فقط. كي يعمل هذا الملف، لابد من تنفيذه على خادم يدعم PHP. ومن الخيارات المتاحة لاختبار PHP محليًا نقترح MAMP ( على نظام التشغيل ويندوز وماك أو إس) و AMPPS (على نظام ويندوز وماك و لينكس).
وفي حال استخدمت MAMP ولم تكن قد ثبّته مسبقًا (أو كانت نسخة تجريبية انتهت صلاحيتها) فقد تواجهك بعض المشكلات عند تشغيل الملف. ولكي يعمل مجددًا، حمل التطبيق واختر NAMP>Preferences>PHP ثم اضبط قيمة Standard Version على*.7.2 وستختلف قيمة * وفقًا للنسخة التي ثبّتها.

مثال على إرسال البيانات للخادم باستخدام لغة بايثون

سنعرض في هذه الفقرة نفس المثال السابق لكن باستخدام لغة بايثون وإطار العمل فلاسك Flask لتصيير القوالب والتعامل مع بيانات الاستمارة. بإمكانك الاطلاع على ملف المثال على جيت-هاب:

from flask import Flask, render_template, request

app = Flask(__name__)

@app.route('/', methods=['GET', 'POST'])
def form():
    return render_template('form.html')

@app.route('/hello', methods=['GET', 'POST'])
def hello():
    return render_template('greeting.html', say=request.form['say'], to=request.form['to'])

if __name__ == "__main__":
    app.run()

يتعامل المثال السابق مع قالبين ينبغي أن يكونا ضمن مجلد فرعي باسمtemplates في نفس المجلد الذي يضم الملف python-example.py إن أردت تشغيل المثال بنفسك:

• القالب form.html: وهو ملف يضم نفس الاستمارة التي تعاملنا معها في المثال السابق، لكن ضبطت قيمة الخاصية action لتكون {{('helo')url_for}}. يُدعى هذا القالب قالب Jinja وهو أساسًا ملف HTML لكن يمكن أن يضم استدعاءات لشيفرة بايثون التي تعمل على الخادم بوضعها ضمن أقواس معقوصة. وتعني الشيفرة url_for('hello') : انتقل إلى الوجهة hello/ عند إرسال الاستمارة.
• القالب greeting.html: ويضم فقط شيفرة لتصيير البيانات التي نمررها إليه عندما تكون جاهزة. وينفذ اﻷمر باستخدام الدالة ()hello التي تُنفذ عند الانتقال إلى الوجهة hello/.

ملاحظة: لن يعمل المثال السابق إن حملته ضمن المتصفح مباشرة، إذ تعمل لغة بايثون بشكل مختلف قليلًا عن PHP. لتنفيذ هذا المثال على متصفحك عليك تثبيت وإعداد Python ، ثم تثبيت Flask باستخدام اﻷمر pip3 install flask. وبعد الانتهاء من المفترض أن تتمكن من تشغيل المثال باستخدام python3 python-example.py. بعد ذلك اكتب العنوان التالي في متصفحك localhost:5042.

لغات وإطارات عمل أخرى

ستجد العديد من التقنيات المتوفرة للتعامل مع الاستمارات في طرف الخادم بما في ذلك بيرل Perl وجافا Java وروبي Ruby ودوت نت Net وغيرها. ومن الجدير بالذكر أن استخدام هذه التقنيات مباشرة ليس شائعًا لأن التعامل معها قد يكون مربكًا. لهذا من اﻷفضل العمل مع إطارات عمل عالية الجودة تُسهّل التعامل مع الاستمارات مثل:

• إطارات عمل بايثون:

  • جانغو Django

  • فلاسك Flask

  • web2py (سهلة للمبتدئين).

  • py4web (طوّرت من قبل نفس مطوري wep2py لكنها تشبه دجانغو قليلًا من ناحية اﻹعداد).

• إطارت عمل Node.js

  • EXpress

  • Next.js (لتطبيقات رياكت).

  • Nuxt (لتطبيقات Vue).

  • Remix

• إطارات PHP

  • لارافيل Laravel

  • سمفوني Symfony

• إطارات Ruby

  • Ruby On Rails

• إطارات جافا

  • Spring Boot

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

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

حالة خاصة: إرسال ملف

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

الخاصية enctype

تسمح لك هذه الخاصية بتحدبد قيمة الترويسة Content_Type في طلب HTTP الذي ينتج عن تسليم الاستمارة. وهذه الترويسة مهمة جدًا لأنها تخبر الخادم عن نوع البيانات التي أرسلت. تأخذ الخاصية افتراضيًا القيمة التالية application/x-www-form-urlencoded والتي
تعني: "هذه بيانات استمارة شُفرت ضمن عنوان URL". لكن إن أردت إرسال ملف، عليك تنفيذ الخطوات اﻹضافية التالية:

• اضبط قيمة الخاصية method على POST لأن محتوى الملف لا يمكن وضعه ضمن عنوان URL.
• اضبط قيمة الخاصية enctype على multipart/form-data لأن البيانات ستُجزّأ إلى أقسام متعددة : قسم لكل ملف وقسم للبيانات النصية التي يضمها جسم الطلب (في حال وجدت بيانات نصية أخرى في الاستمارة).
• استخدام عنصر <'input type='file> أو أكثر لتسمح للمستخدم باختيار الملف أو الملفات التي يريد رفعها.

إليك مثالًا:

<form method="post" action="https://www.foo.com" enctype="multipart/form-data">
  <div>
    <label for="file">Choose a file</label>
    <input type="file" id="file" name="myFile" />
  </div>
  <div>
    <button>Send the file</button>
  </div>
</form>

ملاحظة: قد تُهيّأ الخوادم لتقبل حجمًا محدودًا للملفات أو طلبات HTTP لمنع الاستخدام غير الصحيح لمواردها.

اعتبارات أمنية

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

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

كن مرتابًا ولا تثق أبدًا بالمستخدم

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

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

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

الخلاصة

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

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

ترجمة -وبتصرف- للمقال: Sending form data

اقرأ أيضًا

• المقال السابق: التحقق من صحة بيانات استمارة ويب في طرف العميل
• أمثلة على التعامل مع خادم عميل (Client server) باستعمال لغة Cpp
• إرسال الاستمارات (form submit) ومعالجتها في جافاسكربت
• نظرة على تفاعلات الخادم مع العميل في موقع ويب ديناميكي
• إنشاء تطبيق ويب باستخدام إطار عمل فلاسك Flask من لغة بايثون

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

ولكن من الملاحظ أن الأدوات المستخدمة لاختبار البرمجيات لم تتطور بنفس الوتيرة التي تطورت بها البرمجيات نفسها، وتدل هذه الفجوة على مقدار الحاجة لتطوير وتحديث طرق أتمتة الاختبارات (test automation methods) لتواكب سرعة تطور البرمجيات نفسها.

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

استخدام الطرق التقليدية لأتمتة الاختبارات

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

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

في الفقرات القادمة سنلقي نظرة على طريقتين معتمدتين بشكل واسع في أتمتة عملية الاختبار باستخدام إطار عمل أتمتة الاختبارات سيلينيوم Selenium وإطار أبيوم Appium.

استخدام الأداة سيلينيوم Selenium لأتمتة اختبار تطبيقات الويب

تعتبر أداة سيلينيوم Selenium الأداة الأكثر شيوعًا لأتمتة عمليات الاختبار التي يستخدمها المطورون والمبرمجون لكتابة اختبارات واجهة المستخدم المؤتمتة لتطبيقات الويب.

يمكن تنفيذ هذه الاختبارات في جميع متصفحات الويب ويمكن كتابة هذه الاختبارات بإحدى لغات البرمجة الكثيرة التي تدعمها الأداة سيلينيوم Selenium.

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

1. تشغيل متصفح الويب (أي متصفح من اختيارك).
2. الانتقال إلى صفحة تسجيل الدخول للموقع المراد اختباره.
3. إدخال اسم المستخدم وكلمة السر.
4. الضغط على زر تسجيل الدخول Login.
5. التأكد من تسجيل دخول المستخدم عن طريق ظهور اسم المستخدم على الشاشة.

ملاحظة1: سنستخدم الموقع demoqa.com وهو موقع تجريبي مفيد جداً للمطورين والمهتمين بتعلم أتمتة الاختبارات ويوفر مجموعة متنوعة من الأدوات والصفحات الوهمية التي يمكن استخدامها لأتمتة الاختبارات باستخدام أدوات مثل Selenium و Appium ويمكن للمستخدمين اختبار سيناريوهات مختلفة مثل تسجيل الدخول وتعبئة النماذج والتفاعل مع عناصر الواجهة وغيرها من العمليات الشائعة في مواقع الويب.

ملاحظة2: يمكنك إنشاء مستخدم جديد بالضغط على زر مستخدم جديد New User بحيث يكون لدينا بيانات اعتماد صحيحة لسيناريو أتمتة عملية الاختبار.

سنستخدم كود Selenium التالي لتنفيذ خطوات أتمتة اختبار تسجيل الدخول إلى موقع ويب:

public class Login {
  @Test
  public void loginTest() throws InterruptedException {

    WebDriver driver = new ChromeDriver(); // Instantiating the webdriver instance
    driver.get("https://demoqa.com/login"); // Launching the website
    driver.manage().window().maximize(); // Maximizing browser window

    String user = "your user name";
    String pass = "your password";

    // Locating web elements for username, password, and the Login button
    driver.findElement(By.id("userName")).sendKeys(user);
    driver.findElement(By.id("password")).sendKeys(pass);
    driver.findElement(By.id("login")).click();

    // Using sleep to load web elements on page
    Thread.sleep(5000);

    // Capturing the displayed username after login
    String uName = driver.findElement(By.id("userName-value")).getText();

    // Asserting that the logged-in username matches the expected username
    Assert.assertEquals(uName, user);

    // Locating the web element for the Logout button and closing the webdriver instance
    driver.findElement(By.id("submit")).click();
    driver.quit();
  }
}

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

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

استخدام الأداة Selenium مع الأداة TestGrid لأتمتة اختبار تطبيقات الويب

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

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

بعد تسجيل الدخول إلى الموقع TestGrid وتنفيذ الخطوات الموجودة على الرابط التالي الذي يشرح كيفية تشغيل اختبارات Selenium المكتوبة محليًا على بيئة متصفح موجهة عبر TestGrid ستحصل على الكود التالي:

public class TestGridDemoQaLogin {

  @Test
  public void loginTest() throws InterruptedException, MalformedURLException {

    // Setting the desired capabilities to use the TestGrid platform
    DesiredCapabilities dc = new DesiredCapabilities();
    dc.setCapability("browserName", "firefox");
    dc.setCapability("platformName", "linux");
    dc.setCapability("tg:userToken", "Your Token");
    dc.setCapability("tg:udid", "201");

    // Instantiating the remote webdriver instance and passing desired capabilities to it
    WebDriver driver = new RemoteWebDriver(new URL("Your Browser Run URL(Public)"),dc);

    // Remaining steps are the same as in the previous Selenium code
    driver.get("https://demoqa.com/login");
    driver.manage().window().maximize();

    String user = "your user name";
    String pass = "your password";

    driver.findElement(By.id("userName")).sendKeys(user);
    driver.findElement(By.id("password")).sendKeys(pass);
    driver.findElement(By.id("login")).click();

    Thread.sleep(5000);

    String uName = driver.findElement(By.id("userName-value")).getText();

    Assert.assertEquals(uName, user);

    driver.findElement(By.id("submit")).click();
    driver.quit();
  }
}

عندما تنفذ هذا الكود على جهازك المحلي، ستلاحظ أن نفس الكود سيُنفَّذ على الجهاز الافتراضي للأداة TestGrid عبر الإنترنت لرؤية كيفية تنفيذ الاختبارات على السحابة.

وبهذه الطريقة يمكنك مراقبة عملية تنفيذ الكود عن بعد من خلال البوابة الإلكترونية للأداة وتشخيص أي مشكلات تتعلق بتنفيذه، كما يمكنك أيضًا مشاهدة حالة التنفيذ (Execution Status) والتسجيلات (Recording) وتشغيل الملخص (Run Summary) الموجود في التبويب Automation Sessions ببساطة عن طريق اختيار الجهاز الذي ستنفذ عليه عملية الاختبار مما يوفر لك إمكانية تتبع الأداء والتحقق من صحة نتائج الاختبارات عن بُعد.

استخدام الأداة أبيوم Appium لاختبار تطبيقات الهاتف المحمولة بشكل مؤتمت

تعرف الأداة أبيوم Appium على أنها إطار عمل مفتوح المصدر وشائع الاستخدام يصلح لأتمتة اختبار تطبيقات الجوال الأصيلة (Native Apps) والتطبيقات الهجينة (Hybrid Apps) وتطبيقات الويب على الجوال (Mobile Web Apps).

وتتطلب كتابة السكريبتات الخاصة بالأداة Appium معرفة جيدة بأنظمة تشغيل الهواتف المحمولة وفهم عميق للغات البرمجة مثل لغة جافا ولغة ++C ولغة بايثون.

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

على سبيل المثال سنستخدم تطبيق الآلة الحاسبة الأساسي، ونقوم بأتمتة عملية الاختبار للحالة التالية باستخدام أبيوم Appium.

1. نشغل تطبيق الآلة الحاسبة.
2. ننفذ عملية الضرب بين عددين.
3. نسجل نتيجة العملية الحسابية.
4. التأكد من النتيجة.

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

package appium;

import java.net.MalformedURLException;
import java.net.URL;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.testng.Assert;
import org.testng.annotations.Test;
import io.appium.java_client.AppiumBy;
import io.appium.java_client.android.AndroidDriver;

public class Calculator {

  @Test
  public void calculator() throws MalformedURLException {

    DesiredCapabilities dc = new DesiredCapabilities();

    // Setting the desired capabilities for the android device
    dc.setCapability("platformName", "android");
    dc.setCapability("platformVersion","14");
    dc.setCapability("deviceName", "Pixel6_TestGrid");
    dc.setCapability("automationName", "UiAutomator2");

    // Setting capability for the application we want to test
    dc.setCapability("app", "/Users/macair/Downloads/calculator.apk");

    // Instantiating Android Driver and using Appium server host and port
    AndroidDriver driver = new AndroidDriver(new URL("http://127.0.0.1:4723/wd/hub"), dc);

    // Locating numbers, mathematical operators, and the equals button in the Calculator app
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/digit_4")).click();
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/op_mul")).click();
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/digit_9")).click();
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/eq")).click();

    // Storing the result in a string variable
    String result = driver.findElement(
      AppiumBy.id("com.google.android.calculator:id/result_final")
    ).getText();
    System.out.println("The result is - "+result);

    Assert.assertEquals(result, "36");
    driver.quit();
  }
}

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

استخدام Appium مع TestGrid لأتمتة اختبار تطبيقات الهواتف المحمولة

سنرى في هذه الفقرة طريقة تنفيذ سكريبت اختبار الأداة Appium على السحابة الحقيقية للأجهزة

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

سنلقي نظرة على الكود بعد تحديثه بحيث يتضمن الصنف DesiredCapabilities وهو صنف برمجي يُستخدم لتحديد معاملات معينة عند إعداد بيئة الاختبار، وتستخدم هذه المعاملات لضبط خصائص جهاز TestGrid الذي سيجري عليه الاختبار، على سبيل المثال حددنا هنا المعاملات udid وsmartPort وuserToken لتحديد الجهاز الذي نريد التواصل معه:

package appium;

import java.net.MalformedURLException;
import java.net.URL;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.testng.Assert;
import org.testng.annotations.Test;
import io.appium.java_client.AppiumBy;
import io.appium.java_client.android.AndroidDriver;

public class CalculatorTestGrid {

  @Test
  public void calculator() throws MalformedURLException {

    DesiredCapabilities dc = new DesiredCapabilities();

    // Setting the desired capabilities for the android device
    dc.setCapability("platformName", "android");
    dc.setCapability("platformVersion","12");
    dc.setCapability("deviceName", "Samsung Galaxy S21");
    dc.setCapability("automationName", "UiAutomator2");
    dc.setCapability("udid", "R5CRC28KGKB");
    dc.setCapability("tg:systemPort", "4005");
    dc.setCapability("tg:userToken", "Your user token");

    // Since the application is installed on the device, we directly use
    // the package name and main activity
    dc.setCapability("appPackage", "com.google.android.calculator");
    dc.setCapability("appActivity", "com.android.calculator2.Calculator");

    AndroidDriver driver = new AndroidDriver(new URL("Your TestGrid Appium URL"), dc);

    // Remaining steps are the same as in the previous Appium code
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/digit_4")).click();
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/op_mul")).click();
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/digit_9")).click();
    driver.findElement(AppiumBy.id("com.google.android.calculator:id/eq")).click();

    String result = driver.findElement(
      AppiumBy.id("com.google.android.calculator:id/result_final")
    ).getText();
    System.out.println("The result is - "+result);

    Assert.assertEquals(result, "36");
    driver.quit();
  }
}

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

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

الاستفادة من حلول اختبار الأتمتة الحديثة للأداة TestGrid

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

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

استخدام مولد سكريبت الاختبار للأداة TestGrid لاختبار تطبيقات الويب

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

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

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

يمكنك مع تقدم التنفيذ البدء بمراقبة السجلات وحالة الاختبار التي تم توليدها.

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

يمكنك بعد انتهاء عملية التنفيذ الوصول تقارير التحليل المختلفة والموجودة على التبويب Transaction Analysis في لوحة التحكم اليسرى.

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

يمكنك بعد إنشاء المشروع والوحدة النقر على الأمر Add Test Case with Scriptless لاستخدام هذه الميزة، ستلاحظ وجود الزر Start Recording في لوحة التحكم اليمنى الذي يقوم بعد النقر عليه بتسجيل الإجراءات كما يمكن الضغط على الزر Stop عند الانتهاء.

نلاحظ قفل الأمرين Live View وElement Picker خلال عملية التنفيذ

يمكننا بعد إيقاف التسجيل تعديل المعاملات في العمود Action أو على الأمر Element Picker لإجراء المزيد من التعديلات على الخطوات المضافة باستخدام التسجيل.

يمكننا بعد ذلك الانتقال مرة أخرى إلى الأمر Test Cases وتنفيذ الاختبار كما نفذناه المرة السابقة تمامًا، سنكون قادرين على مشاهدة التنفيذ والنتائج في تقارير التحليل المختلفة، نستطيع باستخدام الأمر Network Log عرض الطلبات requests المرسلة إلى النطاق domain والوقت الذي يستغرقه كل منها

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

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

استخدام مولد سكريبت الاختبار في الأداة TestGrid لاختبار تطبيقات الهاتف المحمول

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

سنشاهد عند الضغط على الزر Add Test Function with TestCase Generator نافذة منبثقة تطلب منك إدخال معرف APK/IPA/BUNDLE ID التطبيق الذي تريد اختباره، حمل التطبيق ثم اختر الجهاز الذي سينفذ عليه الاختبار ثم اضغط على الزر Run لتشغيله.

الخطوات التالية مشابهة تمامًا للخطوات التي طبقناها في حالة تطبيقات الويب

بعد حفظ خطوات تطبيق عملية الضرب على رقمين والتحقق من النتيجة تضاف دالة الاختبار.

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

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

نستطيع من خلال الأمر Build Summary معرفة كافة تفاصيل عملية التنفيذ.

يمكننا استخدام ميزة التسجيل والتشغيل في تطبيقات الهاتف المحمول بطريقة مشابهة تمامًا لتطبيقات الويب.

كما يمكننا الاستفادة بقوة من السجلات والتقارير المتعددة التي توفرها لنا الأداة TestGrid، والتي تجعل تحليل أداء عمليات التنفيذ عملية سهلة وبسيطة للغاية.

تُظهر الميزة Insights رسوم بيانية لمعاملات الأداء المختلفة المتوافقة مع عملية التنفيذ مثل التحميل على وحدة المعالجة المركزية (CPU) خلال الاختبارات. ومقدار استخدام الذاكرة خلال تشغيل التطبيق وحجم بيانات الاستجابة والطلب وغيرها الكثير.

بالإضافة إلى ذلك يوفر الأمر Transaction Analysis العديد من التقارير القابلة للتحميل، والتي تتعلق بمعايير الأداء بما في ذلك معلومات الجهاز.

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

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

استخدام ميزة الاختبار المرئي للأداة TestGrid

يتحقق الاختبار المرئي Visual testing من كون واجهات المستخدم في التطبيقات تظهر كما هو متوقع حيث يتجاوز هذا النوع من الاختبارات التحقق الوظيفي (أي التحقق من أن العناصر تعمل بشكل صحيح) ويركز على التأكد من أن التصميم المرئي والمظهر العام للتطبيق يتطابق مع التصميم المتوقع والمخطط له ويسمح لنا باكتشاف التغييرات غير المرغوب فيها في التصميم أو المشكلات البصرية التي قد تحدث أثناء عملية تطوير التطبيق بمنهجية التطوير السريعة أجايل agile.

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

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

يمكننا بعد اتباع خطوات إعداد الاختبار المرئي في كود الأداة Selenium أو الأداة Appium مشاهدة نتائج الاختبار المرئي عن طريق الانتقال إلى التبويب Visual Testing الموجود ضمن النافذة Automation Sessions للجهاز المختار.

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

الخلاصة

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

تعد كتابة سكريبتات الاختبار في الأداتين Selenium و Appium أمرًا معقدًا ومكلفًا ويستغرق الكثير من الوقت مما يجعل التعديلات المتكررة لهذه السكريبتات أمرًا في غاية الصعوبة وغير موثوق دومًا.

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

وبهذه الطريقة يستطيع المطورون ومهندسو ضمان الجودة (QA Engineers) تحقيق اختبارات نموذجية عن طريق الأجهزة والمتصفحات وأطر العمل وتصور مشكلات واجهة المستخدم UI قبل حدوثها.

ترجمة وبتصرف للمقال Modernizing conventional test automation with TestGrid لكاتبه TestGrid.

اقرأ أيضًا

• مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات
• أتمتة إعداد خادم باستخدام أداة Ansible
• إعداد البيئة للاختبارات الآلية في مشاريع الويب للتوافق مع المتصفحات
• عالم الويب ومعاييره

بعد أن تعلمنا كيفية قياس سرعة البرامج في المقال السابق قياس أداء وسرعة تنفيذ شيفرة بايثون، سنتعلم كيفية قياس الزيادات النظرية theoretical increases في وقت التنفيذ runtime مع نمو حجم البيانات الخاصة بالبرنامج، ويُطلق على ذلك في علوم الحاسوب ترميز O الكبير big O notation.

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

تُعدّ Big O نوعًا من خوارزميات التحليل التي تصف تعقيد الشيفرة مع زيادة عدد العناصر التي تعمل عليها. تصنف الشيفرة في مرتبة تصف عمومًا الوقت الذي تستغرقه الشيفرة لتُنفّذ، وكلما زادت تزيد كمية العمل الواجب إنجازه. يصف مطور لغة بايثون Python نيد باتشلدر Ned Batchelder خوارزمية big O بكونها تحليلًا لكيفية "تباطؤ الشيفرة كلما زادت البيانات" وهو عنوان حديثه في معرض PyCon 2018.

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

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

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

مراتب Big O

يُعرّف ترميز Big O عادةً المراتب التالية، التي تتراوح من المنخفضة -التي تصف الشيفرة التي لا تتباطأ كثيرًا كلما زادت البيانات- إلى المراتب العليا -التي تصف الشيفرة الأكثر تباطؤًا:

1. O(1)‎ وقت ثابت (أدنى مرتبة)
2. O(log n)‎ وقت لوغاريتمي
3. O(n)‎ وقت خطي
4. O(n log n)‎ وقت N-Log-N
5. O(n²)‎ وقت متعدد الحدود
6. O(2ⁿ)‎ وقت أسي
7. O(n!)‎ وقت عاملي (أعلى مرتبة)

لاحظ أن big O تستخدم حرف O كبير متبوعًا بقوسين يحتويان وصف المرتبة، إذ يمثّل حرف O الكبير المرتبة وتمثل n حجم دخل البيانات التي تعمل عليها الشيفرة. نلفظها "big oh of n" أو "big oh n".

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

• خوارزميات O(1)‎ و O(log n)‎ سريعة
• خوارزميات O(n)‎ و O(n log n)‎ ليست سيئة
• خوارزميات O(n²)‎ و O(2ⁿ)‎ بطيئة يمكن طبعًا مناقشة العكس في بعض الحالات ولكن هذه التوصيفات هي قواعد جيدة عمومًا، فهناك مراتب أكثر من big O المذكورة هنا ولكن هذه هي الأعم. دعنا نتحدث عن أنواع المهام التي يصفها كل نوع من هذه المهام.

اصطلاح رف الكتب Bookshelf لمراتب Big O

سنستمر في المثال التالي لمراتب big O باستخدام مصطلح رف الكتب، إذ تمثّل n عدد الكتب في الرف ويصف ترميز Big O كيف أن المهام المختلفة تستغرق وقتًا أطول كلما زاد عدد الكتب.

تعقيد O(1)‎: وقت ثابت

معرفة "هل رف الكتب فارغ؟" هي عملية ذات وقت ثابت، إذ لا يهم عدد الكتب في الرف، فنظرةٌ واحدةٌ ستخبرنا ما إذا كان رف الكتب فارغ أم لا. يمكن أن يختلف عدد الكتب ولكن وقت التنفيذ يبقى ثابتًا، لأنه طالما رأينا كتابًا واحدًا على الرف يمكننا إيقاف البحث. القيمة n غير مهمة لسرعة تنفيذ المهمة لذا لا يوجد n في O(1)‎. يمكنك أيضًا رؤية الوقت الثابت مكتوبًا (O(c أحيانًا ‎.

تعقيد O(log n)‎: لوغاريتمي

اللوغاريتم هو عكس الأس، الأس 2⁴ أو 2×2×2×2 يساوي 16 ولكن اللوغاريتم log₂(16)‎ (تلفظ لوغاريتم أساس 2 للعدد 16) يساوي 4. نفترض في البرمجة قيمة الأساس 2 ولذلك نكتب O(log n)‎ بدلًا من O(log₂ n)‎.

البحث عن كتاب في رف كتب مرتب أبجديًا هي عملية لوغاريتمية الوقت؛ فمن أجل إيجاد كتاب واحد، يمكن التحقق من الكتاب في منتصف الرف، وإذا كان هو الكتاب المطلوب تكون قد انتهيت، وإذا لم يكن كذلك، يمكن تحديد إذا كان الكتاب قبل أو بعد الكتاب الذي في المنتصف. يقلل ذلك مجال البحث إلى النصف، ويمكنك تكرار هذه العملية مجددًا من خلال فحص الكتاب الذي في منتصف النصف الذي تتوقع فيه إيجاد الكتاب. نسمي ذلك خوارزمية بحث ثنائية binary search وهناك مثال على ذلك في "أمثلة عن ترميز Big O" لاحقًا.

عدد المرات التي تستطيع قسم مجموعة n كتاب للنصف هي log₂ n، في رف فيه 16 كتاب ستحتاج إلى 4 خطوات على الأكثر لإيجاد الكتاب الصحيح، لأن كل خطوة تقلل عدد الكتب التي يجب البحث فيها إلى النصف. يحتاج رف الكتب الذي فيه ضعف عدد الكتب فقط إلى خطوة إضافية واحدة للبحث عنه. إذا كان هناك 4.2 مليار كتاب في رف كتب مرتبة أبجديًا ستحتاج فقط إلى 32 خطوة لإيجاد كتاب معين.

تتضمن خوارزميات Log n عادةً خطوة فرّق تسد divide and conquer وتنطوي على اختيار نصف دخل n للعمل عليه وبعدها نصف آخر من ذلك النصف وهكذا دواليك. تتدرج عمليات log n جيدًا، إذ يمكن أن يزداد العمل n إلى الضعف ولكن سيزداد وقت التنفيذ خطوةً واحدةً فقط.

تعقيد O(n)‎: وقت خطي

تستغرق عملية قراءة كل الكتب على الرف وقتًا خطيًا؛ فإذا كانت الكتب بنفس الطول تقريبًا وضاعفت عدد الكتب على الرف، فسيستغرق ضعف الوقت تقريبًا لقراءة كل الكتب، ويزداد وقت التنفيذ بالتناسب مع عدد الكتب n.

تعقيد O(n log n)‎: وقت N-Log-N

ترتيب الكتب أبجديًا هي عملية تستغرق وقت n-log-n. هذه المرتبة هي ناتج ضرب وقتي التنفيذ O(n)‎ و O(log n)‎ ببعضهما. يمكن القول أن مهمة O(n log n)‎ هي مهمة O(log n)‎ مع تنفيذها n مرة. فيما يلي تفسير بسيط حول ذلك.

ابدأ بمجموعة كتب يجب ترتيبها أبجديًا ورف كتب فارغ، واتبع الخطوات في خوارزمية البحث الثنائي كما موضح في الفقرة السابقة "تعقيد O(log n)‎: زمن لوغاريتمي" لمعرفة مكان كل كتاب على الرف. هذه عملية O(log n)‎، ومن أجل ترتيب n كتاب أبجديًا وكان كل كتاب بحاجة إلى log n خطوة لترتيبه أبجديًا، ستحتاج n×log n أو n log n خطوة لترتيب كل مجموعة الكتب أبجديًا. إذا تضاعف عدد الكتب سيستغرق أكثر من ضعف الوقت لترتيبهم أبجديًا، لذا تتدرج خوارزميات n log n جيدًا.

خوارزميات الترتيب ذات الكفاءة، هي: O(n log n)‎، مثل ترتيب الدمج merge sort والترتيب السريع quicksort وترتيب الكومة heapsort وترتيب تيم Timsort (من اختراع تيم بيترز Tim Peters وهي الخوارزمية التي يستخدمها تابع sort()‎ الخاص ببايثون).

تعقيد O(n²)‎: وقت متعدد الحدود

التحقق من الكتب المكررة في رف كتب غير مرتب هي عملية تستغرق وقت حدودي polynomial time operation؛ فإذا كان هناك 100 كتاب يمكنك أن تبدأ بالكتاب الأول وتقارنه مع التسعة وتسعون الكتاب الباقين لمعرفة التشابه، ثم نأخذ ثاني كتاب ونتحقق بنفس الطريقة مثل باقي بقية الكتب التسعة وتسعون. خطوات التحقق من التكرار لكتاب واحد هي 99 (سنقرّب هذا الرقم إلى 100 الذي هو n في هذا المثال). يجب علينا فعل ذلك 100 مرة، مرةً لكل كتاب، لذا عدد خطوات التحقق لكل كتاب على الرف هو تقريبًا n×n أو n². (يبقى هذا التقريب n² صالحًا حتى لو كنا أذكياء ولم نكرر المقارنات).

يزداد وقت التنفيذ بازدياد عدد الكتب تربيعيًا. سيأخذ التحقق من التكرار لمئة كتاب 100×100 أو 10,000 خطوة، ولكن التحقق من ضعف هذه القيمة أي 200 كتاب سيكون 200×200 أو 40,000 خطوة، أي أربع مرات عمل أكثر.

وجد بعض الخبراء في كتابة الشيفرات الواقعية للعالم الحقيقي أن معظم استخدامات تحليل big O هي لتفادي كتابة خوارزمية O(n²)‎ عن طريق الخطأ، عند وجود خوارزمية O(n log n)‎ أو O(n)‎.

مرتبة O(n²)‎ هي عندما تبدأ الخوارزميات بالتباطؤ كثيرًا، لذا معرفة أن الشيفرة الخاصة بك في مرتبة O(n²)‎ أو أعلى يجب أن يجعلك تتوقف. ربما توجد خوارزمية مختلفة يمكنها حل المشكلة بصورةٍ أسرع، ويمكن في هذه الحالة أن يكون الإطلاع على قسم هيكلة البيانات والخوارزميات Data Structure and Algorithms -أو اختصارًا DSA- إما على أكاديمية حسوب مفيدًا.

نسمي أيضًا O(n²)‎ وقتًا تربيعيًا، ويمكن أن يكون لخوارزميات O(n³) وقتًا تكعيبيًا وهو أبطأ من O(n²)‎ أو وقتًا رباعيًا O(n⁴)‎ الذي هو أبطأ من O(n³)‎ أو غيره من الأوقات الزمنية متعددة الحدود.

تعقيد O(2ⁿ): وقت أسي

أخذ صور لرف الكتب مع كل مجموعة ممكنة من الكتب هو عملية تستغرق وقتًا أُسّيًا. انظر لهذا الأمر بهذه الطريقة، كل كتاب على الرف يمكن أن يكون في الصورة أو لا يكون. يبين الشكل 1 كل مجموعة ممكنة، إذ تكون n هي 1 أو 2 أو 3. إذا كانت n هي 1 هناك طريقين للتجميع، إذا كانت n هي 2 هناك أربعة صور ممكنة، الكتابان على الرف، أو الكتابان ليسا على الرف، أو الكتاب الأول موجود والثاني ليس موجودًا، أو الكتاب الأول ليس موجودًا والثاني موجود. إذا أضفنا كتابًا ثالثًا، نكون قد ضاعفنا مرةً ثانية العمل المُراد فعله، لذا يجب عليك النظر إلى كل مجموعة فرعية لكتابين التي تضم الكتاب الثالث (أربعة صور) وكل مجموعة فرعية لكتابين دون الكتاب الثالث (أربعة صور أُخرى أي 2³ أو 8 صور). يضاعف كل كتاب إضافي كمية العمل، فمن أجل n كتاب سيكون عدد الصور التي يجب أخذها (أي العمل الواجب فعله) هو 2ⁿ.

[الشكل 1: مجموعة الكتب الممكنة على رف كتب من أجل كتاب واحد أو اثنين أو ثلاث كتب]

يزداد وقت التنفيذ للمهام الأُسية بسرعة كبيرة. تحتاج ستة كتب إلى 2⁶ أو 32 صورة، ولكن 32 كتاب يحتاج 2³² أو أكثر من 4.2 مليار صورة. مرتبة O(2²) أو O(2³)‎ أو O(2⁴) وما بعدها هي مراتب مختلفة ولكنها كلها تحتوي تعقيدات وقت أُسّي.

تعقيد O(n!)‎: وقت عاملي

أخذ صورةٍ لكل ترتيب معين هي عملية تستغرق وقتًا عاملي. نطلق على كل ترتيب ممكن اسم التبديل permutation من أجل n كتاب. النتيجة هي ترتيب n!‎ أو n عاملي، فمثلًا 3‎!‎‎ هي 3×2×1 أو 6. يبين الشكل 2 كل التبديلات الممكنة لثلاثة كتب.

[الشكل 2: كل تبديلات !3 (أي 6) لثلاثة كتب على رف كتب]

لحساب ذلك بنفسك، فكر بكل التبديلات الممكنة بالنسبة إلى n كتاب. لديك n خيار ممكن للكتاب الأول وبعدها n-1 خيار ممكن للكتاب الثاني (أي كل كتاب ما عدا المكان الذي اخترته للكتاب الأول) وبعدها n-2 خيار ممكن للكتاب الثالث وهكذا دواليك. مع 6 كتب تكون نتيجة !6 هي 6×5×4×3×2×1 أو 720 صورة. إضافة كتاب واحد آخر يجعل عدد الصور المطلوبة !7 أو 5.040. حتى من أجل قيم n صغيرة، تصبح خوارزميات الوقت العاملي مستحيلة الإنجاز في وقت منطقي، فإذا كان لديك 20 كتاب ويمكنك ترتيبهم وأخذ صورة كل ثانية، فستحتاج إلى وقت أكثر من عمر الكون للانتهاء من كل تبديل.

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

يحسب ترميز Big O الحالات الأسوأ

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

يستخدم بعض المبرمجين ترميز big Omega لوصف الحالة الأفضل للخوارزمية، فمثلًا تعمل خوارزمية ‎Ω(n)‎ بكفاءة خطية في أفضل حالاتها وفي الحالة الأسوأ ربما تستغرق وقتًا أطول. تواجه بعض الخوارزميات حالات محظوظة جدًا، يحيث لا تعمل أي شيء، مثل إيجاد مسار الطريق لمكان أنت أصلًا فيه.

يصف ترميز Big Theta الخوارزميات التي لها الترتيب نفسه في أسوأ وأفضل الحالات، فمثلًا تصف ‎Θ(n)‎ خوارزميةً لديها كفاءة خطية في أحسن وأسوأ الحالات، أي أنها خوارزمية O(n)‎ وكذلك ‎Ω(n)‎. لا يُستخدم هذين الترميزين كثيرًا مثل استخدام big O ولكن تجدر معرفتهما.

يُعد سماع الناس يتحدثون عن "big O الحالة الوسطية" عندما يعنون big Theta أو "big O الحالة الفُضلى" عندما يعنون big Omega أمرًا شائعًا رغم أنه متناقض؛ إذ تصف big O الحالة الأسوأ لوقت تنفيذ الخوارزمية تحديدًا، ولكن حتى لو كانت كلماتهم خاطئة لا تزال تفهم المعنى بغض النظر.

العمليات الرياضية الكافية للتعامل مع Big O

إذا كان علم الجبر لديك ضعيفًا فمعرفة العمليات الرياضية التالية أكثر من كافي عند التعامل مع big O:

• الضرب: تكرار الإضافة أي 2×4=8 هو مثل 2+2+2+2=8، وفي حال المتغيرات يكون n+n+n هو 3‎×n.
• ترميز الضرب: يهمل ترميز الجبر عادةً إشارة ×، لذا 2‎×n تُكتب 2n ومع الأرقام 3×2 تُكتب (3)2 أو ببساطة 6.
• خاصية الضرب بالعدد 1: ضرب أي عدد بالرقم 1 يُنتج الرقم نفسه أي 5=x1‏5 و42 =x1‏42 أو عمومًا n×1=n
• توزيع الضرب على الجمع: (3×2) + (3×2) = (4+3)2x كل طرف من المعادلة يساوي 14 أي عمومًا a(b+c) = ab+ac
• الأس: تكرار الضرب 16= 2⁴ (تُلفظ "2 مرفوعة للقوة الرابعة تساوي 16") مثل 2×2×2×2= 16 هنا تكون 2 هي الأساس و 4 هي الأس. باستخدام المتغيرات n×n×n×n هي n⁴. يُستخدم في بايثون المعامل ** على سبيل المثال 2**4 تساوي 16.
• الأس الأول يساوي الأساس: 2= 2¹ و 9999=9999¹ وبصورةٍ عامة n¹=n
• الأس 0 يساوي 1: 1= 2⁰ و 1=9999⁰ وبصورةٍ عامة n⁰=1
• المعاملات: عوامل الضرب في 3n²+4n+5 المعاملات هي 3 و4 و5. يمكنك معرفة أن 5 هي معامل لأن 5 يمكن أن يُعاد كتابتها بالشكل (1)5 وأيضًا يمكن إعادة كتابتها 5n⁰.
• اللوغاريتمات: عكس الأس. لأن 16=2⁴ نعرف أن log₂(16)=4. نفول لوغاريتم الأساس 2 للعدد 16 هو 4. نستخدم في بايثون دالة math.log()‎ إذ math.log(16, 2)‎ تساوي إلى 4.0.

يتطلب حساب big O تبسيط العمليات عن طريق جمع الحدود المتشابهة؛ والحد هو مجموعة من الأرقام والمتغيرات مضروبة مع بعضها، ففي 3n²+4n+5 تكون الحدود هي 3n² و4n و5، إذ أن الحدود المتشابهة لديها نفس المتغير مرفوعًا لنفس القوة. في التعبير 3n²+4n+6n+5 الحدان 4n و6n هما متشابهان بإمكاننا التبسيط وإعادة الكتابة كالتالي 3n²+10n+5.

خذ بالحسبان أنه يمكن كتابة 3n²+5n+4 على النحو التالي 3n²+5n+4(1)‎، إذ تطابق الحدود في هذا التعبير مرتبات big O التالية O(n²)‎ و O(n)‎ و O(1)‎. سيفيد هذا لاحقًا عندما نُسقط المعاملات في حسابات big O.

ستفيد هذه التذكرة عندما تحاول معرفة big O لقطعة من الشيفرة، ولكن لن تحتاجها بعد أن تنتهي من "تحليل Big O بنظرة سريعة" في المقال التالي. مفهوم big O بسيط ويمكن أن يفيد حتى لو لم تتبع القواعد الرياضية بصرامة.

الخلاصة

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

هناك سبع مراتب لترميز big O، وهي: O(1)‎ أو الوقت الثابت، الذي يصف الشيفرة التي لا تتغير مع زيادة البيانات؛ و O(log n)‎ أو الوقت اللوغاريتمي الذي يصف الشيفرة التي تزداد بخطوة كلما تضاعف عدد البيانات بمقدار n؛ و O(n)‎ أو الوقت الخطي، الذي يصف الشيفرة التي تتباطأ يتناسب مع زيادة حجم البيانات بمقدار n؛ و O(n log n)‎ أو وقت n-log-n، الذي يصف الشيفرة التي هي أبطأ من O(n)‎ والعديد من خوارزميات الترتيب لديها هذه المرتبة.

المراتب الأعلى هي أبطأ لأن وقت تنفيذها يزداد بصورةٍ أسرع من زيادة حجم دخل البيانات. يصف الوقت الحدودي O(n²)‎ الشيفرة التي يزداد وقت تنفيذها بتربيع الدخل n. ليست المراتب O(2ⁿ)‎ أو الوقت الأسّي، و O(n!)‎ أو الوقت العاملي شائعة جدًا، ولكنها تأتي مع المجموعات والتبديلات على الترتيب.

ترجمة -وبتصرف- لقسم من الفصل Measuring Performance And Big O Algorithm Analysis من كتاب Beyond the Basic Stuff with Python.

اقرأ أيضًا

• المقال السابق: قياس أداء وسرعة تنفيذ شيفرة بايثون -تحليل الخوارزميات
• تعقيد الخوارزميات Algorithms Complexity
• دليل شامل عن تحليل تعقيد الخوارزمية

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

• المتطلبات الأساسية: المهارات الحاسوبية الأساسية.
• الهدف: فهم الهجمات الأكثر شيوعًا التي تهدّد أمان تطبيقات الويب وما يمكنك فعله لتقليل مخاطر اختراق موقعك.

ما هو أمان موقع الويب؟

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

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

دورة علوم الحاسوب

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

اشترك الآن

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

ملاحظة: يُعَد هذا المقال موضوعًا تمهيديًا، وهو مُصمَّم لمساعدتك على البدء في التفكير في أمان موقع الويب، ولكنه ليس شاملًا.

هجمات أمان مواقع الويب

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

هجمات السكربتات العابرة للمواقع Cross-Site Scripting أو XSS

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

ملاحظة: كانت ثغرات XSS سابقًا أكثر شيوعًا من أي نوع آخر من الهجمات الأمنية.

تنقسم ثغرات XSS إلى ثغرات منعكسة Reflected وأخرى دائمة Persistent بناءً على كيفية إعادة الموقع للسكربتات البرمجية المحقونة في المتصفح كما يلي:

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

http://developer.mozilla.org?q=beer<script%20src="http://example.com/tricky.js"></script>‎

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

تُعَد البيانات الواردة من طلبات من النوع "POST" أو "GET" المصدر الأكثر شيوعًا لثغرات XSS، ولكن يُحتمَل أن تكون أيّ بيانات من المتصفح عرضةً للخطر، مثل بيانات ملفات تعريف الارتباط التي يعرضها المتصفح، أو ملفات المستخدم المُحمَّلة والمعروضة. أفضل دفاع ضد ثغرات XSS هو إزالة أو تعطيل أي شيفرة HTML يمكن أن تحتوي على تعليمات لتشغيل الشيفرة البرمجية، ويتضمن ذلك في لغة HTML عناصرًا، مثل العناصر <script> و <object> و <embed> و <link>.

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

حقن استعلامات SQL

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

تظهر هذه الثغرة الأمنية إذا كان من الممكن أن يغيّر مُدخل المستخدم المُمرَّر إلى تعليمة SQL الأساسية معنى التعليمة، فالغرض من الشيفرة التالية مثلًا هو سرد كافة المستخدمين الذين يملكون اسمًا معينًا userName يوفّره نموذج HTML:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

إذا حدّد المستخدم اسمًا حقيقيًا، فستعمل التعليمة السابقة كما هو متوقع، ولكن يمكن لمستخدم ضار تغيير سلوك تعليمة SQL هذه بالكامل إلى التعليمة الجديدة في المثال الآتي من خلال تحديد التعليمة a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't للحقل userName.

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

تنشِئ التعليمة المُعدَّلة تعليمة SQL صالحة تحذف جدول المستخدمين users وتحدّد جميع البيانات من جدول معلومات المستخدم userinfo الذي يكشف عن معلومات كل مستخدم. تعمل هذه التعليمة لأن الجزء الأول من النص المحقون (a';‎) يكمل التعليمة الأصلية.

يمكنك تجنب هذا النوع من الهجوم من خلال التأكد من أن بيانات المستخدم المُمرَّرة إلى استعلام SQL لا يمكنها تغيير طبيعته، ويمكن تحقيق ذلك باستخدام محرف الهروب Escape Character للهروب من جميع المحارف في مدخلات المستخدم التي لها معنًى خاص في لغة SQL.

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

سنهرّب في التعليمة التالية المحرف (')، إذ ستفسّر لغة SQL الآن الاسم name على أنه سلسلة نصية كاملة بالخط العريض bold (حسنًا إنه اسم غريب جدًا، ولكنه ليس ضارًا):

SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';

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

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

تزوير الطلبات عبر المواقع Cross-Site Request Forgery أو CSRF

تسمح هجمات CSRF لمستخدمٍ ضار بتنفيذ إجراءات باستخدام ثبوتيات مستخدم آخر دون عِلم هذا المستخدم أو موافقته. لنفترض مثلًا أن سامي مستخدم ضار يعرف أن موقعًا معينًا يسمح للمستخدمين الذين سجّلوا الدخول بإرسال أموال إلى حسابٍ محدد باستخدام طلب HTTP من النوع "POST"، بحيث يتضمن هذا الطلب اسم الحساب ومبلغًا من المال. ينشئ سامي نموذجًا يتضمن التفاصيل المصرفية الخاصة به ومبلغًا من المال بوصفها حقولًا مخفية، ويرسله بالبريد الإلكتروني إلى مستخدمي الموقع الآخرين مع زر الإرسال Submit المخفي بوصفه رابطًا إلى موقع "الثراء السريع get rich quick".

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

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

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

تتضمن أطر عمل الويب آليات منع هجمات CSRF في أغلب الأحيان.

هجمات أخرى

تشمل الهجمات أو الثغرات الشائعة الأخرى ما يلي:

• هجمات الاختطاف بالنقر Clickjacking: يختطف مستخدم ضار في هذا الهجوم نقراتٍ مُوجَّهة إلى موقع مرئي من المستوى الأعلى ويوجّهها إلى صفحة مخفية. يمكن استخدام هذه التقنية مثلًا لعرض موقع مصرفي شرعي ولكنه يلتقط ثبوتيات تسجيل الدخول ضمن عنصر <iframe> غير مرئي يتحكم فيه المهاجم. يمكن استخدام هجمات الاختطاف بالنقر لجعل المستخدم ينقر على زر في موقع مرئي، ولكنه بذلك ينقر على زر مختلف تمامًا من غير عِلمه. يمكن تجنب ذلك من خلال أن يمنع موقعك نفسه من أن يُدمَج في عنصر <iframe> في موقع آخر عبر ضبط ترويسات HTTP المناسبة.
• هجمات حجب الخدمة Denial of Service -أو اختصارًا DoS: تتحقق هجمات DoS من خلال إغراق الموقع المستهدف بطلبات مزيفة بحيث يتعطل الوصول إلى الموقع للمستخدمين الشرعيين. يمكن أن تكون هذه الطلبات كثيرةً، أو يستهلك كل طلب منها كميات كبيرة من الموارد، مثل عمليات القراءة البطيئة، أو تحميل ملفات كبيرة. تعمل دفاعات DoS من خلال تحديد وحظر حركة المرور السيئة مع السماح بمرور الرسائل المشروعة، وتوجد هذه الدفاعات عادةً قبل خادم الويب أو فيه، فهي ليست جزءًا من تطبيق الويب نفسه.
• هجوم اجتياز شجرة الملفات Directory Traversal (الملف ومعلوماته): يحاول مستخدم ضار في هذا الهجوم الوصول إلى أجزاء من نظام ملفات خادم الويب التي لا ينبغي أن يتمكن من الوصول إليها. تحدث هذه الثغرة عندما يكون المستخدم قادرًا على تمرير أسماء الملفات التي تتضمن محارف التنقل في نظام الملفات، مثل /../..، والحل هو تعقيم مدخلات المستخدم قبل استخدامها.
• تضمين الملفات File Inclusion: يكون المستخدم في هذا الهجوم قادرًا على تحديد ملف عشوائي لعرض أو تنفيذ البيانات المُمرَّرة إلى الخادم. يمكن عند التحميل تنفيذ هذا الملف على خادم الويب أو من طرف العميل، مما يؤدي إلى هجوم XSS، والحل هو تعقيم مدخلات المستخدم قبل استخدامها.
• حقن الأوامر Command Injection: تسمح هجمات حقن الأوامر للمستخدم الضار بتنفيذ أوامر نظام عشوائية على نظام التشغيل المضيف. الحل هو تعقيم مدخلات المستخدم قبل استخدامها في استدعاءات النظام.

اطّلع أيضًا على الهجمات الأمنية Security Attacks في الشبكات الحاسوبية.

بعض النصائح الأساسية

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

تحذير: الدرس الوحيد الأكثر أهمية الذي يمكنك تعلّمه حول أمان موقع الويب هو عدم الوثوق أبدًا في البيانات الواردة من المتصفح مثل البيانات الموجودة في معاملات عنوان URL لطلبات "GET" وطلبات "POST" وترويسات وملفات تعريف ارتباط HTTP والملفات التي يرفعها المستخدم. تحقق دائمًا من جميع البيانات الواردة وعقّمها، وافترض الأسوأ دائمًا.

إليك عددًا من الخطوات الأخرى التي يمكنك اتخاذها:

• استخدام إدارة أكثر فاعلية لكلمات المرور: شجّع على استخدام كلمات المرور القوية، واستخدم الاستيثاق الثنائي two-factor authentication في موقعك، بحيث يجب على المستخدم إدخال رمز استيثاق آخر بالإضافة إلى كلمة المرور، إذ يمكن تسليم رمز الاستيثاق باستخدام العتاد الحقيقي الذي يمتلكه المستخدم فقط مثل رمز في رسالة SMS مرسَلة إلى هاتف المستخدم.
• إعداد خادمك الويب لاستخدام بروتوكولات HTTPS وأمن HTTP للنقل الصارم HTTP Strict Transport Security -أو اختصارًا HSTS: يشفّر بروتوكول HTTPS البيانات المرسَلة بين العميل والخادم، مما يضمن أن تكون ثبوتيات تسجيل الدخول وملفات تعريف الارتباط وبيانات طلبات "POST" ومعلومات الترويسة غير متاحة بسهولة للمهاجمين.
• يجب تتبّع الهجمات الأكثر شيوعًا (قائمة OWASP الحالية) ومعالجة الثغرات الأكثر شيوعًا أولًا.
• استخدام أدوات فحص الثغرات لإجراء اختبار أمان آلي على موقعك. يمكن أن يجد موقع الويب الناجح الخاص بك لاحقًا أخطاءً من خلال تقديم مكافآت على اكتشاف الأخطاء كما يفعل موقع موزيلا.
• تخزين وعرض البيانات التي تحتاجها فقط، فمثلًا إذا كان يجب على المستخدمين تخزين معلومات حساسة مثل تفاصيل البطاقة الائتمانية، فاعرض فقط أرقامًا كافية من رقم البطاقة التي يمكن للمستخدم تحديدها ولا يكفي أن ينسخها المهاجم ويستخدمها على موقع آخر، والنمط الأكثر شيوعًا عندها هو عرض آخر 4 أرقام فقط من رقم البطاقة الائتمانية.

يمكن أن تساعد أطر عمل الويب في التخفيف من العديد من الثغرات الأكثر شيوعًا.

الخلاصة

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

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

ترجمة -وبتصرُّف- للمقال Website security.

اقرأ أيضًا

• المقال السابق: أطر عمل الويب من طرف الخادم
• تأمين متصفحات الويب في العالم الرقمي
• ممارسات الأمن والحماية في تطبيقات PHP
• رفع مستوى أمان تطبيقات جانغو في بيئة الإنتاج

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

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

ما هي الخوارزمية؟

الخوارزمية algorithm هي مجموعة من التعليمات المرتبة لحل مشكلة ما في الرياضيات أو أي مشكلة تواجهك في الحياة اليومية خلال زمن محدد وعدد خطوات محدود.

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

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

تاريخ الخوارزميات

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

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

تطور مفهوم الخوارزميات في عصر الحضارة الإسلامية، إذ استخدم المسلمون الخوارزميات لحل المعادلات والمسائل الرياضية. ولعل أشهر هذه الخوارزميات هي خوارزمية حل المعادلات من الدرجة الثانية التي ذُكِرت في كتاب "حساب الجبر والمقابلة" لعالم الرياضيات المسلم محمد بن موسى الخوارزمي مؤسس علم الجبر، والذي تُنسب إليه كلمة خوارزمية في اللغة العربية، وكذلك الكلمة المقابلة لها في اللغات اللاتينية algorithm المُشتقة من الكلمة al-Khwārizmī، وهو الاسم الرومي للخوارزمي -وأيضًا كلمة الجبر algebra.

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

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

دورة علوم الحاسوب

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

اشترك الآن

أركان الخوارزمية

تملك أي خوارزمية ثلاثة أركان رئيسية وهي:

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

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

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

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

• الدخل: هو العددان الصحيحان المطلوب حساب ناتج جدائهما x, y

• الخرج: هو ناتج الجداء z

• متن الخوارزمية:

  • الخطوة 1: ابدأ

  • الخطوة 2: قم بالتصريح عن ثلاثة أعداد صحيحة x و y و z

  • الخطوة 3: أدخل قيم المدخلات x و y

  • الخطوة 4: اضرب قيم x بـ y

  • الخطوة 5: خزّن ناتج الضرب في z

  • الخطوة 6: اعرض قيمة z

  • الخطوة 7: توقف

خطوات حل الخوارزميات

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

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

طرق تمثيل الخوارزميات

يمكنك ثمثيل الخوارزمية أو التعبير عنها بعدة طرق:

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

تتوافر عدة برامج مساعدة تساعدك على رسم المخططات الانسيابية، وللمزيد يمكنك مطالعة مقال كيفية رسم مخطط انسيابي Flowchart باستخدام PowerPoin.

دورة الذكاء الاصطناعي

احترف برمجة الذكاء الاصطناعي AI وتحليل البيانات وتعلم كافة المعلومات التي تحتاجها لبناء نماذج ذكاء اصطناعي متخصصة.

اشترك الآن

مثال على استخدام الخوارزمية في حياتنا اليومية

على سبيل المثال إذا طلب منك كتابة خوارزمية توضح طريقة التعامل مع آلة صنع القهوة والشاي ستكون الخطوات التي عليك اتباعها كالتالي:

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

للتعبير عن هذه الخوارزمية باستخدام الشيفرة الزائفة سنكتب التالي:

START;
/Would you like Tea or Coffee?/;
if tea {
  Add Tea in cup;
} else {
  Add Coffee in cup;
}
/Would you like Sugar?/;
if Sugar {
  Add Sugar in cup;
}
Pour boiling water in cup
END;

وللتعبير عنها باستخدام المخطط الانسيابي سنرسم المخطط التالي:

أمثلة على الخوارزميات

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

خوارزمية لحساب قيمة مضروب عدد

في الرياضيات المضروب factorial أو عاملي العدد الصحيح n الذي يعبر عنه بالشكل التالي n! هو جداء كل الأعداد الطبيعية المساوية أو الأصغر من n ما عدا الصفر ولكتابة خوارزمية تحل هذه المسألة الرياضية علينا اتباع الخطوات التالية:

• الدخل: هو العدد الصحيح المطلوب حساب مضروبه n.
• الخرج: هو ناتج المضروب factorial
• المتن:
  • الخطوة 1: إدخال العدد n المراد حساب مضروبه
  • الخطوة 2: تعريف متغير مساعد وليكن i وهو عبارة عن عدد صحيح يأخذ قيمة متغيرة بين الواحد والعدد نفسه ويساعدنا على حساب القيمة المطلوبة.
  • الخطوة 3: تهيئة المتغير factorial الذي يمثل القيمة المؤقتة للمضروب، والمتغير i الذي يمثل المرحلة التي نحن فيها أثناء تنفيذ الخوارزمية بالقيمة واحد أي نجعل factorial = 1 و i = 1
  • الخطوة 4: إعادة تعيين قيم المتغير factorial بالقيمة factorial*i والمتغير بالقيمة i+1
  • الخطوة 5: كرر الخطوة 3 حتى تصبح قيمة المتغير i أكبر تمامًا من n
  • الخطوة 6: قم بإيقاف الخوارزمية وإعادة قيمة factorial التي تمثل مضروب العدد n

الصورة التالية توضح طريقة رسم المخطط الانسيابي لحل خوارزمية حساب مضروب عدد:

هل تعرف طرقًا أو أساليب أخرى لحل هذه المسألة؟ شاركنا إياها في قسم التعليقات أسفل المقال.

خوارزمية للعثور على أكبر عدد من بين ثلاثة أعداد

سنكتب حل هذه المسألة بأكثر من خوارزمية أو طريقة:

طريقة 1:

• الدخل: 3 أرقام a و b و c

• الخرج: العدد الأكبر من بينها a أو b أو c

• المتن:

  • الخطوة 1: أدخل الأرقام الثلاثة وخزنها في المتغيرات a و b و c على التوالي.

  • الخطوة 2: تحقق من كون الرقم الأول a أكبر من الرقم الثاني b و الثالث c عندها اطبع أن a هو العدد الأكبر بين الكل وأنهي التنفيذ

  • الخطوة 3: تحقق من كون b أكبر من a و c عندها اطبع أن b هو العدد الأكبر بين الكل وأنهي التنفيذ

  • الخطوة 4: تحقق من كون c أكبر من a و b عندها اطبع أن c هو العدد الأكبر بين الكل وأنهي التنفيذ

الكود الزائف للتعبير عن خوارزمية أكبر عدد بين 3 أعداد:

Step-1 Start
Step-2 Read three numbers a,b,c
Step-3 If a>b then go to step-5
Step-4 IF b>c THEN
print b is largest
ELSE
print c is largest
ENDIF
GO TO Step-6
Step-5 IF a>c THEN
print a is largest
ELSE
print c is largest
ENDIF
Step-6 Stop

والمخطط الانسيابي للتعبير عن الخوارزمية هو كما يلي:

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

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

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

طريقة 2:

• الدخل: 3 أرقام a و b و c

• الخرج: max الذي يمثل العدد الأكبر

• المتن:

  • الخطوة 1: أدخل الأعداد الثلاثة وخزنها في a و b و c على التوالي

  • الخطوة 3: افترض أن العدد الأول a هو الأكبر max = a

  • الخطوة 4: إذا كان العدد الثاني b أكبر من max اجعل max = b

  • الخطوة 5: إذا كان العدد الثالث c أكبر من أكبر من max اجعل max = c

  • الخطوة 6: اعرض قيمة max

الكود الزائف للتعبير عن هذه الخوارزمية لإيجاد أكبر عدد من بين 3 أعداد:

Step-1 Start
Step-2 Read three numbers: a,b,c
Step-3 max = a
Step-4 IF b > max THEN
max = b
ENDIF
Step-5 IF c > max THEN
max = c
ENDIF
Step-6 print max
Step-7 Stop

والمخطط الانسيابي للتعبير عن الخوارزمية هو كما يلي:

Quote

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

هل لديك خوارزمية أخرى أفضل لحل هذه المسألة؟ يمكن أن تشاركنا إياها لنتناقش حولها.

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

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

تحويل الخوارزمية إلى برنامج حاسوبي

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

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

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

تنفيذ خوارزمية إيجاد أكبر عدد من بين ثلاثة أعداد في لغة بايثون

برنامج بايثون لإيجاد أكبر عدد من بين ثلاثة أعداد

a = int(input('a= '))
b = int(input('b= '))
c = int(input('c= '))
max = a
if b > max :
    max = b
if c > max :
    max = c
print(max, "هو العدد الأكبر")

يمكنك الآن تنفيذ هذه الشيفرة على أيّ حاسوب وستعمل كما هو متوقع. كما يمكنك بالطبع تحقيق الخوارزمية بأيّ لغة برمجة أخرى تريدها مثل C أو C++‎ أو جافا أو جافا سكريبت أو R …إلخ.

تمرين ما رأيك أن تجرب تحويل الخوارزمية السابقة إلى برنامج حاسوبي يطلب من المستخدم إدخال مجموعة أعداد تفصل بينها فراغات مثل 4 9 8 7 10 ليحللها البرنامج بتلك الخوارزمية ويعطي العدد الأكبر من بينها (مساعدة: ستحاول استعمال حلقات التكرار loops)

مجالات استخدام الخوارزميات

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

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

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

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

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

مواصفات الخوارزمية الجيدة

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

• الوضوح: ينبغي أن تكون كل خطوة من خطوات الخوارزمية واضحة ومفهومة ولا لبس فيها.

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

• البساطة والواقعية: ينبغي أن تكون الخوارزمية قابلة للتطبيق بالموارد والتقنيات المتاحة، ولا ينبغي أن تعتمد على تقنية مستقبلية أو غامضة.

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

• صحة النتائج: يجب أن تقوم الخوارزمية بتنفيذ المهمة المطلوبة منها دون أخطاء في التنفيذ أو عدم دقة في النتائج.

• الكفاءة والفعالية: ينبغي أن تستخدم الخوارزمية أفضل الطرق لحل المشكلة بأسرع وقت تنفيذ أو ما يعرف بالتعقيد الزماني للخوارزمية وأقل مساحة ذاكرة أو ما يعرف بالتعقيد المكاني للخوارزمية.

هل أحتاج إلى معرفة الرياضيات لتعلم الخوارزميات؟

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

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

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

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

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

تحليل الخوارزميات

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

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

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

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

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

وإليك قائمة مختصرة بأشهر أنواع تعقيد الخوارزميات وفق تدوين Big O ودلالة كل منها:

• O(1)‎ تعقيد زمني ثابت: أي تستغرق الخوارزمية نفس الزمن مهما كان حجم الدخل.

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

• O(sqrt(n)) تعقيد جذر تربيعي: أي إذا كان حجم دخل الخوازرمية هو n سوف يتناسب زمن تنفيذ الخوارزمية مع الجذر التربيعي لقيمة الدخل.

• O(n^c)‎ تعقيد كثير الحدود: يتناسب زمن تنفيذ الخوارزمية مع حجم الدخل مرفوع للأس c وله أنواع فقد يكون تعقيد زمني تربيعي O (n^²)‎ أي يتناسب زمن تنفيذ الخوارزمية مع مكعب حجم الدخل أو تعقيد زمني تكعيبي O(n^3)‎ أي يتناسب زمن تنفيذ الخوارزمية مع مكعب حجم الدخل.

• O(log n)‎ تعقيد لوغاريتمي: تناسب زمن تنفيذ الخوارزمية مع لوغاريتم حجم الدخل.

• O(n log n)‌‎ تعقيد لوغاريتمي خطي: وهو أبطأ قليلاً من الخطي

• O(2^n)‎ تعقيد أسي: وفيه تتضاعف خطوات الخوارزمية بشكل أسي مع زيادة حجم الدخل.

• O(n!)‎ تعقيد عاملي: أي يتناسب زمن الخوارزمية مع قيمة عاملي الدخل أي ضرب جميع الأعداد الصحيحة الموجبة الأصغر من قيمة الدخل. 

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

للمزيد من المعلومات أنصح بمطالعة مقال مدخل إلى تحليل الخوارزميات ومقال الدليل الشامل عن تعقيد الخوارزميات

أنواع الخوارزميات البرمجية

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

• خوارزميات القوة الغاشمة Brute force algorithms : تحاول الخوارزميات من هذا النوع حل المشكلة بطريقة مباشرة وتمر بجميع الخيارات الممكنة حتى تتمكن من العثور على حل لهذه المشكلة.
• الخوارزميات الجشعة Greedy algorithms: تحاول الخوارزميات الجشعة حل المشكلة خطوة فخطوة، بحيث تقترب رويدًا رويدًا من الحل العام للمشكلة.
• خوارزميات البرمجة الديناميكية Dynamic Programming: تقسّم خوارزميات البرمجة الديناميكية المشكلة إلى مشاكل فرعية أبسط، ثمّ تحل تلك المشاكل الفرعية لاستنتاج الحل النهائي
• خوارزميات فرق تسد Divide and conquer algorithms: تقسِّم خوارزميات فرِّق تسد المسألة إلى مسائل فرعية تشبه المسألة الأصلية، ثمّ تحلها وتدمج الحلول لتقديم حلٍّ المسألة الأصلية.
• خوارزميات التعقب الخلفي Backtracking algorithms: تحاول خوارزميات التعقب الخلفي حل المشكلة تعاوديًا عبر بناء الحل تصاعديًا خطوة فخطوة، مع حذف الحلول التي لا تستجيب للقيود التي تفرضها المسألة المُراد حلها في أيّ وقت أثناء تنفيذ الخوارزمية.
• خوارزميات الترتيب Sort algorithms: هي خوارزميات ترتب مجموعة من العناصر القائمة في ترتيب معين رقمي أو هجائي. والفرز هو أحد الخطوات الهامة في الخوارزميات الأكثر تعقيدًا، توجد عدة خوارزميات تمكننا من تحقيق عملية الفرز ولكل منها ميزاتها ومحدوديتها.
• خوارزميات البحث Search algorithms: هي خوارزميات تقوم بتحديد موقع بيانات محددة بين مجموعة من البيانات أي أنها تبحث عن البيانات المخزنة ضمن بعض الهياكل أو بنى البيانات وتقوم باستردادها.
• خوارزميات التعلم الآلي: هي خوارزميات تحاول التعلم بناءً على مجموعة من حالات اتخاذ القرار السابقة كي تتمكن من اتخاذ قرارات معقدة بناءً عليها.
• خوارزميات التشفير: هي الخوارزميات التي تقوم بتحويل نص مقروء إلى نص غير مقروء يُعرف باسم النص المشفر بحيث يمكن للأطراف المصرح لهم فقط بفهم المعلومات الموجودة في هذا النص وهي خوارزميات هامة جدًا في مجال أمن البيانات الحساسة والحفاظ على الخصوصية.

كانت تلك بعض أنواع وتصنيفات الخوارزميات الأكثر شيوعًا وهناك بالطبع العديد من الخوارزميات الأخرى للعديد من الحالات المختلفة.

هناك أيضًا طرق أخرى يمكن تطبيقها بسهولة في التطبيقات مثل خوارزمية Dijkstra و Cycle Detection و Kruskal Minimum Spanning Trees فهي من الخوارزميات الأساسية للمبتدئين للتعلم منها.

أهمية الخوارزميات في البرمجة

هناك من قد يقول أنّ تعلم الخوارزميات تَرفٌ، وهو غير ضروري لكتابة البرامج والتطبيقات، وأنّه يمكن للمبرمج أن يكتب برامجه مباشرة دون الحاجة إلى مفاهيم الخوارزميات.

صحيح أنّه ليس عليك أن تكون خبيرًا في الخوارزميات لتَكون مبرمجًا، لكن لا يمكنك أن تكون مبرمجًا بارعًا ومحترفًا دون أن تتعلم فن تصميم الخوارزميات.

يوفر تعلم الخوارزميات للمبرمج العديد من الفوائد أبرزها:

• القدرة على حل المشكلات بشكل أفضل
• الاستخدام الفعال للموارد الحاسوبية
• يوفر وقت البرمجة
• يجعل منك مبرمجًا أفضل

لنناقش كل فائدة منها بمزيد من التفصيل ونتعرف كيف يسهم تعلم الخوارزميات في تعزيزها.

القدرة على حل المشكلات بشكل أفضل

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

الاستخدام الفعال للموارد

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

توفير وقت البرمجة

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

الخوارزميات تجعل منك مبرمجًا أفضل

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

أهم مصادر تعلم الخوارزميات

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

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

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

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

كما أن السلسلة تنفذ الخوارزميات التي تستعرضها من خلال العديد من لغات البرمجة، فمهما كانت لغة البرمجة خاصتك، سواء كانت بايثون أو جافا أو C++/C أو #C‏‏ أو جافا سكريبت، فستجد أمثلة بهذه اللغات وغيرها في هذا الكتاب.

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

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

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

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

الخلاصة

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

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

اقرأ أيضًا

• أمثلة عن أنواع الخوارزميات
• تعرف على تخصص هندسة البرمجيات
• مهندس البرمجيات من هو وما هي مهامه
• ما هي مدة تعلم البرمجة؟

ناقشنا حتى الآن في سلسلة مدخل لعلم الحاسوب كيفية تحميل البرنامج في الذاكرة الوهمية، وسنبدأ في هذا المقال بالتعرف على عملية يتعقّبها نظام التشغيل ويتفاعل معها باستخدام استدعاءات النظام هي عملية التصريف Compiling. سنتعرّف في هذا المقال على الخطوات الثلاث لإنشاء ملف قابل للتنفيذ، ولكن سنبدأ أولًا بالتعرّف على الفرق بين البرامج المُصرَّفة Compiled Programs والبرامج المُفسَّرة Interpreted Programs.

البرامج المُصرَّفة Compiled Programs والبرامج المُفسَّرة Interpreted programs

يجب أن يكون البرنامج الذي يمكن تحميله مباشرةً في الذاكرة بصيغة ثنائية binary format، حيث تُسمَّى عملية تحويل الشيفرة البرمجية المكتوبة بلغةٍ مثل لغة C إلى ملف ثنائي جاهز للتنفيذ بعملية التصريف التي تُطبَّق باستخدام مصرِّف Compiler، والمثال الأكثر انتشارًا هو المصرِّف gcc.

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

تعمل البرامج المفسَّرة عادةً بصورة أبطأ من نظيرتها المُصرَّفة، حيث يمكن مصادفة حِمل البرنامج في قراءة وتفسير الشيفرة البرمجية مرةً واحدة فقط في البرامج المُصرَّفة، بينما يصادف البرنامج المفسَّر هذا الحِمل في كل مرة يُشغَّل فيها. لكن تمتلك اللغات المفسَّرة العديد من الجوانب الإيجابية، حيث تعمل العديد من اللغات المفسرة فعليًا في آلة افتراضية virtual machine مُجرَّدة من العتاد الأساسي. تُعَد لغتا بايثون Python و Perl 6 من اللغات التي تستخدم آلةً افتراضية تفسّر الشيفرة البرمجية.

الآلات الافتراضية Virtual Machines

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

تستخدم لغة جافا Java مثلًا نهجًا هجينًا يجمع بين التصريف والتفسير، فهي لغة مُصرَّفة جزئيًا ومُفسَّرة جزئيًا. تُصرَّف شيفرة جافا في برنامج يعمل ضمن آلة جافا الافتراضية Java Virtual Machine أو يشار إليها JVM اختصارًا، وبالتالي يمكن تشغيل البرنامج المُصرَّف على أيّ عتاد يحتوي على آلة JVM خاصة به، أي يمكنك أن تكتب شيفرتك البرمجية مرة واحدة وتشغّلها في أيّ مكان.

بناء ملف قابل للتنفيذ

هناك ثلاث خطوات منفصلة تتضمنها عملية إنشاء ملف قابل للتنفيذ عندما نتحدث عن المُصرِّفات وهذه الخطوات هي:

1. التصريف Compiling
2. التجميع Assembling
3. الربط Linking

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

التصريف Compiling

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

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

هناك خطوة قبل تحليل الشيفرة البرمجية في الشيفرة المكتوبة بلغة C، حيث تسمَّى هذه الخطوة بالمعالجة المُسبَقة أو التمهيدية يقوم بها المعالج المسبق Pre-processor، وهو عبارة عن برنامج لاستبدال النصوص، حيث يُستبدَل مثلًا المتغير variable المُصرَّح عنه بالشكل ‎#define variable text بالنص text، ثم تُمرَّر هذه الشيفرة البرمجية المعالَجة مسبقًا إلى المصرِّف.

الصياغة

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

تُوصَف الصياغة في صيغة باكوس نور Backus-Naur Form -أو BNF اختصارًا- في أغلب الأحيان، وهي لغة يمكنك من خلالها وصف اللغات، والشكل الأكثر شيوعًا منها هو صيغة باكور نور الموسَّعة Extended Backus-Naur Form -أو EBNF اختصارًا- التي تسمح ببعض القواعد الإضافية الأكثر ملاءمة للغات الحديثة.

توليد شيفرة التجميع Assembly Generation

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

المحاذاة Alignment

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

لا تستطيع وحدات المعالجة المركزية CPU تحميل قيمة في المسجل من موقع ذاكرة عشوائي، إذ يتطلب ذلك أن تحاذي المتغيرات حدودًا معينة. يمكننا أن نرى في الشكل السابق كيفية تحميل قيمة 32 بتًا (4 بايتات) في مسجل على آلة تتطلب محاذاة بمقدار 4 بايتات للمتغيرات.

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

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

حاشية البنية Structure Padding

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

إليك مثال عن حاشية بنية Struct Padding:

$ cat struct.c
#include <stdio.h>

struct a_struct {
  char char_one;
  char char_two;
  int int_one;
};

int main(void)
{

  struct a_struct s;

  printf("%p : s.char_one\n" \
    "%p : s.char_two\n" \
    "%p : s.int_one\n", &s.char_one,
    &s.char_two, &s.int_one);

  return 0;

}

$ gcc -o struct struct.c

$ gcc -fpack-struct -o struct-packed struct.c

$ ./struct
0x7fdf6798 : s.char_one
0x7fdf6799 : s.char_two
0x7fdf679c : s.int_one

$ ./struct-packed
0x7fcd2778 : s.char_one
0x7fcd2779 : s.char_two
0x7fcd277a : s.int_one

أنشأنا في المثال السابق بنية تحتوي على بايتين من النوع char متبوعين بعدد صحيح بحجم 4 بايتات من النوع int. يضيف المصرِّف حاشية للبنية البنية كما يلي:

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

محاذاة خط الذاكرة المخبئية Cache line alignment

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

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

إحدى الطرق الممكنة لاكتشاف هذا النوع من المواقف هي التشخيص Profiling الذي يمثّل مراقبة الشيفرة البرمجية لتحليل مساراتها التي يمكن استخدامها والمدة المُستغرقَة لتنفيذها. يمكن للمصرِّف باستخدام التحسين المُوجَّه بالتشخيص Profile Guided Optimization -أو PGO اختصارًا- وضعَ بتات إضافية خاصة من الشيفرة البرمجية في أول ثنائية binary يبنيها ويشغّلها ويسجّل الفروع المأخوذة منها وغير ذلك. يمكنك بعد ذلك إعادة تصريفها مع المعلومات الإضافية لإنشاء ثنائية binary مع أداء أفضل، وإلّا فيمكن للمبرمج أن ينظر إلى خرج عملية التشخيص ويكتشف مواقفًا أخرى مثل ارتداد خط الذاكرة المخبئية.

المقايضة بين المساحة والسرعة

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

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

وضع الافتراضات

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

إليك مثال عن محاذاة المكدس Stack Alignment:

$ cat stack.c
#include <stdio.h>

struct a_struct {
  int a;
  int b;
};

int main(void)
{
  int i;
  struct a_struct s;
  printf("%p\n%p\ndiff %ld\n", &i, &s, (unsigned long)&s - (unsigned long)&i);
  return 0;
}
$ gcc-3.3 -Wall -o stack-3.3 ./stack.c
$ gcc-4.0 -o stack-4.0 stack.c

$ ./stack-3.3
0x60000fffffc2b510
0x60000fffffc2b520
diff 16

$ ./stack-4.0
0x60000fffff89b520
0x60000fffff89b524
diff  4

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

مفاهيم لغة C الخاصة بالمحاذاة

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

يمكننا أخذ بعض الأمثلة من نواة لينكس Linux kernel التي يتعين عليها في أغلب الأحيان التعامل مع محاذاة صفحات الذاكرة ضمن النظام. إليك مثال عن التعامل مع محاذاة الصفحات:

[ include/asm-ia64/page.h ]

/*
 * ‫يحدّد PAGE_SHIFT حجم صفحة النواة الفعلي
 */
#if defined(CONFIG_IA64_PAGE_SIZE_4KB)
# define PAGE_SHIFT     12
#elif defined(CONFIG_IA64_PAGE_SIZE_8KB)
# define PAGE_SHIFT     13
#elif defined(CONFIG_IA64_PAGE_SIZE_16KB)
# define PAGE_SHIFT     14
#elif defined(CONFIG_IA64_PAGE_SIZE_64KB)
# define PAGE_SHIFT     16
#else
# error Unsupported page size!
#endif

#define PAGE_SIZE               (__IA64_UL_CONST(1) << PAGE_SHIFT)
#define PAGE_MASK               (~(PAGE_SIZE - 1))
#define PAGE_ALIGN(addr)        (((addr) + PAGE_SIZE - 1) & PAGE_MASK)

يمكننا أن نرى في المثال السابق أن هناك عددًا من الخيارات المختلفة لأحجام الصفحات داخل النواة التي تتراوح من 4 كيلوبايتات إلى 64 كيلوبايت. يَُعد الماكرو PAGE_SIZE واضحًا إلى حد ما، فهو يعطي حجم الصفحة الحالي المحدّد ضمن النظام عن طريق انزياح قيمته 1 باستخدام رقم الانزياح المُعطَى، ويعادل ذلك 2n حيث n هو انزياح الصفحة PAGE_SHIFT.

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

التحسين Optimisation

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

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

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

• الدوال المضمنة Inlining Functions: يمكن وضع دوال مُضمَّنة لاستدعائها ضمن المستدعي callee، ويمكن للمبرمج تحديد ذلك للمصرِّف من خلال وضع الكلمة inline في تعريف الدالة، ويمكنك مقايضة حجم الشيفرة البرمجية بتسلسل تنفيذها من خلال ذلك.

• توقع الفرع Branch Prediction: إذا صادف الحاسوب تعليمة if، فهناك نتيجتان محتملتان إما صحيحة أو خاطئة. يريد المعالج الاحتفاظ بأنابيبه الواردة ممتلئة قدر الإمكان، لذا لا يمكنه انتظار نتيجة الاختبار قبل وضع الشيفرة البرمجية في خط الأنابيب، وبالتالي يمكن للمصرِّف أن يتنبأ بالطريقة التي يُحتمَل أن يسير بها الاختبار. هناك بعض القواعد البسيطة التي يمكن أن يستخدمها المصرِّف لتخمين هذه الأمور، فمثلًا لا يُحتمَل أن تكون التعليمة if (val == -1)‎ صحيحةً، لأن القيمة ‎-1 تشير عادةً إلى رمز خطأ ونأمل ألّا تُشغَّل هذه التعليمة كثيرًا.

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

المجمع Assembler

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

المجمِّع assembly هو عملية آلية لتحويل شيفرة التجميع إلى صيغة ثنائية. يحتفظ المجمّع بجدول كبير لكل تعليمة ممكنة ولنظيرها الثنائي الذي يسمى شيفرة العملية Op Code. يدمج المجمّع شيفرات العمليات مع المسجلات المحدَّدة في شيفرة التجميع لإنتاج ملف ثنائي بوصفه خرجًا.

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

الرابط Linker

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

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

سنشرح فيما يلي بعض المصطلحات الأساسية لفهم عملية الربط.

الرموز Symbols

لجميع المتغيرات والدوال أسماء في الشيفرة المصدرية، إذ نشير إليها باستخدام هذه الأسماء. تتمثل إحدى طرق التفكير في تعليمة التصريح عن متغير int a في أنك تخبر المصرِّف بأن يحجز حيزًا من الذاكرة بحجم sizeof(int)‎، وبالتالي كلما استخدمت اسم المتغير a، فسيشير إلى هذه الذاكرة المخصَّصة، وكذلك الأمر بالنسبة للدالة التي تخبر المصرِّف بأن يحزّن هذه الشيفرة البرمجية في الذاكرة، ثم ينتقل إليها وينفّذها عند استدعاء الدالة function()‎. وبالتالي نستدعي الرمزين a و function لأنهما يُعَدان تمثيلًا رمزيًا لمنطقةٍ من الذاكرة.

تساعد هذه الرموز البشر على فهم البرمجة. لكن يمكنك القول أن المهمة الأساسية لعملية التصريف هي إزالة هذه الرموز، إذ لا يعرف المعالج ما يمثله الرمز a، فكل ما يعرفه هو أن لديه بعض البيانات في عنوان ذاكرة معين. تحوِّل عملية التصريف التعليمة a += 2 إلى العبارة "زيادة القيمة الموجودة في العنوان 0xABCDE من الذاكرة بمقدار 2".

اقتباس

إمكانية رؤية الرموز Symbol Visibility: لا بد أنك شاهدت في البرامج المكتوبة بلغة C المصطلحين static وextern مع المتغيرات، إذ يمكن أن تؤثر هذه المعدِّلات Modifiers على ما نسميه إمكانية رؤية الرموز.

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

تخبر الكلمة extern المصرِّف أنه لا ينبغي تخصيص أي مساحة في الذاكرة لهذا المتغير، ويجب ترك هذا الرمز في التعليمات المُصرَّفة لإصلاحه لاحقًا. لا يمكن للمصرِّف أن يعرف مكان تعريف الرمز فعليًا ولكن الرابط Linker يمكنه ذلك، فوظيفته هي النظر في جميع ملفات التعليمات المُصرَّفة ودمجها في ملف واحد قابل للتنفيذ. لذا سيرى الرابط هذا الرمز في الملف الثاني، وسيقول: "رأيت هذا الرمز مسبقًا في الملف 1، وأعلم أنه يشير إلى موقع الذاكرة 0x12345"، وبالتالي يمكن تعديل قيمة الرمز لتكون قيمة الذاكرة للمتغير الموجود في الملف الأول.

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

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

عملية الربط

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

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

تعرّفنا في هذا المقال على الخطوات الثلاث لبناء ملف قابل للتنفيذ هي: التصريف Compiling والتجميع Assembling والربط Linking، وسنطبّق في المقال التالي هذه الخطوات عمليًا لبناء ملف قابل للتنفيذ.

ترجمة -وبتصرُّف- للأقسام:

• Compiled v Interpreted Programs
• Building an executable
• Compiling
• Assembler
• Linker

من فصل The Toolchain من كتاب Computer Science from the Bottom Up لصاحبه Ian Wienand.

اقرأ أيضًا

• المقال التالي: تطبيق عملي لبناء برنامج تنفيذي من شيفرة مصدرية بلغة سي C
• المقال السابق: دعم عتاد الحاسوب للذاكرة الوهمية Virtual Memory
• مفهوم التصريف Compilation في لغات البرمجة
• تحسين الشيفرات المكتوبة بلغة Cpp وتشخيصها

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

الوضع الحقيقي والوضع الوهمي

تحتوي جميع المعالجات على مفهومٍ ما للعمل في الوضع الحقيقي Physical Mode أو الوضع الوهمي Virtual Mode، إذ يتوقع العتاد في الوضع الحقيقي أن يشير أيّ عنوان إلى عنوانٍ موجود في ذاكرة النظام الفعلية، بينما يعرف العتاد في الوضع الوهمي أنه يجب ترجمة العناوين للعثور على العنوان الحقيقي.

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

مشاكل التقطيع

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

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

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

التقطيع Segmentation

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

مخزن الترجمة المؤقت TLB

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

أخطاء الصفحات

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

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

تستخدم مخازن TLB شيئًا يشبه خوارزمية الأقل استخدامًا مؤخرًا Least Recently Used -أو LRU اختصارًا، حيث تُخرَج أقدم ترجمة غير مُستخدمَة لإدخال ترجمة جديدة. يمكن بعد ذلك محاولة الوصول مرة أخرى وسيسير كل شيء على ما يرام، حيث يجب العثور على الترجمة في مخزن TLB وستحدث الترجمة بصورة صحيحة.

العثور على جدول الصفحات

لا بد أنك تساءلت عن كيفية إيجاد نظام التشغيل للذاكرة التي تحتوي على جدول الصفحات page table عندما قلنا أن نظام التشغيل يجد الترجمة في هذا الجدول. يُحتفَظ بقاعدة جدول الصفحات في مسجّل مرتبط بكل عملية، حيث يسمى هذا المسجل بالمسجل الأساسي لجدول الصفحات page-table base-register أو ما شابه ذلك. يمكن تحديد موقع المدخلة الصحيحة بوضع العنوان في هذا المسجل وإضافة رقم الصفحة إليه.

أخطاء أخرى متعلقة بالصفحات

هناك عيبان مهمان آخران يمكن أن يولّدهما مخزن TLB ويساعدان على إدارة الصفحات المتسخة dirty pages أي الصفحات التي جرى الوصول إليها مسبقًا، حيث تحتوي كل صفحة على سمة مُمثَّلة ببتٍ واحد تحدّد إذا جرى الوصول إلى الصفحة أي أنها أصبحت صفحة متسخة.

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

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

الصفحة المتسخة هي الصفحة التي تحتوي على بياناتٍ مكتوبةٍ عليها، وبالتالي لا تتطابق مع أيّ بيانات موجودة فعليًا على القرص الصلب. إذا بُدِّلت الصفحة من ثم كتبت فيها عملية مثلًا، فيجب تحديث نسختها الموجودة على القرص الصلب قبل تبديلها. لا تُجرَى أيّ تغييرات على الصفحة النظيفة، لذلك لا حاجة لنسخ الصفحة مرةً أخرى إلى القرص الصلب.

يتشابه هذان النوعان من الصفحات من حيث أنهما يساعدان نظام التشغيل في إدارة الصفحات، حيث تحتوي الصفحة على بتين إضافيين هما: البت المتسخ Dirty Bit وبت الوصول Accessed Bit، إذ يُضبَط هذان البتان عند وضع الصفحة في مخزن TLB للإشارة إلى أن وحدة المعالجة المركزية يجب أن تصدر خطأ.

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

إدارة مخزن TLB

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

تفريغ مخزن TLB

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

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

بينما تطبّق المعالجات الأخرى معرّف فضاء عناوين إضافي Address Space ID -أو ASID اختصارًا- يُضاف إلى كل ترجمة في مخزن TLB لجعلها فريدة، وبالتالي يحصل كل فضاء عناوين -أو كل عملية حيث تريد الخيوط مشاركة فضاء العناوين نفسه- على معرّفها الخاص الذي يُخزَّن مع الترجمات في مخزن TLB، أي ليس هناك داعٍ لتفريغ مخزن TLB عند تبديل السياق، لأن العملية التالية سيكون لها معرّف فضاء عناوين مختلف، وسيختلف معرّف فضاء العناوين وستختلف الترجمة إلى الصفحة الحقيقية حتى إن طلبت العملية العنوان الوهمي نفسه. يقلل هذا النظام من عملية التفريغ ويزيد من أداء النظام، ولكنه يتطلب مزيدًا من عتاد TLB ليحتفظ ببتات معرّف ASID.

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

مخزن TLB المحمل برمجيا وعتاديا

يُعَد التحكم في مخزن TLB من اختصاص نظام التشغيل، ولكنها ليست القصة كاملة، إذ تشرح العملية الموضَّحة في فقرة "أخطاء الصفحات" خطأ الصفحة الذي يُرفَع إلى نظام التشغيل، ويمر على جدول الصفحات للعثور على ترجمة الصفحة الوهمية إلى الحقيقية وتثبيتها في مخزن TLB. يمكن أن يسمَّى ذلك بمخزن TLB المُحمَّل برمجيًا Software-loaded TLB، وهناك بديل آخر هو مخزن TLB المُحمَّل عتاديًا Hardware-loaded TLB.

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

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

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

دعم العتاد للذاكرة الوهمية

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

معالج إيتانيوم

توفر وحدة MMU في معالج إيتانيوم ميزات متعددة لنظام التشغيل للتعامل مع الذاكرة الوهمية سنوضحها فيما يلي.

فضاءات العناوين Address spaces

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

رسم توضيحي للمناطق ومفاتيح الحماية في معالج إيتانيوم

تدرس وحدة MMU في معالج إيتانيوم المشاكل السابقة وتوفر القدرة على مشاركة فضاء العناوين ومدخلات الترجمة بدقة أقل بكثير مع الحفاظ على الحماية داخل العتاد. يقسم معالج إيتانيوم فضاء العناوين المؤلف من 64 بتًا إلى 8 مناطق كما هو موضَّح في الشكل السابق. تحتوي كل عملية على ثمانية مسجلات مناطق بحجم 24 بتًا بوصفها جزءًا من حالتها، ويحتوي كل منها على معرّف منطقة Region ID -أو RID اختصارًا- لكل منطقة من المناطق الثمانية الخاصة بفضاء عناوين العملية. تُوسَم ترجمات مخزن TLB بمعرّف RID، وبالتالي لن تتطابق إلا إذا احتوت العملية على معرّف RID نفسه كما هو موضَّح في الشكل التالي:

رسم توضيحي لترجمة مخزن TLB في معالج إيتانيوم

لا تُحتسَب البتات الثلاثة الأولى (بتات المنطقة) في ترجمة العنوان الوهمي، لذلك إذا كانت هناك عمليتان تشتركان في معرّف RID أي تحتفظان بالقيمة نفسها في أحد مسجلات المنطقة الخاصة بهما، فسيكون لديهما اسم بديل لتلك المنطقة. إذا احتوت العملية A على معرّف RID قيمته 0x100 في مسجل المنطقة 3 واحتوت العملية B معرّف RID نفسه الذي قيمته 0x100 في مسجّل المنطقة 5، فستُسمَّى المنطقة 3 من العملية A باسم بديل هو process-B, region 5. تعني هذه المشاركة المحدودة أن كلتا العمليتين تتلقيان فوائد مدخلات مخزن TLB المشتركة دون الحاجة إلى منح إذن الوصول إلى كامل فضاء العناوين.

مفاتيح الحماية Protection Keys

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

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

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

أداة إيتانيوم العتادية للمرور على جدول الصفحات Itanium Hardware Page-Table Walker

يؤدي تبديل السياق إلى نظام التشغيل عند حل خطأ في مخزن TLB إلى إضافة عبء كبير إلى مسار معالجة الخطأ، إذ يواجه معالج إيتانيوم ذلك العبء من خلال السماح بخيار استخدام العتاد المُدمَج لقراءة جدول الصفحات وتحميل ترجمات الصفحة الوهمية إلى الصفحة الحقيقية في مخزن TLB تلقائيًا. تتجنب أداة المرور على جدول الصفحات العتادية Hardware Page-table Walker -أو HPW اختصارًا- عمليات الانتقال المكلفة إلى نظام التشغيل، ولكنه يتطلب أن تكون الترجمات بصيغة ثابتة ومناسبة للعتاد لتفهمه.

يُشار إلى أداة HPW الخاصة بمعالج إيتانيوم في توثيق إنتل على أنها أداة مُعمَّاة وهميًا للمرور على جدول الصفحات Virtually Hashed Page-table Walker أو VHPT walker اختصارًا. يمنح معالج إيتانيوم المطورين خيارين من تقديمات HPW الحصرية تبادليًا، إذ يعتمد أحدهما على جدول الصفحات الخطي الوهمي ويعتمد الآخر على جدول التعمية Hash Table.

تجدر الإشارة إلى أنه يمكن العمل بدون أداة عتادية للمرور على جدول الصفحات، حيث يحل نظام التشغيل كل خطأ TLB ويصبح المعالج معمارية محمَّلة برمجيًا، ولكن يُعَد تأثير تعطيل HPW على الأداء كبيرًا جدًا دون الحصول على أيّ فائدة.

جدول الصفحات الخطي الوهمي Virtual Linear Page-Table

يشار إلى تقديم جدول الصفحات الخطي الوهمي في التوثيقات على أنه الصيغة القصيرة لجدول الصفحات المُعمَّاة وهميًا Short Format Virtually Hashed Page-table -أو SF-VHPT اختصارًا، وهو نموذج HPW الافتراضي الذي يستخدمه لينكس على معالج إيتانيوم.

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

رسم توضيحي لجدول صفحات هرمي

يأخذ الجدول الخطي الذي حجمه 512 جيبي بايت GiB مع فضاء عناوين 64 بتًا ما مقداره 0.003% فقط من 16 إكسابايت المتاحة، وبالتالي يمكن إنشاء جدول صفحات خطي وهمي Virtual Linear Page-table -أو VLPT اختصارًا- في منطقة متجاورة من فضاء العناوين الوهمية.

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

تقديم جدول VHPT بصيغة قصيرة في معالج إيتانيوم

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

صيغ مدخلة PTE في معالج إيتانيوم

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

العيب الرئيسي هو أن جدول VLPT يتطلب الآن مدخلات مخزن TLB، مما يؤدي إلى زيادة الضغط عليه. يتطلب كل فضاء عناوين جدول صفحاتٍ خاص به، لذلك تصبح التكلفة أكبر كلما أصبح النظام أكثر نشاطًا، ولكن يجب أن تكون أيّ زيادة في أخطاء الوصول إلى مخزن TLB أكبر من الفائدة الحاصلة عند انخفاض تكاليف إعادة الملء من أداة المرور العتادية الفعالة. لاحظ أن الحالة السيئة يمكن أن تتخطى مدخلات بمقدارٍ يساوي نتيجة قسمة حجم الصفحة page_size على حجم الترجمة translation_size، مما يتسبب في حدوث أخطاء متداخلة ومتكررة، ولكنه يُعَد نمط وصول غير مُحتمَل.

تتوقع أداة المرور العتادية hardware walker أن تكون مدخلات الترجمة بصيغة معينة كما هو موضح على يسار الشكل السابق، حيث يتطلب جدول VLPT ترجمات بصيغة قصيرة مؤلَّفة من 8 بايتات. إذا استخدم نظام التشغيل جدول الصفحات الخاص به بوصفه دعمًا لجدول VLPT كما في الشكل "تقديم جدول VHPT بصيغة قصيرة في معالج إيتانيوم"، فيجب أن تستخدم هذه صيغة الترجمة القصيرة. تتجاهل المعمارية عددًا محدودًا من البتات في هذه الصيغة وبالتالي تكون متاحة لتستخدمها البرمجيات مع عدم احتمال حدوث تعديلات كبيرة.

يعتمد جدول الصفحات الخطي linear page-table على فكرة حجم الصفحة الثابت، ويُعَد دعم أحجام الصفحات المتعددة مشكلةً لأنه يعني أن ترجمة صفحة وهمية معينة لم تَعُد عند إزاحة ثابتة، ولكن يمكن حل هذه المشكلة من خلال احتواء كل منطقة من المناطق الثمانية في فضاء العناوين -كما هو موضّح في الشكل "رسم توضيحي للمناطق ومفاتيح الحماية في معالج إيتانيوم"- على جدول VLPT منفصل يربط عناوين تلك المنطقة فقط. يمكن إعطاء حجم الصفحة الوهمية لكل منطقة، حيث تُخصَّص منطقة واحدة لصفحات أكبر (باستخدام مخزن HugeTLB في لينكس) ولكن لا يمكن استخدام أحجام صفحات متعددة ضمن المنطقة الواحدة.

جدول التعمية الوهمي Virtual Hash Table

يمكن أن يكون استخدام مدخلات مخزن TLB لمحاولة تقليل تكاليف إعادة تعبئته -كما هو الحال مع جدول SF-VHPT- مقايضة فعّالة أو يمكن ألّا يكون كذلك. يطبّق معالج إيتانيوم جدول صفحات مُعمَّى hashed page-table مع إمكانية خفض تكاليف مخزن TLB، حيث يعمّي المعالج في هذا المخطط عنوانًا وهميًا للعثور على إزاحة في جدول مجاور.

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

تؤدي المعلومات الإضافية المطلوبة لكل مدخلة ترجمة إلى ظهور اسم بديل بصيغة جدول VHPT الطويلة -أو LF-VHPT اختصارًا. تنمو مدخلات الترجمة إلى 32 بايتًا كما هو موضح على الجانب الأيمن من الشكل "صيغ مدخلة PTE في معالج إيتانيوم".

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

تتمثل إحدى مزايا صيغة SF-VHPT في أن نظام التشغيل يمكنه الاحتفاظ بالترجمات في جدول صفحات هرمي، ويمكنه ربط الصفحات الورقية في هذه البنية الهرمية مباشرةً مع جدول VLPT مع الاحتفاظ بصيغة الترجمة العتادية. بينما يجب على نظام التشغيل باستخدام صيغة LF-VHPT إما استخدام جدول التعمية بوصفه مصدرًا أساسيًا لمدخلات الترجمة أو الاحتفاظ بجدول التعمية بوصفه ذاكرة مخبئية لمعلومات الترجمة الخاصة به. يُعَد الاحتفاظ بجدول التعمية بصيغة LF-VHPT بوصفه ذاكرة مخبئية دون المستوى الأمثل إلى حد ما بسبب زيادة الحِمل في مسارات الأخطاء الأساسية في الوقت المناسب، ولكن تُكتسَب الفوائد من الجدول الذي يتطلب مدخلة واحدة فقط في مخزن TLB.

ترجمة -وبتصرُّف- للقسمين Hardware Support و Hardware support for virtual memory من فصل Virtual Memory من كتاب Computer Science from the Bottom Up لصاحبه Ian Wienand.

اقرأ أيضًا

• المقال التالي: كيف تنشئ ملفا قابلا للتنفيذ Executable File من شيفرة برمجية مصدرية
• المقال السابق: دعم عتاد الحاسوب للذاكرة الوهمية &nbsp;Virtual Memory
• نظرة عميقة على تسلسل الذواكر الهرمي والذاكرة المخبئية في معمارية الحاسوب
• تعرف على نظام العد الثنائي Binary أساس الحوسبة