ایجاد هماهنگی بین چند تیم
با افزایش تعداد اعضای تیم‌های توسعه ابعاد استفاده از اسکرام افزایش نمی‌یابد بلکه باید تعداد تیم‌هایی که اندازه مناسبی دارند افزایش یابد. داشتن بیش از یک تیم چالش هماهنگی ایجاد میکند که دو رویکرد برا آن داریم «اسکرام اسکرام‌ها» و «قطار انتشار»

اسکرام اسکرام‌ها
در اسکرام روزانه اعضای تیم حضور دارند. یکی از روش‌های متداول هماهنگی بین چند تیم اسکرام اسکرام‌ها (SoS) این است که از هر تیم یکنفر نماینده که میتواند با بقیه ارتباط گرفتن و کارها را گزارش دهد در جلسه SoS حضور یابد (بهتر است این نفر ثابت باشد)، در برخی تیم‌ها استاد مشترک چندتیم را هم به همراه نماینده می‌فرستند اما مراقب هستند تعداد زیاد نشود تعیین استاد اسکرام اسکرام‌ها هم بسیار منطقی است. جلسات مربوط به ان چند روز در هفته برگذار میشود نه هر روزه و نحوه برگذاری آن هم رویکردهای خاص خودش را دارد اما سوالات زیر مطرح است

\-تیم‌ من از آخرین جلسه قبلی چه کاری انجام داده است که ممکن است تیم‌های دیگر را تحت تاثیر قرار دهد؟ \-تیم‌ من تا جلسه بعدی چه کاری انجام می‌دهد که احتمالا تیم‌های دیگر را تحت تاثیر قرار می‌دهد؟ \-تیم‌ من چه مشکلاتی دارد و برای حل آنها ممکن است به کمک تیم‌های دیگر نیاز داشته باشد؟

جلسات آن ۱۵ دقیقه است و بحث در خصوص مسایل را بعد از ان انجام می‌دهند تا افراد علاقمند و مورد نیاز حضور داشته باشند. اگر گروه‌های مختلف در اسکرام اسکرام را خوشه بندی کنیم.

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

\-تاریخ‌های برنامه ریزی و تاریخ انتشارهای متناوب و دوره‌ای راهکار تعیین شده باشند \-مدت تکرار در تیم‌ها یکسان است \-مایلستونهای میانی و کلی با هدفی تعیین شده باشند \-یکپارچه سازی علاوه در سطح ویژگی و مولفه، در سطح کلان یا سیستم نیز انجام شود \-بخش‌های قابل انتشار که به آن PSI گفته میشود در فواصل زمانی ۳ یا ۴ ماه جهت نمایش برای مشتری، تضمین کیفیت در سطح سیستم و بازنگری داخلی آماده باشند \-از تکرار تثبیت جهت کاهش بدهی فنی و اختصاص زمان برای ازمون و اعتبارسنجی خاصی در انتشار استفاده شود \-جهت کار تیم‌ها در بستری یکسان مولفه‌های زیرساختی مشخصی همچو رابط‌ها، بسته‌های توسعه سیستم، ابزارهای نصب و محوزدهی، تحربه کاربر و خدمات پایه اینترنتی در دستور کار قرار گیرند

قطار انتشار شامل سبد محصول و سطوح انتشار می‌شود که دارای سه سطح است: بک لاگ سبد محصول(اپیک‌هایی که مالکیت آن با مدیریت آن است)، بک لاگ برنامه(ویژگی‌هایی که مالکیت آن با مدیرت آن است)، بک لاک تیم(داستان‌های کاربر قابل انجام در یک اسپرینت که با ماک محصول است)می‌باشد تصویر اول در کامنت
۹ تیم در قالب ۳ خوشه که با اسکرام اسکرام‌ها پیش می‌روند.در هر زمان ممکن باید ازمون و یکپارچه سازی سیستم به نحوی انجام شود که همه ویژگی‌های ویژگی را در بر بگیرد. مدت اسپرینت برای تمام تیم‌ها یکسان است که موجب ایجاد هماهنگی در تمامی تیم‌ها میشود. هر PSI (هر انتشار بعد از تعداد معینی اسپرینت که معمولا ۴ اسپرینت است) آماده می‌شود. این زمان بندی به سازمان کمک می‌کند هماهنگی اتی خود را انجام دهد که در زمان تعیین شده انتشار میتواند:

\-تصمیم گیری بر اساس منافع کسب و کار جهت استقرار PSI \-فرصت برای تایید صحت یکپارچگی و آزمون کارهای گروه‌های مختلف \-درخواست بازنگری داخلی

