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

الصمت الزائد: دائماً يفضلوا الاستماع فقط بدون إبداء رأي أو تعليق.

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

عدم الوضوح: لما تسألهم سؤال مباشر، تحصل إجابات مختصرة وغالباً ما تكون غامضة أو مبهمة.

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

عدم الحماس: يظهر عليهم عدم الاهتمام أو الاكتراث لأي شيء، سواءً عن نفسك أو عن المستقبل.

أثر الغموضيين عليك:

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

يقللوا من مستوى الحماس أو الإيجابية في الجلسة.

أحياناً قد تشعر وكأنك تبذل مجهوداً كبيراً لتحريك الحديث أو النقاش.

كيف تتعامل معهم؟

حاول تستفسر بطريقة مهذبة ومباشرة عن وجهات نظرهم.

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

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

ستواجها بشكل كبير

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

الدرس؟
خلّي بيتك مكتفّي بخيره (High Cohesion)، وقلل علاقتك بالجيران قدر المستطاع (Weak Coupling)، عشان لو غيرت بيتك، ما تضطر تبني الحارة كلها من جديد. 🚀💡

تطبيق في البرمجة: لو عندك function، خليها مستقلة. كل اللي تحتاجه تمرّره كـ parameters أو يكون داخلها local variables. 🛠️ لو عندك class، ما تعتمد كثير على classes ثانية. اجعل الكلاس يؤدي وظيفة واضحة ومحددة. 🧩 لو عندك system، حاول تقلل الـ dependencies على الأنظمة الأخرى. 🌐 مبدأ الحياة ببساطة:

✨ "You must be high cohesion and loosely coupled!" 💪

أخي المبرمج، خليني أشرح لك العلاقة بين Domain-Driven Design (DDD) وClean Architecture بشكل عبقري ومش ممل، ولو كنت في مقيل مع أصحابك في اليمن، ما بتحتاج غير قهوة مُرّة وهذا الكلام الجميل!
القصة تبدأ من عند التعقيد:
في DDD، قالوا لك إن التعقيد في البرمجيات ينقسم لنوعين:
1️⃣ تعقيد أساسي/طبيعي (Essential Complexity):
هذا التعقيد جاي من طبيعة المجال اللي تشتغل عليه (Domain). يعني مثلاً لو تشتغل على نظام مستشفيات، بيجيك التعقيد من قوانين البزنس، مثل إدارة المرضى، أوقات الأطباء، والمواعيد... يعني وجع راس طبيعي يخص مجال العمل نفسه.
2️⃣ تعقيد صناعي/عرضي (Accidental Complexity):
هذا النوع ماله دخل بالبزنس. هو نتيجة اختيارك لتصميم غير جيد أو استخدام تقنيات معقدة بلا داعي. يعني أنت اللي "تطبخ التعقيد" بيدك في الكود 😅.
💡 DDD قالت لك نصيحة ذهبية:
"افصل بين التعقيدين دول يا بطل. لا تخلي التفاصيل التقنية (اللي تتغير) تلخبط فهمك للبزنس (اللي ثابت نسبياً)."
المشكلة: كيف ننفذ الفكرة؟
هنا DDD أعطتنا الفكرة، لكنها ما شرحت "الطبخة". فقام المطورين وقالوا:
1️⃣ خلينا نستخدم الـ Layered Architecture، بس بنقسم الطبقات بشكل أوضح كالتالي:
Domain: فيه القواعد والقوانين الخاصة بالبزنس.
Infrastructure: يتعامل مع قواعد البيانات أو الأمور التقنية المتغيرة.
Service: هو الوسيط بين البزنس والتقنية.
Presentation: واجهة المستخدم.
2️⃣ بعدها ظهرت تصاميم معمارية زي:
Hexagonal Architecture (الشكل السداسي).
Onion Architecture (شكل البصل).
وبعدين دخل العم بوب مارتن (Uncle Bob) بالساحة وقال:
"اسمعوا يا جماعة، أنا عندي اسم أفضل ورؤية أوضح: Clean Architecture."
وترك بصمته الذهبية، لما قال:
"لما تنظر للتطبيق، لازم يكون البزنس واضح وضوح الشمس. البنية التقنية الداخلية؟ خليها وراء الكواليس!"
التقاء الأفكار
كل هذه المعماريات تشترك في فكرتين رئيسيتين:
1️⃣ فصل البزنس عن التفاصيل التقنية:
وهذا بالضبط اللي نادت به DDD.
2️⃣ استخدام الـ Dependency Injection (DI):
كل شيء في طبقة الـ Domain يعتمد على واجهات (Interfaces)، والتفاصيل التقنية (مثل قواعد البيانات) يتم تطبيقها في طبقة الـ Infrastructure. والربط يتم باستخدام DI.
يعني لو بكرة حبيت تغيّر قاعدة البيانات أو تضيف تقنية جديدة، التطبيق بيظل سليم بدون ما ينكسر.
💡 الخلاصة:
DDD عطتك الفكرة، وClean Architecture نفذتها بشكل عبقري. النتيجة؟
بدل ما تغرق في "تعقيد صناعي"، صار البزنس واضح والبنية التقنية مرنة.
تخيل المشهد:
لا بصل يحرقك ولا سداسي يدوّخك، كل شيء مرتب وحلو، وكأنك تشرب قهوتك المرة في قمة جبل!
وآختمها بالنكتة:
اليوم مدرس العلوم قال:
"اللي ما يعرف عناصر الجدول الدوري ما يكلمنيش خالص."
وأنا أقولك:
"اللي ما يعرف DDD، ما يكلمنيش أصلاً!" 😅

