تخاريف مبرمج

لما بقعد اتناقش مع CHATGPT or Claude في ال architecture الخاص باي مشروع بشتغل عليه آخرها كان product lens يبقي open source يقدر اي مشروع يستخدمه اتكلمنا في تفاصيل كتير جدا ومناقشات علي مستوي ال architecture وال layers وخلافه وهل محتاجين نعمل كل حاجه from scratch ولا نستخدم حاجات موجودة تناسب ال requirements اللي عندنا وهو اقترح شويه github links لمشاريع اقدر استفيد منها في ال RAG Pipeline وبصيت علي كل مشروع وعرفت فايدته ايه وقولتله اقترح علي استخدم ايه هو اقترح حاجة مش افضل شى مناسب فقولتله لا واقترحت عليه repo معين وخليته يراجع القرار بتاعه بناء علي شوية trade-offs criteria حددناها وكان الاختيار اللي قولتله عليه كان افضلهم وبعدين اتكلمنا ورسمنا ال architecture اللي تناسب ال mvp بال features اللي هنطلعها يمكن كانت مناقشة تقترب من الساعه بالظبط او اقل بس كان فيها تفاصيل كتير وخليته يرسم ال architecture بكل تفاصيلها وبعد كده كانت اهم نقطه هي دي لان اكيد كل الحوار اللي اتناقشنا فيه هيتنسي قولتله اكتب كل المناقشات دي بتفاصيلها اللي بيني وبينك بحيث لما اديها لاي ai model يكون فاهم هنعمل ايه وليه وايه ال features اللي هنعملها بال architecture كامل في ملف md ده كان غرضه حاجتين 1. عشان انا اراجع كل حاجه تاني 2. عشان لو هتناقش مع ai model تاني يكون عنده كل حاجه من الاول واضحه بكل شي مش محتاج تعمل نفس المناقشه من جديد وساعتها تقدر تعمل ال product بتاعك الملف ده من اهم الملفات اللي محتاج تعملها عشان تتعلم منها في اي حاجه بتعملها دمتم بخير

شباب كتير اللهم بارك بيبعتلي عشان Consultation sessions وللاسف اشتراك لينكدان premium انتهي فكل ال requests اللي بتيجي بشوفها متأخر جدا فاي حد من الشباب محتاج Consultant session يتواصل مباشرة DM علي لينكدان مباشرة * ----------------------- * بالنسبه لل Connection Requests انا فعليا مش عارف اعمل accept وغالبا بسبب المشكله الخاصه بالوصول الي 30 الف Connection او عشان الاشتراك انتهي فللاسف مش عارف اعمل accept فرجاء اعمل follow بدل ال connection request حاليا * --------------------- * بالنسبه لل arch wiki حقيقي اللهم بارك اكتر من حد عمل شير لل dashboard بعد استخدامها والشباب مبهور بيها جدا وراجعت المعلومات اللي طالعه منها معاهم بعد الإضافات اللي حصلت امبارح وده يمكن اول repo يعدي اكتر من 100 🌟 علي ال github وحقيقي مبسوط بده جدا وان ال Skill فعلا تبقي مفيدة لكل المشاريع واي فيدباك مرحبا بيه اكيد للتطوير واي issue ياريت اتبلغ بيها عشان نصلحها اول بأول * ------------------------ * لنك ال github في اول كومنت فضلا وليس أمرا اعمل star 🌟 علي ال repo دمتم بخير

في حد من الشباب جرب ال arch wiki علي المشروع بتاعه وما شاء الله منبهر بيها جدا 👏👏👏👏👏

