مهندسی

خطاها عضو جداناشدنی نرم‌افزارها هستن. تصور این که کدی داشته باشیم که هرگز هیچ خطایی براش پیش نیاد غیرواقعی و آرمانی به نظر می‌رسه. اما خطاها می‌تونن گسترهٔ تبعات خیلی وسیعی داشته باشن. یک ارور شاید باعث بشه که کاربرها فقط چند دقیقه بیشتر منتظر ثبت سفارششون بمونن، یا این که ممکنه باعث خطا در لانچ یک ماهواره و شکست خوردن پروژه و میلیون‌ها دلار ضرر و زیان بشه. نویسنده ارورها رو به چند دسته تقسیم می‌کنه و در مورد هر کدومشون توضیح می‌ده: - ارورهایی که قابل پیشبینی هستن و ما می‌تونیم هندلشون کنیم. - ارورهایی که قابل پیشبینی هستن و ما نمی‌تونیم (یا نمی‌خوایم) هندلشون کنیم. - ارورهایی که نمی‌تونیم پیشبینی کنیم (همون باگ‌ها). ...

اخیراً می‌خواستیم فیچر بزرگی رو به محصولمون اضافه کنیم. فیچر جدید ابعاد زیادی داشت که بعد از چندین اکسپریمنت و لود تست هنوز بخش‌های گنگی داشت. سوال‌هایی از قبیل اینکه می‌تونه همهٔ ریکوست‌های کاربران رو در ساعات مختلف روز جواب بده؟ اینکه owner سرویس‌های درگیر با این تغییرات عمده موافق هستن؟ این که کاربرها می‌تونن از این فیچر استفاده کنن؟ و … برای ریلیز کردن این فیچر دو راه کلی پیش رومون داشتیم. یکی این که سریع‌ ریلیز کنیم و فیدبک بگیریم (ریسک زیاد، گرفتن فیدبک سریع) یا این که بیایم قبل از ریلیز همهٔ پیشفرض‌هامون رو تست کنیم (ریسک پایین، گرفتن فیدبک کند). اما اومدیم یک راه میانی رو انتخاب کردیم که مزایای هردوی این روش‌ها رو به ارث برده باشه. به این شکل که با تعیین feature flag و ترشولدهای خیلی سخت‌گیرانه محصول رو «دیپلوی» کردیم، اما همزمان فرضیاتمون رو تحلیل می‌کردیم و بعد از مدتی محصول نهاییمون رو «ریلیز» کردیم. با این کار، عملاً بُعد دیگری به ترید‌آف‌هامون اضافه کردیم؛ همزمان که دیپلوی سریعی داشتیم، ریلیز کم‌ریسکی هم داشتیم. ...

این نوشته از بلاگ فنی Twitch می‌گه که در بازه‌هایی از زمان ممکنه تعداد ریکوست‌های کاربرها به ۲۰ برابر حالت عادی برسه! مثلاً کانکشن اینترنت یک استریمر پربیننده‌ به مشکل می‌خوره و همهٔ بیننده‌هاش شروع می‌کنن به رفرش کردن. مثل اینه که هر روز باید برای هندل کردن load یک black friday آماده باشن 🙂 در این مواقع، سرویسی که این APIهارو هندل می‌کنه که با Go نوشته شده به مشکل می‌خوره و کند می‌شه. یک راه اینه که به صورت همیشگی اسکیل کنن که خب خیلی پرهزینه و غیربهینه است. حالا اومدن توی این نوشته توضیح دادن که فقط با اضافه کردن یک خط کد به تابع main برنامه، 30% مصرف CPU و 45% لیتنسی رو کاهش دادن! من در ادامه یکم توضیح می‌دم. ...

چند هفته پیش در مورد روش‌های مختلف تست کردن dependency در کد با استفاده از test-doubleها (mock، stub، و fake) نوشتم. غیر از این سه مورد، test-doubleهای دیگری مثل spy و dummy هم هستن که کاربردهای خاص خودشون رو دارن. در همین راستا، این مفاهیم رو در یک پست به طور دقیق‌تر توضیح دادم. همچنین با استفاده از زبان Go، یک مثال از دنیای واقعی رو پیاده‌سازی کردم. پیشنهاد می‌کنم اگر کدی دارید که به یک dependency وابسته است و براش تست می‌نویسید، این نوشته رو بخونید؛ به خصوص اگر با زبان Go کد می‌زنید. https://aminrb.me/blog/go-test-double/ ...

در هنگام نوشتن Automation Test برای یک نرم‌افزار، با دیپندنسی‌ها و APIهایی مواجه می‌شیم که ترجیح می‌دیم در هر بار اجرای تست‌ها اون‌ها رو فراخوانی نکنیم. در چنین مواقعی، از Test Doubleها استفاده می‌کنیم که انواع متفاوتی دارند و اغلب به اشتباه به همه‌ٔ اون‌ها Mock می‌گیم. اینجا سه نوع رایج Test Double و تفاوت‌هاشون رو توضیح می‌دم. 📌 Fake این نوع Test Double به عنوان یک جایگزین ساده‌تر، کم‌هزینه‌تر و قابل آزمایش‌تر برای دیپندنسی مورد نظر استفاده می‌شه. Fakeها از همون interfaceهای دیپندنسی اصلی استفاده می‌کنه و اون‌ها رو پیاده‌سازی می‌کنه. مثلاً، فرض کنید می‌خوایم یک شیء رو در دیتابیس بنویسیم و بخونیم. به جای راه‌اندازی یک دیتابیس واقعی برای اجرای هربارهٔ تست‌ها، از یک دیکشنری in memory استفاده می‌کنیم تا وظیفه خوندن و نوشتن داده‌ها رو برامون انجام بده. توی این حالت این دیکشنری وظیفهٔ Fake کردن دیتابیس اصلی رو بر عهده داره. ...

