https://virgool.io/feed/@mehrdadep مهندس نرم افزار، نویسنده، شاعر و خیال پرداز fa 2026-04-15 10:34:39 https://files.virgool.io/upload/users/62191/avatar/koQIRZ.jpg?height=120&width=120 https://virgool.io/@mehrdadep https://virgool.io/@mehrdadep/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7-%DA%AF%D9%81%D8%AA%DA%AF%D9%88-%D8%A8%D9%87-%D8%A2%D8%A8%D8%A7%D8%AF%DB%8C-%D8%A8%D8%B1%DA%AF%D8%B1%D8%AF%DB%8C%D9%85-%DB%8C%D8%A7-%D8%A8%D8%A7%D8%B2%D8%AE%D9%88%D8%B1%D8%AF-%D9%85%D9%88%D8%AB%D8%B1-%D8%AF%D8%B1-%D8%AA%DB%8C%D9%85-lm26iot5pqzw درباره ساختن اعتماد تو تیم، تو پست «چرخ‌دنده‌ها برای که می‌شکنند» کمی حرف زدم. بخش بزرگی از ساختن اعتماد بین اعضا و مدیر تیم، با بازخورد (Feedback) گره خورده. بازخورد گاهی اوقات چراغ راه ادامه مسیرمونه و گاهی وقتا هم آخرین شمع امید رو خاموش می‌کنه.به طور خلاصههر وقت که نیاز بود، با هر چارچوبی که انتخاب کرده‌اید (که حداقل دو مشخصه «شفافیت» و «بدون قضاوت بودن» رو داشته باشن)، می‌تونید از ابزار بازخورد برای بهتر کردن وضعیت تیم و آدم‌ها استفاده کنید.گفتگوی حساس چیه؟کری پاترسون و همکاراش می‌گن گفتگوهایی که شامل موضوعات مهم، اختلاف نظر و احساسات قوی باشن، می‌تونن تبدیل به گفتگوی حساس بشن. این گفتگوها هم تو محیط کار و هم تو روابط شخصی پیش می‌آن. بازخورد گاهی وقت‌ها خودش مدلی از گفتگوی حساسه، اما اگه به موقع و درست انجام بشه، می‌شه قبل از اینکه احساسات یا اختلاف نظرها خیلی جدی بشن، از حساس شدن گفتگو جلوگیری کرد. خلاصه اینکه اگه بازخورد تبدیل به یک گفتگوی حساس شد، به تعویق انداختنش فقط بدترش می‌کنه. پس هر چی زودتر، بهتر!کی بازخورد بدیم؟اگه مدیر یه تیم از کارشناس‌ها هستین، بهتره تو دوره‌های مشخص و ثابت بهشون بازخورد بدین. بازخورد با مفاهیمی مثل ارزیابی عملکرد و جلساتی مثل گفتگوی یک به یک، خیلی شبیه به هم هستن. بنابراین می‌تونین بسته به شرایط تیمتون، این گفتگوها و جلسات رو با هم ترکیب کنین. تو شرایط خاص، مثل اتفاقات غیرمنتظره (رفتار نامناسب یکی از اعضا، ضعف شدید تو انجام کارها و...)، می‌تونین جدا از جلسه ثابت، یه جلسه بازخورد فوق‌العاده هم داشته باشین. علاوه بر جلسات رسمی و دوره‌ای، بازخورد می‌تونه خارج از چارچوب یک جلسه رسمی و به صورت یه گفتگوی عادی شکل بگیره. بازخوردهای بی‌درنگ و غیررسمی به ما این امکان رو می‌ده که در لحظه و بلافاصله بعد از یک اتفاق، چه مثبت و چه منفی، نظر خودمون رو بیان کنیم. این نوع بازخورد چون فاصله زمانی کمی با خود اتفاق داره، جزئیاتش واضح‌تره و تاثیر بیشتری روی فرد می‌ذاره. مثلاً اگه یکی از اعضای تیم یه کار فوق‌العاده انجام داد، همون لحظه بهش بگید که کارش چقدر ارزشمنده. این کار باعث می‌شه حس خوب و انگیزه در تیم جاری بشه و به تقویت رفتارهای مثبت کمک می‌کنه.اگه مدیری هستین که تیم‌های دیگه رو هم مدیریت می‌کنه (که هر کدوم مدیر خودشون رو دارن)، بهتره جلسات بازخوردتون فقط با مدیران باشه. برای اینکه داده‌های لازم برای این بازخوردها رو به دست بیارین، می‌تونین جلسات skip-level رو با کارشناس‌های تیم‌ها برگزار کنین. وظیفه شما تو این ساختار اینه که مطمئن بشین بازخورد کارشناس‌ها توسط مدیرشون تو بازه‌های ثابت بهشون داده می‌شه. برای ارتباط موثر با کارشناس‌ها، بهتره از جلسات یک به یک استفاده کنین.بازخورد با چیا همپوشانی داره؟ارتباط بازخورد با ساخت اعتمادتو روش ایجاد اعتماد در تیم از طریق تفویض اختیار که تو پست قبلی توضیحش دادم، بخش‌هایی که مربوط به بررسی راه‌حل یا نتیجه می‌شن، با بازخورد ارتباط مستقیم دارن. با بازخورد صادقانه، صریح و شفاف، می‌شه حتی تو مواقع شکست، میزان اعتماد رو تو تیم بالا برد. حواستون باشه که بازخورد منفی بهتره به صورت فردی داده بشه، اما برای بازخورد مثبت می‌تونین ارائه بازخورد رو به جلسات تیمی موکول کنین. بازخورد مثبت تو جلسات تیمی می‌تونه به تقویت رفتارهای خوب، افزایش انگیزه و اعتمادبه‌نفس و شفافیت تو استانداردها کمک کنه و تیم رو به سمت عملکرد بهتر ببره.همپوشانی بازخورد با ارزیابی عملکردبازخوردهای دوره‌ای و ثابت می‌تونن به سنجه‌های (KPI) ارزیابی عملکرد گره بخورن. روش‌های مختلفی برای ارزیابی عملکرد و انتخاب سنجه‌های مناسب برای افراد و تیم وجود داره (احتمالا در آینده جدا درباره‌اش می‌نویسم). در نهایت، یکی از ورودی‌های بازخورد می‌تونه خروجی این سنجه‌ها و بررسی و تحلیلشون باشه.بازخورد در جلسات یک به یکجلسات یک به یک، قالب‌ها و سوالات از پیش تعیین شده خیلی زیادی دارن. تو این جلسات می‌شه به موضوعات مختلف، از مسیر شغلی تا روحیه افراد تو تیم، پرداخت. باید حواسمون باشه که محتوا و نوع سوال‌ها باید قبل از جلسه به اعضا اطلاع داده بشه تا بتونن از قبل بهشون فکر کنن. اما بازخورد کجای این جلسه قرار می‌گیره؟ با اینکه لزومی نداره بخشی از جلسه یک به یک رو به ارائه بازخورد اختصاص بدیم، اما می‌شه از ظرفیت این جلسه استفاده کرد و بخشی از زمانش رو برای بازخورد گذاشت. جلسه یک به یک و بازخورد هر دو دوره‌ای هستن و با کمک این اشتراک می‌شه ادغامشون کرد.چطور بازخورد بدیم؟چارچوب‌های امتحان‌شده زیادی برای ارائه بازخورد وجود داره. اکثرشون تو مفاهیم مشترکن و فقط تو قدم‌ها و اسم‌ها فرق دارن. من سه چارچوب رو اینجا معرفی می‌کنم که برای بازخوردهای منفی و مثبت می‌شه ازشون استفاده کرد. اگه چارچوب دیگه‌ای رو انتخاب کردین، حواستون باشه که شرح وضعیت فعلی و قدم‌های پیش‌رو به خصوص برای بازخوردهای منفی خیلی مهم هستن. برای بازخوردهای مثبت، شرح وضعیت فعلی و نتیجه اهمیت بیشتری دارن. به طور کلی تو بازخورد انتظار داریم از کلی‌گویی پرهیز کنیم و درباره یک یا چند موضوع مشخص حرف بزنیم. همیشه باید تاثیرات عینی و شرایط موجود رو هم در نظر بگیریم.چارچوب اول: مدل SBI (Situation, Behavior, Impact)این مدل یک چارچوب سه مرحله‌ایه که به کسی که بازخورد می‌گیره کمک می‌کنه دقیقاً بفهمه در مورد چه چیزی حرف می‌زنید.موقعیت (Situation): اول، موقعیت یا شرایط خاصی که رفتار/موضوع مورد نظر تو اون اتفاق افتاده رو توضیح بدید. این مرحله به شفاف شدن مکالمه کمک می‌کنه. به جای اینکه بگید: «تو اسپرینت قبلی»، بهتره بگید: «تو جلسه تیم در روز دوشنبه قبل، زمانی که درباره پروژه آلفا صحبت می‌کردیم».رفتار (Behavior): رفتاری که مشاهده کردید رو کاملاً عینی و بدون قضاوت بگید. به جای اینکه بگید: «به فلانی بی‌احترامی کردی»، بگید: «سه بار صحبت‌های فلانی رو قطع کردی».تاثیر (Impact): تأثیر مستقیم اون رفتار رو روی خودتون، تیم، یا پروژه توضیح بدید. این تأثیر می‌تونه مثبت یا منفی باشه. مثلاً: «قطع کردن صحبت‌های فلانی باعث شد که رشته کلام از دستش در بره و نتونه توضیحاتش رو کامل بده».چارچوب دوم: مدل COIN (Context, Observation, Impact, Next Steps)مدل COIN یه نسخه کامل‌تر از SBI هست که یک مرحله اضافی برای قدم‌های بعدی داره. این مدل برای وقتی مناسبه که می‌خواید بازخورد رو به یه برنامه عملیاتی مشخص تبدیل کنین.موقعیت (Context): مثل SBI، موقعیت و شرایطی که رفتار تو اون رخ داده رو مشخص کنین.مشاهده (Observation): رفتار خاص و قابل مشاهده رو توضیح بدید. تأکید این مرحله روی واقعیت‌هاست و از برداشت‌های شخصی دوری می‌کنه.تاثیر (Impact): تأثیر رفتار رو روی خودتون، بقیه، تیم یا محصول و ... بیان کنین.قدم‌های بعدی (Next Steps): این مرحله، که مهم‌ترین تفاوت با SBI هست، به آینده نگاه می‌کنه. اینجا باید به صورت مشترک با فردی که بازخورد می‌گیره، در مورد کارهای مشخصی که باید برای بهتر شدن وضعیت انجام بشه، به توافق برسین. مثلاً: «تو جلسات بعدی، لطفاً اجازه بده صحبت‌های هر فرد تموم بشه، بعد نظر خودت رو بگو».چارچوب سوم: مدل STAR (Situation, Task, Action, Result)موقعیت (Situation): اول، موقعیت یا شرایطی که رفتار خوب تو اون رخ داده رو مشخص کنین. مثلاً: «تو جلسه تیم در روز سه‌شنبه، وقتی که برای انتخاب ابزار جدید بحث می‌کردیم...».کار (Task): وظیفه‌ای که فرد تو اون موقعیت به عهده داشته رو توضیح بدید. مثلاً: «کار ما این بود که بهترین گزینه رو برای نیازهای تیم پیدا کنیم».اقدام (Action): رفتار یا اقدام مشخصی که فرد انجام داد و شما بهش افتخار می‌کنین رو بیان کنین. مثلاً: «تو با دقت به نظرات همه گوش دادی و یه جدول مقایسه‌ای دقیق از مزایا و معایب هر گزینه آماده کردی».نتیجه (Result): نتیجه مستقیم و تأثیر مثبت اون کار رو بگید. مثلاً: «این کار باعث شد که همه اعضای تیم با اطلاعات کامل‌تری تصمیم بگیرن و در نهایت یه تصمیم بهتر و سریع‌تر گرفته شد».اگه بازخورد تبدیل به یک گفتگوی حساس شد چه کار کنیم؟با دلتون شروع کنید (Start with Heart): قبل از شروع هر گفتگوی حساسی، باید نیت و هدف خودتون رو مشخص کنین. از خودتون بپرسین: «واقعاً چی می‌خوام برای خودم، برای بقیه و برای تیمم؟» این کار بهتون کمک می‌کنه تا تو طول مکالمه، از مسیر اصلی منحرف نشید و تو دام بحث و جدل‌های بی‌فایده نیفتید.فضا رو امن کنین (Make It Safe): وقتی آدما احساس خطر می‌کنن (چه فیزیکی و چه عاطفی)، سیستم عصبی‌شون فعال می‌شه و به جای منطق، از واکنش‌های دفاعی مثل سکوت یا پرخاشگری استفاده می‌کنن. برای مدیریت این وضعیت، باید یه فضای امن بسازین. این کار با نشون دادن احترام متقابل و مشخص کردن هدف مشترک ممکنه. وقتی دو طرف بدونن که بهشون احترام می‌ذارید و هر دو به یه نتیجه مثبت علاقه‌مندن، آمادگی بیشتری برای حرف زدن پیدا می‌کنن. با ساختن استخر مفاهیم مشترک می‌تونین به امن‌تر کردن فضا کمک کنین.مفهوم «استخر مفاهیم مشترک» (Pool of Shared Meaning) یکی از ایده‌های اصلی کتاب «گفتگوهای حساس» هست که نقش اساسی تو موفقیت یه مکالمه داره. این استخر، فضاییه که تو اون تمام نظرات، باورها، احساسات و داده‌های مرتبط با یه موضوع، به صورت آزادانه و محترمانه به اشتراک گذاشته می‌شن و برای همه قابل دسترسه.داستان خودتون رو بلد بشید (Master My Stories): آدما اغلب قبل از گفتگو، داستان‌هایی تو ذهن خودشون می‌سازن که تو این داستان‌ها، طرف مقابل رو فردی بد یا بی‌لیاقت تصور می‌کنن. این داستان‌ها احساسات ما رو تحریک کرده و باعث واکنش‌های تهاجمی یا تدافعی می‌شن. کری پاترسون و همکاراش پیشنهاد می‌کنن که باید داستان‌های خودمون رو بازبینی کنیم و دنبال توضیحات جایگزین باشیم. با پرسیدن سوالاتی مثل «چرا یه آدم منطقی و معقول چنین کاری می‌کنه؟» می‌تونیم از قضاوت‌های عجولانه جلوگیری کنیم و با دیدی بازتر وارد گفتگو بشیم.چطور بازخورد بگیریم و بهش گوش بدیم؟تا اینجا بیشتر در مورد بازخورد دادن حرف زدیم، اما بازخورد گرفتن هم یه مهارت خیلی مهم و کلیدیه. این کار نه تنها به رشد شخصی ما کمک می‌کنه، بلکه به تیم هم نشون می‌ده که ما به بهبود وضعیت اهمیت می‌دیم.آمادگی ذهنی: وقتی کسی بهمون بازخورد می‌ده، اولین کاری که باید بکنیم اینه که گارد نگیریم. بازخورد رو یه فرصت برای رشد ببینین، نه یه حمله شخصی. به جای اینکه به دنبال دفاع از خودتون باشین، سعی کنین با ذهنی باز به حرف‌های طرف مقابل گوش بدین.گوش دادن فعال: گوش دادن فعال (Active Listening) به این معنیه که فقط کلمات رو نشنویم، بلکه به معنای واقعی کلمه به حرف‌ها و احساسات پشتشون توجه کنیم. برای این کار:توجه کامل بدین: موقع بازخورد گرفتن، تمام حواستون رو به طرف مقابل بدین. موبایل رو کنار بذارین و حواس‌پرتی‌ها رو کم کنین. با سؤال کردن شفاف‌سازی کنین: اگه چیزی رو متوجه نشدین، از طرف مقابل بپرسین. مثلاً بگید: «می‌شه یه مثال بزنی؟» یا «منظورت از این جمله دقیقاً چیه؟». این کار نشون می‌ده که به بازخورد اهمیت می‌دین و کمک می‌کنه ابهامات برطرف بشه.حرف‌های طرف مقابل رو تکرار کنین: بعد از اینکه حرفش تموم شد، می‌تونین خلاصه‌ای از چیزی که گفت رو به زبان خودتون بگید تا مطمئن بشین درست فهمیدین. مثلاً: «پس منظورت اینه که تو جلسه دوشنبه، وقتی من سه بار حرف فلانی رو قطع کردم، باعث شد اون نتونه حرفش رو کامل بزنه؟».تشکر کردن: بعد از اینکه بازخورد رو گرفتین، از فرد بازخورد دهنده تشکر کنین. حتی اگه بازخورد سخت و ناخوشاینده، تشکر کردن نشون می‌ده که شما برای زمانی که اون فرد گذاشته و شجاعتی که برای گفتن حقیقت داشته، ارزش قائل هستین. این کار فضا رو برای گفتگوهای بعدی باز نگه می‌داره.تصمیم‌گیری در مورد قدم‌های بعدی: یادتون باشه که قرار نیست هر بازخوردی رو صددرصد قبول کنین. بعد از جلسه، در مورد بازخورد فکر کنین و تصمیم بگیرین که آیا اقدامی نیاز هست یا نه. می‌تونید با کسی که بهتون بازخورد داده، در مورد اقدامات بعدی با هم به توافق برسین.جمع‌بندیبازخورد دادن و گرفتن فقط یه مهارت مدیریتی نیست، بلکه یه فرهنگه. فرهنگی که اگه تو تیممون ریشه بدوونه، به ما کمک می‌کنه تا شفاف‌تر، صادقانه‌تر و مؤثرتر با هم کار کنیم. بازخورد بهمون نشون می‌ده کجا هستیم و برای بهتر شدن به کجا باید بریم. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Tue, 12 Aug 2025 00:33:33 +0330 https://virgool.io/@mehrdadep/%DA%86%D8%B1%D8%AE-%D8%AF%D9%86%D8%AF%D9%87-%D9%87%D8%A7-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%A9%D9%87-%D9%85%DB%8C-%D8%B4%DA%A9%D9%86%D9%86%D8%AF-%DB%8C%D8%A7-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%B1-%D8%AA%DB%8C%D9%85-%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-ekpavztozbsx وقتی یه تیم بیشتر از سه چهار نفر می‌شه، یکی از مهم‌ترین عواملی که می‌تونه چرخ‌دنده‌های همکاری مشترک رو خراب کنه یا حتی بشکونه، نبود اعتماد متقابل بین اعضای تیم با همدیگه یا راهبرشونه. حالا بیایم ببینیم یه راهبر یا مدیر تیم، چطور می‌تونه با تفویض اختیار متناسب، به مرور اعتماد ایجاد کنه و چرخ‌دنده‌ها رو به روتین عملکرد بالاشون برگردونه.انواع تفویض:به طور خلاصهتفویض بخشی از یک کار (با سطوح مختلف راهنمایی و نظارت)تفویض کل یک کار (با سطوح مختلف راهنمایی و نظارت)اعضا خودشان کار را تعریف می‌کنند (با سطوح مختلف گزارش‌دهی)کمی جزیی‌تر۱. تفویض نمی‌کنم: بعضی کارها هستن که نیاز به تصمیم‌گیری کلان دارن یا کارهایی هستن که احتمالا وقت بقیه اعضای تیم رو می‌گیرن یا نمی‌خوای شخص دیگه‌ای انجامش بده. این کارها رو خودتون انجام بدین و نتیجه رو به اعضا اعلام کنین.۲. بخشی از یه کار رو بهت می‌دم و می‌گم چطور انجامش بدی: کارهای بزرگ رو خودت می‌شکنی و بخشیش رو با روش اجرا یا راه‌حل به یکی از اعضا تفویض می‌کنی. اون عضو باید نتیجه رو باهات به اشتراک بذاره. این روش معمولا برای تازه‌کارها یا کم‌تجربه‌ها یا کسایی که تازه به تیم اضافه شدن کاربرد داره و بهشون کمک‌ می‌کنه با سریع به نتیجه رسیدن، خودشون رو برای تفویض‌های بعدی آماده کنن.۳. بخشی از یه کار رو بهت می‌دم و نمی‌گم چطور انجامش بدی اما راه‌حلت را باهام چک کن: یه کار بزرگ شکسته شده و بخشی ازش رو بدون ارائه راه‌حل یا روش اجرا به یکی از اعضا می‌سپری. اون عضو باید به راه‌حل یا راه‌حل‌های مناسب فکر کنه و یکی از اون‌ها را باهات نهایی کنه و اجراش کنه. در نهایت باید نتیجه رو باهات به اشتراک بذاره.۴. بخشی از یه کار رو بهت می‌دم، نمی‌گم چطور انجامش بدی، نیازی به چک کردن راه‌حل باهام نیست: تو این مدل فقط کافیه نتیجه کار باهات چک بشه.۵ و ۶ و ۷. این سه مدل مثل سه تای قبلی هستن اما به جای «بخشی از یه کار»، «کل یک کار» به عضو داده می‌شه.۸. بهم بگو چه کاری باید انجام بدیم و راه‌حل رو باهام چک کن و نتیجه رو باهام به اشتراک بذار.۹. بهم بگو چه کاری باید انجام بدیم و فقط نتیجه رو باهام به اشتراک بذار.۱۰. فقط نتیجه یه کاری که انجام دادی رو باهام به اشتراک بذار.تو مدل‌های اولیه تفویض باید خیلی مراقب مدیریت ذره‌بینی باشین. مرز بین توانمندسازی از طریق آموزش و اعتمادسازی با دیکته کردن کار خیلی باریکه و مسئولیت شما در شکل نگرفتن این ذهنیت که در حال مدیریت ذره‌بینی هستین خیلی مهمه. جلو رفتن در مراحل تفویض، مثل بالا رفتن از یه نردبانه، هر چی بالاتر بری، سطح اعتماد متقابل، بیشتر می‌شه.همه این مدل‌ها با بازخورد گره خوردن. چه در زمانی که دارن درست پیش می‌رن و چه در زمانی که گیر می‌کنن یا کلا شکست می‌خورن. بازخورد موثر در زمان مناسب باعث می‌شه که یه چرخه معیوب شکل نگیره و اشکالات در زمان خودشون بهبود پیدا کنن.تو همه این مدل‌های تفویض که به ترتیب برای اعضای کم‌تجربه‌تر تا اعضای با تجربه پیش می‌رن، داریم با دادن مسئولیت به اعضای تیم، اعتمادمون بهشون رو محک می‌زنیم. نتیجه مثبت در هر مدل تفویض باعث ایجاد اعتماد بین اعضا می‌شه. وقتی اعتماد شکل بگیره، شکست‌ها هم چهره‌ دیگه‌ای به خودشون می‌گیرن و به سمت پاسخگویی اشتراکی پیش می‌ریم. البته دقت کنین که در تفویض ما داریم مسئولیت و اختیار خودمون در یک کار رو به شخص دیگری می‌سپاریم. این سپردن باعث نمیشه ما دیگه پاسخگوی نتیجه کارها نباشیم. بار پاسخگویی با تفویض به شخص دیگه‌ای منتقل نمیشه. تو پست ««سمت ما نیست!»؛ در ستایش ماتریس RACI» توضیح دادم که چطور با استفاده از یه ماتریس میشه، پاسخگویی اشتراکی رو تو تیم نهادینه کرد. البته این فقط یه ابزاره و تنها راه‌حل موثر نیست. برای اینکه ببینید چطور می‌تونید از این ابزار به بهترین شکل استفاده کنید و پاسخگویی اشتراکی رو در تیم نهادینه کنید، می‌تونید اون پست رو بخونید. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Thu, 07 Aug 2025 12:41:32 +0330 https://virgool.io/@mehrdadep/%D8%A7%DB%8C%D9%86-%DB%8C%DA%A9-%D8%A8%D8%A7%D8%B2%D8%AC%D9%88%DB%8C%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA-%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87-%D9%87%D8%A7%DB%8C-%D8%A7%D9%86%D8%B3%D8%A7%D9%86-%D9%85%D8%AD%D9%88%D8%B1-hji56v7nuvto نویسه پیش‌رو با نیم‌نگاهی به کتاب معمای زیبا و تجربه‌های چند ماه اخیرم تو مصاحبه‌ها نوشته شده.تغییر شغل و شرکت استرس‌زاست، حتی برای افرادی که بارها این کار رو انجام دادن. با این حال، فرایندهای مصاحبه در حال بهبودن. خیلی از شرکت‌ها حالا به جای سوال و جواب‌های بداهه، از ارائه‌های آماده در مورد یک موضوع فنی استفاده می کنن که بازتاب بهتری از وظایف واقعی شغلی باشه. علاوه بر این، حل مسئله الگوریتمی روی تخته‌سیاه با چالش‌های کدنویسی روی لپ‌تاپ شخصی با استفاده از ویرایشگر ترجیحی کارجو جایگزین شده.علی‌رغم این پیشرفت‌ها اما مصاحبه‌ها بی عیب و نقص نیستن. بعضی از شرکت‌ها هنوز از کدنویسی روی تخته‌سیاه استفاده می کنن، اغلب به دلیل ترکیبی از اینرسی (مقاومت در برابر تغییر) و این باور که اگه اهداف استخدام برآورده شده، نیازی به بهبود فرآیند نیست.مصاحبه کردن وقتی که به درستی انجام بشه، نسبتاً ساده است. نکته کلیدی «توجه کافی به کارجوها» است.چه کنیم؟مهربان باشید: تجربه یه مصاحبه مثبت با مهربانی شروع می‌شه. مهربانی نمودهای مختلفی داره. به عنوان مثال، اگه مصاحبه بیش از زمان تعیین شده طول بکشه، به جای برنامه‌ریزی یه مصاحبه دیگه برای جبران زمان از دست رفته، چند دقیقه به کارجو فرصت بدید تا سوالاتش رو بپرسه. اگر مصاحبه‌کننده دیر کرد، زمان شروع متفاوتی که برای همه مناسب باشه رو تعیین کنید. اگر مصاحبه‌کننده‌ها به شدت محدود به زمان باشن، داشتن مصاحبه‌ای با محوریت کارجو دشوار می‌شه. مصاحبه‌کننده نامهربان اغلب سیگنال یه مشکل ساختاری تو فرآیند مصاحبه است تا یک مشکل شخصی با مصاحبه کننده.در مورد نقش توافق کنید: اطمینان پیدا کنین که همه مصاحبه‌کننده‌ها در مورد الزامات نقش و مهارت‌های مورد نیازش توافق دارن. این امر به ویژه برای نقش‌هایی مثل مدیران مهندسی، مدیران محصول یا معماران که می‌تونن بین شرکت‌ها تفاوت قابل‌توجهی داشته باشن، مهمه. برای جلوگیری از این امر، انتظارات رو در هر جلسه توجیهی تعیین کنین تا مطمئن بشین که مصاحبه‌کننده‌ها کالیبره شده‌ان. توافق بر سر مهارت‌های مورد انتظار برای یک نقش خاص می‌تونه دشوارتر از حد انتظار باشه و نیاز به صرف زمان قابل توجهی با مصاحبه‌کننده‌ها داره.سیگنال‌ها را پیدا کنید: بعد از تعریف مهارت‌های مورد نیاز، فرآیند مصاحبه رو به مجموعه‌ای از جلسات مصاحبه ساختاربندی کنین که در مجموع سیگنال‌های مختلف مورد انتظارتون رو پوشش بدن. بهتره هر مهارت، توسط دو مصاحبه‌کننده مختلف برای افزونگی پوشش داده بشن. مطمئن بشین که فرمت مصاحبه در واقع سیگنال‌های مورد نظر رو استخراج می‌کنه. به عنوان مثال، به جای درخواست از کارجو برای توضیح معماری در لحظه، ازش بخواهید یه ارائه آماده رو ارائه بده. به جای کدنویسی روی تخته سیاه، ازش بخواهید کد را روی لپ‌تاپ خود اشکال‌زدایی کنه. می‌تونید ازشون بخواهید یه محصول یا ویژگی موجود یه محصول رو ارائه بدن یا جلسه مصاحبه رو تبدیل به تمرین ایفای نقش (Role Playing) کنید. نکته کلیدی اینه که همیشه رویکردهای جدید رو برای کشف سیگنال‌های مورد نیاز امتحان کنید.آماده باشید: بعد از مشخص شدن نقش و سیگنال مورد نظر، برای پیدا کردن سیگنال‌ها آماده بشید. آماده نبودن یه نقص اساسی و نشان دهنده بی احترامی به زمان کارجو، تیم و خودتونه. آمادگی بیشتر به شرکت بستگی داره تا به فرد. شرکت‌هایی که مصاحبه‌کننده‌ها رو آموزش می‌دن، مصاحبه‌ها را تو اولویت می‌ذارن و حجم کاری قابل تحملی را برای مصاحبه‌کننده در هفته حفظ می‌کنن، به طور کلی عملکرد بهتری دارن. اگر مصاحبه‌کنند‌ه‌ها اغلب آماده نیستن، احتمالاً مشکلی ساختاری وجود داره که باید بهش رسیدگی کرد.ابراز توجه کنین: مطمئن باشین که کارجو می‌دونه که شما علاقه‌مند به گفتگو و به طور بالقوه کار باهاش هستید. در زمان ارسال پیشنهاد شغلی، از همه مصاحبه‌کننده‌ها بخواهید یادداشتی برای کارجو ارسال کنن که نشون بده از مصاحبه لذت بردن. این می‌تونه در زمان تصمیم‌گیری در مورد پذیرش یا عدم پذیرش پیشنهاد بسیار ارزشمند باشد.حلقه‌های بازخورد ایجاد کنین: مصاحبه برای هیچ یک از افراد درگیر طبیعی نیست. با تمرین، می‌شه بهبودش داد اما به راحتی می‌تونه تبدیل به یه کابوس بشه. بنابراین، حلقه‌های بازخورد برای مصاحبه‌کننده‌ها و طراح فرآیند مصاحبه ایجاد کنین. مصاحبه‌های جفتی، مصاحبه‌های تمرینی و جلسات هماهنگی هفتگی می‌تونن به بهبود فرآیند کمک کنن. مصاحبه‌کننده‌های جدید باید با مشاهده مصاحبه‌کننده با تجربه‌تر شروع کنن. بعد از هر مصاحبه، هر مصاحبه‌کننده باید به طور مستقل بازخورد خودش رو قبل از بحث در مورد مصاحبه با هم بنویسه. علاوه بر بازخورد از مصاحبه‌کننده‌ها، صاحبان یا طراحان چرخه مصاحبه هم به بازخورد نیاز دارن. بهترین منبع، کارجوی در حال مصاحبه است. همچنین می‌تونین ازشون بخواهید که بازخورد خودشون رو به صورت ناشناس تو سایت های شغلی بگذارن.قیف رو بهینه کنید: بعد از ایجاد اصول اولیه، فرآیندی پایدار ایجاد کنین. از ابزارهای مختلف برای هر مرحله از فرآیند استفاده کنید (پیدا کردن کارجوها، مصاحبه‌های تلفنی، چالش‌های آفلاین، مصاحبه‌های حضوری، پیشنهادات و غیره) و شاخص‌هاشون رو در طول زمان بررسی کنید. اگر نسبت رزومه‌های معرفی‌شده به ارسال مستقیم کاهش پیدا کرد، احتمالاً مشکلی وجود دارد. اگر نرخ پذیرش پیشنهاد کاهش پیدا کرد، ممکنه پیشنهادات‌تون به اندازه کافی بالا نباشن یا بهترین مصاحبه کننده شما فرسوده شده باشه. به داده ها توجه کنید و به بازخورد کارجوها گوش بدید. بهینه سازی قیف واقعاً در مورد تجزیه و تحلیل صریح فرآیندهای شما است و باید آخرین اولویت باشد، چرا که بدون شش اولویت اول، تجزیه و تحلیل‌ها کمکی نمی‌کنن و حتی ممکنه گیج‌تون کنن.مهم ترین جنبه یک مصاحبه خوب اینه که زمان کافی بهش اختصاص بدید و نسبت به اثربخشی فرآیند فعلی خودتون شک داشته باشید. از طریق تکرار و بهبود مستمر، فرآیندتون می‌تونه در نهایت به تاثیرگذاری خوبی برسه. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Mon, 27 Jan 2025 14:10:46 +0330 https://virgool.io/@mehrdadep/%D8%B1%D8%AF%D9%BE%D8%A7-%D8%AF%D8%B1-%D8%AC%D8%B3%D8%AA%D8%AC%D9%88%DB%8C-%D8%AD%D9%84%D9%82%D9%87-%DA%AF%D9%85%D8%B4%D8%AF%D9%87-%D8%AF%D8%B1-%D8%A7%D8%B1%D8%B2%DB%8C%D8%A7%D8%A8%DB%8C-%D8%B9%D9%85%D9%84%DA%A9%D8%B1%D8%AF-%D9%88-%D9%85%D8%B3%DB%8C%D8%B1-%D8%B4%D8%BA%D9%84%DB%8C-htia5gljpbv6 هشداراین سیستم در پاسخ به شرایطی خاص و در زمینه‌ منحصر به فرد خودش ایجاد شده و جوابی برای همه شرایط نیست.زمینهوجود سیستم نردبان شغلی در شرکتنیاز به راه‌اندازی فرایند ارزیابی عملکرد فردینیاز به طراحی مسیر شغلی اعضای تیم توسط تیم‌لیدمقدمه - ارزیابی عملکردفرایند ارزیابی عملکرد، حلقه‌ گم‌شده تیم ما در سیستم مدیریت عملکرد بود. این نیازمندی تو تیم، ابتدا خودش رو با درصد تحقق‌های زیر ۵۰ درصد، تو گروه‌های پنج شش نفره، نشون داد. ما برای این‌که اسیر مدل‌های موجود ارزیابی عملکرد فرد به فرد نشیم (در واقع افراد رو به اعداد تبدیل نکنیم) تو دوره‌های مختلف، روش‌های مختلفی رو تست کردیم.تست اول: ارزیابی عملکرد به شکل گروهی و روی ساب‌تیم‌ها با استفاده از KPIهای مشخص در دوره‌های کنترلی دو هفته‌ای انجام می‌شد. این مدل ارزیابی ما رو با مشکلات آشنا می‌کرد اما نمی‌تونست به درستی ما رو به ریشه مشکل نزدیک کنه. بعد از دو ماه (۴ دوره) تست این مدل رو کنار گذاشتیم. چون فقط نتیجه رو می‌دیدیم اما دیدی به شرایط و علت‌های بروز این نتایج پیدا نمی‌کردیم.تست دوم: ارزیابی عملکرد فردی بالا به پایین: تو این مدل، تو دوره کنترلی دو ماهه، عملکرد هر فرد توسط تیم‌لید بررسی و گزارشی در قالب ایمیل، برای فرد ارسال می‌شد. تو این گزارش، عملکرد فرد (فنی) در گیت (مشارکت در ریویوها، کیفیت مرج‌ها و …) و جیرا (کار تیمی و درصد تحقق کارها و …) سنجیده می‌شدن و بر اساس عملکرد فرد، مسیری برای بهبود بهش پیشنهاد می‌شد. این مدل تنها یک‌بار اجرا شد و به دلیل دشوار بودن اجرا و کم بودن Context تو گزارش‌ها (دور بودن تیم‌لید از خط آخر کارها) کنار گذاشته شد.ما به سیستمی نیاز داشتیم که علاوه بر بررسی در سطح فرد، بتونه ریشه‌ مشکلات رو از زوایای مختلف بررسی کنه و راهکار و بهبود براشون پیشنهاد بده.مقدمه - مسیر شغلییکی از مسئولیت‌های تیم‌لید در تیم ما، هدایت و کنترل مسیر شغلی اعضای تیمه. این مسئولیت تو تیم‌های کوچک با اعضای کم که امکان ارتباط مستقیم و مداوم با افراد وجود داره، تا حد خوبی قابل اجراست اما وقتی تعداد اعضا بیشتر بشه، هدایت مسیر شغلی تبدیل به کارگاه سری‌دوزی می‌شه. تیم ما به طور میانگین ۲۵ عضو داره که از تخصص‌های مختلف دور هم جمع شدن. بنابراین امکان اجرای این مسئولیت برای تیم‌لید با کیفیت مطلوب وجود نداره. ما به فرایندی نیاز داشتیم که این مسئولیت در اون به شکل مناسب به افراد تفویض بشه و تیم‌لید کالیبره کردن و همراهی اون رو به عهده بگیره.منابع الهامرشد در نردبان شغلی در شرکت ما، با ارائه مستندات و توضیحات توسط هر فرد امکان‌پذیره. یعنی فرایند رشد به شکل خوداظهاری پیش می‌ره.مدل Brag Document برای ارائه دستاوردهافرمت گزارش رو از فرمت «گزارش وضعیت» تو سیستم OKR به اسم PPP - Progress/Problem/Plan برداشتیمردپا: یک ضربه روی دو مسالهبرای حل دو مساله موجودمون تصمیم گرفتم، یک راهکار تازه رو امتحان کنم. راهکار تازه‌ای که وامدار فرایند‌های دیگه شرکت بود. همین وامدار بودن، شانس پذیرشش تو اعضای تیم رو بیشتر می‌کرد. سیستم ردپا یه گزارش ساده سه صفحه‌ایه که دو موضوع مشخص رو پوشش می‌ده: ارزیابی عملکرد و مسیر شغلی. هر صفحه یک بخش از فرمت گزارش‌مون رو پوشش می‌ده. صفحه اول پیشرفت فرد (Progress)، صفحه دوم مشکلاتش (Problem) و صفحه سوم، راهکارهاش برای حل اون مشکلات (Plan). این فرایند که از پایین به بالا و به شکل خوداظهاری اجرا می‌شه رو هر دو ماه یک‌بار اجرا می‌کنیم و از نتایجش برای جهت‌دهی ادامه مسیر تیم و فرد استفاده می‌کنیم.بخش اول قالب گزارشردپا در تیمبرای بخش ارزیابی عملکرد با توجه به وضعیت تیم و اولویت‌های شرکت، KPIهایی مشخص به همراه روش محاسبه‌اش به همه اعلام میشه و عضو تیم توی بخش پیشرفت، مشکلات و راهکارها به KPIهاش می‌پردازه. به عنوان مثال KPI درصد تحقق رو در نظر بگیریم (این KPI باید به شکل ترکیبی در کنار چیزهایی مثل Cycle Time استفاده بشه تا خروجی معنادار داشته باشه). عضو تیم تو بخش اول، درصد تحقق دو ماهه‌اش رو محاسبه می‌کنه و اگه از یه میزانی پایین‌تر باشه، به عنوان یه مشکل مطرحش می‌کنه و سعی می‌کنه به شکل فردی یا تیمی ریشه‌یابیش کنه.این KPI ها بهتره بعد از بهبود تغییر کنن و همیشه مهم‌ترین مشکلات تیم رو باهاشون رصد کنیم. مثلا سه دوره ترکیب Done Rate/Cycle Time و در صورت بهبود تو دوره‌های بعد Review Time و … سنجیده بشن.بخش دوم قالب گزارشردپای شغلیبرای بخش مسیر شغلی انتظار داریم که فرد کارهای دوره کنترلی فعلیش رو با محل قرارگیری فعلیش تو نردبون بسنجه و کارهاش رو به سه بخش Well Aligned، Under Challenged و Overburdened تقسیم کنه.Under-challenged: این کار در سطح پایین‌تری از نردبون شغلی قرار داره.Overburdened: این کار در سطح بالاتری از نردبون شغلی قرار داره.Well-aligned: این کار در سطح فعلی، تو نردبون شغلی هست.حالا عضو تیم تصمیم می‌گیره که به هر یک از کارهای تو این سه دسته به شکل یه مشکل نگاه کنه یا نه. اگه از دیدش مشکلی وجود داره، راهکاری برای بهبودش ارائه می‌ده. علاوه بر این می‌تونه تو بخش Plan برنامه پیش‌روی دو ماهه‌اش رو مشخص و با تیم‌لید امکان‌سنجیش کنه. مثلا تصمیم بگیره تو پله فعلی نردبون بمونه یا برای پله‌های بالاتر برنامه‌ریزی کنه. به عنوان مثال همه کارهای یک نفر می‌تونه تو دسته Overburdened قرار بگیره و این تصمیمی بوده باشه که فرد تو دوره کنترلی قبلی به عنوان راهکار برای رشدش ارائه کرده.تو این بخش اگه اکثر کارها تو Under-challenged جا بگیرن، می‌تونه بهمون درباره استفاده نادرست از مهارت اعضای تیم هشدار بده.بخش سوم قالب گزارشروش اجرادوره کنترلی: هر دو ماه یک‌بار این فرایند رو اجرا می‌کنیم. دو ماهه بودن بهمون کمک می‌کنه نتیجه تغییرات یا اثر تصمیمات رو تا حدودی ببینیم و اگه نیاز به اصلاح مسیر داریم، تغییرش بدیم.جلسات بررسی گزارش: گزارش‌های خوداظهاری ارسال شده اعضا، تو جلسات نیم‌ساعته بررسی و مسیرها و راهکارها در سطح فردی کالیبره می‌شن. پیشنهاداتی که نیازمند تغییر تو یه فرایند تیمی یا سازمانی هستن، تجمیع می‌شن و در صورت هم‌جهت بودن اکثریت تیم اجرایی می‌شن.تاریخچه: تو هر دوره کنترلی علاوه بر نتایج دوره فعلی، مقایسه‌ای با دوره‌های قبلی خواهیم داشت که بتونیم روندها و تغییرات رو به شکل ملموس‌تر مشاهده کنیم.محیط امن: شرکت تو این فرایند اختیاریه (هر چند مدام به حضور و انجامش تاکید میشه) و از نتایج ارزیابی عملکرد استفاده تنبیهی نمی‌شه.اکشن‌های اجرایی: بخش سوم گزارش، ما رو به سمت بهبودهای فردی یا تیمی هدایت می‌کنه. بعد از پایان همه گزارش‌ها و جلسات، با جمع‌بندی و برآیندگیری از پیشنهادات و مشکلات، اولویت‌بندی‌شون می‌کنیم و سعی می‌کنیم اجراشون کنیم.نتیجه اجراشش ماه از اجرای این فرایند می‌گذره و درصد مشارکت تو هر سه دوره برگزار شده‌اش بیشتر از ۸۴ درصد بوده. تو ادامه مسیر نیاز به بهبودهایی تو بخش مدیریت مسیر شغلی داریم اما تا این‌جا دو دغدغه بزرگ تیم، به خوبی در دل تیم پخش شدن و تبدیل به دغدغه اعضای تیم شدن. تغییرات کوچک و موثری تو فرایندهای جاری تیم هم داشتیم. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Sun, 24 Nov 2024 15:59:40 +0330 https://virgool.io/@mehrdadep/tech-debt-r5dnaoersku1 From Unleashاز استعارهبدهی فنی رو اولین بار وارد کانینگهام (Ward Cunningham) برای قانع کردن کارفرمایی که تو سیستم مالی داشت به عنوان استعاره‌ای برای دلیل نوسازی کردن نرم‌افزار مطرح کرد. «با قرض کردن می‌شه کارها رو سریع‌تر جلو برد اما تا زمانی که بدهیت رو صاف نکنی داری نرخ بهره‌اش رو هم می‌پردازی» با نوسازی کردن نرم‌افزار در مسیر توسعه ما این بدهی رو پرداخت می‌کنیم. بدهی‌ای که بخاطر سرعت بالا و دانش کم اولیه‌مون ایجاد شده.حل بدهی فنی می‌تونه بهونه‌ای برای نوشتن نرم‌افزار بد باشه. نرم‌افزار باید درک فعلی ما از مساله رو نشون بده. این درک می‌تونه با گذر زمان، اضافه شدن فیچر‌های جدید و … تغییر بکنه. پرداخت بدهی فنی به معنی نوسازی (Refactor) نرم‌افزار موجود برای بازتاب درک فعلی‌مون از مساله‌است.در دنیای نرم‌افزار «بهترین» دشمن «به اندازه کافی خوبه». اگه ما برای درک کامل مساله و نیازمندی‌ها و یه طراحی درست صبر کنیم. احتمالا پنجره ورود به بازار رو از دست می‌دیم. یه راه خوب برای توسعه نرم‌افزار، توسعه، ارائه به کاربر، گرفتن بازخورد و گردش تو همین حلقه است. به این شکل میشه به شکل صعودی محصول و کیفیتش رو بهبود داد و همزمان درک‌‌مون از مساله‌ای که داریم حل ‌می‌کنیم هم بیشتر می‌شه. بنابراین بدهی فنی به خودی خود، مساله نیست. مساله، نشناختن بدهی فنی و زیاد شدنشه.پروداکشن کردن یه کد مثل رفتن زیر بار بدهیه. یه کمی بدهی سرعت‌مون رو بالا می‌بره اما باید بدونیم که به موقع بدهی‌مون رو پس بدیم. نقطه خطرناک اونجاست که بدهی باقی می‌مونه و بیشتر می‌شه. هر زمانی که به کد دارای بدهی اختصاص می‌دیم، نرخ بهره بدهی‌مون رو بیشتر می‌کنه. بزرگترین سازمان‌ها هم می‌تونن زیر بار بدهی فنی زیاد کاملا فلج بشن.بدهی و آن دیگر چیزهابدهی فنی بحث کیفیت رو در مورد کد که برای استفاده کننده نامرئیه مطرح می‌کنه. معمولا تیم‌ها برای به وجود آوردن بدهی فنی بهانه‌های مختلفی دارنوقت نداریممدیر محصول، فنی نمی‌فهمهبرنامه‌نویس قبلی چیزی بلد نبودبچه‌های UX توقع بی‌جا دارنبعضی‌ها فکر می‌کنن می‌شه بدهی فنی رو با از‌نو نویسی نرم‌افزار از بین برد اما در زمان بازنویسی نرم‌افزار اگه اختلاف در‌ک‌مون از مساله رو پوشش ندیم، ما رو به بدهی‌های فنی فعلی می‌رسونه. (در مورد بازنویسی و نوسازی اینجا توضیح دادم) برای رفع بدهی فنی باید نوسازی کردن با افزایش درک مساله و مدل‌سازی مجدد همراه باشه. به‌روش‌ها (Best Practices) به تنهایی کافی نیستند. کد تمیز نمی‌تونه یه مدل خراب رو درست کنه. اگه مساله درست فهمیده نشه استفاده از به‌روش‌ها و کد تمیز فقط هدر دادن پول و منابعه.قانون کانوی (Conway's Law) می‌گه که ساختار و فرهنگ سازمان روی نرم‌افزاری که تولید می‌شه اثرگذاره. «با نحوه چینش تیم بعضی از تصمیم‌های نرم‌افزاری خود‌به‌خود گرفته می‌شن که شبیه نحوه چینش تیم باشن». اگه یه سیستم رو طراحی کنی اما ساختار سازمان رو طراحی نکنی در واقع طراحی سیستم رو درست انجام ندادی.پیچیدگی ضروری و غیرضروریهر نرم‌افزاری شامل پیچیدگی ضروری و پیچیدگی غیرضروریه. پیچیدگی غیرضروری درک نرم‌افزار رو سخت می‌کنه. بیاین به این پیچیدگی غیرضروری بدهی فنی بگیم. در زمان توسعه باید با این پیچیدگی غیرضروری دست و پنجه نرم کنیم، بنابراین توسعه‌مون با پرداخت نرخ بهره برای بدهی فنی‌مون همراهه.پیچیدگی ضروری و غیرضروریفرض کنید یه ساب‌سیستم پیچیده و با روش پیاده‌سازی گمراه‌کننده تو نرم‌افزار وجود داره که باید یه فیچر جدید بهش اضافه بشه. اگه روش پیاده‌سازی تمیز و واضح بود، حدود سه روز برای فیچر جدید زمان نیاز داشتیم اما با وجود پیچیدگی‌های غیرضروری این زمان به شش روز افزایش پیدا می‌کنه. این سه روز بیشتر برای پیاده‌سازی فیچر جدید در واقع بهره‌ایه که برای بدهی فنی موجود تو نرم‌افزار می‌پردازیم. این‌ها اعداد فرضی با پیش‌بینی‌های فرضی هستن. تو دنیای واقعی بدهی فنی به این شکل با اعداد قابل اندازه‌گیری نیست و بهبودی که تو زمان و روش توسعه می‌ده با این دقت قابل اندازه‌گیری نیست.پس باز هم سراغ استعاره مالی می‌ریم. بدهی با بهره رو چطور پس می‌دن؟ به مرور!یکی از روش‌های تشخیص بدهی فنی، نرخ‌ تغییرات و تعداد افرادی هست که روی یه بخش مشخص از کد کار کردن. نرخ تغییرات زیاد معمولا نشون دهنده اینه که یه بخشی از کد مدام باید عوض می‌شده (احتمالا درک‌مون از مساله کامل نبوده). با پیدا کردن این بخش‌های نرم‌افزار در زمان هر تغییر می‌شه بخشی از بدهی فنی اون بخش رو کاهش داد. پرداخت بدهی فنی زمان‌بره اما به استعاره دقت کنیم اگه بهره رو به مرور پرداخت نکنیم در نهایت ورشکست می‌شیم. ورشکستگی تو یه نرم‌افزار با بدهی فنی به این معنیه که دیگه نمیشه به جایی از نرم‌افزار دست زد. پرداخت مداوم بدهی فنی یکی از نشونه‌های Code Stewardship ه که می‌تونه به عنوان فرهنگ جاری تیم بین اعضا رایج بشه.تفاوتی که استعاره بدهی فنی با دنیای واقعی مالی داره اینه که تو دنیای مالی با گذشت زمان باید بدهی رو پس بدهی اما بدهی فنی نرم‌افزار زمانی فعال می‌شه که با اون بخش کد سر و کار داشته باشیم، یعنی لزوما نیاز نیست سراغ بدهی فنی‌هایی بریم که باهاشون سر و کار نداریم. کدهایی که پیچیدگی غیرضروری دارن اما کار می‌کنن رو می‌شه تا زمانی که بهشون برنخوردیم، رها کرد. در مقابل بخش‌هایی از کد که مدام در حال تغییرن باید با سیاست عدم تحمل (صفر کردن بدهی) همراه باشن چون نرخ بهره‌شون مدام بیشتر می‌شه.نادیده گرفتن بدهی فنی رو نباید با رها کردن کیفیت اشتباه بگیریم. بدهی فنی وقتی بزرگ بشه روی بهره‌وری تیم و انگیزه‌ اعضاش تاثیر منفی می‌ذاره و منجر به یه حلقه خطرناک می‌شه: «بدهی فنی زیاد بهره‌وری و روحیه تیم رو کاهش می‌ده و همزمان بهره‌وری پایین باعث می‌شه مدیریت فیچر‌های بیشتری رو وارد کار کنه و حل بدهی‌های فنی رو به بعد موکول کنه، این کار باعث بیشتر شدن بدهی فنی می‌شه»مدیریت، جلوگیری و بازپرداخت بدهی فنی (TS;R)مدیریت بدهی فنیبدهی فنی اجتناب‌ناپذیره. دنیا سریع در حرکته و تیم‌های نرم‌افزاری هم باید به سرعت نرم‌افزار رو برای تولید ارزش به مشتری برسونن. تو این تعقیب و گریز تیم‌ها گاهی مجبور می‌شن راه‌حل‌های سریع و کثیف رو استفاده کنن. بنابراین تیم‌های نرم‌افزاری باید آماده مدیریت بدهی‌هاشون باشن.اولین روش مدیریت بدهی فنی جلوگیری از زیاد شدنشه که با افزایش آگاهی تیم نسبت به بدهی و ایجاد روتین‌‌های سازمانی براش همراهه. روش دیگه مدیریت بازپرداخت بدهی‌هاست. باید تلاش‌های آگاهانه‌ای برای شناسایی، اولویت‌بندی و نوسازی بدهی‌های فنی، انجام بشه.جلوگیری از بدهی فنییک روش جلوگیری از بدهی فنی افزایش آگاهی به وجودش تو تیم‌هاست. تیم‌های توسعه باید بدهی‌های فنی نرم‌افزارشون رو بشناسن، جنبه‌های مختلفش رو بررسی کنن و با اثرش روی نرم‌افزار آشنا باشن. بررسی خودکار کیفیت کد، رعایت اصول کد تمیز، Design Smell ها و روش‌های نوسازی باید براشون روتین باشه. برای افزایش آگاهی میشه از دوره‌ها، کنفرانس‌ها و تمرین‌های متمرکز کمک گرفت.نمونه‌های عملیاتی جلوگیری از زیاد شدن بدهی فنی:ریویو کدریویو طراحی و معماریریو تست‌هابازپرداخت بدهی فنیمعمولا تیم‌ها روی نرم‌افزارهایی کار می‌کنن که میزان زیادی بدهی فنی داره. توسعه بیشتر روی این نرم‌افزارها می‌تونه منجر به ورشکستگی فنی بشه. از طرفی توقف کامل توسعه برای تمرکز کامل روی رفع بدهی‌های فنی منطقی و منطبق با دنیای واقعی نیست. باید روشی میانه این دو رو انتخاب کنیم که بتونیم بدهی‌های فنی رو به صورت مداوم و با نرخ صعودی بازپرداخت کنیم.۱. شناسایی، مستندسازی و دنبال کردن بدهیاولین قدیم تو بازپرداخت بدهی فنی شناسایی و مستند‌سازی بدهی‌های فنی‌ه. ابزارهای زیادی برای شناسایی بدهی در سطح کد (نه معماری، طراحی و …) وجود داره. در ادامه توسعه‌دهنده‌ها و معماران سیستم هم می‌تونن بدهی‌ها رو شناسایی کنن. بعد از شناسایی، بدهی‌های فنی باید تو فرمت مناسبی مستندسازی بشن. میشه برای داکیومنت کردن از شیت‌های اکسل یا هر ابزار دیگه‌ای استفاده کرد. بعد از اون وضعیت بدهی در تیم باید مشخص بشه که آیا قراره فیکس بشه، اگه جواب مثبته چه زمانی؟۲. اولویت‌بندی بخش‌های بدنرم‌افزار بدون بدهی وجود نداره و بهتره که وجود نداشته باشه. بدهی‌ها رو باید مرتب کرد و بر اساس نرخ تغییر و میزان اثرگذاری‌شون روی نرم‌افزار اولویت بندی کرد. طبیعیه که تو نرم‌افزار بدهی‌های با اولویت پایین وجود داشته باشه که سراغ حل‌شون نریم.۳. شکستن بدهی‌ها به بخش‌های کوچک قابل انجام در هر دورهتو دنیای مالی وام بزرگ رو به مرور و با مقادیر کوچک بازپرداخت می‌کنن. تو دنیای نرم‌افزار هم امکان بازپرداخت بدهی فنی بزرگ به صورت یکجا وجود نداره و بهتره بدهی‌ها رو به بخش‌های قابل انجام تو دوره کنترلی بشکونیم و انجام بدیم.۴. ایجاد انگیزه برای نگهداشت کیفیتآدم‌ها به چیزهایی که قابل اندازه‌گیری و پاداش دادن هستن اهمیت می‌دن. اگه مدیر یه تیم به تعداد فیچرهای منتشر شده یا تعداد باگ‌های فیکس شده اهمیت بده، تیم به سمت تعداد فیچر بیشتر یا تعداد باگ‌های فیکس شده بیشتر حرکت می‌کنه. حذف و بهبود کیفیت نرم‌افزار هم باید به معیارهای مهم مدیرها تبدیل بشن.۵. پیروی از قانون پیش‌آهنگیقانون پیش‌آهنگی می‌گه «همیشه زمینی که واردش می‌شی رو تمیزتر از وقتی که واردش شدی ترک کن». تو دنیای نرم‌افزار خوبه که از قانون «کدی که داری روش کار می‌کنی رو تو وضعیت بهتری که تحویل گرفتی، تحویل بده» پیروی بشه. پیروی از این قانون بازپرداخت بدهی فنی رو به روتین تیم تبدیل می‌کنه.۶. به دنبال موقعیت برای بازپرداخت بدهی فنی‌های بزرگ بودنبدهی‌ فنی‌های بزرگ مثل تغییر معماری و طراحی می‌تونن بدهی‌ فنی رو به شکل چشم‌گیری کاهش بدن. باید همیشه به دنبال موقعیت‌های زمانی مناسب برای بازپرداخت بدهی‌های بزرگ بود.۷. رفع افقی بدهی به جای عمودیبدهی‌های بخش‌های مختلف روی همدیگه اثرگذارن. برای مثال بدهی تست و طراحی می‌تونن روی هم اثر بذارن. میشه برای این‌که کد قابل تست کردن باشه بعضی از طراحی‌ها رو تغییر داد یا برعکس. بنابراین بهتره که بدهی مرتبط به یه موضوع به شکل همزمان رفع بشه. یعنی سراغ یک موضوع تو همه جنبه‌ها بریم نه سراغ همه بدهی‌های یه جنبه.۸. بعضی بدهی‌ها رو رها کنینبعضی‌ بدهی‌ها حتی اگه خیلی بزرگ باشن هم ارزش بازپرداخت ندارن. مثلا بدهی‌ فنی تو PoC یا نرم‌افزاری که نزدیک پایان عمرشه، ارزش بازپرداخت نداره یا زمانی که تصمیم به مهاجرت به استک جدید گرفته شده بهتره بدهی‌های فنی تو کد قبلی پرداخت نشه و در زمان مهاجرت بهشون پرداخته بشه.مدیریت، جلوگیری و بازپرداخت بدهی فنی (TL;DR)بدهی فنی ابعاد مختلفی داره، بعضی‌هاشون رو می‌شه تو دسته‌های زیر قرار داد:بدهی نیازمندی‌ها (Requirements): نادیده گرفتن نیازمندی‌ها، بررسی ضعیف نیازمندی‌ها و …بدهی طراحی (Design) و معماری (Architecture): مثل: Design Smell ها، پیروی نکردن از قوانین طراحی یا معماریبدهی پیاده‌سازی (Implementation): مثل کد تکراری، Code Smell ها و …بدهی تست (Test): مثل نداشتن تست، Coverage پایین تست‌ها یا طراحی بد تست‌هابدهی مستندسازی (Documentation): مثل نداشتن مستند از بخش‌ها و تصمیمات مهم سیستم، مستندسازی ضعیف یا مستندات قدیمیبدهی استقرار (Deployment): نداشتن محیط استیج، نداشتن مانیتورینگ و …بدهی اجتماعی (Social) و تیمی: سیلوهای تخصصی و …۱. بدهی نیازمندی‌هانیازمندی بیانیه‌ایه که یکی از ذینفع‌های سیستم درباره یه فیچر یا ویژگی درون سیستم آماده می‌کنه. نیازمندی می‌تونه یه تسک تو بک‌لاگ یا چند خط نوشته تو یه داکیومنت باشه. نیازمندی‌ها در واقع پل بین کسب‌وکار یا ارزش‌های سازمان با پیاده‌سازی فنی هستن. ارزشی که برای مشتری ایجاد می‌شه از طریق نیازمندی‌ها مشخص می‌شن.یکی از روش‌های تشخیص بدهی نیازمندی اینه که نرم‌افزار در نهایت ارزشی رو به مشتری نمی‌رسونه. وقتی ما اولویت‌های پیاده‌سازی‌مون رو به سمت نیازمندی‌هایی ببریم که ارزش کمتری برای مشتری ایجاد می‌کنن، داریم به سمت زیاد کردن بدهی نیازمندی حرکت می‌کنیم. برای مثال، شواهد نشون می‌دن که ۲۰ درصد فیچرهای یه نرم‌افزار نیازمندی ۸۰ درصد از کاربرا رو پوشش می‌ده، یعنی ۸۰ درصد فیچرها عملا بدون استفاده هستن. بدهی نیازمندی معمولا زمانی اتفاق می‌افته که به همه درخواست‌های مشتری‌ها بله بگیم یا نیازمندی‌ها رو بدون تحلیل و بررسی و تصمیم‌گیری وارد کارها کنیم.نقش بدهی فنی تو فرایند بررسی نیازمندی‌ها چیه؟ دو مدل بدهی نیازمندی داریم:۱.۱ مهندسی ضعیف نیازمندی‌ها: وقتی برای استخراج نیازمندی‌ها میان‌بر بزنیم، بدهی نیازمندی‌ اتفاق می‌افته. برای مثال، وقتی با همه ذینفع‌های درگیر صحبت نکنیم، نتیجه کارمون بی‌کیفیت یا با اولویت‌بندی اشتباهه. این شکست تو فرایند استخراج نیازمندی‌هاست. اشتباه تو این فرایند می‌تونه بدهی‌های فنی رو تا مراحل نهایی به شکل تصاعدی زیاد کنه. به عنوان مثال ساخت یه وبسایت که با کاربران در ارتباطه بدون درک درست از نیازمندی‌های حریم خصوصی (مثلا GPDR) می‌تونه منجر به توسعه نرم‌افزاری بشه که تو بدهی‌های فنی غرق شده.۱.۲. نادیده گرفتن نیازمندی‌ها: این مدل بدهی منجر به پیاده‌سازی فیچر‌های اشتباه به خاطر درک نادرست‌مون از نیازمندی‌های مشتری میشه. این شکست تو فرایند توسعه نرم‌افزاره.پیدا کردن بدهی نیازمندی‌هاپیدا کردن بدهی تو بخش مهندسی ضعیف نیازمندی‌ها کار سختیه. ابزار خودکاری برای پیدا کردن این نیازمندی‌ها وجود نداره. تو خیلی موارد بخصوص تو قسمت نیازمندی‌های غیرکارکردی، حتی دیتای مناسب و آماده تحلیل هم پیدا نمی‌شه. مثلا تیمی‌ که می‌خواد اپلیکیشنی برای IoT خونه‌ها بسازه باید درک عمیقی از نیازمندی‌ها و محدودیت‌ها قانونی داشته باشه.دونستن این نیازمندی‌ها و عمل نکردن بهشون به خودی خود بد نیست. همونطور که می‌دونیم ما گاهی آگاهانه می‌پذیریم که بدهی فنی داشته باشیم. برای مثال اوبر با اینکه از مجوزهای لازم برای شروع کارش آگاه بود، اول تاکسی اینترنتیش رو راه انداخت و بعد به دنبال گرفتن مجوزهای قانونی رفت. اگه خیلی دیر بشه، بدهی نیازمندی‌ها رو معمولا میشه از بازدید یه نهاد رگولاتور یا شکایت از طرف یه نهاد یا مشتری ناراضی پیدا کرد.برای اینکه خوشحال‌تر باشیم، باید یه فرایند مشخص برای جمع‌آوری و استخراج نیازمندی‌ها وجود داشته باشه که تو این فرایند نیازمندی‌ها تجمیع و اولویت‌بندی بشن و بعد با استفاده از یه ابزار مدیریت کارهای مناسب تبدیل به درخواست‌های قابل انجام بشن و در نهایت وضعیت انجام‌شون قابل ردیابی و مشاهده باشه.مدیریت بدهی نیازمندی‌هابرای مدیریت بدهی نیازمندی‌ها باید به دنبال استخراج درست نیازمندی‌ها و آگاهانه کار کردن روی چرایی‌شون باشیم. به این معنی که مدام از خودمون بپرسیم چرا باید به این نیازمندی دقت کنیم و داریم روی چه چیزهایی کار می‌کنیم. سوال «چرا داریم روی این فیچر کار می‌کنیم؟» همیشه باید یه جواب سریع و قانع‌کننده داشته باشه، در غیر اینصورت احتمالا درگیر بدهی نیازمندی‌ هستیم.جلوگیری از بدهی نیازمندی‌هابرای جلوگیری از زیاد شدن بدهی نیازمندی‌ها باید تو مرحله استخراج نیازمندی‌ها دقیق باشیم و از روش جمع‌سپاری برای جمع‌آوری اطلاعات استفاده کنیم. استخراج نیازمندی‌ها تو روش‌های اخیر توسعه نرم‌افزار معمولا به مدیر محصول یا مدیر پروژه (PM) اختصاص داده می‌شه و انجام درستش نیاز به تمرین و مهارت ارتباطی خوب داره. PM باید بتونه با مشتری و توسعه‌دهنده ارتباط بگیره و زبان مشترک بین‌شون باشه.استخراج نیازمندی‌ها روش‌های متفاوتی داره. بررسی پروداکشن و اینکه مشتری‌ها با کدوم بخش محصول بیشتر ارتباط دارن، چقدر طول می‌کشه که به جایی که نیاز دارن برسن، کدوم فیچرها اصلا استفاده نمی‌شن و …مدیر محصول یا مدیر پروژه باید با بخش مشتریان ارتباط داشته باشه و به کمک جمع‌آوری دیتا از بخش‌های مختلف (مشتریان جدید، مشتریان فعلی و …) نیازمندی‌ها رو استخراج کنه. صرف زمان چند ساعته روی نیازمندی‌ها می‌تونه جلوی چندین ساعت پیاده‌سازی دوباره یا تغییر معماری رو در آینده بگیره.در نهایت PM باید بتونه نیازمندی‌ها رو به زبان قابل درک و مدیریت برای توسعه‌دهنده تبدیل کنه:نیازمندی رو به روشی که توسعه‌دهنده می‌فهمه بنویسهبخش‌هایی که نیاز به پیاده‌سازی نداره رو حذف کنهکارها رو تو ابزار مدیریت کارهای توسعه‌دهنده وارد کنهدر کنار این‌ها PM باید همیشه نیازمندی‌ها رو به‌روز نگه داره. برای مثال اگه PM از DOORS برای مدیریت نیازمندی‌ها استفاده می‌کنه و توسعه‌دهنده از Jira، در این صورت وظیفه همگام کردن DOORS با Jira به عهده PM هست.۲. بدهی طراحی و معماریطراحی (Design) به معنی مدل ارتباطی و ساختاربندی در سطح کد و معماری (Architecture) ساختاربندی High-Level هستن. برخلاف بدهی‌های پیاده‌سازی، بدهی‌های طراحی و معماری سخت‌تر قابل تشخیص هستن و معمولا با بررسی تاریخچه پروژه و روند تغییراتش قابل شناسایی‌ان. بدهی طراحی به شکل مستقیم روی موفقیت پروژه در بلند مدت تاثیرگذاره.پیدا کردن بدهی طراحیدلایل زیادی برای به وجود اومدن بدهی طراحی وجود داره. برای مثال:رعایت نکردن Separation of Concernsکپی و تغییر: وقتی بخشی از کد از جای دیگه‌ای کپی شده و تغییراتی داخلش ایجاد شدهوابستگی‌های در هم تنیده یا توپ بزرگ گلی: وقتی به معماری سیستم توجهی نشده و طراحی‌ها به شکل ضمنی پیش رفتن.تکامل بدون برنامه: وقتی فیچرهای جدید و اصلاح باگ‌ها بدون بررسی تاثیرشون روی عملکرد کلی سیستم و حفظ یکپارچگیش پیاده‌سازی شدن و نتیجه کدهایی هستن که قابلیت نگهداری، خوانایی و تغییر رو از دست دادن.طراحی خوب، طراحی‌ای هست که انسجام (Cohesion) رو افزایش بده در حالی که در‌هم‌تنیدگی (Coupling) رو کم می‌کنه. هر کاری که این اصل رو نادیده بگیره، بدهی طراحی رو به محصول اضافه می‌کنه.اندازه‌گیری بدهی طراحیبیشتر توسعه‌دهنده‌ها و معماران سیستم حسی کلی نسبت به بدهی‌های تجمیع شده تو نرم‌افزار دارن. می‌تونن بدهی رو حس کنن، می‌تونن تاثیرش رو روی کارهای روزانه‌اشون ببینن اما نمی‌تونن دقیق بگن از کجاست و کجا تاثیر گذاشته. حالا چجوری باید بدهی رو اندازه بگیریم؟برای عددی کردن بدهی بهتره اول تعریف دقیقی از بدهی طراحی داشته باشیم. بدهی طراحی ۱. گروهی از ماژول‌های مرتبط به هم (معمولا فایل‌های مرتبط به هم) و ۲. مدلی که هزینه نگهداری این ماژول‌ها در طول زمان رو مشخص کنه، هست.در درجه اول، چطور باید ماژول‌ها (فایل‌ها)ی مرتبط به هم رو پیدا کنیم؟ دو گام ساده برای این‌‌ کار وجود داره. اولین گام بررسی وابستگی‌های استاتیک بین فایل‌هاست. این کار با ابزارهای مختلف مثل Understand قابل انجامه. دومین گام بررسی رشد این وابستگی‌ها در طول زمانه. برای این کار باید بررسی کنیم که آیا دو فایل با هم و همزمان تغییر می‌کنن یا نه. بهترین ابزار برای این‌ کار، ورژن کنترل‌ها هستن.برای درک بهتر این وابستگی‌ها میشه از ماتریس ساختار طراحی (DSM) استفاده کرد. اسپارس بودن این جدول نشونه خوبیه و به این معنیه که وابستگی شدیدی بین ماژول‌ها وجود نداره.ماتریس ساختار طراحیبه این ماتریس اطلاعات زیادی میشه اضافه کرد: تعداد باگ‌های فیکس‌شده که به این فایل‌ها ارتباط دارن، تعداد کامیت‌های مرتبط و … . در نهایت با بررسی این ماتریس و مدل‌ وابستگی کدها میشه مشکلات مشابه رو تشخیص داد و برای رفع‌شون برنامه‌ریزی کرد. بدهی‌های طراحی معمولا به شش ضدالگو طراحی می‌رسن:۱. اینترفیس ناپایدار (Unstable interface): وقتی یه اینترفیس همزمان با تغییر فایل‌هایی که ازش استفاده کردن، تغییر می‌کنه.۲. اشکال در ماژولاریتی (Modularity violation): وقتی ماژول‌های مجزا از هم، با هم تغییر می‌کنن.۳. وراثت ناسالم (Unhealthy inheritance): وقتی یه کلاس پایه به یکی از ساب‌کلاس‌هاش وابسته است یا یه کلاینت به کلاس پایه و ساب‌کلاسش همزمان وابسته‌است.۴. وابستگی چرخه‌ای (Cyclic dependency): وقتی چند فایل یا ماژول یه گراف به شدت متصل رو ایجاد می‌کنن.۵. چرخه پکیج (Package cycle): وقتی دو یا بیشتر از دو پکیج به هم وابسته‌ان.۶. عبور (Crossing): وقتی یه فایل با وابستگی ورودی و خروجی بالا، همزمان با هر تغییر باعث تغییر در فایل‌های دیگه می‌شه.تحقیقات نشون می‌ده که این ضدالگوها رابطه مستقیمی با باگ‌ها، تغییرات و زمان تغییر دارن.مدیریت بدهی طراحیبعد از شناسایی و اختصاص عدد (میزان کاری که برای بازپرداخت نیاز داریم) باید از خودمون بپرسیم که کدوم گروه‌ها (مجموعه ماژول‌ها و فایل‌ها) هزینه بیشتری بهمون تحمیل می‌کنن؟ آیا رفع این بدهی فنی، یه تصمیم اقتصادی هست یا نه؟ به عنوان مثال گروه کوچکی که نرخ تغییراتش زیاده ارجحیت بیشتری نسبت به گروه بزرگی داره که نرخ تغییراتش خیلی پایینه.جلوگیری از بدهی طراحیمانیفست اجایل بهمون می‌گه که «بهترین طراحی و معماری از دل تیم‌های خودمدیریت کننده به وجود میان». این جمله شاید برای تیم‌ها و نرم‌افزارهای کوچک (وقتی که تصمیمات طراحی و معماری کم هستن) جواب بده اما برای سیستم‌های بزرگ‌تر این اصل هیچ‌وقت جواب نداده. بررسی‌های مختلف نشون می‌ده که بسیاری از طراحی‌ها -طراحی‌های خوب- از دل تیم و خود به خود به وجود نمیان.بهترین راه جلوگیری از بدهی طراحی اینه که از اول نداشته باشیمش. خیلی از سیستم‌ها بدون هیچ نگاه کلانی به طراحی و معماری پیاده‌سازی می‌شن. برای از بین بردن بدهی طراحی، باید به صورت مداوم نتایج ضدالگوهای طراحی رو کم کنیم.۳. بدهی پیاده‌سازی«کد مثل جوکه، اگه نیازه توضیحش بدی، خوب نیست» – Cory Houseتو موارد پرشماری، کدهایی که توسعه‌دهنده چند سال پیش به عنوان Prototype پیاده کرده الان «محصول» ماست. نرم‌افزاری که پر از حفره‌های امنیتیه، نمیشه Scale اش کرد و احتمالا نگهداری ازش خیلی هزینه‌بره. نوشتن کد خوب مثل سالم زندگی کردنه -ورزش کن و به اندازه، غذای خوب بخور- اما درست مثل سالم زندگی کردن، تداوم این کار خیلی سخته و خیلی‌ها کلا رعایتش نمی‌کنن.نوشتن کدهای خوب، با قابلیت نگهداری و تست شده باید تو رژیم کدنویسی روزانه همه باشه. کد غیر مهمی که امروز نوشته می‌شه می‌تونه تبدیل به نقطه بحرانی کسب‌و‌کار تو چند سال آینده بشه. توییتر و استفاده از Ruby تو شروع کارش نمونه خوبی برای این طرز فکره. اونا در نهایت مجبور به تغییرات سخت با هزینه‌های بسیار بالا شدن.شناسایی بدهی پیاده‌سازیبدهی پیاده‌سازی به خاطر استفاده از میان‌برها تو کد به وجود میاد. بعضی از این میان‌برها اجتناب‌ناپذیرن (کپی کردن یه بخش کد برای یه فیچر جدید) اما همیشه باید آماده تمیزکاری به موقع باشیم. مهم‌ترین بدهی‌های پیاده‌سازی شامل استایل کد، کد ناکافی، کد دپریکیت شده و کد کپی شده هستن.مدیریت بدهی پیاده‌سازیبرای بیشتر بدهی‌های پیاده‌سازی میشه از ابزارهای بررسی استاتیک کد استفاده کرد. در کنار این ابزارها بهتره هر نرم‌افزار یه روش رو برای پیروی استایل‌ها رو بپذیره و همه توسعه‌دهنده‌ها از اون استفاده کنن.جلوگیری از بدهی پیاده‌سازیزبان برنامه‌نویسی باید با توجه به دامنه مساله و نیازمندی‌های نرم‌افزار انتخاب بشه. بعد از انتخاب زبان، برای جلوگیری از بدهی‌های پیاده‌سازی بهتره روی کتابخونه‌ها و پکیج‌های ثانویه‌ای که تو کد استفاده می‌شه حساس بود. ریویو کدها به صورت Peer Review باید وجود داشته باشه و بهتره که حداقل دو نفر جدا از توسعه‌دهنده اصلی این کار رو به عهده بگیرن. برای هر ریویو جدا از بررسی‌های خودکار تغییرات (بررسی استایل و …) باید دامنه تغییر رو کمینه کرد. استفاده از پیام‌های جامع و کامل برای کامیت‌ها هم می‌تونه به جلوگیری از بدهی‌ها کمک کنه. پیام خوب کامیت شامل تغییر و جزییاتش در صورت نیازه. استفاده از پیام‌های کلی مثل Minor change/Minor improvement در نهایت کار رو پیچیده و بدهی رو زیاد می‌کنن. در نهایت، برای هر تغییر باید تست‌های خودکار پیش از انتشار نسخه هم وجود داشته باشه.۴. بدهی تستتست‌ها می‌تونن بدهی‌های احتمالی فنی و باگ‌ها رو نمایان کنن. با این وجود خود تست‌ها هم می‌تونن بدهی فنی داشته باشن. برنامه‌نویس‌ها معمولا نرم‌افزارشون رو بدون تست مناسب به پروداکشن می‌برن. دلایل زیادی برای این‌ کار وجود داره اما یکی از مهم‌ترین‌هاش ددلاین‌های زمانیه.در ابتدای عمر نرم‌افزار اصلاح یه باگ کاریه که میشه تو چند ساعت و نهایت یک روز انجامش داد اما با رشد نرم‌افزار، بزرگ شدن تیم‌ها، رفتن و اومدن آدما و موج فیچر‌های جدید، اصلاح باگ‌ها می‌تونن روزها زمان ببرن. امکان داره فیچرهای خرابی وجود داشته باشه که کسی از وجودشون خبر نداره. تمام چابکی اول کار می‌تونه به سادگی و به مرور از بین بره.تست راهی برای اعتبارسنجی اینکه آیا کد و سیستم برای اساس نیازمندی‌ها، درست کار می‌کنن یا نه رو فراهم می‌کنه. تست می‌تونه تو سطوح مختلف انجام بشه. از تست یه متد خاص گرفته تا تست کل محصول و ارتباط اجزاش با هم.بدهی فنی تو تست‌ها زمانی به وجود میاد که تو فرایند تست کردن میان‌بر‌هایی رو به وجود بیاریم. هدف تست باید پوشش همه‌ جانبه برنامه باشه. با این‌که تو دنیای واقعی، هیچ‌وقت نمیشه به این سطح از تست کردن رسید اما هدف‌مون باید همین باشه.برای اندازه‌گیری پیچیدگی یه نرم‌افزار از متریک‌های مختلفی استفاده می‌شه. یکی از معروف‌ترین‌‌هاشون متریک McCabe یا پیچیدگی سایکلومتیک (Cyclomatic complexity) هست که تعداد مسیرهای مستقل یه کد رو اندازه می‌گیره. به عنوان مثال برای این شبه کد (که دو مسیر داره) باید حداقل دو تست وجود داشته باشه.if (some condition) { do something return } do something elseبدهی تست رو می‌شه تو دسته‌های زیر قرار داد:تست ناکافی: فانکشنالیتی اصلی کد فاقد تسته.تست چیزهای اشتباه: متدها و بخش‌هایی از کد تست می‌شن که دامنه اثرگذاریشون کمه. برای این بخش‌ها هم باید تست وجود داشته باشه اما اولویت کمتری نسبت به بخش‌های اصلی دارن.تست بی‌دلیل: تست‌ برای بخش‌هایی از کد که مطمئنیم درستن. مثلا یه بخش قدیمی کد که قرار نیست تغییر کنه و سال‌هاست تو پروداکشن درست کار کرده.تست‌های چشمک‌زن (Flaky): تست‌هایی که با هر اجرا، نتایج مختلف می‌دن.تست‌ مسیر شاد: تست‌هایی که فقط حالات درست نرم‌افزار رو پوشش می‌دن.تست‌هایی که با نیازمندی‌های یا مستندات منطبق نیستن.به طور کلی تست‌ها باید این اطمینان رو بهمون بدن که کد فعلی درست کار می‌کنه و تغییرات آینده‌مون، عملکرد فعلی رو خراب نکرده. بدهی تست رو می‌شه با نشانه‌هایی مثل زیاد شدن تعداد باگ‌های گزارش‌شده، زیاد شدن زمان رفع باگ‌ها و به وجود اومدن باگ‌های جدید بعد از رفع باگ‌های فعلی، تشخیص داد. استفاده از ابزارهای بررسی پوشش تست (Test Coverage) هم می‌تونه نیازمون به اضافه کردن تست‌ها رو مشخص کنه.۵. بدهی استقرارنود و نه درصد کار، تحویل کاره. – Buddy Hackettبدهی استقرار به میان‌برها، خطاها و اشتباهات‌مون در زمان استقرار و عملیاتی کردن یه سیستم، مرتبطه. همه توسعه‌دهنده‌ها با مفاهیم استقرار نرم‌افزار تو اسکیل بزرگ آشنا نیستن. استقرار نرم‌افزار به معنی روش‌هاییه که نرم‌افزار رو در اختیار کاربر نهایی قرار می‌ده. نرم‌افزاری که در اختیار کاربر نهایی قرار می‌گیره رو «محصول» یا «محیط پروداکشن» صدا می‌کنیم. هدف کاهش بدهی استقرار، بهینه کردن شیوه تحویل محصول به کاربر نهاییه.بدهی استقرار زمانی زمانی اتفاق می‌افته که نرم‌افزار رو با کار فشرده و دستی مستقر کنیم. این روش امکان استقرار بهینه و سریع رو بدون دخالت اعضای تیم از بین می‌بره. جدا از این، بدهی‌ استقرار به عنوان مرجع خطاهای مختلف می‌تونه منجر به هرج‌و‌مرج بشه و یه کسب‌و‌کار موفق رو به ورشکستگی برسونه.شناسایی بدهی استقراربدهی استقرار رو می‌شه با استفاده از نشانه‌های مختلف شناسایی کرد:باگ در پروداکشن: یکی از نشانه‌های اصلی بدهی استقرار، وجود باگ‌های جدید بعد از استقرار نسخه‌های جدید نرم‌افزاره. شاید فکر کنین این مدل خطاها بخاطر کمبود تست به وجود میان اما تست‌ها نمی‌تونن همه حالات رو پوشش بدن و سیستم‌های بزرگ رو نمیشه به طور کامل از طریق تست‌ها شبیه‌سازی کرد. در مورد یکی از روش‌های خوب استقرار اینجا توضیح دادم.باگ در پروداکشن بعد از چند هفته: با این‌که این نشونه خیلی رایج نیست اما می‌تونه نشونه‌ای از بدهی استقرار باشه. مشکلاتی که مربوط به کرنر کیس‌ها یا مشکلات موقتی (مثلا زیاد شدن مصرف ریسورس‌ها تحت شرایط خاص) می‌تونن تو این دسته قرار بگیرن.امکان بازگردانی به نسخه قبل نیست: این نشونه خیلی نیاز به توضیح نداره. اگه بعد از استقرار یه نسخه نتونیم به نسخه قبل برگردیم، یعنی بدهی استقرار داریم.وابستگی به فرایند‌های دستی زیاده: فرایند دستی بدون خطا نمیشه. استقرار نسخه جدید و بازگشت به نسخه‌ قبلی باید خودکار باشه.استقرار کور: هیچ متر و معیاری برای بررسی درست بودن نسخه جدید وجود نداره.امکان کنترل سرعت انتشار وجود نداره: فرایند انتشار نسخه و رول‌بک کنده.نسخه استیج وجود ندارهمدیریت بدهی استقراراستراتژی‌های متفاوتی برای مدیریت بدهی استقرار وجود داره:جدا کردن محیط‌های استقرار: وجود سه محیط برای استقرار توصیه می‌شه: «در حال توسعه»، «پیش‌پروداکشن» و «پروداکشن»افزایش قابلیت مشاهده: محیط‌های پیش‌پروداکشن و پروداکشن باید با ابزارها و شاخص‌های مناسب مانیتور بشن. متریک‌های مختلفی مثل مصرف ریسورس‌ها، آپتایم و … می‌تونن به درک درست بودن استقرار کمک کنن. به طور کلی استفاده تنها از لاگ‌ها برای بالا بردن مشاهده‌پذیری سیستم کافی نیست.بررسی مسیر تغییر متریک‌های غیرکارکردی (non-functional): متریک‌هایی مثل مصرف CPU و … باید در زمان استقرار نسبت به نسخه‌های قبل بررسی بشن تا تغییراتی که انتظارش رو نداریم، شناسایی بشن.بررسی متریک‌های کارکردی (functional): متریک‌هایی که مختص نرم‌افزارمون هست (مثل تعداد درخواست‌ها و …) هم باید قبل و بعد هر استقرار بررسی بشن.جلوگیری از بدهی استقراربرای جلوگیری از بدهی استقرار استراتژی‌های مختلفی وجود داره:استقرار خودکار تدریجی: تو هر فرایند دستی، امکان خطا وجود داره. یکی از علت‌های اصلی بدهی استقرار اتکا به افراد برای انجام کارهاییه که باید خودکار انجام بشن. خطای انسانی در زمان استقرار می‌تونه اثرات جبران ناپذیر به بار بیاره. به همین دلیل استقرار باید به شکل خودکار انجام بشه. در کنار استقرار خودکار، در صورتی که با اسکیل بزرگ سر و کار داریم باید از روش‌های استقرار تدریجی استفاده کنیم تا در صورت وجود مشکل دامنه اثرگذاریش رو کمینه و امکان بازگردانی به نسخه قبل رو آسون کنیم. استقرار تدریجی حتی تو بروزرسانی سیستم‌های تعبیه شده هم کاربرد داره. مثلا تسلا برای بروزرسانی نرم‌افزار خودروهاش از استقرار تدریجی استفاده می‌کنه.استقرار باید در دل پایپ‌لاین‌های CI قرار بگیره: تغییرات روی نرم‌افزار باید با شرایط از پیش تعیین شده به شکل خودکار وارد محیط‌های مختلف (استیج و پروداکشن) بشن. بهتره تریگر کردن این عملیات به شکل غیرخودکار (با تاثیر تصمیم بیزنسی) انجام بشه.فرایند استقرار باید تعریف مشخص داشته باشه: خودکار کردن فرایند استقرار به معنی رها کردنش نیست. فرایند استقرار باید به طور کامل مستند بشه. تو تعریف فرایند استقرار باید به این جنبه‌ها توجه کنیم و برای هر کدومشون توضیحات صریح و جامع داشته باشیم:چه کامپوننت‌هایی در حال استقرار هستنبرای شروع استقرار به چه چیزی نیاز داریمچه متریک‌هایی رو در جریان استقرار مانیتور می‌کنیمچه طور می‌تونیم استقرار رو متوقف کنیمچه طور می‌تونیم به نسخه قبلی برگردیمفیچر‌های جدید دکمه خاموش (Kill Switch) داشته باشن: دکمه خاموش می‌تونه در زمان مشکل فنی یا بیزنسی مورد استفاده قرار بگیره. از دکمه خاموش برای غیرفعال کردن یه فیچر در زمان اجرا استفاده می‌شه. در کنار پیاده‌سازی دکمه خاموش باید همیشه لیست بروزی از همه دکمه‌های خاموش‌مون داشته باشیم. برای سیستم‌های تعبیه شده پیاده‌سازی دکمه خاموش دشواره و باید نگرانی‌های امنیتی در نظر بگیریم.۶. بدهی مستند‌سازیمستند نامه عاشقانه‌ایه که به خودمون در آینده می‌نویسیم. – Damain Conwayبدهی مستندسازی به خاطر میان‌بر زدن در زمان مستندسازی به وجود میاد. زمانی که مشخصات طراحی رو بروز نمی‌کنیم یا کامنت‌های قدیمی کدها رو همونطور نگه‌ می‌داریم. بدهی مستندسازی با مستندکردن بدهی‌های فنی تفاوت داره. مستندسازی معمولا کاریه که کسی سراغش نمی‌ره و یک‌باره به عضو جدید تیم سپرده می‌شه اما هر کسی مدتی با نرم‌افزارها کار کنه متوجه می‌شه که مستندات می‌تونه زمان درک نرم‌افزار رو به شکل چشم‌گیری کاهش بده. قانون اصلی مستندسازی اینه که تنها زمانی باید یه چیزی رو مستند کنیم که ارزشش از هزینه‌ای که می‌پردازیم بیشتر باشه.دلایل مستندسازیبه دلیل اینکه توسعه‌دهنده‌های نرم‌افزار معمولا علاقه‌ای به نوشتن ندارن، ایجاد انگیزه برای مستندسازی معمولا دشواره. بدهی مستندسازی زمانی مشخص می‌شه که به بخشی از معماری، طراحی یا کد نگاه کنیم و دنبال دلیلش باشیم اما دلیلش رو پیدا نکنیم. مستندسازی می‌تونه یه کامنت کوتاه روی کد باشه یا یه بحث مفصل روی درخواست مرج یا حتی یه سند مجزا روی سیستم مدیریت اسناد تیم. مستندهایی که مسیر سختی برای پیدا کردن جواب بهمون می‌دن هم مناسب نیستن. این مدل مستندات هزینه نگهداری بالایی دارن و امکان اشتباه رو هم زیاد می‌کنن.اگه بعد از یه تصمیم بزرگ چرایی و چگونگی اجراش رو مستند نکنیم یا مستندات نامناسب بسازیم، شانس ایجاد بدهی مستندسازی رو زیاد کردیم. مقاله “A Rational Design Process: How and Why To Fake It” (Parnas and Clements, 1986) هفت ویژگی مستند مناسب رو مطرح کرده. رعایت نکردن هر کدوم از این هفت اصل می‌تونه به بدهی مستندسازی منجر بشه.برای مخاطب بنویسین: سند خوب جوری نوشته می‌شه که مخاطب رو خسته نکنه. اگه برای کاربر نهاییه باید به زبان قابل فهم برای اون باشه.خودتون رو تکرار نکنین.گنگ و مبهم نباشین.از یه روش ساماندهی استفاده کنین.تصمیم‌ها و چرایی‌ها رو ثبت کنین.اسناد رو به روز نگه دارین اما نه خیلی به روز: اسنادی که خیلی به روز هستن احتمالا شامل جزییاتی هستن که بهشون نیازی نداریم. بهتره اسناد تو دوره‌های کنترلی مشخص به روز بشن.مناسب بودن اسناد رو بازبینی کنین.شناسایی بدهی مستندسازیتو پروژه‌های کوچک و استارت‌آپ‌ها طبیعیه که کدها جلوتر از مستندات باشن. چرا که پروژه و استارت‌آپ ممکنه قبل از احساس نیازش به مستندات از هم بپاشه. نیاز به مستندسازی رو میشه تو جدول زیر خلاصه کرد.زمانی که کانتکست مستندسازی مشخص شد، نشانه‌هایی خودشون رو نشون می‌دن که مشخص می‌کنن آیا بدهی مستندسازی وجود داره یا نه.نشانه اول: توسعه‌دهنده‌های ارشد در حال پاسخ دادن به سوالات پایه‌ای و تکراری هستن.نشانه دوم: وقتی دوباره و چند باره یه بخشی از کد نرم‌افزار رو می‌خونین و چیزی درک نمی‌کنین.نشانه سوم: مستندات بی‌دلیل. مستنداتی که به اجبار نوشته شدن. به سختی پیدا می‌شن و کسی بهشون رجوع نمی‌کنه یا قابل ویرایش نیستن و الکی طولانی‌اند.نشانه چهارم: مستندات پیر. وقتی با داکیومنتی که پیر شده و به درد نمی‌خوره مواجه شدید اصلاح کردنش بهترین راهه اما اگه نیازی به اصلاحش نمی‌بینین، پاک کردنش بهتر از همونجوری نگه‌ داشتنشه.چه چیزهایی باید مستند بشهمدیریت بدهی مستندسازیفرایند مدیریت بدهی مستندسازی شامل کارهایی هست که ساخت و نگهداری مستندات رو در محلی مشخص آسون می‌کنه.همزمان با توسعه، مستندسازی کنید: مستندات مربوط به تصمیمات حول کد باید در کنار کدها باشه نه تو محلی مجزا. اکثر زبان‌ها از روش‌های کامنت‌گذاری چندخطی پشتیابی می‌کنن. مستندات همراه کد باید در زمان ریویو همراه کدها ریویو بشن و تغییراتشون تو ورژن کنترل‌ها باقی بمونن.دیاگرام‌ها: مثل UMLها هم بهتره تو ورژن کنترل و به صورت متنی قرار بگیرن تا تاریخچه تغییرشون مشخص باشه.کد، تست و مستند رو همزمان با هم بنویسین.جلوگیری از بدهی مستندسازیجدا از هفت اصل مطرح شده برای تشخیص این‌که یه مستند مناسب هست یا نه دو روش دیگه وجود دارن که باهاشون میشه مناسب بودن مستند رو تشخیص داد.قابلیت ردیابی: از طریق لینک‌ کردن باگ‌ها، درخواست‌ها و تغییرات مختلف (مثلا از جیرا و گیت‌لب) به مستند میشه مسیر رسیدن به تصمیمات رو هم مشخص کرد.بررسی کیفیت مستندات به بخشی از فرایند کنترل کیفیت نسخه‌ها تبدیل بشه.۷. بدهی اجتماعی و تیمیاین‌که پروژه‌ها فقط به دلایل فنی شکست بخورن، خیلی نادره. بیشتر شکست‌ها به دلیل مشکلات ارتباطی یا مدیریتی اتفاق میفتن. ساختار سازمان نقش مستقیمی روی پروژه و به طبع روی کدها و حتی فرایند تست و کنترل کیفیت داره. ارتباطات، مدیریت و ساختار تیم تاثیرات بزرگی روی بدهی‌های فنی نرم‌افزار دارن.تعریف بدهی اجتماعیمهندسی نرم‌‌افزار به شکل سنتی روی مصنوعات -کدها، فرایندها، ابزار و …- تمرکز می‌کنه، با این حال افراد و تیم‌هاشون، ساختار و ویژگی‌های افراد و تمام چیزهایی که با آدم‌هایی که واقعا با این مصنوعات در اتباطن، اهمیت دارن. ملوین کانوی (Melvin Conway) تو سال ۱۹۶۸ قانونی رو معرفی می‌کنه که حالا به اسم قانون کانوی معروفه: «ساختار و معماری نرم‌‌افزار بازتابی از ساختار سازمانیه که تولیدش کرده.» برای مثال یه کامپایلر COBOL که توسط پنج نفر توسعه داده شده، تو پنج فاز اجرا می‌شه، یا یه کامپایلر ALGOL که سه توسعه‌دهنده داشته تو سه فاز اجرا می‌شه.از اون‌جایی که راه‌های زیادی برای ایجاد ساختار سازمان و ساختار سیستم‌ها وجود داره، میشه نتیجه گرفت که تعدادی از این ساختارها غیربهینه هستن. بدهی اجتماعی رو به عنوان اختلاف ساختار سیستم و سازمان تعریف می‌کینم. علاوه بر این‌، منطقیه که بعضی از نگاشت‌های ساختار سازمانی روی ساختار سیستم هم غیربهینه باشن.بدهی اجتماعی هزینه اضافه‌ایه که به خاطر انواع ناسازگاری‌های فنی به پروژه تحمیل می‌شه. برای مثال اثر سیلو رو در نظر بگیرین: ساختار سازمان از سیلوهایی تشکیل شده که ارتباط کمی با هم دارن. اگه نتیجه کار هر سیلو ورودی کار سیلوی دیگه‌ای باشه، مشکلات شروع می‌شن. برای مثال یه سیلو مستندات لازم برای کار سیلوی دیگه رو با فرض این‌که به مستند نیازی نیست، آماده نکرده یا یه تیم از مشکل کارایی نرم‌افزار تیم دیگه‌ مطلع نیست و راه خودش رو برای بهبود سیستم پیاده کرده که منجر به مشکل بیشتر برای تیم اول شده.به طور کلی تطابق اجتماعی‌فنی (Sociotechnical Congruence) حالت ایده‌‌آل کار روی یه پروژه است به این معنی که کامپوننت‌هایی که به شدت با هم در ارتباط هستن باید توسط تیم‌هایی که ارتباطات مداوم دارن (و یک‌جا هستن) توسعه داده بشن.شناسایی بدهی اجتماعیمشابه Code Smell ها که برای شناسایی اشکالات کد ازشون استفاده می‌کنیم. از مفهوم Community Smells برای شناسایی و اصلاح ساختارها و رفتارهای غیربهینه اجتماعی استفاده می‌کنیم.همه ما بخشی از شبکه‌های مختلفیم: تو خونه، تو زندگی اجتماعی و تو زندگی کاری‌مون. اگه درباره چگونگی چینش شبکه‌های اجتماعی فکر کنیم و تاثیرش رو در محیط کسب‌و‌کار ببینیم متوجه می‌شیم که بعضی از حالات این شبکه‌ها غیر‌بهینه هستن.غیربهینگی ساختار شبکه‌ معمولا برای تیم‌های کوچک (سه تا پنج‌ نفره) مشکل‌ساز نیست. وقتی تیم‌ بزرگ‌تر بشه و انتظار داشته باشیم جریان دانش و تصمیمات توی تیم وجود داشته باشه، مساله پیچیده‌تر و زمان‌بر می‌شه. مثلا برای یه تیم دوازده نفره می‌تونه شصت و شش راه ارتباطی متفاوت تولید کنه. حالا اگه این تیم دوازده نفره رو به سه تیم چهار نفره تبدیل کنیم چه اتفاقی می‌افته؟ اگه این ساب‌تیم‌ها با هم ارتباط زیادی داشته باشن، چیزی رو عوض نکردیم اما اگه این ارتباط کم باشه احتمال این‌که تصمیم یه تیم روی تیم دیگه به شدت اثرگذار باشه وجود داره.بیشتر سازمان‌ها کار بهتری نسبت به این مدل ساده و پیش‌پا افتاده انجام می‌دن. هدف این‌ مثال‌ها این بود که ببینیم ساختار چطور روی بهینه کار کردن اثرگذاره. برای شناسایی بدهی اجتماعی باید ببینیم که کدوم الگوهای اجتماعی مخربن.توسعه طبق اصول (Cookbook Development): توسعه‌دهنده‌هایی که جلوی راه‌های تازه می‌ایستن و روششون رو تغییر نمی‌دن. این ضدالگو می‌تونه منجر به مشکلات ارتباطی بین اعضا یا حتی کاربران و سازمان بشه.پیچیدگی زمانی (Time Warp): یه تغییر تو ساختار سازمان که به اشتباه باعث این تصور می‌شه که ارتباطات زمان کمتری نیازه داره و هماهنگی‌های صریح نیاز نیست. این ضدالگو می‌تونه باعث کیفیت پایین معماری نرم‌افزار، ایجاد Code Smell ها، مشکلات عملیاتی حل نشده و مشتریان ناراضی بشه.فاصله شناختی (Cognitive Distance): فاصله‌ای که بین توسعه‌دهنده‌ها از نظر فیزیکی، فنی، اجتماعی و فرهنگی به دلیل تفاوت‌های پس‌زمینه‌ای به وجود میاد. نیازمندی‌ها به درستی منتقل نمی‌شن. باتجربه‌ها دانششون رو منتشر نمی‌کنن. این ضدالگو می‌تونه باعث زمان هدر رفته، مسخره‌کردن تازه کارا، کد کثیف، هزینه‌های اضافی توسعه، نبود درک متقابل بین بخش‌های مختلف، نبود اعتماد در شبکه و برداشت اشتباه از انتظارات بشه.بیگاری از تازه‌کارا (Newbie Free-Riding): افراد تازه‌کار به حال خودشون رها می‌شن که خودشون بفهمن چه کاری رو چه جوری انجام بدن یا قدیمی‌تر ازشون بیگاری می‌کشن. این ضدالگو باعث فشار کاری بالا، ناراحتی و کم‌انگیزه شدن افراد تازه‌کار می‌شه.فاصله قدرت (Power Distance): افراد قدیمی‌تر (قدرتمند‌تر) نظرات نهایی رو می‌دن. این ضدالگو می‌تونه باعث هزینه‌های اضافی پروژه، ضرر مالی و پروژه‌های شکست خورده بشه.رهایی (Disengagement): رها کردن اصول و روش‌ها یا بی‌اهمیتی به کیفیت که منجر به پروداکشن کردن محصولی که هنوز آماده نیست، میشه. علاوه بر این نادیده گرفتن اطلاعات مستند نرم‌افزار، فرضیات بی‌پشتوانه، از دست رفتن اعتماد مشتری و افزایش هزینه کنترل کیفیت از اثرات دیگه این ضدالگو هستن.اعضای خوک‌صفت (Piggish Members): درخواست‌های بیهوده یا اغراق‌آمیز از دیگران، اغلب به شیوه ای خودپسندانه یا آزاردهنده مطرح می‌شن. افزایش هزینه پروژه، خستگی اعضای تیم و کم شدن روحیه تیم از اثرات این ضدالگو هستن.اختلاف DevOps یا DevOps Clash:اختلافات بین توسعه‌دهندگان و نیروهای عملیاتی منجر به کند شدن سرعت توسعه می‌شه. این ضدالگو اثرات مخربی مثل افزایش هزینه پروژه، کم شدن اعتماد، ناتوانی در ایجاد ارتباط، بسته شدن راه نشر دانش، کم شدن سرعت توسعه، کم شدن سرعت انتشار، بیشتر شدن تعداد حادثه‌ها و غیربهینه بودن فرایند استقرار رو با خودش به همراه داره.درس نگرفتن (Unlearning): یه به‌روش یا تکنولوژی جدید که به دلیل نبودن تمایل به تغییر، اجرایی نمی‌شه. کم شدن انگیزه دانش و استفاده نکردن از به‌روش‌ها از اثرات مخبری این ضدالگو هستن.سیلو (Silo): سیلوهای تخصصی که با سیلوهای دیگه ارتباط نمی‌گیرن یا فقط توسط یکی از اعضا ارتباط می‌گیرن. کم شدن تطابق اجتماعی‌فنی، دید تک‌بعدی و رفتار خودخواهانه از اثرات مخرب این ضدالگو هستن.گرگ تنها (Lone Wolf): افرادی که کارشون رو با کسی در میون نمی‌ذارن، با دیگران مشورت نمی‌کنن و تو ارتباط‌شون به کسی اهمیت نمی‌دن. تغییرات معماری بدون مجوز، نگهداشت ضعیف سیستم و خستگی سایر اعضای تیم از اثرات مخرب این ضدالگو هستن.بیشتر سازمان‌ها با Time Warp و Cognitive Distance و DevOps Clash دست و پنجه نرم‌ می‌کنن. همچنین تحقیقات نشون می‌ده که بدهی‌های معماری ارتباطی مستقیمی با Smell‌های ارتباطی دارن. (حدود ۸۰ درصد همسبتگی)مدیریت بدهی اجتماعیهدف نهایی ما در زمان توسعه نرم‌افزار مدیریت بدهی‌هاست و نه جلوگیری کامل ازشون. مدیر پروژه یا مدیر تیم باید به صورت مداوم وجود بدهی‌های اجتماعی رو بررسی کنه.گروه رو بسازهبه گروه کارایی بدهبه صورت مداوم وضعیت گروه رو رصد و ازش مراقبت کنهمدیران باید گروه‌های به‌هم‌پیوسته بسازن، ترجیحا از نظر مکانی نزدیک به هم باشن و امکان ارتباط بین‌شون وجود داشته باشه. زمانی که امکان نزدیکی مکانی به صورت فیزیکی وجود نداره باید روش‌ها و ابزارهای ارتباطی الکترونیکی مناسب (چت تصویری، پیامرسان، جلسات روزانه و …) وجود داشته باشه.در کنار این‌ روش‌ها می‌شه با ابزارهایی مثل CodeFace4Smells یا CodeFace مدل‌های ارتباطی سازمانی و فعالیت‌ افراد رو بررسی و ضدالگوهای ارتباطی سازمان رو با کمک‌شون استخراج کرد اما به طور معمول می‌شه بدون این ابزارها هم ضدالگوهای ارتباطی رو پیدا کرد. روش‌هایی مثل گفتگو‌های یک‌به‌یک دوره‌ای می‌تونن به پیدا کردن این ضدالگوها کمک کنن.جلوگیری از بدهی اجتماعیمثل بدهی مالی، اگه بدهی اجتماعی رو پرداخت نکنیم با گذر زمان بزرگ و بزرگ‌تر می‌شه. به عنوان مثال، مطالعات اخیر نشون می‌ده که تعداد Smellهای ارتباطی تو تیم‌‌های چابک با گذشت هر ماه به شکل خطی افزایش پیدا می‌کنه. هیچ دلیلی وجود نداره که فکر کنیم تیم‌های چابک از این قاعده مستثنی هستن. در ادامه بعضی از Smellها و روش‌های احتمالی حل‌شون رو می‌بینیم.توسعه طبق اصول (Cookbook Development): برنامه‌های آموزشی برای توسعه‌دهنده‌ها. دعوت از سخنران‌ها برای آموزش. اختصاص زمان مشخص به توسعه‌دهنده‌ها برای رشد فردی.پیچیدگی زمانی (Time Warp): بهبود ساختار تصمیم‌گیری. بهبود همگام‌سازی تصمیمات. داشتن نقشه مشخص از جریان‌های ارتباطی (کی با کی صحبت می‌کنه و کی تصمیم‌ می‌گیره)فاصله شناختی (Cognitive Distance): تیم‌سازی (ناهار مشترک، گفتگو‌های هفتگی و …). استفاده از متخصصان ارتباطی برای آموزش. ارائه‌های منظم بین تیمی درباره کارهایی که انجام می‌دن. اجرای کارگاه و ارائه. اسناد بین‌تیمی.بیگاری از تازه‌کارا (Newbie Free-Riding): برنامه‌های آموزشی منظم. جلسات تک به تک منظم و جلسات روزانه منظم و نظرسنجی درباره خلق‌وخوی افراد تیم.فاصله قدرت (Power Distance): دادن کارهای مهم به افراد تازه‌کار و همراه کردن افراد کهنه‌کار برای آموزش‌شون. ایجاد انگیزه در افراد کهنه‌کار برای آموزش و آنبورد کردن تازه‌کارها.رهایی (Disengagement): به توسعه‌دهنده اجازه داده بشه که زمانی از کارشون رو به حل بدهی‌های فنی بپردازن. تیم‌های متنوع (از نظر فرهنگ و جنسیت) بسازین.اعضای خوک‌صفت (Piggish Members): به این افراد نشون بدین که کارشون چطور بهره‌وری رو کاهش می‌ده. برای تعداد درخواست‌هاشون سقف تعیین کنین که متوجه بشه و میزان‌شون رو کم کنه.اختلاف DevOps یا DevOps Clash: مشابه روش‌های Power Distance و Cognitive Distance.درس نگرفتن (Unlearning): کسایی که دانش زیادی تو یه زمینه دارن رو پیدا کنین و ترغیب‌شون کنین به دیگران یاد بدن. با شاخص‌های مختلف بهتر بودن به‌روش‌ها رو به افراد اثبات کنین.سیلو (Silo): سیلوها باید جلسات منظم دوره‌ای با هم داشته باشن.گرگ تنها (Lone Wolf): این افراد رو با اعضای دیگه برای انجام کار دیگه‌ای همراه کنین. شناسایی‌شون کنین و جلوی رفتارشون رو بگیرین.تا واقعیتتو دنیای واقعی اگه بخوایم نرم‌افزاری با عمر طولانی داشته باشیم، باید وجود بدهی درونش رو بپذیریم. با این حال باید به صورت مداوم حدود ۲۰ درصد یا بیشتر زمان‌مون رو صرف شناسایی و بازپرداخت این‌ بدهی‌ها کنیم.منابعTechnical debt in practice how to find it and fix itA Mess is not a Technical Debt.Debt MetaphorTechnical debt isn't technical - Einar W. HøstTechnical DebtPrioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022Pragmatic Technical Debt Management Mehrdad Esmaeilpour Mehrdad Esmaeilpour Wed, 08 Nov 2023 14:16:09 +0330 https://virgool.io/@mehrdadep/%D8%B3%D9%85%D8%AA-%D9%85%D8%A7-%D9%86%DB%8C%D8%B3%D8%AA-%D8%AF%D8%B1-%D8%B3%D8%AA%D8%A7%DB%8C%D8%B4-%D9%85%D8%A7%D8%AA%D8%B1%DB%8C%D8%B3-raci-mo2aenh58fxo تصویر از slidemodel.com«از کی باید بپرسم؟»، «کی پاسخگوئه؟»، «به من ربطی نداره»، «من مسئولش نیستم ولی ...»، «بهتر بود منم در جریان باشم»، «به کی باید تحویل بدیم؟» و ... . اگه روزانه در حین کار با این سوالات و جمله‌ها مواجه می‌شید، احتمالا استفاده از ماتریس RACI برای شفافیت اوضاع به دردتون می‌خوره.تعاریف؛ زمین مشترک ماماتریس RACI از کنار هم قرار گرفتن چهار نقش به وجود اومده:مسئول (Responsible): انجام دهنده کاره. یعنی کسی که مسئولیت تصمیم‌گیری برای روش اجرا و به اتمام رسوندن کار رو بر عهده داره. تو ماتریس RACI یک یا چند نفر می‌تونن R باشن.پاسخگو (Accountable): کسی که علاوه بر مسئولیت، اختیاراتی تو حوزه کارش داره. A مسئول تایید تصمیم‌گیری‌ها و بررسی و تایید نتیجه کارهاست. در واقع A مسئولی هست که اختیار داره (Responsibility + Authority). برای هر کار یک و تنها یک نفر باید A باشه.مشاور (Consulted): متخصصین حوزه که مستقیما مسئول یا پاسخگو نیستن اما نظراتشون برای انجام کارها مهمه. ارتباط با مشاور تو یه کار دو طرفه‌ است و R معمولا تو یه حلقه با C ها در اتباطه. برای هر کار یک یا چند نفر می‌تونن C باشن.مطلع (Informed): افرادی که مستقیما تو انجام یا تصمیم‌گیری کار دخیل نیستن اما وضعیت پیشروی کار براشون مهمه. برای هر کار یک یا چند نفر می‌تونن I باشن. ارتباط با مطلع تو یه کار یه طرفه استهر کدوم از این نقش‌ها به ازای هر کار تعریف می‌شن و بدیهی‌ه که یه نفر تو یه کار می‌تونه R باشه و تو کار دیگه C (یا هر حالت دیگه‌). علاوه بر این یه شخص همزمان می‌تونه برای یه کار R و A باشه اما همه R ها نمی‌تونن A باشن (فقط یک A برای یک کار معنی داره). نقش A، هم در زمان شکست و هم در زمان موفقیت پاسخگوی وضعیت موجود خواهد بود.این ماتریس ساده!خب چطور از ماتریس RACI برای ایجاد شفافیت تو کارها استفاده کنیم.قالب نمونه از ماتریس RACIگام اول: کارهای موجود پروژه تو یه محدوده (Scope) رو مشخص کنیم و اون‌ها رو به ترتیب اجرا مرتب کنیم.گام دوم: ذینفعان (Stakeholders) رو مشخص کنیم و بالای ماتریس قرارشون بدیم. ذینفعان با توجه به محدوده و بزرگی کار می‌تونن تیم‌ها یا افراد باشن. گام‌های ساخت ماتریس، می‌تونن تا پایین‌ترین سطح و برای کوچک‌ترین تیم تکرار بشن.گام سوم: مسئول انجام کارها رو از ذینفعان مشخص کنیم. بعد از این، به ترتیب بقیه نقش‌های هر کار رو هم مشخص می‌کنیم.گام چهارم: گام‌های اول تا سوم باید به تایید همه ذینفعان برسن. هر تیم/فرد باید نقشش در هر کار رو بدونه و بپذیره. اگه تیم/فرد با نقشش در یکی از کارها موافق یا بهش متعهد نباشه احتمال به وجود اومدن مشکل جدی تو پروژه بسیار بیشتر میشه.گام پنجم: نهایی کردن ماتریس و شروع کارها.نهایی شدن ماتریس، به معنای حک شدنش روی سنگ نیست. ترتیب کارها و نقش‌ها می‌تونن با توجه به شرایط پروژه تغییر کنن. مهم اینه که در زمان تغییر گام‌های اول تا پنجم اجرا بشه.به‌روش‌های استفاده از ماتریس RACIمثلث ماتریس RACIمثلث بالا تعداد نقش‌هایی که به یه کار تخصیص داده می‌شن رو مشخص می‌کنه:یک و تنها یک نفر/تیم پاسخگوست.یک یا بیشتر از یک نفر/تیم مسئول کاره. بولد بودن یک R به معنی اینه که فقط یک نفر/تیم مسئول اصلی کار (گردآورنده افراد/تیم‌ها برای کار) هست.یک یا بیشتر از یک نفر/تیم مشاوره.یک یا بیشتر از یک نفر/تیم مطلعه.به‌روش‌های دیگه‌ای هم برای استفاده از ماتریس RACI وجود دارن:تعداد زیادی از کارها نباید به تعداد کمی از افراد/تیم‌ها سپرده بشن. به عبارتی افراد/تیم‌های بهره‌ورتر نباید جور افراد/تیم‌های کم‌تر بهره‌ور رو بکشن.از تعداد زیاد مشاوران برای کار دوری کنین. تعداد زیاد مشاور معمولا روند اجرای کار رو کند می‌کنه.تعداد زیاد مطلع‌ها می‌تونه مشکل گزارش‌دهی به وجود بیاره. این امکان رو بررسی کنین که آیا می‌شه روی پلن توافق کرد و تنها اگه چیزی خارج از پلن اتفاق افتاد مطلع‌ها رو با خبر کرد یا نه.مطمئن باشین که هیچ سلولی از ماتریس خالی نیست (برای یه کار همه نقش‌ها تعریف شدن) و همچنین سلول‌ها رو فقط برای اینکه پر باشن، پر نکنین.مطمئن باشید همه ذینفعان مرتبط با پروژه رو در نظر گرفتید. حذف یا در نظر نگرفتن یک یا چند ذینفع می‌تونه منجر به مشکل در روند اجرای پروژه بشه.خوبی‌ها و بدی‌هاخوبی‌هاشفافیت؛ کی چی کار می‌کنه و چه وظیفه‌ای داره.جلوگیری از بازی اتهام‌زنی (Blame Game)؛ با وجود مطلع‌ها و یک پاسخگو، امکان پیدا کردن سریع‌تر مشکل (قبل از گند خوردن به همه‌چی) وجود داره. این‌طوری میشه از بازی «تقصیر تو بود» جلوگیری کرد.بهبود وضعیت پاسخگویی؛ وقتی نقش‌ها مشخص نباشن همیشه این سوال وجود که پس کی متعهده؟ تعریف دقیق نقش‌ها و اختصاص‌شون به افراد به شفافیت پروژه و رشد فرهنگ پاسخگویی کمک می‌کنه. مناسب برای پروژه‌هایی که چند تیم درگیر انجامش می‌شن.مناسب برای سازمان‌ها و تیم‌هایی با ساختار خطی که امکان تفویض اختیار داخل‌شون وجود داره.بدی‌هااگه کاری تعداد زیادی R داره، پس کی مسئوله؟رعایت تعادل بین پاسخگوها، مسئولان و مشاوران سخته و امکان افتادن تو دام همپوشانی کارها وجود داره.بیشتر به درد کارهای بزرگ می‌خوره. شرکت‌ها یا پروژه‌های کوچیک که نقش بیشتر افراد «آچار فرانسه» است تو پیاده‌سازیش با مشکل مواجه می‌شن.با ساختار بعضی سازمان‌ها در تضاده. این ماتریس به درد ساختارهای خطی می‌خوره و سازمان‌هایی که تصمیم‌گیرهاش تعداد کمی هستن یا مدیریت ذره‌بینی توش رواج داره تو استفاده ازش دچار مشکل می‌شن. شرکت‌های استارت‌آپی معمولا با این تناقض درگیرن: وقتی موسسین یا گروه اندکی از تصمیم‌گیرها باید ریسک زنده‌موندن رو به تفویض اختیارات ترجیح بدن.استفاده از این روش به شکل کلی ممکنه اجرای پروژه رو کندتر کنه. اگه ماتریس RACI با ساختار سازمان سازگار نباشه، هزینه زمانی بیشتری رو به پروژه تحمیل می‌کنه.یه اصلاح کوچولو؛ ماتریس RASCIمثلث ماتریس RASCIبرای حل یکی از بدی‌های ماتریس RACI یه ماتریس دیگه وجود داره که یه نقش تازه واسش تعریف شده.کمک‌حال (Supporting): مسئولی که مسئولیت اصلی کار رو برعهده نداره و در کنار R، کار رو پیش می‌بره. تعداد کمک‌حال‌ها می‌تونه از صفر شروع شه و بیشتر بشه. برای اختصاص نقش S هم باید به به‌روش‌های مربوط به نقش R توجه داشته باشیم.تو ماتریس RASCI هر کار یک و تنها یک R داره.«سمت ما هست!»؛ عادی‌سازی اعتماد گفتیم که پاسخگویی به معنی «مسئولیت + اختیارات»ه اما آیا یه شخص می‌تونه تو همه کارها پاسخگو باشه؟ البته که نه. برای حل این چالش می‌تونیم از تفویض اختیار استفاده کنیم. یعنی شخص پاسخگو تصمیم می‌گیره برای اینکه به شخص دیگه‌ای توان پاسخگویی بده، بخشی از اختیاراتش رو به اون تفویض کنه. تفویض اختیار به خودی خود چالش‌برانگیزه و برای اطمینان از صحت عملکردش، تفویض کننده باید ابزاری برای پایش (Control/Monitor) نحوه استفاده از اختیارات تفویض شده، داشته باشه. در کنار این‌ها تو سازمان‌هایی که به سمت بلوغ حرکت می‌کنن پاسخگویی یه فرد/تیم کمرنگ‌ می‌شه و جای خودش رو به پاسخگویی اشتراکی (Shared Accountability) می‌ده. با پررنگ‌تر شدن اعتماد -که کلید موفقیت سازمان‌هاست- در سطح سازمان، پاسخگویی اشتراکی هم پررنگ‌تر میشه.به این مثال دقت کنید:تیم الف، وجود مشکل X در سازمان/پروژه رو انکار می‌کنهتیم الف، وجود مشکل X در سازمان/پروژه رو می‌پذیره اما نقش خودش در مشکل رو نمی‌پذیره. (همون جمله معرف «سمت ما نیست»)تیم الف، وجود مشکل X رو می‌پذیره و برای حل‌اش با یک/چند تیم دیگه شروع به همکاری می‌کنه.تیم الف، ریسک‌های مرتبط با یه تیم دیگه رو شناسایی می‌کنه و با پیش‌بینی و تحلیل، وجود مشکل X رو قبل از وقوعش به اطلاع ذینفعان می‌رسونه.تو این مثال تو مراحل ۱ و ۲ سطح اعتماد بین افراد/تیم‌های سازمان پایینه و تو مراحل ۳ و ۴ همکاری و پاسخگویی اشتراکی شکل گرفته. ماتریس‌ RACI و روش‌های مشابهش کمک‌مون می‌کنن که میزان اعتماد و در نتیجه پاسخگویی اشتراکی رو در سازمان بالا ببریم. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Mon, 26 Jun 2023 10:26:17 +0330 https://virgool.io/@mehrdadep/%D8%A7%D9%86%D8%AA%D8%B4%D8%A7%D8%B1-%D9%86%D8%B3%D8%AE%D9%87-%D8%A7%DB%8C%D9%86-%D9%82%D9%86%D8%A7%D8%B1%DB%8C-%D8%AE%D8%A7%D9%85%D9%88%D8%B4-lv5jriyjnjqu تصویر از nordapis.comای قناری!قناری‌ها، تو معادن ذغال‌سنگ، به عنوان سیستم طبیعی هشدار استفاده می‌شدن. سیستمی که عاقبت خوشی واسشون نداشت. گازهای سمی مثل دی‌اکسید کربن، مونواکسید کربن یا متان خیلی زودتر از آدما، جون قناری‌ها رو می‌گیرن. وقتی قناری‌ها تو معدن بی‌تابی می‌کردن، معدن‌چی‌ها می‌فهمیدن اوضاع خوب نیست و باید بزنن بیرون. البته این شیوه دیگه از سال ۱۹۸۷ مورد استفاده قرار نمی‌گیره و حالا ما از قناری‌های کوچیک تو نسخه‌دهی‌ها استفاده می‌کنیم تا قبل از انفجار بزنیم بیرون.قناری قهرمان!مهندسی انتشار، واژه‌ایه که برای توصیف فرایندها و کارهای مربوط به انتقال کد از یه ریپازیتوری به یه سیستم در حال اجرای پروداکشن گفته می‌شه. خودکارسازی انتشار نسخه‌ها می‌تونه از خیلی از مشکلات سنتی که با انتشار یه نسخه عجین شده‌ان، جلوگیری کنه. مشکلاتی مثل: نیاز به انجام کارهای پشت‌سر هم و تکراری به شکل دستی، ناپایدار بودن یه فرایند غیرخودکار، ندونستن اینکه وضعیت فعلی چیه و در آخر سخت بودن برگشتن به نسخه قبلی.حالا شیوه انتشار قناری چیه؟ تو این شیوه تغییرات به شکل جزیی و تو یه بازه زمانی مشخص برای تعداد کمی از کاربران منتشر می‌شه. این شیوه بهمون کمک می‌کنه برای انتشار کامل نسخه تصمیم بگیریم -درست مثل قناری‌های در حال مرگ تو معدن- اون بخش از سرویس که تغییرات رو تو خودش داره رو «قناری» صدا می‌کنیم و بقیه بخش‌ها رو «کنترل». منطق پشت این روش هم اینه که قناری همیشه بخش کوچیک‌تری از درخواست‌ها یا کاربران رو نسبت به کنترل شامل می‌شه. شیوه قناری یه فرایند تست A/B موثره.حتی اگه پایپ‌لاین انتشار نسخه‌تون کاملا خودکار باشه باز هم امکان این‌که به شکل کامل همه مشکلاتی که ممکنه تو محیط پروداکشن اتفاق بیفته رو پیدا کنین، خیلی بالا نیست. زمانی که تصمیم به انتشار یه نسخه روی پروداکشن می‌گیرین، استراتژی تست‌تون باید به شکلی باشه که به مقدار قابل توجهی به تغییرات اطمینان داشته باشین و بدونین که نسخه جدید همونطور که انتظار دارین کار می‌کنه. با این وجود محیط تست نمی‌تونه صد درصد مثل پروداکشن باشه و تست‌های ما هم احتمالا همه سناریو‌ها رو پوشش نمی‌دن. بنابراین بعضی از باگ‌ها راه‌شون رو به محیط پروداکشن باز می‌کنن. حالا اگه یه نسخه رو همزمان همه‌جا منتشر کنیم، باگ‌هاش هم دنبالش همه‌جا خواهند رفت.این سناریو زمانی که امکان کشف و حل اشکالات به شکل خیلی سریع وجود داره شاید قابل قبول باشه اما یه راه خیلی بهتر هست. اونم اینه که بخش کوچیکی از ترافیک پروداکشن رو با استفاده از قناری به سمت تغییرات جدید هدایت کنین. استفاده از قناری کمک می‌کنه که اشکالات خیلی سریع و با تاثیر خیلی کم حل بشن.مهندسی انتشار با قناریوقتی نسخه جدیدی از سیستم یا یه بخش اصلیش (مثل تنظیمات یا دیتا) رو منتشر می‌کنیم، با تغییراتی سر و کار داریم که در معرض ورودی‌های دنیای واقعی نبودن. تغییرات واسه‌مون امکانات و توانایی‌های جدید به وجود میارن اما همیشه همراه خودشون ریسکی دارن که در زمان انتشار، مشخص می‌شه. هدف ما کنترل کردن این ریسکه. این کار رو از طریق تست کردن تغییرات روی بخش کوچیکی از ترافیک انجام ‌می‌دیم. اینجوری می‌تونیم مطمئن بشیم اثر مخربی وجود نداره.فرایند قناری بهمون کمک می‌کنه تغییرات‌مون رو با اعتماد به نفس در معرض دیتا و ورودی بزرگ و بزرگ‌تر قرار بدیم. استفاده از قناری همچنین کمک‌مون می‌کنه نقاط کوری که با فریم‌ورک‌های تست مثل یونیت تست یا تست بار قابل شناسایی نیستن رو پیدا کنیم.چی چیزایی لازمه؟برای پیاده‌سازی قناری رو یه سرویس به این موارد نیاز داریمروشی که باهاش بتونیم تغییرات رو برای بخش کوچکی از سرویس در دسترس قرار بدیمیه فرایند ارزیابی که باهاش بتونیم مشخص کنیم تغییرات روی قناری «خوب» یا «بد» هستنهمگام‌سازی ارزیابی‌های قناری با فرایند‌های انتشاردر نهایت یه فرایند خوب قناری قراره نسخه‌های بد رو به شکل قطعی و نسخه‌های خوب رو بدون درست‌نماها مشخص کنه.چقدر زمان لازمه؟وقتی می‌خوایم زمان مناسب برای قناری رو انتخاب کنیم باید به سرعت انتشار نسخه‌هامون دقت کنیم. اگه هر روز نسخه می‌دیم، نمی‌تونیم قناری رو یه هفته طول بدیم. اگه هر هفته نسخه منتشر می‌کنیم، قناری‌هامون باید طولانی‌تر عمر کنن. اگه هر روز نزدیک بیست نسخه منتشر می‌کنیم، اونوقت عمر قناری‌ها باید خیلی کوتاه‌تر باشه. در نظر داشته باشید که امکان این‌که همزمان چند نسخه قناری داشته باشیم وجود داره اما این‌کار انرژی ذهنی زیادی از ما برای دنبال کردن وضعیت سیستم می‌گیره. مثلا وقتی تحلیل وضعیت فعلی سیستم تو بازه خیلی کوتاه مورد نیازه وجود چندین وضعیت همزمان کار رو پیچیده می‌کنه. پیشنهاد معمولا اینه که در یک زمان تنها یک نسخه قناری وجود داشته باشه.انتخاب و ارزیابی متریک‌هااز چه معیارهایی می‌تونیم برای ارزیابی این‌که یه قناری منجر به نسخه خوب یا بد شده استفاده کنیم؟متریک‌ها باید نشان دهنده مشکل باشنهر متریکی اگه به شکل افراطی انتخاب بشه، می‌تونه مشکل‌ساز باشه، در عین حال اضافه کردن متریک‌های جدید هم هزینه‌بره. باید بتونیم با دقت رفتار درست و قابل قبول یک متریک رو در فرایند قناری کردن، تعریف کنیم. اگه این تعریف خیلی سفت و سخت باشه، تعداد درست‌نماها خیلی زیاد می‌شن و ممکنه به اشتباه فکر کنیم تغییرات قناری درست نیستن، در حالی که واقعا اینطور نیست. از طرفی اگه تعریف‌مون از رفتار درست خیلی ساده باشه، امکان اینکه تغییرات نادرست باشن و متوجهشون نشیم وجود داره. انتخاب این‌که رفتار درست چیه فرایند هزینه‌بری هست که زمان‌بره و نیاز به آنالیز داره. با این حال اگه این‌کار به درستی انجام نشه، نتایج کار گمراه‌کننده خواهند بود. همچنین با بزرگ‌تر شدن و تغییر تو کل سیستم این تعاریف باید بازنگری یا بازتعریف بشن و همیشه در کنار کل مجموعه رشد کنن.قبل از هر چیز، متریک انتخابی باید بتونه مشکل رو در سرویس مشخص کنه. این بخش کمی سخته چرا که تعریف مشخصی از مشکلی که هنوز به وجود نیومده، وجود نداره. شاید بتونیم یه درخواست کاربر که با خطا رو به رو شده رو یه مشکل فرض کنیم اما اگه درخواست کاربر ده درصد بیشتر زمان ببره یا ده درصد بیشتر مموری نیاز داشته باشه چی؟ معمولا استفاده از SLI ها نقطه شروع خوبی برای انتخاب متریک‌ها هستن. SLI های خوب به میزان قابل توجهی سلامت سیستم رو مشخص می‌کنن. به عنوان مثال برای یه سرویس که API ارائه می‌ده، کد وضعیت HTTP (۲۰۰ و ۳۰۰ و ...)، مدت زمان پاسخ‌دهی، میزان درستی و ... می‌تونن متریک‌های خوبی باشن.متریک‌ها باید نمایشگر و قابل انتساب باشنمنبع تغییرات تو متریک‌ها باید به طور واضح قابل انتساب به تغییراتی که قناری کردیم، باشن و فاکتورهای بیرونی نباید روی این متریک‌ها اثر بذارن. تو سرویس‌های بزرگ (به عنوان مثال تعداد زیاد سرورها و کانتینرها) معمولا عوامل جانبی مثل ماشین‌هایی که کرنل متفاوت دارن یا مشخصات سخت‌افزاریشون فرق می‌کنه یا تو قسمت پر بار شبکه قرار گرفتن وجود داره. تغییراتی که بین قناری و کنترل وجود داره باید توزیع متناسبی بین این مدل تفاوت‌ها داشته باشه.مدیریت قناری‌ها در واقع ایجاد تعادل بین نیروهای مختلفه. زیاد کردن جمعیت قناری‌ها یک راه کم کردن تاثیر این مشکله. زمانی که به جمعیت مورد قبول قناری برای سیستم خودمون رسیدیم باید مطمئن بشیم که تمام متریک‌هایی که انتخاب کردیم می‌تونن مغایرت‌های شدید رو نمایش بدن.استراتژی‌های انتخاب کاربرانزمانی که متریک‌ها و درصد قناری‌ها مشخص شدن باید روشی رو برای انتخاب کاربرانی که به نسخه قناری هدایت میشن یا ازش استفاده می‌کنن داشته باشیم. چهار روش مختلف برای این‌ کار وجود داره. تصادفی: تو این روش همونطور که از اسمش پیداست درصد مورد نظر از کاربران رو به شکل تصادفی به قناری می‌فرستیم. منطقه جغرافیایی: کاربران با توجه به منطقه جغرافیایی‌شون انتخاب می‌شن. به عنوان مثال می‌شه نسخه جدید رو برای هر منطقه تو زمان ترافیک کم منتشر کرد.استفاده‌کننده‌های اولیه: با استفاده از این روش کاربرانی که دوست دارن تو مرحله قناری از محصول استفاده کنن درخواست می‌دن و از نسخه‌های قناری استفاده می‌کنن. یکی از مزیت‌های این روش اینه که این مدل کاربران معمولا تمایل دارن نظرات سازنده‌شون رو به اشتراک بذارن.مدل Dogfooding: این اصطلاح به عبارت «غذای سگ خودت رو بخور» اشاره داره و به معنی اینه که نسخه‌های قناری برای کاربران داخلی و کارمندان منتشر می‌شن.گاهی بهترین انتخاب، تنها یک گزینه نیست و میشه هر کدوم از روش‌های گفته شده رو در ترکیب با همدیگه استفاده کرد. نقاط تاریک استفاده از قناری‌هاهیچ روشی کامل نیست و قناری‌ها هم بهترین پرنده‌ها نیستن. ببینیم با استفاده از قناری‌ها چه چیزهایی ممکنه اشتباه پیش برن.کلافگی: کاربرانی که از نسخه‌های قناری استفاده می‌کنن می‌تونن با بدترین باگ‌ها روبه‌رو بشن. بعضی کاربران ممکنه با فهمیدن این‌که از نسخه‌های قناری استفاده می‌کنن حس موش آزمایشگاهی بگیرن. اگه این موضوع باعث نگرانی‌تون می‌شه از برنامه‌های داوطلبانه واسه قناری استفاده کنین.هزینه: استفاده از قناری به زیرساخت بیشتر نیاز داره. زیرساخت بیشتر یعنی هزینه بیشتر. پیچیدگی: استفاده از چندین ماشین مختلف برای پروداکشن، مهاجرت کاربران به قناری و کنترل، مانیتور کردن تغییرات، همه و همه کارهای پیچیده‌ای هستن. برای کنترل کردن این پیچیدگی میزان انجام‌شون به شکل دستی رو به حداقل برسونین.زمان: ایجاد و مدیریت یک پایپ‌لاین خوب قناری زمان و تلاش زیادی می‌بره اما اگه به درستی انجام بشه باعث نسخه‌دهی امن‌تر می‌شه.پایگاه‌داده‌ها: کتاب‌های زیادی درباره این‌که چطور اسکیما پایگاه‌داده‌ها رو تغییر بدیم نوشته شده. در زمان استفاده از روش قناری یک مشکل بزرگ وجود داره. اسکیما باید با هر دو نسخه کار کنه. بنابراین باید نسخه‌هامون همیشه backward-compatible باشن و این یعنی اضافه کردن یک لایه دیگه از پیچیدگی.قناری برای همه نیستاستفاده از قناری‌ها برای همه شیوه‌های توسعه نرم‌افزار مناسب نیست. قناری‌ها با نرم‌افزارهایی که درون حلقه توسعه مداوم هستن سازگارترن. این مدل نرم‌افزارها بهتره از قناری استفاده نکنن:نرم‌افزارهای بیمارستانی، هوایی و صنعتی که نسخه‌دهی مداوم واسشون معنی‌ نداره و حتی خطرناکهنرم‌افزارهایی که با منابع حساس یا موقعیت‌های مرگ و زندگی در ارتباطن مثل نرم‌افزار نیروگاه اتمی یا شبکه توزیع برق و ...نرم‌افزارهای مالی که خطا داخل‌شون منجر به عواقب فاجعه بار میشهنرم افزارهایی که امکان بروزرسانی ریموت‌شون وجود نداره و مستقیم روی سیستم‌ کاربرها نصب می‌شنمنابع[1] Domestic canary[2] Google site reliability engineering By Alec Warner and Štěpán Davidovič[3] What is Canary Deployment By Tomas Fernandez Mehrdad Esmaeilpour Mehrdad Esmaeilpour Sat, 17 Dec 2022 21:17:40 +0330 https://virgool.io/@mehrdadep/%D8%A7%DB%8C%D9%86-%D8%A8%DB%8C%D9%84-%D8%B1%D8%A7-%D8%A8%D8%A7-%D9%85%D9%86-%D8%A8%D8%B2%D9%86-%D9%86%D9%88%D8%B3%D8%A7%D8%B2%DB%8C-%D9%88-%D8%A7%D8%B2-%D9%86%D9%88-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%DA%A9%D8%AF%D9%87%D8%A7-q4wljc1915ou تصویر از trees.comپیش از گفتارنوسازی (Refactoring) و از نو نویسی (Rewriting) رو به روی هم نیستن. ما فقط دو انتخاب نداریم که یا «کدهامون رو دور بریزیم و از نو شروع کنیم» یا «یک بیل برداریم و آروم آروم خاک‌برداری کنیم». برای زنده نگه داشتن یک محصول نرم‌افزاری باید روش‌های مختلف رو در تلفیق با هم استفاده کرد. گاهی معماری تغییر می‌کنه و نوسازی بی‌معنی میشه و گاهی تنها با نوسازی میشه عملکرد رو بهبود داد.از نو نویسی رو گاهی معادل ضربه فنی شدن محصول، از دست بدهی‌های فنی می‌دونن. اگه تو تیمی هستین که تا این حد بدهی فنی بار آوردین احتمال اینکه محصول از نو نوشته شده‌‌تون هم همینقدر بدهی فنی ایجاد کنه، کم نیست. نوسازی‌های دنباله‌دار و همیشگی و از نو نویسی‌های به‌جا، در کنار هم، محصول رو زنده‌ و پویا نگه می‌دارن. اینجا توضیح دادم که چطور با استفاده از نوسازی و از نو نویسی به تیم قبلیم کمک کردم محصول‌مون رو بهبود بدیم.نوسازینوسازی کد تغییر ساختار داخلی اون، بدون ایجاد تغییر تو رفتار بیرونیشه. به عنوان مثال با حذف کدهای اضافی، یا شکستن یه بخش بزرگ کد به زیربخش‌های کوچک‌تر که هر کدوم وظیفه مشخص خودشون رو دارن میشه کد رو نوسازی کرد.روش توسعه «برنامه نویسی Extreme» که ازش به عنوان نوسازی بی‌رحم هم اسم می‌برن، معتقده که کدهامون باید به شکل مداوم نوسازی بشن. به شکل تئوری برنامه‌نویس‌هایی که به صورت مداوم کدهاشون رو نوسازی می‌کنن، اون رو برای پذیرش تغییرات جدید آماده‌تر تحویل می‌گیرن. یکی از اهداف نوسازی، جنگیدن با بدهی‌های فنیه. نوسازی کدهای پیچیده و کثیف رو به کدهای ساده‌تر و تمیزتر تبدیل می‌کنه. اما کد تمیز چه ویژگی‌هایی داره؟کد تمیز برای بقیه قابل درک و واضحه.کد تمیز، قسمت‌های تکراری نداره.کد تمیز تعداد کلاس‌های حداقلی داره.همه تست‌ها تو کد تمیز با موفقیت انجام می‌شن.نگهداری و توسعه کد تمیز آسون‌تر و ارزون‌تره.چه زمانی نوسازی کنیم؟اگه برای بار اوله که انجامش می‌دی، فقط انجامش بده.اگه دومین باره که انجامش می‌دی یه کم اخم کن و همون کار رو تکرار کن.دفعه سوم که شد نوسازی رو شروع کن.ویژگی جدید اضافه می‌کنی؟نوسازی به درک کد بقیه کمک می‌کنه. اگه با کد کثیف بقیه سر و کار داری، اول نوسازیش کن. با این کار هم برای خودت آسونش می‌کنی و هم نفر بعد از خودت.کد نوسازی شده، اضافه کردن ویژگی جدید رو آسون می‌کنه. تغییر تو کد تمیز ساده‌تره.باگ رو اصلاح می‌کنی؟باگ‌ها تو نقاط تاریک و کثیف کد زندگی می‌کنن. با تمیز کردن کد پیدا کردن‌شون آسون‌تر می‌شه.نوسازی‌های کوچک و مداوم، نیاز به نوسازی‌های بزرگ رو کم می‌کنن.زمان بازبینی کدبازبینی کد شاید آخرین فرصت قبل از انتشار کد باشه. اگه با نویسنده اصلی کد همراه بشی و کد رو در زمان بازبینی، نوسازی کنین خیلی سریع‌تر به نتیجه می‌رسین.تکنیک‌های نوسازیروش‌های زیادی برای نوسازی کدها وجود داره و میشه گفت نوسازی کدها هیچوقت تموم نمیشه و همیشه جا برای بهبود وجود داره. اینجا خیلی خلاصه به بعضی از تکنیک‌ها اشاره می‌کنم.اصلاح متدها: بار اصلی نوسازی روی دوش چگونگی استفاده از متدهاست. متدهای طولانی و بزرگ ریشه بیشتر کثیفی‌ها هستن. اتفاقاتی که توی بدنه متدهای بزرگ میفته باعث میشه درک منطق‌شون دشوار بشه و اگه نتونیم منطق متدی رو بفهمیم تغییر دادنش ممکن نخواهد بود. با روش‌هایی مثل استخراج‌ متدها، شکستن منطق، اصلاح پارامترها میشه وضعیت رو بهبود داد.انتقال ویژگی‌ها بین اشیا: توزیع متدها و ویژگی‌ها بین کلاس‌ها باعث میشه کد تمیزتری داشته باشیم. کارهایی مثل جابجا کردن متدها یا فیلدها از یه کلاس به کلاسی که استفاده بیشتری از اون داره. تبدیل یه کلاس بزرگ به دو یا چند کلاس کوچک‌تر که هر کدوم هدف مشخصی دارن نمونه‌هایی از اجرای این تکنیک هستن.ساده‌سازی عبارات شرطی: عبارات شرطی با گذر زمان پیچیده و پیچیده‌تر می‌شن. برای ساده سازی عبارات شرطی میشه از روش‌هایی مثل یکی کردن شرط‌هایی که نتیجه مشابه به همراه دارن، جابجا کردن کدهای تکراری که توی همه شاخه‌ها استفاده شدن، حذف فلگ‌های کنترلی داخل حلقه‌ها و استفاده از ویژگی‌های حلقه‌ها (break, continue, return) به جای اون، استفاده کرد.ساده‌سازی صدا کردن متدها: با روش‌هایی مثل اضافه کردن پارامتر مورد نیاز بیرونی به امضای متد یا حذف یه پارامتر بلااستفاده از امضا، تغییر نام متد به چیزی که کارش رو توضیح بده، ساخت متدهای مجزا از متدی که با استفاده از شروط کارهای مختلفی انجام می‌ده و ... میشه کد تمیزتری درست کرد.مزایای نوسازینوسازی همیشه گزینه‌ روی میزه. برنامه‌نویس‌ها نیازی به اجازه کسی برای نوسازی ندارن.امکان نوسازی برای هر مدل معماری و نرم‌افزاری وجود داره.نوسازی به بالا بردن کیفیت کد بدون کند کردن فرایند توسعه کمک می‌کنه. برخلاف از نو نویسی، نوسازی نیاز به مدیریت دو یا چند کدبیس مجزا از هم، به صورت همزمان رو از بین می‌بره.اگه برنامه‌نویسی تنها روی بخشی از کد یه نرم‌افزار کار می‌کنه می‌تونه تنها همون بخش رو نوسازی کنه.معایب نوسازیدرسته که نوسازی کیفیت کد رو بهبود می‌ده اما توانایی حل مشکلات عمیق رو نداره. مثلا نرم‌افزاری که معماری بهینه‌ای نداره رو نمیشه با نوسازی بهینه کرد.نوسازی همیشه شرایط موجود نرم‌افزار رو حفظ می‌کنه. بنابراین امکان اینکه بعد از نوسازی هنوز امکان اضافه کردن ویژگی جدید به محصول نداشته باشیم، وجود خواهد داشت.برنامه‌نویس‌هایی که از تست‌نویسی فراری هستن از نوسازی هم فراری خواهند بود، چون نوسازی بدون وجود تست، معنی نداره.با اینکه یکی از اهداف نوسازی کم کردن میزان کدهاست اما گاهی برای بهینه شدن باید میزان کدها را افزایش بدیم. این یعنی کدهای بیشتر برای نگهداری و تست.از نو نویسیگاهی اوقات نیازه به جای برررسی، خوندن و تمیز کردن کدهای قدیمی، کدها رو از نو بنویسیم. برخلاف نوسازی که تکنیک‌ها و روش‌های مختلفی داره و با تکرار و تمرین می‌شه توش بهتر شد، از نو نوشتن کد به نظر سرراست‌تر میاد، چرا که باید ویژگی‌های موجود تو اون بخش از کد که داریم از نو می‌نویسیمش رو، خب از نو بنویسیم!برای از نو نویسی معمولا تیم‌ها به دو بخش تقسیم می‌شن. یک بخش کد قدیمی رو نگهداری می‌کنه و بخش دوم شروع به از نو نوشتن می‌کنه. اتفاق ناگوار اینجا اینه که کد قدیمی هنوز در حال کاره و نیاز به بروزرسانی و اضافه کردن ویژگی‌های جدید داره. بنابراین از نو نویسی اگه درست مدیریت و برنامه‌ریزی نشه می‌تونه اصطلاحات «محصول قدیمی» و «محصول جدید» رو ایجاد کنه و اینطوری محصول جدید هیچوقت جایگزین محصول قدیمی نشه. گاهی اوقات چاره‌ای جز از نو نوشتن همه محصول نیست (وقتایی که معماری کل محصول رو تغییر می‌دیم و ...) اما همیشه بهتره از نو نوشتن کد رو روی ویژگی‌های کوچک‌تر محصول پیش ببریم.مزایای از نو نویسیاز نو نوشتن کد، راه رو برای ورود کاربران جدید، تکنولوژی‌های جدید و بازار جدید فراهم می‌کنه. به عنوان مثال میشه یه محصول که وابسته به سیستم‌عامل ویندوز بود رو روی وب از نو نوشت و بازار هدفش رو گسترش داد.از نو نویسی کدبیسی تازه و تمیز ایجاد می‌کنه (البته اگه بشه حفظش کرد)از نو نویسی کدهای legacy رو به شکل کامل کنار می‌ذاره و نیاز به بروزرسانی تکنولوژی‌ها و بازبینی و اصلاح syntax زبان‌ها رو از بین می‌بره.معایب از نو نویسیاز نو نویسی کامل، زمان‌بر و هزینه‌بره و تنها وقتی باید سراغش رفت که توان هزینه کردن زمان و پول براش وجود داشته باشه.کد قدیمی کثیفه و ممکنه کثیف‌تر هم بشه. برای از نو نویسی، برنامه‌نویس‌ها باید به شکل مداوم کدهای قدیمی رو بررسی کنن. وجود دو دنیای مجزا برای کد جدید و قدیم، باعث میشه نتیجه این بررسی‌ها همیشه بروز نباشه.از نو نویسی لزوما مساله کد کثیف رو حل نمی‌کنه و بهتره ازش به عنوان راه حل تمیز کردن کد استفاده نشه.منابع https://refactoring.guruNdepend blog postRefactor vs. rewrite: Deciding what to do with problem software Mehrdad Esmaeilpour Mehrdad Esmaeilpour Sat, 17 Dec 2022 21:16:21 +0330 https://virgool.io/@mehrdadep/%D9%86%D8%AA-%D9%86%DA%AF%D9%87%D8%AF%D8%A7%D8%B1%DB%8C-%D9%88-%D8%AA%D8%B9%D9%85%DB%8C%D8%B1-%D9%BE%DB%8C%D8%B4%DA%AF%DB%8C%D8%B1%D8%A7%D9%86%D9%87-%D8%AF%D8%B1-%D8%AA%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-g2eru933hip1 نت پیشگیرانه در تیم‌های کوچکFix it before it breaksنت (تعمیر و نگهداری) پیشگیرانه (Preventive Maintenance)، یه استراتژی فعال تو نگهداری از ابزار و منابع‌ه که در نهایت باعث میشه هزینه تعمیر و نگهداری نهایی (در صورت خرابی و نیاز به توقف تولید) تا ده برابر کاهش پیدا کنه. تو این نوشته قصد دارم اول با این مفهوم تو حوزه اصلیش (تولیدی‌ها، کارخونه‌ها و ...) آشنا بشیم و در نهایت ببینیم چطور میشه این دیدگاه رو به نگهداری تیم‌های نرم‌افزاری تعمیم داد.به طور خلاصه نت پیشگیرانه:یه استراتژی فعال‌ه یعنی پیش از اینکه یه اتفاق کوچک تبدیل به یه مساله بزرگ بشه باهاش رو‌به‌رو می‌شیم.روتین و چک‌لیست داره یعنی بر اساس یه برنامه از پیش تعیین شده پیش می‌ریم.چک‌لیست کارهای نت پیشگیرانه رو میشه با سه پارامتر اصلی از هم تفکیک کرد: ضروری یا غیرضروری بودن، هرمی یا غیر هرمی و کارهای بازبینی محور یا تسک‌محورنت پیشگیرانه چیه؟یکی از نکات اصلی که نت پیشگیرانه رو از انواع دیگه استراتژی‌های نگهداری متمایز می‌کنه روتین بودن کارهاست. نگهداری تو یه زمان‌بندی از پیش تعیین‌شده انجام می‌شه تا اطمینان حاصل کنیم که ابزار درست کار می‌کنن و مشکلی براشون پیش نمیاد. بنابراین این روش بیشتر برای ابزاری مناسبه که این ویژگی‌ها رو داشته باشن:روش‌های پیشگیری از خطانسبت مستقیم ریسک خطا با تعداد استفاده (استفاده بیشتر احتمال خرابی رو زیاد کنه)داشتن نقش اساسی در فعالیت اصلی شرکت (تولیدی، کارخونه و ...) یا ایمنی و سلامت کارکنانکارهایی که باید برای نت پیشگیرانه انجام بدیم وابسته به ابزارمون‌ه. برای مثال، یه وسیله نیاز به تمیزکاری یا روغن‌کاری دوره‌ای داره یا نیازه که به شکل دوره‌ای قطعات داخلیش بازبینی و در صورت نیاز تعمیر یا تعویض بشن که کل دستگاه درست و دقیق کار کنه. نت پیشگیرانه فقط روی ماشین‌آلات و دستگاه‌ها کاربرد نداره و منابع آب، سیستم‌های الکتریکی و ... هم باید به شکل منظم بررسی بشن.انواع نت پیشگیرانهچک‌لیست کارهای نت پیشگیرانه رو میشه با سه پارامتر اصلی از هم تفکیک کرد: ضروری یا غیرضروری بودن، هرمی یا غیر هرمی و کارهای بازبینی محور یا تسک‌محورضروری یا غیر ضروری بودن کارهابه کارهایی که برای حفظ امنیت و سلامت بهشون نیازمندیم و انجام‌شون محدودیت زمانی داره، کارهای ضروری می‌گیم. کارهای ضروری رو نمی‌شه لغو کرد یا به زمان دیگه‌ای موکول کرد. از طرف دیگه کاری که بدون آسیب جدی یا کاهش کارایی میشه به زمان‌ دیگه‌ای موکول کرد یه کار غیر ضروریه.هرمی (pyramiding) یا غیر هرمی (non-pyramiding) بودن کارهااگه یه کار بنا به دلایلی تا زمان بازبینی بعدی به تعویق بیفته، یادداشتی شامل زمان اصلی بازبینی به کار اضافه می‌کنیم. به این کار یه کار هرمی می‌گیم. اگه زمان اصلی رو یادداشت نکنیم و فقط از زمان جدید استفاده کنیم کار غیر هرمی‌ه.بازبینی‌محور یا تسک‌محور بودن کارهاتو کارهای بازبینی‌محور نتیجه کار فعلی روی روند انجام کار بعدی اثرگذاره اما میشه تعمیرها و بهبودهای کوچکی رو بدون وابستگی کارهای دوره‌ای به هم اجرا کرد. این کارها تسک‌محور هستن.نت پیشگیرانه در تیم‌های نر‌م‌افزاریتیم‌های نرم‌افزاری تو متدولوژی‌های پرکاربرد فعلی معمولا تا سقف دوازده نفر عضو دارن. درسته که برای انجام کارها تو تیم‌های نرم‌افزاری به ابزارهای ارتباطی، مدیریت کارها، مدیریت نسخه کدها و ... و سخت‌افزار (لپ‌تاپ، مانیتور و ...) نیاز داریم اما در نهایت منبع اصلی یه تیم نرم‌افزاری تا حد زیادی اعضای اون تیم هستن. در ادامه بعضی از روش‌های موجود رو به عنوان نت پیشگیرانه تو تیم نرم‌افزاری بررسی می‌کنیم.نگهداری از ابزاراگرچه اعضای تیم مهم‌ترین بخش تیم‌های نرم‌افزاری هستن اما بدون ابزار مناسب تیم‌ها کارایی مناسبی نخواهند داشت. اما برای ارتباطات درون تیمی، بین تیمی، بین تیم و مشتری ابزارهای مختلفی وجود داره که می‌تونن به شکل self-hosted یا cloud-based مورد استفاده قرار بگیرن. همچنین برای کنترل نسخه کد، دیزاین‌ها، مستندات، مدیریت کارها، workflowها و ... هم همین مدل انتخاب‌ها وجود داره. نت پیشگیرانه در زمینه انتخاب بین self-hosted و cloud-based پیشنهاد ویژه‌ای برامون نداره.اگه از ابزارهای self-hosted استفاده می‌کنین:بروزرسانی دوره‌ای نرم‌افزارها برای حل مشکلات امنیتی، کارایی و ...تهیه نسخه پشتیبان از داده‌های موجود. بازه اجرایی این روتین با توجه به نرخ تغییرات برای تیم‌های مختلف متفاوته.افزایش/کاهش منابع سخت‌افزاری مصرفی با مانیتور کردن مصرف فعلی. این کار بهتره به صورت بازبینی‌محور انجام بشه.اگه از ابزارهای cloud-based استفاده می‌کنین:تهیه نسخه پشتیبان از داده‌های موجود (سازگار با سایر ابزارهای cloud-based) با توجه به امکان فیلتر/تحریمبررسی دوره‌ای و پیش‌ از موعد امکان تمدید (در صورت subscription-based بودن ابزار)برگزاری جلسات تک‌به‌تک با اعضای تیمهدف این جلسه بازبینی، ارزیابی و هدف‌گذاری برای هر کدوم از اعضای تیم‌ه که باید به صورت برنامه‌ریزی شده و دوره‌ای انجام بشه. در قالب همین جلسه می‌شه اختلافات کوچک درون‌تیمی رو شناسایی کرد و قبل از بزرگ شدن مشکل، راه‌حلی رو براش اجرا کرد. پیدا کردن ریشه مشکلاتی مثل کم‌شدن کارایی، تمرکز و ... هم از طریق همین جلسه امکان‌پذیره. جلسه تک‌به‌تک باید به شکل بازبینی‌محور اجرا بشه و عملکرد اعضا تو هر دوره در مقایسه با دوره‌های قبل سنجیده بشه.تیم‌سازی به صورت دوره‌ایارتباط انسانی و حسی می‌تونه اعضای تیم رو به هم نزدیک‌تر کنه و درک اون‌ها از شرایط مختلف روحی و جسمی سایر اعضا رو بالا ببره. این مدل ارتباطات معمولا تو محیط کار و در زمان انجام کار شکل نمی‌گیرن و نیاز به برنامه‌های جدا از روند انجام کارهای اصلی دارن و گاهی نیازه اعضای تیم برای مدت کوتاهی کار نکنن. تیم‌سازی هم باید به صورت دوره‌ای و برنامه‌ریزی شده و هم با اهداف مشخص انجام بشه. افزایش حس تعلق و تعهد شغلی (Loyalty/Engagement) با روش‌های مختلف (پاداش مالی و ...)، کمک به اعضا برای ارتباط گرفتن با کار معنادار (با جابجایی نقش، سمت و مسئولیت‌ها) می‌تونن از اهداف تیم‌سازی باشن. گاهی هم لازمه با بررسی بازبینی‌محور افراد رو از تیم حذف یا به تعدادشون اضافه کنیم. چرا باید نت پیشگیرانه رو تو تیم نرم‌افزاری جدی بگیریم؟تو صنعت زمانی رو که برای انجام روتین‌های تعمیری یا اصلاحی انتخاب می‌کنن از طریق محاسبات ریاضی و با توجه به هزینه فرصت از دست رفته می‌سنجن. هزینه فرصت از دست رفته در واقع یه تصمیم مهم بین هزینه توقف تولید برای انجام اقدامات اصلاحی تو مدت زمان محدود و پذیرش ریسک توقف تولید به دلیل خرابی دستگاه‌هاست. همونطور که بالاتر اشاره کردم منبع اصلی تیم‌های نرم‌افزاری اعضای تیم هستن. این ریسک در تیم نرم‌افزاری یعنی از دست دادن افراد (ترک تیم، کم شدن وفاداری و ...) بنابراین با اقدامات روتین پیشگرانه میشه تا حدی این ریسک و محتمل شدن هزینه گزاف تیم‌سازی مجدد رو کاهش داد.منابع:[1] Preventive Maintenance as the Key to Efficient Production Mehrdad Esmaeilpour Mehrdad Esmaeilpour Wed, 16 Nov 2022 00:25:16 +0330 https://tech.arvancloud.ir/گاه-شمار-رنج-های-مکرر-فیلترینگ-چطور-تو-محصول-حادثه-آفرید-xvbfzzg4pyn7 شبکه توزیع محتوا بدون اینترنت آزاد مثل دوچرخه بدون چرخه. سرورهای لبه شبکه‌ توزیع محتوا تو قاره‌های مختلف قرار گرفتن و برای ساختن یه ابر دور سرویس مشتری‌ها، نیاز به اینترنت بدون محدودیت دارن. مهم‌ترین هدف این شبکه، دسترسی‌پذیری بیشتر و سرعت و امنیت بالاتر برای سرویس‌های کاربرانه.فرض کنید شما سروری رو از یکی از ارائه‌دهندگان خدمات ابری (ایران‌سرور، پارس‌پک، زس، آروان یا ...) تو یکی از شهرهای ایران (برای مثال تهران) خریدید. حالا تو سرورتون یه وبسایت راه‌اندازی کردید و توش تصاویر بامزه از گربه‌ها رو قرار می‌دید. یکی از کاربراتون از آمریکا بهتون پیام می‌ده که سرعت بارگذاری سایت‌تون پایینه و روی تجربه‌ کاربریش از استفاده از سایت‌تون اثر گذاشته. اینجاست که شبکه توزیع محتوا به کمک‌تون میاد. با استفاده از شبکه توزیع محتوا، کاربر آمریکایی‌تون به سرورهای لبه تو آمریکا متصل میشه و محتوای Cache شده سایت‌تون رو با نهایت سرعت بارگذاری می‌کنه.حالا چه اتفاقی میفته اگه شرکت ارتباطات زیرساخت تصمیم بگیره محدودیت‌های سلیقه‌ایش روی اینترنت اعمال کنه؟ تو روزهای اخیر این اتفاق به شکل گسترده افتاد و ما توی بخش رابط کاربری شبکه‌ توزیع محتوا با مشکلات تازه و بیهوده درگیر شدیم. لیست TLD ها که فیلتر شدما برای تشخیص درست فرمت دامنه‌ها و اینکه آیا زیردامنه هستن یا نه از دو تا لیست متن باز و تجزیه کردن‌شون استفاده می‌کنیم. قبلا راجع به تجزیه کردن یکی از این لیست‌ها با Golang مطلبی نوشتم. https://publicsuffix.org/list/public_suffix_list.dathttps://data.iana.org/TLD/tlds-alpha-by-domain.txtاین تشخیص بهمون کمک می‌کنه که nameserver های دامنه رو درست پیدا کنیم و همچنین پلنش رو درست تنظیم کنیم. اگه این لیست‌ها نباشن شما اصلا نمی‌تونین دامنه جدیدی تو پنل ثبت کنین.حالا کاربر آمریکایی شما از سرعت سایت‌تون ناراضیه و شما قصد دارین از شبکه توزیع محتوا استفاده کنید اما این دو تا لیست فیلتر شدن، زمان کش شدن‌شون هم منقضی شده و ما برای دریافت مجددشون مشکل داریم. این یعنی حادثه اول.نمیشه نسخه جدید داد اما باید نسخه جدید دادما هیچ‌وقت کد روی پروداکشن رو مستقیم عوض نمی‌کنیم و برای هات‌فیکس‌ها از فرایندی از پیش تعیین شده استفاده می‌کنیم. فرایندی که اینجا توضیحش دادم. حالا با فیلتر شدن لیست TLD ها مجبور بودیم تو شرایطی که کسی توان روحی و جسمی کار کردن نداشت برای انتشار نسخه هات‌فیکس آماده بشیم و اینجا بود که با حادثه دوم روبه‌رو شدیم. امکان دریافت Image ها از داکر وجود نداشت چرا که شبکه رو با اختلال عجیبی مواجه کرده بودن. بنابراین باید فرایند و روش درست رو زیرپا میذاشتیم. باید تو پادهای مختلف و به شکل دستی بخشی از کدمون رو اصلاح می‌کردیم. کاری که می‌تونست از بروز حادثه دوم جلوگیری کنه و همزمان حادثه اول رو حل کنه. به هر حال تو آمریکا یکی هست که منتظر دیدن گربه‌های ایرانیه.حادثه پیش اومده بعد از بررسی چند راه حل از جمله پر کردن دوباره کش، تغییر آدرس لیست‌ها به جایی که هنوز فیلتر نیست (و پذیرفتن خطر آپدیت نبودن‌شون) و انتشار ناموفق یه نسخه تو کمتر از دو ساعت برطرف شد اما رنج‌های مکرر ادامه داشتن.هشدارها دیگه ارسال نمی‌شنما برای ارتباط درون‌سازمانی از زوهو استفاده می‌کنیم که چند وقتی هست بیشتر سرویس‌هاش روی بیشتر ارائه‌دهنده‌های اینترنت فیلتر شدن اما خوش‌شانس بودیم که Messaging API اش از زیر دستشون رد شده بود و می‌تونستیم ازش واسه ارسال پیام‌های خودکار استفاده کنیم. مثلا وقتی یکی از صف‌های پردازشی‌مون کند می‌شدن یا زمانی که صدور گواهی‌نامه رایگان SSL برای کاربرامون با مشکل مواجه می‌شد.این هشدارها بهمون کمک می‌کردن مسائل و مشکلات رو قبل از بزرگ شدن پیدا کنیم و نذاریم دامنه تاثیرگذاریش زیاد بشه و کاربرا اذیت بشن. حالا اما هیچ چیزی از زیر دستشون رد نشده و ما تو ارسال و در نتیجه دریافت این هشدارها با مشکل مواجهیم. فیلترینگ اینجا مستقیما ما رو وارد حادثه نکرده اما کیفیت کار و پاسخ‌دهی‌مون رو تا حد زیادی کم کرده. حالا تا پیاده کردن راه جایگزین این خطاها رو هم به شکل دستی مدیریت می‌کنیم.کاربرا زیاد شدن و ما فریز شدیمساخت دامنه‌ها تو روزهای‌ اخیر نسبت به ماه گذشته رشد قابل ملاحظه‌ای داشته (بین خطوط رو بخونین). رشدی که از نظر منابع خیلی واسش آماده نبودیم و فاجعه‌بار بودن وضعیت زیرساخت مانع از حرکت‌مون به سمت افزایش منابع می‌شد. تو این شرایط نمی‌تونستیم تعداد ورکرهای پردازش صف‌هامون رو افزایش بدیم و این باعث حادثه چهارم شد.تو این حادثه که خوشبختانه نمود بیرونی نداشت ما باز هم مجبور بودیم کارهای خودکار رو به مدت یکی دو روز به شکل دستی مدیریت کنیم و اجرای صف‌ها رو تا زمان کاهش پیک مصرف به تعویق بندازیم. بعد باید ریسکی که تو روزهای اول واسمون خیلی سنگین بود و هزینه زیادی داشت رو تو روزهای اخیر می‌پذیرفتیم. برای افزایش تعداد ورکرها نیاز به انتشار نسخه جدید داشتیم و این‌کار که تو شرایط عادی حدود ۵ پنج دقیقه طول می‌کشید با تاخیری نیم‌ساعته به انجام رسید.این بازی بی‌نهایتهما محصول‌مون رو برای بقا توسعه می‌دیم. شرایط غیرمنصفانه و تاسف‌بار پیش اومده واسمون هفته‌های پر حادثه‌ای رو به همراه داشته اما ابرها باید زنده بمونن تا گربه‌ها دیده بشن! Mehrdad Esmaeilpour Mehrdad Esmaeilpour Tue, 11 Oct 2022 11:10:15 +0330 https://virgool.io/@mehrdadep/%D9%85%D9%85%DB%8C%D8%B2%DB%8C-%D8%B1%D9%88%DB%8C-%D9%85%D8%AA%D9%86-%D8%BA%DB%8C%D8%B1%D8%B9%D8%A7%D9%82%D9%84%D8%A7%D9%86%D9%87-%D8%A7%D8%B6%D8%A7%D9%81%DB%8C-%D9%88-%D8%A7%D8%AD%D9%85%D9%82%D8%A7%D9%86%D9%87-xswt1y6rvhtq سال ۹۹ که مغز کاغذی بدون هیچ اصلاحیه‌ای مجوز گرفت و چاپ شد با خودم گفتم چه عجیب و خوب که برای نویسنده‌های بی‌نام و نشون ممیزی‌های بی‌دلیل ارسال نمیشه و مسیر ورودشون به دنیای نشر کتاب کاغذی ساده‌تر و کم‌دردسرتر از قبل‌ترهاست. من سال‌های پیش، قبل از این‌که گرفتن مجوز برای نشر الکترونیکی کتاب‌ها اجباری بشه چند کتابم رو به صورت الکترونیکی منتشر کرده بودم و از زیر و بم وجود و نحوه ممیزی‌ها اطلاع زیادی نداشتم. تو سال ۱۴۰۰ تصمیم گرفتم یک کتاب دیگه‌ام رو با مجوز به چاپ برسونم که ماجرای ممیزی‌ها شروع شد.یک قانون کلی با اجرایی سلیقه‌اینسل ما با آموزه‌ها و شیوه فکری نظام حاکم‌مون آشناست و بعضی خودسانسوری‌ها از کودکی تو وجودمون نهادینه شده. نوشته‌های من که با هدف نشر تو همین چارچوب نوشته شدن ناخودآگاه شامل این خودسانسوری‌ها هستن و خوب می‌دونم که کجا باید مساله‌ای رو به خیال و تفکر مخاطبم واگذار کنم؛ اما جدا از این مسائل یک قانون کلی برای نوشتن وجود داره و اون «اهداف، سیاست­ها و ضوابط نشر کتاب» هست. به اشتباه یا درست بودن وجود همچین قانونی کاری ندارم (از دید من وجود قانون برای اون‌چه نتیجه تفکر یک نفره اساسا اشتباهه!). این قانون ما رو از نوشتن درباره بسیاری از مسائل منع می‌کنه و از طرفی وادارمون می‌کنه اگه جور دیگه‌ای فکر می‌کنیم بهتره چیزی ننویسیم.مساله اما باز اینجا نیست؛ مساله کلی بودن قانون و امکان اجرای سلیقه‌ایه اونه. همونطور که تو سال ۹۹ یک کتاب من با پی‌رنگ جدال با افسردگی، بدون اصلاحیه مجوز می‌گیره و یک سال و خرده‌ای بعد کتاب دیگه‌ام با پی‌رنگی مشابه، با واژه‌ها و توصیف‌هایی به مراتب تلطیف شده‌تر از نظر لحن، دچار ممیزی شدید میشه. (از اینجا به وزارت محترم فرهنگ و ارشاد اسلامی لقب وزارت ممیزی می‌دم!)ابلاغیه‌های دریافت شده از وزارت ممیزی ساده اما جان‌کاه هستن. با چند جمله شروع می‌شن و با یک جدول شامل حذفیات ادامه پیدا می‌کنن. «... نظر به این‌که بعضی از مطالب درج شده در کتاب با قوانین و ضوابط نشر مطابقت ندارد موارد زیر برای اصلاح و اقدام لازم ابلاغ می‌شود ...» بعد از این جملات یک جدول وجود داره که تنها خطوط کتاب رو با ذکر صفحه مشخص می‌کنه و «نحوه رفع» رو «حذف» می‌دونه. جالب این‌جاست قوانین و ضوابط نشر به هیچ‌کدوم از ابلاغیه‌ها پیوست نمی‌شن و وزارت ممیزی پاش رو یک قدم جلو‌تر می‌ذاره و علت ممیزی رو هم توضیح نمی‌ده که بشه اصلاحش کرد.با بررسی خطوط و حذفیات میشه فهمید کارکنان بخش مربوطه وزارت ممیزی روی کلیدواژه‌ها حساس هستن. مثلا بند ۴ ماده ج که میگه «ترویج ناامیدی، سرخوردگی، پوچی و بیهودگی و نگرش­های منفی در جامعه و افزایش بی‌­اعتمادی عمومی» ممنوع هستن؛ به کلیدواژه‌های «مرگ»، «مردن»، «سراب» و ... تقلیل پیدا می‌کنن. ممیز بعد از این دیگه کاری به محتوای متن، جمله‌های پیشین، هدف کتاب، خروجی، پایان‌بندی و ... نداره. به این ترتیب هرجایی که کلیدواژه‌های مورد نظر استفاده شدن با توجه به حوصله ممیز باید حذف بشن: اگه اوایل کتاب هست همون جمله، هر چه جلوتر بریم از یک جمله به یک پاراگراف و بعد چند پاراگراف و در نهایت به چند صفحه می‌رسیم. به این شکل، کتاب ارسالی من در نهایت با حذف دو و نیم فصل آخر روبه‌رو میشه.عاقلانه است؟جواب کوتاه و مختصر من اینه: «البته که نه». اگه دهه شصت یا هفتاد بود می‌شد با چشم‌پوشی‌های زیاد گفت که بله این قانون و رعایتش به این شکل ابتر، باعث می‌شه شکل خاصی از محتوا هیچ‌وقت تولید نشه اما حالا این روش نه تنها جواب نمی‌ده و بلکه هدفی که واسش تصویب شده دیگه قابل دست‌یابی نیست. حالا هر کسی می‌تونه تو هر سنی به هر محتوایی که بخواد دسترسی داشته باشه. در کنار دسترسی آزاد به مطالب مختلف امکان انتشار مطالب ممیزی شده به شکل‌های ساده و بی‌دردسر وجود داره و ممیزی فقط به بی‌اعتبار شدن وزارت ممیزی منجر میشه. حتی میشه با نشرهای فارسی خارج از کشور به شکل ناشناس کار کرد و بدون اعمال محدودیت‌های بیهوده به کار ادامه داد. حالا کاملا مشخصه که راه جهت‌دهی به فرهنگ، محدود کردن خروجی فکر آدم‌ها نیست.به جاست؟فرایند گرفتن مجوز بعد از این مراحل شروع میشه: اول نویسنده مدت زمانی رو صرف نوشتن می‌کنه. هزینه زمانی، مالی و فکریش صرف تبدیل تخیلات و افکارش به واژه‌ها می‌شن. بعد با یک ناشر به توافق می‌رسه. ناشر کتاب رو از نظر کیفی و همسو بودن با ارزش‌هاش بررسی می‌کنه. اینجا هم ناشر داره هزینه مالی و زمانی خودش رو متحمل میشه. بعد از صفحه‌آرایی و گرفتن شابک کتاب برای مجوز به وزارت ممیزی ارسال میشه و اینجاست که یک (یا چند) نفر می‌تونه با برداشت سلیقه‌ای از یک قانون کلی (و البته اضافی) تمام این هزینه‌ها رو پوچ کنه و با ممیزی‌هاش ادامه روند چاپ کتاب رو متوقف کنه.وزارت ممیزی به جای نقش منطقیش تو فرهنگ و هنر که باید تسهیل‌گر و بهبود دهنده باشه در نقش متوقف‌گر و مانع‌ساز فرو می‌ره و امکان تولید درآمدهایی که می‌تونه با انتشار کتاب به وجود بیاد رو از بین می‌بره. چاپ کتاب به چاپخونه‌ها رونق می‌ده، شرکت‌های توزیع کتاب، کتاب‌فروشی‌ها و وبسایت‌های فروش از چاپ کتاب‌های جدید سود می‌برن و در نهایت این امکان وجود داره که یک نفر با خوندن کتاب حس بهتری پیدا کنه. تمام این نتایج به دلیل شیوه کار وزارت ممیزی غیرممکن میشن. همه این‌ها به چه دلیل؟ مشخص نیست!احمقانه است؟نمونه‌های بزرگ ممیزی روی کارهای هنری رو تو دهه‌های قبل به یاد بیاریم. کدوم‌شون دیده نشدن، خونده نشدن و درباره‌شون صحبت نشد؟ یه بررسی شهودی ساده نشون می‌ده که ممیزی و توقیف نه تنها بازدارنده نبوده بلکه به یه شیوه تبلیغ تبدیل شده. به شکلی که حالا عده‌ای دارن به عمد ازش برای تبلیغ آثارشون استفاده می‌کنن و خروجی‌های بریده و منقطع که ابتدا و انتهاشون مشخص نیست به عنوان نتیجه کار وزارت ممیزی داره دست به دست می‌چرخه.اجرای این شیوه (حذف و ممنوعیت) نه تنها کمکی به بهتر شدن فرهنگ نکرده بلکه افراد رو تو سنین مختلف به سمت محتوای نامناسب برای سن‌شون سوق داده. بند ۵ مورد الف قانون «بیان جزئیات مراودات جنسی ...» نیازی به حذف و ممنوعیت نداره فقط کافیه به سمت مخاطب مورد نظرش هدایت بشه. به نظر میاد وزارت ممیزی بهتره نقشش رو از «بازدارنده» و «ممانعت کننده» به «تنظیم‌گر» و «هدایت‌کننده» تغییر بده و محتوای کتاب رو بدون اعمال نظر برای مخاطبین مورد نظر تعیین وضعیت کنه. تعیین گروه سنی و ... راه درست اعمال نظر وزارت ممیزی روی متن‌هاست نه تغییر و حذف اون‌ها. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Fri, 15 Apr 2022 20:07:28 +0430 https://virgool.io/@mehrdadep/%D9%82%D8%B7%D8%A8-%D9%86%D9%85%D8%A7%DB%8C-%D8%A7%D8%AE%D9%84%D8%A7%D9%82%DB%8C-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-j5t0yhmxz8v0 ترجمه‌ نادقیقِ بخشی از ویرایش دوم کتاب برنامه‌نویس عملگرابهای این قدرت نامتعارف، هوشیاریه. اعمال ما مستقیما روی مردم اثر می‌ذارن. دیگه خیلی خبری از برنامه‌های تفریحی روی پردازنده ۸ بیتی تو گاراژ، یه برنامه ایزوله برای پردازش داده‌های بیزنس تو یه دیتاسنتر خصوصی یا حتی یه برنامه روی دسکتاپ نیست. برنامه‌های ما تار و پود زندگی روزانه مدرن مردم شدن.حالا وظیفه ماست با هر قطعه کدی که تحویل می‌دیم، از خودمون بپرسیم:آیا از کاربر نرم‌افزارم محافظت کردم؟آیا خودم از همین نرم‌افزار استفاده می‌کنم؟قبل از همه‌چیز از خودتون بپرسید که «آیا بیشترین تلاشم رو برای محافظت از کاربرا تو این قطعه کد انجام دادم؟»، «آیا دستور‌العملی برای اعمال مداوم پچ‌های امنیتی برای دستگاه مانیتور کودک ساده خودم دارم؟»، «آیا مطمئنم هر چه قدر هم ترموستات به شکل اتوماتیک عمل می‌کنه در نهایت کاربر هم می‌تونه اون رو به شکل دستی کنترل کنه؟»، «آیا فقط داده‌هایی که نیاز دارم رو ذخیره می‌کنم و همه اطلاعات شخصی رو رمزگذاری می‌کنم؟»هیچ‌کس کامل نیست؛ همه یکی یا بعضی از این مدل پرسش‌ها رو فراموش می‌کنن. صادقانه نمی‌تونین بگین که همه عواقب کارتون رو لیست کردین و مطمئن شدین کاربر جاش امنه اما در نهایت مسئولیت کارتون رو نپذیرین.قبل از همه چیز، به کسی صدمه نزنینیک قانون طلایی برای قضاوت وجود داره: آیا خودم از استفاده این نرم‌افزار به عنوان کاربر راضی خواهم بود؟ راضی خواهم بود که اطلاعات شخصیم به اشتراک گذاشته بشه؟ آیا می‌خوام که حرکاتم به خرده‌فروشی‌ها واگذار بشه؟ آیا از اینکه یه نرم‌افزار ناشناس خودروم رو کنترل کنه خوشحال خواهم شد؟ آیا از این کار احساس راحتی می‌کنم؟ بعضی‌ها با ایده‌های مبتکرانه مرزهای رفتار اخلاقی رو دور می‌زنن اما اگه داخل یک پروژه حضور دارین، به اندازه سرمایه‌گذارها مسئولین. مهم هم نیست تا چه اندازه با منطق و توجیه بتونین لایه‌های مختلف رو از هم تفکیک کنین. یه قانون رو در نظر داشته باشین:به کثافت‌ها توانایی نبخشین Mehrdad Esmaeilpour Mehrdad Esmaeilpour Mon, 16 Aug 2021 20:38:52 +0430 https://virgool.io/@mehrdadep/%D8%A7%DB%8C-%DA%A9%D8%A7%D8%B4-%D8%A2%D8%AF%D9%85%DB%8C-%D9%88%D8%B7%D9%86%D8%B4-%D8%B1%D8%A7-%D9%87%DB%8C%DA%86%DB%8C-srdm5i7dhchr تصویر از doc-research.orgبه عنوان یه متخصص یا حتی یه شهروند دنبال تخصص سوالی که هر چند وقت یه بار به ذهن‌مون می‌رسه اینه که باید جمع کنیم بریم یا بمونیم و زندگی کنیم. مولفه‌هایی زیادی توی این تصمیم نقش دارن. بهتره قبل از تصمیم‌گیری مطلوبیت‌های مختلف شخصی خودمون رو لیست کنیم و بعد از سبک سنگین کردن، اقدام کنیم. فاکتورهای احساسی، ملی، اقتصادی، سیاسی و ... ضریب اهمیت متفاوتی واسه هر کس دارن و صادر کردن حکم نهایی رفتن یا موندن، به شکل کلی، ساده‌لوحانه به نظر می‌رسه. حتی خود این فاکتورها برای هر شخص هم می‌تونه روز به روز یا هفته به هفته تغییر کنه و کفه ترازو رو سمت رفتن یا موندن سنگین‌تر کنه.اینجا قصد دارم با بررسی داده‌ها و مشاهدات، بعضی از باورهای پیرامون مهاجرت و موندن تو ایران رو بازخوانی کنم. آخرش هم نتیجه‌ای نمی‌گیرم. نسخه‌پیچی تو این مساله پیچیده کار من نیست.رفتن مؤلفه موفقیت نیست/استموفقیت مفهومی شناوره و تعریفش تو ذهن هر شخص یا گروه، متفاوته. برای یکی پیدا کردن شغلی با درآمد بالا موفقیت محسوب میشه. برای کسی خوشحال کردن کسی که دوستش داره، یکی ادامه تحصیل تو یه دانشگاه معتبر، یکی آزادی بیان و ... اما این وسط افرادی هستن که صرف زندگی کردن تو یه منطقه جغرافیایی رو شکست یا پیروزی می‌دونن. کاری با درست یا غلط بودن دیدگاه‌شون نداریم اما درک این‌که این مؤلفه‌ها برای هر کس ضریب و ارزش متفاوتی داره و بعضی می‌تونن و می‌خوان بدون مهاجرت هم احساس موفقیت کنن، خیلی پیچیده نیست.اگه مؤلفه‌ای مثل تحصیل تو دانشگاه‌های برتر دنیا یا کار تو ابرشرکت‌ها واسه‌تون موفقیت محسوب میشه، مهاجرت پلی واسه رسیدن بهش محسوب میشه و به تنهایی سهم خاصی از موفقیت رو به دوش نمی‌کشه.هر که رفته نخبه نبوده/بودهمقاله‌ای که سال ۲۰۰۵ درباره مهاجران ایرانی در کانادا منتشر شده نشون می‌ده که حدود ۴۲ درصد مهاجران ایرانی بدون تخصص دانشگاهی خاصی (پایان دبیرستان یا کمتر از اون) به زندگی‌شون در کانادا ادامه دادن. همچنین حدود ۳۵ درصدشون تو یک سال مشخص بیکار بودن و حدود ۳۵ درصد دیگه کار پاره وقت داشتن، یعنی تقریبا ۷۰ درصد مهاجران ایرانی به کانادا تو یک سال مشخص حتی کار ثابت نداشتن. البته این داده‌ها در مقایسه با کانادایی‌های غیرمهاجر معنای بیشتری پیدا می‌کنه که به نظر می‌رسه سهم ایرانی‌های مهاجر بیشتر از بقیه بوده.صرف نظر از اینکه تعریف فرد نخبه چی هست به نظر میاد مفهوم این واژه در کنار خیلی از واژه‌های دیگه تو کشور ما دچار تحول شده و از کاربرد درستش فاصله گرفته. مهاجرت از کشور برای کار تو یه شرکت یا تحصیل تو یک دانشگاه به معنای نخبگی نیست و صرفا به معنای تغییر شرایط برای رسیدن احساس موفقیته. در واقع رابطه علت و معلولی ساده‌ای اینجا وجود داره که به دلایل نامعلوم، علت و معلولش مخدوش شده. نخبه‌ها هم مهاجرت می‌کنن اما مهاجرت کردن هرگز مساوی نخبه بودن نیست. ساده بودن/نبودن وفق با فرهنگ جدیدمقاله‌ای که سال ۲۰۱۷ درباره وضعیت اجتماعی مهاجران ایرانی به اروپای غربی منتشر شده، نشون می‌ده بحران هویت و دشواری هم‌فرهنگ شدن با کشور مقصد، سال‌ها گریبان‌گیر مهاجران باقی مونده و حتی تا ۳۰ سال بعد از مهاجرت هم تغییر چندانی نکرده. دغدغه‌هایی مثل «اکثرا من رو به عنوان مهاجر عرب می‌شناسن»، «ایرانی‌های مهاجر دیگه من رو جزیی از خودشون نمی‌دونن»، «احساس می‌کنم ساکنین اصلی به ارزش‌های فرهنگی من احترام نمی‌ذارن» و ... تا سال‌ها با مهاجران باقی می‌مونن.این مقاله‌ها و مقاله‌های مشابه‌اش نکات جالب دیگه‌ای رو درباره مهاجرت در اختیارمون میذارن که مطالعه‌اش رو به خودتون واگذار می‌کنم.مونده‌ها بیانیه سیاسی دادن/ندادنخیلی از ما فکر می‌کنیم مهاجرت کردن یا نکردن یه جور بیانیه سیاسی دادنه. این نگاه صفر و یکی ما رو تو دام یه آفت بزرگ میندازه. برچسب زدن به آدما و نیت‌هاشون. این روزا نمیشه کاری کرد که بلافاصله روت برچسب خاصی نخوره. رشد سوشال مدیا و نرمال شدن سایبربولی هم تو این داستان نقش پررنگی داره.با همین دیدگاه «یا با ما، یا بر ما» دو قطبی عجیبی بین کسایی که مهاجرت کردن و کسایی که موندن شکل گرفته. داخل همین دو قطبی باز میشه گروه‌های دیگه‌ای رو پیدا کرد که در حال برچسب زدن به همدیگه (صرفا به خاطر تصمیم‌شون برای انتخاب مسیر به سمت احساس موفقیت) هستن.قبل از این‌که تو این دام بیفتیم در نظر بگیریم که سیاست تنها یک عامل از مجموعه عواملی هست که منجر به تصمیم برای مهاجرت میشه. ربط دادن همه چیز و همه کس به این یه عامل ساده‌سازی بی‌مورد مساله‌ای بسیار پیچیده است. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Mon, 26 Jul 2021 12:41:54 +0430 https://virgool.io/@mehrdadep/%D9%87%D9%86%D8%B1-%D8%A8%D8%AE%D8%B4%DB%8C-%D8%A7%D8%B2-%D8%B1%D8%A7%D9%87-%D8%AD%D9%84-%D8%A8%D9%88%D8%AF%D9%86-wl8dj0rdrfek تصویر از olab.comاگر بخشی از راه‌حل نیستید احتمالا بخشی از مشکل هستیدچند روز قبل از انتخابات ماسک به صورت و دست در جیب رفتم کمی خرده ریز واسه خونه بخرم. تلویزیون مثل همه روزهای قبل از انتخابات پر از آهنگ‌های حماسی و در حال پخش رقص محلی کردی بود. فروشنده نگاهی به تلویزیون انداخت و پوزخندی زد و گفت «پدر سوخته‌های دزد». باهاش موافق بودم اما چیزی نگفتم. وقت حساب رسید و متوجه شدم پنج شش دونه از لیموها از نایلون کشیده شده، کم شدن. درخواست کردم که لیموها دوباره وزن بشن و ماجرا با «حتما آوردنی افتادن» ختم شد. شاید منم می‌تونستم پوزخند بزنم و جمله اول فروشنده رو تکرار کنم. شاید یکی مثل فروشنده (یا من) الان رییس یه جایی شده و داره تعداد لیموها رو از نایلون کسی کم می‌کنه.بی‌کفایتی رو هر روز چپ و راست می‌بینیم. تو کار خودمون، درون خودمون یا تو سوپرمارکت سر خیابون. بیشترمون معتقدیم که همه غیر از خودمون تو جایگاه درستی نیستن و با عواملی غیر از کفایت به نقطه فعلی‌شون رسیدن. بیشترمون اسیر حباب «ایده و خلاقیت فقط واسه منه و بقیه ادای من رو در میارن» هستیم. بعضی جملات رو از اطرافیان‌مون تا وزیرهامون مکرر و بدون توضیح اضافه می‌شنویم. از قطع شدن برق تا توان کم اپراتورهای اینترنت. از شکایت کارمندا و کارفرماها از هم تا دزدی‌ها و کلاهبرداری‌های کوچیک و بزرگ. من این‌جا بعضی از اون‌هایی که زیاد شنیدم رو مرور می‌کنم.این اشتباه تقصیر اونهوقتی برق قطع می‌شه، اینترنت هم می‌ره. وزیر ارتباطات، وزیر نیرو رو مقصر می‌دونه، وزیر نیرو مردم و ما هم جفت وزیر‌ها رو. شاید اگه ده سال پیش و زمان رییس جمهور اعظم قیمت‌ها واقعا واقعی می‌شد و یارانه‌ها واقعا هدفمند، یکی از ریشه‌های مشکل فعلی خشک می‌شد اما نشد. حالا ما یک مشکل بزرگ داریم که همه با تاثیرگذاری‌های متفاوت توش سهیم هستیم. بی‌کفایتی از مایی که درست مصرف نمی‌کنیم شروع می‌شه و تا شرکت برق که درست تولید و توزیع نمی‌کنه و نمی‌فروشه ادامه پیدا می‌کنه. تو این دور باطل همه انگشت‌هامون سمت شخص و گروه دیگه‌ای درازه و حاضر نیستیم سهم خودمون رو تو مشکل بپذیریم. اگه برای عوض کردن نقش‌مون به بخشی از راه‌حل بودن تلاش نکنیم همیشه بخشی از علت مشکل باقی می‌مونیم. این که کپی فلان کارهبه تعداد آدم‌های روی زمین ایده برای خلق محصول وجود نداره. پس با یه محاسبه ساده میشه فهمید وجود محصول‌هایی که چه به صورت عمدی از روی یکی دیگه کپی شده باشن و چه اتفاقی نتیجه مشابه محصول دیگه بدن، دور از ذهن نیست. پایین آوردن ارزش کار یک تیم یا فرد صرفا به خاطر این‌که از کار کسی یا تیمی کپی کرده نه تنها سازنده نیست بلکه ممکنه تولید کننده‌ها رو به جایی برسونه که از هر حرکت خودشون بترسن و کلا کاری نکنن. اگه قرار بود کسی از کسی کپی نکنه، ابزارهایی مثل تلگرام، جیمیل و ... اصلا وجود نداشتن. چون ایده‌هاشون قبلا توسط تیم دیگه‌ای پیاده شده بودن. اگه قرار بود کسی از کسی کپی نکنه سیستم‌عامل‌ها، گوشی‌ها و لپ‌تاپ‌ها همه یکسان بودن و شاید آخرش ما هم شبیه هم می‌شدیم.مهم نیست که کارمون رو با کپی برداری از ایده دیگری شروع کنیم (البته اگه اون ایده ثبت شده است و انحصاری، مشکلات قانونیش پای خودتون) مهم اینه در نهایت اون ایده و محصول رو به شکلی مال خودمون کنیم و بهش هویت مستقل ببخشیم و با هدف آرمانی خودمون هم مسیرش کنیم.این رو که من هم می‌تونم انجام بدماگه به اندازه کافی وقت و هزینه و انرژی بذاریم، همه می‌تونیم هر کاری که بخوایم رو انجام بدیم. این دروغیه که کم و بیش خیلی‌هامون بهش باور داریم. چون جایی از ذهن‌مون رو قلقلک می‌ده که امیدبخشه، اما در واقع این‌طور نیست. داستان شکست‌های بزرگِ شرکت‌های بزرگ، با این طرز فکر کم نیستن. بلک‌بری که فکر می‌کرد می‌تونه همون کاری که اپل کرد رو بکنه و شکست خورد. کُداک که بعد از قبول نکردن پیشرفت دنیای عکاسی فکر می‌کرد می‌تونه همون کار فوجی رو انجام بده و شکست خورد.مسیر زندگی و کاری، در نهایت ما رو به جایی می‌رسونه که خونه پر، تو یک یا دو زمینه واقعا متخصص هستیم و از مابقی ماجراها فقط کم و بیش سر در میاریم. این‌که فکر کنیم می‌تونیم بدون مشکلات مشابه همه محصولات فعلی رو با کیفیت بهتر به وجود بیاریم شاید علتش دید کم و زندگی تو حباب خودمون باشه. We put our minds to it all, But disappointment crashed the ballمن هم اگه رانت داشتم همین‌جا بودم (رانت، این مولفه نکوهیده)ما نمی‌توانیم بازی را انتخاب کنیم. نمی‌توانیم قواعد بازی را انتخاب کنیم. فقط می‌توانیم انتخاب کنیم که چطور بازی کنیمبیشتر کسایی که باهاشون هم صحبت شدم تو یه لایه‌ای از حرف‌هاشون گلایه‌شون از وجود رانت به اینکه چرا رانت به اون‌ها نرسیده تبدیل می‌شه. «رانت» کلیدواژه سمی این‌روزهای صنعت و بازار کار ماست. همه دنبالش هستن و همزمان از بدی‌هاش می‌گن. همه ازش متنفرن و همزمان تو این بازی بزرگ برای سر پا موندن بهش نیاز دارن. چه بخوایم چه نخوایم رانت به یکی از مولفه‌های مهم بقای شرکت‌ها تبدیل شده. هدف من نکوهش وجود رانت نیست چرا که همه می دونیم چقدر نکوهیده است. هدف من ارائه راهکار واسه حذف رانت نیست چرا که علم و سوادش رو ندارم. فقط می‌خوام اشاره کنم یه کارآفرین یا یه شرکت نمی‌تونه قاعده فعلی بازی رو تو کوتاه مدت و به تنهایی به هم بزنه. پس تو این مسابقه بقا و برای جلوگیری از سرنوشت استارپ‌های قارچی، خواه ناخواه باید به این «مولفه نکوهیده» تن بده.یعنی همین یه کار هم نمی‌تونن درست انجام بدنکسب و کارهای بزرگ فعلی بازار کار ما کم، نقص و ایراد ندارن و معمولا پست‌های اعتراضی عریض و طویل گریبان‌شون رو می‌گیره. اگه به عنوان مصرف کننده این گلایه‌ها رو مطرح کردین که حق‌تون بوده و توصیه می‌کنم باز هم به همین کار ادامه بدین اما اگه خواستین کار بقیه رو بهشون یاد بدین و بهشون بگین همین یه کار هم نمی‌تونین درست انجام بدین، دست نگه دارین.تخصص ما منحصر به فرد نیست. بیشترمون از دانشگاه‌های مختلف فارغ‌التحصیل شدیم که کم و بیش کیفیت مشابه داشتن. دوره‌های مشابه دیدیم. کتاب‌های مشابه خوندیم. اگه خیلی بخوایم واقعی به وضعیت‌مون نگاه کنیم خیلی‌هامون به راحتی قابل جایگزین شدن هستیم. پس هر وقت حس کردین تنها کسی هستین که راه حل یه مشکل دستشه یه نفس عمیق بکشین و مطمئن باشین کسی توی همون کسب‌و‌کار تقریبا به اندازه شما بلده و می‌فهمه.در نهایت اگه راه‌کاری دارین که فکر می‌کنین به ذهن کسی نمی‌رسه با ادبیات مثبت انتقالش بدین یا حتی بفروشینش. فراموش نکنیم بقای یه کسب و کار منجر به بقای خیلی از کسب و کارهای دیگه میشه. رشد و بزرگ شدن یه شرکت رقیب‌هاش رو با کیفیت‌تر می‌کنه. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Thu, 08 Jul 2021 18:09:23 +0430 https://virgool.io/@mehrdadep/%D8%A2%D9%85%D8%A7%D8%B1-%D8%A8%D8%A7%D8%B2%D8%AF%DB%8C%D8%AF-%D9%BE%D8%B3%D8%AA-%D9%87%D8%A7%DB%8C-%D9%85%D9%86-%D8%AF%D8%B1-%D8%B3%D8%A7%D9%84-%DB%B9%DB%B9-kn5tahzqgije در طول تاریخ از اعداد استفاده کردیم تا اغلب داد و ستد کنیم و آن‌چیزی که شمردنی است را بشماریم. برای هر عدد واحد درست کردیم تا عددهای زندگی قاطی نشوند و از اعداد، شفاف‌تر استفاده کنیم؛ مثلا وقتی می‌گوییم ده هزار تومان به پول اشاره داریم و وقتی می‌گوییم ده هزار بلیط به بلیط!روز به روز که در زندگی جلو‌تر رفتیم عددها فرقی نکردند ولی این واحدها بودند که زیاد شدند. واحد کریپتو، واحد اصله درخت، واحد فاصله و …«واحد» یک توافق عمومی است برای شمردن؛ تا همانطور که گفتم شمردن‌ها قاطی نشود. مشاهده افراد دارای ثروت (اجتماعی یا مالی) به من ثابت کرده اینکه چه چیزی را بشماریم از اینکه چطور بشماریم مهم‌تر است. هرکس با واحد خاصی مسائل زندگی را می‌شمارد. اینطور به نظرم آمده که مشخص کردن واحد یعنی مشخص کردن اینکه من در زندگی برای چه چیزهایی ارزش قائلم و می‌خواهم چه چیزهایی را در زندگی بشمارم. https://cdn.virgool.io/annual-report/1399/asvrefhpatmz-bx4xu.mp4 اعدادی که بدون واحد ثبت کردمبه ویدیویی که ویرگول برایم ساخته که نگاه می‌کنم میبینم که در سال ۹۹، من در مجموع ۱۰,۵۸۹ کلمه در ویرگول نوشتم و منتشر کردم و مخاطبین، پست‌های من را ۱۲۸ مرتبه پسندیدند و ۱۲ بار هم نظر خود را روی پست‌های من به اشتراک گذاشتند. در سال ۹۹، ۳۷ نفر در ویرگول من را دنبال کردند تا پست‌های بعدیم را بخوانند. این اعداد نشان میدهند من کاری کرده‌ام. هرکدام به واحدی وصل هستند. از خودم می‌پرسم من کدام واحد را شمارش کرده‌ام؟ کدامیک از واحدهای بالا از همه برای من مهم‌تر است؟ ادامه ویدیو را می‌بینم.آمار از اثر بیرونی می‌گویندطبق آمار پست‌های من ۱,۳۶۵ بار خوانده شدند و ۱۴۰,۰۳۸ ثانیه صرف مطالعه آنها شده است، که با توجه به جمعیتی که در ایران به اینترنت دسترسی دارند، ویرگول به من می‌گوید که توانستم ۰/۰۰۱۹۱۹۹۰۷ ثانیه، سرانه مطالعه دیجیتال کشور را بالا ببرم.از طرف دیگر ویرگول به من می‌گوید که اگر قرار بود پست‌هایم را چاپ و به دست تک تک خوانندگان برسانم باید ۷,۱۸۰ کاغذ مصرف می‌کردم.آن عددهای کوچک ابتدای ویدیو حالا تبدیل شده‌اند به عددهای بزرگ به اینکه من جلوی مصرف این تعداد کاغذ را گرفتم یا به اینکه من ۰/۰۰۱۹۱۹۹۰۷ ثانیه، سرانه مطالعه دیجیتال کشور را جابه جا کرده‌ام. واحد این عددها برای من ملموس‌تر است.واحد نوشتن چیست؟همه عددهای بالا و همینطور اثر بیرونی که روی خوانندگان و همینطور در مقیاس بزرگتر طبیعت و جامعه اطرافم گذاشتم اعدادی هستند که من دوستشان دارم و به آنها افتخار می‌کنم. اگر چنین ویدیویی دست شما نیز رسید به شما بابت تک تک اعداد تبریک می‌گویم.اثر هر نوشته تا حدودی معلوم است، اگر بنویسید جلوی قطع درخت را می‌گیرید، به سرانه مطالعه کشور اضافه می‌کنید و خوانندگانی جذب می‌کنید که شما را از طریق نوشته‌هایتان می‌شناسند و …به نظرم می‌رسد که نوشته‌های من و شما واحد ندارند ولی اثر بیرونی دارند. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Mon, 22 Mar 2021 18:03:13 +0430 https://virgool.io/@mehrdadep/%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4-%D8%A8%D8%A7%DA%AF-%D8%A2%D8%B3%D8%A7%D9%86-%D8%AA%D8%B1-%D9%88-%D8%AA%D9%85%DB%8C%D8%B2%D8%AA%D8%B1-k5mnwmwoj58j گزارش باگپیدا کردن باگ تو نرم افزار خیلی مهمه اما مهم‌تر از اون سندی هست که بشه از اون برای رفع باگ استفاده کرد. ایجاد ارتباط بین زبان پشتیبان‌های نرم‌افزار و توسعه‌دهندگان معمولا با تجربه‌های ناموفق همراهه. نتیجه؟ باگ‌های مشابهی که مدام به شکل‌های متفاوت گزارش می‌شن و هیچ‌کس تمایلی برای رفع‌شون نداره و اگه تمایل هم داشته باشه نمی‌تونه کاری واسش انجام بده. در نهایت یه نرم‌افزار باقی می‌مونه و کلی پنجره شکسته که همه به وجودشون عادت می‌کنن اما باید راه بهتری وجود داشته باشه. پیدا کردن زبان مشترک نباید اون‌قدرها هم سخت باشه.گزارش درست باگ به توسعه‌دهنده کمک می‌کنه نقطه شروعی برای پیدا کردن ریشه مشکل داشته باشه و توی دریایی از احتمالات غرق نشه. حالا سوال اینجاست آیا گزارش‌های طولانی با جزییات زیاد موثرترن یا گزارش‌های کوتاه با نکات کلیدی؟ برای گزارش‌نویسی اصل معروف KISS (Keep it simple, stupid) رو بخاطر داشته باشید. یادتون باشه تو گزارش باگ فقط یک هدف وجود داره و اونم اینه که شما یه باگ پیدا کردید و حالا باید اون رو تو یه بسته‌بندی قابل قبول ارائه بدید. این بسته بندی چه ویژگی‌هایی داره؟ فکر کنید گزارش باگ مثل یک توییت‌ه. کوتاه، کامل و هدفمند باشیدگزارش باگ نباید همزمان به بیشتر یه مشکل اختصاص پیدا کنه. اگه بیشتر از یه مشکل وجود داره باید به ازای هر کدوم گزارش جداگانه‌ای ارائه بشه.ویژگی‌های گزارش باگعنوانعنوان باگ باید توضیح مختصری درباره محتوای باگ بده. به عنوان یه نکته کلیدی بهتره عنوان رو بعد از تکمیل گزارش بازبینی و احتمالا تغییرش بدید.محیط نرم‌افزارمحیط هر نرم‌افزار می‌تونه بسته به جنس نرم‌افزار متنوع باشه. در مورد محیط تا جایی که می‌تونید جزییات رو بگین. بعضی از ویژگی‌های محیط که به صورت عمومی می‌تونن اطلاعات خوبی در اختیار توسعه دهنده بذارن اینا هستن. این ویژگی‌ها می‌تونن بیشتر یا کمتر از این‌ها هم باشن.دستگاه: شامل سخت افزار و مدلسیستم‌عامل: نوع و ورژن سیستم‌عاملورژن نرم‌افزار: اگه نسخه‌های متفاوتی از نرم‌افزار وجود داره لازمه که ببینید آیا باگ تو ورژن‌های جدیدتر رفع شده یا نه. نرخ وقوع مجدد: احتمال دوباره اتفاق افتادن باگ چقدره؟ نسبت اتفاق افتادن باگ به تعداد تست‌ها رو به دست بیارین.گام‌های بازتولیدچه گام‌هایی برای بازتولید باگ تو نرم‌افزار مورد نیازه. این بخش از گزارش اهمیت زیادی داره و خطای محیط یا کاربر رو از باگ تفکیک می‌کنه. گام‌های بازتولید باید هدفمند در خصوص باگ باشن. مثلا اگه باگی بعد از لاگین کردن کاربر و تو بخش گزارش‌گیری اتفاق میفته نیازی نیست یکی از گام‌ها لاگین کردن به نرم‌افزار باشه. گام‌های بازتولید رو بعد از ثبت دوباره خودتون مرحله به مرحله اجرا کنید و از درست‌ بودن‌شون مطمئن بشید.نتیجه مورد انتظاروقتی گام‌های بازتولید اجرا می‌شن انتظار داریم نرم‌افزار چه عملکردی داشته باشه؟ نتیجه به دست آمدهنتیجه گام‌های بازتولید چی هست؟ آیا نرم‌افزار متوقف شده؟ آیا اتفاقی نیفتاده یا چیزی خلاف اون‌چه انتظار داشتیم به وجود اومده؟ تو این مرحله باید از کلی‌گویی پرهیز کنیم. هرچه دقیق‌تر و هدفمندتر بهتر.مدرک تصویریآیا امکان تهیه اسکرین‌شات، متن خطا، لاگ و یا هر مدرک دیگه‌ای که بشه اون رو به گزارش پیوست کرد وجود داره؟ اگه آره حتما از مدارک تصویری استفاده کنید.اولویتاولویتی که برای رفع این باگ وجود داره چقدره؟ باگ‌هایی که باعث اختلال تو عملکرد کلی سیستم میشن باید به سرعت رفع بشن و اولویت بالایی دارن. باگ‌هایی که باعث بد شدن تجربه‌کاربری می‌شن اما بدون رفع اون‌ها عملکرد کلی سیستم زیرسوال نمیره اولویت متوسط دارن و بقیه باگ‌ها اولویتشون پایین هست. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Sun, 24 Jan 2021 16:37:03 +0330 https://virgool.io/@mehrdadep/%D8%A7%D9%84%DA%AF%D9%88%D9%87%D8%A7%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%A7%D9%81%D8%B3%D8%A7%D9%86%D9%87-%DB%8C%D8%A7-%D9%88%D8%A7%D9%82%D8%B9%DB%8C%D8%AA-sym6jscames9 Design patternsچی شد؟چند وقت پیش تو توییتر، توییتی دیدم که می‌گفت الگوهای طراحی فقط به درد مصاحبه‌ها می‌خورن و کاربرد دیگه‌ای ندارن. حالا تو لینکداین هم می‌بینم که می‌گن الگوهای طراحی فقط کد رو پیچیده می‌کنن و درکش رو دشوار اما خب واقعیت احتمالا (قطعا) چیز دیگه‌ای هست.اگه فقط یه چکش دستت باشه؛ همه چیز به نظر میخ میادچی میشه؟وقتی اون توییت رو دیدم با خودم فکر کردم آیا توییت کننده تا حالا API توسعه نداده؟ اگه داده چطور از الگوی Builder استفاده نکرده؟ پس حدس می‌زنم که تجربه توییت‌کننده با ادعاش کاملا متفاوت بودن.در توسعه نرم‌افزار یک اصل اساسی وجود داره که بقیه اصول و مفاهیم حول اون شکل گرفتن.High cohesion and less couplingاصول SOLID همین تک جمله رو ساده سازی کردن و الگوهای طراحی هم برای اجرای همین اصل ساخته و پرداخته شدن. شیوه‌های جدیدتر معماری هم برای رسیدن به این اصل تلاش کردن.حالا سوال اینجاست که آیا باید با همه الگوها آشنا باشیم یا حتما از همه اون‌ها استفاده کرده باشیم؟ جواب دو بخش داره: بله باید با الگوهای مطرح آشنا باشیم و بدونیم برای حل چه مدل مسائلی مورد استفاده قرار می‌گیرن و بخش دوم جواب هم به نظر واضح میاد. اگه تجربه کار در حوزه‌های مختلف رو داشته باشین و به همه این مدل مساله‌ها برخورد کرده باشین استفاده از الگوها زندگی رو آسون‌تر می‌کنه اما بعضی الگوها برای حل مسائل مشترک حوزه فرانت طراحی شدن و لزومی نداره متخصص‌های بک‌اند از اون استفاده کرده باشن (و برعکس).از نظر من بهتره به جای گارد گرفتن یا مسخره کردن به این نکته توجه کنیم که الگوهای طراحی برای خلق زبان مشترک برای مسائل مشترک به وجود اومدن و باعث می‌شن دو توسعه دهنده از دو فرهنگ و خاستگاه متفاوت که شیوه‌های متفاوت ذهنی برای حل مساله دارن بتونن به درک مشترک از بخش بزرگی از کدها برسن و این به تنهایی یعنی توسعه‌پذیری ساده‌تر و نگهداشت کم دردسرتر.پس کِی؟و اما می‌رسیم به این سوال اصلی که چه زمانی باید از الگوها استفاده کنیم:الگوها باید خودشون رو پیشنهاد بدن و از دل کدتون بیرون زده بشن. مسائل کلی مشابه راه‌حل‌های تست شده و جواب پس داده مشابه دارن. ذهن‌تون رو درگیر حل مساله‌های حل شده نکنین و روی دامنه مساله منحصر به خودتون تمرکز کنین.ریفکتور کردن کد به استفاده از الگوهای طراحی معمولا روش بهتری نسبت به پیاده کردن الگوها از ابتدای توسعه است.استفاده از الگوها با توجه به زبان برنامه‌نویسی مورد استفاده معمولا با پیچیده‌تر شدن کد همراه هستن (که به خودی خود چیز بدی نیست). قبل از استفاده به این سوال جواب بدین که اضافه کردن الگو به کد سود بیشتری داره یا نه. برای جواب دادن به این سوال در کنار پیچیدگی، فاکتورهایی مثل امکان نگهداشت، امکان توسعه‌پذیری و سادگی بازنویسی رو در نظر بگیرین. الگوها زبان مشترک توسعه دهنده‌ها هستن. همه با اون‌ها آشنا هستن (بهتره که باشن) پس توضیح اون‌ها در قالب مساله خیلی ساده‌تر از توضیح روش دلخواه شماست.از الگوها فقط برای اینکه از الگوها استفاده کرده باشین استفاده نکنین. الگوها باید به بهتر و تمیز شدن کد (بله، بله کتاب کد تمیز رو بخونین) کمک کنن. گفتن این جمله که: «من می‌خوام برنامه x رو با استفاده از الگوهای y و z بنویسم» یعنی شروع فاجعه. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Fri, 15 Jan 2021 13:14:07 +0330 https://virgool.io/@mehrdadep/%D8%AF%DB%8C%D8%A8%D8%A7%DA%AF-%DA%A9%D8%B1%D8%AF%D9%86-%D8%B9%D9%85%D9%84%DA%AF%D8%B1%D8%A7-wqzh0nwsa5ay برگردان غیردقیق بخش‌هایی از ویرایش دوم کتاب برنامه‌نویس عملگرادیباگ کردن عملگرادیدن خطای خود و دانستن این‌که هیچ‌کس غیر از خودتان در ایجاد آن نقش نداشته، بسیار دردناک است. Ajax, Sophoclesهیچ‌کس برنامه بی‌نقص نمی‌نویسد و بیشتر وقت برنامه‌نویسان صرف دیباگ کردن می‌شود. در ادامه برخی از تکنیک‌های عمومی برای پیدا کردن باگ‌ها را مطرح می‌کنیم.فلسفه دیباگ کردندیباگ کردن کد برای بسیاری از توسعه‌دهندگان فرایندی حسی و حساس است. ممکن است به‌جای اینکه با یک باگ به‌عنوان مساله‌ یا پازلی که باید حل شود برخورد کنید، در مقابل آن گارد بگیرید، بهانه‌های سطح پایین بیاورید، وجودش را انکار کنید، دیگران را مقصر بدانید یا حتی نسبت به آن بی‌علاقگی نشان دهید.بهتر است این حقیقت را بپذیرید که دیباگ کردن نوعی حل مساله است و تعامل خود با باگ را اینگونه پیش ببرید. اگر باگ شخص دیگری را پیدا کرده اید می‌توانید انرژی و توان خود را صرف انتقاد از او کنید. در بعضی از محیط‌‌های کاری این امر جزیی از فرهنگ تیم شده و توسعه‌دهندگان رفع باگ را بدون سرزنش دیگران انجام نمی‌دهند. به‌عنوان برنامه‌نویس عملگرا بهتر است تمام وقت شما صرف حل مشکل شود نه سرزش دیگران.مشکل را حل کنید و دست از سرزنش برداریدمهم نیست که باگ حاصل کار شما یا شخص دیگری است. مساله حاضر، مساله شماست.ذهنیتی برای دیباگ کردنپیش از شروع فرایند دیباگ کردن بهتر است ذهن خود را آماده کنید. بسیاری از مسائل احساسی مانند حفظ غرور و فشار روانی باید کنار گذاشته شوند. اصل اول دیباگ کردن این است.وحشت نکنیدترسیدن بخصوص زمانی که ددلاینی نزدیک است، رییس‌تان نگران است یا مشتری عصبانی است و شما باید علت باگ را پیدا کنید، بسیار ساده است اما نکته مهم این است که یک قدم عقب بایستید و به دنبال ریشه واقعی مشکل بگردید.اگر اولین واکنش‌تان در مقابل گزارش یک باگ «غیر ممکن است» بود، بدانید که قطعا اشتباه می‌کنید. ذهن خود را با «اما این نمی‌تواند اتفاق بیفتد» خسته نکنید چرا که هر چیزی می‌تواند اتفاق بیفتد و اکنون هم اتفاق افتاده‌است.در زمان دیباگ کردن نزدیک‌بین نباشید. در مقابل وسوسه این‌که فقط نشانه‌های باگ را برطرف کنید، مقاومت کنید. به احتمال فراوان علت اصلی و ریشه مشکل چند گام عقب‌تر از محدوده‌ دید شما قرار گرفته است. همیشه تلاش خود را معطوف به پیدا کردن ریشه مشکل کنید و به نشانه‌های ثانویه بسنده نکنید.نقطه شروعقبل از کار روی باگ، مطمئن شوید که نسخه نهایی و تمیز کد را در اختیار دارید. سطح هشدار کامپایلر خود را بالا ببرید و درگیر پیدا کردن خطاهایی که کامپیوتر می‌تواند پیدا کند، نشوید.برای حل هر مساله‌ای ابتدا باید تا جای ممکن اطلاعات کسب کنید. متاسفانه گزارش دادن باگ علم نیست و همین باعث می‌شود بروز برخی همرویدادها به سادگی مسیر دیباگ کردن را منحرف کنند. هرگز وقت خود را برای دیباگ کردن همرویدادها تلف نکنید و پیش از شروع کار دقت خود را در مشاهدات بالا ببرید.در برخی موارد گزارش‌دهنده باگ از فرایند فنی بازتولید آن بی‌اطلاع است. در این موارد سعی کنید عملکرد کاربر گزارش‌دهنده باگ را بررسی کنید و جزییات لازم در سطح مورد نظر خود را از زمان وقوع باگ کسب کنید.استراتژی های دیباگ کردنزمانی که مطمئن شدید که مشکل را می‌دانید وقت آن است که ببینید برنامه چطور عمل می‌کند.بازتولید باگبهترین روش برای رفع یک باگ، پیدا کردن راه بازتولید آن است. اگر نتوانید باگ را بازتولید کنید چگونه می‌خواهید متوجه برطرف شدن آن بشوید؟بازتولید یک باگ با انجام مراحل پیچیده و طولانی مطلوب ما نیست. هدف، بازتولید باگ تنها با یک دستور یا یک گام است. اگر برای بازتولید باگ نیاز به 15 گام مختلف باشد فرایند رفع آن بسیار پیچیده و دشوار می‌شود.از مهم‌ترین نکات دیباگ کردن این است:ابتدا تست درست با نتیجه نادرست و سپس اصلاح کد در بسیاری موارد با مجبور کردن خود به این‌که شرایط بازتولید باگ را محدود و محدودتر کنید، درک بهتری از نحوه رفع آن به دست می‌آورید. فرایند نوشتن تست راه حل را پیشنهاد می‌دهد.برنامه نویس در دنیای ناشناختهاستراتژی قبلی برای محدود کردن شرایط بسیار مفید است اما وقتی با 50 هزار خط کد رو‌به‌رو هستید باید چکار کنید؟ ابتدا به مشکل نگاه کنید. آیا اجرای برنامه متوقف شده؟ شگفت‌انگیز است که برخی برنامه‌نویسان بعد از دیدن پیغام خطا در کد به دنبال آن می‌گردند!پیغام لعنتی را بخوانیداگر برنامه متوقف نشده باشد؟ اگر پیغام نمایش داده شده اشتباه باشد؟ با دیباگر و تست خود به سراغ بازتولید مشکل بروید. گاهی اوقات مساله ساده است: insert_rate برابر 4.5 است در حالی که باید 0.045 باشد. بیشتر اوقات برای پیدا کردن اینکه چرا این مقدار اشتباه است باید عمیق‌تر به کد نگاه کنید. مطمئن باشید که می توانید به راحتی در پشته فراخوانی (call stack) بالا و پایین بروید و فراخوانی‌ها و مقادیر را بررسی کنید.همراه داشتن خودکار و کاغذ و نوشتن نکات و نقاط شروع می‌تواند به بازگشت به نقطه قبلی و سردرگم نشدن کمک بزرگی کند. گاهی اوقات سرنخی را دنبال می‌کنیم که به نتیجه‌ای نمی‌رسد. با نوشتن نقطه شروع و علت آن، می‌توانیم بدون هدر رفت زمان به همان نقطه بازگردیم و مسیر دیگری را پیش بگیریم.گاهی اوقات به پشته فراخوانی نگاه می‌کنید و خیال می‌کنید که پایانی برای آن وجود ندارد. در این مواقع از برش دودویی کمک بگیرید و در هر مرحله نیمی از پشته را دور بریزید تا به نقطه مورد نظر برسید.برش دودوییهر فارغ‌التحصیل کامپیوتر حداقل یک‌بار مجبور شده الگتوریتم جستجوی دودویی را برای لیست‌های مرتب پیاده‌سازی کند. ایده آن بسیار ساده و نتیجه آن بسیار سریع است. از ایده همین الگتوریم می‌توان برای دیباگ کردن بهره برد.وقتی با stack trace بسیار بزرگی سر و کار دارید و به دنبال آن هستید که متد دارای مشکل را پیدا کنید، پشته را به صورت تقریبی از میانه به دو قسمت تقسیم کنید و به دنبال مشکل بگردید. همین کار با نیمه اول یا دوم (به صورت بازگشتی) انجام دهید تا سرانجام به خطای مورد نظر برسید.اگر خطا روی مجموعه خاصی از داده‌ها رخ می‌دهد می‌توانید از همین ایده کمک بگیرید. مجموعه داده‌ها را کوچک و کوچک‌تر کنید تا داده‌ای که به مشکل ختم می‌شود را پیدا کنید.اگر تیم شما در مجموعه‌ای از نسخه‌ها باگ جدیدی را به‌وجود آورده نیز می توانید از همین روش استفاده کرده و با تست نسخه‌های مختلف، نسخه‌ای که موجب بروز باگ شده است را پیدا کنید. استفاده از یک ابزار کنترل ورژن در این امر کمک بسیاری خواهد کرد.لاگ و دنبال کردنابزارهای دیباگر معمولا روی وضعیت فعلی برنامه متمرکز می‌شوند و دیدی نسبت به وضعیت پیشین آن ندارند. در برخی مواقع برای یافتن علت مشکل لازم است که وضعیت برنامه و داده‌ها در طول زمان مورد بررسی قرار گیرند. مشاهده stack trace مسیر رسیدن به وضعیت فعلی را مشخص می‌کند و بخصوص در سیستم‌های مبتی بر رخداد، نمی‌تواند درباره زنجیره فراخوانی‌ها اطلاعاتی در اختیار شما قرار دهد. دنبال کردن مسیر برنامه تکنیک ساده‌ایست که می‌تواند در سیستم‌های همزمان، مبتنی بر رخداد یا بلادرنگ کمک بسیار زیادی به درک درست علت مشکل و حل آن کند. برای این‌کار کافی است در نقاط مختلف برنامه پیام‌های متناسبی قرار دهید و با بررسی آن‌ها دید خود به مساله را عمیق‌تر کنید.اردک پلاستیکییک تکنیک بسیار ساده اما موثر برای پیدا کردن ریشه مشکل توضیح آن به دیگران است. شخص دیگر باید پشت سر شما بایستد، به مانیتورتان خیره شود و مدام سرش را تکان دهد (مثل اردک پلاستیکی در وان حمام که مدام بالا و پایین می‌رود) و لازم هم نیست چیزی بگوید. فرایند توضیح مشکل، گام به گام و آن‌چه که کد باید انجام دهد، معمولا باعث می‌شود مشکل از مانیتور بیرون بپرد و خودش را نشان دهد.به نظر ساده می‌رسد اما در توضیح مساله به دیگران باید نکاتی که خودتان پیشفرض در نظر گرفته‌اید را با جزییات زیاد مطرح کنید. همزمان با به زبان آوردن این پیشفرض‌ها دید شما به مشکل نیز تغییر می‌کند. اگر شخص دیگری همراه‌تان نیست و به تنهایی کار می‌کنید، مشکل را برای اردک پلاستیکی یا گلدان خود شرح دهید.فرایند حذفدر بیشتر پروژه‌ها برنامه‌ای که شما روی آن کار می‌کنید ترکیبی از کد تیم شما، برنامه‌های طرف سوم (پایگاه‌ داده، اتصال، فریم‌ورک‌های وب، الگوریتم‌ها و ...) و محیط توسعه (سیستم عامل، کامپایلر و ...) است.ممکن است باگی در سطح سیستم عامل، کامپایلر و برنامه طرف سوم وجود داشته باشد اما این امر نباید اولین دیدگاه شما باشد. احتمال این‌که باگ در کد تیم شما وجود داشته باشد بسیار بالاتر است. این‌که برنامه شما از یک کتابخانه طرف سوم به درستی استفاده نمی‌کند باورپذیرتر از آن است که کتابخانه اشتباه کار می‌کند. حتی اگر کتابخانه دارای باگ باشد برای اطمینان ابتدا باید کد خود را از فرایند تست حذف کنید.برنامه‌نویس ارشدی در پروژه‌ای کار می‌کرد و پس از مدتی کلنجار رفتن با یک باگ عمیقا معتقد بود که select در سیستم Unix خراب است. هیچ منطق و فشاری هم نظرش را عوض نمی‌کرد. این حقیقت که همه برنامه‌های دیگر که از select استفاده می‌کنند بدون باگ هستند هم در نظرش اثری نداشت. او هفته‌ها صرف دور زدن مشکل و پیاده‌سازی روش‌های عجیب برای برطرف کردن باگ کرد اما در نهایت مشکل پابرجا باقی ماند. سرانجام از طرف مدیران مجبور شد که داکیومنت select را مطالعه کند. پس از آن باگ مورد نظر را در چند دقیقه برطرف کرد.همیشه در مواجهه با باگ در نظر داشته باشید که:تابع select خراب نیستبه خاطر داشته باشید که اگر رد سُم دیدید ابتدا به اسب فکر کنید نه گورخر! سیستم عامل به احتمال زیاد خراب نیست و select هم به درستی کار می کند.اگر شما «فقط یک چیز را عوض کرده‌اید» و سیستم خراب شده است، به احتمال زیاد همان یک چیز به صورت مستقیم یا غیرمستقیم (هر چقدر دور) مسئول این خرابی است. گاهی اوقات تغییرات بیرون از محدوده پروژه شما می‌توانند روی پروژه شما تاثیر بگذارند. ورژن‌های جدید سیستم‌عامل، کامپایلر، پایگاه داده و ... می‌توانند باعث به وجود آمدن باگ‌‌های جدید در کد شما شوند. در زمان وقوع این مدل تغییرات کل سیستم باید از ابتدا مورد تست قرار گیرد.مولفه غافل‌گیریوقتی از وقوع یک باگ غافل‌گیر می‌شوید (شاید زیر لب بگویید «محال است») باید حقایقی را که نزد خود ثابت کرده‌اید زیر سوال ببرید. در محاسبه تخفیف (همان که فکر می‌کردید در برابر هر باگی مقاوم است و امکان بروز باگ در الگوریتمش وجود ندارد) آیا همه محدودیت‌ها را بررسی کرده بودید؟ آن قطعه کد که سال‌هاست استفاده می‌کنید نمی‌تواند باعث بروز باگ شود؟البته که می‌شود. مقدار غافل‌گیری در زمان بروز خطا با میزان اعتماد و باوری که به کد خود دارید متناسب است. به همین دلیل، در زمان مواجهه با یک باگ غافل‌گیر کننده باید به این نتیجه برسید که یکی از فرضیات شما اشتباه بوده است. از بررسی یک قطعه کد فقط به این دلیل که «می‌دانید» درست کار می‌کند چشم‌پوشی نکنید. ثابت کنید. در زمینه موجود، با داده‌های و محدودیت‌های موجود درست بودن آن را ثابت کنید.فرض نکنید، ثابت کنید.در مواجهه با یک باگ غافل‌گیر کننده، همزمان با رفع باگ این سوال را مطرح کنید که چرا این باگ پیش از این کشف نشده است. روش تست خود را بررسی کنید و در صورت نیاز تغییرش دهید.اگر باگ غافل‌گیر کننده‌ای در سیستم رخ داد به این نکته فکر کنید که آیا جای دیگری از سیستم حاوی کدهایی هست که با فرض درست بودن استفاده شده‌اند؟ آیا وقتش نشده که درست بودن‌شان ثابت شود؟اگر رفع یک باگ زمان زیادی از شما گرفته، چرایی آن را از خود بپرسید. آیا راه بهتری برای رفع این مدل باگ‌ها در آینده وجود دارد؟ نوشتن هوک‌های جدید تست یا لاگ‌های جزئی‌تر کمکی می‌کند؟اگر باگ حاصل فرض اشتباه شخص دیگری در تیم است، مشکل را با تیم مطرح کنید. اگر یک نفر اشتباه متوجه شده باشد، امکان این‌که دیگران نیز اشتباه متوجه شوند وجود دارد.چک لیست دیباگ کردنآیا مشکل گزارش شده نتیجه مستقیم یک باگ است یا فقط نشانه آن است؟آیا باگ واقعا در فریمورک یا سیستم عامل شماست؟ یا در کد شما؟اگر لازم باشد که مشکل را برای همکار خود شرح دهید، چه می‌گویید؟آیا کد مشکوک شما همه تست‌ها را با موفقیت گذرانده؟ آیا تست‌های شما کامل هستند؟ اگر همین تست را با داده‌های دیگر انجام دهید چه اتفاقی می‌افتد؟آیا شرایطی که موجب بروز این باگ شده جای دیگری در سیستم وجود دارد؟ آیا باگ‌های دیگری هنوز در پیله‌اند تا پروانه شوند؟ Mehrdad Esmaeilpour Mehrdad Esmaeilpour Wed, 14 Oct 2020 21:25:01 +0330 https://virgool.io/@mehrdadep/%D8%AD%D9%84-%D9%85%D8%B3%D8%A7%D9%84%D9%87-%D8%AF%D8%B1%D8%B3%D8%AA-%D9%88-%D8%AD%D9%84-%D8%AF%D8%B1%D8%B3%D8%AA-%D9%85%D8%B3%D8%A7%D9%84%D9%87-%D8%AF%D8%B1-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-tgu3dhbfksci مسیر حل مسالهپیش از گفتارآلبرت اینشتین می گه "اگه یک ساعت برای نجات دنیا داشته باشم، پنجاه و نه دقیقه اش رو صرف تعریف مساله و یک دقیقه باقیمونده رو صرف حلش می کنم." ما بیشتر وقت ها حل مساله رو با داده های کم و عجله شروع می کنیم. تو مسیر حل، همینطور پشت سر هم مسائل بی ربط به مساله اصلی رو تو دل حل همون مساله، بوجود میاریم. در نهایت تنها با یک مساله و یک راه حل مواجه نیستیم و سردرگم برای حل مسائل بی اهمیت دور خودمون می چرخیم. حتما راه بهتری هست، اینطور نیست؟مسائل دنیای نرم افزارمهندسی نرم افزار حل مساله رو نسبت به کدنویسی در اولویت قرار می ده اما چرا؟ اول اینکه نرم افزارها نمی تونن با پیشفرض های انسانی کار کنن و اگه بهشون مسیر درست معرفی نشه حتما راه رو گم می کنن و دوم اینکه نرم افزار برای حل یک مساله ساخته می شه و اگه از قبل ندونیم اون مساله چطور حل میشه، پیاده سازی به جایی نمی رسه. بنابراین مهم ترین وظیفه یک مهندس نرم افزار آشنایی با زبان های برنامه نویسی یا فریمورک های مختلف نیست بلکه اتصال ایده ها و الگوریتم های موجود و/یا جدید به هم برای ایجاد یه نرم افزار کارا و به درد بخوره. به طور کلی فرایند حل مسائل نرم افزاری رو می شه به چهار گام تقسیم کرد:شناخت مسالهجمع آوری اطلاعاتبررسی راه حل های مختلفتست راه حلچه نوع مسائلی؟هر مساله ای در هر اندازه و نوعی می تونه در مسیر توسعه بوجود بیاد:دارین تلاش می کنین یه کار بخصوص انجام بدین و یه بخشی به شکل مطلوب کار نمی کنه.یه خطای عجیب و غریب می بینید و معنیش رو نمی دونین.با کد پیچیده ای از توسعه دهنده های اصلی سر و کار دارین که همه شون شرکت رو ترک کردن.به شکل کلی می دونین چه چیزی باید ساخته بشه اما درباره ساختار و اجزای درونی مطمئن نیستین.می خواین بدونین از کدوم پروژه های متن باز می تونین استفاده کنین.یه متدی هست که کاری که می خواین رو انجام می ده اما یادتون نیست چیه.باید شکل تعامل اجزای داخلی سیستم رو تغییر بدین اما با شیوه عملکرد بعضی از اونا آشنایی ندارین.با مساله ها دوست باشینمرحله اول شاید از بقیه مراحل ساده تر باشه. گاهی وقت ها زمان زیادی ازتون گرفته نمیشه که بخواین یه خطای واضح رو بخونین و مثلا شکل رفرنس دادن به یه متغیر رو تغییر بدین یا پکیجی که استفاده کردین رو با یه پکیج دیگه جایگزین کنین اما باگ ها اغلب خودشون رو با یه متن قرمز تو مانیتور نشون نمی دن و بعضی وقت ها مسائل می تونن پیچیده تر هم باشن. برای شناخت و درک مساله (حتی ساده ترین هاش) همیشه این سوال ها رو از خودتون بپرسین:آیا این مساله چندین مساله کوچک تر در دل خودش داره؟هدف حل مساله چیه؟قبلا چه کارهایی برای حلش کردم؟چه محدودیت های خارجی و داخلی برای حل وجود داره؟چه رفتاری رو از نرم افزار انتظار داریم؟رفتار فعلی نرم افزار چیه؟اطلاعات کلید حل مساله استخیلی ها گام اول رو رد می کنن و مستقیم به این مرحله میان و گوگل و stack overflow رو مرحله اول می دونن. آخر هم مستقیم کدهاشون رو از اینور اونور کپی می کنن. راجع به دزدیدن کد به جای کپی کردنش مطلب زیاد هست اما مخلص کلام اینه اول درک کنید و بعد کپیش کنید.عبور از گام اول شاید منجر به حل مساله بشه اما اونوقت مساله ای رو حل کردیم که اصلا نمی دونیم چی هست. قبل از رفتن به سمت راه حل ها باید بدونیم آیا افراد دیگه همین مساله یا مسائل مشابه رو تجربه کردن و ایده ها و راه حل هاشون چی بوده؟ گوگل، راهنماها و stack overflow باید فقط ابزارهایی باشن کنار بقیه ابزارهای حل مساله و حل مساله نباید از اون ها شروع بشه یا به اون ها ختم بشه. چه ابزارهای دیگه ای نیاز داریم؟اگه از پکیج یا کد متن بازی استفاده می کنین داکیومنت و کدش می تونه نقطه شروع خوبی باشه.برای آشنایی اولیه با فریمورک ها یا ابزارهای جدید راهنماهای "شروع سریع" مسیر درستی هستن.اگه نمی فهمین که یه بخش از نرم افزار به چه دلیلی به شکل فعلی طراحی شده، کامیت های قبلیش رو دنبال کنین تا داستان شروع تا نقطه فعلی و ایده توسعه دهنده اش رو درک کنین.اگه با پروتکل ها و استانداردها سر و کار دارین اول سعی کنین اسناد رسمی رو مطالعه کنین و ایده ها رو خوب متوجه بشین.و در آخر بله، موتورهای جستجو. برای زمانی که می دونین می خواین چکار کنین اما روش پایتونی، جاوایی و ... اون رو نمی دونین. راه های بالقوه رو امتحان کنینراه حل تو مراحل اولیه نیاز نیست بهترین باشه. اگه ایده ای رو امتحان کردین و نتیجه بهبود پیدا کرد، یه گام به جلو رفتین. راه حل رو همیشه میشه بهبود داد. اگه تو زمینه ناآشنایی کار می کنین، بهتره راه حل رو به قطعه های کوچک تر خرد کنید. قطعه ها رو حل کنید و به هم بچسبونین اما یادتون باشه روش Divide and conquer شما رو به لونه خرگوش حل مساله های بی ربط نکشونه. اون وقت با یه مشت XY problem مواجه می شین که شاید حل شون پر از چالش و یادگیری باشه اما در نهایت ارتباط معناداری با مساله اصلی وجود نداشته باشه. این مراحل می تونن روی کد دیگران یا کدهای کپی شده هم اعمال بشن. مفهوم دزدیدن کد همینه. ببینید و خودتون بازنویسی کنید. ایده بگیرید و از نو خلق کنید. تو این گام باید حواستون باشه راه حل ها گولتون نزن. زود قانع نشین و سعی کنین از زاویه های دیگه هم به مساله نگاه کنین. شاید شما دارین از راه حلی استفاده می کنین که مساله تون رو حل می کنه اما با تغییر نگرش بتونین راه حل ساده تر و بهینه تری رو پیدا کنین. برگشت به گام اول از این گام طبیعیه و اگه راه حلی زمان زیادی ازتون گرفته و نتیجه نداده به این موضوع شک کنین که شاید مساله رو خوب درک نکردین. برگردین و از نو با دید تازه شروع کنین. در نهایت هر زمان که راه حل تون اون چیزی که باید انجام بده رو انجام داد به گام چهارم برید.اینم راه حل، کار هم می کنهنوع تست راه حل به شیوه توسعه تون وابسته است. روش test driven development کمک تون می کنه که حل مساله رو به ابزار و روش حلش ترجیح بدین اما اگه تست اتوماتیک ندارین، سناریوهای ساده تست هم می تونن کمک تون کنن. زمانی که راه حل تون کار نکرد تصمیم اینکه به کدوم گام برگردین مهمه اما فراموش نکنین شناخت مساله مهم ترین گام حل مساله است. Mehrdad Esmaeilpour Mehrdad Esmaeilpour Tue, 08 Sep 2020 22:28:31 +0430 https://virgool.io/@mehrdadep/%D8%AF%D8%B1-%D9%85%D8%AF%D8%AD-%D9%88-%D8%B3%D8%AA%D8%A7%DB%8C%D8%B4-%D8%A7%D8%AE%D9%84%D8%A7%D9%82-%DA%A9%D8%A7%D8%B1%DB%8C-diappfojbljv اخلاق کاری (work ethic)پیش از گفتارسخت کوشی ذاتاً مقدس است و ارزش پاداش دارد.بله بله بله، می دانیم که سخت کوشی به معنای سخت و زیاد کار کردن خالی نیست! سخت کوشی، بهینه، باهوش و درست کار کردن است و معمولا منجر به خلق ارزش (مادی یا معنوی) می شود اما چه چیزهایی باعث می شوند که خیلی ها، این اصل را نادرست بدانند یا حتی با پذیریش آن موفق به رعایت اخلاق کاری در طول زندگی کوتاه شغلی خود نشوند؟ اخلاق کاری که بود و چه کرد؟برای اخلاق کاری تعاریف و فاکتورهای متنوعی ارائه شده که عمده آنها روی مسائل مشترکی تاکید دارند. در ادامه به فاکتورهای مشترک این تعاریف اشاره می کنیم و درباره هریک توضیح مختصری می دهیم.حرفه ای بودنحرفه ای بودن با توجه به مشاغل مختلف می تواند خصوصیات منحصر به فردی داشته باشد اما در بسیاری از مواردِ مشترک، نمود بیرونی آن قابل مشاهده است:رعایت ادب و احترام لباس و ظاهر مرتبنظمپرهیز از شایعه پراکنی و غرولندبازدهی بهینهکارمندانی که سعی در تقویت اخلاق کاری خود دارند سعی می کنند برنامه های روزانه کاری ایجاد کرده و آن را دنبال کنند. برای بهبود بازدهی می توان:یک طرح با جزییات ایجاد کردهدف های روز (هفته/ماه/...) را مستند کرداز حواس پرتی پرهیز کردبرای رسیدن به هدف های تعیین شده تلاش مضاعف کردکار گروهی یا همکاریدر دنیای امروز بیشتر کارها یا گروهی انجام می شود یا از طریق همکاری واحدهای (منفرد) شکل می گیرند. برای تقویت اخلاق کاری باید بدانیم که ما در نهایت عضو یک تیم و با اهداف کاری مشترک هستیم. برای بهبود کارایی در تیم به یاد داشته باشیم:رعایت احترام متقابل اعضای تیمکمک و انتقال تجربه/دانش در صورت نیاز به هم تیمی هاسازگاری با شرایط حاکم بر تیممصمم بودن برای موفقیتنه شما در حال خواندن یک متن از سخنرانی انگیزشی (یا بازاریابی شبکه ای) نیستید و موفقیت در اخلاق کاری گستره ای تا بی نهایت و جمله های بی سر و ته را در بر نمی گیرد. به یاد دارید که بازدهی بهینه یکی از فاکتورهای مشترک در تقویت اخلاق کاری است که در آن شما اهداف قابل دستیابی کاری را در بازه های زمانی محدود برای خود تعیین می کنید. همچنین امکان دارد این اهداف برای شما از سمتی بالاتر تعیین شوند که آن هم طبیعی است. فاکتور مصمم بودن این نکته را یادآوری می کند که برای بازدهی بهینه باید:فراتر از توان خود هدف بگیریداهداف را به خود یادآوری کنیدبه انجام رسیدن اهداف مقید باشیدارائه کار با کیفیت به صورت مداومهمه فاکتورهای مطرح شده پیشین در این فاکتور نمود پیدا می کنند. در واقع برای ارائه کار با کیفیت به صورت مداوم باید حرفه ای باشید، بازدهی خود را افزایش دهید، به خوبی در قالب تیم ها کار کنید و برای رسیدن به اهداف تعیین شده مصمم باشید اما این فاکتور همیشه در گرو سواد و دانش کاری است (باید در مدح و ستایش سواد کاری هم بنویسم!)فرهنگ عامه چه می گوید؟فرهنگ عامه فاکتورهای بخش قبل را ساده سازی کرده و می گوید:برایت مهم باشد چه کار می کنی!کاری که گفتی انجام می دهی را انجام بده (بهانه، اخلاق کاری را می کشد)تمرکز کن و تمرین کن حواست پرت نشودآماده باش و شگفت زده نشو Mehrdad Esmaeilpour Mehrdad Esmaeilpour Mon, 22 Jun 2020 22:40:41 +0430