بعد ما وصلنا بفضل الله لـ 117 🌟 علي الـ repo فده شجعني ان اكمل في مشروع الـ arch-wiki من فترة كنت اشتغلت على arch-wiki وكانت الفكرة إننا نعمل Architecture Documentation للمشاريع بشكل Automatic وفي نفس الوقت تكون مفيدة للـ Developers والـ AI Tools النهارده عملنا شوية Updates جديدة وحاجات مهمة اتضافت بناء علي الفيدباك اللي وصلنا وان شاءالله تبقي مفيدة 1. الـ Prerequisites & Setup Pipeline. دلوقتي الـ arch-wiki تقدر تستخرج الـ Requirements اللي المشروع محتاجها عشان يشتغل زي Java / Node.js / Python، Docke، Databases والـ External Services وكمان بتطلع خطوات الـ Setup والتشغيل وده مفيد جدا في موضوع الـ Developer Onboarding بدل ما الـ Developer الجديد يدخل المشروع ويبدأ يسأل: أثبت إيه؟ أشغل إيه؟ أبدأ منين؟ جزء كبير من الكلام ده يبقى موجود في الـ Documentation نفسها. 2. الحاجة التانية كانت الـ PDF Export وبالتالي الـ PDF يطلع شامل الـ Architecture Documentation كاملة. 3. وكمان أضفنا Zoom In / Zoom Out / Reset والـ Grab Cursor للـ Architecture وDocker Diagrams وده هيفرق جدا مع المشاريع الكبيرة اللي الـ Diagrams بتاعتها بتبقى معقدة ومليانة Components 4. وكمان اتعمل شوية Improvements للـ Swagger UI والـ Dark Mode لأن الهدف من arch-wiki مش إننا نعمل Documentation شكلها حلو وخلاص الفكرة إننا نعمل Architecture Map للمشروع تكون مفيدة للـ Developers وفي نفس الوقت AI Friendly بدل ما الـ AI Agent يدخل على Project كبير ويبدأ يقرأ مئات الملفات عشان يفهم الـ Architecture، يقدر يبدأ من "architecture.json" فيها معلومات عن الـ Modules والـ Endpoints والـ Database والـ Security والـ Dependencies وغيرها يعني بدل ما الـ AI يبدأ من الـ Code عشان يفهم الـ Architecture يبدأ من الـ Architecture نفسها. وده ممكن يوفر وقت وTokens بشكل كبير والهدف في النهاية إن الـ Documentation تبقى Living Documentation مش ملف بيتكتب أول المشروع وبعد كده محدش يبص عليه. لينك الـ repo https://github.com/ahmedemad3/arch-wiki فضلا وليس أمرا اعمل star 🌟 لل repo دمتم بخير

بالنسبه لموضوع الخطوط والباكبورت اللي اتفتح والكوارث اللي في الشركات والمسخرة اللي بتحصل ويعني ايه اشترى خطوط بصور بطايق بتاعة ناس تانيه طبعا الناس اللي سرقت صور البطايق والناس اللي اشترتهم دول المفروض يتحبسوا وش والشركات الاتصالات تتدفع تعويضات وغرامات غصب عن اللي خلفوهم واللي جابهوم عشان شركات وسخه من الاخر وعارفين الفساد وعايشين فيه طب عشان نحل الموضوع ده نعمل ايه اولا اي واحد بيشترى اي خط جديد ومعندوش خط مسبق لو اكبر من 16 سنه واقل من 21 سنه فطبعا مفيش حل غير البطاقة ده رقم واحد مع صورة بطاقة الوالد ثانيا اي حد هيشترى رقم تاني لابد من التاكد من البطاقه والتأكد انه عنده رقم سابق بنفس الاسم يبقي ساعتها يتم ارسال otp علي رقمه السابق والتأكيد من خلاله انه هيشترى خط جديد وده مش هينفع يطبق علي شركة واحدة لا التاكد من الرقم السابق في ال ٣ شركات طب عنده اكتر من رقم سابق يتم اختيار رقم منهم وارسال ال otp ليه مع إرسال رسالة فورية على كل الأرقام المسجلة باسم الشخص عند إصدار أي خط جديد مثلا تم تسجيل رقم جديد باسمك إذا لم تكن أنت اتصل فورا بخدمة العملاء أو ألغِ العمليه طبعا لو من الاول عندنا هوية رقميه فعلا مكناش وصلنا للعك ده دمتم بخير

