https://virgool.io/feed/@amin.dannak هنر توسعه‌ی نرم‌افزار رو دوست دارم، توسعه دهنده هستم و گهگاهی راجب چیزایی که بهشون علاقه دارم می‌نویسم. fa 2026-07-12 00:31:47 https://files.virgool.io/upload/users/131871/avatar/AOUIjp.jpeg?height=120&width=120 https://virgool.io/@amin.dannak https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B9-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%B2%D9%85%D8%A7%D9%86-%D8%A8%D8%AE%D8%B4-%DB%B2-k23imckqz4oq این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.سهمیه‌بندی تمرکزبرنامه‌نویسی یه کار ذهنیه که توش لازمه تو بازه‌های زمانی طولانی، تمرکز بالایی به خرج بدیم.تمرکز یه منبع کمیابه.وقتی که ما سهمیه‌ی تمرکزمون رو بسوزونیم، باید دوباره خودمون رو با انجام کارهایی که به تمرکز احتیاج ندارن شارژ کنیم. پیاده‌روی طولانی، حرف زدن با یه دوست، به افق خیره شدن از پنجره و ...توسعه‌دهنده‌های حرفه‌ای یاد می‌گیرن که زمانشون رو مدیریت کنن و تمرکزشون رو جای درستی خرج کنن. ما وقتی که وقتی که هنوز سهمیه‌ی تمرکز داریم، کُد می‌زنیم و وقتی که تموم شد یا آخراش بود، می‌ریم سراغ کارهایی که به اندازه‌ی کد زدن نیاز به تمرکز ندارن.تمرکز یه منبع زوال‌پذیر (decaying) هم است. یعنی چی؟ 🤨 یعنی وقتی هنوز توانایی تمرکز کردن رو داری، ازش استفاده نمی‌کنی، قابلیت تمرکز کردنت به مرور کمتر می‌شه. [مثلا دیگه به جایی روزی ۴ ساعت، کم کم ممکنه فقط بتونی روزی ۲ ساعت کار با تمرکز انجام بدی]نگرانی و حواس‌پرت‌کن‌ها هم سهمیه‌ی تمرکز ما رو مصرف می‌کنن. [دعوایی که با همسرت داشتی، قبضی که پرداخت نکردی، بدهی که باید تسویه کنی و ...]عمو باب می‌فرماید که بعد از یه خواب خوب و با کیفیت، احساس می‌کنه که سهمیه‌ی تمرکز فولِ فول شده.توسعه‌دهنده‌های حرفه‌ای، برنامه‌ی خوابشون رو جوری مدیریت می‌کنن که وقتی می‌خوان کُد بزنن، بیش‌ترین توانایی رو واسه تمرکز داشته باشن.یه موضوع جالبی هم می‌گه راجب اینکه تجربه‌ش اینه که انجام کارهای فیزیکی مثل ورزش یا هر چیزی که عضله‌ها و ... درگیر می‌کنه، توانایی انجام کارهای ذهنی رو هم بیش‌تر می‌کنه.[یه چیزی یادم اومد تقریبا مرتبط با همین موضوع. یجایی شنیدم اینو و تجربه‌ی خودم هم هست. اینکه خستگی ناشی از کار ذهنی 👨🏻‍💻 رو می‌شه با کار فیزیکی 🏃🏻‍♂️ برطرف کرد و خستگی کار فیزیکی رو هم با خواب 😴]🍅[ خب اول بریم سراغ گوجه. چه ربطی به مدیریت زمان داره؟ تو زبان ایتالیایی به گوجه می‌گن pomodoro. پومودورو یه تکنیک مدیریت زمان واسه انجام کارها هست که تو یه بازه‌ی زمانی مثلا ۲۵ یه کاری رو بدون هیچ وقفه‌ای انجام می‌دیم (به این بازه می‌گن گوجه!)، یه استراحت کوتاه مثلا ۵ دقیقه‌ای می‌کنیم و بعد دوباره می‌ریم سراغ انجام اون کار.]تکنیک پومودورو رو بصورت سنتی با یه تایمر آشپرخونه انجام می‌دادن.تو بازه‌ی مربوط به انجام کار (🍅)، «هیچ» وقفه‌ای نباید باشه. [نه تلفن جواب دادن، نه چک کردن شبکه اجتماعی و ایمیل و ... و نه هیچ کار دیگه‌ای]. هر کاری که پیش میاد رو باید موکول کنیم به بعد از این بازه. و خیلی بعیده یه کاری پیش بیاد که نشه حداکثر ۲۵ دقیقه بعد انجامش داد!بعد از تموم شدن بازه‌ی کار، بلافاصله کار رو متوقف کنید. کارهایی که تو این بازه پیش اومدن رو سر و سامون بدید (هندل کنید). بعدش ۵ دقیقه استراحت کنید و بعد برید سراغ گوجه‌ی بعدی.تو بهترین حالت احتمالا بشه ۱۲ تا ۱۴ بازه‌ی کاری (🍅) انجام داد. بعضی روزها هم شاید دو سه تا بیش‌تر نشه! اگه تعداد گوجه‌های هر روز رو بشماریم و ببریمشون رو یه نمودار، خیلی سریع متوجه می‌شیم چقدر تو روز داریم کار مفید می‌کنیم و چقدر مشغول کارهای دیگه‌ایم.[یه نکته از تجربه‌ی خودم اینجا اضافه کنم. یه تکنیک جالبی هست که یه کاغذ کنار دستتون باشه. هر فکری که اومد تو ذهنتون یا هر چیزی که می‌خواست حواس شما رو یه جوری پرت کنه، اون رو بنویسید. اینجوری اون دغدغه موقتا از ذهنتون می‌ره بیرون می‌تونید با تمرکز ادامه بدید. بعد از تموم شدن بازه‌ی کارتون، برید سراغ چیزهایی که نوشتید و بهشون فکر کنید یا انجامشون بدید اگه واجبن. نکته اینه که حتما بعد از کار برید سراغ اون کاغذ وگرنه دفعات بعد مغزتون به شما اعتماد نمی‌کنه و بعد از نوشتن هم ممکنه نتونید مثل قبل تمرکز کنید. ]اجتناببعضی وقت‌ها دل و دماغ کار کردن نداریم. شاید کاری که باید انجام بدیم ترسناکه یا معذبمون می‌کنه یا صرفا خسته کننده‌س. شاید فکر می‌کنیم مجبوریم یه جایی از کار با یکی بحث کنیم. بعضی وقتا هم صرفا نمی‌خوایم انجامش بدیم!تو این جور حالتا ممکنه ما یه کار دیگه واسه انجام دادن پیدا کنیم و خودمون رو قانع کنیم که الان انجام دادنش ضروریه! به این پدیده‌ی زیبا می‌گن «وارونگی اولویت». توسعه‌دهنده‌های حرفه‌ای چی‌کار میکنن تو این موارد؟ 🤔 حدسش سخت نیست! اولویت هر کدوم از کارهایی که وجود داره رو ارزیابی می‌کنن، فارغ از ترس‌ها و مودشون و ... و کارها رو طبق اولویت واقعی‌شون انجام می‌دن.کوچه‌های بن بستبعضی وقت‌ها ما یه انتخابی فنی می‌کنیم (استفاده از یه لایبرری، فریمورک، روش یا هر چیز دیگه‌ای) ولی نهایتا به بن بست می‌خوره. چه بخوایم چه نخوایم، این چیزها بعضی وقت‌ها پیش میاد.هر چی تجربه‌ی ما بیش‌تر می‌شه، می‌تونیم زودتر این کوچه‌ها رو تشخیص بدیم ولی هیچ کامل از دستشون خلاص نمی‌شیم. مهارت واقعی که بهش نیاز داریم اینه که زودتر تشخیص بدیم که تو همچین کوچه‌ای گیر افتادیم و شجاعتشو داشته باشیم که از همون‌جا برگردیم.قانون چاه: وقتی می‌فهمی تو یه چاه گیر افتادی، دست از کندن بردار!باتلاق‌هاتو این قسمت راجب mess توی نرم‌افزارها حرف می‌زنه. mess یعنی جای بهم ریخته و شلوغ پلوغ. به نرم‌افزارهایی می‌گن که کدهای تمیزی ندارن و نظم و ترتیب و قاعده‌ی خاصی وجود نداره توشون. از best practiceها توشون استفاده نمی‌شه. کدهاشون اسپاگتیه و ... . چندتا اصطلاح دیگه هم به کار برده اینجا که من باتلاق رو انتخاب کردم.باتلاق‌ها سرعت ما رو می‌گیرن ولی ما رو متوقف نمی‌کنن! باتلاق‌ها از کوچه‌های بن بست هم بدترن. چرا؟ 🤔 چون آدم فکر می‌کنه می‌تونه به راهش ادامه بده و بالاخره به یه جایی برسه، و فکر می‌کنه این راه از راه برگشت کوتاه‌تره (ولی خب... نیست).هیچ چیزی به اندازه‌ی یه باتلاق رو بهره‌وری یه تیم نرم‌افزاری تاثیر نمی‌ذاره. هیچ چیز.یه جایی از کار بالاخره آدم متوجه می‌شه که تو طراحی سیستم اشتباه کرده و این سیستم واسه پروژه‌های بزرگ‌تر از این جواب نمی‌ده (scale نمیشه). این نقطه‌ی عطفه. اینجا می‌شه برگشت و طراحی رو اصلاح کرد یا می‌شه به مسیر قبلی ادامه داد. برگشتن به نظر هزینه‌بر میاد چون کد فعلی رو ریفکتور یا بازنویسی کرد ولی برگشتن تو این لحظه، کم‌هزینه ترین برگشته و از این به بعد هزینه‌ش فقط بیش‌تر می‌شه! اگه به مسیر قبلی ادامه بدیم، پروژه رو کم کم به یه باتلاق تبدیل می‌کنیم.توسعه دهنده‌های حرفه‌ای از باتلاق‌ها به مراتب بیش‌تر از کوچه‌های بن بست می‌ترسن. همیشه حواسشون به باتلاق‌های در حال شکل‌گیری هست و هر کاری لازم باشه انجام می‌دن تا تو کوتاه‌ترین زمان ممکن از شروشون خلاص شن. امین ظاهردناک امین ظاهردناک Sat, 16 Nov 2024 21:35:05 +0330 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B9-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%B2%D9%85%D8%A7%D9%86-%D8%A8%D8%AE%D8%B4-%DB%B1-uhrgmg78fypg این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.هشت ساعت واقعا زمان کوتاهیه [به شخصه اصلا باهاش موافق نیستم تو این زمینه 😅]. ما توسعه‌دهنده‌های حرفه‌ای باید از این زمان به بهینه‌ترین و مؤثرترین حالت ممکن استفاده کنیم. سوال اینه که چطور؟ 🤔اول فصل رو طبق معمول با یه خاطره شروع می‌کنه از زمان شاه که واسه یه شرکتی کار می‌کرده و مدیر یه تیم نرم‌افزاری ۱۵ نفره بوده. تماس‌ها، جلسه‌های خلق‌الساعه، بازدیدهای میدانی! و ... باعث می‌شده که روزهای خیلی شلوغی داشته باشه. این بنده خدا هم میاد یه برنامه میریزه واسه خودش و اجرا می‌کنه که از ۵ صبح بیدار می‌شه و زمانش رو به قسمت‌های مشخصی تقسیم می‌کنه و یه تایم‌هایی رو خالی می‌ذاره واسه کارهایی که بی‌برنامه پیش میان. آخر این خاطره می‌گه که درسته که همیشه نتونسته این برنامه رو مو به مو اجرا کنه ولی بیشتر اوقات این برنامه کمکش کرده که گلیم خودشو از آب بکشه بیرون.جلسه‌هاجلسه‌ها ممکنه حدود ۲۰۰ دلار به ازای هر نفر تو هر ساعت هزینه بذارن رو دست شرکت (قاعدتا اینجا کمتره ولی قابل توجهه همچنان). چطور؟ با در نظر گرفتن حقوق و مزایا و بیمه و ... دفعه بعد که تو یه جلسه می‌ری، هزینه‌شو حساب کن. جالب می‌شه واست.دو حقیقت راجب جلسه‌ها وجود دراه:جلسه‌ها ضروری هستنجلسه‌ها باعث می‌شن وقت زیادی تلف شهبعضی‌ها فکر می‌کنن جلسه‌های خیلی مهم و با ارزش هستن از نظر بعضیای دیگه، صرفا وقت تلف کردنن.🤓 حرفه‌ای‌ها متوجه هستن که جلسه‌ها هزینه‌ی زیادی دارن. اون‌ها می‌دونن که وقتشون با ارزشه. باید تسک‌هاشون رو انجام بدن و به ضرب‌الاجل (deadline) برسونن. اون‌ها به طور فعالی واسه شرکت تو جلسه‌هایی که ضرورت یا اهمیت ندارن مقاومت می‌کنن.نه!شما مجبور نیستید به هر جلسه‌ای که توش دعوت می‌شید شرکت کنید [احتمالا این بستگی به شرکت و نقش شما تو اون شرکت داره البته]. خیلی مراقب باشید که تو جلسه‌هایی شرکت کنید و به کدوما مودبانه «نه» بگید.ممکنه جلسه‌ای باشه که دوست داشته باشی توش شرکت کنی. ولی قبلش چند لحظه با خودت فکر کن که اگه شرکت کنی، به تعهداتت می‌رسی یا نه؟خداحافظطبق تجربه‌ی چندین و چند ساله‌م به یه قانون ساده رسیدم: «وقتی جلسه خسته کننده می‌شه، برو بیرون»اگه دیدی تو یه جلسه‌ای گیر افتادی که داره وقتت رو تلف می‌کنه، باید یه راهی پیدا کنی که مودبانه از اون جلسه بیای بیرون.ما «وظیفه» داریم که زمان و پول کارفرمارو درست خرج کنیم، پس اینکه بخوایم یه راهی پیدا کنیم که مودبانه از همچین جلسه‌هایی بیایم بیرون، غیرحرفه‌ای نیست.برنامه و هدف داشته باشواسه اینکه وقت شرکت‌کننده‌ها تو یه جلسه درست صرف بشه، جلسه باید برنامه شفافی داشته باشه. همینطور مشخص شه که هر آیتم قراره چقدر وقت صرفش بشه و نهایتا به چی ختم بشه.وقتی می‌خوای تو یه جلسه شرکت کنی، سعی کن هدف و برنامه جلسه رو بپرسی. اگه جواب واضحی نگرفتی، مودبانه بگو که نمی‌تونی تو جلسه شرکت کنی.جلسه‌های استنداپ (یا daily)تو این جلسه صرفا هر کس باید به این سه تا سوال جواب بده:دیروز چی‌کار کردم؟امروز می‌خوام چیکار کنم؟چه مانعی واسه انجام کارهام دارم الان؟جلسه‌های برنامه ریزی اسپرینت (iteration planning meetings)اینا سخت‌ترین جلسه‌های اسکرام هستن.از لیست بکلاگ (backlog)، تسک‌هایی که احتمالا باید تو اسپرینت بعد انجام بشن رو انتخاب کنید. تخمین‌ها باید از قبل زده شده باشه واسه این تسک‌ها. باید ارزیابی بیزنسی هر تسک از قبل مشخص باشه. تو شرکت‌های خیلی خفن، تست‌های پذیرش و کامپوننت هم از قبل نوشته شدن واسه این تسک‌ها.این جلسه باید با سرعت برگزار بشه. هر آیتم مختصرا بحث بشه راجبش و بعد تصمیم بگیریم که قراره تو اسپرینت بعد انجام بشه یا نه.قانون سرانگشتی‌ش اینه که این جلسه نباید بیش‌تر از ۵٪ کل وقت اسپرینت رو بگیره. پس واسه یه اسپرینت یه هفته‌ای ۴۰ ساعته (اینجا معمولا یکم بیش‌تره)، جلسه پلنینگ نباید بیش‌تر از دو ساعت طول بکشه.جلسه‌های رترو (retrospective) و دمو (demo)تو جلسه‌ی دمو هر کسی کارهایی که انجام داده رو نشون میده (دمو می‌کنه).تو جلسه‌ی رترو هم راجب نکات مثبت و منفی که تو اسپرینت اتفاق افتاده صحبت می‌شه.این جلسه‌ها رو آخر وقت آخرین روز کاری تو هفته بذارید. ۲۰ دقیقه واسه رترو و ۲۵ دقیقه هم واسه دمو [واسه اسپرینت‌های یک هفته‌ای].بحث‌ها/مخالفت‌هایه سخن بزرگانی شنیده از کِنت بِک که تحت تاثیر قرارداده عمو باب رو:هر بحثی که تو ۵ دقیقه به نتیجه نرسه، با حرف زدن به نتیجه نمی‌رسه.دلیل طول کشیدن بحث اینه که هیچ طرفی شواهد واضحی واسه ادعاش نداره. بحث احتمالا سلیقه‌ای یا ... هست و بر اساس واقعیت‌ها (facts) نیست. امین ظاهردناک امین ظاهردناک Tue, 05 Nov 2024 23:40:17 +0330 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B8-%D8%A7%D8%B3%D8%AA%D8%B1%D8%A7%D8%AA%DA%98%DB%8C-%D9%87%D8%A7%DB%8C-%D8%AA%D8%B3%D8%AA-%DA%A9%D8%B1%D8%AF%D9%86-tbqangukwfew این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.تست کردن فقط این نیست که چند تا تست واحد (unit test) و چندتا تست پذیریش (acceptance test) داشته باشیم. هر تیم توسعه‌ی حرفه‌ای لازمه که یه استراتژی داشته باشه واسه تست کردن.این یه پاراگراف شاید مهم نباشه ولی جالب بود واسه من، واسه همین توی پرانتز بخونیدش. همون اوایل فصل اشاره می‌کنه به اینکه تو شرکتی که سال ۱۹۸۹ کار می‌کرده، تقریبا هر یه ماه یکبار یه مراسم پر فیض و ملکوتی داشتن که بهش می‌گفتن Bug Hunt یا «شکار باگ». که تو اون روز از توسعه‌دهنده گرفته تا مدیرها و منشی‌ها، محصولات رو تست می‌کردن و سعی می‌کردن باگ پیدا کنن. بسته به باگی که پیدا می‌کردن، جایزه‌هایی از شرکت می‌گرفتن. این رو الزاما به‌عنوان توصیه نمی‌گه. تیم تست نباید هیچ باگی پیدا کنههدف تیم توسعه باید این باشه که تیم تست، هیچ باگی توش پیدا نکنه.احتمال همیشه رسیدن به این هدف خیلی کمه ولی با این وجود، هر بار تیم تست یه ایرادی تو محصول پیدا می‌کنه، تیم توسعه باید وحشت کنه. باید از خودشون بپرسن «چی‌شده که این باگ از دستمون در رفته؟» و کاری کنن که دفعه‌ی بعد این اتفاق نیفته.تیم بیزنس و تیم تست باید باهم تست‌های پذیرش رو بنویسن. تیم بیزنس تمرکزش رو نوشتن تست‌های happy-path هست (حالت سر راست استفاده از محصول) و تیم تست تمرکزش رو نوشتن تست‌ها unhappy-path (حالت‌های حدی و خاص و استثناها و ...).هرم اتوماسیون تست‌هاتوسعه دهنده‌های حرفه‌ای، از روش TDD (توسعه‌ی تست محور) استفاده می‌کنن واسه نوشتن تست‌های واحد.این هرم نشون می‌ده که یه تیم توسعه‌ی حرفه‌ای، به چه نوع تست‌هایی نیاز داره و هر کدومشون چند درصد از سیستم رو باید پوشش بدن.هرم اتوماسیون تست‌هاتست واحد: تست‌هایی هستن که توسط توسعه‌دهنده‌ها و برای توسعه‌دهنده‌ها نوشته می‌شن. هدف این تست‌ها، مشخص کردن [رفتار] سیستم تو پایین‌ترین سطحه. این تست‌ها به عنوان بخشی از continuous integration (یکپارچه‌سازی مداوم) اجرا می‌شن. این تست‌ها باید نزدیک به ۱۰۰٪ کد رو پوشش بدن.تست اجزا (component test): این‌ها بخشی از تست‌های پذیریشی هستن که قبلا راجبش صحبت کردیم که واسه اجزای سیستم به طور جداگانه نوشته شدن. اجزای سیستم، business rules (قوانین بیزنس) رو مشخص می‌کنن، بخاطر همین این تست‌ها، تست‌های پذیرش مربوط به اون بخش از قوانین بیزنس می‌شن.تست‌های اجزا رو تیم‌های بیزنس و تست با کمک تیم توسعه می‌نویسن. اجزایی که رابط کاربری گرافیکی (GUI) دارن، با ابزارهایی مثل Selenium یا Watir تست می‌شن.این تست‌ها تقریبا نصف سیستم رو پوشش می‌دن. بیش‌تر برای حالت‌های happy-path و حالت‌های حدی و خاصِ نسبتا واضح نوشته می‌شن.تست یکپارچگی (integration test): واسه سیستم‌های بزرگی که اجزا (component)ی متعددی دارن معنی داره همیچین تستی. تست‌هایی هستن که برای مجموعه‌ای از اجزا که با هم در ارتباط هستن نوشته می‌شن. این‌ها قوانین بیزنس رو تست نمی‌کنن، بجاش تمرکزشون رو اینه که این اجزا تو همکاری با هم چطور کار می‌کنن.تست‌های یکپارچگی معمولا توسط معمارهای سیستم (system architects) یا طراح‌های اصلی (lead designers) نوشته می‌شن. [اگه فرقشون رو می‌دونید لطفا تو کامنت‌ها بنویسید]ممکنه بین این تست‌ها، تست‌های مربوط به عملکرد و توان عملیاتی (throughput) رو هم ببینیم.این تست‌ها معمولا بعنوان بخشی از CI اجرا نمی‌شن چون معمولا زمان اجرای طولانی‌تری دارن. بجاش، تو فاصله‌های زمانی طولانی‌تر (هر روز یا هفته یا ... یه بار) اجرا می‌شن.تست‌های سیستمی (system tests): این‌ها تست‌هایی هستن که واسه تمامیت یکپارچه‌ی سیستم نوشته می‌شن. مستقیما قوانین بیزنس رو تست نمی‌کنن. کارشون اینه که تست کنن که قسمت‌های مختلف سیستم درست به هم وصل شدن و قسمت‌های مختلف طبق نقشه با هم به درستی کار می‌کنن. اینجا هم تست‌های عملکردی و توان عملیاتی رو می‌بینیم.این تست‌ها رو هم معمارهای سیستم یا طراح‌های اصلی می‌نویسن.بسته به زمانی که طول می‌کشه اجرا شن، تا جای ممکن تو فواصل زمانی کم اجرا می‌شن.حدود ۱۰٪ از سیستم رو پوشش می‌دن چون کارشون تایید رفتار سیستم نیست، تایید ساخت (construction) درستشه.تست‌های اکتشافی (manual exploratory tests): این یه جورایی همون مراسم bug hunt هست که ذکر خیرش اول متن بود.این تست‌ها اتوماتیک نیستن و اسکریپتی واسشون نوشته نمی‌شه و آدم‌ها به‌طور دستی انجامشون می‌دن.بعضی تیم‌ها ممکنه متخصص‌هایی رو دعوت کنن که محصولشون رو اینجور تست کنن و دیگران ممکنه از مدیر و منشی و تیم بیزنس و هر کی که خلاصه دم دست هست استفاده کنن!اینجا هدف پوشش کُد نیست. اینه که ببینیم محصولمون وقتی کاربرامون تو دنیای واقعی ازش استفاده می‌کنن چه رفتاری از خودش نشون می‌ده و تا جای ممکنه چیز میزای عجیبی که تو محصول وجود دارن رو هم پیدا کنیم! امین ظاهردناک امین ظاهردناک Sat, 26 Oct 2024 21:38:45 +0330 https://virgool.io/@amin.dannak/git-once-and-for-all-lii8netkc3sl نظرتون راجب کسی که ماشینش ۵ دنده‌س ولی فکر می‌کنه ۳ دنده بیشتر نداره چیه؟ چطور از این ماشین استفاده می‌کنه؟ چقدر مجبوره آروم تر بره تو جاده؟ چقدر زمان ازش تلف می‌شه؟یا فرض کنید ندونه برف‌پاک کن رو چطور استفاده کنه. ندونه که دکمه داره، هر سری شیشه رو می‌خواد تمیز کنه، پیاده میشه میره با یه دستمال تمیزش میکنه. یا از اون بدتر، هر بار برف‌پاک‌کن رو باز کنه و بگیره دستش و با اون شیشه رو تمیز کنه 😁شاید بخندیم به همچین آدمی ولی خب بعضی‌وقتا خودمون تو این شرایطیم! کجاها؟ 🧐وقتایی که از امکانات ابزاری که در اختیارمون قرار گرفته خبر نداریم و داریم اشتباه استفاده می‌کنیم!تو مثال این راننده‌ی بنده خدا و ماشینش، مشخصه که این وضع، نتیجه‌ی بی‌خبر بودنش از امکانات ماشینشه ولی خب در عین حال همچنان هم کارش رو راه میندازه. سوال اینه که چقدر تجربه‌ی استفاده‌ش از ماشین میتونست متفاوت باشه؟ 🤔 چه کارهایی میتونست انجام بده که الان نمی‌تونه؟اگه برنامه‌نویس هستید مثل من، احتمالا هر روز از ابزارهای خیلی زیادی استفاده می‌کنید (editor ها و IDEها، کامندلاین‌ها و برنامه‌ها و اسکریپت‌ها، سایت‌ها، نرم‌افزارها و ...). از یه طرف قاعدتا نمی‌خوایم مثل این راننده از این ابزارها استفاده کنیم، از یه طرف احتمالا داریم می‌گیم «ما مگه چقدر وقت داریم که بریم ته توی همه‌ی اینارو دراریم؟ 🤷🏻‍♂️». کاملا حق با شماست! تازه این هم هست که اینا مدام آپدیت هم میشن و تغییر می‌کنن! خب پس چی‌کار کنیم؟ 🧐می‌شه گفت همه چیز داره تغییر می‌کنه و هر چی من یاد بگیرم چند ماه دیگه به‌درد نمی‌خوره و هیچ کاری نکرد! ما جز این دسته نیستیم! (حالا این هم بگذریم که اصول ثابتن معمولا و یه سری جزئیات هستن که تغییر می‌کنن ). بجای این کار میایم مشخص می‌کنیم چه ابزارهایی هست که برای مهم‌تر هستن و بیشتر با اون‌ها کار می‌کنیم و تمرکزمون رو می‌ذاریم رو اونا و کم کم یاد می‌گیریم که دنده‌ی ۴ و ۵ی هم هست و برف‌پاک‌کن هم از داخل اتاق فعال می‌شه 😅اگه برنامه‌نویس هستید، به احتمالا خیلی بالا از یه VCS (سیستم کنترل نسخه) و به احتمال زیاد مثل من از Git استفاده می‌کنید. جز ابزارهایی هست که هر روز ازش استفاده می‌کنیم.تا چند سال پیش، حسی که داشتم موقع استفاده از گیت، این بود که دارم از ۳ دنده‌ی یه ماشین ۵ دنده استفاده می‌کنم. کار رو انجام می‌دادم ولی همیشه هم میدونستم میلنگه یه جای کار. یه روزی یادم نیست چی شد که شروع کردم به مطالعه‌ی بیش‌تر راجب گیت و مقاله‌ها و ویدیوهای یوتیوب و ... یه چند هفته‌ای که گذشت، داشتم تاثیر این اطلاعات جدید رو روی استفاده‌م از گیت می‌دیدم! و اینکه چقدر راحت‌تر و مسلط‌تر دارم از گیت استفاده می‌کنم.دیگه موقع merge conflict حس نمی‌کردم دنیا تموم شده. وقتی داشتم برنچ جدید می‌ساختم می‌دونستم دقیقا دارم چیکار می‌کنم. همینطور rebase و cherry-pick و ... خلاصه شرایط مثل کتلت از این رو به اون رو شده بود!نهایتا این اطلاعات جدید و تجربه‌ی چند سال استفاده‌م از گیت رو کنار هم گذاشتم و ختم شد به اولین دوره‌ی من. (بعد از یک سال و نیم ناقابل!)چرا دوره‌ی «گیت، یکبار برای همیشه؟»یادگیری وقتی اتفاق میفته که چیزهای جدیدی که یاد می‌گیریم، ارتباط داشته باشن با چیزهایی که از قبل بلدیم.من تلاشم این بوده که تو این دوره این اتفاق بیفته. پیش اومده که چند بار ترتیب بعضی چیزهارو جابجا کردم و ویدیوهاشون رو هم دوباره ضبط کردم یا کلا وقتی خلا یه موضوعی رو حس کردم، چند قسمت دوباره مطلب نوشتم و ضبط کردم. با اینکه چند ماه انتشار دوره رو به تعویق انداختن ولی ارزشش رو داشت و اون ترتیب و انسجامی که می‌خواستم رو پیدا کردن.خلاصه که این دوره از هسته‌ای ترین مفاهیم شروع می‌کنه و آجر به آجر مطالب رو روی هم می‌چینه تا کاخ دانش ما از گیت رو بسازه 😎 (مثال تبلیغاتی 😁).یه موضوعی که دقت کردم این بود که استفاده‌ی بد از گیت، برمی‌گرده به سو برداشت از بعضی مفاهیم. فرض کنید دو تا دولوپر داریم که یکیشون فکر می‌کنه وقتی یه برنچ می‌سازه یه کپی از کل پروژه گرفته می‌شه، اون یکی میدونه که برنچ صرفا یه فایل چند کیلوبایتیه! کدومشون راحت‌تر برنچ می‌سازه و ازش استفاده می‌کنه؟ 🧐 سعی کردم با شفاف کردنِ این مدلیِ مسائل، این موضوع رو هم حل کنم.علاوه بر این،‌ تو این دوره هر چیزی که راجبش حرف می‌زنیم رو می‌بینیم! اگه راجب commit و snapshot و branch و آبجکت‌های گیت حرف می‌زنیم، همه‌ی رو با هم عینا می‌بینیم. از این گذشته، وقتی بعد از هر مفهومی یه دستوراتش هم می‌رسیم، بعد از اون یه قسمت آزمایشگاه داریم که هر چی که راجبش صحبت کردیم رو انجام هم می‌دیم و هیچ چی تو سطح یه مفهوم صرف باقی نمی‌مونه!هدف آموزشی من از این دوره یه چیز بوده، اینکه شما بعد از دیدن (و تمرین با!) این دوره، بتونید با خیال راحت و اعتماد به نفس از گیت تو هر پروژه‌ای استفاده بکنید! پس این شما و این هم «گیت، یکبار برای همیشه»!این دوره تو پلتفورم مکتب خونه منتشر شده. این هم لینکش تقدیم به شما!یه گروه تلگرام هم زدم، اگه سوالی داشتید راجب دوره یا گیت و ...، می‌تونیم اونجا با هم در راتباط باشیم و از هم چیز یاد بگیریم. امین ظاهردناک امین ظاهردناک Sat, 26 Oct 2024 13:30:19 +0330 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B7-%D8%AA%D8%B3%D8%AA-%D9%BE%D8%B0%DB%8C%D8%B1%D8%B4-lrmbtovvhvja این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.نیازمندی‌هایکی از مواردی که خیلی مستعد سوء تفاهم بین تیم توسعه و مشتری (business) هست، «نیازمندی‌ها» (requirements) است.یه درس خیلی مهمی که عمو جان باب بعد از یه‌سری اتفاقات نسبتا دردناک یاد گرفته اینه که حتی خود مشتری هم از اول نمیدونه که دقیقا چی‌میخواد! و همینطور که کار جلو میره، «کشف» می‌کنه که این چیزایی که میخواد دقیقا چی هستن ??‍♂️?. اون ایده‌ی اولیه‌ای که از نیازهاشون و چیزی که میخوان دارن، اغلب اوقات تغییر می‌کنه.دقت پیش از موعدواقعیت اینه که تا قبل از اینکه محصول تا حدودی توسعه پیدا کنه (کدش زده شه و خروجی ملموسی ازش به دست بیاد)، نمیشه «دقیقا» فهمید که ماحصل نهایی قراره چی بشه (هرچند کلیات و حتی جزئیات تا حدود خوبی مشخص هستن). اما بعضی وقتا مشتری‌ها و دولوپرها این موضوع رو متوجه نیستن. حالا مشکل کجاست؟ اینجاست که از طرفی مشتری می‌خواد قبل از اینکه اوکی نهایی رو واسه شروع پروژه بده، بدونه که دقیقا قراره چی تحویل بگیره و از اون طرف تیم توسعه هم قبل از اینکه بگه پروژه رو چه زمانی تحویل میده، می‌خواد بدونه که دقیقا قراره چی تحویل بده!اصل عدم قطعیتمشکل اینجاست که مشتری وقتی پیاده‌سازی واقعی اون نیازمندی‌هایی که به تیم توسعه داده رو می‌بینه تازه متوجه می‌شه که این اون چیزی نیست که واقعا می‌خواسته و تازه ایده‌هایی به ذهنش می‌رسه که چطور می‌تونه چیزی که تا الان ساخته شده رو بهتر کنه!البته نمی‌شه به مشتری هم ایراد گرفت چون بعد از دیدن پیاده‌سازی، اطلاعات بیش‌تری به‌دست آورده (نسبت به زمان شروع پروژه) و همین باعث می‌شه که دید جدیدی به محصول پیدا کنه.با این توضیحات فک کنم بخش «دقت پیش از موعد» رو هم بهتر متوجه می‌شیم.اضطراب تخمیندولوپرها فکر می‌کنن که حتما باید تخمین بزنن و فکر می‌کنن که این کار نیازمند «دقت»ه ?مورد اول این‌که حتی اگه بی‌نقص‌ترین اطلاعات از چیزی که قراره پیاده‌سازی بشه رو به شما بدن (حداکثر دقت)، باز هم تخمینی که شما می‌زنید احتمال داره اختلاف زیادی با زمان واقعی پیاده‌سازی داشته باشه!مورد دوم این‌که طبق چیزایی که تا الان متوجه شدیم، وسط راه «نیازمندی‌ها» تغییر می‌کنن و تخمین‌های اولیه می‌ره رو هوا.? دولوپرهای حرفه‌ای می‌دونن که تخمین می‌تونه و اصلا باید براساس نیازمندی‌هایی باشه که دقت بالایی ندارن ( low precision requirements) و متوجه این موضوعه که این تخمین‌ها صرفا تخمین هستن. (راجب تخمین‌هم تو فصل‌های بعد توضیحات کامل‌تری هست).ابهام دیرهنگامهر ابهامی که توی سند نیازمندی‌ها (قرارداد و غیره) هست، نیاز به یه جلسه بین ذی‌نفع‌ها داره. (ذی‌نفع‌هایی مثل مشتری، تیم محصول، حتی خود تیم توسعه و …). بعضی وقتا ذی‌نفع‌ها «فرض می‌کنن» که کسی که این سند رو می‌خونه خودش متوجه می‌شه منظور ذی‌نفع از نوشتن اون چی بوده (حتی وقتی مبهمه!)یه مثالی می‌زنه عمو باب که بعضی وقت‌ها این اختلاف ممکنه در این حد باشه که توی سند اومده باشه که مثلا این نرم‌افزار نیاز به فیچر بکاپ‌گیری داره و منظور کسی که سند یا قرارداد رو نوشته، بکاپ گیری روزانه‌ای باشه که یک سال هم نگهداری می‌شه ولی تیم محصول یا توسعه برداشتش این باشه که نیازی به نگهداری بکاپ‌ها نیست و هر وقت بکاپ جدیدی گرفته شد (یعنی یک روز بعد به‌جای یک سال!)، بکاپ قبلی پاک می‌شه (شاید حتی با دلیل خوبی مثل صرفه‌جویی در فضای نگهداری (storage) و کاهش هزینه).تست پذیرشتعریف‌های زیادی برای «تست پذیرش» وجود دارد:تست‌هایی که کاربر قبل از تحویل نرم‌افزار انجام می‌ده تا مشخص شه همه‌چی طبق سند پیاده‌سازی شدهتست‌هایی که تو بخش ارزیابی کیفیت (QA یا همون تیم تست) انجام می‌شهو تعریف‌های دیگه. تو این بخش، تعریف ما از تست پذیرش اینه:«تست‌هایی که با همکاری ذی‌نفع‌ها و تیم توسعه نوشته می‌شه تا مشخص شه تعریف انجام شدن برای هر نیازمندی دقیقا چیه». احتمالا این تعریف الان مبهمه. پس ادامه بدیم ببینیم منظورش چیه.تعریف انجام شدنوقتی یه دولوپر می‌گه فلان تسک رو انجام دادم، منظورش دقیقا چیه؟ خبر بد این‌که هرکی یه تعریفی داره واسه خودش! ممکنه منظورش یکی از این موارد باشه:فیچر کاملا پیاده‌سازی و تست شده و آماده‌س برای دیپلویتسک رو زده و آماده‌س که بفرسته واسه تستکد رو زده و یک‌بار هم رانش کرده ولی حتی خودش هم خوب تستش نکرده و قاعدتا آماده‌ی فرستادنش به تیم تست هم نیستآما دولوپرهای حرفه‌ای یه تعریف واحد از انجام شدن دارن و وقتی میگن فلان تسک انجام شده، منظورشون اینه:«کد به‌طور کامل نوشته شده، تمام تست‌ها پاس شدن، تیم تست هم تست کرده و اوکی داده و ذی‌نفع‌ها هم قبول کردن که این تسک الان انجام شده»انجام همچین کاری به‌نظر راحت نیست و حتی شاید انجام همه‌ی این مراحل واسه هر تسک دست و پا گیر هم باشه.راه حل چیه؟ این‌که یه‌سری تست خودکار (automatic test) نوشته شه که فقط وقتی پاس بشن که همه‌ی معیارهایی که تو تعریف بالا (تعریف دولوپرهای حرفه‌ای از انجام شدن)هست ارضا شده باشه.ارتباطهدف تست پذیرش این سه تا چیزه؛ ارتباط، شفافیت (عدم وجود ابهام) و دقت.وقتی همه (ذی‌نفع‌ها، تیم توسعه و تیم تست) روی تست‌های پذیرش به توافق برسن، همه متوجه می‌شن که این سیستم قرار دقیقا چه ویژگی‌ها و رفتاری داشته باشه.رسیدن به همچین توافقی، وظیفه‌ی همه‌سدولوپرهای حرفه‌ای این رو وظیفه‌ی خودشون می‌دونن که با ذی‌نفع‌ها و تیم تست کار کنن تا این توافق به‌دست بیاد و همه بدونن که این سیستم قراره دقیقا چی رفتاری داشته باشه.خودکار کردن (automation)تست‌های پذیرش همیشه باید خودکار باشن. دلیلش هم ساده‌س: هزینه.اگه شما هم مثل من فکر باشید، احتمالا دارید یه همچین فکرهایی می‌کنید که چه‌خبره بابا! به‌نظر می‌رسه داره روغن داغ زیادی استفاده می‌شه! ادامه بدیم ببینیم دلیل اصرار به همچین کار نسبتا سختی چیه و مگه چقدر هزینه‌ قرار داشته باشه انجام دستی تست‌های پذیرش.فعلا این عکس رو با هم ببینیم:خب اگه به گوشه‌ی سمت راست پایین عکس دقت کنیم دست‌های یه بنده خدایی رو می‌بینیم که مدیر بخش ارزیابی کیفیت (QA) یه شرکت اینترنتی عریض و طویلِ و این چیزی که تو این صفحه می‌بینید صرفا فهرست سندی هست که بر اساس اون، ارزیابی کیفیت انجام می‌شه!!! بقول عمو باب این بزرگوار یه لشکر تستر تو کشورهای دیگه داره (احتمالا واسه کاهش هزینه) که هر ۶ هفته یک‌بار همه‌ی این تست‌ها رو انجام می‌دن و هربار حدود یک میلیون دلار هزینه‌ی این تست‌ها می‌شه. حالا جریان این عکس چیه؟ اینه که مدیر این آقا مدیر تو یه جلسه بهش گفته که قرار بودجه‌ش نصف شه و بعد از جلسه در حالی که این تو دستش بوده از عمو باب سوال کرده که حالا کدوم نصف تست‌ها رو باید بیخیال شیم! دیگه فکر کردن به ابعاد این فاجعه به عهده‌ی دانشجو.در مقایسه با همچین هزینه‌هایی، هزینه‌ی تست‌های خودکار خیلی خیلی ناچیزه. دولوپرهای حرفه‌ای این رو وظیفه‌ی خودشون می‌دونن که کاری کنن که تست‌های پذیرش حتما به‌طور خودکار نوشته شن.ابزارهای زیادی مثل Selenium، FITNESSE و غیره وجود دارن که این امکان رو فراهم می‌کنن که افرادی که برنامه‌نویس نیستن هم بتونن این تست‌های خودکار رو بخونن، بفهمن و حتی بنویسن.کار اضافیاحتمالا همه تو ذهنمون الان این موضوع هست که واسه نوشتن تست خودکار واسه تست‌های پذیرش باید کلی کار اضافه انجام داد. و خب حرف درستی هم هست. البته نه در مقایسه با چیزی که چند لحظه پیش عکسش رو دیدیم!کاری که ما داریم انجام می‌دیم در واقع تعیین رفتار سیستم با سطح بالایی از دقته. این کار این مزیت‌ها رو واسه ما داره:تیم توسعه با دقت و شفافیت خیلی بالایی می‌دونه که دقیقا چی باید تحویل بدهذی‌نفع‌ها کاملا مطمئن هستن که چیزی که قراره تحویل بگیرن، دقیقا اون نیازی که دارن رو فع می‌کنهنوشتن تست‌های خودکار (تا این دقت نباشه، نمی‌شه تست‌های درست و مناسبی نوشت)تست‌های پذیرش رو کی می‌نویسه؟تو یه دنیای ایده‌آل، تیم تست و ذی‌نفع‌ها. ولی خب چون ذی‌نفع‌ها تو دنیای واقعی معمولا علاقه و وقت این کار رو ندارن، این کار میفته‌ی به عهده‌ی تحلیل‌گرهای کسب و کار (business analysts)، تیم ارزیابی تست و یا حتی تیم توسعه.اگه قرار باشه تحلیل‌گرها و تیم تست این تست‌ها رو بنویسن، معمولا اینجوریه که تیم تحلیل، تست‌های روند سر راست (happy path) و تیم تست، تست‌های حالت‌ها و شرایط خاص (unhappy path) رو می‌نویسن.اگه قرار باشه تیم توسعه این کار رو انجام بده، حتما باید به این نکته دقت کرد که دولوپر یا دولوپرهایی که این تست‌ها رو می‌نویسن، همون دولوپرهایی نباشن که قراره نرم‌افزار رو توسعه بدن.طبق قاعده‌ی «دقت دیرهنگام»، تست‌های پذیرش باید تا جایی که ممکنه دیرتر نوشته شن. معمولا چند روز قبل از پیاده‌سازی هر فیچر. تو تیم‌های چابک، معمولا بعد از اینکه یه فیچر برای اسپرینت بعد انتخاب می‌شه، این تست‌ها نوشته می‌شن.مذاکرات پسا تستتست‌هایی که برای تست پذیرش نوشته می‌شن ممکنه دارای اشکالاتی باشن، مثلا خیلی پیچیده باشن، فرضیات بی‌ربطی داشته باشن یا اینکه اصلا اشتباه باشن. و خب قاعدتا نوشتن کدی که همچین تست‌هایی رو قرار باشه پاس کنه، کار شدیدا آزاردهنده‌ایه.یه دولوپر حرفه‌ای، با کسی که تست(ها) رو نوشته مذاکره می‌کنه راجب تست تا نهایتا تست بهتری نوشته شه.یه کاری که به هیچ وجه نباید انجام بدیم اینه که وقتی دیدیم یه تست مشکل داره، بجای حرف زدن و صحبت کردن با کسی که اون تست رو نوشته، یجورایی لج کنیم و صرفا یه کدی بنویسیم که اون تست اشتباه رو پاس کنه!تست‌های پذیرش و تست‌های واحدنکته‌ی مهم اینه که بین تست‌های واحد (unit test) و تست‌های پذیرش (acceptance test) فرق هست.تو تست‌های واحد، هم نویسنده‌ی تست یه دولوپره و هم مخاطب تست.تو تست‌های پذیرش، نویسنده و مخاطب، تیم‌های کسب و کار (business) هستن (حتی وقتی که تیم توسعه نهایتا اون‌ها رو می‌نویسه). این تست‌ها مستندات نیازمندی‌ها هستن و مشخص می‌کنن که سیستم باید چه رفتاری داشته باشه. (شاید بشه گفت از دیدگاه کاربر محصول، به محصول نگاه می‌شه تو این تست‌ها)درسته که تو هر دو نوع تست، یک چیز عملا داره تست می‌شه (رفتار سیستم) ولی با دو مکانیزم متفاوت این کار انجام می‌شه. تو تست واحد ما یجورایی از داخل دل و روده‌ی سیستم داریم تست می‌کنیم و متدها رو صدا می‌زنیم و آبجکت می‌سازیم از کلاس‌ها و غیره. ولی تو تست پذیرش، از فاصله‌ی خیلی بیش‌تر و در سطح API یا حتی رابط کاربری (UI) داریم این کار رو انجام می‌دیم.رابط کاربری گرافیکیمعمولا رابط کاربری گرافیکی (GUI) از اول آماده نیست و حتی اگر هم آماده باشه معمولا خیلی راجبش اظهار فضل می‌شه و دستخوش تغییراتی می‌شه. پس اگه ما تست‌ها رو برای رابط کاربری بنویسیم، یا بعد از هر تغییر باید تست‌ها رو بریزیم دور یا تغییر بدیم، یا اینکه کلا بیخیال تغییرات بشیم که خب هیچکدومش خوب نیست. پس راه حل چیه؟راه حل اینه که تست‌ها رو واسه لایه‌ی API یی بنویسیم که دقیقا یه سطح پایین‌تر از رابط کاربریه. باید سعی کنیم تست‌های خود رابط کاربری رو تو حداقل نگه داریم.ادغام مداوم (Continuous Integration یا CI)بعد از هر کامیت و قبل از ساختن (build) پروژه، سیستم CI باید تست‌های واحد و پذیرش رو اجرا کنه.اگه شما تجربه‌های متفاوتی از چیزی که عمو باب داره دارید خوشحال میشم با من و بقیه‌ی کسایی که این مقاله رو می‌خونن در میون بذارید. تو تیم‌هایی با سایزها و پروژه‌های مختلف به‌نظر شما این موضوع ثابته؟ همیشه نوشتن تست پذیرش منطقی و عملیه؟ امین ظاهردناک امین ظاهردناک Tue, 04 Oct 2022 23:54:23 +0330 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B6-%D8%AA%D9%85%D8%B1%DB%8C%D9%86-gwcaszczxrsq این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.همه‌ی افرادی که تو هر زمینه‌ای به‌طور حرفه‌ای کار می‌کنن، تمرینایی انجام می‌دن که مهارت‌هاشون رو حفظ و تقویت کنه. فرق نمی‌کنه وکیل باشن، سرباز، ورزشکار یا هنرمند. هر جا سرعت عمل مهم باشه، آدم‌های حرفه‌ای تمرین می‌کنن.یه ورزشکار هنرهای رزمی رو در نظر بگیرید. اونقدر تمرین کرده که وقتی توی مبارزه‌س، دیگه بدنش بصورت خودکار به خیلی از حمله‌های حریف عکس‌العمل نشون می‌ده و ذهن درگیر تک تک عکس‌العمل‌ها نمیشه و مشغول چیدن استراتژی‌های کلی‌تره. یا کسی که گیتار میزنه اگه حرفه‌ای باشه، همین که یه موزیکی تو ذهنش باشه، دستاش سریع اونو پیاده می‌کنن بدون اینکه ذهنش درگیر موقعیت انگشتاش و تارها و … باشه. [من: اگه این موضوع واستون جالبه می‌تونید راجب muscle memory مطالعه کنید].[بعضی از] برنامه‌نویس‌های حرفه‌ای هم همین کار رو می‌کنن. اون‌ها جلسه‌های تمرینی مثل رزمی‌کارها دارن. اسم‌های مختلفی رو این جلسه‌ها گذاشتن ولی معروف‌ترینش coding dojo یا «دوجو برنامه‌نویسی» هست. تو این جلسه‌ها بعضی از تمرین‌ها به‌صورت گروهی (مثل رزمی‌کارها) و بعضی‌ها به‌طور فردی (باز هم مثل رزمی‌کارها) انجام می‌شن. تمرین‌هایی که میشه انجام داد رو در ادامه با هم مرور می‌کنیم.Kataتعریف ویکی‌پدیا:کاتا، به معنای «فُرم» واژه‌ای ژاپنی است و به مجموعه حرکات از پیش طراحی شده‌ای گفته می‌شود که می‌تواند به‌طور انفرادی یا گروهی انجام شود.هدف از کاتا، انجام درست و بی‌عیب و نقص هر حرکته. درسته با کاتا نمی‌شه کسی رو شکست داد! ولی یه با این کار، یه رزمی‌کار داره روی حرکات و دقت مورد نیاز واسه شکست حریف تو مبارزه تمرین می‌کنه.با انجام این تمرین‌ها توی برنامه‌نویسی به مرور حس می‌کنیم که سرعت انجام کارها و سرعت حل مسألمون بهتر شده.? واسه تمرین چه‌چیزایی دقیقا می‌شه ازش استفاده کرد؟میان‌بُر(shortcut/hotkey)ی محیط توسعه (IDE) و سیستم عامل و چیزهای دیگه‌ای که همیشه ازشون استفاده می‌کنیم.تمرین دسیپلین‌های جدید مثل توسعه آزمون‌محور (TDD) و ادغام مستمر (CI/Continuous Integration) و غیره.انتقال مساله‌های پر استفاده‌ی برنامه نویسی و راه‌حل اون‌ها به ناخودآگاه که وقتی واقعا بهشون نیاز شد، بتونید خیلی سریع اونارو از غلاف در بیارید و ازشون استفاده کنید (یا به عبارتی خودشون از غلاف دربیان و شما فقط حالشو ببرین).مثل رزمی‌کارها، دولوپرها هم باید چند تا kata متفاوت بلد باشن و مرتب اون‌ها رو تمرین کنن که از حافظشون پاک نشه.Wasaمشابه kata ولی دو نفره‌س.تمام حرکت‌ها از قبل معلومه و به ترتیب یه نفر حمله و یه نفر دفاع می‌کنه و بعدش نقششون رو عوض می‌کنن.دولوپرها میتونن از یه تکنیک به اسم «پینگ پنگ» استفاده کنن. خلاصه‌ش اینه که یه نفر یه یونیت تست می‌نویسه و نفر مقابل باید کدی بنویسه که بتونه اون تست رو پاس کنه. بعد نقش‌هارو عوض می‌کنن و الی آخر.بسته به اینکه تو این پینگ پنگ چه مسائلی رو انتخاب کرده باشن، دو طرف می‌تونن همدیگه رو تو زمینه‌های متفاوتی نقد کنن.مساله از قبل معلوم باشه: نقد متمرکز میشه به سرعت عمل و استفاده از میانبرها و مسائل مرتبط با سرعتمساله‌ها جدید باشه: نقد متمرکز میشه به روش حل مساله.(البته نویسنده‌ی تست می‌تونه محدودیت زمان اجرا یا مقدار حافظه‌ی مورد استفاده و غیره هم بذاره واسه جالب کردن ماجرا)Randoriتعریف ویکی‌پدیا:کلمه‌ای ژاپنی به معنی تمرین سبک آزاد (free-style) در ورزش‌های رزمی.عمو باب از خاطرات روزهای جودو کاریش تعریف می‌کنه و می‌گه که بعضی از تمریناشون به این شکل بوده که که هر بار به جور تمرینی تعریف می‌کردن و انجام میدادن. مثل یه نفر دفاع کنه و سه نفر حمله، یا دو به دو و غیره.این سناریو جایگزین خیلی خوبی واسه دولوپرها نداره ولی بعضی‌ها یه همچین کاری می‌کنن:مواد لازم: چند عدد دولوپر، یه سیستم و یه پروژکتور که صفحه‌ی اون سیستم رو میندازه رو دیوار. یه نفر می‌ره پشت اون سیستم و یه تست می‌نویسه. نفر بعد می‌ره کدی می‌نویسه که تست پاس شه و یه تست دیگه می‌نویسه و نفر بعدی کدی می‌نویسه که پاسش کنه و باز هم یه تست جدید می‌نویسه و الی آخر.شاید واسه بعضیامون خیلی هیجان‌انگیز به‌نظر نرسه و یه جورایی فکر کنیم بی‌فایده‌س. نکته اینه که با این کار، ما متوجه می‌شیم که بقیه دقیقا چطور مسائل رو حل ‌می‌کنن! ?همین موضوع ساده می‌تونه باعث شه شما تکنیک‌ها و روش‌های جدید یاد بگیرید و به دولوپر بهتری تبدیل شید.جدای از تمرین، یه موضوع دیگه که خیلی مهمه و بعضی از حتی دولوپرهای حرفه‌ای هم توش می‌لنگن اینه که مسائلی که حل کردن و پروژه‌هایی که روش کار کردن، تنوع زیادی نداشته و در نتیجه تجربه‌های محدودی دارن (از نظر زبان برنامه‌نویسی، سیستم عامل، فریم‌ورک و حوزه‌ی کاری). این موضوع باعث میشه دولوپرها تو زمینه‌های معدود و محدودی رشد کنن و نتونن در زمان و به شکل مناسب به تغییرات صنعت نرم‌افزار عکس‌العمل نشون بدن. تو این حالت، به نسبت کسی که تجربه‌های بیش‌تری داره هم قاعدتا رزومه‌ی ضعیف‌تری دارن.یه روش خیلی خوب واسه جلوگیری از این موضوع، کار رو پروژه‌های open source هست. اون هم کار روی زبان‌ها و فریمورک‌هایی که معمولا روشون کار نمی‌کنید! قراره تنوع ایجاد کنیم بالاخره!? یه نکته اخلاقی هم اینکه تو تایم خودمون باید تمرین کنیم نه تو تایم شرکت. این وظیفه‌ی کارفرما نیست که هزینه‌ی تیز نگه داشتن تبر مهارت ما رو بده.جمع بندی فصل [عینا ترجمه کردم]:همه‌ی حرفه‌ای ها به یه شکلی تمرین می‌کنن. دلیل تمرین کردنشون هم اینه که واسشون مهمه که کار رو به بهترین شکل انجام بدن. نکته دیگه این‌که تو زمان خودشون تمرین می‌کنن چون متوجه این موضوع هستن که این وظیفه‌ی خودشونه که تبر مهارتهاشون رو تیز نگه دارن (نه وظیفه‌ی کارفرما!). تمرین، کاری هست که وقتی کسی بهت پولی نمیده انجام می‌دی. تو این کار رو می‌کنی که بعدا در ازاش پول دریافت کنی و پول خوب هم دریافت کنی!لیستی از سایت‌هایی که تو این زمینه به کمکتون میاد:codekata.pragprog.comcodingdojo.orgkatas.softwarecraftsmanship.org امین ظاهردناک امین ظاهردناک Thu, 07 Jul 2022 18:03:01 +0430 https://virgool.io/Rocket/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B5-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D8%AA%D8%B3%D8%AA-%D9%85%D8%AD%D9%88%D8%B1-tdd-hbtvutxgplgf این مقاله یکی از مجموعه مقالات کتاب the clean coder هست. برای پیدا کردن دید بهتر از کل این مجموعه و محتوایی که تو این مقاله می‌خونید، پیشنهاد می‌کنم مقاله‌ی صفرم رو هم یه نگاه بهش بندازید.اوایل فصل، عمو باب لطف کردن و با چندتا سوال در قالب استفهام انکاری، لزوم استفاده از TDD رو به ما گفتن:وقتی حتی مطمئن نیستیم همه‌ی کدی که نوشتیم کار می‌کنه یا نه، چطور می‌تونیم خودمون رو «برنامه‌نویس حرفه‌ای» بدونیم؟اگه بعد از هر تغییری که توی پروژه می‌دیم اون رو تست نکنیم، چطور می‌تونیم مطمئن باشیم که همش کار می‌کنه و مشکلی پیش نیومده؟اگه تست اتوماتیک نداشته باشیم چطور می‌تونیم مطمئن باشیم همش کار می‌کنه؟ (هر بار دستی همشو تست کنیم؟)اگه درصد خیلی بالایی از کدمون، تست واحد (unit test) نداشته باشه، می‌تونیم مطمئن باشیم همه چیز اوکیه؟سوال آخر هم این‌که، اگه از TDD استفاده نکنیم، چطور قراره این حجم از تست‌های واحد رو بنویسیم؟سه قانون TDD:قبل از نوشتن هر کد [و بعد از نام و یاد خدا]، اول یه تست واحد شکست خورنده می‌نویسی (چرا شکست خورنده؟‌ چون هنوز کدی ننوشتیم که این تست پاس/موفق شه)تست واحدی که نوشتی باید حداقل کد لازم برای شکست خوردن باشه، نه بیش‌تر. (مثلا فقط متدی که هنوز پیاده سازی نشده رو صرفا صدا بزنه).حداقل کد ممکن واسه پاس شدن این تستی که نوشتی رو می‌نویسیهمین سه قانون، ما رو به یه‌سری چرخه‌های کوتاه حدود ۳۰ ثانیه‌ای می‌رسونن (از نوشتن تست شکست‌خورنده تا کد پاس کننده) و ما تو این چرخه می‌چرخیم و می‌چرخیم و می‌نوشیم از این جام TDD. تو این چرخ‌زدنای ما، یه اتفاق جالبی داره میفته، اونم اینه که همزمان هم کد اصلی (production) ما داره نوشته می‌شه و هم تست‌های ما (که قرار بود درصد بالایی از کدمون رو پوشش بدن و خب این شکلی، می‌دن)فهرست مزیت‌هایی TDD:قطعیتچون ما برای هر قسمت از کدمون از قبل تست نوشتیم، با درصد بالایی مطمئنیم که پروژمون کار می‌کنه. عمو باب به پروژه‌ی خودش به اسم FITNESSE اشاره می‌کنه که ۶۴ هزار خط کده و ۲۸ هزار خطش مربوط به تست‌های واحده (حدود ۲۲۰۰ تا تست واحد!!) که ۹۰٪ کد اصلیش رو تو حدود ۹۰ ثانیه تست می‌کنن!باگ‌خیزیمطالعات و گزارش‌های زیادی هست که نشون می‌دن استفاده از TDD باعث کاهش قابل توجه باگ‌های جدید توی پروژه می‌شه. حتی شرکت‌هایی مثل مایکروسافت و IBM و غیره هم تجربه‌ی کاهش باگ‌ها به نصف و حتی گاها به یک‌دهم رو داشتن [!!] و این آمار چیزی نیست که یه دولوپر حرفه‌ای بتونه راحت از کنارش بگذره.شجاعتوقتی تست‌هایی که باید بنویسی رو نوشته باشی، تقریبا هیچ ترسی از تغییر کد نداری، چون بلافاصله بعد از تغییر می‌تونی تست‌ها رو اجرا کنی و اگه کاری که انجام دادی روی بخش دیگه‌ای از کد تاثیر داشته (اثر جانبی یا اصطلاحا side effect) داشته، خیلی راحت و سریع متوجه می‌شی.خیلی وقت‌ها نداشتن همچین تست‌هایی باعث می‌شه که ما کدمون رو تمیز نکنیم، ریفکتور نکنیم و کلا تغییرش ندیم چون وقتی کد کار می‌کنه که کسی بهش دست نمی‌زنه! (البته کد بدون تست)مستندسازیوقتی تست داشته باشیم، واسه هر کاری یه تست نوشته شده و به‌ بهترین شکل و با جزئیات (با کد) مشخصه که چطور باید هرکاری رو انجام داد. به‌عبارتی همین تست‌های واحد(unit test)ی که نوشتیم، خودشون مستندسازی پروژه هستن. این کار باعث می‌شه که مستندسازی داشته باشیم که مبهم نیست، دقیقه و به زبانی نوشته شده که مخاطبش (دولوپری که قراره روی پروژه کار کنه) اونو به‌خوبی متوجه می‌شه.طراحی (design)یکی از مشکلاتی که تست نوشتن داره این که معمولا باید کد رو ایزوله کنی. معمولا تست کردن تابعی که تابع‌های دیگه رو صدا می‌زنه کار سختیه. به‌خاطر همین مجبوری راهی پیدا کنی که هر تابع، از توابع دیگه جدا (decouple) باشه. به‌عبارتی، این‌که اول تست رو بنویسیم، ما رو مجبور می‌کنه که طراحی خوبی داشته باشیم (و پیاده‌سازیش کنیم).اگه اول تست ننوشته باشیم، چیز دیگه‌ای نیست که ما رو مجبور کنه توابع رو جدا از هم بنویسیم و به یه کد ناپایدار و به‌هم‌ریخته نرسیم نهایتا! خب اگه آخر سر تست بنویسیم چی‌میشه؟ ممکنه بتونیم ورودی و خروجی اون کد به‌هم‌ریخته‌ی ناپایدار رو تست کنیم ولی احتمالا تست کردن همه‌ی تابع‌ها کار خیلی سختی می‌شه (چون جدا از هم نوشته نشدن).البته TDD یه فرمول جادویی یا وحی مُنزَل نیست. جاهایی هست که ضررش به نفعش می‌چربه ولی خب جاهای خیلی کمی هستن. امین ظاهردناک امین ظاهردناک Thu, 23 Jun 2022 15:05:58 +0430 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B4-%DA%A9%D8%AF-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%A8%D8%AE%D8%B4-%DB%B2-d6pjgntmwoo1 (اگه قسمت‌های قبلی رو نخوندی، پیشنهاد می‌کنم قسمت ۰۰ رو اول مطالعه کنی)این پست ادامه‌ی بخش ۱ هست و اگه اون رو نخوندی پیشنهاد می‌کنم از اون شروع کنی. مسائلی که تو این دو بخش مطرح میشه، چارچوب و قوانینی و توصیه‌هایی هست راجب کد نویسی که عمو باب بعد از سعی و خطا تو چند دهه بهشون رسیده.بعضی وقتا آدم کُدش نمیاد (writer's block). ایمیل می‌خونه، تو جلسه شرکت می‌کنه، با همکاراش از هر دری حرف می‌زنه و خلاصه هر کاری می‌کنه که کد نزنه! دلیلش می‌تونه چیزای مختلفی مثل اینا باشه:کم‌خوابینگرانیترسافسردگیغیرهراه حل؟می‌تونی از برنامه‌نویسی دو نفره استفاده کنی. معمولا وقتی شروع می‌کنی به این کار، حالت بهتر می‌شه و شروع می‌کنی به کد زدن.البته این هم بعضی وقت‌ها جواب نمی‌ده و صرفا باید بری و خودتو ریکاوری کنی. یا بخوابی، یا اون مشکلت رو به یه شکلی حل کنی.جالبه که بعضی از دولوپرها وقتی دارن دیباگ می‌کنن، حس نمی‌کنن دارن برنامه‌نویسی می‌کنن! یه کاریه که باید انجام بشه ولی برنامه‌نویسی نیست انگار.زمانی که واسه دیباگ صرف می‌کنیم هزینش واسه شرکت با زمانی که صرف کد نویسی می‌کنیم فرقی نمی‌کنه پس باگ کمتر، هزینه‌ی کمتر [زندگی بهتر].عمو باب می‌فرماید که زمانی که الان واسه دیباگ صرف می‌کنه تقریبا یک دهم قبل هست!!! و دلیلش رو استفاده از TDD میدونه. ??برای یه دولوپر حرفه‌ای لازمه که زمان دیباگ رو تا جای ممکن به صفر نزدیک کنه و TDD تو این راه خیلی کمک می‌کنه.??‍♂️ دولوپمنت مثل دو ماراتونه نه دو سرعت. یه دونده ماراتون، هم توی مسابقه و هم قبلش از بدنش مراقبت می‌کنه. واسه برنده شدن تو ماراتون، نباید از اول مسابقه با حداکثر سرعت دوید. باید از انرژی درست استفاده کرد و همه مسیر رو در نظر گرفت.وقتی حس می‌کنی گیر کردی یا خسته‌ای، چند دقیقه (یا چند ساعت) از کار فاصله بگیر. تو این فاصله ممکنه ناخوداگاهت مساله رو واست حل کنه. باید الگوهای خلاقیت خودت رو شناسایی کنی (بدونی کِی و تو چه شرایطی خلاقیت بیش‌تر و بهتری داری) و از اونا استفاده کنی تا اینکه بخوای با زور و فشار بیش‌تر به خودت مساله رو حل کنی.قطعا پیش میاد واست که به ضرب‌الاجل (deadline) نرسی و واسه همه اتفاق میافته. ولی اینجا هم دولوپر حرفه‌ای فرق خودشو با بقیه نشون می‌ده. راه کنترل دیر تحویل دادن، اینه که زود متوجه بشی که کدت نمی‌رسه و اینکه این موضوع رو هم مخفی نکنی از بقیه.مرتب پیشرفتت رو اندازه‌گیری کن و ببین چقدر به هدف (انجام تسک) نزدیک شدی و این سه‌تا تخمین رو بزن (تو بخش «تخمین» بیش‌تر راجبش توضیح می‌ده و اینکه از این سه تا چه استفاده‌ای می‌شه):تو بهترین حالت کار کی انجام می‌شهاگه همه‌چی طبق روال و معمولی جلو بره کی انجام می‌شهتو بدترین حالت کی انجام می‌شه⚠️⚠️ وقتی داری این تخمین‌ها رو می‌زنی،کلا «امید» رو وارد قضیه نکن!«امید» چندتا اسم دیگه هم داره ?:قاتل پروژه‌هازمان‌بندی‌خراب‌کُنبی‌اعتبارکُناگه تخمین «معمولی» که زدی، ۱۲ روزه و پروژه (یا تسک) باید ۱۰ روز دیگه برسه، به احتمالا خیلی خیلی زیاد، نمی‌رسه ?. به بقیه‌ی تیم (و ذی‌نفع‌ها) اطلاع بده موضوع رو و تا یه برنامه‌ی جایگزین به‌دردبخور (fall-back plan) کسی ارائه نداده، ول کن ماجرا نباش. و علاوه بر اینکه خودت امید نداری، اجازه نده هیچ‌کس دیگه‌ای هم امید واهی داشته باشه ??.اگه مدیرت اومد کنارت و ازت خواست که پروژه رو برسونی، حالا هر طور که شده، چیکار باید کرد؟ ? دو دستی همون تخمین اولیه رو بچسب! چرا?؟ قضیه حساسه! ?دلیلش اینه که تخمین اولیه‌ای که زدی دقیق‌تر از تخمینیه‌ی که تحت این فشار می‌زنی. به مدیرت بگو که تنها راه رسیدن پروژه اینه که یه بخشی از تسک‌ها کنار گذاشته بشه (یا اگه بحث یه تسک بخصوصه، بعضی از بخش‌هاش حذف شه).? وای بر دولوپری که زیر فشار کمر خم کنه و بگه «باشه سعیمو می‌کنم» (اگه قسمت ۰۲ رو نخوندید، یه‌سر بهش بزنید، توضیحش اونجا هست). این‌کار دستور پخت فاجعه‌س، چون به شما، تیمتون و ذی‌نفع‌ها امید واهی (?) میده.? اضافه کاری چی؟ نمیشه یه‌جوری سر و تهشو هم آورد؟ چرا بعضی وقتا میشه.یادت باشه که ۲۰٪ اضافه کاری، به ۲۰٪ کار بیش‌تر ختم نمی‌شه و بازدهیش پایین‌ترهفقط باید مراقب بود بیش‌تر از دو سه هفته نشه که زوار نیروها در میره? اگه این سه تا شرط برقرار نبود، به هیچ وجه با اضافه‌کاری موافقت نکن:ضربه‌ای که به زندگی شخصیت وارد میشه بخاطر اضافه‌کاری قابل مدیریت باشهبرنامه‌ی اضافه‌کاری قطعا از دو هفته کم‌ترهمدیر یا رئیس یه برنامه‌ی جایگزین در نظر گرفته باشه برای حالتی که پروژه با اضافه‌کاری هم نرسه و این خیلی مهمه. اگه مدیر یا رئیس نتونه به‌طور مشخص برنامه‌ی جایگزین رو توضیح بده، نباید با اضافه‌کار موافقت کنی.آدمای مختلف وقتی می‌گن کارشون تموم شده یا فلان چیز انجام شده، منظورهای کاملا متفاوتی دارن. یکی صرف این‌که کد رو زده باشه حتی اگه کامپایل هم نشده باشه و باگ داشته باشه هم می‌گه انجام شده! باید توی تیم به تعریف واحدی از «انجام شدن» برسید.(تو حالت ایده‌آل) بهترین راه این‌کار اینه که acceptance test نوشته بشه توسط تیم تست یا تحلیل‌گرهای کسب و کار (business analysts).برنامه‌نویسی کار سختیه. هرچقدر جوون تر باشی، اعتقادت به این جمله احتمالا کمترهمهم نیست تو چه سطحی از مهارت هستی، قطعا فکر و ایده‌های یه دولوپر دیگه می‌تونه بهت کمک کنه.اون روی سکه اینه که تو به‌عنوان یه دولوپر حرفه‌ای، وظیفه داری به دیگران کمک کنی. البته اگه وقتی ازت سوالی میشه، خودت درگیر یه کار تمرکز‌لازمی، بگی که مثلا فلان ساعت می‌تونم کمک کنم یا از اول مشخص کرده باشی که مثلا ساعت ۱۰ تا ۱۲ مشغولم و ۱ تا ۳ اگه سوالی کسی داشت در خدمتم.اینکه باید به بقیه کمک کنیم، معنیش این نیست که ما از بقیه باهوش تریم، بعضی وقتی صرفا «یه نگاه جدید» به مساله لازمه (به قول سهراب: چشم‌ها را باید شست).وقتی داری به یکی کمک می‌کنی، با همه تمرکزت کار کن و روش وقت بذار. جوری به نظر نرسه انگار به زور اومدی کمک.وقتی از دیگران کمک گرفتی هم یه مقدار به اونا زمان بده. مثلا نیم ساعت. اگه دیدی تا اون موقع خیلی نتونست به رفع اون مشکل کمکی بکنه، مودبانه ازش تشکر کن و برو (یا ردش کن بره ?).وقتی حس می‌کنی تو یا مساله گیر کردی و نمی‌تونی حلش کنی، از یه نفر کمک بگیر. اگه کسی هست که بهت می‌تونه (یا ممکنه) کمک کنه، کار حرفه‌ای نیست که ازش کمک نگیری.?? برنامه‌نویس‌ها معمولا مغرور، خودشیفته و درون‌گرا هستن ?. احتمالا بخاطر ارتباط و علاقه‌ی فوق‌العادمون به آدما نیست که برنامه نویس شدیم ?. کار با مفاهیم انتزاعی و فکری رو به کار با آدما ترجیح می‌دیم و عموما دوست داریم به خودمون ثابت کنیم که مغز ما هم‌سایز کره‌ی زمین و چه بسا بزرگتره. خلاصه این‌که شاید واسه خیلی از ما همکاری کردن با دیگران خیلی راحت و غریزی و طبیعی نباشه ولی حوزه‌ای که واردش شدیم جوریه که باید با دیگران همکاری کنیم، پس باید این موضوع رو تو خودمون تقویت کنیم.هیچ چیز مثل علاقه‌ی درونی و منتورینگ خوب یه سینیور، باعث رشد سریع‌تر یک برنامه‌نویس تازه‌کار نمیشه. امین ظاهردناک امین ظاهردناک Sat, 07 May 2022 23:27:16 +0430 https://virgool.io/Rocket/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B4-%DA%A9%D8%AF-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%A8%D8%AE%D8%B4-%DB%B1-vy1xzimuuvid (اگه قسمت‌های قبلی رو نخوندی، پیشنهاد می‌کنم قسمت ۰۰ رو اول مطالعه کنی)(بخاطر طولانی بودن این قسمت، تو دو بخش پستش می‌کنم که وسطاش خسته نشیم ?)مسائلی که تو این بخش مطرح میشه، چارچوب و قوانینی هست که عمو باب بعد از سعی و خطا تو چند دهه بهشون رسیده.آماده باشکد نویسی ذهن رو به چالش می‌کشه و انرژی زیادی از دولوپر می‌گیره. نیاز به سطح بالایی از تمرکز داره، سطحی که تو کمتر کاری بهش نیاز پیدا می‌شه. حالا واقعا اینجوره یا پیاز داغشو داریم زیاد می‌کنیم؟ بنظر می‌رسه اینجوره چون دولوپر باید بین مفاهیم مختلف و ظاهرا متضاد یه هماهنگی ایجاد کنه‌:کد باید کار کنه. همه جزئیات باید جوری پیاده‌سازی بشن که شما همزمان باید از قوانین و امکانات زبان برنامه‌نویسی که استفاده می‌کنید، معماری پروژه و سایر موارد تبعیت کنیدکد باید مشکل مشتری رو حل کنه.باید به کدهایی که از قبل وجود داره هماهنگ باشه و به درستی از اونا استفاده کنه. کد رو نباید شکننده کنه، انعطاف‌پذیریش رو کم کنه یا سیستم رو مبهم و غیر شفاف کنه.کد باید خوانا باشه و بقیه‌ی دولوپرها بتونن نسبتا بدون مشکل اون رو بخونن و متوجه شن. این یکی از سخت‌ترین کارهایی هست که هر برنامه‌نویس باید توش مهارت کسب کنه ??.ایجاد یه‌جور هماهنگی بین همه‌ی این مفاهیم به چند دلیل سخته:به‌طور کلی حفظ تمرکز برای مدت زمان طولانی از نظر فیزیولوژیکی کار سختیهمشکلات و حواس‌پرتی‌هایی که بخاطر کار تیمی ایجاد می‌شه رو هم به این اضافه کنمشکلات و نگرانی‌های همیشگی زندگی هم که همیشه هستن!⚠️ وقتی نمی‌تونی به اندازه‌ای که نیاز هست تمرکز کنی، کدی که می‌نویسی از دو حالت خارج نیست:بعدا دوباره باید از اول بنویسیدوباره کلی روش کار کنی تا مشکلاتشو حل کنی.کد نوشتن وقتی که تمرکز نداری، هدر دادن وقت و انرژیه.⚠️? وقتی خسته‌ای یا تمرکز نداری، کد نزن! به‌جاش سعی کن حواس‌پرتی‌ها رو حذف کنی و ذهنت رو آروم کنی.? طبیعتا بعضی از مشکلات هستن که نمیشه به این راحتی حلشون کرد. تو همچین مواقعی، این دو مورد کمک می‌کنن:اون صدایی که مدام توی ذهنت راجب اون مشکل حرف میزنه رو ساکت کنیتو ذهنت اون صدا رو ضعیف کنی یا موقتا ساکت کنی تا یه‌ضرب مزاحمت نباشهواسه انجام این کارها می‌تونی زمانت رو تقسیم‌بندی (پارتیشن بندی) کنی. مثلا یه واحد مشخصی از زمان مثلا یک ساعت رو به کار کردن روی اون مساله اختصاص بدی. به احتمال زیاد مشکل تو اون یه ساعت حل نمی‌شه ولی احتمالش خیلی زیاده که نگرانی که اون مساله باعثش شده و اون صدای کذایی رو کم کنی.تو حالت ایده‌آل، این یک ساعت باید از زمان شخصی خودت باشه. ولی احیانا اگه به خودت اومدی دیدی تو محل کاری و صدای تو ذهنت ول کن نیست، بهتره که یه ساعت وقت بذاری و آرومش کنی تا اینکه بخوای خودت رو وادار به کد زدن کنی و بعد مجبور شی روز بعد همه‌ی اون کد رو از اول بزنی یا کلی روش وقت بذاری (یا ازینا بدتر، اون کد مشکل دار تو سیستم باقی بمونه و چندین ماه یا چند سال بخوای کج دار و مریز باش تا کنی)حس پرواز (The Flow Zone)[اول این‌که عبارت حس پرواز نمی‌دونم چقدر جایگزین خوبی واسه flow zone یا اصطلاحا the zone هست ولی با توضیحاتی که تو موردای بعدی میگم، معنیش مشخص می‌شه]حس پرواز یه حالتی که شما توش عملکرد، بازده و تمرکز فوق‌العاده‌ای دارید و می‌تونید بی‌وقفه کد بزنید. وقتی تو این حالتید، حس خیلی خوبی دارید و احتمالا حس می‌کنید روئین تنید.یه نکته کوچیک که ممکنه یه مقدار بهتون کمک کنه اینه که «از حس پرواز فرار کنید» ?????. چرا آخه ???؟؟ واقعیت اینه که شما تو این حالت، عملکرد و بازده واقعا بالایی ندارید. حس پرواز صرفا یه حالت خفیف مدیتیشن‌طوره که توش ما حس می‌کنیم سرعتمون بالا رفته ولی نیمه‌ی تاریک ماجرا اینه که توی این حالت، یه بخش‌هایی از توانایی‌های منطقی ما عملکرد ضعیفی دارن.واقعیت اینه که توی حس پرواز، حجم کاری که انجام می‌دید بیش‌تره. ولی مشکل اینجاس که تو این حالت حواستون به موضوعات مهم‌تر و کلی‌تر (big picture) نیست. به احتمال زیاد تصمیم‌هایی می‌گیرید که احتمالا بعدا مجبورید دوباره بیاید سراغشون و اصلاحشون کنید یا حتی همه‌ی تغییرات رو برگردونید به حالت اول.البته این حس پرواز اینقدرا هم به‌درد نخور نیست [و نمی‌خوایم اونو دور بندازیم?] و وقتی داریم «تمرین» می‌کنیم اتفاقا خیلی حالت خوبیه. [یه بخش راجب «تمرین» داریم در آینده]?? موزیک گوش بدم وقتی دارم کد می‌زنم ?؟عمو باب می‌فرماید که تجربه‌ی خوبی نداره ازش و وقتی موزیک گوش می‌ده، خوب کد نمی‌زنه. به‌نظر می‌رسه موزیک گوش دادن، یه بخشی از منابع حیاتی از ذهن که واسه کد تمیز (و مطابق طراحی) زدن نیاز داریم رو مصرف می‌کنه. ⚠️ اگه موقع کد زدن موزیک گوش می‌دید هم مراقب باشید که حس پرواز بهتون دست نده.? وقتی مشغول کد زدنی، تمرکز کردی و داری کد رو از یه گردنه‌ی حساس میگذرونی که یه نفر میاد و ازت سوال می‌پرسه. چه عکس‌العملی نشون می‌دی؟ کلافه و عصبانی می‌شی؟ یا کارت رو متوقف می‌کنی و بهش جواب می‌دی؟اگه عصبانی می‌شی ممکنه به‌خطر این باشه که تو حس پروازی و دوست نداری کسی مزاحمت شه. یا داری تلاش می‌کنی که به حس پرواز برسی!البته بعضی وقت‌ها هم دلیلش اینه که واقعا داری کاری که تمرکز زیادی لازم داره رو انجام می‌دی و نباید کارت قطع شه چون رسیدن به اون مرحله‌ی ذهنی که تو اون لحظه توش هستی، انرژی و تمرکز زیادی گرفته ازت و دوباره رسیدن بهش هم راحت نیست. تو این مواقع چی‌کار کنیم؟?? برنامه‌نویسی دونفره (pair programming) که باعث می‌شه وقتی اون وقفه (سوالی که یه نفر پرسیده، تماسی که گرفته شده یا غیره) رو هندل (مدیریت؟) کردی و برگشتی، نفر دوم که تو این بازه داشته به کار روی کد ادامه می‌داده بهت کمک کنه که دوباره بیای توی باغ (مدل ذهنیت از مساله رو بازسازی کنی)? استفاده از روش TDD (تو بخش‌های بعدی بیش‌تر توضیح داده ولی خلاصه‌ش اینه که هر چیزی رو که می‌خوایم کدش رو بزنیم، اول تستش رو می‌نویسیم، بعد حداقل کدی که باعث میشه اون تست با موفقیت اجرا شه رو می‌زنیم، بعد برای مابقی عملکردی که انتظار داریم تست نویسی می‌کنیم و دوباره کد و الی آخر). وقتی قضیه رو هندل کردی و برگشتی، می‌تونی به آخرین تستی که با موفقیت اجرا نشده نگاه کنی و سریع یادت بیاد کجای مساله بودی.این واقعیت رو باید قبول کنی که بالاخره این موارد پیش میان و باهاش کنار بیای☺️ و در آخر اینکه یادت باشه که همیشه در رو پاشنه نمی‌چرخه و دفعه‌ی بعد که یه‌نفر وسط کار همکارش ازش سوال می‌پرسه تو همونی باشی که داره سوال می‌پرسه! خلق و خوی حرفه‌ای ها تو همچین مواقعی مودبانه است و دوست دارن به بقیه کمک کنن. امین ظاهردناک امین ظاهردناک Thu, 28 Apr 2022 11:49:23 +0430 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B3-%D8%A8%D9%84%D9%87-%DA%AF%D9%81%D8%AA%D9%86-izepyghrbejq (اگه قسمت‌های قبلی رو نخوندی، پیشنهاد می‌کنم قسمت ۰۰ رو اول مطالعه کنی)هر تعهدی سه بخش داره:بگی انجامش می‌دمواقعا بخوای انجام بدیانجامش بدی⚠️ بعضی وقتا خودمون یا دیگران می‌گیم که می‌خوایم یه کاری رو انجام بدیم ولی ته دلمون انگار متوجه می‌شیم واقعا قرار نیست اون کار رو انجام بدیم یا بدن! یه راهش اینه که به قلبمون رجوع کنیم واسه قضاوت که خب خیلی قابل اعتماد نیست. یه راه دیگش اینه که دنبال یه شواهدی باشیم. مثلا کلمه‌هایی که استفاده می‌شه یجوری هستن که بوی تعهد و جدیت نمیدن:لازمه/باید: مثال: آره این صفحه باید تا شنبه آماده باشه. باید تست نوشت واسه کدها.آرزو می‌کنم/امیدوارم: امیدوارم تا فردا برسهبیا (فلان کار رو بکنیم): بیا فلان کار رو انجام بدیم. بیا یروز بریم فلان جا (بدون اینکه مشخص شه دقیقا کی تو چه زمانی باید چه کاری انجام بده (بدون برنامه))? «همیشه» یه چیزی وجود داره که تماما تحت کنترل ما باشه پس «همیشه» چیزی وجود داره که بشه به انجامش متعهد شد. واسه تشخیص اینکه واقعا یه نفر (یا خودمون) قرار یه کاری رو انجام بده (بهش متعهده)، باید دنبال همچین عبارت‌هایی گشت:من … رو تا (تاریخِ) … انجام می‌دمتو جمله بالا هم مشخصه که «شما» قراره یه کاری رو انجام بدید و تاریخ انجامش هم مشخصه و خودتون رو تو شرایطی قرار دادید که اگه تو اون تاریخ تحویل ندید، بازخواست می‌شید. ترسناکه؟ باید باشه.وقتی داری راجب تاریخ تموم شدن یه کاری اطلاعات می‌دی به کسی (مدیر یا غیره)، اگر مطمئن نیستی به اون تاریخ میرسه، عدم قطعیت خودت رو بهش منتقل کن.ممکنه بعضی وقتا تو شرایطی قرار بگیری که بخوای اصول کاری (دسیپلین‌ها) رو کنار بذاری (ریفکتور کردن، تست نوشتن و غیره) که به ددلاین برسی، ولی یه آدم حرفه‌ای هیچ‌وقت این‌کار رو نمیکنه. طبق تجربه‌ی عمو باب (نویسنده کتاب)، کنار گذاشتن اصول، فقط باعث میشه کندتر جلو بری.? یکی از بزرگترین تعهدهای یه دولوپر حرفه‌ای اینه که این اصول رو رعایت کنه. بقیه تعهداتش باید زیرمجموعه‌ی این تعهد باشن. (مثلا وقتی میگه تا فلان تاریخ تحویل می‌دم، یعنی کدی که اصول توش رعایت شده، تست براش نوشته شده، به اندازه‌ی کافی تمیزه و … رو تا اون تاریخ تحویل می‌دم)? دولوپرهای حرفه‌ای، حدود توانایی خودشون رو می‌دونن. میدونن چقدر اضافه کار مفید می‌تونن انجام بدن و میدونن هزینه‌ی این اضافه کار چیه (چند روز نیاز به استراحت دارن، چه لطمه‌ای به زندگی شخصیشون می‌خوره و غیره) امین ظاهردناک امین ظاهردناک Sun, 17 Apr 2022 00:32:10 +0430 https://virgool.io/Rocket/%D9%86%D9%87-%DA%AF%D9%81%D8%AA%D9%86-hgmxzqerpdgr آدم‌های حرفه‌ای، شجاعت نه گفتن به مدیرشون رو دارن. یه مدیر خوب قطعا به‌دنبال نیروهایی هست که همچین شجاعتی داشته باشن چون اگه غیر از این باشه، هیچ کاری رو نمیشه با موفقیت به آخر رسوند.بهترین تصمیم‌ها وقتی گرفته می‌شن که دو نقش وجود داره که در تقابل با هم هستن و هر کدوم با قدرت از مواضعشون دفاع می‌کنن و دنبال اهداف خودشون هستن.مثلا وقتی مدیر شما میگه که صفحه لاگین تا فردا باید آماده باشه، دنبال هدف خودشه (داره کارشو انجام می‌ده). از طرفی اگه تو میدونی که قطعا صفحه لاگین تا فردا آماده نمیشه، اگه بگی آماده می‌شه، کارت رو درست انجام ندادی. این وظیفه‌ی تو هست که بش بگی «نه، قطعا تا فردا نمی‌رسه».درستش اینه که مکالمه‌ی بالا ادامه پیدا کنه تا دو نفر به یه توافق اصولی برسن (تو این مثال راجب زمان آماده شدن اون صفحه).طبیعیه که یه‌سری تقابل و لحظه‌های معذب‌کننده هم پیش میاد تو این مکالمه‌ها، چون دو نفر دارن از مواضع مختلفی دفاع می‌کنن. (میتونی از تکنیک «صفحه‌ی خط افتاده» استفاده کنی).موقعی که می‌خوای بگی فلان چیز به فلان تاریخ نمی‌رسه، نیاز نیست خیلی وارد جزئیات بشی چون راه رو برای micro-management باز می‌کنه.? مهم‌ترین موقعی که باید شجاعت نه گفتن رو داشت، تو مواقع حساس و حیاتیه.بازیکن تیمیِ خوبی بودن یعنی:نقش خودت رو به بهترین شکل انجام بدیوقتی واسه هم‌تیمی‌هات مشکلی پیش میاد بهشون کمک کنی? بدترین کاری که میتونی بکنی اینه که بجای «نه»، بگی «باشه، سعی می‌کنم»؛اینکه بگی تلاش می‌کنم، یعنی تا الان داشتی کم‌کاری می‌کردیاینکه بگی تلاش می‌کنم، یعنی با تلاش بیش‌تر میشه به هدف کذایی رسیدوقتی میگی تلاش می‌کنم، تو داری خودت رو متعهد می‌کنی به «موفقیت» و به‌سرانجام رسوندن اون کار و داری یه باری رو به دوش خودت میذاری.اگه نقشه‌ی جدیدی نداری، اگه کارهایی که می‌کنی رو تغییر ندی، اگه دقیقا همون کارهای قبلی رو بکنی، پس «سعی می‌کنم» یعنی چی؟! ⚠️⚠️ اگه اینجوره، احتمالا صرفا واسه حفظ ظاهر و فرار از یه مکالمه‌ای که معذبت می‌کنه اون قول رو داری می‌دی.ممکنه طرف مقابل واسه انداختن تو توی دام «تلاش می‌کنم»، تکنیک‌های مختلفی بزنه، رفاقتی، خواهش، نمایش قدرت و غیره. مهم اینه که تو پوزیشن خودت رو حفظ کنی (مثل کوه سرجای خودت بمونی).اگه پیش‌بینی از زمان تحویل دقیق نیست (به هر دلیل)، این عدم قطعیت رو منتقل کن به مدیریت.? اگه مدیر مستقیم داره تخمین رو نادیده می‌گیره و حدس می‌زنی که داره وعده اشتباه به مدیر بالادستی می‌ده، دو راه داری:سند و مدرک جمع کنی که تو به مدیر مستقیم گفتی که نمی‌رسه و صبر کنی تا ددلاین و پروژه نرسه و عواقبش به شرکت و تیم تحمیل شههمون موقعی که متوجه موضوع می‌شی، به مدیر بالادستی بگی و تیم و شرکت رو نجات بدیتو تیم‌های درست و حسابی، آدما با هم حرف می‌زنن تا به یه نقشه‌ای برسن که مورد توافق همشونه. بعضی وقت‌ها تنها راه رسیدن به «بله» درست، اینه که از «نه» گفتن نگران نباشی.بعضی از ذی‌نفع‌ها (چه مشتری خارجی یا مدیریت داخلی) یاد گرفتن چی‌کار کنن که دولوپر با سرعت بنز کار کنه و پروژه رو در اسرع وقت تحویل بده (این‌که چه چیزایی مثل کیفیت کد، زندگی شخصی دولوپر و غیره قربانی می‌شن هم احتمالا واسشون خیلی مهم نیست). مراحلش از این قراره:به دولوپر میگی پروژه ساده‌سفیچرها رو کم کم اضافه می‌کنی به این شکل که به دولوپر(ها) میگی که «خب معلومه که فلان چیز لازمه»، یا «مگه میشه نرم‌افزار فلان باشه ولی بهمان فیچر رو نداشته باشه»، یا «این که دیگه گفتن نداره، معلومه» و غیره.یه ددلاین نزدیک میذاری که دولوپر مجبور شه با حداکثر توان و سرعت کد بزنه، بعد که پروژه نرسید، ددلاین رو یکم جابجا می‌کنی و همین کار رو تکرار می‌کنی.اگه «بله»ای که می‌گی، به قیمت کنار گذاشتن دسیپلین‌های حرفه‌ایت تموم میشه، داری به احتمال زیاد اشتباه می‌زنی و این مسیری که می‌ری نه تنها مشکل رو حل نمی‌کنه، که احتمالا بهش اضافه هم می‌کنه. امین ظاهردناک امین ظاهردناک Mon, 04 Apr 2022 22:09:29 +0430 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B1-%D8%AD%D8%B1%D9%81%D9%87-%D8%A7%DB%8C-%D8%A8%D9%88%D8%AF%D9%86-wdojj5dpejns یکی از مهمترین جنبه‌های حرفه‌ای بودن، مسئولیت‌پذیر بودنه.اگه هزینه‌هایی که از محل کار میشه از جیب خودت باشه چطور حساسیت نشون میدی را کارها و هزینه‌هایی که دارن؟ باید پول کارفرما هم واست همین‌طور مهم باشه.اجتناب‌ناپذیر بودن باگ‌ها معنیش این نیست که ما به‌عنوان دولوپر، مسئولیتی در قبالشون نداریم?! هرچقدر که حرفه‌ای‌تر بشی، باید کدی که مینویسی هم باگ‌های کم و کمتری داشته باشه.? باید به این موضوع هم دقت کرد که هر باگی چرا اتفاق افتاده و چیکار میشه کرد که دیگه اتفاق نیفته.یکی از جنبه‌های مسئولیت پذیری تست کردنه.باید هدف این باشه که کدی که به بخش کنترل کیفیت (QA یا بخش مشابه) می‌رسه، هیچ باگی توش نباشه. خلاف این کار باعث میشه.هزینه‌ی اضافی تحمیل بشه به شرکت (چون حتی باگ‌های نسبتا واضحی رو که دولوپر می‌تونه پیدا کنه و دیباگ کنه هم میرن تو QA و اونجا پیدا می‌شن و کد برگشت می‌خوره به تیم توسعه و بعد دیباگ و دوباره ارسال به QA و الی آخر و این رفت و برگشت هزینه داره)باعث میشه برنامه‌ریزی‌ها بهم بریزهخدشه وارد شه به اعتمادی که شرکت به تیم توسعه دارهtest it [your code] seven ways to Sunday!میفرماید که: کُدت رو تا جای ممکن (تا خرتلاق) تست کن.(درستش همین خرتلاقِ، نه خرتناق?)تست کردن دستی زمان زیادی می‌بَره. درسته. بخاطر همینه که باید بریم سراغ اتوماتیک کردن تست‌هامون.هر خط از کد باید تست داشته باشه. والسلام.این غیر واقع بینانه نیست؟ معلومه که نه. ما این کدها رو داریم می‌نویسیم که کار کنن (دعا واسه آمینه). تنها راهی که میشه مطمئن بود از این موضوع اینه که تست بشه!تست نوشتن واسه بعضی از کدها سخت نیست؟ چرا.دلیلشم اینه که کد جوری نوشته شده که تست نوشتن واسش سخته! راه حلش چیه حالا؟اینه که کدت رو جوری بنویسی که تست نوشتن واسش ساده باشه!? بهترین راهشم اینه که اول تست بنویسیساختار (structure) کد خیلی مهمهنباید ساختار فدای عملکرد (functionality) بشه.Boy Scout rule: always check in a module cleaner than when you checked it out.قانون پسر پیشاهنگ: همیشه وقتی با یه کدی کار می‌کنی، سعی کن کدی که تحویل می‌دی تمیزتر از کدی باشه که تحویل گرفتی? قانون پسر پیشاهنگ نشون میده که ما باید مدام کد رو تغییر بدیم و بهتر کنیم. حالا خطرناک نیست این کار؟ مدام کدی که کار میکنه رو تغییر بدیم؟ چرا خطرناکه. ولی اگه واسش تست نوشته باشی، بعد از هر تغییر میتونی تست‌ها رو اجرا کنی و مطمئن شی که آب از آب تکون نخورده!مسئول پیشرفت شغلی تو فقط خودت هستی، نه کارفرما یا شرکتی که واسش کار میکنیتو هفته باید ۴۰ ساعت واسه شرکت کار کنی و ۲۰ ساعت رو یادگیری و مهارت‌های خودت⚙️ این ۲۰ ساعت که میشه حدودا ۳ ساعت در روز می‌تونه شامل پادکست گوش دادن، خوندن، یادگرفتن یه زبان برنامه‌نویسی جدید و غیره باشه. تو این مدت نباید رو پروژه‌ی کارفرما کار کنی مگه اینکه مرتبط باشه با چیزی که داری یاد می‌گیری که در این صورت اوکیه.میشه این کار رو هم انجام نداد. مشکلی نداره. فقط دیگه نباید خودت رو «حرفه‌ای» بدونی.شاید فک کنی این ۲۰ ساعت باعث میشه که زده شی از کار. ولی برعکسه! این کار باعث میشه اون اتفاق نیفته! ? چرا؟ چون توی این ۲۰ ساعت باید کارایی رو انجام بدی که بهت حال میدن. از جنس اون چیزایی که باعث شدن اون روز اول علاقه پیدا کنی به برنامه‌نویسی! خلاصه باید بهت (عمدتا) خوش بگذره تو این ۲۰ ساعت.تو مهندسی نرم‌افزارها ایده‌ها، تکنیک‌ها، ابزارها و ترمینولوژی (عبارات و کلمات) گسترده‌ای وجود داره. اگه میخوای حرفه‌ای باشی، باید یه بخش قابل توجهی از این‌ها رو بلد باشی و حجم چیزهایی که بلدی هم باید مدام در حال افزایش باشه.? که چی حالا؟ واقعیت اینه که اِنقد این چیزا زیادن و سرعت زیاد شدنشون هم زیاده که هرچیزی من الان یاد بگیرم بعد از یه مدت قدیمی و بلا استفاده میشه.بله. سرعت رشد این حوزه خیلی خیلی زیاده. ولی از طرفی ما همون if و elsهای ۵۰ سال پیش رو داریم می‌نویسیم.موضوعات خیلی کمی از ۵۰ سال پیش تا الان کلا بلا استفاده شدن. مثلا موضوعی مثل توسعه‌ی آبشاری تاریخ مصرفش تموم شده ولی معنیش این نیست که ما نیاز نیست بدونیم چی هست. باید خودش و نقاط قوت و ضعفش رو بدونیم (تا بتونیم مزایای سیستم‌های چابک رو مثلا بهتر درک کنیم)⚙️ حداقل چیزهایی که هر دولوپر حرفه‌ای باید بدونه اینان:الگوهای طراحی:۲۴ تا الگوی طراحی کتاب Gang of Fourهمینطور الگوهای معرفی شده تو کتاب‌های Pattern-Oriented Software Architectureاصول طراحی:اصول SOLIDاصول componentروش‌ها:WaterfallXPScrumLeanKanbanStructured DesignStructured Analysisاصول کاری (دسیپلین‌ها):TDDطراحی شی گراStructured ProgrammingContinuous IntegrationPair programmingArtifact ها: باید بدونی چطور از موارد پایین استفاده کنی:UMLDFDهاStructure ChartsPetri NetsState Transition Diagrams and tablesFlow chartsDecision tablesدولوپری که نتونه تکنیک‌ها و اصول کاری (دسیپلین‌های) جدید رو یاد بگیری، هم‌رده‌هاش به سرعت رشد میکنن و اون پس‌رفت میکنه.چیزهایی رو یاد بگیر که از حاشیه‌ی امن(comfort zone)ت خارج هستن.دولوپرهای حرفه‌ای مدام رو مهارتشون کار میکنن و همیشه آماده‌ی کد زدن هستن. کاری که هر روز تو شرکت انجام میدی «اجرا» است، «تمرین» نیست.یه نوازنده رو درنظر بگیر. اگه تمرینش سر اجراهاش باشه چی میشه؟؟ هدف تمرین اصلاح و بهبود سطح مهارته و اینکه هماهنگی ذهن و انگشت‌ها باهم بالاتر بره.حوزه‌ای که توش کار می‌کنی رو بشناس (مثلا سیستم بانکی یا اتوماسیون اداری).باید اطلاعاتت در حدی باشه که بتونی خطاهایی که توی جزئیاتی که بهت ارائه میشه رو بشناسی و بتونی آگاهانه تحلیلش کنی و اونو به چالش بکشی.مشکل کارفرمای تو، مشکل توئه! باید درک کنی مشکل چیه و به سمت راه حلش حرکت کنی. سعی نکن یه خطی بین خودت و کارفرما (و کلا برنامه‌نویس‌ها و کارفرماها) بکشی.یه آدم حرفه‌ای، کارش رو میشناسه، احساس افتخار می‌کنه از کاری که میکنه، به توانایی‌هاش اعتماد داره و ریسک‌های بزرگ و حساب‌شده میکنه که مبتنی بر اون اعتماد هستن. البته این رو هم می‌دونه که ممکنه بعضی وقتا شکست بخوره. امین ظاهردناک امین ظاهردناک Tue, 29 Mar 2022 17:13:36 +0430 https://virgool.io/@amin.dannak/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-the-clean-coder-%D9%82%D8%B3%D9%85%D8%AA-%DB%B0%DB%B0-tz3m3k3pghyn برنامه‌نویس حرفه‌ای بودن دقیقا یعنی چی؟ باید چیکار کنم که حرفه‌ای شم؟هر چی کارفرما گفت باید بگم چشم؟چطور باید تسک‌ها رو تخمین بزنم؟ اگه تخمین زدم یعنی تعهد دادم که تا اون موقع برسه؟ اگه نرسید وظیفمه که بی‌خوابی بکشم تا تسک برسه؟واقعا اصولی مثل SOLID مهم هستن یا تو شرایط حساس مثل وقتی که ددلاین پروژه نزدیکه باید بیخیالشون شد؟چطور از دست تست کردن دستی نرم‌افزار خلاص شم؟ راه بهتری هم هست؟ اگه به جواب قانع کننده‌ای واسه این سوال‌ها یا سوال‌های شبیه اینا نرسیدید، این کتاب احتمالا می‌تونه کمکتون کنه.اگه یه مدتی از دولوپر بودنتون میگذره، احتمالا اسم این کتاب رو شنیدید (همینطور Clean Code و Clean Architecture). این کتاب راجب یه موضوع صحبت می‌کنه، اینکه «یه دولوپر حرفه‌ای چطور فکر و رفتار می‌کنه».من خوندن این کتاب رو تازه تموم کردم و با اینکه از خوندن یه قسمت‌هاییش سیر نمی‌شدم و پیش میومد که چند ساعت نتونم کتابو زمین بذارم، وقتی تموم شد متوجه شدم که خیلی از مطالبش تو ذهنم نیست با اینکه هم خط کشیدم زیر مطالب مهم و هم گوشه و کنار متن اصلی، یه اظهار فضل‌هایی کردم و خلاصه نوشتم و غیره. خب پس این همه وقت گذاشتم رو این کتاب واسه چی؟? تصمیم گرفتم چکیده‌ی هر فصل رو بنویسم تا بتونم بعدا سریع‌تر کتاب رو مرور کنم و مطالب واسم یادآوری شه. مطالبی که می‌نویسم رو هم اینجا با شما به اشتراک می‌ذارم. بدرد من که خورد، باشد که بدرد شما هم بخوره.⚠️ این کتاب راجب آموزش برنامه‌نویسی نیست و اینکه چطور میشه اصولی‌تر برنامه‌نویسی کرد. اگر دنبال این موضوع هستید باید برید سراغ کتاب Clean Code.⚠️ نکته مهم اینه که من نکته‌هایی که به نظر خودم مهم اومده رو می‌نویسم نه همه‌ی نکته‌های کتاب رو.⚠️ این کتاب واقعا فوق‌العاده‌س و به نظرم هر دولوپری باید این کتاب رو بخونه، پس اگه تو متن‌هایی که من می‌نویسم خیلی ارتباط برقرار نکردید با کتاب، حتما یه شانس به خود کتاب بدید. توی کتاب‌ها مطالب با زبان متفاوتی اومده و مثال‌ها و داستان‌هایی هست که تو این خلاصه‌ها نیست. خلاصه اینکه خوندن این خلاصه‌ها احتمالا جایگزین خوندن کتاب و تاثیری که اون روی شما میذاره نیست.? متن‌هایی که می‌ذارم، مستقیم از متن اصلی (انگلیسی) خلاصه و ترجمه کردم و بخاطر همین میشه گفت مطالب به منظور نویسنده‌ی اصلی (عمو باب) نزدیکن (از یه ترجمه‌ی دیگه نیست که برداشت اون مترجم از متن هم بین برداشت من و منظور عمو باب قرار گرفته باشه).وقتی خلاصه‌ی قسمت‌ها اضافه میشه، همین‌جا لینکشون رو اضافه می‌کنیم و می‌تونید از همین پست به‌عنوان فهرست خلاصه‌ها استفاده کنید.امیدوارم که به کارتون بیان مطالب. اگه نظر، انتقاد یا پیشنهادی هم داشتید حتما باهام در میون بذارید.قسمت ۰۱ - حرفه‌ای بودنقسمت ۰۲ - نه گفتن قسمت ۰۳ - بله گفتنقسمت ۰۴ - کد نویسی (بخش ۱)قسمت ۰۴ - کد نویسی (بخش ۲)قسمت ۰۵ - توسعه تست محور (TDD)قسمت ۰۶ - تمرینقسمت ۰۷ - تست پذیرشقسمت ۰۸ - استراتژی‌های تست کردنقسمت ۰۹ - مدیریت زمان (بخش ۱)اگه به دنبال یادگیری Git و GitHub هستید یا دوست دارید گیت رو اونجوری که باید، دوباره یاد بگیرید، دعوت می‌کنم از دوره‌ی «Git، یکبار برای همیشه» من دیدن کنید. تو این مقاله می‌تونید بیش‌تر با این دوره و ویژگی‌هاش آشنا شید. امین ظاهردناک امین ظاهردناک Tue, 29 Mar 2022 16:40:54 +0430