تیم فنی واتس‌اپ توی این بلاگ پست توضیح داده که برای افزایش امنیت تماس‌های صوتی چه تغییراتی در طراحی‌هاشون دادن. برای این کار دوتا امکان به اپلیکیشن اضافه کردن. یکی Silence Unknown Callers است که جلوی مزاحمت و البته حمله‌های مختلف رو به گیرنده می‌گیره. همچنین Protect IP Address in Calls رو اضافه کرده که باعث می‌شه به جای برقراری ارتباط به صورت P2P، سرورهای واتس‌اپ واسط تماس صوتی باشن و طرفین از IP همدیگه اطلاع نداشته باشن تا مواردی از جنس privacy کاربر مثل موقعیت جغرافیایی و پرودایدر اینترنت پنهان بمونه. ...

بروزرسانی نسخهٔ دیتابیس در خیلی از پروژه‌ها و شرکت‌ها کار پیچیده‌ای نیست و شاید چند ساعت بیشتر زمان نیاز نداشته باشه. اما برای شرکتی مثل Github که +۳۰۰ ترابایت داده رو بر روی بیشتر از ۵۰ کلاستر دیتابیس نگهداری می‌کنه و +۵ میلیون کوئری بر ثانیه رو تحمل می‌کنه، پروژه‌ای بزرگ و پر هزینه است. در گیتهاب چندین تیم بیشتر از یک سال برای ارتقای mysql 5.7 به 8 بر روی برنامه‌ریزی، تست و اجرای این فرآیند زمان گذاشتن تا بتونن بدون داون‌تایم خاصی، این ارتقا رو صورت بدن. ...

سال پیش شرکت متا محصول Threads رو عرضه کرد. این محصول جدا از سر و صدایی که به خاطر رقابت با توییتر درست کرد، یک شاهکار مهندسی در دنیای نرم‌افزار بود. پیاده‌سازی یک محصول کامل در ۵ ماه، رسیدن به ۱۰۰ میلیون یوزر در یک هفته و بدون هیچ داون‌تایم خاصی! من خیلی کنجکاو بودم ببینم چطوری محصولی با این کیفیت رو در این مدت زمان کوتاه پیاده‌سازی و عرضه کردن. توی این قسمت از پادکست مهندسی متا، با سه نفر از مهندس‌های Threads در مورد همین موضوع صحبت کردن. یک Android Engineer، یک iOS Engineer و یک Product Backend Engineer. ...

بدهی‌های فنی عضو جدا ناپذیر توسعهٔ یک محصول هستن. با وجود این که عموماً بار معنایی منفی دارن، اما به وجود آوردنش لزوماً تصمیم معیوبی نیست؛ بلکه همونطور که از اسمش پیداست، یک چیزی رو قرض می‌گیریم که در آینده و در فرصت بهتری بهاش رو پرداخت کنیم. مارتین فالر بدهی‌های فنی رو به چند دسته تقسیم می‌کنه. بدهی‌های فنی می‌تونن بی‌ملاحظه (reckless) باشن و یا محتاطانه (prudent) به وجود اومده باشن. این که بیایم دیزاین یک قسمتی از کد رو به خاطر چند روز از برنامه جلو افتادن بد پیش ببریم، بیشتر ساختن یک بدهی بی‌ملاحظه است تا محتاطانه. یا این یک بدهی تولید کنیم و برنامه‌ای بهبودش در آینده نداشته باشیم بی ملاحظه است. ...

در محصول‌های بالغ، اکسپریمنت کردن روش خوبی برای تغییر و بهبوده؛ ولی خیلی مهمه که بدونیم به کمک یک اکسپریمنت خاص به چه نتیجه‌ای می‌خوایم برسیم، چه یوزرهایی رو درگیر می‌کنیم و چه نیازهایی برای این اکسپریمنت داریم. به طور دقیق‌تر، وقتی می‌خوایم یک تغییری رو آزمایش کنیم، خوبه که قبلش برای این دو سوال جواب داشته باشیم: با این آزمایش به چه تصمیمی می‌خوایم برسیم؟ چرا این تصمیم رو با اطلاعات فعلی نمی‌تونیم بگیریم؟ جواب دادن به این سوال‌ها کمک می‌کنه که اکسپریمنت‌هایی رو طراحی کنیم که با حداقل منابع، بیشترین کمک رو به تصمیمی که می‌خوایم بگیریم بکنه. یک نکته دیگری که مقاله میگه اینه که بدونیم برای چه کاربری داریم آزمایش رو اجرا می‌کنیم و تا جای ممکن کاربرها رو به صورت محلی انتخاب کنیم. این که بیایم تغییری رو برای همهٔ کاربرهامون آزمایش کنیم، احتمالاً به اون نتیجه‌ای که می‌خوایم بگیریم همگرا نمی‌شیم. مثلاً یک تغییری ممکنه برای یک دسته از کاربرهامون خیلی مفید باشه اما دستهٔ عمده‌تری بهبودی حس نکنن. توی این حالت متریک‌هامون به اندازه کافی جابجا نمی‌شه و ممکنه به نتیجه برسیم که تغییر، تغییر خوبی نیست؛ در صورتی که می‌تونستیم این تغییر رو فقط برای اون دستهٔ محدودتر کاربرهامون انجام بدیم. ...