في المنتورشيب عندنا في الشهر التاني بيكون فيه آخر Task في جزء الـ Database وهو إننا نعمل Database Optimization للـ Queries اللي اشتغلنا عليها طول الشهر بس قبل ما نبدأ الـ Optimization بيكون عندنا خطوة مهمة جدا إننا نملي الـ Database بحجم Data كبير الهدف مش مجرد إنك تعرف تعمل Insert لملايين الـ Records الهدف الحقيقي إنك تكسر رهبة التعامل مع الداتا الكبيرة في المنتورشيب حجم الداتا بيوصل لـ 50 مليون Record عشان لما تشوف 5 أو 10 مليون بعد كده متحسش إن الموضوع مرعب أو أول مرة تشوفه النهارده واحد من الشباب اللي معانا كان عنده Task على الـ Production والداتا حوالي 10 مليون Record وكان مطلوب منه يعمل Query Optimization لعدد من الـ Queries طبعا هو مينفعش ياخد نسخة من Database الـ Production فكان لازم يعمل Simulation عنده على بيئة الـ Testing بنفس السيناريو الجميل في الموضوع إن الأسئلة اللي كان بيسألها كانت مختلفة وطريقة التفكير كانت مختلفة والأهم إنه مكانش قلقان هو عارف هيبدأ منين وهيشتغل إزاي وهيقيس الـ Performance بإيه وده بصراحة بسطني جدا لأن الـ Case دي ناس كتير بتستغرب إنها بتتعمل أصلا بحجة إن مفيش وقت أو إن الشركات مبتعملهاش مع إن من وجهة نظري دي من أهم الحاجات اللي لازم تتعمل قبل أول Release يطلع Production على الأقل من الـ Development Team والـ QA Team عشان تقلل مشاكل أول 6 شهور وبعد كده تتكرر بشكل دوري كل فترة تخيل بقى لو أول مرة تشوف موقف زي ده وهو على الـ Production - هتفكر إزاي؟ - وهتبدأ منين؟ - وهتبقى واثق في قرارك قد إيه؟ وده السبب اللي بيخليني دايما مركز في المنتورشيب على الـ Cases العملية كل الـ Cases اللي بنشتغل عليها جاية من مشاريع حقيقية اشتغلنا عليها وحتى المواقف اللي بحكيها أثناء الشرح الهدف منها نقل الخبرة العملية مش مجرد شرح تكنيكال وخلاص إن شاء الله هعلن عن فتح الحجز للباتش الجديد في منتصف شهر أغسطس دمتم بخير.

بصراحة السوق بقى أصعب من أي وقت فات للأسف في شركات كتير خصوصا في الشرق الأوسط بقت شايفة إن طالما فيه AI Tools يبقى مفيش داعي تدفع مرتبات كبيرة، ونجيب أي حد يمشي الدنيا لكن الحقيقة إن الموضوع مش بالبساطة دي في أوروبا لسه في شركات كتير بتدور على الشخص اللي عنده خبرة حقيقية وفي نفس الوقت بيعرف يستخدم الـ AI صح ليه؟ لأن الخبرة هي اللي بتفرق الشخص اللي عنده خبرة هو اللي يعرف يعمل Architecture صح ويسأل الأسئلة الصح ويطلع Solution مناسب ويستخدم الـ AI عشان يسرع شغله ويطلع كود بجودة عالية وهو كمان اللي يقدر يبني Skills أو Agentic Systems تنجز مشاريع كاملة طبعا هتلاقي برضه شركات بتسترخص هناك لكن ده موجود في أي مكان لو عايز يبقى ليك Value حقيقية في السوق متقفش عند مجال واحد لو شغال Backend اتعلم Front End وخد فكرة كويسة عن Mobile وافهم AI لو Front End افهم Backend واتعلم AI لو Mobile افهم Backend وخد فكرة عن Front End وAI الفكرة مش إنك تبقى خبير في كل حاجة لكن يبقى عندك خبرة قوية في تخصصك ومعاها فهم كويس لباقي المجالات يخليك تقدر تبني Product كامل وكمان لازم يبقى عندك أساس قوي في Architecture وSystem Design لأن دول بقوا من أهم المهارات لأي Senior أو Staff أو Architect أما بالنسبة للـ Juniors ركز الأول إنك تبقى قوي جدا في مجال واحد وبعدها ابدأ اتوسع واحدة واحدة متحاولش تتعلم كل حاجة في نفس الوقت لو بصيت للكلام ده كله هتلاقي إن السوق ماشي ناحية شخصية اسمها Product Engineer أو Full Stack Engineer شخص يقدر يبني المنتج من أول الفكرة لحد المنتج ويستفيد من الـ AI بدل ما يستبدله وفي الآخر افتكر إن الـ AI مش هيعوض الخبرة كل ما كانت خبرتك أكبر وأسئلتك أفضل وفهمك للـ Architecture أعمق كل ما هتاخد نتائج أقوى بكتير من أي AI Tool وبالمناسبة الشباب اللي شغالين Front End هسيبلكم في أول كومنت Playlist ممتازة جدا للـ Front End System Design وأنصح أي حد يشوفها. دمتم بخير

