🎯 تمرین امروز ProgrammerCity

فرض کن این Task بهت داده شده:

«به اپلیکیشن، قابلیت ثبت‌نام کاربر اضافه کن.»

❓ قبل از اینکه شروع به کدنویسی کنی، حداقل ۳ سؤال از کسی که Task رو بهت داده میپرسی؟

سؤالاتت رو همین‌جا بنویس. 👇

مثلاً:

🔹 چه اطلاعاتی باید از کاربر دریافت بشه؟
اما سعی کن سؤال‌های خودتو پیدا کنی. 😉

📅 قسمت بعدی:

🧪 چرا برنامه‌نویس‌های حرفه‌ای قبل از تحویل Task، خودشون کدشونو تست میکنن؟

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

💼 از دانشگاه تا شرکت
🚀 فصل دوم | قسمت هفتم
🧪 قبل از تحویل Task، خودت کدتو تست کن!

🎬 داستان امروز از یک روز واقعی در دنیای برنامه‌نویسی...

بالاخره Task رو تموم کردی! 🎉

کدت اجرا میشه و همه‌چیز به نظر درست میاد.

پس سریع برای لید میفرستیش:

«انجام شد ✅»

اما چند دقیقه بعد...

🚨 یک باگ پیدا میشه!

و اولین سؤال لید:

«خودت قبل از تحویل تستش کردی؟» 😅

امروز میخوایم درباره یکی از عادت‌های مهم برنامه‌نویس‌های حرفه‌ای صحبت کنیم:

🧪 قبل از اینکه کسی کدتو تست کنه، خودت تستش کن.

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

🧪 تست کردن یعنی فقط یکبار برنامه رو اجرا کنی و ببینی خطا میده یا نه؟

نه! ❌

قبل از تحویل یک Task، حداقل این حالت‌ها رو بررسی کن:

✅ حالت معمولی
کاربر اطلاعات درست وارد میکنه.

⚠️ ورودی اشتباه
کاربر اطلاعات ناقص یا نامعتبر وارد میکنه.

🔲 حالت خالی
مثلاً فرم رو بدون وارد کردن اطلاعات ارسال میکنه.

🚨 حالت غیرمنتظره
مثلاً مقدار خیلی بزرگ یا یک داده غیرعادی وارد میشه.

📌 برنامه‌نویس حرفه‌ای فقط نمیپرسه:

«آیا برنامه من کار میکنه؟»

میپرسه:

«چطور ممکنه برنامه من خراب بشه؟»

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

🎯 تمرین امروز

فرض کن یک فرم «ورود به حساب کاربری» ساختی.

قبل از تحویل، چه حالت‌هایی رو تست میکنی؟

حداقل ۳ مورد بنویس. 👇

مثلاً:

🔹 رمز عبور اشتباه

اما دو مورد دیگه رو خودت پیدا کن. 😉

📅 فردا میرسیم به مرحله بعد:

📤 اولین Pull Request

و میبینیم وقتی کدت آماده شد، چطور باید اونو برای بررسی به تیم تحویل بدی.

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

💼 از دانشگاه تا شرکت
🚀 فصل دوم | قسمت هشتم
📤 اولین Pull Request؛ کدتو چطور به تیم تحویل بدیم؟

🎬 داستان امروز از یک روز واقعی در دنیای برنامه‌نویسی...

خب Task رو انجام دادی. ✅

کدتو هم تست کردی. 🧪

حالا باید تغییراتتو به تیم تحویل بدی.

اما یک سؤال:

❓ آیا مستقیم کدتو وارد Branch اصلی پروژه میکنی؟

معمولاً نه! 😅

اینجاست که با یکی از مهم‌ترین مفاهیم کار تیمی آشنا میشی:

📤 Pull Request یا PR

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

📤مفهوم Pull Request یعنی درخواست بررسی و وارد شدن تغییرات تو به یک Branch دیگه، معمولاً Branch اصلی یا یک Branch مشخص از پروژه.

یک روند ساده میتونه این‌طور باشه:

💻 کدنویسی میکنی

⬇️

🧪 کدتو تست میکنی

⬇️

📦بعد Commit میزنی

⬇️

🚀 تغییراتو Push میکنی

⬇️

📤 بعد Pull Request ایجاد میکنی

⬇️

👀 هم‌تیمی‌ها کدتو بررسی میکنن

⬇️

✅ بعد از تأیید، تغییرات Merge میشن.

📌 پس PR فقط یک دکمه نیست؛
یکی از مهم‌ترین نقاط ارتباطی بین اعضای تیمه.

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

🎯 حالا یک موقعیت واقعی:

تو Pull Request ساختی و برای Review فرستادی.

هم‌تیمی‌ات روی کدت ۳ تا پیشنهاد گذاشته.

اولین واکنش تو چیه؟

1️⃣ سریع همه رو رد میکنم. 😅
2️⃣ ناراحت میشم که چرا کدمو ایراد گرفته.
3️⃣ هر مورد رو بررسی میکنم و اگر منطقی بود اصلاحش میکنم.
4️⃣ ازش میپرسم چرا این پیشنهادو داده.

👇 شماره گزینه رو مشخص کن.

📅 قسمت بعدی:

💬 وقتی لید روی کدت بازخورد میده، چطور حرفه‌ای برخورد کنیم؟

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

💼 از دانشگاه تا شرکت
🚀 فصل دوم | قسمت نهم
💬 وقتی لید روی کدت بازخورد میده، چطور حرفه‌ای برخورد کنیم؟