را داشته باشد

هر قطار انتشار با برگزاری جلسه برنامه ریزی انتشار آغاز می‌شود که همه تیم‌هایی که روی PSI کار می‌کنند در ان حاضرند.

در یک اتاق بزرگ مالک ارشد PSI را ارائه داده و هر تیم کنار هم نشسته و تیم‌هایی که در یک گروه ویژگی قرار دارند نزدیک هم می‌نشینند تیم‌های حاضر در یک گروه دور هم جمع شده و مالکان آنها تصویر مربوط به به خود برای انتشار بعدی را ارائه می‌دهند و تیم‌ها نگاشت اسپرینت (قراردادن ویژگی‌ها در اسپرینت‌ها) می‌کنند جهت هماهنگی بیشتر هرزگاهی یکی از اعضای تیم به تیم‌های دیگر رفته و از انها میپرسد آیا میتوانند این ویژگی را در همین قطار انتشار انجام دهند و با دریافت تایید تیم متعهد به انجام آن می‌شود. جهت اطمینان از درک بیشتر قطار انتشار مالک ارشد، مالکان گروه ویژگی و معماران به میان تیم‌های دیگر می‌روند البته تیم‌ها نیز می‌توانند درخواست کمک از آنها را ارائه دهند. پس از پایان اسپرینت‌ها به نقطه انتشار PSI می‌رسیم. در این نقطه فعالیت بازرسی و تطبیق در سطح قطار انتشار را انجام می‌دهیم اولین فعالیت بازبینی کل بار قطار انتشار و دومی بازاندیشی در سطح قطار انتشار است

#scrum

@code_crafters

ساختارهای تیم اسکرام

مرور
اگر در حال توسعه یک پروژه کوچک هستید فقط کافیست تیم چندتخصصی به همراه یک مالک و استاد داشته باشید. اما کار بر روی پروژه‌های بزرگ و سازمان‌ها با نیروی زیاد نیاز به ایجاد هماهنگی بین تیم‌ها دارد چونکه کار اشتراک صورت میگیرد. نحوه سازماندهی این تیم‌ها که کارایی بالایی داشته باشند رو با در نظر گرفتن چند عامل پاسخ می‌دهیم. اول اینکه از بین تیم‌های ویژگی محور یا مولفه محور کدام یک برای شما مناسب است دوم اینکه برای هماهنگ کردن فعالیت‌های بین چند تیم از چه رویکردهایی میتوانید استفاده کنید

