BRM-142Bug
إعادة محاولة الدفع بتبلع timeout المزود من غير ما تبيّن
مُبلَّغ من الدعم
معايير القبول
- الـ timeout يبقى متميّز عن النتيجة الفاضية
- الفشل يتعاد بمحاولة محدودة العدد
- في test بيغطي مسار الـ timeout
التقدير
٣ نقاط · اتفقنا عليها بعد جولتين
برمج بيشتغل إزاي
من الطلب لحد أول pull request بيتدمج ليك، وكل اللي بيتكرر بعد كده.
إزاي بتشتغل
عشر خطوات، والأخيرة هي المقصودة
معظم ده عادي جدًا لأي حد اشتغل في فريق. وده بالظبط سبب إنك تعمله قبل أول شغلانة مش أثناءها.
- 01
قدّم
قول لنا إنت فين وبنيت إيه. إنسان بيقرا الطلب.
- 02
التقييم
تمرين تقني قصير، عشان الفرق تبدأ من مستوى متقارب.
- 03
انضم لفريقك
بيئة هندسية صغيرة فيها mentor و backlog حقيقي.
- 04
خد شغل حقيقي
ticket من الـ backlog. غامض، زي أي ticket حقيقي.
- 05
ناقش وقدّر
تسأل في الـ ticket مع فريقك قبل ما تكتب سطر واحد.
- 06
نفّذ
على branch، في كود له قواعد لازم تحترمها.
- 07
افتح pull request
مكتوب بحيث المراجع يبدأ من غير ما يسألك حاجة.
- 08
استلم المراجعة
مهندس كبير بيرد خلال يوم عمل واحد.
- 09
اعمل ship
تعالج الملاحظات، يتدمج الكود، وتشوفه نزل.
- 10
ابني دليلك
كل merge بيضيف لسجل بيوضح إنت بتشتغل إزاي فعلًا.
جوه مساحة العمل
ticket، و pull request، وحد مستني يقراه
مفيش هنا محرر كود ولا مشغّل دروس. إنت بتشتغل في المكان اللي بتشتغل فيه أصلًا؛ اللي برمج بيديهولك هو كل الباقي.
رسم توضيحي للفكرة — مش لقطة شاشة
المراجعةمطلوب تعديلات
feature/retry-timeoutأول رد من إنسان
خلال ٤ ساعات و١٢ دقيقة من ساعات العمل
الجولة ٢
بتتعد. وعمرها ما بتبقى هدف.
- الاختباراتقوي
غطّى مسار الـ timeout من غير ما حد يطلب
- فهم المتطلباتفي تطور
سأل قبل ما يفترض
- التعامل مع الملاحظاتقوي
ناقش نقطة، وبعدين غيّر التصميم
مستويات، مش نسب مئوية. وكل واحد مربوط بالـ pull request اللي وراه.
- المناقشة›
- التنفيذ›
- المراجعة›
- الدمج
التجربة الهندسية
دورة واحدة، بتتعمل صح، وبتتكرر
ده مش منهج دراسي. دي الدورة اللي أي فريق محترف بيشتغل بيها كل sprint، وإنت بتشتغل جواها.
- 01
Backlog
شغل حقيقي مكتوب كـ tickets — أخطاء، مميزات، ديون تقنية.
- 02
Refinement
تقراه، تسأل فيه، وتكتشف اللي الـ ticket مقالوش.
- 03
Planning poker
كل واحد يقدّر لوحده. محدش يشوف رقم حد قبل الكشف.
- 04
Sprint
نطاق متفق عليه، ليه بداية ونهاية.
- 05
التنفيذ
branch على fork بتاعك في كود مش إنت اللي كتبته.
- 06
Pull request
موصوف كويس بحيث المراجع يبدأ فورًا.
- 07
Code review
مهندس كبير بيرد خلال يوم عمل واحد.
- 08
Merge
بيتدمج لما يبقى صح، مش لما إنت تخلص.
- 09
الملاحظات
إيه اللي عملته صح، إيه اللي يتغير، وليه.
- 10
دليل المهارة
سجل منسوب لصاحبه، مربوط بالشغل اللي بيثبته.
وبعدين تبدأ من أول وجديد، بـ ticket أصعب.
الفجوة
اتعلمت React. وبنيت مشاريع.
بس محدش علّمك فرق الشغل الحقيقية بتشتغل إزاي.
كل رسالة رفض بتقول نفس الكلام بصيغة مختلفة: كنا بندور على حد عنده خبرة أكتر. الفجوة مش في المعرفة. الفجوة في كل حاجة حوالين كتابة الكود.
عالم الدروس
الهندسة الحقيقية
المتطلبات كاملة وواضحة.
الـ ticket ناقص وغامض، وإنك تسأل السؤال الصح ده جزء من الشغل.
بتبدأ من فولدر فاضي.
بتبدأ جوه كود كتبه حد تاني، وله قواعده الخاصة.
إنت الوحيد اللي هيقرا الكود ده.
مهندس كبير بيقرا كل سطر ويسألك ليه عملتها كده.
شغّال على جهازك، يبقى خلص.
يخلص لما يتراجع ويتختبر ويتدمج ومايكسرش حاجة تانية.
إنت اللي بتقرر تبني إيه وإمتى.
الشغل بييجي من backlog، بيتناقش، بيتقدّر، وبيدخل sprint.
محدش بيختلف معاك.
حد بيختلف مع طريقتك، ولازم تدافع عن قرارك بحجة.
إنت مش محتاج درس تاني.
إنت محتاج خبرة.
الطلبات بيقراها إنسان، والأماكن محدودة بعدد الـ pull requests اللي نقدر نراجعها صح كل أسبوع.
قدّم على برمج