تطوير الويب

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

تعريفنا لتطوير الويب

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

ستة قرارات داخل أي مشروع ويب

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

استراتيجية التصيير: متى تولد كل صفحة

الخيارات ثلاثة. في التوليد الساكن تبنى الصفحة وقت الترجمة، وإذا كانت مجموعة العناوين معروفة فهذا أسرع الطرق وأرخصها. وفي التصيير على الخادم تبنى الصفحة عند كل طلب، وهو ما يحتاجه المحتوى الخاص بكل مستخدم أو الدائم التغير. وفي التوليد التدريجي تبقى الصفحة ساكنة وتحدث حين يتغير محتواها. والتفصيل المهم في الثالث: ينبغي ربط التحديث بحدث لا بمؤقت زمني. وفي الموقع الذي تقرأونه يسقط كل حفظ في لوحة الإدارة وسم التخزين المؤقت الموافق له وحده، فلا حاجة إلى إعادة بناء. وأرشيف موقع bebekistiyorum.com المؤلف من 66 مقالة طبية ومئات صفحات الفيديو وملفات الأخصائيين ينشر على منصة تعتمد قاعدة MongoDB ويجري تصييرها على الخادم بواسطة Next.js App Router وReact Server Components معا.

مؤشرات Core Web Vitals والقياس من المستخدمين الحقيقيين

درجة المختبر وبيانات الميدان ليستا شيئا واحدا: فأداة Lighthouse تقيس جهازا واحدا وملف اتصال واحدا وذاكرة مؤقتة فارغة، أما البيانات التي تستعملها Google فتأتي من متصفحات الزوار الحقيقيين. ولهذا لا نسلم درجة خضراء، بل نتابع ثلاثة مؤشرات ميدانية: زمن رسم أكبر عنصر في الصفحة، والتأخر بين تفاعل المستخدم والرسم التالي، ومقدار ما يتزحزح به التخطيط أثناء الزيارة. والأشياء التي تفسد هذه الثلاثة قليلة معروفة: صور تقدم بلا أبعاد، وخطوط تصل متأخرة، وحزمة JavaScript أكبر مما تحتاجه الصفحة، وشيفرة تقيس عنصرا بعد تركيبه ثم تغير نمطه في الحال. والأخيرة تجبر المتصفح على حساب تخطيط متزامن، ولذلك جعلنا قاعدة في الصفحات التي يراها الزائر أن يؤخذ القياس من نداء ResizeObserver نفسه. وقد كان أداء الهاتف من المشكلات المعروفة في النسخة القديمة من موقع bebekistiyorum.com، وجرى في المنصة الجديدة عمل على الأداء يرتكز على مؤشرات Core Web Vitals الميدانية.

سلامة الأنواع مع TypeScript واستدامة الشيفرة

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

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

تعدد اللغات ليس مسألة ملف ترجمة بل مسألة عناوين وتخطيط. فلكل لغة عنوانها، وتعلن الصلة بين النسخ لمحركات البحث بوسم hreflang، وينبغي أن تكون مقاطع المسار نفسها قابلة للترجمة. وفي الموقع الذي تقرأونه يتوطن العنوان نفسه: الصفحة الواحدة تسكن تحت hizmetlerimiz بالتركية وتحت услуги بالروسية وتحت خدماتنا بالعربية. واللغات التي تكتب من اليمين إلى اليسار تضيف طبقة ثانية. فالعربية تقلب أكثر من اتجاه النص: تنعكس معها الهوامش واتجاه الأيقونات ومحاذاة النماذج، وإن بنيتم ذلك على «يمين» و«يسار» بدل خصائص CSS المنطقية كتبتم كل مكون مرتين. وموقع bebekistiyorum.com ينشر بالتركية والإنجليزية والروسية والعربية، وصممت مكوناته كلها في النسخة العربية لتعمل من اليمين إلى اليسار. وقد جمعنا أكثر الأخطاء تكرارا في ملاحظاتنا عن التوطين.

إدارة المحتوى واستقلال المحرر

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

الترحيل وحفظ قيمة العناوين

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

أول ما ننظر فيه في المشاريع التي نتسلمها

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

كيف توضع ميزانية الأداء

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

سؤال من سيدير الموقع

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

خمسة بنود في حزمة التسليم

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

كل هذا في مشروع واحد

أكثر القرارات المذكورة في هذه الصفحة تجتمع في مشروع واحد: موقع bebekistiyorum.com التابع لمركز Eurofertil لأطفال الأنابيب انتقل من بنية ASP.NET WebForms القديمة إلى منصة Next.js بأربع لغات. والبنود الخمسة الأولى مما يلي مكتوبة في صفحة المشروع نفسه، أما السادس فهو الموقع الذي تقرأونه.

• التصيير والبيانات: منصة تعتمد قاعدة MongoDB ويجري تصييرها على الخادم بواسطة Next.js App Router وReact Server Components معا.
• الترحيل: أكثر من 1200 عنوان من الموقع القديم قوبلت ببنية المعلومات الجديدة وحفظت بطبقة تحويلات 301 قائمة على قاعدة بيانات.
• تعدد اللغات: نشر بالتركية والإنجليزية والروسية والعربية، وتصميم كل المكونات من اليمين إلى اليسار في العربية، وإعلان النسخ اللغوية بوسم hreflang لمحركات البحث.
• إدارة المحتوى: لوحة خاصة فيها محرر Tiptap واستيراد جماعي للمحتوى، وفريق المحتوى يدير الموقع كله بلا حاجة إلى رخصة CMS مدفوعة.
• السيو التقني: بيانات وصفية ديناميكية لكل صفحة، وخريطة موقع تلقائية، وبيانات منظمة بمعيار schema.org، وعمل على الأداء يرتكز على مؤشرات Core Web Vitals الميدانية.
• موقع detartech.com: البنية نفسها: إطار Next.js App Router وأربع لغات ومقاطع مسار متوطنة وتخطيط من اليمين إلى اليسار في العربية.