مقایسه تیم‌های ویژگی محور با مولفه محور
تیم ویژگی محور تیمی چندتخصصی و چند مولفه‌ای است که می‌تواند ویژگی‌ها را از یک‌لاگ برداشته و تکمیل نماید، در حالیکه تیم مولفه محور مسئول توسعه یک مولفه یا زیرسیستم است و فقط می‌تواند قسمتی از ویژگی درخواستی و نه همه آن را تکمیل نماید.
به تیم‌های مولفه محور، تیم‌های دارایی محور یا تیم‌های زیرسیستم هم گفته می‌شود که از افرادی با تخصص‌های مشابه و مهارتی ویژه تشکیل شده‌اند. گزارش خود را به یک مدیر وظیفه‌ای گزارش داده و بعنوان منبعی مشترک و متمرکز برای سایر تیم‌ها کار می‌کند. نمونه این تیم‌ها واحد متمرکز «طراحی تجربه کاربر» است که رابط کاربر را برای سایر تیم‌ها طراحی می‌کند. اسکرام طرفدار تیم‌های ویژگی محور است اما سازمانها علاقه به مولفه محور دارند با این دیدگاه که یک تیم متخصص توسعه قسمت خود را برعهده گرفته و مسئولیت آن را برعهده بگیرد تا تیم چندتخصصی که ممکن است کد را بهم بزند. تصویر اول در کامنت
در این نمونه تیم ویژگی محور وجود ندارد لذا اقلام از بک‌لاگ برداشته شده و به تیم‌های مولفه محور سپرده می‌شود. تقسیم بندی توسط تیم‌های مولفه محور به صورت دسته جمعی یا احتمالا توسط یک معمار انجام می‌شود. سپس هر قلم در بک‌لاگ محصول یکی از تیم‌ها قرار میگیرد و شروع به اجرای بک‌لاگ میکنند اما تکمیل نمی‌کنند. تکمیل ان با روش اسکرام اسکرام‌ها در نهایت تکمیل می‌گرد. چنین رویکردی که یک کانال برای ورود درخواست‌های محصول به تیم‌های مولفه محور وجود داشته باشد. تجربه نشان داده است که سازمان‌ها بعد از روی زمین ماندن ویژگی پی میبرند که چنین تیم‌هایی کاربرد ندارند. تعداد نقاط شکست در تیم‌های مولفه محور به اندازه تعداد تیم‌های موجود است برخلاف آن در تیم‌های ویژگی محور یک نقطه شکست وجود دارد. در تیم‌های مولفه محور نمی‌توان زمان قطعی ارائه داد و انجام شدن یا نشدن یک ویژگی را مشخص کرد. در تیم‌های ویژگی محور خوش ترکیب باشند و به مرور زمان مالکیت مشترکی نسبت به کد پیدا کنند و بتوانند در قالب یک گروه به متولیان قابل اعتمادی برای کد تبدیل شوند، مشکلاتی از قبیل بهم‌ریختگی کد و بدهی فنی و ... برطرف خواهد شد. یکی از رویکردهای موقتی در دستیابی به تیم‌های ویژگی محور که مالکیت مشترکی بر کد داشته باشند در تصویر دوم در کامنت می‌بینید. در اینجا یک تیم ویژگی محور داریم که می‌تواند اقلام با ارزش را از بک لاگ برداشته و تکمیل نماید، مسئولیت و مدیریت جزییات برعهده این تیم است. تیم‌های مولفه محور مورد اعتماد هم‌چنان باقی می‌مانند تا به حفظ یکپارچگی مولفه‌ها کمک کنند. بک‌لاگ آن‌ها حاوی کارهای فنی است در هر یک از مولفه‌ها انجام شوند. از هر تیم مولفه محور یکنفر در تیم‌ویژگی محور حصگضور دارد. این موجب رویکرد بذرافشان و دروگر می‌شود. فرد در تیم ویژگی محور دانش خود را به تیم انتقال می‌دهد جهت مالکیت مشترک کد (بذرافشانی)، تیم مولفه محور هم تغییرات مورد نیاز تیم ویژگی محور گردآوری کرده و با همکاران خود در خصوص آن گفتگو کرده و هرکدام نیز به نوبه خود از تیم‌های دیگر گرداوری کرده‌اند. تیم مولفه محور مطمئن می‌شود که تغییرات در مولفه‌ها برای رفع نیازهای تیم‌های ویژگی محور انجام خواهد شدهماهنگ و تحت کنترل، که منجر به تغییرات به شیوه منسجم و بدون تعارض تا از یکپارچگی مفهومی آن مطمئن گردند. یکی از مشکلات در شرکتهای بزرگ برای مثال که ۵۰ تیم مولفه محور دارند در چنین مواقعی چندتیم ویژگی محور ساخته میشود و اعضای هر تیم متشکل از اعضای مولفه‌هایی است که بیشتر باهم در ارتباط هستند و جهت هماهنگی بین آن‌ها از تیم‌های چندگانه بهره میبریم، یکی دیگر از مشکلات این است که ممکن است یکی از تیم‌های مولفه محور تنها ۴ عضو داشته باشد که نمیتوانیم آنها را بشکنیم در این مواقع افراد با مهارت بالاتر استخدام میکنیم یا تعداد محصولات در حال توسعه را کاهش می‌دهیم یا اموزش مولفه به تعداد بیشتر یا بهتر از همه ارتقا سطح مالکیت مشترک کد. هیچ راه حل جامعی برای ترکیب دو تیم وجود ندارد اما بهتر است تیم ویژگی محور داشته باشیم و در کنارش تیم مولفه محور به شرط توجیه اقتصادی داشتن اما تجربه نشان داده اکثر سازمان‌ها خلاف ان را انجام می‌دهند

#scrum

@code_crafters

در مهندسی نرم افزار نوین بیشتر از هرچیزی به کار گروهی و مسئولیت تیمی اشاره شده است. یاد این بخش از سخنان ژیژک افتادم و مجدد این بخش از حرفاش رو نگاه کردم و نگاه عمیقتری به این مسئله انداختم که چرا کل تیم مسئولیت آنچه رخ می‌دهد (شکست و موفقیت) را باید بپذیرد

