خلاصه‌ی The Clean Coder - قسمت ۰۴ - کد نویسی (بخش ۲)
(اگه قسمت‌های قبلی رو نخوندی، پیشنهاد می‌کنم قسمت ۰۰ رو اول مطالعه کنی)
این پست ادامه‌ی بخش ۱ هست و اگه اون رو نخوندی پیشنهاد می‌کنم از اون شروع کنی. مسائلی که تو این دو بخش مطرح میشه، چارچوب و قوانینی و توصیه‌هایی هست راجب کد نویسی که عمو باب بعد از سعی و خطا تو چند دهه بهشون رسیده.
بعضی وقتا آدم کُدش نمیاد (writer's block). ایمیل می‌خونه، تو جلسه شرکت می‌کنه، با همکاراش از هر دری حرف می‌زنه و خلاصه هر کاری می‌کنه که کد نزنه! دلیلش می‌تونه چیزای مختلفی مثل اینا باشه:
کم‌خوابی
نگرانی
ترس
افسردگی
غیره
راه حل؟
می‌تونی از برنامه‌نویسی دو نفره استفاده کنی. معمولا وقتی شروع می‌کنی به این کار، حالت بهتر میشه و شروع می‌کنی به کد زدن.
البته این هم بعضی وقت‌ها جواب نمی‌ده و صرفا باید بری و خودتو ریکاوری کنی. یا بخوابی، یا اون مشکلت رو به یه شکلی حل کنی.
جالبه که بعضی از دولوپرها وقتی دارن دیباگ می‌کنن، حس نمی‌کنن دارن برنامه‌نویسی می‌کنن! یه کاریه که باید انجام بشه ولی برنامه‌نویسی نیست انگار.
زمانی که واسه دیباگ صرف می‌کنیم هزینش واسه شرکت با زمانی که صرف کد نویسی می‌کنیم فرقی نمی‌کنه پس باگ کمتر، هزینه‌ی کمتر [زندگی بهتر].
عمو باب می‌فرماید که زمانی که الان واسه دیباگ صرف می‌کنه تقریبا یک دهم قبل هست!!! و دلیلش رو استفاده از TDD میدونه. ??
برای یه دولوپر حرفه‌ای لازمه که زمان دیباگ رو تا جای ممکن به صفر نزدیک کنه و TDD تو این راه خیلی کمک می‌کنه.
??♂️ دولوپمنت مثل دو ماراتونه نه دو سرعت. یه دونده ماراتون، هم توی مسابقه و هم قبلش از بدنش مراقبت می‌کنه. واسه برنده شدن تو ماراتون، نباید از اول مسابقه با حداکثر سرعت دوید. باید از انرژی درست استفاده کرد و همه مسیر رو در نظر گرفت.
وقتی حس می‌کنی گیر کردی یا خسته‌ای، چند دقیقه (یا چند ساعت) از کار فاصله بگیر. تو این فاصله ممکنه ناخوداگاهت مساله رو واست حل کنه. باید الگوهای خلاقیت خودت رو شناسایی کنی (بدونی کِی و تو چه شرایطی خلاقیت بیش‌تر و بهتری داری) و از اونا استفاده کنی تا اینکه بخوای با زور و فشار بیش‌تر به خودت مساله رو حل کنی.
قطعا پیش میاد واست که به ضرب‌الاجل (deadline) نرسی و واسه همه اتفاق میافته. ولی اینجا هم دولوپر حرفه‌ای فرق خودشو با بقیه نشون میده. راه کنترل دیر تحویل دادن، اینه که زود متوجه بشی که کدت نمی‌رسه و اینکه این موضوع رو هم مخفی نکنی از بقیه.
مرتب پیشرفتت رو اندازه‌گیری کن و ببین چقدر به هدف (انجام تسک) نزدیک شدی و این سه‌تا تخمین رو بزن (تو بخش «تخمین» بیش‌تر راجبش توضیح میده و اینکه از این سه تا چه استفاده‌ای میشه):
تو بهترین حالت کار کی انجام میشه
اگه همه‌چی طبق روال و معمولی جلو بره کی انجام میشه
تو بدترین حالت کی انجام میشه
⚠️⚠️ وقتی داری این تخمین‌ها رو می‌زنی،کلا «امید» رو وارد قضیه نکن!
«امید» چندتا اسم دیگه هم داره ?:
قاتل پروژه‌ها
زمان‌بندی‌خراب‌کُن
بی‌اعتبارکُن
اگه تخمین «معمولی» که زدی، ۱۲ روزه و پروژه (یا تسک) باید ۱۰ روز دیگه برسه، به احتمالا خیلی خیلی زیاد، نمی‌رسه ?. به بقیه‌ی تیم (و ذی‌نفع‌ها) اطلاع بده موضوع رو و تا یه برنامه‌ی جایگزین به‌دردبخور (fall-back plan) کسی ارائه نداده، ول کن ماجرا نباش. و علاوه بر اینکه خودت امید نداری، اجازه نده هیچ‌کس دیگه‌ای هم امید واهی داشته باشه ??.
اگه مدیرت اومد کنارت و ازت خواست که پروژه رو برسونی، حالا هر طور که شده، چیکار باید کرد؟ ? دو دستی همون تخمین اولیه رو بچسب! چرا?؟ قضیه حساسه! ?دلیلش اینه که تخمین اولیه‌ای که زدی دقیق‌تر از تخمینیه‌ی که تحت این فشار می‌زنی. به مدیرت بگو که تنها راه رسیدن پروژه اینه که یه بخشی از تسک‌ها کنار گذاشته بشه (یا اگه بحث یه تسک بخصوصه، بعضی از بخش‌هاش حذف شه).
? وای بر دولوپری که زیر فشار کمر خم کنه و بگه «باشه سعیمو می‌کنم» (اگه قسمت ۰۲ رو نخوندید، یه‌سر بهش بزنید، توضیحش اونجا هست). این‌کار دستور پخت فاجعه‌س، چون به شما، تیمتون و ذی‌نفع‌ها امید واهی (?) میده.
? اضافه کاری چی؟ نمیشه یه‌جوری سر و تهشو هم آورد؟ چرا بعضی وقتا میشه.
یادت باشه که ۲۰٪ اضافه کاری، به ۲۰٪ کار بیش‌تر ختم نمیشه و بازدهیش پایین‌تره
فقط باید مراقب بود بیش‌تر از دو سه هفته نشه که زوار نیروها در میره
? اگه این سه تا شرط برقرار نبود، به هیچ وجه با اضافه‌کاری موافقت نکن:
ضربه‌ای که به زندگی شخصیت وارد میشه بخاطر اضافه‌کاری قابل مدیریت باشه
برنامه‌ی اضافه‌کاری قطعا از دو هفته کمتره
مدیر یا رئیس یه برنامه‌ی جایگزین در نظر گرفته باشه برای حالتی که پروژه با اضافه‌کاری هم نرسه و این خیلی مهمه. اگه مدیر یا رئیس نتونه به‌طور مشخص برنامه‌ی جایگزین رو توضیح بده، نباید با اضافه‌کار موافقت کنی.
آدمای مختلف وقتی می‌گن کارشون تموم شده یا فلان چیز انجام شده، منظورهای کاملا متفاوتی دارن. یکی صرف اینکه کد رو زده باشه حتی اگه کامپایل هم نشده باشه و باگ داشته باشه هم می‌گه انجام شده! باید توی تیم به تعریف واحدی از «انجام شدن» برسید.
(تو حالت ایده‌آل) بهترین راه این‌کار اینه که acceptance test نوشته بشه توسط تیم تست یا تحلیل‌گرهای کسب و کار (business analysts).
برنامه‌نویسی کار سختیه. هرچقدر جوون تر باشی، اعتقادت به این جمله احتمالا کمتره
مهم نیست تو چه سطحی از مهارت هستی، قطعا فکر و ایده‌های یه دولوپر دیگه می‌تونه بهت کمک کنه.
اون روی سکه اینه که تو به‌عنوان یه دولوپر حرفه‌ای، وظیفه داری به دیگران کمک کنی. البته اگه وقتی ازت سوالی میشه، خودت درگیر یه کار تمرکز‌لازمی، بگی که مثلا فلان ساعت می‌تونم کمک کنم یا از اول مشخص کرده باشی که مثلا ساعت ۱۰ تا ۱۲ مشغولم و ۱ تا ۳ اگه سوالی کسی داشت در خدمتم.
اینکه باید به بقیه کمک کنیم، معنیش این نیست که ما از بقیه باهوش تریم، بعضی وقتی صرفا «یه نگاه جدید» به مساله لازمه (به قول سهراب: چشم‌ها را باید شست).
وقتی داری به یکی کمک می‌کنی، با همه تمرکزت کار کن و روش وقت بذار. جوری به نظر نرسه انگار به زور اومدی کمک.
وقتی از دیگران کمک گرفتی هم یه مقدار به اونا زمان بده. مثلا نیم ساعت. اگه دیدی تا اون موقع خیلی نتونست به رفع اون مشکل کمکی بکنه، مودبانه ازش تشکر کن و برو (یا ردش کن بره ?).
وقتی حس می‌کنی تو یا مساله گیر کردی و نمی‌تونی حلش کنی، از یه نفر کمک بگیر. اگه کسی هست که بهت می‌تونه (یا ممکنه) کمک کنه، کار حرفه‌ای نیست که ازش کمک نگیری.
?? برنامه‌نویس‌ها معمولا مغرور، خودشیفته و درون‌گرا هستن ?. احتمالا بخاطر ارتباط و علاقه‌ی فوق‌العادمون به آدما نیست که برنامه نویس شدیم ?. کار با مفاهیم انتزاعی و فکری رو به کار با آدما ترجیح می‌دیم و عموما دوست داریم به خودمون ثابت کنیم که مغز ما هم‌سایز کره‌ی زمین و چه بسا بزرگتره. خلاصه اینکه شاید واسه خیلی از ما همکاری کردن با دیگران خیلی راحت و غریزی و طبیعی نباشه ولی حوزه‌ای که واردش شدیم جوریه که باید با دیگران همکاری کنیم، پس باید این موضوع رو تو خودمون تقویت کنیم.
هیچ چیز مثل علاقه‌ی درونی و منتورینگ خوب یه سینیور، باعث رشد سریع‌تر یک برنامه‌نویس تازه‌کار نمیشه.
