اگر دانش قدرت است، دانستن اینکه نمی‌دانیم خردمندی.

— متن بیوی Mohammad Reza

همراه‌اول گفته تعرفه‌های خدماتش رو تا ۳۰ درصد گرون می‌کنه از امروز.

یکی از خطرناک‌ترین جمله‌هایی که تو پروژه می‌شنوی اینه: «فعلاً ساده بزن، بعداً درستش می‌کنیم.»

معمولاً این «بعداً» هیچ‌وقت نمیاد.
می‌شه همون کدی که همه از دست زدن بهش می‌ترسن، یا اون ستون بلااستفاده‌ی یه جدول دیتابیس که آلتر کردنش مثل دست زدن به یه برج جِنگائه.

وقتی تصمیم‌ها مستند نیستن، ساده‌ترین تغییر هم ریسک می‌شه.

کد فقط خط به خط نوشته نمی‌شه؛
با تصمیم‌هایی ساخته می‌شه که یا ثبت می‌شن، یا بعداً تبدیل می‌شن به حدس و دعوا.

فکت: QA in Agile isn’t a phase. It’s a responsibility that never turns off.

یه چیزی که توی کار با تیم‌های مختلف برام جا افتاده اینه که QA توی Agile اصلاً یه مرحله نیست. بیشتر شبیه یه مسئولیت دائمیه که از لحظه‌ای که درباره‌ی یه فیچر حرف می‌زنیم شروع می‌شه و عملاً هیچ‌وقت خاموش نمی‌شه.

هر وقت می‌بینم QA شده آخرِ خط فلوی توسعه، معمولاً بقیه‌ی مسیر یه جاییش اشتباه رفته. چون وقتی QA رو برابر با تست آخر کار می‌گیریم، یعنی پذیرفتیم که قراره ریسک رو جمع کنیم، نه اینکه از اول جلوش رو بگیریم.

برای من، QA از همون موقعی شروع می‌شه که هنوز کدی نوشته نشده. وقتی درباره‌ی ری‌کوایرمنت حرف می‌زنیم، وقتی یه جمله هنوز مبهمه، وقتی معلوم نیست قراره سیستم توی حالت‌های غیرعادی چی‌کار کنه. همون‌جاهاست که اگه سؤال درست پرسیده نشه، بعداً باگ درست می‌شه.

تو روزمره‌ی واقعی، QA بیشتر شبیه فکر کردنه تا تست کردن. فکر کردن به این که اگه این مقدار نال باشه چی می‌شه، اگه کاربر این کار رو نکنه چی، اگه سیستم نصفه جواب بده چی. خیلی از چیزایی که آخر کار به عنوان باگ دیده می‌شن، اگه همون وسط توسعه یه بار دیده می‌شدن، اصلاً به اون مرحله نمی‌رسیدن.

یه سوءتفاهم رایج هم اینه که QA قراره کار بقیه رو آخرش تأیید کنه. یا بدتر، قراره جای خالی تست‌هایی رو پر کنه که اصلاً نوشته نشدن. تجربه‌ی من می‌گه هر جا این اتفاق افتاده، نه QA کمک کرده، نه تیم جلو رفته؛ فقط هزینه اضافی ایجاد شده.

حقیقتش اینه که وقتی QA آخر کار باگ‌های واضح پیدا می‌کنه، معمولاً مشکل از QA نیست. فرآینده که دیر فهمیده، تیمه که دیر فکر کرده. تیم‌هایی که خوب کار می‌کنن، کنترل کیفی رو نمی‌دن جلوتر؛ همون اول می‌سازنش. QA فقط کمک می‌کنه شکاف‌ها زودتر دیده بشن.

آیا با وجود یک نقش QA در سازمان، آگاهانه ریسک رو کم می‌کنیم یا نه. چون QA توی سیستم Agile بیشتر از هر چیزی، هدفش جلوگیری از اشتباهاته؛ قبل از اینکه برسن به prod و دیگه دیر شده باشه.

