بذارید با یک گفتگوی فرضی بین چند تا برنامه‌نویس شروع کنیم:
--- پت بالاخره چطور مشکل پرفورمنس سرویس‌تون را حل کردید؟
--- آره، اما خیلی اذیت شدیم. حتی یک از بچه‌های تیم نصف سرویس را از اول نوشت، اما فایده نداشت. ولی نهایتا مت اومد و فقط با تغییر چند خط از کافیگ پرفورمنس را چند برابر بهتر کرد.
--- عجب خر شانسی ه این مت.
--- نه شانسی نبود، مت توی کار قبلیش چند سال با X کار کرده بود
--- مگه شما با X کار می‌کنید؟ من فکر کردم تمام سرویس‌هاتون بر مبنای Y است
--- اووم، نمی‌دونم والله!
احتمالا مشابه این داستان برای خیلی از ما اتفاق افتاده و به نظرم خیلی کَل-کَل‌های گیگ جماعت حول این داستان «یادگیری X به یادگیری Y خیلی کمک می‌کند.» می‌گردد. مثلا امکان داره یکی بگه «یادگیری C به یادگیری Go کمک می‌کند.» و بعد بقیه موافق و یا مخالف باشند
حالا اجازه بدهید برویم سر یک بحث موازی دیگر. معمولا تلاش می‌کنیم با انتخاب abstractionهای مناسب وابستگی لایه‌های مختلف سیستم را به هم دیگر تا حد امکان از بین ببریم. سوال مهم ۱: اگر همچین abstractionی وجود دارد، چرا ما نیاز داریم بدانیم اون abstraction چطور نوشته شده؟ مثلا چطور شناخت C و یا ساختار پردازنده‌ها می‌تواند ما را برنامه‌نویس بهتری به زبان مثلا Go بکند؟ این نقض غرض نیست؟
اینجا می‌شود مفهوم leaky abstraction را مطرح کرد [1]. حقیقت این است تقریبا هیچ abstractionی وجود ندارد که ما را از دانستن جزئیات پیاده‌سازی‌اش بی‌نیاز کند و اصطلاحا جزئیات از لایه‌ای به لایه دیگر نشت می‌کنند.
سوال مهم ۲: این نشت جزئیات کی قابل قبول است و کی نیست؟ من شخصا جواب واضحی برای این سوال ندارم. با این وجود اعتقاد دارم فکر کردن به جواب این سوال می‌تواند هر کسی را برنامه‌نویس بهتری بکند.
و اما جواب غیر دقیق من:
این پست بر مبنای [2] نوشته شده.
[1] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
