بين الفكرة والبدء بالتكويد.. أسئلتي وإجابتهم

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

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

وهل هناك مسار (سريع) عندما يطرأ المشروع ومسار آخر (متمهل) لبناء مشاريع ممتازة؟

علمًا بأن مستوى المشاريع التي أتخيّلها هنا هي مشاريع (صغيرة-متوسطة) ولا مانع من ذكر نصائح معينة في المشاريع الكبيرة.»

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

سألت على عدة منصات، على حسوب آي أو، ومجموعة Elzero Web School في فيس بوك، وعلى تويتر وسألت كذلك في لينكدن وكوورا ومجموعة Mena Devs على Slack.

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

كل الإجابات تعود لأصحابها، وربما عدّلت بعض الصيغ لتناسب المقال ولكن المضمون نفسه. لم أختر كل الإجابات ولكن معظمها. وترجمت إجابات Mena Devs (بتصرّف) لأنها كتبت بالإنجليزية.

أكرر تنويهي: إذا كان أحد الذين نقلت إجابتهم لا يرغب بظهور إجابته أو اسمه في التدوينة فسأحذف الإجابة.

**إجابات لينكدن كانت كالتالي: **

أجاب صديقي Hamza Mughales:

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

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

وأنصحك وبشده تتابع حلقة "علاج المثالية - طلب الكمال" لـ علي وكتاب»

**وأجاب الصديق Mohammad Gharabat: **

«أعتقد ان ما تبحث عنه يمكنك ايجاده هنا: Agile Project Management Methodology»

أما في فيسبوك فحصلت على إجابة واحدة:

كانت الإجابة من الصديق Hassan Kuraimi:

«غالبًا، كلما ذكرته تجده مثلما قلت في سؤالك في كتب وكورسات لكن الفجوة الحقيقة أنها لا تُطبّق في الواقع العملي، بل وتعد أكاديمية. حسب اعتقادي من الممكن تطبيقها في مؤسسات عملاقة أما أغلب الشركات يتم تصميم وتطوير الصلاحيات وقواعد البيانات والكلاسات حسب ال task المقدمة وتساعدك منصات مثل ال Azure Repository و GitHub في عمليات ال merge ودمج المشاريع في حالة العمل ضمن فريق بهذه الآليات التي تعمل بها أغلب المؤسسات.»

وأضاف Hassan Kuraimi:

«أفضل الكتب في هذا المجال أو بالأحرى التي اطلعت عليها هي Clean Code و Adaptive Code: Agile Coding with Design Patterns and SOLID Principles.»

وفي تويتر كانت إجابات الأصدقاء:

**أجاب nabil lakrib: **

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

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

وواصل nabil lakrib:

«ثم أبدأ بتصميم قاعدة البيانات وكل العلاقات المطلوبة، وأفضل طريقة لمعرفة هيكلية قاعدة البيانات هي بسؤال "ما معنى (الشيء الذي تود صناعته)"، مثلًا: 

-  ما معنى "مستخدم" في تطبيقي؟

-  ما معنى أن يقوم المستخدم بشراء منتج مثلا؟

ثم تأتي مرحلة صناعة APIs (واجهات برمجية) لجعل backend يعمل مع frontend»

وأضاف:

«المرحلة الاخيرة هي ربط مكونات الواجهات (frontend)

وهي سهلة جدًا لأن التصميم المكتوب بHTML موجود. يحتاج فقط تقسيمه على شكل مكونات (component). وبعدها، كل component يعرف كيفية التعامل مع البيانات وكيف يتصل مع Backend»

وأجاب Riadh Felhi باختصار ودقة:

«إرم نفسك وسط المعركة وستتعلم في الطريق. إذا تعلّمت الأساسيات، أنجز مشاريع صغيرة وكل مرة أضف شيئًا جديدًا.»

وأجاب الأستاذ Ahmed Aljaberi:

«حاليًا، أنا استخدم الevent storming. إذا استطعت تحويل جميع الevents في نظام صار من السهل تحويلها لevents في الclasses ويصير عندي rich classes أضع فيها الconstraints وأستخدم مبادئ SOLID وأنماط التصميم(Design Patterns) ونمط CQRS  وأبني معمارية نظيفة  (clean architecture). المهم أن تفكر أكثر وقت التحليل وليس وقت البرمجة.