مدیران محترم، زمانیکه محیط رقابتی ایجاد می‌کنید آنچه ژیژک در این داستان گفته در سطح سازمان شما رخ می‌دهد
مهندسی نرم افزار نوین بدور از فلسفه و جامعه نیست بجای ایجاد محیط رقابتی، محیط مبتنی بر همکاری ایجاد کنید. در کنار تشویق و پیشرفت جایگاه فردی برای کسی که یک تنه عامل پیشرفت و پیشبرد اهداف سازمان است به همان اندازه نیرویی که به مابقی تیم جهت افزایش دانش و ایجاد محیط همکاری کمک میکند رو هم تشویق و پیشرفت جایگاه فردی بدهید با پیاده سازی چنین رفتارهایی در سطح سازمان خود به اعضا نشان دهید که در سازمان شما دسته‌های مختلفی از نیروهای برتر وجود دارد (این نظریه رو هم حتی میتوان در جامعه انسانی دید و تفاوت عمده جوامع جهان سومی و اولی بصورت بارز در تک قطبی بودن آلفای برتر و چندقطبی بودن آلفای برتر وجود دارد)
مراقب باشید که برخی از نیروهای شما از ایجاد چنین محیطی جهت منفعت شخصی سواستفاده نکنند

خودخواهی و فردطلبی را در سازمان شناسایی کنید و قاطعانه با آن برخورد کنید اجازه رشد چنین تفکراتی را ندهید و در صورت لزوم در سیاست نامه سازمانی خود قوانینی جهت مقابله با آن مشخص کنید

در صورت رخ داد هر مشکلی، یکی از اعضا رو مورد خطاب و یا مسیول نبینید بلکه تیم را جمع کرده و در سطح تیم بررسی کنید موضوع رو

#free

@code_crafters

در DevOps، مفهوم "ناک" (NOC: Network Operations Center) به تیم یا مرکزی اشاره دارد که وظیفه نظارت، مدیریت و رفع مشکلات زیرساخت‌های شبکه و سرویس‌های یک سازمان را دارد. ناک‌ها به بررسی و پاسخ‌دهی به حوادث و رخدادهای مختلف در سیستم‌ها و شبکه‌ها می‌پردازند تا اطمینان حاصل شود که سرویس‌ها به درستی کار می‌کنند و در صورت بروز هرگونه مشکل، سریعاً حل می‌شوند.

درجه‌بندی ناک‌ها در دواپس به سطح خدمات و مهارت‌های فنی تیم‌های ناک بستگی دارد. برخی از سطوح و تقسیم‌بندی‌های معمول عبارتند از:
1. ناک سطح 1 (L1 یا Frontline Support):
- این تیم اولین نقطه تماس برای مشکلات گزارش‌شده است.
- وظایف اصلی این سطح شامل نظارت بر سیستم‌ها و شبکه، بررسی اولیه مشکلات، و حل مسائل ساده و روزمره است.
- معمولاً مشکلاتی مانند ری‌استارت سرویس‌ها، بررسی لاگ‌های پایه، یا پیکربندی‌های ابتدایی در این سطح حل می‌شوند.
- اگر مشکلی در این سطح حل نشود، به سطح بعدی منتقل می‌شود.

2. ناک سطح 2 (L2 یا Advanced Support):
- این سطح با تخصص بیشتری در ارتباط با مشکلات فنی درگیر است.
- مشکلات پیچیده‌تر که نیاز به تجزیه و تحلیل بیشتر دارند (مانند بررسی عمقی لاگ‌ها، کار با ابزارهای پیشرفته‌تری مانند مانیتورینگ‌های پیچیده‌تر) به این تیم ارجاع داده می‌شود.
-در L2 همچنین ممکن است با مسائل زیرساختی یا تنظیمات شبکه‌ای پیچیده‌تر مانند مشکلات سرورهای مجازی یا کلاسترهای Kubernetes سر و کار داشته باشد.
- در صورت عدم توانایی حل مشکل در این سطح، مشکل به L3 ارجاع می‌شود.
3. ناک سطح 3 (L3 یا Expert Support):
- این تیم از متخصصان بسیار ماهر و دارای تجربه‌های پیشرفته در زمینه دواپس و شبکه تشکیل شده است.
- مشکلاتی که در سطوح پایین‌تر حل نشده‌اند یا نیاز به تغییرات ساختاری، تنظیمات بسیار پیچیده و یا کدنویسی دارند، در این سطح رسیدگی می‌شوند.
- تیم‌های L3 ممکن است با مهندسان نرم‌افزار، توسعه‌دهندگان، یا تیم‌های معماری زیرساخت برای حل مشکلات به صورت مستقیم کار کنند.
- در این سطح، مسائل ممکن است به راهکارهای دائمی، اصلاحات سیستمی یا تغییرات در کد پایه نیاز داشته باشند.

