برای رسیدن به متریک مناسب سرویس تون یه سری راه حل اینجا گذاشته
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

📌 Go Developers (m/f/d) create masterpieces & pioneering work in the backend while their career takes off at the front!

📝 Type: Visa Sponsorship

🌍 Relocation Package: ✅

🏢 Company: mytalentscout gmbh

📍 Location: GERMANY

⌨️ Category: #Programming

🔗 Tags: #golang #mysql #ai


📌 Backend Engineer (Tabby Finance)

📝 Type: Visa Sponsorship

🌍 Relocation Package: ✅

🏢 Company: tabby

📍 Location: SERBIA

⌨️ Category: #Programming

🔗 Tags: #golang #postgresql #redis #kubernetes #cloud #gitlab

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

لیستی از مکانیزم های قفل برای جلوگیری از دسترسی همزمان دادها و ناسازگاری داده ها
👇👇👇👇
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

🔻لیستی از مکانیزم های قفل برای جلوگیری از دسترسی همزمان دادها و ناسازگاری داده ها🔻

🎯1. Shared Lock (S Lock)
It allows multiple transactions to read a resource simultaneously but not modify it. Other transactions can also acquire a shared lock on the same resource.

🎯2. Exclusive Lock (X Lock)
It allows a transaction to both read and modify a resource. No other transaction can acquire any type of lock on the same resource while an exclusive lock is held.

🎯3. Update Lock (U Lock)
It is used to prevent a deadlock scenario when a transaction intends to update a resource.

🎯4. Schema Lock
It is used to protect the structure of database objects.

🎯5. Bulk Update Lock (BU Lock)
It is used during bulk insert operations to improve performance by reducing the number of locks required.

🎯6. Key-Range Lock
It is used in indexed data to prevent phantom reads (inserting new rows into a range that a transaction has already read).

🎯7. Row-Level Lock
It locks a specific row in a table, allowing other rows to be accessed concurrently.

🎯8. Page-Level Lock
It locks a specific page (a fixed-size block of data) in the database.

🎯9. Table-Level Lock
It locks an entire table. This is simple to implement but can reduce concurrency significantly.

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

Massimo Dev

میدونستید #ایندکس ترکیبی یا Composite Index تو #دیتابیس چی هست؟ یه سوالیه که معمولا تو #مصاحبه های #استخدام #برنامه_نویسی می‌پرسن!

ایندکس ترکیبی، ایندکسی هست که چندتا ستون رو باهم تو خودش داره. یعنی به جای اینکه فقط یه ستون رو ایندکس کنیم، میایم و چندتا ستون رو با همدیگه ایندکس می‌کنیم تا وقتی که توی کوئری‌ها (دستورات جستجو) از چندتا ستون استفاده می‌کنیم، دیتابیس سریع‌تر بتونه نتایج رو پیدا کنه.

👈 مثال از ایندکس ترکیبی

فرض کن یه جدول به اسم employees داریم که این ستون‌ها رو داره:

- employee_id
- first_name
- last_name
- department
- hire_date

اگه بخوایم جستجوهایی که بر اساس department و hire_date هستن سریع‌تر بشن، میایم و یه ایندکس ترکیبی روی این دوتا ستون درست می‌کنیم:

CREATE INDEX idx_department_hire_date ON employees(department, hire_date);

👈 ترتیب ستون‌ها توی ایندکس ترکیبی:

ترتیب ستون‌ها توی ایندکس ترکیبی خیلی مهمه. این ایندکس بیشتر به درد جستجوهایی می‌خوره که از ستون‌های اول ایندکس شروع بشن.

🍒 مثال‌هایی از کوئری‌ها

1. کوئری‌ای که از هر دو ستون استفاده می‌کنه**:

 SELECT * FROM employees WHERE department = 'Sales' AND hire_date = '2023-01-15';
 

این کوئری می‌تونه از ایندکس ترکیبی idx_department_hire_date کامل استفاده کنه.

2. کوئری‌ای که فقط از ستون اول استفاده می‌کنه:

 SELECT * FROM employees WHERE department = 'Sales';
 

این کوئری هم می‌تونه از ایندکس استفاده کنه چون با ستون department شروع شده.

3. کوئری‌ای که فقط از ستون دوم استفاده می‌کنه:

 SELECT * FROM employees WHERE hire_date = '2023-01-15';
 

این کوئری نمی‌تونه به طور مؤثری از ایندکس ترکیبی idx_department_hire_date استفاده کنه، چون با ستون department شروع نمی‌شه. به این معنا نیست که تحت هیچ شرایطی از ایندکس استفاده نمی‌کنه، بلکه به این معناست که از بخش زیادی از ایندکس استفاده نمی‌شه و عملاً سود چندانی از ایندکس نمی‌بره.

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

 SELECT * FROM employees WHERE hire_date = '2023-01-15' AND department = 'Sales';
 

این کوئری هم می‌تونه از ایندکس استفاده کنه چون از هر دو ستون استفاده کرده، ولی بهتره ستون‌ها رو به همون ترتیبی که تو ایندکس تعریف شدن استفاده کنیم.

👈👈👈 خلاصه

🔺 ترتیب مهمه: ترتیب ستون‌ها توی ایندکس ترکیبی خیلی مهمه. ایندکس وقتی بهترین کارایی رو داره که جستجوها از ستون‌های اول ایندکس شروع بشن.
🔺 استفاده از پیشوند: جستجوهایی که از ستون اول، دو ستون اول و همینطور ادامه دارن، از ایندکس بهره می‌برن.
🔺 استفاده جزئی: استفاده از ستون دوم یا بعدی بدون ستون اول نمی‌تونه از ایندکس ترکیبی استفاده کنه.

فهمیدن اینکه کوئری‌هات چجوری با ایندکس‌ها کار می‌کنن خیلی مهمه تا بتونی عملکرد دیتابیس رو بهتر کنی.

➖➖➖➖➖➖➖➖
👑 @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

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

خلاصه کتاب قورباغه ات را قورت بده در یک دقیقه:

♦️قانون اول:
فکر نکن بخورش.
اگه دو تا قورباغه روی میز هست و تو قراره اونارو بخوری نگاه کردن بهشون و تعلل کردن هیچ چیزی رو حل نمیکنه همین الان قورباغرو قورت بده

کار سختی که باید انجام بدیو همین الان انجام بده.

♦️قانون دوم :
اول زشته رو بخور
اگه دو تا قورباغه روی یک میز هست اول اونی که زشت تره رو بخور، اول اون کاری که سخت تره رو انجام بده

وقتی اول صبح کارای سختو انجام بدی اعتماد به نفس پیدا میکنی برای ادامه روزت.

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

فرصت همکاری
دورکاری
Digital marketer

➖➖➖➖➖➖➖➖
👑 @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

✍️ 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

کی از قشنگ ترین مطالبی که خوندم، ۷ تکنیک ژاپنی برای مقابله با تنبلی و اهمال کاری بود که می گفت.....

۱) ایکیگای
این تکنیک میگه هرانسانی برای بیدار شدن از خواب نیاز به یه دلیل و‌ هدف داره که به زندگیش معنا بده، بگرد و معنای زندگی خودت رو پیدا کن
به قول دکتر فرانکل در کتاب معروفش"انسانی که چرایی برای زندگی داشته باشه، هر چگونگی رو تحمل میکنه"

۲) کایزن
هر روز روی پیشرفت های کوچک تمرکز کن، سعی کن هر روز ۱٪ فقط بهتر بشی، همین کافیه

۳) شوشین
ذهنت رو متمرکز و خالی نگه‌دار، هرچیزی رو نخون، هرآهنگی رو گوش نده، هر فیلمی رو نبین، روی ورودی های ذهنت حساس باش

+ذهن یه متخصص برخلاف باور همه خالی تر از ذهن یه انسان معمولیه
چون متمرکزه

۴) هارا هاچی بو
وقتی ۸۰ درصد احساس سیری کردی دست از غذا بکش، همونطور که روی ورودی های ذهن حساسی رو جسمت هم حساس باش، بدنی که هرچیزی بخوره خواه نا خواه تنبل میشه

۵) شنیرین یوکو
با طبیعت انس بگیر، ژاپنی ها طبیعت رو منبع الهام بخشی برای انگیزه و انرژی میدونن

۶) وابی سابی
به جای پیدا کردن زیبایی در کمال و کامل بودن، به دنبال زیبایی در نقص باش، یعنی دقیقا نقطه مقابل کمال‌گرایی

۷) گانبارو
صبور باش و استمرار داشته باش، هیچ اتفاقی یهویی رخ نمیده این رو برای خودت مرور کن

➖➖➖➖➖➖➖➖
👑 @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

✍️ 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

هر چند وقت یک بار بد نیست ۵ قانون مهم دنیا را برای درک بهتر موفقیت برای خود مرور کنید:

1. قانون مورفی (Murphy’s Law)

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

2. قانون کیدلین (Kidlin’s Law)

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

3. قانون گیلبرت (Gilbert’s Law)

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

4. قانون والسون (Walson’s Law)

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

5. قانون فالکلند (Falkland’s Law)

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

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

سیستم دیزاین تلگرام🤔👾
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

یه ریپازیتوری باحال توی گیتهاب پیدا کردم که یکی از بچه های ایرانی آماده کرده.

نکات خیلی خوبی برای گرفتن جاب آفر از جمله رزومه نویسی، مصاحبه ، پروسه اپلای و... رو توش نوشته.

حتما چک کنید:

https://github.com/coditori/highly-skilled-job-offers

DevTwitter | <Reza/>

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