أغلب المبرمجين بسبب ال o/r mapping صاروا يبنون data model وليس domain model. البرمجة بالdata model مملة و ليست حتى OOP حقيقي. انس التفكير في الواجهات (UI) وقاعدة البيانات (DB)  وحتى المعمارية (Architecture)، هي للمتطلبات غير الوظيفية (non functional requirements). يعني تقدر تضيفها بعد ذلك. اعتمد فقط على الdomain core، الباقي تفاصيل تضيفها.»

وعندما سألته:

«شكرا جزيلا.. أود أن أسأل "هل هناك علافة لDomain Driven Design (DDD) بأنماط التصميم (Design Pattern) أم هي بديل عنها؟»

أجابني Ahmed Aljaberi:

«الdesign patterns هي لعلاقة الكلاسات مع بعضها لكن الDDD للنظام ككل و كيف تبنيه. الdesign pattern تدعمك في الDDD بالتأكيد وحقيقةأن 3 أو 4 أنماط (patterns). هي المهمة لكن من الضروري أنها تظهر في رأسك وقت التحليل و ليس أثناء الكود. انس الSOLID و الDesign Patterns الآن. الDDD فيها بعض الPatterns بالأصل.»

وأضاف:

«انظر إلى هذا Github DDD in PHP Blog CQRS 

وحاول تفهم الكود.

وهذا أيضًا من الممكن أن يفيدك من أجل أن تفهم المصطلحات PHP Domain Driven Design 2018 Tutorial with a Laravel Implementation 

ولأجل أن تصل لهذا اقرا عن الevent storming»

وفي حسوب IO حصلت على إجابتين:

الأولى إجابة تفصيلية رائعة من Mohammad Atwi:

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

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

لذلك الخطوات هي كالتالي:

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

• تخطيط وبناء قاعدة البيانات، على لوح أبيض -إن توفر- لربط الأفكار وعلى الورق كذلك.

• التخطيط لكيفية عمل الـ API. وهنا أعني ما هي الخصائص التي سوف:

    - تضيف / تعدل في قاعدة البيانات (Insert/Update).

    - جلب البيانات من قاعدة البيانات لعرضها (Get Data).

    - الأمور التي ستعمل في الخلفية مثل خصائص ضغط الصور، أي أعمال تلقائية، تسجيلات الحماية (Security Log).

     - نظام الصلاحيات - يجب أن يحدد سابقاً عند طرح الأفكار - أي كيف سيتم ترجمة نظام الصلاحيات برمجياً.

     - وغيرها من الأمور التي تريد لبرنامجك أي يقوم بها.

• يتم وضع الـ Requests كلها على مواقع مثل postman و trello وغيرها لكي يطلع عليها الفريق أو لكي تعرف جميع الطلبات التي ستستخدمها بدون عناء وبشكل منظم.

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

• يتم ربط البرنامج في النهاية ببعضه من خلال ال API والواجهات وسيكون لديك برنامج منظم ومؤرشف وقابل للتطوير بشكل مستمر.»

وأجابني Mahmoud A Rabo:

بما فحواة «أن ألتزم بالحد الأدنى من المشروع والذي يُسمّى  MVP.»

وفي كوورا: 

من عبدالهادي جعفر (Abdelhadi Djafer):

«ببساطة، تنقصك مقدمة حول علم "هندسة البرمجيات".

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

** فرددت عليه:**

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

فأجاب:

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

وأضاف Riadh Felhi:

«أضيف على إجابتك، هناك تخصص كامل هو تصميم البرامج لا أعلم بالضبط ترجمتها من اللغة الفرنسية conception يعتمد على ال UML فهناك فرق كبير بين المبرمج أو كاتب الأكواد و الشخص الذي يقوم بتصميم البرامج.»

فرد عليه عبدالهادي:

«نعم، هذا كله يندرج تحت Software Design و علم هندسة البرمجيات عموماً.»

وفي مجموعة Mena Devs على Slack

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

**أجابني terabithera: **

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

أخمّن أنك في مرحلة بين :"سيصبح العالم أفضل إذا كان المشروع (س) موجودًا وما زلت لم تكتب سطر كود واحد لتطوير هذا المشروع.