وعاد في Architecture  يستخدم بكثره بذات في microservices  يسمى  vertical  slice Architecture    مرن جدا ومناسب ل في بعض micro خالي بالك ليست انك كيف تنظم الملفات لا غلط فادح موضوع موضوع فصل وتسهيل لعمليات الاختبارات وغيرها انتبه ان اعتقادك فقط كيف تنظم الملفات وأن المعماريات هذه هي كيف تنظم الملفات انتبه

عم الحج معي

تمام يا حبيب أخوك، خلينا نوضح نقطة مهمة جدًا عن Vertical Slice Architecture، خصوصًا في Microservices، وكيف إنها مش مجرد "طريقة لتنظيم الملفات". الموضوع أعمق من كذا بكثير. لو كنت فاكر إن المعماريات كلها بس مجرد تنظيم ملفات، فإنت بتختصر فكرة كبيرة جدًا بشكل خاطئ. 😅
إيش هي Vertical Slice Architecture؟
Vertical Slice Architecture تركّز على تقسيم التطبيق بناءً على الميزات أو الوظائف (Features) بدلًا من الطبقات التقليدية.
كل "شريحة عمودية" (Vertical Slice) تشمل كل ما تحتاجه لتنفيذ ميزة معينة، من البداية (API) للنهاية (قاعدة البيانات).
بمعنى آخر:
بدل ما تقول "عندي طبقة للعرض، طبقة للمنطق، وطبقة للبيانات"، تقول:
"عندي شريحة عمودية اسمها إضافة مستخدم، وشريحة أخرى اسمها إدارة الطلبات".
ليه Vertical Slice Architecture مرنة ومثالية للـ Microservices؟
فصل المسؤوليات بشكل كامل:
كل شريحة مستقلة بنفسها وتتعامل مع ميزة واحدة. هذا يجعل الكود خالي من التداخل.
سهولة الاختبار (Testing):
كل شريحة يمكن اختبارها كوحدة منفصلة (Unit Testing أو Integration Testing) دون التأثير على بقية التطبيق.
تحسين القابلية للتوسع (Scalability):
لو احتجت توسّع ميزة معينة، تشتغل فقط على شريحتها بدون لمس باقي النظام.
تنظيم يعتمد على الـ Domain:
بدل ما تفكر في كيف أنظم الملفات؟، تفكر في كيف أنظم الميزات بناءً على طبيعة التطبيق؟.
توافق تام مع DDD:
لأنه يعكس الفكرة الأساسية في DDD بفصل التعقيد الأساسي (Essential Complexity) عن التعقيد الصناعي (Accidental Complexity).
مغالطة تنظيم الملفات
خليني أوضحها بشيء من التفصيل:
Vertical Slice Architecture مش مجرد طريقة لتنظيم الملفات.
لو فكرت فيها كأنها "فين أحط الفولدر ده؟"، فأنت ما فهمت الفكرة.
هي بالأصح منهجية كاملة لتصميم التطبيق بحيث كل شريحة تمثل مسار مستقل من العمل (Workflow).
الملفات قد تكون جزء صغير جدًا من التنفيذ، لكن الجوهر الحقيقي هو الفصل بين الشرائح بناءً على الوظائف والتدفق الوظيفي (Workflow).
كيف تنفذ Vertical Slice Architecture؟
كل شريحة هي وحدة متكاملة:
تحتوي على:
Endpoint/API أو Command/Query لتفعيلها.
منطق العمل (Business Logic).
وصول البيانات (Data Access).
كل هذا مدمج مع بعضه لشريحة معينة.
استخدام تقنيات CQRS:
عادةً يتم استخدام CQRS (Command Query Responsibility Segregation) مع Vertical Slice، حيث تكون الأوامر والاستعلامات مفصولة لكل شريحة.
مثال بسيط:
لو عندك ميزة اسمها "إضافة مستخدم"، الشريحة العمودية قد تحتوي:
ملف Command: مسؤول عن تنفيذ العملية.
ملف Handler: يحتوي منطق العمل الخاص بالعملية.
ملف Data Access: يتعامل مع قاعدة البيانات.
توضيح بأمثلة بسيطة
الطريقة التقليدية (Layered Architecture):
Controllers/ UserController.cs Services/ UserService.cs Repositories/ UserRepository.cs
Vertical Slice Architecture:
Features/ AddUser/ AddUserCommand.cs AddUserHandler.cs AddUserValidator.cs
الخلاصة
Vertical Slice Architecture مبنية على فصل المسؤوليات وتبسيط التطبيق من خلال تقسيمه بناءً على الوظائف بدلًا من الطبقات.
فهمك لهذا النمط كـ "طريقة لتنظيم الملفات" يعتبر خطأ فادح، لأن المعمارية تهدف لجعل الكود أكثر قابلية للتطوير، الفهم، والاختبار، وليس فقط ترتيب الملفات في الفولدرات.
ركز دائمًا على المفهوم الأساسي:

