‫‪1.

‬خوانایی کد)‪(Code Readability‬‬

‫از دستورهای شرطی با ساختار ساده و واضح استفاده شود؛ از شرطهای چندگانه پیچیده اجتناب شود‪.‬‬ ‫•‬

‫کامنتها به زبان انگلیسی نوشته شوند و کوتاه اما توصیفی باشند‪.‬‬ ‫•‬

‫فاصلهها و تورفتگیها در تمام بخشها استاندارد باشند‪.‬‬ ‫•‬

‫فایلها و پوشهها به درستی سازماندهی شدهاند و نامهایی معنادار دارند‪.‬‬ ‫•‬

‫ساختار پروژه از الگوهای استاندارد مانند ‪ MVC‬یا ‪ MTV‬پیروی کند‪ (.‬در صورت استفاده از‪) Django‬‬ ‫•‬

‫‪2.‬نامگذاری متغیرها و توابع‬

‫برای متغیرهای ‪ Boolean‬از پیشوندهای _‪has_ ،is‬یا _‪can‬استفاده شود‪.‬‬ ‫•‬

‫نام متغیرها و توابع از بهکار بردن مخففهای غیرمعمول خودداری شود‪.‬‬ ‫•‬

‫متغیرهای سراسری در سطح ماژول به درستی نامگذاری شوند و از حرف بزرگ شروع شوند‪.‬‬ ‫•‬

‫نام متغیرها و توابع باید معنادار و گویا باشند تا عملکرد آنها مشخص باشد‪.‬‬ ‫•‬

‫در نامگذاری توابع از افعال استفاده شود مثالً )(‪get_user‬به جای )(‪user_get‬‬ ‫•‬

‫‪3.‬ساختار ماژولها‬

‫نام فایلها و ماژولها کوتاه‪ ،‬اما نمایانگر عملکردشان باشند‪.‬‬ ‫•‬

‫تعداد خطوط هر فایل کمتر از ‪ 500‬خط باشد و فایلهای بسیار بزرگ به ماژولهای کوچکتر شکسته شوند‪.‬‬ ‫•‬

‫ماژولها به صورت گروهبندی منطقی در پوشههای جداگانه سازماندهی شوند‪.‬‬ ‫•‬

‫از پیادهسازی کدهای اضافی که باعث افزایش پیچیدگی میشوند‪ ،‬خودداری شود‪.‬‬ ‫•‬

‫ماژولها باید قابلیت استفاده مجدد داشته باشند و هیچکدام نباید وابستگیهای پیچیدهای به یکدیگر داشته باشند‪.‬‬ ‫•‬
 ‫‪4.‬عملکرد توابع‬

‫توابع طوالنیتر از ‪ 20‬خط به توابع کوچکتر تقسیم شوند‪.‬‬ ‫•‬

‫هر تابع یک کار مشخص انجام دهد و وظایف مختلف به توابع دیگر واگذار شود‪.‬‬ ‫•‬

‫از آرگومانهای پیشفرض برای ساده کردن توابع استفاده شود‪.‬‬ ‫•‬

‫توابع باید از هیچگونه پیچیدگی غیرضروری اجتناب کنند‪.‬‬ ‫•‬

‫از توابع کمکی برای اجتناب از تکرار کد استفاده شود‪.‬‬ ‫•‬

‫‪5.‬مدیریت استثناها‬

‫از ارثبری کالسهای خطا برای خطاهای خاص پروژه استفاده شود‪.‬‬ ‫•‬

‫در بلوکهای ‪ except‬فقط خطاهای خاصی که انتظار میروند مدیریت شوند‪.‬‬ ‫•‬

‫پیغامهای خطا شفاف و قابل فهم باشند‪.‬‬ ‫•‬

‫خطاهای بحرانی در سیستم با دقت بیشتری مدیریت شوند‪.‬‬ ‫•‬

‫از ارثبری از کالسهای خطا برای دستهبندی خطاها استفاده شود تا مدیریت آنها سادهتر باشد‪.‬‬ ‫•‬

‫‪6.‬مدیریت ورودی و خروجیها‬

‫دادههای ورودی با ابزارهایی مانند ‪ marshmallow‬یا ‪ pydantic‬اعتبارسنجی شوند‪.‬‬ ‫•‬

‫خروجیها استانداردسازی شوند و به فرمت خاصی مانند ‪ JSON‬یا ‪ XML‬برگردانده شوند‪.‬‬ ‫•‬

‫ورودیهای ناامن برای جلوگیری از حمالت تزریق )‪ (Injection‬پاکسازی شوند‪.‬‬ ‫•‬

‫از کتابخانههای معتبر برای تبدیل دادهها به فرمتهای مشخص استفاده شود‪.‬‬ ‫•‬

‫اطمینان حاصل شود که دادهها قبل از پردازش به درستی اعتبارسنجی شدهاند‪.‬‬ ‫•‬
 ‫‪7.‬اصول‪SOLID‬‬

‫از الگوی ‪ Dependency Injection‬در جایی که منطقی است استفاده شود‪.‬‬ ‫•‬

‫در اصل‪ ، Interface Segregation‬کالسها فقط توابع مورد نیازشان را استفاده کنند‪.‬‬ ‫•‬

‫از اصل ‪ Open/Closed‬برای توسعه بدون تغییر کالسهای موجود استفاده شود‪.‬‬ ‫•‬

‫کالسها و ماژولها به صورت مستقل از یکدیگر طراحی شوند‪.‬‬ ‫•‬

‫از اصل ‪ Liskov Substitution‬برای اطمینان از قابلیت تعویض کالسها استفاده شود‪.‬‬ ‫•‬

‫‪8.‬پیادهسازی‪PEP 8‬‬

‫از ابزار ‪ autopep8‬برای بهروزرسانی خودکار سبک کد استفاده شود‪.‬‬ ‫•‬

‫فضای خالی اضافی بین خطوط حذف شود‪.‬‬ ‫•‬

‫ماژولها و کالسها از ترتیب ‪ import‬مناسب پیروی کنند‪.‬‬ ‫•‬

‫نامگذاری متغیرها و توابع طبق دستورالعملهای ‪ PEP 8‬انجام شود‪.‬‬ ‫•‬

‫از فاصلهگذاری استاندارد برای جدا کردن بخشهای مختلف کد استفاده شود‪.‬‬ ‫•‬

‫‪9.‬استفاده از تایپها)‪(Type Annotations‬‬

‫تایپهای ترکیبی با استفاده از ‪ Union‬یا |مشخص شوند‪.‬‬ ‫•‬

‫از ‪Literal‬برای محدود کردن مقدارهای خاص ورودیها استفاده شود‪.‬‬ ‫•‬

‫تایپها در کدهای پیچیده مستند شوند‪.‬‬ ‫•‬

‫تایپها باید خوانا و واضح باشند تا فهم کد راحتتر شود‪.‬‬ ‫•‬

‫تایپهای مربوط به متغیرها و توابع بهطور صحیح و دقیق تعریف شوند‪.‬‬ ‫•‬
 ‫‪10.‬عملکرد)‪(Performance‬‬

‫پردازشهای تکراری با الگوریتمهای دستهای جایگزین شوند‪.‬‬ ‫•‬

‫حلقههای ‪ nested‬بیش از دو الیه حذف یا بهینه شوند‪.‬‬ ‫•‬

‫استفاده از ‪ cache‬در محاسبات پرهزینه انجام شود‪.‬‬ ‫•‬

‫کد باید بهطور منظم و مستمر برای بهینهسازی عملکرد تحلیل شود‪.‬‬ ‫•‬

‫از ساختارهای داده مناسب برای افزایش سرعت پردازش استفاده شود‪.‬‬ ‫•‬

‫‪11.‬مدیریت وابستگیها‬

‫ابزارهایی مانند ‪ poetry‬برای مدیریت نسخههای دقیقتر استفاده شود‪.‬‬ ‫•‬

‫وابستگیهای پروژه در محیط مجازی ایزوله شوند‪.‬‬ ‫•‬

‫فایلهای ضروری مانند ‪ requirements.txt‬یا ‪ pyproject.toml‬به پروژه اضافه شوند‪.‬‬ ‫•‬

‫از نصب وابستگیها از طریق ‪ pip‬و نگهداری آنها در نسخههای مشخص استفاده شود‪.‬‬ ‫•‬

‫نسخههای وابستگیها باید بهطور مستمر بررسی و بهروز شوند‪.‬‬ ‫•‬

‫‪12.‬امنیت کد‬

‫از الگوریتمهای رمزنگاری قوی مانند ‪ bcrypt‬برای هش کردن رمز عبور استفاده شود‪.‬‬ ‫•‬

‫مسیرهای حساس در ‪ API‬با احراز هویت چندعاملی ایمن شوند‪.‬‬ ‫•‬

‫کلیدهای ‪ API‬و اطالعات حساس در فایلهای محیطی )‪ (env‬ذخیره شوند‪.‬‬ ‫•‬

‫از پروتکلهای ‪ HTTPS‬برای انتقال اطالعات حساس استفاده شود‪.‬‬ ‫•‬

‫از تکنیکهای امنیتی برای جلوگیری از حمالت ‪ CSRF‬و ‪ XSS‬استفاده شود‪.‬‬ ‫•‬
 ‫‪13.‬ماژوالر بودن و استفاده مجدد‬

‫کالسهای عمومی و انتزاعی برای اشتراکگذاری منطق مشترک ایجاد شوند‪.‬‬ ‫•‬

‫ماژولهای غیرضروری به مرور زمان حذف شوند‪.‬‬ ‫•‬

‫از توابع کمکی برای اجتناب از تکرار کد استفاده شود‪.‬‬ ‫•‬

‫هر ماژول باید قابل استفاده مجدد باشد و کمترین وابستگی را به دیگر ماژولها داشته باشد‪.‬‬ ‫•‬

‫از اصول طراحی )‪ DRY (Don't Repeat Yourself‬پیروی شود‪.‬‬ ‫•‬

‫‪14.‬مدیریت پایگاه داده‬

‫از ‪ connection pooling‬برای مدیریت بهتر اتصاالت پایگاه داده استفاده شود‪.‬‬ ‫•‬

‫جداول با استفاده از‪ Index‬های مناسب بهینه شوند‪.‬‬ ‫•‬

‫از ابزارهای ‪ ORM‬مانند ‪ Django ORM‬یا ‪ SQLAlchemy‬استفاده شود‪.‬‬ ‫•‬

‫کوئریهای پیچیده باید بهینهسازی شوند تا تأثیر منفی روی عملکرد نداشته باشند‪.‬‬ ‫•‬

‫از تراکنشها برای مدیریت تغییرات دادهها بهطور امن استفاده شود‪.‬‬ ‫•‬

‫‪15.‬الگها و اشکالزدایی)‪(Logging & Debugging‬‬

‫ساختار الگها شامل شناسههای کاربری و شماره تراکنشها برای ردیابی بهتر باشد‪.‬‬ ‫•‬

‫الگهای اضافی یا غیرضروری در تولید حذف شوند‪.‬‬ ‫•‬

‫سطوح مختلف الگ مانند‪warning ، info‬و ‪ error‬به درستی استفاده شوند‪.‬‬ ‫•‬

‫الگها باید بهطور منظم بررسی و از مشکالت بالقوه آگاه شود‪.‬‬ ‫•‬

‫از ابزارهای مدیریت الگ مانند ‪ ELK stack‬یا ‪ Splunk‬استفاده شود‪.‬‬ ‫•‬
 ‫‪16.‬مستندسازی)‪(Documentation‬‬

‫مثالهایی از سناریوهای واقعی برای تست‪ API‬ها در مستندات آورده شوند‪.‬‬ ‫•‬

‫مستندات پروژه شامل تاریخچه تغییرات باشد‪.‬‬ ‫•‬

‫مستندات به زبان انگلیسی و با قالب استاندارد نوشته شوند‪.‬‬ ‫•‬

‫توضیحات دقیق برای نحوه استفاده از‪ API‬ها و بخشهای مختلف پروژه داده شود‪.‬‬ ‫•‬

‫راهنمای نصب و راهاندازی پروژه باید بهصورت واضح و کامل ارائه شود‪.‬‬ ‫•‬

‫‪17.‬محیط توسعه)‪(Development Environment‬‬

‫ابزارهایی مانند ‪ pre-commit hooks‬برای بررسی خودکار کیفیت کد پیش از ‪ commit‬استفاده شوند‪.‬‬ ‫•‬

‫تنظیمات محیط توسعه بهطور کامل در ‪ Docker Compose‬تعریف شوند‪.‬‬ ‫•‬

‫فایل ‪ .gitignore‬به درستی پیکربندی شود تا فایلهای غیرضروری وارد کنترل نسخه نشوند‪.‬‬ ‫•‬

‫محیط توسعه باید مشابه محیط تولید باشد تا اطمینان حاصل شود که کد در هر دو محیط بهدرستی اجرا میشود‪.‬‬ ‫•‬

‫وابستگیها باید در یک محیط مجازی ایزوله نگهداری شوند‪.‬‬ ‫•‬

‫‪18.‬بررسی کیفیت کد‬

‫از ابزارهای ‪ linting‬مانند ‪ flake8-bugbear‬برای پیدا کردن مشکالت خاص استفاده شود‪.‬‬ ‫•‬

‫کیفیت کد با استفاده از معیارهایی مانند ‪ Maintainability Index‬اندازهگیری شود‪.‬‬ ‫•‬

‫تستهای استاتیک کد بهصورت منظم انجام شوند‪.‬‬ ‫•‬

‫از ابزارهای تست کد مانند ‪ SonarQube‬برای بررسی کیفیت استفاده شود‪.‬‬ ‫•‬

‫معیارهای مشخصی برای بررسی کیفیت کد قبل از ‪ deploy‬تنظیم شوند‪.‬‬ ‫•‬

 ‫‪19.‬بهینهسازی و نگهداری‬

‫از ‪ Task Scheduler‬مانند ‪ Celery‬برای اجرای وظایف سنگین بهطور پسزمینه استفاده شود‪.‬‬ ‫•‬

‫پایگاه داده بهطور منظم پشتیبانگیری و بهروزرسانی شود‪.‬‬ ‫•‬

‫کد باید بهطور منظم بررسی و برای بهبودهای آینده بهینه شود‪.‬‬ ‫•‬

‫عملیاتهایی که به منابع زیادی نیاز دارند باید به شیوهای غیرمستقیم و ناهمزمان انجام شوند‪.‬‬ ‫•‬

‫هر تغییر در کد باید مستند شود تا مشکالت آینده به راحتی شناسایی شوند‬ ‫•‬

‫‪20.‬الگها و اشکالزدایی)‪(Logging & Debugging‬‬

‫ساختار الگها شامل شناسههای کاربری و شماره تراکنشها برای ردیابی بهتر باشد‪.‬‬ ‫•‬

‫الگهای اضافی یا غیرضروری در تولید حذف شوند‪.‬‬ ‫•‬

‫سطوح مختلف الگ مانند ‪warning ،info‬و ‪error‬به درستی استفاده شوند‪.‬‬ ‫•‬

‫ساختار الگها شامل شناسههای کاربری و شماره تراکنشها برای ردیابی بهتر باشد‪.‬‬ ‫•‬

‫الگهای اضافی یا غیرضروری در تولید حذف شوند‪.‬‬ ‫•‬

‫‪21.‬مستندسازی)‪(Documentation‬‬

‫مثالهایی از سناریوهای واقعی برای تست‪ API‬ها در مستندات آورده شوند‪.‬‬ ‫•‬

‫مستندات پروژه شامل تاریخچه تغییرات باشد‪.‬‬ ‫•‬

‫مستندات به زبان انگلیسی و با قالب استاندارد نوشته شوند‪.‬‬ ‫•‬

‫مثالهایی از سناریوهای واقعی برای تست‪ API‬ها در مستندات آورده شوند‪.‬‬ ‫•‬

‫مستندات پروژه شامل تاریخچه تغییرات باشد‪.‬‬ ‫•‬

 ‫‪22.‬محیط توسعه)‪(Development Environment‬‬

‫ابزارهایی مانند ‪pre-commit hooks‬برای بررسی خودکار کیفیت کد پیش از ‪ commit‬استفاده شوند‪.‬‬ ‫•‬

‫تنظیمات محیط توسعه بهطور کامل در ‪ Docker Compose‬تعریف شوند‪.‬‬ ‫•‬

‫فایل ‪.gitignore‬به درستی پیکربندی شود تا فایلهای غیرضروری وارد کنترل نسخه نشوند‪.‬‬ ‫•‬

‫ابزارهایی مانند ‪pre-commit hooks‬برای بررسی خودکار کیفیت کد پیش از ‪ commit‬استفاده شوند‪.‬‬ ‫•‬

‫تنظیمات محیط توسعه بهطور کامل در ‪ Docker Compose‬تعریف شوند‪.‬‬ ‫•‬

‫‪23.‬بررسی کیفیت کد‬

‫از ابزارهای ‪ linting‬مانند ‪flake8-bugbear‬برای پیدا کردن مشکالت خاص استفاده شود‪.‬‬ ‫•‬

‫کیفیت کد با استفاده از معیارهایی مانند ‪Maintainability Index‬اندازهگیری شود‪.‬‬ ‫•‬

‫تستهای استاتیک کد بهصورت منظم انجام شوند‪.‬‬ ‫•‬

‫از ابزارهای ‪ linting‬مانند ‪flake8-bugbear‬برای پیدا کردن مشکالت خاص استفاده شود‪.‬‬ ‫•‬

‫کیفیت کد با استفاده از معیارهایی مانند ‪Maintainability Index‬اندازهگیری شود‪.‬‬ ‫•‬

‫‪25.‬بهینهسازی و نگهداری‬

‫از ‪ Task Scheduler‬مانند ‪Celery‬برای پردازشهای زمانبر استفاده شود‪.‬‬ ‫•‬

‫فرآیندهای نگهداری کد بهصورت مرتب در اسپرینتهای توسعه برنامهریزی شوند‪.‬‬ ‫•‬

‫کدهای قدیمی و منسوخ حذف یا بازنویسی شوند‪.‬‬ ‫•‬

‫از ‪ Task Scheduler‬مانند ‪Celery‬برای پردازشهای زمانبر استفاده شود‪.‬‬ ‫•‬

‫فرآیندهای نگهداری کد بهصورت مرتب در اسپرینتهای توسعه برنامهریزی شوند‪.‬‬ ‫•‬

 ‫‪26.‬تست و تضمین کیفیت پیشرفته‬

‫از ابزارهای تست بالدرنگ مانند ‪pytest-watch‬برای اجرای خودکار تستها استفاده شود‪.‬‬ ‫•‬

‫تستهای خودکار در چندین نسخه ‪ Python‬اجرا شوند‪.‬‬ ‫•‬

‫تستهای ‪ End-to-End‬برای فرآیندهای اصلی تعریف شوند‪.‬‬ ‫•‬

‫از ابزارهای تست بالدرنگ مانند ‪pytest-watch‬برای اجرای خودکار تستها استفاده شود‪.‬‬ ‫•‬

‫تستهای خودکار در چندین نسخه ‪ Python‬اجرا شوند‪.‬‬ ‫•‬

‫‪27.‬تعامالت با ‪ API‬و سرویسهای خارجی‬

‫درخواستهای ‪ API‬با ‪Retry Policy‬مدیریت شود‪.‬‬ ‫•‬

‫پاسخهای ‪ API‬برای کش شدن مناسب تنظیم شوند‪.‬‬ ‫•‬

‫از ‪timeouts‬برای جلوگیری از قفل شدن برنامه استفاده شود‪.‬‬ ‫•‬

‫درخواستهای ‪ API‬با ‪Retry Policy‬مدیریت شود‪.‬‬ ‫•‬

‫پاسخهای ‪ API‬برای کش شدن مناسب تنظیم شوند‪.‬‬ ‫•‬

‫‪28.‬مهاجرتها و بروزرسانیها‬

‫یک فرآیند ‪Rollback‬مشخص برای مهاجرتهای ناسازگار وجود داشته باشد‪.‬‬ ‫•‬

‫ابزارهایی برای بررسی ناسازگاری نسخههای جدید وابستگیها استفاده شوند‪.‬‬ ‫•‬

‫نسخههای پایگاه داده و کد همواره همگام باشند‪.‬‬ ‫•‬

‫یک فرآیند ‪Rollback‬مشخص برای مهاجرتهای ناسازگاری وجود داشته باشد‪.‬‬ ‫•‬

‫ابزارهایی برای بررسی ناسازگاری نسخههای جدید وابستگیها استفاده شوند‪.‬‬ ‫•‬
 ‫‪29.‬رعایت اصول ‪ DevOps‬و‪CI/CD‬‬

‫از ابزارهای مانیتورینگ مانند ‪Prometheus‬یا ‪Grafana‬استفاده شود‪.‬‬ ‫•‬

‫کانتینرها از ابزارهایی مانند ‪Trivy‬برای بررسی آسیبپذیریها اسکن شوند‪.‬‬ ‫•‬

‫‪Pipeline‬های ‪ CI/CD‬به صورت خودکار وضعیت کد را بررسی کنند‪.‬‬ ‫•‬

‫از ابزارهای مانیتورینگ مانند ‪Prometheus‬یا ‪Grafana‬استفاده شود‪.‬‬ ‫•‬

‫کانتینرها از ابزارهایی مانند ‪Trivy‬برای بررسی آسیبپذیریها اسکن شوند‪.‬‬ ‫•‬

‫‪30.‬رعایت اصول همکاری تیمی‬

‫فرآیند ‪Branch Naming‬بهصورت دقیق تعریف شود (مثالً ‪feature/, bugfix/).‬‬ ‫•‬

‫جلسات کدخوانی بهطور منظم برگزار شوند‪.‬‬ ‫•‬

‫از ابزارهای مدیریت پروژه مانند ‪Jira‬یا ‪Trello‬استفاده شود‪.‬‬ ‫•‬

‫فرآیند ‪Branch Naming‬بهصورت دقیق تعریف شود (مثالً ‪feature/, bugfix/).‬‬ ‫•‬

‫جلسات کدخوانی بهطور منظم برگزار شوند‪.‬‬ ‫•‬

‫‪31.‬کدهای جاوااسکریپت یا فرانتاند‬

‫فایلهای جاوااسکریپت در زمان ‪ build‬به فایلهای ‪ ES6+‬تبدیل شوند‪.‬‬ ‫•‬

‫استایلهای ‪ CSS‬با ابزارهایی مانند ‪Sass‬مدیریت شوند‪.‬‬ ‫•‬

‫کدهای جاوااسکریپت در هنگام بارگذاری بهینه شوند‪.‬‬ ‫•‬

‫فایلهای جاوااسکریپت در زمان ‪ build‬به فایلهای ‪ ES6+‬تبدیل شوند‪.‬‬ ‫•‬

‫استایلهای ‪ CSS‬با ابزارهایی مانند ‪Sass‬مدیریت شوند‪.‬‬ ‫•‬

 ‫‪32.‬مستندسازی بیشتر و کمک به توسعهدهندگان دیگر‬

‫ابزارهای ‪ Documentation‬مانند ‪Swagger‬یا ‪Redoc‬برای مستندسازی ‪ API‬استفاده شوند‪.‬‬ ‫•‬

‫راهنمای مشارکت برای توسعهدهندگان جدید نوشته شود‪.‬‬ ‫•‬

‫یک فایل ‪README‬کامل با دستورالعملهای اجرا و تست پروژه ارائه شود‪.‬‬ ‫•‬

‫ابزارهای ‪ Documentation‬مانند ‪Swagger‬یا ‪Redoc‬برای مستندسازی ‪ API‬استفاده شوند‪.‬‬ ‫•‬

‫راهنمای مشارکت برای توسعهدهندگان جدید نوشته شود‪.‬‬ ‫•‬