Free kimi 3 https://www.tokenrouter.com/?fbclid=Iwb21leATYdyZjbGNrBNh3G3Bkb2YBZXh0bgNhZW0CMTEAc3J0YwZhcHBfaWQMMzUwNjg1NTMxNzI4AAEeEfzW14Iqf_U9VnmPsfXV5RGmHL2hnap20d8ljVSsdNlpJfdX7RNS99itaOU_aem_K9sFmz_UKen-pS-sJektag

الفكرة دي بقالها كام يوم شاغلة دماغي كل الناس دلوقتي بتتكلم عن AI Agents Backend Agent Frontend Agent DevOps Agent UI Agent Architecture Agent وكل ما عدد الـ Agents يزيد الناس تحس انها خلاص عملت كل حاجة بس وأنا بفكر حسيت إننا ممكن نكون بنحل المشكلة من الاتجاه الغلط بقي عندنا كمية agents كتير وكل مرة ببدا من الصفر أنا ليه أصلا محتاج Backend Agent يفكر هيعمل Payment إزاي؟ وليه محتاج Architecture Agent يقرر Database Design كل مرة؟ وليه محتاج DevOps Agent يعيد كتابة الـ CI/CD من الصفر؟ ليه كل مشروع يبدأ من أول السطر؟ طب ما أعملش Payment Component مرة واحدة؟ بس مش Component فيها Code لا Component فيها كل الـ Knowledge الخاصة بالـ Payment فيها Business Rules فيها Architecture فيها Database Desig فيها APIs فيها Events فيها Security فيها Testing فيها Observability فيها Deployment فيها Documentation فيها ADRs وفيها الـ Trade offs وليه اخترنا كل قرار يعني بدل ما أقول للـ AI اعمل Payment Service أقوله استخدم Payment Component v1.2 والـ AI شغله الوحيد إنه ينفذ المعرفة الموجودة جوه الـ Component مش يخترعها من جديد ساعتها بقى تخيل الموضوع هيبقي عامل ازاي مثال مثلا تقولهاعمل E Commerce يرد عليك محتاج الـ Components دي Authentication Catalog Inventory Cart Payment Order Notification Search Observability CI/CD ويبدأ يركبهم مع بعض عن طريق Orchestrator زي الل Lego طب ولو اكتشف إن فيه Component ناقصة يروح يبنيها مرة واحدة ويحفظها في الـ Registry وبعد كده أي مشروع تاني يعيد استخدامها كل مشروع بعد كده هيبقى بيستفيد من الخبرة اللي اتجمعت في المشاريع اللي قبله وقتها إحنا مش بنبني AI Developers ولا حتى AI Software Engineers إحنا بنبني Architecture Knowledge Platform منصة المعرفة فيها أهم من الكود نفسه لأن الكود بيتولد في دقائق لكن القرارات الهندسية الصح هي اللي بتاخد سنين من الخبرة حاسس إن الاتجاه ده ممكن يكون مستقبل بناء السوفت وير مع الـ AI وإننا هنبدأ نفكر في إعادة استخدام المعرفة الهندسية، مش إعادة استخدام الكود فقط. إيه رأيكم؟ هل مستقبل الـ AI هيكون في زيادة عدد الـ Agents ولا في بناء Components ذكية مليانة Knowledge والـ Agents مجرد منفذين؟ بالنسبة لي ده اتجاه أقوى بكتير من فكرة إن كل Agent يبدأ يفكر من الصفر في كل مشروع محتاج اسمع ارائكم في الفكرة نفسها واشوف تعليقاتكم في الكومنتات دمتم بخير

ازيكم يا شباب اخباركم ايه حد جرب Arch Wiki ال skill اللي بتعمل documentation للمشاريع لو حد جربها يقولي feedback

