طراحی‌های هزینه‌بر و غیر مؤثر از سه منبع ناشی می‌شوند:
■ یک راه حل پیچیده برای یک مشکل ساده
■ یک راه حل ساده ولی نادرست برای یک مشکل پیچیده
■ یک راه حل نامناسب و پیچیده برای یک مشکل پیچیده
#code_complete

در همین راستا:

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

اولین راه‌حل که به ذهنم رسید، این بود که آیدی آخرین موردی که توی دیتابیس خودمه و از اون سرویس اومده رو بیارم، بعد یه foreach بزنم روی ریسپانس و یکی یکی برم تا ته، هر وقت آیدی مطابقت داشت، متوقف بشه و از بعد اون صرف نظر کنم.

راه‌حل رفت روی پروداکشن و یه شکست مذبوحانه داشت. بعد از فیکس‌کردنش، این راه‌حل به ذهنم رسید:
به جای آیدی آخرین مورد، آیدی‌های اخیر رو از دیتابیس گرفتم، بعد ریسپانس رو filter کردم! منطق شلوغی که پیاده شده بود، با چند خط ساده انجام شد.

راه‌حل اول، یه مثال خوب برای راه‌حل نامناسب و پیچیده‌ای بود که برای یه مشکل ساده در نظر گرفتیم!

آقای Michael Feathers می‌گه: از نظر من، Legacy Code یعنی کدی که تست نداشته باشه.

جناب Robert Martin از اون طرف می‌گه: می‌دونم مسخره به نظر میاد، ولی قابل ملاحظه‌ست که اگه کدهای پروداکشن شما یه جوری حذف بشه و فقط تست‌هاش بمونه، می‌تونید کل سیستم با کمی تلاش بازنویسی کنید!

بعد Noback توی کتاب Advanced Web Application Architecture که قبلاً معرفی کرده بودم، برعکسش رو می‌گه: اما اگه فقط کدهای پروداکشن رو داشته باشید، اینکه براش تست بنویسید خیلی سخته!

سیستم ما، در هر ساعت، 2566~ ریکوست به یه سرویس دیگه می‌زد که با همّت بنده به 1269~ ریکوست رسید و احتمالاً در نهایت به 670~ ریکوست برسه. 😎

It makes sense for PHP to have a weak type system. Being a language that mainly works with a HTTP request, everything is basically a string.
#BrentRoose

This pattern of wrapping unstructured data in types, so that we can use that data in a reliable way, is called “data transfer objects”. It's the first concrete pattern I highly recommend you to use in your larger-than-average Laravel projects.
#BrentRoose

انتخاب اسم‌های طولانی در صورت ضرورت، ایرادی نداره و اجتناب‌ناپذیره. Brent Roose می‌گه ما توی یکی از پروژه‌هامون یه همچین کلاسی داریم:
CreateOrUpdateHabitantContractUnitPackageAction 😁

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

اگه می‌خوایید بگید یه عدد بزرگ‌تر از فلان، از min استفاده نکنید! min تعداد کاراکتر رشته رو بررسی می‌کنه، نه مقدار خود عدد!
#laravel

Before:

{{ explode('|', $gift->noscript)[0] }} - {{ explode('|', $gift->noscript)[1] }}

After:

{{ str_replace('|', ' - ', $gift->noscript) }}



آدم تحت فشار کدهای مزخرفی می‌نویسه. 😂

ادیت: کد اول، جدا از پیچیدگی و کثیف‌بودن، در صورتی که کاراکتر | داخل رشته نباشه، ارور می‌ده (توی بخش دوم)، اما کد دوم در هر صورت درست کار می‌کنه.

این وبسایت یه مجموعه از cheatsheetهای زبان‌های برنامه‌نویسی و حتی ابزارها و لایبرری‌های مختلف رو جمع کرده:
https://devhints.io

این پروژۀ جدیدیه که دارم شروع می‌کنم و محتاج ⭐️ شما هستم.
این پروژه، یه شبکۀ اجتماعیه برای افرادی که به چیز خاصی اعتیاد دارند و خودشون رو به چالش می‌کشند. ان شاء الله رنکینگ و اشیومنت و این جور چیزها خواهد داشت. تست‌های خوبی خواهم نوشت و از PHP/Laravel/Docker استفاده می‌کنم. برای پیاده‌کردن فید، ایده‌هایی دارم که حالا بعدا باید ببینیم چطوری می‌شه.
https://github.com/muhammadmp97/Hope