نرم‌افزار نباید یواشکی خراب بشه: راهنمای جیغ کشیدن درست!

یه چیزی که توی پروژه‌های مختلف حسابی عصبیم کرده، اپلیکیشن‌هایی‌ان که بی‌صدا و مخفیانه اشتباه می‌کنن. فکر کن همه‌چی داره خوب پیش می‌ره، داده‌ها ذخیره می‌شن، کاربر خوشحاله، ولی یه جایی توی عمق کد، یه خطای کوچولو داره همه‌چی رو به گند می‌کشه – بدون این‌که حتی یه سرنخ بده.

خطرناک‌ترین باگ‌ها، همونایی‌ان که ساکت می‌مونن. کرش کردن حداقل یه افتخاره! حداقل می‌گه: «هی رفیق، یه جایی از دستوراتت گند زدی، بیا درستش کن!» ولی خطای silent؟ به دروغ می‌گه «همه‌چی اوکیه» و تو بعداً توی prod می‌فهمی که چند هفته‌ست داده‌ها اشتباه ذخیره شدن یا محاسبات غلط بوده.

تجربه‌ی من می‌گه هر وقت دیدم توی کد try-catch خالی داریم، یا ارور رو swallow می‌کنیم بدون لاگ، یا فکر می‌کنیم «حالا اشکال نداره، بعداً درست می‌شه»، دقیقاً همون‌جا داریم بذر یه فاجعه رو می‌کاریم.
پس چیکار کنیم؟ ساده‌ست:

لطفاً بذارید نرم‌افزار وقتی دردش میاد، مثل بچه‌ی لوس جیغ بکشه.

هر اروری که می‌گیریم، حداقل یه لاگ درست و حسابی بزنیم (با جزئیات، stack trace، context).
اگه ارور کریتیکاله، آلارم بفرستیم (به Slack، RocketChat یا Telegram هر چی!).
و Fail fast کنیم: به جای این‌که سعی کنیم با یه مقدار پیش‌فرض ادامه بدیم، همون‌جا بگیم «نمی‌تونم ادامه بدم» و کرش کنیم یا ارور برگردونیم.
و مهم‌تر از همه، هیچ‌وقت ارور رو قورت ندیم.

نرم‌افزار سالم، نرم‌افزاریه که وقتی مشکلی داره، داد می‌زنه تا زودتر درست بشه. نه این‌که یواشکی خراب بشه و بعداً همه رو غافلگیر کنه.

دفعه‌ی بعد که وسوسه شدی یک خطا رو silent کنی، یادت باشه:
Software should fail loudly, not silently

اینطوری حداقل می‌دونیم کجای کار داره اشتباه جلو می‌ره، نه این‌که یه روز صبح بیدار بشیم و ببینیم همه‌چی ریخته به هم!

رباتی که توی چنل @mtproxyboy پروکسی پُست می‌کرد، به‌خاطر جابجایی کل پروژه‌هام به یک سرور نزدیک‌تر به تلگرام، خاموشه. همه رو دوباره فعال کردم اما فرصت نکردم این یکی رو دوباره دیپلوی کنم.
ممکنه تا فردا هم وقت آزادشو پیدا نکنم. بابتش عذر میخوام.

تلسکوپ، یک Cross-browser web performance testing agent از کلودفلره:
- ضبط ویدیو و فیلم‌استریپ از بارگذاری صفحه
- جمع‌آوری معیارهای زمان‌بندی، خروجی کنسول، HAR و screenshot
- امکان شبیه‌سازی شبکه، محدودیت CPU، غیرفعال‌کردن JS و تنظیم کوکی/هدر

https://github.com/cloudflare/telescope

جی‌میل بلاخره اجازه می‌ده به کاربراش که بتونن آدرس اکانتشون رو عوض کنن!
https://www.linkedin.com/news/story/google-finally-lets-gmail-users-change-their-addresses-6844044/