System Design tips from mentors

سنة 1865، الاقتصادي William Stanley Jevons لاحظ حاجة مثيرة للاهتمام.

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

الفكرة دي اتعرفت بعد كده باسم Jevons Paradox.

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

بص على اللي حصل مع Cloud.

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

ودلوقتي، إحنا قدام تحول مشابه محتمل في صناعة الـ Software.

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

بس كل ما قدرتك على إنتاج الكود تزيد، بيظهر سؤال أهم:

مين هيحدد إحنا محتاجين نبني إيه أصلًا؟ ومين هيتأكد إن اللي بنبنيه صح، قابل للصيانة، ويستحمل التوسع؟

المستقبل مش مجرد إنك تعرف تكتب كود أسرع. المستقبل إنك تفهم إزاي تبني Software صح.

وده جزء أساسي من اللي بحاول أساعد الناس تفهمه في المينتورشب.

مش مجرد إنك تتعلم React أو Next.js أكتر، لكن إنك تطور طريقة تفكيرك، وتفهم القرارات الهندسية اللي ورا الكود، وتعرف تتعامل مع المشاكل اللي مفيش Tutorial جاهز يحلها.

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

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

السؤال مش بس: هل اAI هيكتب كود أكتر؟

السؤال: هل أنت بتبني خبرتك عشان تكتب الكود، ولا عشان تفهم الـ Software اللي بتبنيه؟

إزاي صفحة Next توصل فورا وجواها بيانات خاصة بالمستخدم؟

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

الـ Partial Prerendering بتدّيك الاتنين في صفحة واحدة.

وقت الـ Build، Next بتعدّي على شجرة الـ Components وتقرر مصير كل حتة:
\

• حاجة متخزنة بـ use cache، أو حاجة ثابتة (imports، قراءة ملف محلي، حسابات بحتة): بتدخل الـ Static Shell.\
• حاجة جوه Suspense: الـ Fallback بس هو اللي بيدخل الـ Shell، والمحتوى الحقيقي بييجي وقت الطلب.
  
  الـ Shell ده HTML بيتخدم من الـ CDN مباشرة، ومعاه RSC Payload للتنقل جوه الموقع. يعني أول محتوى بيوصل من غير ما السيرفر الأصلي يتحرك.
  
  والتفصيلة اللي بتفرق: كل ما كانت الحاجة اللي بتستنى الـ Request أعمق في الشجرة، كل ما الـ Shell بتاعك أكبر.
  
  مثال: لو الـ Layout قرا الـ params في أول سطر، الـ Layout كله بقى بيستنى الـ Request ومش هيدخل الـ Shell. لو نقلت القراءة جوه Component صغير ملفوف في Suspense، الباقي كله بيدخل الـ Shell.
  
  ولو الـ params مجهولة وقت الـ Build، بيطلع App Shell مشترك، وبعد أول زيارة بيتحدث للنسخة الكاملة (ISR).
  
  سؤال: Component بتاعك بيقرا الـ Request فين في الشجرة؟

ايه موضوع المينتورشيب او التوجيه ده ؟ - يعني ايه ادفع فلوس في ميتنج ؟

ببساطة الفكرة بدأت من موقع أجنبي مشهور موجود فيه معظم الـ Software Engineers الـ في العالم والـ شغالين في ميتا وشغالين في فيسبوك وغيره , ولكن أسعارهم مُبالغ فيها جداً لدرجة إن الميتنج الواحد بيكلفك 500 دولار

وطبعاً في وطنا العربي مفيش خدمة زي دي رغم ان عندنا كوادر كتير جداً محترمين تقدر تستفاد منهم ,

علشان كده عملنا موديول المينتورشيب , علشان الناس الـ عندها خبرة تقدر تفيد بعض

الفكرة الحلوة هنا انك مش لازم تكون جنيور او طالب علشان تستفاد , كفاية جداً انك تاخد استشارة في اي مجال انت عايزه , باسعار غريبة جداً يعني ممكن تدخل إستشاره كامله لـ ساعتين بـ 300 لـ 700 جنيه , الـ هو ثمن قهوة وكيك

وطبعاً بما إن منصة مونسترزغيت كانت بتقدم كورسات , قولت ليه مخليش المينتور يبقي موجود مع الكورسات بحيث انك تتعلم وفي نفس الوقت تلاقي حد تستشيره

انا محتاج منكم تجربوا الموديول وتقولولي رأيكم