<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های امیر ضیاءپور</title><link>https://virgool.ir/feed/@amirzpr</link><description>Software Engineer</description><language>fa</language><pubDate>2026-11-11 17:10:03</pubDate><image><url>https://virgool.ir/images/default-avatar.jpg</url><title>امیر ضیاءپور</title><link>https://virgool.ir/@amirzpr</link></image><item><title>چطور paginate کنیم، آب زیرمون نره؟</title><link>https://virgool.ir/@amirzpr/sql-pagination-ujshverzgndn</link><description>صفحه‌بندی رکوردهای ذخیره شده در دیتابیس، بخش جدایی ناپذیر هر پروژه نرم افزاری، به خصوص از نوع وبشه. راهکار پیش فرض و دم دستی هم برای انجام این کار در دیتابیس‌های SQL استفاده از کلیدواژه‌های OFFSET و LIMIT هست. حتی چند ORMئی هم که من بررسی کردم، همه متد paginate رو با استفاده از همین دو کلیدواژه ترجمه می‌کردند.استفاده از LIMIT و OFFSET خیلی راحت و قابل فهمه و زمانی که تعداد رکوردها کم باشه یا به کاربر اجازه گردش عمیق در صفحات (یعنی رفتن به شماره صفحات خیلی بالا) رو ندیم، آپشن کاملا مناسبیه. اما این نکته رو باید در نظر داشته باشیم که وقتی ما مثلا از OFFSET 1000 استفاده میکنیم، اینطور نیست که MySQL از روی 1000 رکورد اول بپره و مستقیم بره سراغ 1001 و از اونجا شروع کنه دیتا رو بگیره. بلکه به اندازه مجموع اعداد آفست و لیمیت رکوردها رو واکشی میکنه و داخل مموری میاره، بعدش اون تعدادی که با آفست مشخص شده رو دور میریزه و بقیه‌اش رو به اپ ما تحویل میده.بنابراین اگر جدولی با مثلا یک میلیون رکورد دارید، تا زمانی که عدد آفست کوچیک باشه، مشکل خاصی ایجاد نمیشه. اما با افزایش آفست زمان پاسخ دهی به صورت خطی افزایش پیدا میکنه و اختلاف قابل ملاحظه‌ای رو خواهید دید که باید مراقبش باشید.مشکل اصلی استفاده از OFFSET در کوئری اصلیوقتی ما «مستقیما» از OFFSET در کوئری اصلی استفاده میکنیم، تعداد زیادی ردیف از جدول مورد نظر که ما در واقع قصد نادیده گرفتنشون رو داشتیم، ابتدا لود میشن توی مموری و قبل از خروجی دادن دور ریخته میشن. 🚮چه زمانی این مشکل تشدید میشه؟‫1- زمانی که تعداد رکوردهای جدول خیلی زیاد باشه‫2- زمانی که جدول ستون‌های زیاد یا حجیمی داشته باشهبنابراین، بدیهیه که برای بهبود اوضاع، یکی از 2 راه حل زیر رو پیش رو داریم:‫1- حداقل تعداد «ردیف» رو لود کنیم‫2- حداقل تعداد «ستون‌» رو لود کنیماول بریم سراغ مورد دوم، چون توضیح و پیاده‌سازیش ساده‌تره.روش Deferred Joinبه منظور لود کردن حداقل تعداد ستون ممکن در مموری، میتونیم از تکنیکی به نام Deferred Join استفاده کنیم. روش کار به این صورته که به جای استفاده «مستقیم» از آفست روی کوئری اصلی، باید آفست و لیمیت رو در یک «ساب‌کوئری» روی زیرمجموعه‌ای از جدول مورد نظر با حداقل تعداد ستون ممکن اعمال کنید و سپس اون رو با INNER JOIN به کوئری اصلی که در نظر داشتید الحاق بزنید. به مثال زیر توجه کنید:SELECT * FROM products&#xA;INNER JOIN (&#xA;    SELECT id FROM products ORDER BY name, id LIMIT 100 OFFSET 500000&#xA;) AS tmp USING (id)&#xA;ORDER BY name, idاتفاقی که میفته اینه که برای اون 500 هزار رکورد ناخواسته‌ای که توی مموری لود میشه، فقط دیتای ستون‌های درگیر در مرتب‌سازی لود میشه و دیتای تمام ستون‌ها فقط برای 100 رکورد مورد نیاز بیرون کشیده میشه.همین تکنیک ساده، زمان لود دیتا رو حتی برای جدول‌هایی که تعداد ستون کمی دارند (مثلا 5 تا ستون سبک) حدودا 3 برابر کاهش میده. طبیعتا وقتی تعداد ستون‌ها زیاد باشه، این اختلاف میتونه چند ده برابر هم بشه.دلیل استفاده از واژه deferred به معنای «به تعویق افتاده» هم به این دلیله که انجام عمل الحاق تا بعد از عمل pagination به تعویق میفته.روش Cursor-based paginationبرای این که حداقل تعداد ردیف ممکن رو لود کنیم، چاره‌ای نداریم جز این که OFFSET رو به کلی کنار بذاریم و یه کاری کنیم که دیتابیس عزیزمون مستقیم بره سر اصل مطلب. حالا وقتی برای مشخص کردن رکوردهای مورد نظرمون دیگه آفست رو نداریم، چی برامون میمونه؟ آفرین، WHERE. برخلاف OFFSET ،WHERE اصلا دورریز نداره. یعنی میره دقیقا همون میزان دیتایی که میخوایم رو میاره توی مموری، نه بیشتر.حالا برای فیلتر کردن با WHERE که به شرط نیاز داریم. شرطش چی باشه؟!جواب ما رو دوستانی که روش Cursor-based pagination رو ابداع کردند، دادند. در این روش، ما از یک cursor یعنی نشانه یا مکان‌نما برای تعیین صفحه بعد نتایج استفاده می ‌کنیم.لازمه تاکید کنم که این cursor که ازش صحبت می ‌کنیم، با database cursor که مفهوم کاملا متفاوتی هست فرق داره.بذارید با یه مثال خیلی ساده مفهومش رو براتون شرح بدم.SELECT * FROM products ORDER BY id LIMIT 10;کوئری بالا که داره محصولات رو بر اساس id مرتب میکنه و 10 تای اول رو برمیگردونه. فرض کنید آی ‌دی آخرین رکوردی که خروجی داده 10 بوده که برای ما عدد مهمیه. چون باید حتما این عدد رو توی جوابی که به فرانت میدیم قرار بدیم. مثلا میتونیم جواب رو با چنین فرمتی بفرستیم:{&#xA;    &#34;next_page&#34;: &#34;(id=10)&#34;,&#xA;    &#34;records&#34;: [ &#xA;        // ...&#xA;    ]&#xA;}در مرحله بعد، فرانت باید برای گرفتن نتایج صفحه بعد، توی درخواست بعدی مقدار next_page ای که دریافت کرده رو به سرور بفرسته. کوئری اجرا شده بعد از تفسیر مقدار دریافت شده، در این مرحله به این شکل خواهد بود:SELECT * FROM products WHERE id &gt; 10 ORDER BY id LIMIT 10;حالا اگه علاوه بر ستون id، محصولات رو ابتدا با ستون &#34;نام&#34; مرتب کرده باشیم چی؟ به مثال زیر توجه کنید:SELECT * FROM products ORDER BY name, id LIMIT 10;در این صورت، هم مقدار next_page متفاوت میشه، هم شرط WHERE کوئری کمی پیچیده ‌تر میشه. فرض کنید آخرین رکوردی که از کوئری بالا به دست میاد، نامش &#34;NoteBook&#34; و آی ‌دیش &#34;309&#34; باشه. در این صورت مقدار next_page و کوئری به ترتیب اینطور خواهند بود:‭next_page = (name=NoteBook, id=309)SELECT * FROM products WHERE&#xA;   (&#xA;       (name &gt; &#39;NoteBook&#39;)&#xA;       OR&#xA;       (name = &#39;NoteBook&#39; AND id &gt; 309)&#xA;   )&#xA;ORDER BY name, id LIMIT 10;همونطور که مشاهده میکنید، توی کوئری 2 تا شرط داریم که با &#34;یا&#34; به هم متصل شدند که به این صورت ترجمه میشه:رکوردهایی که نامشون بعد از NoteBook هست یا نامشون مساوی با NoteBook هست ولی id بزرگتر از 309 دارند رو بهم بده.خب، این هم Cursor-based Pagination بود که خیلی خلاصه خدمتتون توضیح دادم. مزیت این روش به طور واضح اینه که فقط دیتای مورد نیاز رو داخل رم لود میکنه. بزرگترین ایرادش هم اینه که قابلیت رفتن به یه شماره صفحه خاص مثلا صفحه 15 رو از دست میدیم. از این رو، استفاده از این روش، بیشتر برای لیست ‌هایی که به صورت اسکرول نمایش داده میشن توصیه میشه.گفتن این نکته هم خالی از لطف نیست که معمولا مقدار next_page رو با کد گذاریbase64  رد و بدل میکنند که ما توی مثال ‌هامون برای ساده ‌سازی ازش صرف نظر کردیم.جمع بندیممنون بابت وقتی که برای خوندن این نوشته گذاشتید. اگر نظری دارید یا راه‌های دیگه‌ای میشناسید، خوشحال میشم که همین جا یا در صفحه لینکدین من، با من در میون بذارید.</description><category>امیر ضیاءپور</category><author>امیر ضیاءپور</author><pubDate>Wed, 24 Apr 2024 20:51:37 +0330</pubDate></item><item><title>کثیف ننویس! (بخش چهارم)</title><link>https://virgool.ir/@amirzpr/کثیف-ننویس-بخش-چهارم-vqunvmy2xar9</link><description>سلام. من امیر ضیاپور هستم؛ و بالاخره رسیدیم به آخرین بخش این موضوع. این سری نوشته‌ها از اینجا شروع شد و قراره با این قسمت خاتمه پیدا کنه. پس با من همراه باشید و نکات این بخش رو هم به ذهن بسپارید و تو کدهاتون ازشون استفاده کنید.۲۹) از عملگرهای کوتاه استفاده کنیدزبان PHP عملگرهای بسیار کارآمدی داره که میتونن جایگزین if-check های زشت بشن! پس اونا رو بخاطر بسپارید و ازشون استفاده کنید.۳۰) استفاده از helper ها به جای facade ها رو در نظر بگیریدمیشه گفت که این مورد بیشتر یه نظر شخصیه، اما صدا زدن یه تابع global به جای اینکه یه کلاس رو import کنید و متد استاتیکشو صدا بزنید، به نظر من قشنگ تره.علی الخصوص در مورد سینتکس (&#39;session(&#39;key. ۳۱) برای business logic، دستورات blade سفارشی بسازیدمیتونین با ساختن دستورات سفارشی، محتویات فایل‌های blade خودتون رو گویاتر کنید. برای مثال، به جای چک کردن این که یوزر، ادمین است یا نه، میتونین دستور admin@ رو بسازید و ازش استفاده کنید.۳۲) توی فایل‌های Blade به دیتابیس کوئری نزنیدبعضی اوقات ممکنه که بخواین کوئری‌ها رو تو فایل blade اجرا کنید. برخی از مواقع ایرادی تو این کار وجود نداره، مثلا داخل فایل‌های layout.اما اگه اون view رو قراره یه کنترلر برگردونه، اطلاعات رو درون کنترلر از دیتابیس بگیرین و به view پاس بدین.۳۳) مقایسه strict انجام بدینهمیشه از مقایسه strict استفاده کنید (=== و ==!). اگه لازم بود، قبل از مقایسه، مقادیر مورد مقایسه رو به type درستشون cast کنید. این کار بهتر از اینه با نتایج عجیب حاصل از == روبرو بشین.همچنین، strict types رو تو کدتون فعال کنید. این کار باعث میشه که نتونین متغیرهای با type نادرست رو به توابع پاس بدین.۳۴) از doc-block فقط زمانی استفاده کنید که به درک عملکرد کمک می‌کننخیلی از افراد با این نکته مخالفن، چون خودشون برای همه فانکشن‌ها doc-block مینویسن. اما واقعا با عقل جور درنمیاد!وقتی یه doc-block هیچ اطلاعات اضافه‌ای رو به خواننده‌اش نمیده، پس چرا باید نوشتش؟ اگه type hint برای درک کار فانکشن کفایت میکنه، دیگه لازم نیست doc-block رو هم اضافه کنید.۳۵) یک منبع واحد برای قوانین validation داشته باشیداگه attributeهای یک resource رو در جاهای مختلف اعتبارسنجی (validate) می‌کنید، قطعا باید قوانینش رو تو یه جای مشخص یک بار بنویسید و هر بار اونها رو تکرار نکنید تا در صورت نیاز به ایجاد تغییر تو قوانین، لازم نباشه بگردین تا هر جا که ازش استفاده کردید رو پیدا کنید.مثلا تو عکس پایین، یه متد تو کلاس مدل براش در نظر گرفته شده، اما یه راه (درست‌تر) دیگه‌اش، استفاده از Form Request Class هست که در بخش‌های قبلی همین مقاله بهش اشاره شده.۳۶) از کالکشن‌ها فقط وقتی که کدتونو تمیزتر میکنن استفاده کنیدلازم نیست که تمام arrayها رو به کالکشن تبدیل کنید فقط به این خاطر که لاراول این امکان رو بهتون میده. اما اگه جایی استفاده از کالکشن، کدتون رو تمیزتر میکنه، حتما ازش بهره ببرید.۳۷) از کد functional وقتی استفاده کنید که واقعا فایده‌ای داشته باشهکد فانکشنال هم میتونه کد رو تمیز کنه، هم غیر قابل درکش کنه! لوپ‌های معمول رو به فانکشن ریفکتور کنید، اما فقط به دلیل این که نمیخواین یه حلقه بنویسین، ()reduce های فوق پیچیده رو جایگزینش نکنین. تو عکس پایین، مثالی از هر دو مورد هست.۳۸) کامنت‌ها اغلب نشون دهنده طراحی کد ضعیف هستنقبل از این که یه کامنت رو بنویسید، از خودتون بپرسین که چطور میتونم با تغییر نام بعضی چیزا یا ایجاد متغیر، خوانایی کد رو بیشتر کنم و نیاز به نوشتن کامنت رو از بین ببرم. اما اگه شدنی نبود، کامنت رو طوری بنویسید که هم خودتون هم همکاراتون ۶ ماه بعد متوجه بشن منظورتون چیه!? کانتکست مهمه!تو نکته‌های قبل گفتم که انتقال بیزینس لاجیک به کلاس‌های action/service کار خوبیه. اما کانتکست اهمیت داره.عکس زیر یکی از نکات ریپازیتوری معروف &#34;Laravel best practices&#34; تو گیتهابه. واقعا هیچ دلیلی نداره که بخواین یه if-check سه خطی رو به یه کلاس تبدیل کنید! با این کار اصطلاحا over-engineering انجام دادین.خب دوستان، به پایان رسید این دفتر، اما حکایت کدنویسی تمیز و برنامه‌نویس بهتر شدن همچنان باقیست و فکر نکنم حکایتی باشه که حالا حالاها تموم بشه!در پایان این مقاله لازمه بگم که هیچ ضرورتی وجود نداره که تمام نکاتی که گفته شد رو رعایت کنید. هدف شما نوشتن کد خواناست نه صرفا انجام دادن کارهایی که یه نفر تو اینترنت گفته!همیشه موقع نوشتن کد از خودتون بپرسید «بهتر نیست اینجوری انجامش بدم؟». اگه جواب مثبت بود، پس « اینجوری! » انجامش بدین. 😁‫✳️ اگه نوشته رو دوست داشتین، لایک کنین؛‫✳️ اگه نظری داشین، نظرتونو برام بنویسید؛‫✳️ اگه براتون مفید بوده و قصد حمایت دارید، با دیگران به اشتراک بذارید.‮🔗 لینک بخش‌های قبلی‫- کثیف ننویس! (بخش اول)‫⁧- کثیف ننویس! (بخش دوم)‫- کثیف ننویس! (بخش سوم)</description><category>امیر ضیاءپور</category><author>امیر ضیاءپور</author><pubDate>Thu, 02 Jul 2020 16:14:07 +0430</pubDate></item><item><title>کثیف ننویس! (بخش سوم)</title><link>https://virgool.ir/@amirzpr/کثیف-ننویس-بخش-سوم-pg1d26ulcd9w</link><description>? بهتره قبل از خوندن این نوشته، بخش‌های قبلیش ( اول و دوم ) رو خونده باشید.درود بر همه شما دوستان عزیزی که همیشه در حال تلاش برای تبدیل شدن به یه برنامه‌نویس بهتر هستین و به خاطر همینه که الان دارین این نوشته رو میخونین ?. در ادامه مبحث اصول کدنویسی تمیز در لاراول، در این نوشته هم ۱۰ مورد دیگه رو بررسی می‌کنیم. Just doing some cleaning after writing dirty code! ?۱۹) سعی کنید از CRUD اکشن‌ها استفاده کنیدCRUD ?  Create, Read, Update, Deleteاگه امکانش وجود داره، فقط از ۷ اکشن CRUD اصلی (یا حتی کمتر) تو کنترلرهاتون استفاده کنید.کنترلرهایی نسازید که توشون ۲۰ تا متد وجود داره. هر چه کنترلر کوتاه‌تر باشه بهتره.۲۰) از اسم‌های معنادار برای نامگذاری متدها استفاده کنیدبه جای فکر کردن راجع به این که «این آبجکت چه کاری میتونه انجام بده؟»، به این فکر کنید که «چه کاری رو این آبجکت انجام پذیره؟».استثنائاتی هم ممکنه وجود داشته باشه (مثلا در مورد action classها)، اما در حالت کلی، استفاده از این روش میتونه خیلی کمک کننده باشه.۲۱)ـ trait های یکبار مصرف بسازیداضافه کردن متدها به کلاسی که بهش تعلق دارن راه حل تمیزتریه نسبت به حالتی که برای هر چیز action class بسازیم اما باعث میشه کلاس‌هامون بزرگ بشن.اینجاست که میتونید استفاده از trait ها رو در نظر بگیرید. درسته که هدف اصلی ساخت trait ها، قابلیت استفاده مجدد از اونهاست، اما اشکالی نداره که trait های یکبار مصرف هم داشته باشیم.۲۲)ـ Blade include های یکبار مصرف بسازیداینا هم مثل مورد قبلی هستن.این تکنیک جاهایی به کارتون میاد که تمپلیت‌های خیلی طولانی دارید و میخواین کاری کنین که مدیریتشون آسون‌تر بشه.خیلی راحت میتونین فایل‌های blade دلخواهتون رو بسازید و با استفاده از تگ include@ اونا رو تو تو یه فایل blade دیگه فراخونی کنید.۲۳) به جای استفاده از alias،ـ name spaceها رو ایمپورت کنیدبعضی اوقات ممکنه چند کلاس با یه نام داشته باشید. به جای اینکه اونا رو با یه alias ایمپورت کنید، میتونین فضاهای نامی یا همون namespace هاشون رو ایمپورت کنید.۲۴) برای where های پیچیده، query scope بسازیدبه جای نوشتن کوئری‌های پیچیده با ()where،ـ query scope بسازید و یه اسم معنادار روش بذارین.این باعث میشه که کنترلرها درگیری کمتری با ساختار دیتابیستون داشته باشن.۲۵) از متدهای مدل برای دریافت داده استفاده نکنیداگه میخواین از یه مدل داده‌ای رو دریافت کنید، accessor ایجاد کنید.برای آشنایی با نحوه ساخت accessor به این لینک مراجعه کنید.از متدها فقط زمانی استفاده کنید که لازم باشه به نحوی تغییری در مدل ایجاد کنید.۲۶) از فایل‌های کانفیگ سفارشی استفاده کنیدشما میتونین چیزایی مثل «تعداد نتایج در هر صفحه» رو تو فایلای کانفیگ ذخیره کنید. اما ذخیره این موارد تو فایل کانفیگ app روش خوبی نیست.فایل‌های کانفیگ مخصوص خودتونو بسازید. مثلا من تو پروژه‌های فروشگاه اینترنتی، از فایل config/shop.php استفاده میکنم.۲۷) کنترلرهاتون رو بهتر آدرس‌دهی کنیدبه جای نوشتن اکشن‌های کنترلر به صورت PostController@index، از سینتکس آرایه‌ای اون استفاده کنید که به این شکله: [PostController::class, &#39;index&#39;].در این حالت، میتونین تو IDE با کلیک روی نام کلاس، فایل کلاس مورد نظرتونو باز کنید.? با IDE خودتون دوست باشید!افزونه نصب کنید، یادداشت نویسی کنید، از type hint استفاده کنید. IDE شما بهتون کمک میکنه کدتون درست کار کنه تا شما بتونین انرژی بیشتری رو برای نوشتن کدهای خوانا صرف کنید.۲۸) از کنترلرهای یک اکشنی استفاده کنیداگه برای یه route اکشن پیچیده‌ای دارید، بهتره یه کنترلر جداگانه براش بسازین.مثلا میتونین به جای OrderController::create، کلاس CreateOrderController رو بسازین.راه حل دیگه هم انتقال اون منطق به یه action class هستش. چیزی که تو اون مورد بهتر جوابگو هست رو انجام بدین.خب، این بخش هم به پایان رسید و به زودی بخش چهارم و پایانی این مقاله رو منتشر میکنم.اگه نوشته منو دوست داشتید و نکات براتون مفید بوده، لطفا لایک، ارسال نظر و به اشتراک گذاری با دیگران فراموش نشه ?.منو تو ویرگول، اینستاگرام، توئیتر و لینکدین میتونین دنبال کنین. مخصوصا اینستاگرام رو حتما چک کنید. چون اونجا هم نکات خوبی رو به اشتراک میذارم.? لینک سایر بخش‌ها? کثیف ننویس! (بخش اول)? کثیف ننویس! (بخش دوم)? کثیف ننویس! (بخش چهارم)</description><category>امیر ضیاءپور</category><author>امیر ضیاءپور</author><pubDate>Sat, 27 Jun 2020 17:57:49 +0430</pubDate></item><item><title>کثیف ننویس! (بخش دوم)</title><link>https://virgool.ir/@amirzpr/کثیف-ننویس-بخش-دوم-y9sladarsjhf</link><description>سلام دوستان. من امیر ضیاپور هستم. در بخش اول این نوشته، ۸ مورد از نکاتی که باعث میشه کدهای تمیزتری بنویسید رو با هم بررسی کردیم و در این بخش هم قراره ۱۰ مورد دیگه رو بررسی کنیم. مقدمه و توضیحات لازم رو در قسمت قبل نوشتم. اگه نخوندین، حتما یه سر بهش بزنید تا بدونید اوضاع از چه قراره. اگر هم خوندین که بدون معطلی میریم سر اصل مطلب.? یادآورینکات و مثال‌ها با محوریت فریمورک لاراول هستن. اما اغلب به طور کلی اشاره شده و تقریبا برای تمام زبان‌های برنامه‌نویسی شی محور قابل استفادست.کدهای کثیف رو حتما با دستکش refactor کنید ?۹) از event استفاده کنیددر نظر داشته باشید که بخشی از منطق پیاده سازی شده در کدتون رو از کنترلرها به eventها منتقل کنید. یه مثال از این مورد، زمانیه که میخواین مدل‌ها رو بسازین.خوبی این روش اینه که دیگه مدلتون تو همه جا (کنترلر، job و ...) به یه شکل کار میکنه و کنترلرتون درگیر جزئیات ساختار دیتابیس نمیشه.۱۰) متُد استخراج کنیداگه یکی از متدهاتون خیلی طولانی و پیچیده شد و احساس کردید که درک اتفاقی که داره می‌افته مشکل شده، بهتره که کدتون رو به چند متد مجزا انتقال بدید (استخراج کنید) و با نامگذاری مناسب، درک منطق کدتون رو ساده کنید. ۱۱) توابع کمکی (helper function) بسازیداگه از یه قطعه کد زیاد استفاده میکنید، با استخراجش به عنوان یه تابع کمکی، کدتون تمیزتر میشه.توابع view ،auth و request نمونه‌هایی از توابع کمکی هستند که در فریمورک لاراول به طور پیش فرض قرار داده شدن. ۱۲) از کلاس‌های کمکی (helper classes) پرهیز کنیدگاهی پیش میاد که بعضیا helperها به صورت کلاس مینویسن.دقت کنید که این یه کلاسه که فقط متدهای استاتیک داره که ازشون به عنوان تابع کمکی استفاده میشه و میتونه کدتونو شلوغ و به هم ریخته کنه.پس بهتره که این متدها رو به کلاس‌هایی که منطق مربوط بهشون در اون وجود داره منتقل کنید یا اینکه به صورت global function درشون بیارید.۱۳) یکی از تعطیلات آخر هفته رو به یادگیری صحیح OOP اختصاص بدینتفاوت بین متدهای استاتیک و instance method ها، و متغیرهای private و protected و public رو یاد بگیرید. علاوه بر این‌ها، نحوه کار متدهای جادویی (magic methods) در لاراول رو بررسی کنید.دونستن این نکات در شروع کار شاید لازم نباشه، اما با گسترش کدهاتون، تبدیل به ضروریات میشه.۱۴) تو کلاس‌ها، procedural code ننویسیداین نکته، مورد قبلی رو با بقیه نکاتی که گفته شد، پیوند میده. برنامه نویسی شی گرا (OOP) به وجود اومده تا کدها خواناتر باشن. پس، از قابلیت‌هاش استفاده کنید و ۴۰۰ خط کد procedural توی متدهای کنترلرهاتون ننویسید!عکس زیر رو به عنوان آیینه عبرت ببینید و سعی کنید که کدهاتون هرگز این شکلی نشه. ?? در مورد اصول SOLID از جمله SRP مطالعه کنید و تا حد معقول از اون‌ها پیروی کنید. از داشتن کلاس‌هایی که کارهای زیادی رو بدون اینکه به هم ربط خاصی هم داشته باشن، انجام میدن اجتناب کنید. اما محض رضای خدا، خواهشاً برای هر چیز کوچیک یه کلاس نسازید! با نشستن و جدا کردن همه چیز از هم، الزاماً کدتون تمیزتر و بهتر نمیشه!? وقتی می‌بینید که یک تابع پارامترهای زیادی داره، به این معناست که:۱. این تابع مسئولیت‌های زیادی داره؛ پس طبق SRP عمل کنید.۲. مسئولیت‌هاش کمه و از این لحاظ مشکلی نیست، اما نیاز به ریفکتور (refactor) داره.? دو نکته بعدی (۱۵ و ۱۶)، تکنیک‌هایی برای انجام مورد دوم هستند.۱۵) از Data Transfer Object استفاده کنیدبه جای پاس دادن آرگومان‌های فراوان با ترتیب مشخص به تابع، یه آبجکت که پراپرتی‌های مورد نظر رو داره ایجاد کنید و داده‌ها رو در اون ذخیره کنید.۱۶) آبجکت‌های fluent بسازیداگه آبجکت‌هایی بسازید که API سلیسی دارند (اصطلاحا fluent API)، میتونین داده‌ها رو از طریق فراخوانی متدهای مجزا به آبجکت نسبت بدین (method chaining). در این حالت، تو constructor فقط حداقل موارد رو برای ایجاد آبجکت لازم دارین. هر متد هم this$ رو برمی‌گردونه، به خاطر همین، در هر نقطه‌ای که دوست داشته باشید میتونین زنجیره فراخوانی متدها رو قطع کنید.۱۷) از کالکشن‌های سفارشی استفاده کنیدساختن کالکشن‌های سفارشی، یه راه عالی برای دستیابی به سینتکس رساتر و گویاتره. این مثال در مورد جمع مبلغ سفارش رو در نظر بگیرید:۱۸) از مخفف‌ها استفاده نکنیداینطور تصور نکنید که اگه اسم متغیر یا متد طولانی باشه، مشکلی وجود داره. نه اینطور نیست؛ بلکه گویاتره. این که یه متد رو با اسم طولانیش صدا بزنید بهتره تا این که بخواین doc-block رو چک کنین که بفهمین قراره چیکار کنه.در مورد متغیرها هم همینطوره. از مخفف‌های ۳ حرفی بی معنی استفاده نکنید.بخش دوم رو هم با این ۱۰ نکته کاربردی به پایان میرسونم. ۲ بخش دیگه هم باقی مونده و اگه تا اینجا نکات رو دوست داشتید و بهتون کمک کرده، حتما ? من رو دنبال کنید و طی روزهای آینده منتظر انتشارشون باشید.اگه نوشته‌های منو دوست داشتید و براتون مفید بوده، با لایک کردن نوشته و ارسال نظر دلگرمم کنید تا انتشار چنین مطالبی رو ادامه بدم.معرفی و فرستادن نوشته برای دوستاتون هم فراموش نشه لطفا! ?? لینک سایر بخش‌ها? کثیف ننویس! (بخش اول)? کثیف ننویس! (بخش سوم)? کثیف ننویس! (بخش چهارم)</description><category>امیر ضیاءپور</category><author>امیر ضیاءپور</author><pubDate>Sat, 20 Jun 2020 13:19:54 +0430</pubDate></item><item><title>کثیف ننویس! (بخش اول)</title><link>https://virgool.ir/@amirzpr/کثیف-ننویس-بخش-اول-ynps8gvrw9xc</link><description>امروز صبح که از خواب بیدار شدم، طبق عادت همیشگی موبایلم رو برداشتم و یه چرخی تو اینستاگرام و توئیتر زدم. از اونجا که من در توئیتر به زبان انگلیسی فعال هستم و بیشتر، برنامه‌نویس‌ها رو دنبال میکنم، دیدم که taylorotwell@ (سازنده فریمورک لاراول) توئیتی از samuelstancl@ رو ریتوئیت کرده و کامنتی با این ترجمه براش نوشته: «صادقانه بگم که تقریبا همه نکاتی که در این رشته توئیت گفته شده خیلی خوبه و چیزایی هستن که خودم در برنامه‌هام انجامشون دادم. آفرین.»تصویر توئیت Taylor Otwell طبیعتاً اگه برنامه‌نویس PHP باشی و عاشق Laravel، نمیتونی از چیزی که Taylor Otwell اینطور ازش تعریف کرده به راحتی بگذری! در حالیکه حتی چشمام کامل باز نمیشدن، توئیت‌ها رو خوندم و با وجود اینکه بیشترش برام حکم یادآوری رو داشت، ولی واقعا نکات ارزشمندی بودن و میدونم که میتونه به خیلیا کمک کنه. بنابراین تصمیم گرفتم این نکات کاربردی رو به عنوان اولین پستم تو ویرگول باهاتون به اشتراک بذارم تا همه با هم تمیزتر کد بزنیم ☺.۲ نکته مهم در ابتدای کار:۱) نکات و نمونه کدها با محوریت فریمورک لاراوله اما اکثرشون مربوط به اصول کدنویسی تمیزه (Clean Code). به خاطر همین، قطعا برای افرادی که با PHP و لاراول آشنا هستن ملموس‌تره، اما برای کسانی هم که با سایر زبان‌های شی‌گرا کار میکنن و مخصوصاً با معماری MVC آشنا هستن میتونه سودمند باشه.۲) این مبحث به چند بخش (حداقل ۳ بخش) تقسیم میشه تا متن هر بخش خیلی طولانی نشه و حوصله کنید تمام نکات رو بخونید. چون واقعا ارزشمندن و شما رو به توسعه دهنده بهتری تبدیل میکنن. پس اگه این نوشته رو دوست داشتید، ? من ? رو دنبال کنید تا قسمت‌های بعدی رو از دست ندید.۱) از lookup table استفاده کنیدبه جای نوشتن else if های مکرر، از یه آرایه برای پیدا کردن مقدار مد نظرتون بر اساس کلیدی که دارید، استفاده کنید. اینطوری کدتون تمیزتر و خواناتر میشه و اگه مشکلی پیش بیاد، exceptionهاتون قابل فهم هستن و چیزی از زیر دستتون در نمیره!۲) زود برگردونیدبا برگردوندن زودهنگام یک مقدار در تابع، از nesting غیرضروری جلوگیری کنید.زیاده روی در استفاده از else و nesting (بلوک‌های تودرتوی کد)، خوندن کد رو سخت‌تر میکنه. تلاش کنید که بیش از یک سطح indentation در توابعتون نداشته باشید.۳) خطوط رو درست بشکنیدخطوط کدتون رو در جاهای تصادفی نشکنید (استفاده از line break منظورمه)، اما نذارید خیلی هم طولانی بشن.باز کردن یک آرایه با ` ] ` و حاشیه دادن (indent) به مقادیرش در خطوط بعدی میتونه جوابگو باشه. همین کارو با آرگومان‌های طویل توابع هم میتونید انجام بدین.صدا زدن توابع به صورت زنجیره‌ای (chained calls) و closureها هم نمونه مناسبی از مواردی هستن که میتونیم خطوط رو بشکنیم.&#xA;۴) بیهوده متغیر نسازیدمواقعی که میتونید مستقیماً مقدار رو پاس بدین، متغیر اضافی نسازید.۵) متغیرها رو زمانی که باعث افزایش خوانایی میشن، بسازیدبرخلاف نکته قبلی، بعضی اوقات مقادیر، حاصل فراخوانی توابع پیچیده هستن و در نتیجه، ایجاد یک متغیر باعث افزایش خوانایی کد و رفع نیازمند بودن به کامنت میشه.یادتون باشه که همیشه context مهمه و هدف نهایی خوانا بودن کدتونه. ۶) برای business logic در مدل مربوطه متد بسازیدـ business logic در واقع حاوی منطق اصلی برنامه بوده و وظیفه ارتباط بین presentation layer و data layer رو بر عهده داره.کنترلرهای شما باید ساده باشن و توشون چیزایی مثل &#34;create invoice for order&#34; نوشته بشه. نباید اونا رو با چیزایی مثل جزئیات ساختار دیتابیس درگیر کنید. این کارو به مدل بسپارید.۷) کلاس‌های Action بسازیدبیاین مثال قبلی رو گسترش بدیم. بعضی اوقات، ساختن یک کلاس برای تنها یک عمل (action class) میتونه کدتون رو تمیزتر کنه.درسته که مدل‌ها باید business logic مربوط به خودشون رو دربر داشته باشن، اما نباید خیلی هم بزرگ باشن.۸) از form request استفاده کنیدمواقعی که فرایند validation پیچیده‌تر میشه، میتونین یه form request بسازین. فرم ریکوئست‌ها در واقع request classهای سفارشی‌ای هستن که منطق validation رو شامل میشن. برای ساخت یه کلاس form request میتونین از دستور زیر استفاده کنین:php artisan make:request class_nameدقت کنین که این کلاس‌ها جای خوبی برای مخفی کردن validation logicهای پیچیده هستن و اگه validation logic ساده‌ای دارین، هیچ مشکلی در استفاده مستقیم از اون در کنترلر وجود نداره.&#xA;برای بخش اول، همین ۸ مورد فکر میکنم کافی باشه. الان وقتشه که یه سر به کدهاتون بزنید و ببینید چقدر این موارد رو توش رعایت کردید! ? سعی کردم علاوه بر ترجمه، اگر جایی گنگ بوده، با اضافه کردن دانسته‌های خودم، به درک بیشتر مطلب کمک کنم. امیدوارم که براتون مفید واقع شده باشه. اگه اینطور بوده، خوشحال میشم که منو در ویرگول، اینستاگرام و توئیتر دنبال کنید.به اشتراک گذاری با دوستان و همکارانتون هم فراموش نشه لطفا! قطعا هر چه اونا تمیزتر کد بزنن، کار شما هم راحت‌تر میشه! ?اگه سوالی داشتین، کامنت بذارین، حتماً جواب میدم. ❤? لینک بخش‌های بعدی? کثیف ننویس! (بخش دوم)? کثیف ننویس! (بخش سوم)? کثیف ننویس! (بخش چهارم)</description><category>امیر ضیاءپور</category><author>امیر ضیاءپور</author><pubDate>Wed, 17 Jun 2020 21:03:13 +0430</pubDate></item></channel></rss>