"كيف أفصل الوظائف في التطبيق بشكل يسهل العمل عليها مستقلًا عن بقية الأجزاء؟"

ختامًا، إذا كنت في مقيل مع أصحابك، قل لهم:
"لو ما تعرفش Vertical Slice Architecture، خلّيك في الكبسة وما تدخل في النقاش!" 😅

🛑🚦 مفقودات

العلاقات بين الكائنات: كيف تحوّل الكود إلى قصة؟
دعني أخبرك سرًا صغيرًا، العلاقات بين الكائنات في البرمجة تشبه العلاقات البشرية تمامًا. هناك تواصل مؤقت، وهناك صداقات طويلة الأمد، وهناك علاقات لا تنفصم أبدًا. والآن، لنضع هذا في سياق البرمجة الكائنية بأسلوب جديد يجعلك تشعر بأنك تحكي قصة حياتك!
1. Association (علاقة التعارف العابرة):
تخيّل أنك تتعرف على شخص في رحلة قصيرة، تتعاونان لإنجاز مهمة، ثم تودّعانه إلى الأبد.
هذه العلاقة البسيطة هي مثلما يحدث في البرمجة عندما "يتفاعل كائنان دون التزام مستقبلي".
🔹 مثال من الحياة البرمجية:
في نظام حجوزات السفر:
العميل (Customer) يتواصل مع الحجز (Booking) لإتمام عملية الحجز، لكن كلًّا منهما يمكن أن يستمر بدون الآخر.
🔑 النصيحة: استخدم Association عندما تحتاج إلى علاقة عابرة بدون مسؤوليات طويلة المدى.
2. Aggregation (علاقة "الاحتفاظ بالمسافة"):
تصوّر أن لديك مكتبة ضخمة مليئة بالكتب. يمكنك تغيير أو إزالة الكتب دون أن تتأثر المكتبة نفسها. هذه العلاقة هي "صداقات مرنة".
🔹 مثال من الحياة البرمجية:
في نظام المدارس:
المدرسة (School) تحتوي على مجموعة من المدرسين (Teachers)، لكن لو أُغلقت المدرسة، يمكن للمدرسين العمل في أماكن أخرى.
🔑 النصيحة: استخدم Aggregation عندما تحتاج إلى علاقة "has-a" مع استقلالية الطرفين.
3. Composition (علاقة "لا أستطيع العيش بدونك"):
تخيّل منزلك. إذا اختفى المنزل، ستختفي غرفه معه. إنها علاقة "حياة أو موت". الكائن الرئيسي يحدد مصير الكائن التابع.
🔹 مثال من الحياة البرمجية:
في نظام تصميم المنازل:
المنزل (House) يحتوي على غرف (Rooms). لو تم حذف المنزل، ستختفي الغرف تلقائيًا معه.
🔑 النصيحة: استخدم Composition عندما تكون دورة حياة الكائن التابع مرتبطة بالكامل بالكائن الرئيسي.
مفاجأة العلاقة المخفية:
هناك علاقة غير مكتوبة غالبًا ما نتجاهلها: علاقة التوازن.
عندما تبدأ في كتابة كودك، اسأل نفسك:
هل هذه العلاقة ضرورية أصلًا؟
ما تأثيرها على مرونة النظام؟
كيف ستؤثر على الاختبارات المستقبلية؟
نظرة جديدة على العلاقات:
لتجعل علاقاتك البرمجية مذهلة:
لا تجعل الكائنات "تتعلق ببعضها" أكثر مما يجب.
احترم دورة حياة كل كائن.
اكتب كودًا يحكي قصة منطقية، بحيث إذا قرأه شخص غريب عن المشروع، يستطيع فهمه كما لو كان يشاهد فيلمًا مشوقًا.
هل ترى كيف أصبحت العلاقات بين الكائنات لعبة فنية؟ اختر العلاقة المناسبة لتصميم كودك كأنك تختار شريك حياة!

