این‌جا منظور از Trade-Off چیه؟

اصطلاح Trade-off یکی از مهم‌ترین مفاهیم مهندسی نرم‌افزاره. معنیش اینه که واسه به‌دست آوردن یه مزیت، مجبور می‌شی از یه مزیت یا ویژگی دیگه چشم‌پوشی کنی.

تو تصمیم‌گیری مهندسی معمولاً چیزی به اسم «همه‌چیز با هم و بدون هزینه» نداریم.

فرضا می‌‌خوایم Redis Cache به پروژه اضافه کنیم. این کار یسری مزیت و یسری معایب داره. مثلا باعث افزایش سرعت و کاهش فشار روی دیتابیس می‌شه. ولی از طرفی Complexity ایجاد شده، باید Cache Invalidation مدیریت بشه و ...

با همچین قابلیتی عملا Performance رو بهبود دادیم، ولی باید Complexity و احتمال Stale Data رو هم‌ بپذیریم.

یه مهندس نرم‌افزار باید بتونه بنا به وضعیت و شرایط پروژه تصمیم بگیره که این مزایا / معایب می‌صرفن یا نه.

این مهارت با کسب تجربه به دست میاد و در عصر Ai یکی از مهارت های کلیدیه.

@Mern_stack_01

اگه توی مسیر رشد شغلی دنبال یه Mentor خوب می‌گردی، ADPList رو حتماً ببین

یه پلتفرمه که می‌تونی از بین Mentorهای مختلف توی حوزه‌هایی مثل برنامه‌نویسی، AI، طراحی و Product، آدم مناسب خودت رو پیدا کنی و باهاش جلسه داشته باشی.

جالب‌تر اینکه جلسات برای Menteeها رایگانه!

🔗 ADPList

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

در این مسیر از راهنمایی و منتورینگ آقای امیررضا محمدی افضل و حسین رضایی خیلی استفاده کردم و واقعاً بابت وقتی که گذاشتن و تجربه‌ای که در اختیارم قرار دادن ممنونم. 🙏🏻

در حال حاضر آماده‌ام که در یک تیم حرفه‌ای، پروژه واقعی یا موقعیت شغلی Backend/Full-Stack همکاری کنم و در کنار کار واقعی، همچنان یاد بگیرم و رشد کنم.

اگر در تیم یا شرکتتون فرصت همکاری دارید، یا روی پروژه‌ای کار می‌کنید که فکر می‌کنید می‌تونم در اون مفید باشم، خوشحال می‌شم باهام در ارتباط باشید. 🤝

ممنون از همه دوستانی که در این مسیر کمکم کردن 🤍

جدا از برنامه نویسی

موسیقی که واقعا روتون اثر گذاشته و از چیزی ک هستید خارجتون کرده رو بفرستید تو کامنتا لذت ببریم

مثل اینکه روزه برنامه نویسه

Design pattern _ factory pattern 1

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

مثلا من تو سیستمم چند نو ناتیفیکیشن دارم و باید بر اساس نوع اون ابجکت مناسب رو بسازم
پس به جای اینکه کدمون رو پر از if/else کنیم و سیستم رو خراب کنیم میاییم از دیزاین پترن هارو وارد کار میکنیم

factory pattern - simple factory
مسئولیت ساخت ابجکت را از کدی که از ان ابجکت استفاده میکند جدا کن

ببین مثلا یه ناتفیکیشن سرویس داریم
حالا توی این ناتیفیکیشن سرویس طبق فکتوری پترن نباید این کارو کنیم :
new emailNotification()
new smsNotification()

به جای اینکار میاییم یه کلاس فکتوری میسازیم :

class NotificationFactory {
  static create(type: string): Notification {
    switch (type) {
      case "email":
        return new EmailNotification();

      case "sms":
        return new SmsNotification();

      case "push":
        return new PushNotification();

      default:
        throw new Error(`Unsupported notification type: ${type}`);
    }
  }
}

و در سرویس ناتیفیکیشن

class NotificationService {
  async send(type: string, message: string) {
    const notification = NotificationFactory.create(type);

    await notification.send(message);
  }
}

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

حالا جریان سیستم اینطوری میشه که کنترلر به سرویس و سرویس به فکتوری و فکتوری به ایمپلمنتشن هایی که داریم وابسته میشه

