🚀 فصل دوم | قسمت پنجم
⏳ چرا برنامه‌نویس‌ها گاهی زمان انجام یک تسکو اشتباه تخمین میزنن؟

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

لید تیم میاد سراغت:

«این قابلیتو تا فردا میتونی تحویل بدی؟»

تو هم با اعتمادبه‌نفس میگی:

«آره، فکر کنم چند ساعت بیشتر طول نکشه.»

⏰ فردا میشه...

هنوز کارت تموم نشده!

یک باگ پیدا کردی، یک بخش پروژه رو بهتر نفهمیدی و یک مشکل دیگه هم وسط کار به وجود اومده.

حالا سؤال:

❓ مشکل از کجا بود؟

آیا برنامه‌نویس ضعیفی بودی؟

یا از اول زمان انجام کار رو درست تخمین نزدی؟

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

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

⏳ تخمین زمان یعنی قبل از شروع کار، حدس بزنیم انجام یک Task واقعاً چقدر زمان میبره.

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

❌ «فکر کنم دو ساعت طول بکشه.»

برنامه‌نویس حرفه‌ای قبل از تخمین، اول Task رو بررسی میکنه.

مثلاً:

🔹 دقیقاً چه چیزی باید ساخته بشه؟
🔹 چه بخش‌هایی باید تغییر کنن؟
🔹 آیا با بخش ناشناخته‌ای از پروژه روبه‌رو هستیم؟
🔹 نیاز به تست داریم؟
🔹 احتمال وجود مشکل یا وابستگی وجود داره؟

📌 تخمین خوب یعنی حدس زدنِ شانسی نیست؛
یعنی شناختن کاری که قراره انجام بدی.

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

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

لید تیم ازت میپرسه:

«این قابلیت رو کی میتونی تحویل بدی؟»

تو هنوز دقیقاً پروژه رو بررسی نکردی.

چه جوابی میدی؟

1️⃣ «امروز تمومش میکنم.»
2️⃣ «فکر کنم دو روز زمان ببره.»
3️⃣ «اجازه بده اول Task رو بررسی کنم، بعد زمان دقیق‌تری بهت بدم.»
4️⃣ «نمیدونم.»

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

📅 فردا میریم سراغ قدمی که قبل از تخمین زمان باید انجام بدی:

📝 چطور یک Task رو درست تحلیل کنیم؟

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

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

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

یک Task بهت داده شده:

«قابلیت جستجوی محصولات رو به سایت اضافه کن.»

خب...

میری سراغ کدنویسی؟ 💻

صبر کن! ✋

این جمله خیلی کلیه.

قبل از اینکه حتی یک خط کد بنویسی، باید بفهمی:

❓ جستجو دقیقاً باید چطور کار کنه؟

و همین‌جا مهارت مهمی به اسم Task Analysis وارد ماجرا میشه.

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

📝 برای تحلیل یک Task، اول باید ابهام‌ها رو از بین ببری.

مثلاً برای قابلیت جستجوی محصولات، میتونی بپرسی:

🔹 جستجو بر اساس نام محصوله یا دسته‌بندی هم شامل میشه؟
🔹 اگر نتیجه‌ای پیدا نشد، چه چیزی نمایش داده بشه؟
🔹 جستجو باید لحظه‌ای باشه یا بعد از زدن دکمه؟
🔹 حروف بزرگ و کوچک اهمیت دارن؟
🔹 نتیجه‌ها چطور مرتب بشن؟

بعد از مشخص شدن این موارد، Task خیلی واضح‌تر میشه.

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

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

🎯 تمرین امروز 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
━━━━━━━━━━━━━━━━━━