نموذج 🛑🛑




العلاقات بين الكائنات: من الكود إلى الأبعاد الموازية
في عالم البرمجة الكائنية، تخيل أنك لست مبرمجًا، بل مهندسًا في محاكاة للأكوان. الكائنات ليست مجرد صفوف برمجية، بل هي عوالم متكاملة تربطها قوانين تشبه قوانين الفيزياء. اليوم، سأقدم لك العلاقات بين الكائنات كما لو كنت تكتب دستورًا لعالم موازٍ:
1. Association: الجسور بين الأكوان
تخيل أن الأكوان المختلفة يمكن أن تتواصل عبر جسور مؤقتة. الجسر ليس جزءًا من أي كون، لكنه وسيلة لمرور المعلومات.
🔹 التفسير البرمجي:
عندما يتفاعل كائنان دون أي التزام مستقبلي، فهذا جسر عابر بين الأكوان.
مثال:
العميل (Customer) يعبر الجسر للتواصل مع الحجز (Booking)، ثم يعود لعالمه الخاص.
🔑 القانون:
لا تترك الجسر مفتوحًا بعد انتهاء المهمة. حافظ على استقلالية الأكوان.
2. Aggregation: مدن تحت إدارة واحدة
تخيل مدنًا مستقلة، لكن لها حكومة مشتركة. الحكومة تستطيع إدارة المدن، لكن المدن تظل قائمة حتى لو انهارت الحكومة.
🔹 التفسير البرمجي:
عندما يحتوي كائن رئيسي على كائنات تابعة مستقلة عنه، يكون هذا اتحادًا إداريًا.
مثال:
المدرسة (School) تدير المدرسين (Teachers)، لكن المدرسين يظلون يعملون حتى لو اختفت المدرسة.
🔑 القانون:
اترك للمدن حريتها، ولا تفرض سيطرة مطلقة.
3. Composition: نظام الخلايا العضوية
تخيل كائنًا بيولوجيًا، حيث تكون الخلايا جزءًا لا يتجزأ من الجسم. إذا مات الجسم، تتحلل الخلايا تلقائيًا.
🔹 التفسير البرمجي:
عندما يكون الكائن التابع جزءًا لا يتجزأ من الكائن الرئيسي، فإنه يصبح جزءًا من دورة حياته.
مثال:
المنزل (House) يتكون من غرف (Rooms). إذا اختفى المنزل، تختفي الغرف.
🔑 القانون:
لا تفصل الخلايا عن الجسم، إلا إذا كنت تعيد بناء الكائن من جديد.
4. Inheritance: الجينات البرمجية
تخيل أنك تنشئ كائنًا يمكنه تمرير صفاته لأجيال قادمة. الوراثة هنا ليست مجرد انتقال للصفات، بل هي شكل من أشكال التطور.
🔹 التفسير البرمجي:
عندما يرث كائن صفات كائن آخر ويضيف عليها ميزاته الخاصة.
مثال:
المنتج الرقمي (DigitalProduct) يرث من المنتج الأساسي (Product) ويضيف ميزات التحميل.
🔑 القانون:
لا تنشئ شجرة جينية معقدة. حافظ على البساطة لتجنب الفوضى.
الختام: أنت خالق الأكوان البرمجية
في عام 2050، الكود ليس مجرد أداة، بل هو شكل من أشكال الفن والعلم معًا. عندما تصمم العلاقات بين الكائنات، فكر كأنك تبني عوالم متكاملة. كل قرار تتخذه هو قانون فيزيائي يؤثر على هذا العالم:
الجسور (Association) للتفاعل المؤقت.
المدن (Aggregation) للاستقلالية المنظمة.
الخلايا (Composition) للاندماج الكامل.
الجينات (Inheritance) للتطور المستمر.
تذكر، كودك ليس مجرد نص، بل كيان ينبض بالحياة!

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