🎬 داستان امروز از یک روز واقعی در دنیای برنامه‌نویسی...

اولین Pull Request خودتو فرستادی. 🚀

چند دقیقه بعد یک نوتیفیکیشن میاد:

💬 «I have a few comments on your code.»

میری داخل Pull Request...

و میبینی چندین خط روی کدت Comment خورده! 😳

اولین فکری که ممکنه به ذهنت برسه:

«یعنی کدم این‌قدر بد بوده؟!»

اما صبر کن...

حواست باشه Code Review قرار نیست ثابت کنه تو برنامه‌نویس بدی هستی.

امروز میخوایم یاد بگیریم چطور از Feedback برای بهتر شدن استفاده کنیم.

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

💡 وقتی کسی روی کدت Feedback میده، اول باید بفهمی:

آیا داره به خودت ایراد میگیره؟

نه! ❌

داره درباره کد و راه‌حل صحبت میکنه.

پس به جای اینکه بگی:
❌ «ولی من فکر میکنم کدم خوبه!»

میتونی بپرسی:
✅ «میشه توضیح بدی چرا این روشو پیشنهاد میکنی؟»

یا:

✅ «اگر این تغییرو انجام بدم، چه مشکلیو حل میکنه؟»

و اگر متوجه شدی پیشنهاد بهتره:
🔧 اصلاحش کن.

📌 برنامه‌نویس حرفه‌ای کسی نیست که همیشه بهترین کدو از همون بار اول بنویسه؛

کسیه که از بازخورد دیگران برای بهتر کردن کدش استفاده میکنه.

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

🎯 یک موقعیت واقعی:

لید تیم روی کدت نوشته:

💬 «این بخش میتونه ساده‌تر نوشته بشه.»

تو مطمئن نیستی منظورش دقیقاً چیه.

چکار میکنی؟

1️⃣ کامنتو نادیده میگیرم. 😅
2️⃣ میگم «ولی کد من کار میکنه!»
3️⃣ میپرسم منظورش از ساده‌تر کردن چیه.
4️⃣ بدون اینکه بفهمم، کدو تغییر میدم.

👇 شماره گزینه رو مشخص کن.

📅 قسمت بعدی:

😬 اولین اشتباه در محیط کار؛ وقتی یک اشتباه میکنیم، چه واکنشی حرفه‌ایه؟

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

💼 از دانشگاه تا شرکت
🚀 فصل دوم | قسمت دهم
😬 اولین اشتباه در محیط کار؛ پنهانش کنیم یا بگیم؟

🎬 داستان امروز از یک روز واقعی در دنیای برنامه‌نویسی...

هفته سوم کاریته.

یک تغییر کوچیک توی پروژه انجام دادی و همه‌چیز روی سیستم خودت درست کار میکنه.

اما چند ساعت بعد...

🚨 یکی از هم‌تیمی‌ها پیام میده:

«بعد از تغییر جدید، این بخش دیگه درست کار نمیکنه.»

قلبت میاد تو دهنت! 😰

اولین فکری که از ذهنت میگذره:

«نکنه تقصیر من باشه؟»

حالا سه راه داری:

🤫 چیزی نگی.
🙈 امیدوار باشی کسی متوجه نشه.
💬 یا مسئولیتش رو بپذیری و برای حلش اقدام کنی.

اما کدوم رفتار حرفه‌ای‌تره؟

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

💡 اشتباه کردن در محیط کار اجتناب‌ناپذیره.

اما نحوه برخورد با اشتباه خیلی مهم‌تر از خود اشتباهه.

اگه متوجه شدی مشکلی ایجاد کردی:

1️⃣ اول مسئله رو بررسی کن.
2️⃣ اگر مطمئن شدی اشتباه از تو بوده، پنهانش نکن.
3️⃣ سریع تیم رو در جریان بذار.
4️⃣ برای پیدا کردن راه‌حل اقدام کن.
5️⃣ بعد از حل مشکل، بفهم چرا اتفاق افتاده.

❌ «من خراب کردم، وای!»

به تنهایی کمکی نمیکنه.

✅ «این تغییر باعث این مشکل شده؛ دارم علتش رو بررسی میکنم و این راه‌حل رو پیشنهاد میدم.»

این یعنی مسئولیت‌پذیری حرفه‌ای.

📌 تیم‌ها دنبال آدمی نیستن که هیچوقت اشتباه نکنه؛
دنبال کسی هستن که وقتی اشتباه میکنه، مسئولانه باهاش برخورد کنه.

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━

🎯 یک موقعیت واقعی:

متوجه شدی کدی که نوشتی باعث ایجاد یک باگ شده.

اولین کارت چیه؟

1️⃣ سعی میکنم مشکلو خودم حل کنم و چیزی نگم.
2️⃣ امیدوارم کسی متوجه نشه. 😅
3️⃣ سریع مشکل و کاری که انجام دادم رو به تیم اطلاع میدم.
4️⃣ دنبال کسی میگردم که شاید کدش باعث مشکل شده باشه.

👇 شماره گزینه رو بنویس.

📅 فردا میریم سراغ یک سؤال خیلی مهم:

چطور بعد از چند هفته کاری، اعتماد تیم رو به دست بیاریم؟

━━━━━━━━━━━━━━━━━━
°⋆⸜ 𝙋𝙧𝙤𝙜𝙧𝙖𝙢𝙢𝙚𝙧'𝙨 𝘾𝙞𝙩𝙮 ⸝⋆°
➤ Code • Learn • Build
➤ @programercity
━━━━━━━━━━━━━━━━━━