4. ناک سطح 4 (L4 یا External Vendor Support):
- در برخی موارد نادر، مشکلات ممکن است خارج از کنترل داخلی سازمان باشد و نیاز به همکاری با تأمین‌کنندگان خارجی (مانند سرویس‌دهندگان ابری یا تولیدکنندگان نرم‌افزار) داشته باشد.
- این سطح به مواردی می‌پردازد که نیاز به پشتیبانی فنی از سوی شرکت‌های تأمین‌کننده یا شرکای تجاری دارند.

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

#devops
#k8s

@code_crafters

#خلیج_فارس❌
#خلیج_همیشه_فارس✅

در پروژه‌های نرم‌افزاری، مدیریت و نگهداری کد منبع یکی از بخش‌های مهم توسعه هستش، ما از ابزارهای متعددی برای این منظور استفاده می‌کنیم، مثه GitLab، Bitbucket و GitHub. این پلتفرم‌ها با فراهم کردن قابلیت همکاری و اشتراک‌گذاری کد، به توسعه‌دهندگان این امکان رو‌ میدن تا به راحتی تغییرات در کد رو مدیریت و دنبال کنه. اما هسته اصلی تمام این ابزارها، Git هستش که در اکثر سازمان‌ها به عنوان استاندارد مدیریت نسخه مورد استفاده قرار می‌گیره (هرچند هنوز روش‌هایی مثل زیپ کردن کد منبع هم در برخی تیم‌ها دیده می‌شود?)

یکی از مهم‌ترین مواردی که در کار با Git باید رعایت کنیم، نگارش صحیح کامیت‌ هستش(اینکه چه تعداد کامیت زده بشه، مورد اختلاف علما هستش) اما کیفیت و شیوه نوشتن متن کامیت بسیار مهم هستش. یک کامیت خوب باید به گونه‌ای باشه که سایر اعضای تیم بتونن به راحتی متوجه بشن چه تغییری انجام شده و دلیلش چیه. به همین منظور، یک ساختار استاندارد برای نوشتن کامیت‌ پیشنهاد شده که به ما کمک می‌کنه متن‌های کامیت واضح و مفهومی باشند

دسته‌بندی کامیت‌ها
کامیت‌ها رو می‌تونیم به ۹ دسته اصلی تقسیم کرد:

1. feat: افزودن یک ویژگی جدید به کد 2. fix: رفع یک مشکل یا باگ 3. docs: تغییرات مرتبط با مستندات 4. style: تغییرات فرمت‌بندی که تأثیری بر عملکرد یا معنای کد ندارند (مانند فاصله‌گذاری یا استفاده از نقطه‌ویرگول) 5. refactor: تغییرات در ساختار کد بدون تغییر در عملکرد یا رفع باگ 6. perf: تغییراتی که به بهبود عملکرد منجر می‌شوند 7. test: اضافه یا تغییر تست‌های نرم‌افزار 8. chore: تغییرات مرتبط با ابزارها، کتابخانه‌ها یا فرایندهای پشتیبان (مثل تنظیمات build) 9. ci: تغییرات مربوط به سیستم‌های یکپارچه‌سازی مداوم و استقرار

بیایید چندتا مثال بزنیم
۱. افزودن ویژگی‌های جدید
- افزودن یک قابلیت جدید به سیستم ثبت‌نام:

feat(auth): add user registration with email verification

- اضافه کردن پنل ادمین جدید:

feat(admin): add dashboard for managing users and orders

1. رفع باگ‌ها
   - رفع مشکل ورود کاربران:

fix(auth): fix login issue with incorrect password handling

- رفع خطای محاسبه مالیات در فاکتورها:

fix(invoice): correct tax calculation in final price

1. مستندسازی
   - اضافه کردن راهنمای نصب برای پروژه:

docs: add installation guide for new developers

- به‌روزرسانی README:

docs: update README with new API endpoints

1. تغییرات فرمت و سبک کد
   - بهبود خوانایی کد:

style: format code according to eslint rules

- استفاده از کاما در جای درست:

style: add missing commas in product component

1. بازسازی و بازنویسی کد
   - بازنویسی یک تابع بزرگ برای ساده‌تر شدن:

refactor(cart): split calculateTotal function into smaller functions

- بهینه‌سازی ساختار پروژه:

```
refactor(folder-structure): reorganize components and services folders

```

1. بهبود کارایی
   - بهینه‌سازی عملکرد کوئری‌های دیتابیس:

```
perf(database): optimize query for retrieving large datasets

```

- کاهش زمان بارگذاری صفحات:

```
perf(page-load): lazy load images to improve page load time

```

1. تست‌ها
   - اضافه کردن تست‌های جدید برای تابع جستجو:

```
test(search): add unit tests for search functionality

```

- به‌روزرسانی تست‌های قدیمی:

```
test(cart): update tests to reflect changes in cart logic

```

1. تغییرات جانبی و ابزارها
   - به‌روزرسانی پکیج‌های pip:

```
chore(deps): update pip packages to latest versions

```

- تنظیم محیط توسعه برای استفاده از Docker:

```
chore(docker): add Dockerfile for local development

```

1. یکپارچه‌سازی مداوم (CI)
   - افزودن یک اسکریپت CI برای ساخت اتوماتیک پروژه:

```
ci: add CI script for automated builds

```

- رفع خطای پیکربندی در pipeline:

fix(ci): fix incorrect variable in CI pipeline

نکات مهم:
1. وضوح و شفافیت: پیام کامیت باید به وضوح تغییرات ایجاد شده را بیان کند. از عبارات گنگ یا نامفهوم پرهیز کنید
2. سازگاری با استانداردها: استفاده از کلمات کلیدی مانند feat، fix و... برای دسته‌بندی کامیت‌ها، کمک می‌کند تا تاریخچه تغییرات پروژه ساختاریافته و قابل پیگیری باشد
3. توضیحات کوتاه اما مفید: در پیام کامیت به‌خصوص در خط اول، تلاش کنید مختصر و مفید تغییرات را بیان کنید. در صورت نیاز، توضیحات اضافی می‌تواند در خطوط بعدی پیام کامیت اضافه شود

#git
#gitlab

@code_crafters

1. بهینه‌سازی طراحی پایگاه داده
   بهینه‌سازی طراحی پایگاه داده نیز می‌تواند عملکرد کوئری را بهبود بخشد. این شامل اطمینان از نرمال‌سازی صحیح جداول و استفاده مؤثر از ایندکس‌ها است. علاوه بر این، مهم است که پایگاه داده برای بار کاری مورد انتظار به درستی تنظیم شود و برای سطح مناسب همزمانی (Concurrency) پیکربندی شود.

2. استفاده از ابزارهای بهینه‌سازی کوئری
   انواع مختلفی از ابزارهای بهینه‌سازی کوئری موجود هستند که می‌توانند به شناسایی مشکلات عملکرد در کوئری‌های SQL کمک کنند. این ابزارها می‌توانند توصیه‌هایی برای بهبود عملکرد کوئری‌ها ارائه دهند، مانند ایجاد ایندکس‌ها، بازنویسی کوئری‌ها یا بهینه‌سازی طراحی پایگاه داده. برخی از ابزارهای محبوب بهینه‌سازی کوئری شامل Microsoft SQL Server Query Optimizer، Oracle SQL Developer و MySQL Query Optimizer هستند.

3. مانیتورینگ عملکرد کوئری
   مانیتورینگ عملکرد کوئری یک گام مهم در بهینه‌سازی کوئری‌های SQL است. با مانیتورینگ عملکرد کوئری، می‌توان مشکلات عملکرد را شناسایی و تنظیمات مناسب را انجام داد. این می‌تواند شامل بهینه‌سازی ایندکس‌ها، بازنویسی کوئری‌ها یا تنظیم طراحی پایگاه داده باشد. برای ردیابی عملکرد کوئری، تعدادی ابزار موجود است، از جمله SQL Server Profiler، Oracle Enterprise Manager و MySQL Enterprise Monitor.

نتیجه‌گیری

بهینه‌سازی کوئری‌های SQL برای عملکرد سریع‌تر یک گام مهم در اطمینان از اجرای کارآمد برنامه‌های پایگاه داده است. از طریق این مقاله، می‌توانیم به نکات زیر برسیم:

- ایندکس‌گذاری مؤثرترین تکنیک برای افزایش عملکرد کوئری‌های SQL است، اما باید ملاحظات بین عملکرد خواندن و نوشتن را در نظر گرفت و تصمیم‌گیری کرد که کدام ستون‌ها باید ایندکس شوند و کدام نوع ایندکس‌ها باید استفاده شوند.(ایندکس ها مثل چاقو دو لبه هستند اگر اشتباه استفاده شوند میتوانند موجب سربار شوند اعمال کردن آنها به درستی نیاز به کمی تخصص دارد )
- بهینه‌سازی کوئری‌های SQL یک فرآیند پیوسته است و نیاز به مانیتورینگ و تنظیمات منظم برای اطمینان از بهبود مداوم عملکرد دارد.
- باید استفاده از عملیات هزینه‌بر مانند JOIN، GROUP BY، IN و زیرکوئری‌ها را به حداقل رساند تا عملکرد بهبود یابد.
- کوئری‌ها را بر روی مجموعه‌های داده واقعی آزمایش کنید تا اطمینان حاصل شود که بهینه‌سازی‌ها تأثیر مطلوبی دارند.