حالا شما بگید فکتوری پترن با solid و کانسپت هایی که قبلا گفتیم چه ارتباط هایی داره

از‌ امروز کم کم وارد دیزاین پترن شدم
و توی مسیر چیزایی ک یاد میگیرم رو میزارم براتون

ری‌اکت به ورژن 19.3 آپدیت شده و تغییرات قابل توجهی ارائه کرده. این‌جا می‌تونید این تغییرات رو بخونید:

🔗 React Blog

پ‌ن: برنامه‌نویس های باتجربه به طور مستمر داکیومنت تکنولوژی‌ها رو مطالعه می‌کنن تا همیشه دانش‌شون بروز باشه.

@Rads_notes

دوستان این ریپازیتوری هم شاید به دردتون بخوره

https://github.com/3lf/design-patterns-for-humans

چندتا نکته ساده برای اینکه لپ‌تاپمون سالم‌تر بمونه:

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


با این قیمتا و شرایط بهتره از چیزی که داریم بهترین استفاده رو کنیم و به بهترین شکل مواظبش باشیم.

design pattern - builder pattern
این پترن تو بک اند زیاد به درد میخوره
خصوصا جاهایی که ابجکت های ما پیچیده یا پارامتر های زیادی دارند

مثلا میخواییم یه یوزر بسازیم کلی پارامتر داریم برای ساخت یوزر که باعث کاهش خوانایی کد میشود ، ترنیب پارامتر ها مهم میشود ، تشخیص هر مقدار سخت میشود ، خصوصا اگه اپشنال پارامتر داشته باشیم

روش اول که ابجکت پارمتر هستش که خیلیم خوبه تو تایپ اسکریپت

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

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

دیگه اینطوری نیست که توی constructor دونه به دونه واردش کنیم به جاش با بیلدر اوکیش میکنیم

class UserBuilder {
  private name!: string;
  private email!: string;
  private age!: number;
  private phone?: string;

  setName(name: string) {
    this.name = name;
    return this;
  }

  setEmail(email: string) {
    this.email = email;
    return this;
  }

  setAge(age: number) {
    this.age = age;
    return this;
  }

  setPhone(phone: string) {
    this.phone = phone;
    return this;
  }

  build() {
    return new User(
      this.name,
      this.email,
      this.age,
      this.phone,
    );
  }
}

و در استفاده :

const user = new UserBuilder()
  .setName("Amir")
  .setEmail("amir@example.com")
  .setAge(25)
  .setPhone("0912...")
  .build();

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

دیزاین پترن ها ابزار هستن نه قانون
اگه مسئله ساده حل میشه ساده حلش کن
اگه مسئله پیچیده شد پترن مناسب رو واردش کن

تو بک اند این پترن بیشتر برای کوئری بیلدر ها ، ساخت httprequest و.. استفاده میشه

فک کن دکل محلتون خراب شده باشه کل محله نت نداشته باشن
و بگن ک تعمیرش یه هفته طول میکشه
روزی ۲ ساعتم برق بره
برنامه نویسم باشی تازه
بهتر از این نمیشه دیگه

اینبار اومدیم با پترن Adapter

رفقا فرض کنید یه اینترفیس داریم برای پیمنت که متد pay رو داره
ولی مثلا یکی از گیتوی ها به جای اینکه pay داشته باشه مثلا یه همچین ساختاری داره :
zaripal.requestPayment({
amount: 100000
});
که اینا باهم سازگار نیستند

اینجاست که adapter به کمکمون میاد
adapter: بین دوتا چیز که باهم سازگار نیستند یه واسطه بسازیم تا اون دو چیز باخم بتونن کار کنن

مثلا تو برنامه نویسی :
PaymentService
↓
PaymentGateway
↓
Adapter
↓
Zarinpal API

class ZarinpalAdapter implements PaymentGateway {
  constructor(
    private readonly zarinpal: ZarinpalSDK
  ) {}

  async pay(amount: number): Promise<void> {
    await this.zarinpal.requestPayment({
      amount,
    });
  }
}

پس adapter تفاوت بین دو اینترفیس رو برامون حل میکنه

فک کنم با تعریفی ک داشتیم و مثال و تکه کد متوجه شده باشید جریانش کلا چیه و چطوریه

ممنون

Decorator pattern

