سألت قبل فترة عن وقت الشروع في تعلم إطار عمل. طرحت السؤال على عدة منصات، على حسوب آي أو، ومجموعة Elzero Web School في فيس بوك، وعلى تويتر..
كان هذا نص سؤالي الذي اختصر في تويتر مع نفس المضمون:
السؤال:
[للنقاش] ما الوقت المناسب للانتقال لتعلم إطار عمل؟
هناك مدرستان في تناول هذه القضية:
الأولى: بتعلم إطار العمل بأسرع ما يمكن لأنه يوفر الوقت والجهد وهو مطلوب في أي شركة أو عمل حقيقي.
والثانية تدعو للتمهل؛ لأنه بحسبها تعلم الأساسيات جيدًا يمكنك من الاستثمار الطويل لمهارتك وستستطيع الانتقال لأي إطار عمل بسهولة وأنت راسخ في الأساسيات وستكون مبرمجًا جيدًا على المدى الطويل..
ما رأيك؟ هل كان لك تجربة في هذا ولك كلمة قد تساعد أحدهم؟
ما المتطلبات للانتقال لتعلم إطار عمل ولنقل Laravel، تعلم مبادئ البرمجة الكائنية OOP والانتقال مباشرة، أم بحاجة تعلم أنماط التصميم Design Pattern وبناء مشاريع سابقة وبناء إطار عمل مصغر من عمل يدك؟
انتهى السؤال.
وكانت هذه الإجابات.. الإجابات في فيس بوك كانت من زملائي وأصدقائي الجامعيين. أما إجابات تويتر وحسوب فكانت من أصدقاء افتراضيين على الويب العربي.. أعدت صياغة بعض الإجابات إذا ورد فيها كلام باللهجة المحلية وحتى تناسب المقال، وكل هذا حتى تعم الفائدة..
إذا كان أحد الذين نقلت إجابتهم لا يرغب بظهور إجابته في التدوينة فسأحذفها..
**في مجموعة Elzero Web School على فيس بوك: **
** أجاب Ibrahim Hanash:**
"تعلم ال mvc
وال oop
ثم الانتقال ال laravel"
** وأجاب فياض المطلس:**
"أنا مع الرأي الأول أنك تتعلم الإطار على طول [بسرعة] وبعدين لو في أساسيات تحتاجها لأي شيء آخر بتأخذها لأنه غالبا ما بتحتاج لكل التفاصيل في الأساسيات
ولو كل واحد انتظر لتعلم كل الأساسيات فيمكن أن تظهر تقنية جديد".
أما Ammar Hassan فقد كتب إجابة تفصيلية وتجربة ملهمة:
" الخلاصة:
1- إذا كانت نيّتك تعلم الاطار لعمل مواقع بسيطة تكسب منها ربح مادي اعتيادي فعليك بتعلم الإطار مباشرة، لعدم وجود التعقيدات التي تمنعك من إنهاء برمجة المواقع بأسرع ما يمكن، حتى إذا واجهت أخطاء ستبحث وتحصل على الإجابة وتنسخ ولصق بدون ما تعرف ما الذي يحصل حقًا.
2- أما إذا كانت نيتك تعلم الإطار من أجل بناء أنظمة كبيرة ومحترمة، وتكون عارفًا بما يحدث في الإطار نفسه، وقتها إياك ثم إياك ثم إياك أن تدخل في الاطار مباشرة؛ لأن كمية الأخطاء والمصطلحات والمفاهيم التي ستواجهك ستصيبك بالجنون. وكلما بحثت عن مفهوم ستجده مرتبطًا بعدّة مفاهيم أخرى ووقتها سيضيع وقت كثير مثلما حصل لي بالضبط."
يواصل Ammar Hassan سرد تجربته:
"بالبداية، طُلب مني أن أنشئ موقعًا. تعلّمت الإطار وأتممت الموقع وكان سريعًا ورائعًا ومنظمًا. وقتها أحببت إطار لارافيل بشدة.
بعد فترة، طُلب مني برمجة نظام متكامل. بدأت وكنت أصل لأخطاء محاولًا حلّها لأكثر من خمس ساعات! ويظهر بعد ذلك أن حلها بمجرد سطر واحد فقط! لماذا؟ لأنني قفزت من فوق الأساسيات إلى الإطار مباشرة.
المهم أنني انتهيت من النظام بعد عناء كبير وحالات وصلت إلى العقدة من إطار العمل (لارافيل) مع أنه جميل جدًا. ومن وقتها قررت الرجوع للأساسيات. تصدق هذا؟ رجعت لأساسيات البرمجة الكائنية وغيرها. ضاع وقت كثير جدًا في ملاحقة أخطاء كان الأصل ألا يضيع فيها وقت من الأساس.
لذلك إذا كنت تنوي الدخول وتعلم أطر العمل وأن تعرف ماذا يعمل الناس يلزمك أن تكون ملمًّا بهذه المفاهيم على الأقل:
1- أن تكون قويًا بالبرمجة الكائنية.
2- برمجة الـ PHP Packages، هذه بذاتها ستدخلك لمفهوم composer.
3- تفهم Dependency Injection.
4- تفهم Containers.
5- تفهم كيفية التعامل مع مختلف الـ Http request.
6- تأخذ نظرة على أنماط التصميم (Design pattern).
7- تأخذ نظرة على Tests and PHP Unit.
8- تأخذ نظرة على PHP template.
9- تفهم في الـ Code Style Guide. مثل الـ PSR.
ويحبذ بعد أن تتعلم هذه المفاهيم أن تبني مشروعًا متكاملًا بها بدون عمل جاهز، وأن تبني إطار عمل MVC مصغر.
بعدها ستخدل لإطار العمل وعندك ثقة لتعلمه بسهولة، وستكون عندك القدرة والإمكانية أن تضي أو تعدّل عليه. حتى الأخطاء الي ستظهر لك ستقدر أن تتعامل معها."
يواصل Ammar Hassan:
"أنا بهذه الفترة رجعت لمراجعة الأساسيات. بعد فترة سنة ونصف من البرمجة بإطار عمل لارافيل.
هذي تجربتي بالتفصيل :).
إن شاء الله أكون أفدتك ولو بالشيء القليل."
وهذه ملاحظة أخيرة من Ammar Hassan:
"ليست أغلب الأنظمة الكبيرة، بل جميعها لا يبنى إلا بآلية معينة مثل آلية MVC، من أجل ترتيب العمل، وتعرف المداخل والمخارج جيدًا. وبدون إطارات العمل سيكون تطوير الأنظمة كالجحيم بصراحة. وهذا ما لاحظته في مشاريعي السابقة والمشاريع التي بنيتها بإطار عمل. لذلك تعلم الاطار صار واجبًا."
محمد ال شايع:
"تعلم ال OOP وال MVC والانتقال مباشرة إلى Laravel لا داعي لبناء فريمورك من الصفر".
**و Hassan Kuraimi: **
"الخلاصة:
إطار العلم يصلح لمشاريع التي يقال عنها أنها متوسطة، في حالة دخولك في مشاريع مؤسسات (enterprise)، ستحتاج إلى ما هو أوسع من إطر العمل، ما لا يقدر توفيره لك لا Laravel ولا غيره من أطر العمل. بل وربما يكون إطار عمل مثل Laravel مثل أداة Utility إذا عملت في مشاريع ضخمة ومؤسسية. ستحتاج إلى معرفة عميقة بلغة البرمجة نفسها وأنماط التصميم (Design Pattern) وهو الذي سيكون أحد الأعمدة الرئيسية في عملك كنمط Dependency Injection وغيرها من الأنماط المساعدة.
باختصار:
أن تكون لك خلفية عميقة في البرمجة، وهياكل البيانات، والخوارزميات، وأنماط التصميم، أفضل بكثير من معرفتك بإطار العمل مثلما قلت في الأنظمة المؤسسية، وهو ما سيضطرك لبناء إطار عمل خاص حسب النظام الذي تعمل به".
وفي تويتر كانت الإجابات كالتالي:
أجابني خالد العفان بكلمة واحد فقط: "الآن".
فرد عليه Moheb Rofail بقوله: "البارحة".
**Moaath Alattas | معاذ العطاس: **
"إذا كان بإمكانك البرمجة باللغة انطلق بالإطار المناسب لك. التطبيق العملي أسهل وسيلة للتعلم."
**وأجاب لطيف: **
"شخصياً؛ الحاجة الماسة لتجنب إعادة اختراع العجلة وعادةً ما أبدأ بأبسطها .. "
فرددت عليه: "تقصد البدء بأبسط إطار عمل؟"
فقال: "تماماً، طالما أنه يسهل عملي وبذات الوقت تعلمه لا يشتتني عن هدفي.
كثرة الميزات في إطار العمل ليست دائماً شيئاً إيجابياً. إذ أنها غالباً ماتزيد التعقيد."
وأضاف: "مثالي المفضل هو مكتبة سبارك جافا لبناء خوادم http، إذ أنها بسيطة وسريعة الاستخدام وبديهية مقارنة بضخامة Spring مثلاً. صحيح أن الأخير أشمل وأعم ولكن لم أحتج يوماً له بفضل سبارك جافا
وكانت إجابة Riadh Felhi:
"تعلم أساسيات اللغة ثم مر مباشرة لإطار العمل، حتى تربح الوقت".
وكذلك إجابة Omar al-Majedi:
"بعد تعلّم لغة وعمل بعض المشاريع بها وبعدها الانتقال إلى إطار عمل والمواصلة فيه".
وأخيرًا -في تويتر- أجاب Tareef Mando:
"كما أجاب البقية بعد تعلم اللغة وإنجاز بعض المشاريع بها، ثم يبقى بين كل حين وآخر تعود للغة وتنمي نفسك بها أكثر. أيضا اختيار أبسط أطر العمل بداية طالما أنه لا يوجد دافع لما هو أعقد وأكبر".
وكانت إجابات الأصدقاء على حسوب io كالتالي:
** Samy Massoud: **
"من حصيلة تجاربي الشخصية، الأشخاص الذين تمهلوا وتعلموا كل شيء أولا ثم انتقلوا إلي أطر العمل بعد ذلك لديهم فهم أعمق للمشاكل وتفادي إنتاجها في برمجياتهم، فمثلا هناك فارق بين الشخص الذي يعلم كيف تعمل الجلسات session وأين يتم تخزينها وأشهر مشاكلها وكيفية حلها من الشخص الذي يستخدم مكتبة للقيام بكل الأمور المرتبطة بالجلسات دون فهمها، فالشخص الأول عند حدوث مشكلة في إطار العمل نفسه يسبب سقوط الجلسات سيكون الأقدر علي معالجة الأمر عن فهم وبشكل صحيح، بينما الشخص الثاني ربما ينتهي به الأمر بنسخ بعض الأكواد والممارسات غير الصحيحة لعلاج المشكلة دون فهم."
**مضحي Modhy: **
"دائماً العجلة في أمور العلوم لا تأتي بخير أو بالأحرى يخرج لنا شخص مشوه علمياً لا يعلم كيف تُدار الامور بالخلفية، لذلك الأفضل والأحسن هو التمهل في التعلم وعدم التعجل حتى تتركز الاساسيات في المُتعلم وترسخ عنده مفاهيم البرمجة الاساسية ومن ثم يكون الانتقال سهل ومرن ولا يواجه صعوبات في فهم المكتبات واطر العمل.
في الغالب لن تجد الكثير من الناس يصبرون على بدايات التعلم والرسوخ فيه، فتجد الاكثرية يتعجل في الانتقال الى أطر العمل أو يكون هناك سبب آخر وهو لقمة العيش."
Mohammad Atwi:
"بحسب تجربتي، لم يعجبني استخدام إطار عمل (للبرمجة) وشعرت أنه محدود. لذلك، وبحسب تجربتي الخاصة، الأفضل هو بناء إطار عمل خاص بك. وهذا ما فعلته وتمكنت من خلاله بناء مواقع ضخمة ومعقدة وأنا أستخدمه وأطوره من حوالي ثلاث سنوات إلى الآن. الجميل في الأمر أن جميع برامجك ستكون متشابهة بحيث تستطيع نسخ sub-systems كاملة من مشروع إلى آخر بدون أي مشاكل. كما أنها أكثر أماناً (إذا كنت تعرف بالطبع أسس الحماية). فإطار العمل الخاص بي مثلاً يملك خاصيات عديدة فقط للحماية وأخرى لل logging وأخرى لتسريع عملية التعامل مع قاعدة البيانات وغيرها."
"بالنسبة لموضوع أنه مطلوب للعمل فبالطبع هذه نقطة قوة لإطارات العمل الموجودة حالياً، ولكن من الأفضل عدم التخلي عن طريقتك الخاصة في التطوير والاعتماد بشكل كامل على إطارات العمل. وبما أنك ذكرت PHP يمكنك معرفة رأي موجد هذه اللغة بإطارات العمل من خلال هذا الفيديو" [في هذا الفيديو يتحدث مبرمج PHP عن انزعاجه من أطر العمل].
رددت عليه "طبعا، كلام مؤسس اللغة البرمجية لن يكون دقيقا، لأنه (يفهم) كل شيء في اللغة، ولكن هذا لن ينطبق على مبرمجين (مساكين) مثلي.. وفي الأخير تحدّث هو عن أطر العمل على أنها سيئة لكن لا يمكن تجاوزها فهي حقيقة موجودة في سوق البرمجيات.."
فرد عليّ محمد عطوي:
"هو ركز على فكرة أساسية هي مشكلة الإعتماد على إطار العمل وحده لأنه سيسبب مشاكل في المستقبل خاصة مشكلة التطوير المستمر. لذلك لا يجب أن يدخل المبرمج في دوامة الـ plugins والمكتبات العشوائية لأن برنامجه سيكبر ويتعقد بشكل كبير لدرجة يصعب بعدها التعامل مع التطويرات المستقبلية وهذا ما رأيته بنفسي في برنامج كان حجمه حوالي 700 mb لمشروع متوسط التعقيد مبني على إطار Laravel وعند فحصه تبين أن المبرمجين الذي بنوه كانوا يستخدمون مكتبات بشكل عشوائي وغير منطقي حتى لأبسط الأمور .. تخيل أن هناك أكثر من 100 مكتبة وإضافة تم استخدامها .. وتخيل كم من ثغرات أمنية ستوجد في هذه الإضافات ناهيك عن عدم إمكانية التعديل على هذه الإضافات وتطويرها بسبب تعقيدها واعتمادها هي ذاتها على إضافات أخرى أيضاً! وهنا بدل أن يكون إطار العمل نعمة للمبرمجين الذين سيعملون على البرنامج من بعدهم ستكون هذه مشكلة كبيرة لأن المبرمج نفسه لا يعلم كيفية عمل الإضافات التي استخدمها. فهو فقط قام ب "تركيب" البرنامج حرفياً و ليس كتابته.
لذلك وبحسب فهمي لما قاله فإنه لا يجب الخوض في استخدام أطر العمل بشكل عشوائي بل بشكل عقلاني وبحسب الحاجة فقط بحيث لا يكون البرنامج عبارة عن كومة من الإضافات تم جمعها معاً لأنها ستجعل البرنامج أقل كفاءة وصعب التطوير."
**وأجاب Tarek Boublat: **
"لو أردت جواب مختصر سأقول من خلال تجربتي المتواضعة : يمكنك الإنتقال لاستعمال أطر العمل عندما ترى نفسك قادر على برمجة كل ما تريد بدون إطار عمل وبالتالي يمكنك البرمجة بنفسك في أي وقت والتخلي عنه لكن هذا بالنسبة لمن يريد وضع أساس قوي لمعرفته ومن يريد الإحتراف بأتم معنى الكلمة ورغم ذلك قد يكون البرمجة من خلال إطار العمل فقط ليس أمرا سيئا بالنسبة للهواة ومن يريدون برمجة أشياء بسيطة لربح الوقت."
**هذه كانت الإجابات.. **
وماذا عنّي؟
أنا الآن أتعلم دورة php فيها أساسيات وOOP وبناء مشروع بنمط MVC بدوت إطار عمل.. سأكملها وأنتقل لتعلم إطار عمل لارافيل إن شاء الله تعالى، مع العودة بين الحين والآخر لتعلم بعض المفاهيم التي تنقصني..
إضافة مهمة من المبرمج مدحت داود: هذا الفيديو فيه رؤية المبرمج مدحت عن هذا الموضوع ويركز أكثر على مطوري الواجهات.