[ Source >> @srfirouzi_channel ]
#مهندسی_نرم_افزار
آنتیپترنها در برنامهنویسی
(الگوهای که باید از آنها دوری کرد)
در دنیای توسعه نرمافزار، الگوهای طراحی (Design Patterns) راهحلهایی اثباتشده برای مشکلات تکراری هستند. در مقابل، آنتیپترن (Anti-Pattern) ظاهراً راهحلی منطقی ارائه میدهد، اما در عمل به مشکلات جدی و هزینههای بلندمدت منجر میشود.
ویژگی کلیدی آنتیپترن این است که همیشه یک راهحل بهتر و جایگزین برای آن وجود دارد.
این مفهوم از دههی ۹۰ میلادی وارد ادبیات مهندسی نرمافزار شد و کتاب AntiPatterns (۱۹۹۸) به شناخته شدن آن کمک زیادی کرد.
نمونههای رایج آنتیپترنها
- اسپاگتی کد (Spaghetti Code): کدی درهمتنیده و بیساختار که تغییر یا توسعهاش کابوس است.
- شی خدا (God Object): کلاسی که بیش از حد مسئولیت دارد و اصل Single Responsibility را زیر پا میگذارد.
- چکش طلایی (Golden Hammer): استفاده از یک ابزار، متد یا تکنولوژی برای همهچیز، فقط به خاطر آشنایی یا راحتی.
- بهینهسازی زودهنگام (Premature Optimization): بهینهسازیای که اغلب پیچیدگی بیهوده ایجاد میکند.
- کپی و پیست (Copy-and-Paste Programming): تکرار کد در بخشهای مختلف به جای استفاده از انتزاع و ماژولار کردن.
- جریان مذاب (Lava Flow): باقی ماندن کدهای قدیمی و بلااستفاده که فهم و نگهداری پروژه را دشوار میکند.
- طراحی بیش از حد (Overdesign): افزودن پیچیدگی و امکانات غیرضروری برای نیازهایی که هنوز وجود ندارند
- و ...
چگونه از آنتیپترنها دوری کنیم؟
- از همه مهمتر آشنایی با آنتی پترن های مطرح
- بازبینی مستمر کد (Code Review).
- بازسازی ساختار کد (Refactoring) بدون تغییر رفتار.
- رعایت اصول ساده و پایهای مانند:
DRY (Don’t Repeat Yourself)
KISS (Keep It Simple, Stupid)
- انتخاب ابزار و تکنولوژی بر اساس نیاز واقعی، نه صرفاً تجربه یا سلیقه شخصی.
- تمرکز بر حل مسئلهی فعلی و پرهیز از طراحی بیشازحد برای آیندهای نامعلوم.
آنتیپترنها صرفاً «اشتباهات فردی» نیستند، بلکه تلههایی رایج در مسیر توسعه نرمافزارند. آنها در کوتاهمدت سودمند به نظر میرسند اما در بلندمدت به پیچیدگی و بدهی فنی منجر میشوند.
شناخت و پرهیز از این الگوها، یکی از مهمترین گامها برای ساخت نرمافزاری پایدار، قابلاعتماد و توسعهپذیر است.
🚁 Hicte Blog | (smm)
#مهندسی_نرم_افزار
آنتیپترنها در برنامهنویسی
(الگوهای که باید از آنها دوری کرد)
در دنیای توسعه نرمافزار، الگوهای طراحی (Design Patterns) راهحلهایی اثباتشده برای مشکلات تکراری هستند. در مقابل، آنتیپترن (Anti-Pattern) ظاهراً راهحلی منطقی ارائه میدهد، اما در عمل به مشکلات جدی و هزینههای بلندمدت منجر میشود.
ویژگی کلیدی آنتیپترن این است که همیشه یک راهحل بهتر و جایگزین برای آن وجود دارد.
این مفهوم از دههی ۹۰ میلادی وارد ادبیات مهندسی نرمافزار شد و کتاب AntiPatterns (۱۹۹۸) به شناخته شدن آن کمک زیادی کرد.
نمونههای رایج آنتیپترنها
- اسپاگتی کد (Spaghetti Code): کدی درهمتنیده و بیساختار که تغییر یا توسعهاش کابوس است.
- شی خدا (God Object): کلاسی که بیش از حد مسئولیت دارد و اصل Single Responsibility را زیر پا میگذارد.
- چکش طلایی (Golden Hammer): استفاده از یک ابزار، متد یا تکنولوژی برای همهچیز، فقط به خاطر آشنایی یا راحتی.
- بهینهسازی زودهنگام (Premature Optimization): بهینهسازیای که اغلب پیچیدگی بیهوده ایجاد میکند.
- کپی و پیست (Copy-and-Paste Programming): تکرار کد در بخشهای مختلف به جای استفاده از انتزاع و ماژولار کردن.
- جریان مذاب (Lava Flow): باقی ماندن کدهای قدیمی و بلااستفاده که فهم و نگهداری پروژه را دشوار میکند.
- طراحی بیش از حد (Overdesign): افزودن پیچیدگی و امکانات غیرضروری برای نیازهایی که هنوز وجود ندارند
- و ...
چگونه از آنتیپترنها دوری کنیم؟
- از همه مهمتر آشنایی با آنتی پترن های مطرح
- بازبینی مستمر کد (Code Review).
- بازسازی ساختار کد (Refactoring) بدون تغییر رفتار.
- رعایت اصول ساده و پایهای مانند:
DRY (Don’t Repeat Yourself)
KISS (Keep It Simple, Stupid)
- انتخاب ابزار و تکنولوژی بر اساس نیاز واقعی، نه صرفاً تجربه یا سلیقه شخصی.
- تمرکز بر حل مسئلهی فعلی و پرهیز از طراحی بیشازحد برای آیندهای نامعلوم.
آنتیپترنها صرفاً «اشتباهات فردی» نیستند، بلکه تلههایی رایج در مسیر توسعه نرمافزارند. آنها در کوتاهمدت سودمند به نظر میرسند اما در بلندمدت به پیچیدگی و بدهی فنی منجر میشوند.
شناخت و پرهیز از این الگوها، یکی از مهمترین گامها برای ساخت نرمافزاری پایدار، قابلاعتماد و توسعهپذیر است.
🚁 Hicte Blog | (smm)
👍4❤1
[ Source >> @openpcb ]
#سی
پروژه LWMalloc یه memory allocator سبک برای سیستمهای امبدده که نسبت به ptmalloc تو Glibc تا ۵۳٪ سریعتره و ۲۳٪ هم حافظه کمتری مصرف میکنه.
مشکل malloc تو امبدد اینه که به مرور حافظه رو تکهتکه میکنه و وقتی فریمور طولانیمدت بالا بمونه آخرش به کرش میرسه. بعضیا سمت garbage collection میرن، ولی روی دیوایسهای محدود خیلی وقتا عملی نیست. به همین خاطر خیلیا ترجیح میدن حافظه رو استاتیک یا با memory pool مدیریت کنن (که به نظر من بهترین راهه). یه گزینه دیگه هم نوشتن allocator اختصاصیه (که از نظر من بدترین راهه!)، و این دقیقاً کاریه که LWMalloc کرده.
طبق مقاله “LWMalloc: A Lightweight Dynamic Memory Allocator for Resource-Constrained Environments”، این لایبرری از ساختار داده خیلی سبک، سیاست deferred coalescing و استخرهای جدا برای chunkهای کوچیک استفاده میکنه. نتیجه؟ متادیتای کمتر، عملیات ادغام بهموقع به جای وسط کار، و پاسخ O(1) برای درخواستهای کوچیک.
تستهای دانشگاه SEOULTECH نشون داده LWMalloc نسبت به ptmalloc حدود ۵۳٪ سریعتره و ۲۳٪ کمتر حافظه میخوره. کل کدش ۵۳۰ خط و footprint حدود ۲۰ کیلوبایته، در حالی که ptmalloc نزدیک ۴۸۳۸ خط و ۱۱۶ کیلوبایته. تو اطلاعیهشون هم اشاره کردن که allocatorهایی مثل jemalloc، tcmalloc و mimalloc هستن ولی به خاطر مصرف حافظه بالا و پیچیدگی آخرش افت کارایی دارن.
کد C و برنامه تستش روی گیتهاب هست و چون همون malloc/calloc/realloc/free استاندارد رو پیادهسازی کرده، میشه مستقیم جاش استفاده کرد یا حتی با LD_PRELOAD بدون تغییر اپلیکیشن جایگزینش کرد.
کاربرد اصلیش تو سیستمهای امبدد و IoT با محدودیت حافظه و کاراییه: از تلویزیون هوشمند و ستتاپباکس گرفته تا پوشیدنیها، سیستمهای خودرویی real-time و کامپیوترهای edge برای AI.
ولی راستش رو بخواید، من همچنان روشهای استاتیک یا memory pool رو پیشنهاد میکنم، مگر اینکه اسلحه رو سرتون باشه :)
اگه دوست داشتید اصل مقاله رو مطالعه کنید اینجا میتونید پیداش کنید.
ریپوی پروژه رو هم اینجا میتونید بررسی کنید.
🚁 Hicte Blog | (smm)
#سی
پروژه LWMalloc یه memory allocator سبک برای سیستمهای امبدده که نسبت به ptmalloc تو Glibc تا ۵۳٪ سریعتره و ۲۳٪ هم حافظه کمتری مصرف میکنه.
مشکل malloc تو امبدد اینه که به مرور حافظه رو تکهتکه میکنه و وقتی فریمور طولانیمدت بالا بمونه آخرش به کرش میرسه. بعضیا سمت garbage collection میرن، ولی روی دیوایسهای محدود خیلی وقتا عملی نیست. به همین خاطر خیلیا ترجیح میدن حافظه رو استاتیک یا با memory pool مدیریت کنن (که به نظر من بهترین راهه). یه گزینه دیگه هم نوشتن allocator اختصاصیه (که از نظر من بدترین راهه!)، و این دقیقاً کاریه که LWMalloc کرده.
طبق مقاله “LWMalloc: A Lightweight Dynamic Memory Allocator for Resource-Constrained Environments”، این لایبرری از ساختار داده خیلی سبک، سیاست deferred coalescing و استخرهای جدا برای chunkهای کوچیک استفاده میکنه. نتیجه؟ متادیتای کمتر، عملیات ادغام بهموقع به جای وسط کار، و پاسخ O(1) برای درخواستهای کوچیک.
تستهای دانشگاه SEOULTECH نشون داده LWMalloc نسبت به ptmalloc حدود ۵۳٪ سریعتره و ۲۳٪ کمتر حافظه میخوره. کل کدش ۵۳۰ خط و footprint حدود ۲۰ کیلوبایته، در حالی که ptmalloc نزدیک ۴۸۳۸ خط و ۱۱۶ کیلوبایته. تو اطلاعیهشون هم اشاره کردن که allocatorهایی مثل jemalloc، tcmalloc و mimalloc هستن ولی به خاطر مصرف حافظه بالا و پیچیدگی آخرش افت کارایی دارن.
کد C و برنامه تستش روی گیتهاب هست و چون همون malloc/calloc/realloc/free استاندارد رو پیادهسازی کرده، میشه مستقیم جاش استفاده کرد یا حتی با LD_PRELOAD بدون تغییر اپلیکیشن جایگزینش کرد.
کاربرد اصلیش تو سیستمهای امبدد و IoT با محدودیت حافظه و کاراییه: از تلویزیون هوشمند و ستتاپباکس گرفته تا پوشیدنیها، سیستمهای خودرویی real-time و کامپیوترهای edge برای AI.
ولی راستش رو بخواید، من همچنان روشهای استاتیک یا memory pool رو پیشنهاد میکنم، مگر اینکه اسلحه رو سرتون باشه :)
اگه دوست داشتید اصل مقاله رو مطالعه کنید اینجا میتونید پیداش کنید.
ریپوی پروژه رو هم اینجا میتونید بررسی کنید.
🚁 Hicte Blog | (smm)
👍3❤1
🤯8😁3😐2😡1