١. تحقيق النتائج عبر الآخرين

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

٢. التخطيط وتقسيم المهام

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

٣. مهارة الإنصات

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

٤. التواصل بوضوح

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

٥. التنظيم وإدارة الوقت

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

إذا كنت باحثًا قدمت إسهامًا علميًا مميزًا في مجالات الطب والصحة أو الهندسة والتكنولوجيا أو العلوم الأساسية أو الإنسانية والاجتماعية أو المياه والطاقة والغذاء أو الاقتصاد والإدارة، فرصتك الآن لتتقدم لجائزة مؤسسة عبد الحميد شومان للباحثين العرب في دورتها الـ43 لعام 2025، بقيمة 20 ألف دولار!

📅 آخر موعد لتقديم الطلبات: 31 آذار 2025
🌐 اعرف المزيد وتقدّم الآن عبر: https://bit.ly/3L3lB8c

الجائزة التي تستحقها العقول النابغة، جائزة عبد الحميد شومان للباحثين العرب!

#جائزة_عبد_الحميد_شومان #الباحثين_العرب

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


و لا ننسَ أن نشكر د/مروة على مشاركتها الرابط و الفرصة لنا جميعًا 🥀✨.

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

1. شغال؟ خلّه بحاله!
"إذا هو شغال، ما له داعي تعدل فيه"، هذا كلام ما ينفع، لأن الكود إذا خليته بدون تحسين، مع الوقت يصبح كأنه جبل ما تقدر تحركه. اشتغل على تحسين الكود دايم، بس لا تعقد الأمور. 👌

2. لا تزيدها تعقيد (Overengineering)
لا تصمم حاجة كأنك بتبني مصنع وأنت شغلك بسيط. خلك على قد حاجتك، لا تحط أشياء فوق اللازم. السهالة زينة، والتعقيد ما منه إلا التعب. ✨

3. فلان قال! (Appeal to Authority)
لا تأخذ كلام مدير أو شيخ أو مبرمج كبير كأنه قرآن. شغل عقلك، وشوف إذا الكلام يناسب مشروعك أو لا. مش كل واحد يقول حاجة تكون صح. 🤔

4. القديم؟ أحيانًا ماهو زين (Appeal to Tradition)
لا تتمسك بالأدوات والأساليب القديمة وتقول "هذا اللي نعرفه". جرّب الجديد، بس بحساب، لا تخاطر على الفاضي. 🌟

5. الكود الكثير أحسن؟ لا يا شيخ!
الكود مش بالكيلو، الكود الزين هو اللي يكون واضح وقليل. لا تعقد نفسك وتكتب رواية، اكتب كود على قد الحاجة. ✍️