من يومين نزلت ال Arch Wiki Skill وكان الهدف الأساسي منها إنها تساعد أي حد يدخل Project جديد أو حتى Project قديم مفيهوش Documentation محترمة إنه يفهم الدنيا أسرع بدل ما يقعد أيام بيدور ويسأل من أكتر الحاجات اللي بتضيع وقت أي Software Engineer هي إنه يفهم ال Architecture بتاعة المشروع خصوصا إن في مشاريع كتير جدا مفيهاش أي Documentation تشرح هي ماشية إزاي ومن هنا جات فكرة Feature من أهم الـ Features الموجودة في ال Skill ببساطة أغلب المشاريع دلوقتي بيكون فيها Docker Compose أو Dockerfile فليه منستغلش ده ونحوله بشكل تلقائي إلى Architecture Diagram يوضح مكونات المشروع وعلاقة الخدمات ببعض أكيد وارد يبقى في نسبة أخطاء لكن في النهاية هيديك تصور سريع جدا عن شكل ال Architecture بدل ما تبدأ من الصفر ولو المشروع مفيهوش Docker أصلا فال Skill بتولد Architecture Diagram استرشادي مبني على فكرة الـ 3 Tier Architecture بحيث يبقى عندك نقطة بداية تساعدك تفهم المشروع وتبني عليها الفكرة كلها مبنية على البساطة وسرعة الفهم لأن الهدف مش إنه يستبدل التفكير أو المراجعة لكن يوفر عليك وقت كبير في بداية أي Project مستني منكم تجربوا ال Skill وياريت تشاركوني أي Feedback أو أفكار للتطوير لأن لسه في Features كتير نفسي أضيفها. ولو ال Repo عجبكم فضلا وليس أمرا اعملوا له Star وجربوا ال Skill لينك ال Repo موجود في الكومنتات دمتم بخير

عشان كده بنقول ذاكر

AI Engineer, System design patterns for AI LLM, RAG , AGENTS

🔥🔥🔥🔥🔥

اتهريت أسئلة كتير بخصوص الـ Skill اللي نزلتها امبارح الخاصة بالـ Arch Wiki وما شاء الله في أقل من 24 ساعة وصلت لـ 62 Star، اللهم بارك جالي أسئلة عن الـ Governance وأسئلة عن الـ Security وأسئلة عن استهلاك الـ Tokens وأسئلة تانية كتير الحقيقة فخليني أوضح الفكرة اللي كانت في دماغي من البداية أنا مكنش هدفي أعمل Tool معقدة أو AI Agent أو RAG أو Chat مع الكود، لأن ده موجود بالفعل وفيه أدوات كتير بتعمله بشكل ممتاز كان هدفي أبسط من كده بكتير كنت عايز Skill بسيطة جدا، ليها شوية Guidelines واضحة وتطلع Output ثابت تقدر تعتمد عليه طول عمر المشروع - Skill تساعد أي حد يدخل مشروع جديد يعمل - Onboarding بسرعة، وتبقى وسيلة كويسة للـ - Knowledge Sharing بين أفراد التيم، وفي نفس الوقت متبقاش بتستهلك أي Tokens ولا تطلع الكود بره الشركة وبالتالي مفيش مشاكل Security أو Governance الفكرة ببساطة إن كل Skill بيبقى ليها Description واضح ومعاها شوية Templates وReferences عشان تقدر تطلع Output معين الـ Output ده بالنسبالي عبارة عن Dashboard صغيرة حتى لو Offline Dashboard تخليني أشوف شكل الـ Modules أو الـ Infrastructure أو الـ SQL Queries الموجودة في المشروع وأفهم المشروع متقسم إزاي وليه كنت عايز لما يجيني مشروع جديد أو أرجع أشتغل على Module مفتحتهاش من شهور، ألاقي Roadmap بسيطة قدامي أعرف عندي كام Module و كل Module فيها كام Endpoint الموديول دي مسؤولة عن إيه وأبدأ أفهم المشروع بسرعة بدل ما أقضي ساعات بلف وسط الكود عشان كده جربت الـ Skill على اكتر من مشروع من GitHub وكل مرة كنت بعدل فيها وأحسنها. وجربتها على مشاريع: - Node.js - Spring Boot - Python ولسه شغال على دعم باقي اللغات لأن الفكرة كلها Framework Agnostic. اللي بيحصل ببساطة إن فيه Script مكتوب بـ Python بيشتغل Offline على الـ Codebase ويقرأ المشروع بناء على الـ Skill Guidelines وبعدها يطلع ملفين 1. JSON File 2. HTML File الـ JSON بيكون عبارة عن Map للمشروع كله وبمجرد ما الـ JSON يتبني بشكل صحيح بيتولد منه الـ HTML Dashboard ولو المشروع اتغير، كل اللي عليك تشغل الـ Skill تاني فيتحدث الـ JSON ويتبني الـ HTML من جديد ببساطة كده بقي عندك Documentation وKnowledge Sharing بين أفراد التيم بدون أي مجهود إضافي ودي مجرد البداية فيه أفكار كتير جدا ممكن تتضاف للـ Skill مع الوقت لكن كان بالنسبة لي مهم إن النسخة الأولى تكون Simple وسريعة وتشتغل Offline بالكامل بدون أي استهلاك للـ AI أو الـ Tokens مع الحفاظ على الـ Security والـ Governance الخاصة بالكود لو جربتوا الـ Skill ياريت تشاركوني الـ Feedback ولو حد عنده فكرة تطوير أو Feature جديدة هيكون سعيد جدا بأي Contribution على الـ Repo رابط ال skill في اول كومنت دمتم بخير