وأحب أن أقضي أسبوعًا/عدة أيام للتفكير فيما أريد أو التوقف عنه، تخيّل سير العمل (workflow)، وتخيّل كيفية عمل الأدوات مع بضعها البعض..إلخ.

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

أنا من المدرسة القديمة، لذلك فأنا أحب أن أشكّل الأشياء وأرسمها حتى قبل أن أكتب الكود. آخرون يفضلون القفز إلى التكويد مباشرة واكتشاف الأفكار أثناء كتابتهم للكود.»

** ثم أجاب Jad:**

«نصيحة عامة:

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

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

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

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

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

هذه نصيحة عامة.. 

والآن لنصيحة موجهة أكثر: اعملها بغباء (=لا تتذاكى في الكود كثيرًا)، نفّذ الكود، أصلحه وحسّنه باستمرار.»

**وأجاب Joe: **

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

وأجاب Jad مرة أخرى:

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

ورد terabithera:

«أختلف مع ما ذكره Jad مؤخرًا.. كلامه صحيح في حالة أن المشروع منتجًا ستبيعه وليس مشروعًا شخصيًا للتجربة والاستمتاع، وإذا كانت كذلك فحاول أن تكون ذكيًا قدر الإمكان ولا تتخذ المختصرات (الأدوات الجاهزة) بل تعلم أن تصنعها بنفسك لأن هذا ما سيفيدك حقًا. وبدون ذلك، لن تتحسن جودة الكود.»

وتساءل Joe:

«ما الذي تعنيه بالذكاء في حديثك؟»

فأجاب terabithera:

«الذكاء = يعني عمل الأشياء بنفسك بدلًا من استخدام الأدوات الجاهزة بدون حكمة.»

رد Joe:

«بم يختلف هذا عن "إعادة اختراع العجلة"؟»

فأجاب terabithera:

«أعني المراعاة في ذلك (استخدام الأدوات المعدة مسبقًا)، وهذا ما قد يؤدي لإلقاء العديد من الأدوات والأنماط بدون حكمة أو سبب وجيه لها.

وعلى سبيل المثال: في تقنيات  ‏‏‏‏ORM) Object Relational Mapping) والتي تعني تحويل أوامر قواعد البيانات إلى كائنات تتبع اللغة البرمجية أو إطار العمل، هذه التقنيات مفيدة، ولكن هل هي ضرورية دائمًا؟ إذا كنت تحتاج جدولًا واحدًا في قاعدة البيانات فتسطيع التعامل معه بدون ORM وبدون الحاجة لإدارة اعتمادياته.»

وأجاب HassanKanj:

«بناء على نوع سؤالك، لدي بعض الاقتراحات: 

