🔵 عنوان مقاله
The Day the Linter Broke My Code
🟢 خلاصه مقاله:
**
روزِ خراب‌کاریِ linter یادآور این واقعیت است که تحلیل ایستا همیشه تمامِ زمینه را نمی‌بیند. یک «اصلاح بی‌ضرر»—مثل حذف یک متغیر به‌ظاهر بلااستفاده—می‌تواند رفتار پنهانی یا الگوهای پویا را از کار بیندازد و کد را بشکند. راه‌حل، کنار گذاشتن linter نیست؛ بلکه تنظیم دقیق قوانین، پرهیز از autofix برای تغییرات معنایی، کاهش شدت برخی قوانین، افزودن مستندات و استثناهای صریح، و تکیه بر تست‌ها و بازبینی انسانی است. از lint باید به‌عنوان راهنما استفاده کرد، نه مرجع نهایی؛ به‌ویژه در کدهایی که با الگوهای پویا، reflection یا codegen کار می‌کنند. با بازخورد به نگه‌داران ابزارها، استفاده از حالت‌های آگاه به نوع (مثل ESLint با TypeScript) و سیاست‌های روشن در CI، می‌توان مزایای lint را گرفت و ریسک «اصلاحات خطرناک» را کم کرد.
#linting #staticanalysis #codequality #developerexperience #CI #autofix #falsepositives #softwareengineering
🟣لینک مقاله:
https://golangweekly.com/link/174418/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The Day the Linter Broke My Code
🟢 خلاصه مقاله:
**
روزِ خراب‌کاریِ linter یادآور این واقعیت است که تحلیل ایستا همیشه تمامِ زمینه را نمی‌بیند. یک «اصلاح بی‌ضرر»—مثل حذف یک متغیر به‌ظاهر بلااستفاده—می‌تواند رفتار پنهانی یا الگوهای پویا را از کار بیندازد و کد را بشکند. راه‌حل، کنار گذاشتن linter نیست؛ بلکه تنظیم دقیق قوانین، پرهیز از autofix برای تغییرات معنایی، کاهش شدت برخی قوانین، افزودن مستندات و استثناهای صریح، و تکیه بر تست‌ها و بازبینی انسانی است. از lint باید به‌عنوان راهنما استفاده کرد، نه مرجع نهایی؛ به‌ویژه در کدهایی که با الگوهای پویا، reflection یا codegen کار می‌کنند. با بازخورد به نگه‌داران ابزارها، استفاده از حالت‌های آگاه به نوع (مثل ESLint با TypeScript) و سیاست‌های روشن در CI، می‌توان مزایای lint را گرفت و ریسک «اصلاحات خطرناک» را کم کرد.
#linting #staticanalysis #codequality #developerexperience #CI #autofix #falsepositives #softwareengineering
🟣لینک مقاله:
https://golangweekly.com/link/174418/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
👍1
🔵 عنوان مقاله
How to Reproduce and Fix an I/O Data Race with Go and DTrace
🟢 خلاصه مقاله:
در این مقاله نویسنده با یک باگ مبهم روبه‌رو می‌شود که فقط در CI رخ می‌دهد: یک data race در سطح I/O فایل‌ها که باعث شکست گهگاه تست‌ها می‌شود. چون این رقابت در مرز فایل‌سیستم رخ می‌دهد و نه در حافظه مشترک، ابزار race detector در Go آن را تشخیص نمی‌دهد. برای بازتولید محلی، نویسنده شرایط شبیه CI را ایجاد می‌کند: اجرای تکراری تست‌ها، افزایش همزمانی، و ایجاد تنوع زمانی تا ترتیب‌های نادری که خطا را می‌سازند آشکار شوند. با استفاده از DTrace و رصد فراخوانی‌های سیستمی مانند open، write، fsync و rename، الگوی واقعی آشکار می‌شود: خواندن فایل همزمان با نوشتن/حذف جزئی یا قبل از تحویل اتمی محتوا.
راهکار با اتمی‌سازی و هماهنگ‌سازی است: نوشتن در فایل موقت و سپس os.Rename برای تحویل اتمی، افزودن fsync در نقاط لازم، و در صورت نیاز قفل/کانال برای سریال‌سازی دسترسی به مسیرهای مشترک. در تست‌ها نیز از t.TempDir() برای جداسازی حالت، پرهیز از تکیه بر mtime، و اتکا به سیگنال‌های قطعی به‌جای تأخیرهای زمانی استفاده می‌شود. نتیجه، حذف flaky بودن در CI و همگرایی رفتار محلی و CI است؛ و درس اصلی اینکه برای رقابت‌های I/O باید به ابزارهای ردیابی سطح سیستم تکیه کرد و پروتکل I/O را صریح و اتمی طراحی نمود.
#Go #DTrace #Concurrency #CI #Filesystem #Testing #Debugging #RaceCondition
🟣لینک مقاله:
https://golangweekly.com/link/175360/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How to Reproduce and Fix an I/O Data Race with Go and DTrace
🟢 خلاصه مقاله:
در این مقاله نویسنده با یک باگ مبهم روبه‌رو می‌شود که فقط در CI رخ می‌دهد: یک data race در سطح I/O فایل‌ها که باعث شکست گهگاه تست‌ها می‌شود. چون این رقابت در مرز فایل‌سیستم رخ می‌دهد و نه در حافظه مشترک، ابزار race detector در Go آن را تشخیص نمی‌دهد. برای بازتولید محلی، نویسنده شرایط شبیه CI را ایجاد می‌کند: اجرای تکراری تست‌ها، افزایش همزمانی، و ایجاد تنوع زمانی تا ترتیب‌های نادری که خطا را می‌سازند آشکار شوند. با استفاده از DTrace و رصد فراخوانی‌های سیستمی مانند open، write، fsync و rename، الگوی واقعی آشکار می‌شود: خواندن فایل همزمان با نوشتن/حذف جزئی یا قبل از تحویل اتمی محتوا.
راهکار با اتمی‌سازی و هماهنگ‌سازی است: نوشتن در فایل موقت و سپس os.Rename برای تحویل اتمی، افزودن fsync در نقاط لازم، و در صورت نیاز قفل/کانال برای سریال‌سازی دسترسی به مسیرهای مشترک. در تست‌ها نیز از t.TempDir() برای جداسازی حالت، پرهیز از تکیه بر mtime، و اتکا به سیگنال‌های قطعی به‌جای تأخیرهای زمانی استفاده می‌شود. نتیجه، حذف flaky بودن در CI و همگرایی رفتار محلی و CI است؛ و درس اصلی اینکه برای رقابت‌های I/O باید به ابزارهای ردیابی سطح سیستم تکیه کرد و پروتکل I/O را صریح و اتمی طراحی نمود.
#Go #DTrace #Concurrency #CI #Filesystem #Testing #Debugging #RaceCondition
🟣لینک مقاله:
https://golangweekly.com/link/175360/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy