Gopher Academy

✍️ Massimo Dev 🔵⚪️ نسخه‌بندی API یا API Versioning میدونی چیه؟ 🚨 نسخه‌بندی API یه راه‌حلیه برای مدیریت تغییرات API در طول زمان بدون اینکه کاربرهای قدیمی دچار مشکل بشن. وقتی که API تغییر می‌کنه و ویژگی‌های جدیدی بهش اضافه می‌شه یا مشکلاتی برطرف می‌شن، نسخه‌بندی کمک می‌کنه تا کاربرهایی که از نسخه‌های قدیمی استفاده می‌کنن همچنان بدون مشکل به کارشون ادامه بدن و در عین حال نسخه‌های جدیدتر هم در دسترس باشن. ✳️ بذار یه مثال ساده بزنم: فرض کن یه API داری که اطلاعات آب و هوا رو می‌ده. اولین نسخه‌ی API (v1) یه اندپوینت داره به اسم /weather که اطلاعات ساده‌ای مثل دما و رطوبت رو برمی‌گردونه. نسخه 1 (v1):

GET /v1/weather?city=London
Result:
{
 "temperature": "15°C",
 "humidity": "75%"
}

بعداً تصمیم می‌گیری اطلاعات بیشتری مثل سرعت باد و پیش‌بینی هوا رو اضافه کنی. برای اینکه کاربرهای قدیمی دچار مشکل نشن، یه نسخه جدید از API (v2) معرفی می‌کنی: نسخه 2 (v2):

GET /v2/weather?city=London
Result:
{
 "temperature": "15°C",
 "humidity": "75%",
 "wind_speed": "10 km/h",
 "forecast": [
 {"day": "Monday", "temperature": "16°C"},
 {"day": "Tuesday", "temperature": "17°C"}
 ]
}

به این ترتیب، کاربرهایی که از نسخه قدیمی (v1) استفاده می‌کنن همچنان بدون تغییر به کارشون ادامه می‌دن و کاربرهای جدید می‌تونن از ویژگی‌های جدید نسخه 2 (v2) استفاده کنن. ✳️ بهترین روش‌ها برای نسخه‌بندی API 🔹نسخه‌بندی URL: - شماره نسخه رو توی مسیر URL قرار بده، مثل /v1/resource و /v2/resource - مثال: `GET /api/v1/weather`، GET /api/v2/weather. 🔹نسخه‌بندی با هدرها: - از هدرهای سفارشی برای مشخص کردن نسخه استفاده کن. - مثال: GET /api/weather با headers: {"API-Version": "v2"} 🔹نسخه‌بندی با پارامترهای کوئری: - شماره نسخه رو به عنوان پارامتر کوئری قرار بده. - مثال: GET /api/weather?version=2 🔹استراتژی پایان‌دهی به نسخه‌های قدیمی: - به کاربرها بگو که نسخه قدیمی چه زمانی غیرفعال می‌شه و راهنمایی برای مهاجرت به نسخه‌های جدید بده. - یه بازه زمانی مشخص و راهنمای مهاجرت ارائه کن. 🔹مستندسازی: - برای هر نسخه از API مستندات واضح و دقیقی فراهم کن. - مثال‌ها، موارد استفاده و راهنماهای مهاجرت رو توضیح بده. 🔹سازگاری با نسخه‌های قبلی: - تا حد ممکن نسخه‌های جدید رو سازگار با نسخه‌های قبلی نگه دار تا کاربرها دچار مشکل نشن. - از نسخه‌بندی معنایی (مثل major.minor.patch) استفاده کن تا سطح تغییرات رو نشون بدی مثلا نسخه ،29.5.0 شده 29.5.1 🔹سیاست نسخه‌بندی: - یه سیاست نسخه‌بندی تعریف کن که مشخص کنه کی و چطور نسخه‌های جدید منتشر می‌شن. - واضح بگو که چه زمانی تغییرات بزرگ نیاز به یه نسخه جدید دارن. ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️ Massimo Dev 🔧 بهبود مهارت‌های گیت: نکات کلیدی که باید رعایت کنی گیت یه ابزار خیلی مهم برای هر برنامه‌نویسه، اما اگه بخواید واقعاً حرفه‌ای کار کنید، باید به یه سری اصول و قواعدش مسلط بشید. اینجا چند تا نکته کلیدی گیت رو براتون می‌گم که کارتون رو راحت‌تر و تیم‌تون رو منسجم‌تر می‌کنه: 📍۱. پیام‌های کامیت واضح و مختصر 🔹هر کامیت باید یه تغییر مشخص و قابل فهم رو نشون بده. 🔹 با لحن امری بنویسید و پیام‌ها رو کوتاه و مفید نگه دارید. 🚦مثال:

fix: resolve user login issue

- Correct typo in login function
- Update error handling for failed login attempts

📍۲. نام‌گذاری برنچ‌ها باید با معنی باشد 🔹 اسم برنچ باید مشخص کنه که چه کاری توش انجام می‌شه معمولا با اسم تسکی که در اختیار داری یکسان میشه 🔹 از پیشوندهایی مثل feature/`، `bugfix/`، `chore/ و release/ برای شروع برنچ ها استفاده کنید که به شرح زیره: 📌 feature: اگه داری یه فیچر اضافه می‌کنی 📌 bugfix: اگه داری باگی رو روی محیط استیج فیکس می کنی 📌 chore: اگه داری کارهای دواپسی یا آپدیت پکیج ها که نه فیچر و نه باگ هستن، انجام میدی 📌 release: اگه میخوای ریلیزی بدی 📌 hotfix: اگه داری روی یه باگ روی مستر یا پروداکشن فیکس می‌کنی 📌 pref: اگه داری کارهایی برای ارتقا پرفورمنس انجام میدی 📌 docs: اگه داری داکیومنت یا مستنداتی به کد اضافه می‌کنی 📌 test: اگر داری تستی می‌نویسی یا تستی رو بهبود میدی 📌 refactor: اگر داری ساختار یه کد رو بدون تغییر لاجیکش عوض می‌کنی 📌 ci: اگر داری پروسه CI/CD رو تغییر یا بهبود میدی 🚦مثال:

feature/add-payment-gateway
bugfix/fix-cart-bug
chore/update-dependencies
release/v2.0.0
hotfix/urgent-login-fix
perf/optimize-database-queries
docs/add-api-documentation
test/add-unit-tests
refactor/clean-up-auth-module
ci/add-github-actions

📍۳. درخواست‌های ادغام (PR) کامل و دقیق 🔹 پول ریکوئست یا PRها باید واضح و قابل بررسی باشن. 🔹 توضیحات کامل بدید و مسائل مرتبط رو لینک کنید. 🚦مثال:

### Summary
Implement payment gateway integration.

### Changes
- Add payment processing service
- Create payment UI component
- Update checkout workflow

### Testing
- Manual testing on staging environment
- Unit tests for payment service

### Related Issues
- Resolves #123

📍۴. برچسب‌گذاری برای نسخه‌ها 🔹 از برچسب‌ها برای نشونه‌گذاری نقاط مهم تو تاریخچه پروژه استفاده کن. 🔹 از نسخه‌بندی معنایی استفاده کن. 🚦مثال:

git tag -a v2.0.0 -m "Release version 2.0.0"
git push origin v2.0.0

📍۵. تاریخچه کامیت تمیز 🔹 تاریخچه کامیت‌هاتون باید قابل خوندن و منطقی باشه. 🔹 کامیت‌ها رو ریبیس و اسکواش کنید تا از شلوغی جلوگیری کنید. مثال:

# Rebase feature branch onto main
git rebase main

# Squash multiple commits into one
git rebase -i HEAD~3

➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

کی از قشنگ ترین مطالبی که خوندم، ۷ تکنیک ژاپنی برای مقابله با تنبلی و اهمال کاری بود که می گفت..... ۱) ایکیگای این تکنیک میگه هرانسانی برای بیدار شدن از خواب نیاز به یه دلیل و‌ هدف داره که به زندگیش معنا بده، بگرد و معنای زندگی خودت رو پیدا کن به قول دکتر فرانکل در کتاب معروفش"انسانی که چرایی برای زندگی داشته باشه، هر چگونگی رو تحمل میکنه" ۲) کایزن هر روز روی پیشرفت های کوچک تمرکز کن، سعی کن هر روز ۱٪ فقط بهتر بشی، همین کافیه ۳) شوشین ذهنت رو متمرکز و خالی نگه‌دار، هرچیزی رو نخون، هرآهنگی رو گوش نده، هر فیلمی رو نبین، روی ورودی های ذهنت حساس باش +ذهن یه متخصص برخلاف باور همه خالی تر از ذهن یه انسان معمولیه چون متمرکزه ۴) هارا هاچی بو وقتی ۸۰ درصد احساس سیری کردی دست از غذا بکش، همونطور که روی ورودی های ذهن حساسی رو جسمت هم حساس باش، بدنی که هرچیزی بخوره خواه نا خواه تنبل میشه ۵) شنیرین یوکو با طبیعت انس بگیر، ژاپنی ها طبیعت رو منبع الهام بخشی برای انگیزه و انرژی میدونن ۶) وابی سابی به جای پیدا کردن زیبایی در کمال و کامل بودن، به دنبال زیبایی در نقص باش، یعنی دقیقا نقطه مقابل کمال‌گرایی ۷) گانبارو صبور باش و استمرار داشته باش، هیچ اتفاقی یهویی رخ نمیده این رو برای خودت مرور کن ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️ Massimo Dev توی مهندسی نرم‌افزار، "طراحی مبتنی بر دامنه" (DDD) یه روش طراحی هست که توسط Eric Evans معرفی شده. هدف این روش اینه که یه درک مشترک از حوزه‌ی کاری بین برنامه‌نویسا و استراتژیست ها ایجاد بشه مفاهیم کلیدی دامنه (Domain): همون قسمتی که کاربر از برنامه استفاده می‌کنه. مثلاً اگه برنامه ما یه فروشگاه آنلاین کتابه، دامنه‌اش همینه. مدل دامنه (Domain Model): یه مدل انتزاعی که مفاهیم، قوانین و منطق دامنه کاری رو نشون می‌ده. این مدل باید طوری باشه که هم کارشناسان فنی و هم استراتژیست ها بتونن بفهمنش. زبان مشترک (Ubiquitous Language): یه زبان مشترک که تیم ازش استفاده می‌کنه تا همه حرف‌ها و مفاهیم توی پروژه رو با اون بیان کنن. این زبان شکاف بین اصطلاحات فنی و تخصصی رو پر می‌کنه. مرزهای محدود (Bounded Context): یه مرز که داخلش یه مدل خاص تعریف شده و کاربرد داره. این به مدیریت پیچیدگی کمک می‌کنه و حوزه رو به بخش‌های کوچیک‌تر و قابل مدیریت‌تر تقسیم می‌کنه. موجودیت‌ها (Entities): Object هایی که هویت مشخص و ثابتی دارن و می‌تونن حالت‌های مختلفی داشته باشن. اشیاء ارزشمند (Value Objects): آبجکت هایی که جنبه‌های خاصی از دامنه رو توصیف می‌کنن ولی هویت مشخصی ندارن. مجموعه‌ها (Aggregates): یه کلاستر از آبجکت های دامنه هستن که می‌تونن به‌عنوان یه واحد در نظر گرفته بشن. نگران نباشید مثال میزنم بعدش که متوجه بشید. مخازن (Repositories): مکانیزم‌هایی برای نگهداری، بازیابی و جستجوی اشیاء که شبیه یه کلکسیون از اشیاء عمل می‌کنن. سرویس‌ها (Services): عملیات یا فرایندهایی که به Life Cycle یه Entity یا Value Object ربطی ندارن. مثال عملی: فروشگاه آنلاین کتاب بیاین این مفاهیم رو با یه مثال از یه فروشگاه آنلاین کتاب توضیح بدیم. Domain: دامنه همون "فروشگاه آنلاین کتاب" هست که روی منطق کسب‌وکار خرید، فروش و مدیریت کتاب تمرکز داره. Domain Model: مدل دامنه شامل موجودیت‌هایی مثل کتاب، مشتری، سفارش و مفاهیمی مثل مدیریت موجودی و پردازش پرداخت می‌شه. Ubiquitous Language: - کتاب: همون محصولیه که داریم می‌فروشیم. - مشتری: کسی که کتاب می‌خره. - سفارش: خرید مشتری که شامل یه یا چندتا کتابه. - موجودی: تعداد کتاب‌های موجود. - پرداخت: تراکنش برای یه سفارش. Bounded Context: 1. کانتکست فروش: شامل موجودیت‌ها و گرفتن سفارش و پردازش پرداخت. 2. کانتکست موجودی: شامل موجودیت‌ها و مدیریت موجودی کتاب‌ها. 3. کانتکست مشتری: شامل موجودیت‌ها و اطلاعات و پروفایل مشتری‌ها. Entities and Value Objects - Entities: - کتاب (ISBN، Title، Author، Price) - مشتری (ID, Name، Email) - سفارش (ID، Book Items، total amount، order date ) - Value Objects: - آدرس (خیابان، شهر، استان، کدپستی) - پول (مبلغ، ارز) Aggregates - مجموعه سفارش: موجودیت Order یک Aggregate root است. شامل لیست کتاب‌ها به‌عنوان Value object و مبلغ کل به‌عنوان یه value object. - مجموعه مشتری: موجودیت Customer یک Aggregate root است. شامل آدرس به‌عنوان یه Value object. Repositories - مخزن کتاب: مدیریت موجودیت‌های کتاب، پیدا کردن، ذخیره و حذف کتاب‌ها. - مخزن سفارش: مدیریت موجودیت‌های سفارش، ثبت، پیگیری و بازیابی سفارش‌ها. Services - سرویس سفارش: شامل منطق ثبت سفارش، از جمله چک کردن موجودی، پردازش پرداخت و تایید سفارش. - سرویس موجودی: شامل منطق به‌روز‌رسانی سطح موجودی، چک کردن موجودی و تجدید موجودی کتاب‌ها ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev آشنایی با اصول SOLID# به عنوان برنامه‌نویس، همیشه دنبال نوشتن کد تمیز، قابل نگهداری و قابل گسترش هستیم. اصول SOLID یک سری راهنما برای رسیدن به این هدف‌ها ارائه می‌ده. 📍1. اصلSingle Responsible Principle (SRP) - مفهوم: هر کلاس باید فقط یک دلیل برای تغییر داشته باشه و یک مسولیت رو بپذیره! - مثال: فکر کن یه دستگاه قهوه‌ساز داری که هم قهوه درست می‌کنه و هم رادیو داره. اگه رادیو خراب بشه، ممکنه نتونی قهوه درست کنی تا رادیو تعمیر بشه. بهتره دستگاه‌های جدا برای قهوه و موسیقی داشته باشی. 📍2. اصل باز/بسته (OCP) یا Open-Close Principle - مفهوم: موجودیت‌های نرم‌افزاری باید برای گسترش باز و برای تغییر بسته باشن. - مثال: فرض کن یک فروشگاه آنلاین داری که روش‌های مختلف پرداخت رو پشتیبانی می‌کنه. به جای اینکه هر بار که یک روش پرداخت جدید اضافه می‌کنی، کد اصلی فروشگاه رو تغییر بدی، می‌تونی یک ساختار ماژولار طراحی کنی که هر روش پرداخت به صورت یک ماژول جداگانه باشه. اینجوری، وقتی می‌خوای یک روش پرداخت جدید مثل پرداخت با بیت‌کوین اضافه کنی، فقط کافیه یک ماژول جدید برای اون روش پرداخت بسازی و به سیستم اضافه کنی، بدون اینکه کد اصلی فروشگاه تغییر کنه. 📍3. اصل جایگزینی لیسکوف (LSP) یا Liskov Substitution Principle جایگزینی لیسکوف یا اصل جایگزین‌پذیری Liskov مفهومی در برنامه‌نویسی شیءگرا است که تضمین می‌کند هر شیء یا نمونه‌ای از یک کلاس می‌تواند به جای هر نمونه دیگری از آن کلاس قرار گیرد بدون اینکه عملکرد برنامه‌ی کامل را تحت تاثیر قرار دهد. به این معنی که اگر یک کلاس زیرکلاس (subclass) باشد، باید بتواند به جای کلاس اصلی (superclass) قرار گیرد و همه‌ی عملکردها به درستی کار کنند. فرض کنید که شما یک کلاس اتومبیل (Car) دارید که دارای عملکردهایی مانند شروع کردن (start)، توقف کردن (stop) و حرکت کردن (move) است. حالا شما یک زیرکلاس به نام اتومبیل الکتریکی (ElectricCar) ایجاد می‌کنید که همه‌ی این عملکردها را به ارث می‌برد. بر اساس اصل جایگزین‌پذیری لیسکوف، اگر برنامه شما برای کلاس اتومبیل نوشته شده باشد، باید بتوانید به جای هر اتومبیل، یک اتومبیل الکتریکی قرار دهید و برنامه همچنان به درستی کار کند، به این معنی که توابع start، stop و move به درستی اجرا شوند بدون نیاز به تغییر در کد برنامه. 📍4. اصل جداسازی اینترفیس‌ها (ISP) Interface Segregation Principle - مفهوم: هیچ مشتری نباید مجبور باشه به متدهایی که استفاده نمی‌کنه وابسته باشه. - مثال: فکر کن یه ابزار چندکاره داری با قابلیت‌های جدا برای کارهای مختلف (پیچ‌گوشتی، چاقو، درب‌بازکن). هر ابزار وظیفه خاصی داره بدون اینکه مجبور باشی امکانات اضافی رو حمل و استفاده کنی. 📍5. اصل وارونگی وابستگی (DIP) یا Dependency Inversion - مفهوم: ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشن. هر دو باید به انتزاع وابسته باشن. یک مثال ساده از اعمال اصل DIP می‌تواند در استفاده از وابستگی‌ها و تزریق وابستگی باشد. به عنوان مثال، فرض کنید شما یک برنامه‌ای دارید که برای ارسال ایمیل به کاربران خود نیاز به استفاده از یک سرویس ایمیل دارد. به جای اینکه مستقیماً به یک سرویس خاص مثل Gmail یا Outlook وابسته شوید، شما یک رابط یا اینترفیس برای سرویس ارسال ایمیل خود تعریف می‌کنید. #برنامه_نویسی #دیزاین_پترن #کدنویسی ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

فرصت همکاری دورکاری Digital marketer ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

خلاصه کتاب قورباغه ات را قورت بده در یک دقیقه: ♦️قانون اول: فکر نکن بخورش. اگه دو تا قورباغه روی میز هست و تو قراره اونارو بخوری نگاه کردن بهشون و تعلل کردن هیچ چیزی رو حل نمیکنه همین الان قورباغرو قورت بده کار سختی که باید انجام بدیو همین الان انجام بده. ♦️قانون دوم : اول زشته رو بخور اگه دو تا قورباغه روی یک میز هست اول اونی که زشت تره رو بخور، اول اون کاری که سخت تره رو انجام بده وقتی اول صبح کارای سختو انجام بدی اعتماد به نفس پیدا میکنی برای ادامه روزت. ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev 🚀 تست‌نویسی در پروژه‌های بزرگ: بهترین روش‌ها و یه مثال واقعی 🚀 تو دنیای پرسرعت توسعه نرم‌افزار، تضمین کیفیت کد و اطمینان از عملکرد درست خیلی مهمه. روش تست‌نویسی قبل از کدنویسی (TDD) ثابت کرده که می‌تونه یه تغییر بزرگ ایجاد کنه، مخصوصاً تو پروژه‌های بزرگ. اینجا چندتا از بهترین روش‌ها برای اجرای TDD تو پروژه‌های بزرگ رو با یه مثال واقعی براتون می‌گم. ✅ 1. طراحی و معماری ماژولار ما تو شرکت مون ابتدا سعی کردیم یه اپلیکیشن مونولیتیک رو به مایکروسرویس‌ها تقسیم کردیم. این کار نوشتن تست‌های مستقل برای هر سرویس رو آسون‌تر کرد و نگهداری و مقیاس‌پذیری رو بهتر کرد. ✅ 2. پایپلاین تست اتوماتیک ما TDD رو با استفاده از Jenkins و GitHub Actions تو CI/CDمون ادغام کردیم. هر کامیت یه سری تست رو اجرا می‌کنه و بلافاصله بازخورد می‌ده و سلامت کد رو حفظ می‌کنه. ✅ 3. تست کاوریج (پوشش تست) و کیفیت به جای دنبال کردن پوشش ۱۰۰٪، روی مسیرهای بحرانی تمرکز کردیم. مثلاً، تست احراز هویت کاربر به ما کمک کرد که مشکلات امنیتی رو زودتر پیدا و رفع کنیم ✅ 4. انواع و سطوح تست - تست‌های واحد یا Unit Tests: اعتبارسنجی اجزای فردی. - تست‌های یکپارچه‌سازی یا Integration Tests: اطمینان از عملکرد درست اجزا با هم. - تست‌های End-to-End: تست کل ورک فلوهای اپلیکیشن. تو پروژه، Unit Testing برای پردازش پرداخت‌ها با تست‌های End-to-End که تراکنش‌های واقعی کاربران رو شبیه‌سازی می‌کرد، اجرا شد تا عملکرد قوی‌ای داشته باشیم. ✅ 5. نگهداری تست‌ها مرور و بازسازی منظم تست‌ها به ما کمک کرد تا مجموعه تست‌هامون رو مرتبط و کارآمد نگه داریم و بدهی فنی رو کاهش بدیم. ✅ 6. کد ریویو بررسی دقیق کدها، شامل تست‌ها، فرهنگ ارتقاء کیفیت و مسئولیت مشترک بین اعضای تیم رو تقویت کرد. ✅ 7. ماکینگ و Stubbing ما از ماک‌ها (Mocks) برای شبیه‌سازی درگاه‌های پرداخت خارجی استفاده کردیم تا تست‌هامون بدون وابستگی به سرویس‌های خارجی سریع و قابل اعتماد باشه. ✅ 8. تست‌های مقیاس‌پذیری و عملکرد یا Scalability & Performance Testing قبل از نسخه‌های اصلی، بارگذاری سرویس‌هامون رو تست کردیم تا گلوگاه‌ها رو شناسایی کنیم و تو دوره‌های ترافیک بالا، عملکرد روان داشته باشیم. ✅ 9. مستندسازی و آموزش مستندات جامع و جلسات آموزشی منظم در مورد بهترین روش‌های TDD تیم‌مون رو هماهنگ و مچ تر نگه داشت. ✅ 10. بازخورد و بهبود جلسات رترو دو هفته‌ای یه فضایی رو برای بحث در مورد چالش‌ها و بهبودهای TDD فراهم کرد و رویکردمون رو به طور مداوم بهبود داد. با ادغام این روش‌ها، فرآیند توسعه‌مون رو متحول کردیم و نتیجه‌ش نرم‌افزار با کیفیت‌تر و نسخه‌های قابل پیش‌بینی‌تر شد. TDD فقط یه روش نیست، یه ذهنیته که وقتی کامل پذیرفته بشه، می‌تونه بهبودهای قابل توجهی هم تو فرآیند توسعه و هم محصول نهایی ایجاد کنه. #توسعه_نرم‌افزار #TDD #تضمین_کیفیت #DevOps #مایکروسرویس‌ها #اجایل ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev 📗 اصول مهم کد ریویو یا بررسی کد: YAGNI، KISS و DRY من خودم موقع کد ریویوها این سه اصل رو خیلی با دقت رعایت می‌کنم. 🔶 1. YAGNI (You aren't gonna need it): - این اصل داره میگه از اضافه کردن ویژگی‌ها یا کدی که الان لازم نیست خودداری کن. این کار باعث میشه کدت تمیز و ساده بمونه. 🔹 - مثال: اگه تو داری یه فرم ساده برای ورود اطلاعات می‌نویسی، لازم نیست از الان برای فیلتر کردن داده‌ها یا اضافه کردن قابلیت‌های پیچیده فکر کنی. اونها رو بعداً وقتی واقعاً نیاز بود اضافه کن. 🔶 2. KISS (Keep it simple & stupid): - میگه سعی کن کدت ساده باشه. راه‌حل‌های پیچیده معمولاً میشه ساده‌ترشون کرد و این باعث میشه کد راحت‌تر خوانده و نگهداری بشه. 🔹 - مثال: به جای نوشتن یه تابع پیچیده برای محاسبه تخفیف، یه تابع ساده بنویس که فقط تخفیف رو بر اساس درصد حساب کنه. اگه بعداً نیاز به محاسبات پیچیده‌تر بود، اون موقع بهش اضافه کن. 🔶 3. DRY (Don't repeat yourself): - میگه جایی که میشه، از کدهای موجود استفاده کن و از تکرار کد خودداری کن. این کار باعث میشه نگهداری کد راحت‌تر باشه و احتمال خطاها کمتر بشه. 🔹- مثال: اگه داری چند بار یه عملیات مشابه مثل محاسبه مالیات رو انجام میدی، اون رو تو یه تابع مجزا بنویس و هر بار از اون تابع استفاده کن. با رعایت این اصول در کد ریویوها، می‌تونی کدی بنویسی که هم خواناتر، هم قابل نگهداری‌تر و هم بهینه‌تر باشه. همه چیز در مورد نوشتن کد کمتر ولی بهتره. ➖➖➖➖➖➖➖➖ 👑 @gopher_academy | 💸 Donate | 💋 Boost