أنا شايف إن واحدة من أكبر المشاكل اللي ظهرت بعد انتشار الـ AI في البرمجة إن الكود بقى بيتكتب أسرع بكتير من الـ Documentation. كل يوم Module جديد ، Endpoint جديدة ، SQL Query جديدة، Permission جديدة. وبعد أسبوع تيجي تسأل الـ AI اشرحلي Architecture المشروع تلاقيه يبدأ يقرأ مئات الملفات عشان يفهم المشروع، ويستهلك كمية Tokens ضخمة، وأوقات يديك إجابة ناقصة لأنه مش شاف كل حاجة. ومن هنا جات فكرة Arch Wiki ك Skill الفكرة مش إنك تولد Documentation وخلاص الفكرة إن يبقى عندك Living Architecture دايما متزامنة مع الكود كل ما تضيف Endpoint أو Module أو Docker Service أو Permission أو SQL Query تشغل Skill واحدة وهي تعمل الباقي تعمل Scan للكود تحدث architecture.json وتولد Dashboard تفاعلية فيها كل حاجة. بس اللي كنت حريص عليه وأنا ببنيها كان حاجتين. - Simplicity. مش محتاج Config معقد ولا Setup طويل ولا تكتب Documentation بإيدك. وفي نفس الوقت تكون Framework Agnostic سواء شغال بـ Spring Boot أو NestJS أو Express أو FastAPI أو Django أو Laravel أو أي Framework تاني الفكرة هي نفسها. وكمان كنت مهتم جدا إن التنقل بين الـ Modules يبقى سريع وواضح، بحيث تقدر توصل لأي Endpoint أو SQL Query أو Permission أو Service في ثواني بدل ما تفضل تلف في المشروع. بدل ما تفتح عشرات الملفات يبقى عندك مكان واحد فيه كل الـ API Modules والـ Endpoints. - System Architecture Diagram. - Docker Topology. - SQL Queries. - Permissions و RBAC - Core Layers. - Request Pipeline. - Infrastructure. بس بالنسبة لي أهم جزء مش الـ HTML ، أهم جزء هو architecture.json لأن الملف ده معمول أساسا للـ AI. بدل ما الـ AI يلف على الريبو كله ويقرأ Controllers وRepositories وRoutes وDocker وSwagger بيقرأ File واحدة فيها خريطة المشروع بالكامل وده معناه عدد أقل من الـ Tokens فهم أسرع للمشروع وتعديلات أدق لأن الـ AI عارف يروح لأي File مباشرة بدل ما يعمل Search في الريبو كله. وفيه فايدة تانية بشوفها أهم من كده كمان - Onboarding. أي Developer جديد يدخل المشروع مش هيقعد أسبوع أو اتنين يحاول يفهم السيستم من الكود هيفتح الـ Dashboard ويشوف Architecture المشروع، الـ Modules، الـ Data Flow، والـ Request Pipeline، ويبدأ يفهم الصورة الكبيرة بسرعة. ونفس الكلام داخل التيم بدل ما كل شوية حد يسأل: الـ Endpoint دي فين؟ مين بيستخدم الـ Service دي؟ الـ Permission دي بتتطبق فين؟ المعلومة موجودة في مكان واحد، ومحدثة تلقائيا وده بيخلي الـ Knowledge Sharing بين أفراد التيم أسهل بكتير، ويخلي المعرفة تبقى ملك للفريق كله، مش موجودة في دماغ شخص أو اتنين. أنا مقتنع إن مع الوقت أي مشروع هيحتاج نوعين من الـ Documentation. 1. Documentation للبشر 2. Documentation للـ AI ولو الاتنين مش متزامنين مع الكود فبعد كام Sprint هيبقوا Outdated وده كان السبب الرئيسي اللي خلاني أعمل Arch Wiki لنك ال github repo في الكومنتات ، فضلا وليس امرا اعمل star 🌟 وشير للبوست محتاج منكم فيدباك عن ال skill نفسها دمتم بخير

ده يا شباب اللى طلعته حرفيا من مشروع قديم - محتاج رايكم