=))) a có push lên github ko cho em xin clone về nghịch với

Vậy SSR dưới BE phải build html rồi trả về FE đúng ko b. B có thể nói qua cách build html dưới BE thế nào đc ko. Kiểu FE phải nhìn giao diện mới căn content đc, chứ BE thì sao mà thấy đc nhỉ, hay là nháp bằng FE rồi paste file sang BE. Có gì chỉ giáo mình nhé ^^

Cảm ơn bác rất nhiều, nghe một mentor có nói về bác từ lâu mà nay mới đọc bài của bác, mà đọc cuốn quá không dứt ra được

Cảm ơn những chia sẻ hết sức quý báu của bác ạ,

Ước có mentor nào đó

chào bạn,trong django có custome field như handfield ,làm sao ghi admin.py để cái hand filed xuất hiện trong trang admin

À cảm ơn bạn đóng góp nhé. Mình lỗi chính tả tòe loe. Nhưng mình k định hướng các bài viết của mình theo văn bản hành chính hay dùng làm tài liệu document cho hãng. Mình thấy ae dev cũng dễ tính thôi, đọc hiểu là được. Đơn thuần chia sẻ thôi. Bạn k thích có thể k đọc ạ

@Clarence161095

@huukimit Lầu ngày quá ha, 😂 Quá chuẩn luôn! Thật sự không nên cứng nhắc áp dụng nguyên tắc SOLID vào tất cả trường hợp có thể. Tuy nhiên, việc hiểu rõ nó cũng giúp ích khá nhiều trong công việc hiện tại của mình.

Mình đã học về SOLID này cách đây khoảng 7-8 năm, nhưng cứ thỉnh thoảng ôn lại, mình vẫn nghiệm ra được nhiều điều mới. Đặc biệt gần đây, khi phải xây dựng nhiều bộ source code mới cho dự án, mình đã cân nhắc kỹ lưỡng khi đặt nền móng. Thường thì mình sẽ code một vài module nhỏ để các đồng nghiệp có thể tham khảo và làm theo.

Vì dự án thường được triển khai bởi đội ngũ offshore, nên cấu trúc code cần phải dễ mở rộng và đặc biệt là dễ kiểm thử, nhất là với automated testing. Đây cũng là bài học xương máu khi các module quá phụ thuộc vào nhau, dẫn đến việc kiểm thử trở nên vô cùng khó khăn.

Tuy nhiên, cuối cùng thì như @huukimit ông nói, SOLID không phải là luật bất di bất dịch. Việc áp dụng không nên quá cứng nhắc. Nhưng nếu thật sự nắm vững SOLID và Clean Code, nó sẽ giúp ích rất nhiều trong quá trình lập trình của chúng ta.

Mình thấy điểm quan trọng không kém đó là SOLID không phải là luật bất di bất dịch. Chúng ta không cần phải quá cứng nhắc viết code phải đáp ứng đủ cả 5 nguyên tắc. Miễn sao khi nhìn vào những dòng code,người đọc thấy nó dễ đọc, dễ hiểu là được.

🤣🤣🤣

Tính ra mình code vi phạm hết bà 5 nguyên lý , nhưng nó run được ))))

@refacore ♥️

ko sài đc nữa rầu

Chính xác. Như mình đã đề cập trong bài, nó chỉ tối ưu hơn khi bạn sử dụng map nhiều lần. Còn thật sự trong trường hợp bạn chỉ sử dụng map 1 lần thì không có khác biệt. Việc áp dụng Map phải thật sự cân nhắc rõ ràng trong các trường hợp cụ thể, vì cái gì sinh ra cũng có chức năng của nó. Cảm ơn bạn đã commnet nhé. 🙌🫶

Ở ví dụ phía trên khi tạo mới Map vẫn phải gọi hàm .map khởi tạo value cho nó thì cũng đã trải qua vòng lặp rồi => cũng chưa thực sự tối ưu lắm.

const bookMap = new Map(books.map(book => [book.isbn, book]));

@H003g nghĩ ra, nói ra là bước đầu tiên để hiểu ra. a vẫn upvote bài viết

Interface segregation: cách giải thích dễ nhầm tưởng mỗi method tách 1 interface.

ShapeCalculator là một lớp đặc thù và việc nó có 3 phương thức tính chu vi, diện tích, thể tích là hoàn toàn hợp lý, không có gì sai cả. Vậy nếu có interface IShapeCalculator thì nó nên có cả 3 phương thức.

Nếu 3 phương thức trên thuộc về Shape thì lại khác. Chu vi và diện tích thì của hình 2D, diện tích và thể tích lại của hình 3D, việc gom cả 3 hành vi vào 1 interface là không thể nên cần tách ra để giữ được sự mềm dẻo.

public class Circle: IHasArea, IHasPerimeter
{
  public number GetArea();
  public number GetPerimeter();
}

public class Cube: IHasArea, IHasVolume
{
  public number GetArea();
  public number GetVolume();
}

Liskov thì có 2 ví dụ kinh điển:

1. Con vịt trời và con vịt cao su không thể thay thế cho nhau dù cùng là vịt. Phương thức bay của giống vịt sẽ gây lỗi nếu là gọi từ instance con vịt cao su.
2. Shape. Nếu trừu tượng hóa các đa giác theo số cạnh của nó, các hành vi của nó sẽ không hoạt động giống nhau với mỗi mỗi hình khác nhau. Tam giác có cách tính diện tích khác. Hình vuông có cách tính diện tích khác tam giác (khác số cạnh), và khác hình chữ nhật (dù cùng số cạnh). Cho nên các hình chỉ đơn giản là thừa kế IShape với phương thức computeSurface mà thôi.

Thực ra ví dụ trên vẫn trừu tượng. Hãy xét một bài toán về e-commerce, cách implement chương trình khuyến mãi hay giảm giá cho sản phẩm là coupon (voucher) và giảm giá - discount. Liệu chúng ta có thể tạo một parent chung cho cả hai phương thức là ISaleProgram được không?

public interface ISaleProgram {}

public class Voucher : ISaleProgram {}

public class Discount : ISaleProgram {}

public class Order 
{
  private readonly IEnumerable<ISaleProgram> salePrograms;

  public number Pay()
  {
    var totalCost = items.Sum(i => i.Price);

    var afterTax = totalCost * 1.1; // tax 10%

     var matchedSalePrograms = allSalePrograms.Where(p => p.IsMatched(this));

     var totalDiscountAmount = matchedSaleProgames.Sum(p => p.Discount(this));

     return afterTax - totalDiscountAmount;
  }
}

Tổng quan thì là hợp lý, nhưng có sự khác biệt đối với 2 phương thức trên:

• Voucher: trừ thẳng tiền mặt, tính sau thuế. Thuế tính theo giá gốc.
• Discount: trừ giá trước thuế, thuế tính trên giá mới.

Như vậy Voucher được tính sau khi tính tổng hóa đơn rồi trừ đi. Discount được tính trong khi tính tổng hóa đơn. Sự khác biệt này sẽ làm chương trình tính giá bị lỗi nếu chúng ta coi Voucher và Discount là cùng họ. Hai cách tính là khác nhau và tham gia vào hai bước khác nhau của quá trình tính giá phải trả.

Bài của e chán quá, a xem mấy cái còn lại có vấn đề gì không, a sửa giúp e với nhé

@refacore Cảm ơn bạn đã chia sẻ