من أول سطر HTML إلى عقلية مهندس البرمجيات: كيف تغيرت نظرتي إلى البرمجة؟

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

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

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

لكن اللحظة التي أتذكرها جيدا كانت عندما اكتشفنا HTML.

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

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

من هنا بدأت أفكر جديا في دخول مجال تقنية المعلومات (Information Technology)، وقررت أن أتخصص فيه بعد تخرجي من الثانوية.

عندما اكتشفت أن البرمجة أكبر مما كنت أتخيل

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

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

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

مع مرور الوقت بدأت أكتشف عالما مختلفا تماما.

هناك تطوير الواجهات الأمامية (Frontend Development)، وتطوير الواجهات الخلفية (Backend Development)، ولغات مثل PHP، وأطر عمل مثل Laravel، وقواعد بيانات علائقية وغير علائقية، وواجهات برمجة التطبيقات (APIs)، وأنظمة المصادقة والصلاحيات (Authentication & Authorization)، ومفاهيم الحماية وتحسين الأداء.

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

والأهم من ذلك أن كل نظام له طبيعة ومتطلبات مختلفة؛ فطريقة بناء موقع تعريفي بسيط ليست كطريقة بناء منصة خدمية أو نظام إداري أو تطبيق يتعامل مع آلاف المستخدمين.

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

خطأ ارتكبته أثناء التعلم: مشاهدة الكورسات بدلا من فهمها

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

لا تجعل هدفك إنهاء الكورس، بل اجعل هدفك فهم ما تتعلمه والقدرة على استخدامه بنفسك.

وقعت في هذا الخطأ في بداياتي.

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

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

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

وعندما انتقلت إلى التطبيق الفعلي، اصطدمت بالواقع: معرفتي لم تكن كافية كما كنت أعتقد.

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

أصبحت أرى أن من أفضل طرق التعلم أن تسأل نفسك دائما:

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

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

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

أول مشروع جعلني أدرك حجم ما لا أعرفه

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

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

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

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

اضطررت إلى الرجوع والتعلم من الأساسيات: كيف تنظم البيانات؟ كيف تحفظ؟ كيف تسترجع؟ ما الفرق بين قواعد البيانات العلائقية (Relational Databases) وقواعد البيانات غير العلائقية (NoSQL)؟ وكيف تتعامل التطبيقات مع الخدمات السحابية؟

تعلمت أيضا أن Firebase ليست مجرد قاعدة بيانات واحدة؛ فهناك Cloud Firestore الذي يعتمد على المستندات والمجموعات، وهناك Realtime Database الذي يعتمد على بنية بيانات شجرية بصيغة JSON.

كانت تلك التجربة مهمة بالنسبة لي لأنها وضعتني أمام حقيقة لم أكن أفكر فيها من قبل:

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

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

ما الذي يجعل الشخص مهندس برمجيات حقيقيا في عصر الذكاء الاصطناعي؟

أعتقد أن هذا السؤال أصبح أكثر أهمية اليوم من أي وقت مضى.

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

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

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

لكن هل هذا يعني أن دور المطور أصبح أقل أهمية؟

لا أعتقد ذلك.

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

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

يجب أن تفهم طبيعة العمل نفسه:

• من المستخدمون الذين سيتعاملون مع النظام؟
• ما الصلاحيات التي يحتاجها كل مستخدم؟
• كيف تسير العمليات الإدارية داخل المؤسسة؟
• ما حجم البيانات المتوقع؟
• كم عدد المستخدمين الذين قد يتعاملون مع النظام في الوقت نفسه؟
• كيف يمكن تصميم بنية تتحمل زيادة الاستخدام مستقبلا؟
• ما الإجراءات اللازمة لحماية البيانات وضمان استقرار النظام؟

هنا تظهر أهمية مفاهيم مثل هندسة البرمجيات (Software Engineering)، وتصميم الأنظمة (System Design)، والمعمارية البرمجية (Software Architecture)، وقابلية التوسع (Scalability)، وتحسين الأداء (Performance Optimization)، والأمن السيبراني (Cybersecurity).

هذه ليست مجرد مصطلحات تقنية إضافية، بل قرارات تؤثر في نجاح النظام واستمراريته.

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

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

كثرة مصادر التعلم قد تكون أكبر عائق أمام المبتدئ

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

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

وهذا أمر إيجابي جدا، لكنه يحمل مشكلة أخرى، خصوصا للمبتدئين: التشتت.

قد يبدأ شخص بتعلم Laravel، ثم يسمع عن Node.js فينتقل إليه، وبعد ذلك يكتشف Django، ثم يبدأ بتعلم React، وبعد فترة يجد نفسه قد جرب تقنيات كثيرة دون أن يتمكن من بناء مشروع متكامل باستخدام أي منها.

برأيي، لا ينبغي للمبتدئ أن يقضي وقتا طويلا في البحث عن أفضل مصدر على الإطلاق.

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

أما بالنسبة إلى المطور الذي تجاوز مرحلة البدايات، فأرى أن تنظيم الوقت وترتيب الأولويات أمران أساسيان.

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

هذا المجال لا يتوقف عن التطور، لكن مواكبة كل جديد لا تعني أن تتعلم كل تقنية تظهر أمامك.

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

لو عدت إلى بداياتي، ماذا كنت سأغير؟

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

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

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

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

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

والثاني هو أنني كنت أتمنى أن أمنح هندسة الأنظمة (System Architecture) وتصميم البرمجيات اهتماما أكبر في وقت مبكر.

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

في النهاية: قيمة المطور ليست في عدد الأسطر التي يكتبها

اليوم أصبحت نظرتي إلى البرمجة مختلفة تماما عن بداياتي.

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

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

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

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

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

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

وهذا، في رأيي، أحد أجمل الأشياء في عالم البرمجيات.