اقا ما بر فرض مثال ما یه سرویسی داریم هعی به این سرویس چیزای جدید اضافه میکنیم کداش رو زیاد و شلوغ تر میکنیم مثلا چی مثلا logging , cache , metrics,authrization ,...

به جای اینکار دکوریتور رو میاریم وسط
که میگه :
بدون تغییر دادن ابجکت اصلی بهش قابلیت های جدید اضافه کن
پس برای هر قابلیت یه دکوریتور داریم
loggingDecorator

مثال

interface UserService {
  getUser(id: string): Promise<User>;
}

class UserServiceImpl implements UserService {
  async getUser(id: string): Promise<User> {
    console.log("Fetching user from database");

    return {
      id,
      name: "Amir",
    };
  }
}

class LoggingUserService implements UserService {
  constructor(
    private readonly service: UserService
  ) {}

  async getUser(id: string): Promise<User> {
    console.log(`Getting user: ${id}`);

    const user = await this.service.getUser(id);

    console.log(`User found: ${id}`);

    return user;
  }

استفاده :

const userService = new UserServiceImpl();

const loggedUserService =
  new LoggingUserService(userService);

await loggedUserService.getUser("123");

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

مثلا به یوزر سرویس بالا بیاییم یه دکوریتور برای کش اضافه کنیم :

class CacheUserService implements UserService {
  constructor(
    private readonly service: UserService
  ) {}

  async getUser(id: string): Promise<User> {
    const cached = await cache.get(id);

    if (cached) {
      return JSON.parse(cached);
    }

    const user = await this.service.getUser(id);

    await cache.set(
      id,
      JSON.stringify(user)
    );

    return user;
  }
}

فک کنم تا اینجا متوجه شده باشید که جریانش چطوریاست
ممنون

این روزا همزمان دارم روی دو تا پروژه کار می‌کنم 👨🏻‍💻

یکی یه فروشگاه اینترنتیه که دارم روش کار می‌کنم و سعی می‌کنم از نظر فنی و UI یه چیز تمیز و حرفه‌ای دربیاد.

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

فعلاً هر دو پروژه رو همزمان جلو می‌برم و احتمالاً پس از اینکه به پروداکشن رسوندمشون براتون اینجا بزارمشون.

خب همچنان یادگیریمون ادامه داره

Fecade pattern

که خیلی ساده و کاربردی هستش توی بک اند

ببین حاجی فک کن که فک کن کاربر میخواد یه چیزی سفارش بده و به /orders پست میزنه
اینجا چندتا مرحله داره دیگه خب مثلا ثبت سفارش و پرداخت و ..
خالا فک کن همه ی اینارو کنترلر هندل میکنه

fecade چی‌میگه؟
میگه اقا بیا یه اینترفیس ساده بزار جلوی یه سیستم پیچیده
ینی چی یعنی بجای اینکه کنترلرت با ۵ تا سرویس مختلف کار کنه بیا یه fecade بساز بین کنترلر و اون سرویس ها
فقط با کنترلر اینو داشته باش :

orderFacade.createOrder(...)

مثال :

class OrderFacade {
  constructor(
    private readonly orderService: OrderService,
    private readonly paymentService: PaymentService,
    private readonly inventoryService: InventoryService,
    private readonly notificationService: NotificationService,
  ) {}

  async createOrder() {
    await this.orderService.create();

    await this.paymentService.pay();

    await this.inventoryService.decreaseStock();

    await this.notificationService.send();
  }
}

class OrderController {
  constructor(
    private readonly orderFacade: OrderFacade
  ) {}