منبع

#SQL
@Code_Crafters

1. استفاده از EXISTS به جای IN
   عبارت IN یک مقدار را با لیستی از مقادیر بازگشتی از یک زیرکوئری مقایسه می‌کند. با این حال، استفاده از IN می‌تواند عملکرد کوئری را کند کند زیرا نیازمند اسکن کامل جدول بر روی زیرکوئری است. برای بهینه‌سازی کوئری‌های SQL، می‌توان از EXISTS به جای IN استفاده کرد.

به عنوان مثال، برای یافتن تمامی مشتریانی که در 30 روز گذشته سفارشی ثبت کرده‌اند:

SELECT * FROM customers WHERE customer\_id IN (SELECT customer\_id FROM orders WHERE order\_date >= DATEADD(day, \-30, GETDATE()));

این کوئری از IN برای مقایسه شناسه مشتری با لیست شناسه‌های مشتری بازگشتی از زیرکوئری

استفاده می‌کند. برای بهینه‌سازی کوئری، می‌توان از EXISTS به جای IN استفاده کرد:

SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer\_id = c.customer\_id AND o.order\_date >= DATEADD(day, \-30, GETDATE()));

این کوئری از EXISTS برای بررسی اینکه آیا ردیف مطابقی در جدول orders وجود دارد یا خیر استفاده می‌کند. این می‌تواند عملکرد کوئری را با اجتناب از اسکن کامل جدول بهبود بخشد.

1. استفاده از GROUP BY برای گروه‌بندی داده‌ها
   عبارت GROUP BY برای گروه‌بندی ردیف‌ها بر اساس یک یا چند ستون استفاده می‌شود. این می‌تواند برای خلاصه کردن داده‌ها یا انجام توابع تجمعی بر روی گروه‌های داده مفید باشد. با این حال، استفاده از GROUP BY می‌تواند عملکرد کوئری را کند کند اگر به طور غیرضروری استفاده شود. برای بهینه‌سازی کوئری‌های SQL، باید تنها زمانی که ضروری است از GROUP BY استفاده کرد.

به عنوان مثال، برای یافتن تعداد کل سفارش‌های انجام شده توسط هر مشتری:

SELECT customer\_id, COUNT(*) as order\_count FROM orders GROUP BY customer\_id;

این کوئری از GROUP BY برای گروه‌بندی ردیف‌ها بر اساس شناسه مشتری و شمارش تعداد سفارش‌های انجام شده توسط هر مشتری استفاده می‌کند. برای بهینه‌سازی کوئری، می‌توان از زیرکوئری برای بازیابی اطلاعات مشتری و پیوند آن با جدول orders استفاده کرد:

SELECT c.customer\_id, c.first\_name, c.last\_name, o.order\_count FROM customers c JOIN (SELECT customer\_id, COUNT(*) as order\_count FROM orders GROUP BY customer\_id) o ON c.customer\_id = o.customer\_id;

این کوئری از زیرکوئری برای محاسبه تعداد سفارش‌های انجام شده توسط هر مشتری استفاده می‌کند و سپس نتیجه را با جدول customers برای بازیابی اطلاعات مشتری پیوند می‌دهد. این اجتناب از استفاده از GROUP BY می‌کند و می‌تواند عملکرد کوئری را بهبود بخشد.

1. استفاده از رویه‌های ذخیره‌شده (Stored Procedures)
   رویه‌های ذخیره‌شده (Stored Procedures) دستورات SQL پیش‌کامپایل شده‌ای هستند که در پایگاه داده ذخیره می‌شوند. آن‌ها می‌توانند از یک برنامه یا مستقیماً از یک کوئری SQL فراخوانی شوند. استفاده از رویه‌های ذخیره‌شده می‌تواند عملکرد کوئری را با کاهش مقدار داده‌ای که بین پایگاه داده و برنامه ارسال می‌شود و با کاهش زمان لازم برای کامپایل و اجرای دستورات SQL بهبود بخشد.

#SQL
@Code_Crafters

یه مورد دیگه ای هم خودم اضافه کنم که به نظرم لازمه گاهی اوقات لازمه که یک همچنین کوئری بزنید که بررسی کند که یک مقداری وجود دارد یا خیر که در نوشتن پروسیجر ها بسیار مرسوم است:

```

IF EXISTS(SELECT * FROM dbo.Employee AS em WHERE em.Id = 1)
BEGIN
PRINT('exist')
RETURN;
END
PRINT('not found')
```

در حالی که شما هیچ نیازی به موارد پاس داده شده از طرف جدول ندارید
پس میتوانید کوئری خود را به این صورت اصلاح کنید که بهتر است

```

IF EXISTS(SELECT 1 FROM dbo.Employee AS em WHERE em.Id = 1)
BEGIN
PRINT('exist')
RETURN ;
END
PRINT('not found')
```

به جای عملکرد * از عدد یا حروف به شکل 'A' میتوان استفاده کرد که اگر مقداری با شرط ما پیدا کرد را برگرداند که عملکرد بهتری دارد

در این کد بخش های پرینت و شرط و.. T-SQL است و به موضوع پست مربوط نیست تنها قصدم نشان دادن کاربردی تره موضوع بود.

#SQL
@Code_Crafters

ذخیره سازی اطلاعات خام ولی در حجم بالا با Blob در PostgreSQL

در پایگاه داده PostgreSQL نوع داده‌ای به نام bytea را ارائه می‌دهد که برای ذخیره اطلاعات باینری مانند تصاویر، فایل‌های صوتی و ویدئوها ایده‌آل است. اما گاهی اوقات با داده‌های باینری خیلی بزرگتر از حد معمول سروکار داریم. در اینجاست که مفهوم BLOB یا "Binary Large Object" به کمک ما می‌آید.

تعریف BLOB چیست؟

در واقع BLOB یک نوع داده در PostgreSQL است که برای ذخیره داده‌های باینری بسیار بزرگ مانند:

1. فایل‌های چند گیگابایتی
2. مجموعه داده‌های علمی
3. تصاویر با وضوح بالا
4. فایل‌های ویدئویی با کیفیت بالا

استفاده می‌شود.

مزایای استفاده از BLOB:

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

نحوه استفاده از BLOB:

برای استفاده از BLOB در PostgreSQL، باید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE my\_table ( id INT PRIMARY KEY, data BYTEA );

1. با استفاده از دستور INSERT، داده‌های BLOB را در جدول ذخیره کنید:

INSERT INTO my\_table (id, data) VALUES (1, lo\_import('image.jpg'));

1. با استفاده از دستور SELECT، داده‌های BLOB را از جدول بازیابی کنید:

SELECT data FROM my\_table WHERE id = 1;

نکات مهم:

برای ذخیره و بازیابی BLOB ها، باید از توابع lo_import و lo_export استفاده کنید.
پایگاه داده PostgreSQL ابزارهای مختلفی برای مدیریت BLOB ها ارائه می‌دهد، مانند توابع و عملگرهای خاص.
برای اطلاعات بیشتر در مورد BLOB ها، می‌توانید به مستندات PostgreSQL مراجعه کنید.

مثال:

فرض کنید می‌خواهید یک ویدیو با حجم 2 گیگابایت را در PostgreSQL ذخیره کنید. می‌توانید مراحل زیر را انجام دهید:

1. نوع داده BLOB را در جدول خود تعریف کنید:

CREATE TABLE videos ( id INT PRIMARY KEY, title VARCHAR(255), data BYTEA );

1. با استفاده از دستور INSERT، ویدیو را در جدول ذخیره کنید:

INSERT INTO videos (id, title, data) VALUES (1, 'My Video', lo\_import('video.mp4'));

1. با استفاده از دستور SELECT، ویدیو را از جدول بازیابی کنید:

SELECT data FROM videos WHERE id = 1;

با استفاده از BLOB ها، می‌توانید هر نوع داده باینری را در PostgreSQL ذخیره کنید و به آنها دسترسی داشته باشید. این امر PostgreSQL را به یک راه حل قدرتمند برای ذخیره سازی و مدیریت داده‌های باینری تبدیل می‌کند.

در ادامه، چند نمونه دیگر از کاربردهای BLOB در PostgreSQL آورده شده است:

1. ذخیره سازی اسناد و مدارک
2. ذخیره سازی تصاویر و ویدیوها
3. ذخیره سازی فایل‌های صوتی
4. ذخیره سازی پایگاه داده‌های NoSQL
5. ذخیره سازی داده‌های رمزنگاری شده

جمع بندی:

ف BLOB ها یک ابزار قدرتمند برای ذخیره سازی داده‌های باینری در PostgreSQL هستند. با استفاده از BLOB ها، می‌توانید داده‌های حجیم را به طور کارآمد و ایمن ذخیره کنید.

#PostgreSQL
@Code_Crafters