• اشتر دفترًا وقلمًا، وضعهما في طاولتك. سيكونان أهم أدواتك لبناء أي مشروع، لأنهما يوفران المرونة والأهمية خلال السنوات على عكس بعض أطر جافاسكريبت التي تنتهي بليلة وضحاها.
• استخدم هذا الدفتر للتمثيل المرئي لنظامك وكيف يعمل وكيف ترتبط المكونات ببعضها البعض، ارسم فقط بطريقتك الخاصة، ولا حاجة لاستخدام أيًا من معايير UML أو غيرها. تستطيع رسم المستخدم على شكل ملصق على شكل رَجُل، واستخدم الأسهم والمستطيلات لبناء الروابط بين مختلف أجزاء النظام. [وأنا أفضل استخدام دفتر لأنه يشعرك أنه أكثر واقعية ويحفز مناطقًا مختلفة من دماغك عند استخدام القلم عوضًا عن لوحة المفاتيح، ولكن اختر ما يناسبك وبعد ذلك تستطيع نسخ وتنظيم ما رسمته على الورق إلى حاسوبك باستخدام الأداة التي تريد (Notepad, Textedit, Trello, xMind ..إلخ)].
• إذا كنت ستتدبّر واجهة الاستخدام وآلية سير العمل فيها، بعد إنهاء الخطوة السابقة (رسم النظام بالورقة والقلم  ونقل ذلك للحاسوب) ستحصل على فكرة مبدئية على كامل النظام. استخدم هذه المعرفة لكي ترسم على دفترك مختلف الصفحات/الواجهات وكيف سينتقل المستخدم/الزائر بين هذه الصفحات. مجددًا أفضل ذلك على الورقة والقلم، ثم نسخها أو إعادة رسمها في حاسوبك بالطريقة التي تفضلها للرجوع إليها لاحقًا.
• بعد ذلك، تستطيع أن تغوص أكثر في الجوانب التقنية وتحويل النظام السابق/الموقع إلى كيانات يفهمها الحاسوب (قاعدة بيانات بجداول وعلاقات بينها..إلخ).
• ضع في حسبانك دائما، أن العملية ليست خطية أو تتبع نموذج الشلاّل (Waterfall) الذي لا يمكن العودة للمراحل التي تخطيتها، ولكنها على العكس من ذلك، فأنت تحتاج للعودة إلى دفترك وتعديل بعض الجزئيات وتحسينها باستمرار. وضع في اعتبارك مقولة أن الخطط لا قيمة لها ولكن التخطيط (المستمر) هو المهم.
• الآن لنتحدث عن التكويد. ضع في اعتبارك أن الكود ليس دائمًا أهم الأجزاء في المشروع، وعلى الرغم من ذلك فهو يحتاج إلى مهارات عديدة، وقد يحتاج لسنوات حتى تتقنه في عملية لا تنتهي.. ولكن ما أقصده هو أنك تحتاج لمعرفة نظامك جيدًا قبل البدء بالتكويد. لا أحد سيأبه بكودك الخارق مهما كان آمنا وجميلًا ومنظّمًا إذا كان التنفيذ لمتطلبات خاطئة، أو تنفيذ خصائص لا أحد يحتاجها، وهذا هو الأسوأ (في حالة بناء منتجك بدون دراسة السوق على سبيل المثال).
• فيما يتعلق بكتب البرمجة، هي بالفعل مهمة ولكن حاول ألا تضيع في قراءة هذه الكتب أو في محاولة فهم كل أنماط التصميم الموجودة في البداية. أقترح عليك أن تبدأ بمشاريع صغيرة مثل برنامج قائمة مهام (to do list)، أو نظام بسيط يحتوي آلية تسجيل الدخول للمستخدمين. وتعلم من خلال التجربة، وفي نفس الوقت يمكنك قراءة كتاب واحد على الأكثر والاطلاع العشوائي على مشاريع مفتوحة المصدر على GitHub وقراءة أكواد لمشاريع عالية الجودة هناك. لا داعي لفهم كل سطر برمجي ولكن عمل ذلك سيمكنك من فهم طريقة تفكير عدة أنواع من المبرمجين وكيف يكتبون الكود. ومع مرور الزمن سيجعل هذا منك مطورًا أفضل غير متقيّد بنمط أو منهجية واحدة لحل المشاكل البرمجية، وسيساعدك هذا لمراجعة الكود الذي كتبته مراجعة أسهل في المستقبل وعند العمل مع الفريق.
• محرك جوجل هو صديقك، لذلك لا تقلق كثيرا على التفاصيل التقنية. تقريبًا لكل ما تريد تنفيذه ستجد مصدرًا على الويب يعلمك كيف تعمله، مع التوثيق (documentation) والمراجع، لذلك ركز على مهارات البحث لديك (أن تتعلم كيف تتعلم) وكيف تصل للمصادر بسهولة لحل المشاكل التي تواجهها وتعلم أن تقرأ التوثيقات/الأدلة (docs/manuals)، وهذا لا يعني مجرد النسخ واللصق عشوائيًا، ولكن يجب أن تنسّق المشروع كاملًا في وحدة متّسقة/متماسكة بدلًا من مجرد النسخ واللصق الذي لا معنى له.
• فيما يتعلق بأطر العمل، يعد Laravel إطار عمل جيد إذا كنت تستخدم PHP، ويمكنك استخدام أطر عمل مبنية على Python، و Node.js، وغيرها لعمل المواقع. ابدأ بما تعلمه واكتشف خيارات أخرى في وقت فراغك كذلك.
• وفيما بتعلق بمحررات النصوص فأنا أنصحك ب VS code.

بالتوفيق.»

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

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

إذا كان لديك اقتراح أو إجابة لا تتردد بكتابتها في التعليقات.