6. السوبر مبرمج (Hero Programmer)
لا تعتمد على شخص واحد يشيل الشغل كله. شغل الفريق أهم، وإذا المبرمج السوبر مشى أو مرض، ما أحد بيدري كيف تشتغل الأمور. 💪

7. لا تكابر (Denial of Problem)
لو عندك مشكلة، لا تقول "ما في شي". واجهها من البداية حتى ما تكبر وتخرب عليك الشغل بعدين. المشاكل مثل النار، إذا ما طفيتها بدري، تحرق كل شي. 🚨

8. الحل السحري (Silver Bullet)
لا تصدق إنه في أداة أو تقنية وحدة بتحل كل شي. كل مشروع وله حاجته، استخدم الشي المناسب في مكانه. 🧰

9. كود يغطي الدنيا؟ ليش؟ (Overgeneralization)
لا تصمم كود يعالج كل شيء وأنت بس تحتاج حاجة بسيطة. اشتغل على المطلوب الآن، وخلي الكود جاهز للتوسيع إذا احتجت في المستقبل. 🛠️

10. التمسك بالكود القديم (Legacy Code Attachment)
إذا الكود قديم وما له داعي، لا تخاف تحذفه. نظف كودك، وحط مكانه شيء أزين. الكود النظيف يسهّل حياتك وحياة اللي بيجي يشتغل بعدك. 🧹

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

#عاشت_الصقور 👨‍💻

الان tailwindcss الاصدار 4 جاهز و stable 🔥

المقال الرسمي:
https://tailwindcss.com/blog/tailwindcss-v4

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

#وظيفة في شركة Venus في صنعاء

Senior PHP - Laravel Developer


https://www.facebook.com/photo/?fbid=1167389928727524&set=pcb.1167393982060452

🛑🛑🛑 هااام 🛑🛑🛑


مطلوب شخص فاهم ERP بس تمام لوظيفة شاغرة، الذي يشوف نفسه قد الفرصة ال CV فضلا @ahmed_jalalCS

|￣￣￣￣￣￣￣￣￣￣￣￣|
| Open-source ≠ Free |
|＿＿＿＿＿＿＿＿＿＿＿＿|
\ (•◡•) /
\ /
——
| |
_| |_

قطرة عرق في التدريب تغنيك عن أنهار من الدماء في المعركة!"
هذه المقولة تنطبق تماماً على الوقت الذي يقضيه الفريق في جمع المتطلبات من العميل. أي وقت الفريق يقضيه في فهم البيزنس بعمق، وضبط الفلو بحيث يتماشى مع احتياجات العميل، وطرح كل الأسئلة الممكنة للنقاش مع العميل، هذا مش وقت ضايع إطلاقاً! بل استثمار ذكي يحميك من إنك تطلع بمنتج ما يطابق اللي كان العميل يريده أو يتوقعه. سواء لأنك ما سألت العميل، أو لأن العميل نفسه ما كان يعرف يوضح احتياجاته بشكل واضح.
دورك هنا إنك تسأل، تخلي العميل يفكر، وتساعده يوصف احتياجاته. لأنه ببساطة، لو ما فيش أسئلة، ما فيش إجابات! 😌
وهذا بالمناسبة مش دور الـ Business Analyst فقط، بل مسؤولية كل الفريق. سواء كنت فرونت إند أو باك إند، كل شخص عنده منظور مختلف، وهذه الرؤية تضيف نقاط قيمة للنقاش.
وأنا سامع حد يقول: "إحنا نشتغل أجايل، والتعديلات بسيطة." 👍 تمام، التعديلات بتكون سهلة إذا كانت بصفحة أو اثنتين، أو في ميزة بسيطة. لكن لما التعديلات تضرب في صلب المشروع (زي الـ Data Model أو الـ Business Logic)، هنا تصير الأمور معقدة جدًا، وتؤثر على الهيكل بالكامل.
كلما كان فهم البيزنس واضح من البداية:
الداتا مودل بيُبنى مضبوط.
الـ UI بيكون سلس وسهل.
المشروع بيكون مستقر وقابل للتطوير بشكل أكبر.
وإياك تنسى: فهمك الواضح للبيزنس مش بس يبني مشروع ناجح، بل يبني ثقة العميل فيك وفي فريقك. 🔥