  async create() {
    await this.orderFacade.createOrder();
  }
}

مثلا تو ثبت نام یوزر چندتا سرویس داریم مثل یوزر سرویس ، توکن سرویس ، ایمیل سرویس ، و.. اینجا این پترن خیلی به کار میاد

درود دوستان شرمنده به علت مشغله زیاد کمتر میتونم پست بسازم و حتی یادگیریم هم کمتر شده ولی خب ما ادامه داریم

proxy pattern
بر فرض مثال به سرویس داریم
میخواییم توی سرویس اتورایزیشن، کش ، ریت لیمیت و.. داشته باشیم
ایا سرویس شلوغ نمیشه ؟

اینجا پروکسی پترن میاد و میگه که یه ابجکت واسطه رو بیار جلوی ابجکت اصلی قرار بده تا دسترسی ها به ابجکت اصلی رو کنترل کنی

پروکسی سرویس اصلی نیستش و فقط سرویس اصلی رو کنترل میکنه
و همون اینترفیس سرویس اصلی‌رو داره

مثال :

interface UserService { getUser(id: string): Promise<User>; }
class UserServiceImpl implements UserService { async getUser(id: string): Promise<User> { console.log("Fetching user from database");
return {
  id,
  name: "Amir",
};
} }

class CachedUserServiceProxy implements UserService { private cache = new Map<string, User>();
constructor( private readonly service: UserService ) {}
async getUser(id: string): Promise<User> { const cached = this.cache.get(id);
if (cached) {
  console.log(`Returning cached user: ${id}`);
  return cached;
}
const user = await this.service.getUser(id);

this.cache.set(id, user);

return user;
} }

const userService = new UserServiceImpl();
const proxy = new CachedUserServiceProxy(userService);

await proxy.getUser("123"); // میره دیتابیس
await proxy.getUser("123"); // از کش میاره ✅

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

ممنون از حمایت ها و ریکشناتون 🤍🙏🏼

دوستان ایدیم به
@VebIag
تغییر کرد 🤍👋🏼

داداش کدت پر از if/else/switche هستش؟

مثلا میخوای تخفیف رو محاسبه کنه میگه اگه یوزر حدید بود انقد باشه اگه بلک فرایدی بود انقد باشه اگه فلان قدر خرید داشت انقدر باشه و..
هرچی اینا بیشتر هم کد بزرگ تر هم پیچیده تر

Staregy pattern
این پترنه میگه که به جای اینکه بیای همه ی روش هارو داخل یه کلاس بنویسی هر روش رو جدا کن و بزارش پشت یه اینترفیس

مثلا :

interface DiscountStrategy {
  calculate(price: number): number;
}

class BlackFridayDiscount implements DiscountStrategy {
  calculate(price: number): number {
    return price * 0.5;
  }
}

class NewUserDiscount implements DiscountStrategy {
  calculate(price: number): number {
    return price * 0.9;
  }
}

حالا تو سرویس دیگه مهم نیست تخفیف چطوری محاسبه میشه

class CheckoutService {
  constructor(
    private readonly discountStrategy: DiscountStrategy
  ) {}

  calculateTotal(price: number): number {
    return this.discountStrategy.calculate(price);
  }
}

فقط موقع استفاده تصمیم میگیریم که کدوم استراتژی رو بدیم بهش

const checkout = new CheckoutService(
  new VipDiscount()
);

checkout.calculateTotal(100);

پس استراتژی سرویس میشه انتخاب بین چند روش مختلف برای انجام یک کار

کاربردهاش :
روش های مختلف پرداخت ، محاسبه تخفیف ، روش های مختلف ارسال، روش های احراز هویت ، روش های مختلف ناتیفیکیشن و کلی چیز دیگه ک الان حضوز ذهن ندارن

ممنون از حمایت ها و ریکشن هاتون 🤍🙏🏼

migration
ینی ثبت تغییرات دیتابیس به صورت مرحله به مرحله تا وقتی پروژه روی یه سیستم دیگه ای بالا اومد دیتابیس دقیقا با همون تغییرات بالا بیاد و اپدیت بشه
ما با مایگریشن مرحله های مختلف تغییراتی که داریم رو مینویسیم و اجرا میکنیم
مثلا تو دولوپمنت اول کار تیبل یوزر رو ساختیم بعدش ستون تلفن رو بهش اضافه کردیم بعدش به تیبل دیگه اضافه کردیم
حالا اگه بیا

استفاده نکردن ازش لوزوما پروژه رو خراب نمیکنه ولی مدیریت دیتابیس رو سخت میکنه چرا؟
مثلا امروز یه چیزی دستی ب دیتابیس اضافه کردی حالا وقتی یکی دیگه پروژه میخواد دیپلوی کنه باید همین تغییر رو دوباره دستی اضافه کنه
ولی مایگریشن داشتی باشه به ترتیب همه ی تغییراتی که داشتی رو میتونی مدیریت کنی

یه سرچ بزنی کل مطلب نابی میاد تو دستت من چیزی ک به فکرم اومد رو برات نوشتم