DEV Community: Nguyễn Anh Tuấn

Lynx: Giải pháp mới cho ứng dụng đa nền tảng - JS Engine

Nguyễn Anh Tuấn — Thu, 13 Mar 2025 02:21:38 +0000

Vì sao Lynx nhanh và nhấn mạnh đặc điểm không bị màn hình trắng (blank screen)?

Định nghĩa NHANH ở đây có thể xem xét đến yếu tố hiệu năng, và yếu tố cảm giác phản hồi.

Như ở bài trước tôi có đề cập tới con số 0.1s, nếu UI cập nhật dưới ngưỡng này thì cho ta cảm giác chung là hệ thống phản hồi ngay lập tức, ta có cảm giác nó nhanh, còn thực sự tác vụ tính toán đó đã hoàn thành hay chưa thì tạm chưa bàn đến.

Lynx có cách tiếp cận hướng người dùng, nghĩa là nó đang hướng tới sự chiều chuộng khách hàng, cho người ta có cảm giác UI phản hồi ngay tức khắc.

Để đáp ứng được hướng tiếp cận này thì đội ngũ Lynx đã chọn cách build PrimJS JS engine dựa trên QuickJS, đây một engine JS nhúng (embeddable Javascript engine) với các đặc điểm sau:

Siêu nhẹ 210 KiB, nó không sử dụng bất kỳ depenency nào
Sử dụng ngôn ngữ C
Chiếm dụng cực ít tài nguyên RAM
Thời gian khởi động rất nhanh
Sử dụng trình dọn rác đơn giản
QuickJS là một Intepreter JS engine, không hỗ trợ JIT (Just In Time)

Đội ngũ thực hiện một số thay đổi trên PrimJS khiến nó tối ưu hơn QuickJS như:

Tối ưu interpreter: hỗ trợ cache và cải thiện hiệu năng
Tích hợp mô hình đối tượng liền mạch: các object của JS Engine tích hợp hiệu quả với Lynx Object, giảm thiểu trao đổi thông tin và nâng cao hiệu suất (để so sánh thì React Native old Arch từng bị nghẽn cổ chai khi thực hiện batching message qua bridge)
Trình dọn rác nâng cao: phân tích bộ hiệu quả hơn, giảm thiểu rủi ro leak memory. (QuickJS nguyên bản chỉ đơn giản là tìm, đếm và dọn các reference)
Hỗ trợ trình debug Chrome đầy đủ (Chrome DevTools Protocol)

Vậy là Lynx được thừa hưởng toàn bộ các ưu điểm của QuickJS cộng thêm các tính năng custom riêng.

Mặc dù QuickJS có nhiều ưu điểm nhưng để so sánh với Engine V8 thì cũng có những điểm chưa tốt bằng.

Ví dụ như:

V8 parse JSON (large object) hết đâu đó tầm ~50ms, trong khi QuickJS thì chậm hơn 2-3 lần.
V8 loop 100M iteration trong ~100-150ms, còn QuickJS thì chậm hơn 3-4 lần.

Tuy vậy, mỗi JS engine lại có ưu điểm riêng biệt khiến nó nổi trội hơn trong những use case cụ thể.

Điển hình trong trường hợp này Lynx đánh đổi việc tối ưu thời gian khởi động cũng như giảm thiểu communicate giữa các object khiến nó trở nên hiệu quả, một hướng tiếp cận khá thông minh.

Mình đang xây dựng Cộng đồng Lynx Vietnam tại: https://lynx-vietnam.dev, các bạn có ý kiến đóng góp hoặc yêu cầu gì xin vui lòng comment bên dưới. Mình rất trân quý và sẽ nỗ lực hết sức để giúp ích nhiều hơn cho cộng đồng.

Chúc các bạn ngày mới làm việc hiệu quả.

[edit]:

Trong phần lớn trường hợp RN dùng Hermes
Nếu Hermes bị disable thì nó sẽ chuyển qua dùng JSC (Javascript Core).
Khi dùng Chrome debug thì code sẽ thực thi trên Chrome vốn sử dụng V8

Lynx: Giải pháp mới cho ứng dụng đa nền tảng - Giới thiệu

Nguyễn Anh Tuấn — Thu, 13 Mar 2025 02:20:21 +0000

Lynx là một framework mới, ra mắt vào ngày 05/03/2025, được thiết kế để khắc phục những hạn chế của các nền tảng phát triển ứng dụng đa nền tảng hiện tại như React Native và Flutter.

Lynx giúp các lập trình viên web có thể tận dụng ngay kỹ năng của mình để xây dựng ứng dụng di động và web từ một mã nguồn duy nhất, mà không cần phải học thêm một ngôn ngữ lập trình mới.

Với mục tiêu đạt hiệu suất cao và mang đến trải nghiệm người dùng mượt mà, Lynx đem lại một cách tiếp cận hoàn toàn mới trong việc phát triển ứng dụng đa nền tảng.

Vì sao Lynx ra đời?

Hiện nay, React Native và Flutter là hai nền tảng phổ biến nhất để xây dựng ứng dụng di động đa nền tảng. Tuy nhiên, cả hai đều có những hạn chế nhất định:

React Native sử dụng JavaScript/TypeScript, cho phép tái sử dụng mã nguồn.
Tuy nhiên, nó gặp vấn đề về hiệu suất do phải sử dụng cầu nối (bridge) để giao tiếp giữa JavaScript và mã native.
Dù đã có New Architecture, nhưng React Native vẫn đối mặt với lỗi màn hình trắng (blank screen) khi ứng dụng khởi chạy hay khi scroll nhanh một Flatlist nhiều item với các item có chiều cao bất kỳ.

Flutter có hiệu suất gần như ứng dụng native, nhưng lại yêu cầu lập trình viên học ngôn ngữ Dart – một rào cản không nhỏ. Đồng thời, việc tận dụng lại kỹ năng của web developers là không khả thi, khiến nhiều người không thể chuyển đổi nhanh chóng sang Flutter.
Lynx ra đời để giải quyết những vấn đề này bằng cách cung cấp một framework:

✅ Hiệu suất cao như Flutter
✅ Dễ tiếp cận như React Native
✅ Tận dụng công nghệ web (HTML, CSS) giúp lập trình viên nhanh chóng xây dựng ứng dụng đa nền tảng.

Vì sao Lynx nhanh?

Lynx có một cải tiến quan trọng trong kiến trúc, giúp tăng tốc độ xử lý bằng cách chia script thành hai luồng chạy song song:

Main Thread – Luồng chính
👉 Sử dụng PrimJS, một engine JavaScript tốc độ cao, được tối ưu riêng cho Lynx.
👉 Xử lý các tác vụ UI đồng bộ như khởi chạy ứng dụng và các sự kiện có độ ưu tiên cao.
Background Thread – Luồng nền
👉 Xử lý phần lớn mã của lập trình viên, giúp giảm tải công việc trên Main Thread.
👉 Đảm bảo ứng dụng chạy mượt mà, không bị blocking, ngay cả khi thực thi các tác vụ phức tạp.

Nhờ vào kiến trúc này, Lynx có thể đạt được hai tính năng quan trọng giúp tăng tốc độ xử lý:

🔥 Instant First-Frame Rendering (IFR)
Theo nghiên cứu từ Nielsen Norman Group, thời gian phản hồi dưới 0.1 giây khiến người dùng cảm nhận ứng dụng phản hồi ngay lập tức [Nguồn https://www.nngroup.com/articles/response-times-3-important-limits].

Lynx chặn Main Thread cho đến khi khung hình đầu tiên được vẽ hoàn chỉnh, giúp loại bỏ hiện tượng màn hình trắng (blank screen) khi mở ứng dụng. Điều này giúp tạo ra trải nghiệm người dùng mượt mà và tức thì.

🚀 Main Thread Scripting (MTS)
Lynx có một cơ chế đặc biệt: một đoạn mã tĩnh nhỏ sẽ được lập lịch và chạy trên Main Thread.
👉 Ưu tiên xử lý các sự kiện UI quan trọng như cử chỉ (gestures) và thao tác người dùng.
👉 Đảm bảo giao diện luôn mượt mà, không bị giật lag, mang lại trải nghiệm nhanh như ứng dụng native.

Kết luận
Lynx không chỉ giúp các lập trình viên web dễ dàng xây dựng ứng dụng đa nền tảng, mà còn giải quyết những vấn đề về hiệu suất mà các framework trước đây gặp phải.
Lynx hứa hẹn sẽ trở thành một lựa chọn hàng đầu cho việc phát triển ứng dụng di động và web trong tương lai. 🚀

[còn tiếp]

Review code

Nguyễn Anh Tuấn — Sun, 28 Jan 2024 03:42:06 +0000

Review code là gì?

Review code là một hoạt động quan trọng trong quá trình phát triển phần mềm, nơi các đồng nghiệp kiểm tra và đánh giá chéo mã code của nhau.

Vì sao cần review code?

Việc con người gây ra lỗi là điều không mong muốn nhưng cũng không hoàn toàn tránh được (Có nhiều yếu tố khiến con người gây ra lỗi như thể trạng sức khỏe, tâm lý, tiếng ồn, suy giảm sự tập chung, etc...). Vì vậy chúng ta cần review code để giảm thiểu rủi ro tiềm tàng cho hệ thống càng sớm càng tốt.

Mục tiêu chính của việc review code bao gồm:

Tìm và sửa lỗi
Đảm bảo code tuân thủ các tiêu chuẩn, các nguyên tắc mà dự án đang áp dụng
Cung cấp cơ hội chia sẻ kiến thức giữa các thành viên
Gia tăng giao tiếp giúp các thành viên hiểu nhau hơn

Các vấn đề chính khi review code

Bạn cần tạo ra một danh sách (checklist) những câu hỏi và quy tắc được xác định trước mà dự án (và nhóm của bạn) sẽ tuân theo trong quá trình review.

Danh sách này thường tập chung vào các vấn đề chính sau:

Readability (Khả năng đọc): Có bất kỳ đoạn comment dư thừa nào trong code không?
Security (Bảo mật): Đoạn mã có khả năng khiến hệ thống bị tấn công mạng không?
Test coverage (Độ bao phủ test): Có cần thêm các test case khác không?
Architecture (Kiến trúc): Mã có tính bao đóng, mô đun hóa để đạt được sự phân tách mối quan ngại không (separation of concerns)? Pattern áp dụng có chính xác không?
Reusability (Khả năng tái sử dụng): Mã có tái sử dụng các components, functions hay services có sẵn không?

Bằng cách kiểm tra danh sách câu hỏi những vấn đề trong đoạn code sẽ được phơi bày một cách chi tiết và tường minh, không mang cảm tính. Việc sửa lỗi cũng trở nên rõ ràng và dễ hiểu hơn.

Những lưu ý khi review code

Để lại review chi tiết

Khi bạn review code, đừng chỉ để lại những đánh giá chung chung hoặc chỉ gợi ý thay đổi, thay vào đó hãy giải thích vấn đề hiện tại là gì, vì sao nên thực hiện thay đổi.

Vì sao cần giải thích chi tiết như vậy?

Đó là cách mà bạn biện minh cho nhận xét của mình, họ sẽ k cần hỏi lại bạn vì sao nên thực hiện những thay đổi mà bạn khuyến nghị. Điều này sẽ tiết kiệm thời gian cho bạn và cho người đánh giá.
Bạn review code cẩn thận hơn, không xuề xòa cho qua, nói có sách, mách có chứng.
Người được đánh giá code sẽ biết lý do cụ thể vì sao họ cần thực hiện thay đổi, điều này giúp họ giải quyết vấn đề tương tự trong tương lai.

Giữ thái độ đúng mực, cầu tiến

Việc review code suy cho cùng là khiến cho con tàu đi đúng hướng, mục tiêu dự án hoàn thành một cách đúng đắn. Mọi người cần giữ thái độ đúng mực, cầu tiến khi review cũng như khi nhận được review. Hãy loại bỏ yếu tố cảm xúc để tránh ảnh hưởng tới công việc.

Nếu bạn viết code chưa được tốt, những feedback đáng giá sẽ giúp bạn viết code tốt hơn, điều này tốt cho bạn.

Không review đoạn code dài hơn 200 dòng

Nghiên cứu tại Cisco Systems năm 2006 chỉ ra rằng khả năng tìm ra bug của developer giảm dần khi phải review nhiều hơn 200 dòng code.

Mỗi commit chỉ nên chứa một ý nghĩa

Những commit chứa quá nhiều code, nhiều thay đổi không liên quan tới nhau cũng làm giảm khả năng khôi phục mã code trong các nhánh (branch) đồng thời cũng làm khó người review.

Ví dụ: bạn có một commit đảm nhiệm 02 thay đổi: format code, add thêm business logic

Khi này bạn cần tách ra làm 02 commit riêng lẻ, 01 commit cho format code, 01 commit cho việc add thêm business logic.

Tự động hóa quá trình review codeTrên thị trường có nhiều công cụ review code tự động có thể kể đến SonarQube, ESLint, SwiftLint, JSHint, Codestriker, Deepscan etc...

Tùy thuộc dự án và chi phí mà bạn tìm công cụ phù hợp với mình.

Đa phần các công cụ này đều rất dễ dàng tích hợp vào CI/CD, developer có thể nhận được phản hồi rất sớm sau khi commit code (hoặc trước khi commit code như sử dụng precommit kết hợp Linter).

Việc này cũng làm giảm tải đáng kể cho người review.

Tuy nhiên những công cụ này không hoàn toàn thay thế cho con người được, có thể kể đến những nguyên tắc mà team bạn đề ra, lấy ví dụ như SOLID principles, bạn cần yếu tố con người để review khía cạnh này một cách chuẩn xác hơn.

Developer cần hiểu rõ trách nhiệm

Dù review code giúp nâng cao chất lượng code và giảm thiểu lỗi, tuy nhiên không ai chắc chắn 100% phương pháp này sẽ loại bỏ hoàn toàn những lỗi tiềm tàng.

Bạn với tư cách là người viết code cần chịu trách nhiệm cao nhất về tính đúng đắn của code.

Kết bài

Code review là một hoạt động thú vị nhưng mất thời gian và công sức. Tuy nhiên kết quả có tốt hay không còn phụ thuộc vào sự cam kết của team bạn.

Team bạn áp dụng quy trình review code như thế nào?

Nếu bạn thấy bài viết này còn thiếu sót hay cần bổ sung gì thì đừng ngần ngại liên hệ với mình qua các kênh mxh bên dưới nhé.

Chúc bạn và team có những buổi review code hiệu quả.

Bài viết gốc tại đây

Dependency Inversion Principle (DIP)

Nguyễn Anh Tuấn — Wed, 13 Dec 2023 15:04:26 +0000

Tiếp nối chuỗi bài SOLID principles, bài này chúng ta cùng tìm hiểu nguyên tắc đảo ngược phụ thuộc (dependency inversion principle) là gì và nó quan trọng ra sao nhé.

Đây là nguyên tắc cuối cùng trong bộ 05 nguyên tắc SOLID.

Dependency Inversion Principle (DIP) là gì?

Nguyên tắc đảo ngược phụ thuộc (DIP) là nguyên tắc mà trong đó nhấn mạnh module cấp cao chỉ được phụ thuộc vào các lớp trừu tượng (abstraction/interface) của module cấp thấp.

Nguyên tắc này được giới thiệu bởi Robert C. Martin hay còn gọi là Uncle Bob.

Có thể thấy Uncle Bob đã đóng góp 3/5 nguyên tắc trong bộ SOLID principles bao gồm:

Trong định nghĩa trên có 02 điểm chưa rõ ràng, module cấp cao là gì? module cấp thấp là gì?

Module cấp cao (high-level modules) là gì?:

Là các module mà trong đó nó phụ thuộc vào các module cấp thấp khác để implement business logic với mục đích cụ thể như xử lý thanh toán giỏ hàng, book lịch họp etc...

// high-level module
class OrderProcessorService {
    // PaymentRepository and ShippingRepository are injected too loose coupled
    constructor(private payment: PaymentRepository, private shipping: ShippingRepository) { }

    checkout() {
        const result = this.payment.process()
        if (result) {
            this.shipping.process()
        }
    }
}

Ở ví dụ này module OrderProcessorService là module cấp cao, nó phụ thuộc vào module cấp thấp hơn là PaymentRepository và ShippingRepository (trình bày bên dưới).

Module cấp thấp (low-level modules) là gì?:

Ngược lại với module bậc cao, module cấp thấp là các module mà trong đó nó có thể hoạt động độc lập, không phụ thuộc vào bất cứ module nào khác. Nó có thể dễ dàng tái sử dụng ở bất kỳ đâu mà không bị ràng buộc vào phụ thuộc nào khác.

// abstraction
interface PaymentRepository {
    process(): void
}

// abstraction
abstract class ShippingRepository {
    abstract process(): void
}

// low-level module
class PaypalPaymentRepository implements PaymentRepository {
    process(): void {
        // call Paypal API
        console.log('Processing paypal payment')
    }
}

// low-level module
class AirplaneShippingRepository extends ShippingRepository {
    process(): void {
        // call Delivery API
        console.log('Processing shipping with A320 Airplane')
    }
}

Ở ví dụ này, các module cấp thấp như PaymentRepository, ShippingRepository không phụ thuộc vào bất cứ module nào khác, vì thế 02 modules này rất linh hoạt trong việc tái sử dụng.

Hãy làm rõ hơn vấn đề qua ví dụ sau

Ví dụ vi phạm nguyên tắc đảo ngược phụ thuộc (DIP)

// Violating DIP

// concrete implemented class
class SMSSender {
    send(message: string): void {
        console.log(`sending SMS: ${message}`)
    }
}

class NotificationService {
    // violate since NotificationService depend on concrete implementation of SMSSender
        private sender = new SMSSender(); // tight coulped

    send(message: string): void {
        this.sender.send(message)
    }
}

const notiService = new NotificationService()

Ở ví dụ này, high-level module NotificationService phụ thuộc vào low-level module SMSSender trong khi nguyên tắc chỉ ra rằng module bậc cao chỉ được phụ thuộc vào lớp trừu tượng (abstract/interface) của module bậc thấp.

Việc phụ thuộc vào một module/class đã được implement chi tiết là vi phạm nguyên tắc.

Ví dụ tuân theo nguyên tắc đảo ngược phụ thuộc (DIP)

Chúng ta hãy thiết kế lại ví dụ trên để tuân theo nguyên tắc đảo ngược phụ thuộc nhé.

// Adhering DIP

interface SenderRepository {
    send(message: string): void
}

// low-level module
class SmsSenderRepository implements SenderRepository {
    send(message: string): void {
        // calling sms api
    }
}

// low-level module
class EmailSenderRepository implements SenderRepository {
    send(message: string): void {
        // calling smtp
    }
}

// high-level module
class NotificationService {
    // adhering since NotificationService depend on an abstraction of low-level abstraction/interface
    constructor(private sender: SenderRepository) { } // loose coupled by using dependency injection

    send(message: string): void {
        this.sender.send(message)
    }
}

const smsSenderRepository = new SmsSenderRepository()
const notiServiceSMS = new NotificationService(smsSenderRepository)

const emailSenderRepository = new EmailSenderRepository()
const notiServiceEmail = new NotificationService(emailSenderRepository)

Ở ví dụ này mình đã triển khai interface SenderRepository, class NotificationService nay chỉ phụ thuộc vào interface SenderRepository, bạn có thể truyền bất cứ class nào implement interface SenderRepository đều được.

Chúng ta sử dụng kỹ thuật tiêm vào sự phụ thuộc (Dependency injection technique) để truyền bất cứ class nào implement interface SenderRepository vào class NotificationService

Một vài khái niệm nhắc đến trong bài:

Dependency injection: Là một kỹ thuật mà trong đó các class hoặc module nhận instance/object của class phụ thuộc thông qua constructor thay vì khởi tạo instance đó trong class chỉ định.

  interface PaymentRepository {
    ...
  }

  // low-level module
  class MomoPaymentRepository implements PaymentRepository {
    ...
  }

  // high-level module
  class ShoppingCartService {
    constructor(private payment: PaymentRepository) {} // depend on PaymentRepository interface
  }

  const momoPaymentRepo = new MomoPaymentRepository()
  const shoppingCartService = new ShoppingCartService(momoPaymentRepo) // inject dependency momoPaymentRepo into class via constructor

tight coupled: Liên kết chặt chẽ. Điều này không tốt, các module phụ thuộc chặt chẽ sẽ làm giảm khả năng mở rộng, nâng cấp.

Xét ví dụ sau

  class PaymentRepository implements BasePaymentRepository {
    ...
  }

  class OrderProcessorService {
    private payment = new PaymentRepository() // tight coupled
  }

  const orderProcessorService = new OrderProcessorService()

loose coupled: Liên kết lỏng lẻo. Việc này khiến các module trở nên độc lập hơn, dễ mở rộng và nâng cấp hơn.

Thiết kế lại ví dụ bên trên

  class PaymentRepository implements BasePaymentRepository {
    ...
  }

  class OrderProcessorService {
    constructor(private payment: BasePaymentRepository) {} // loose coupled
  }

  const paymentRepository = new PaymentRepository()
  const orderProcessorService = new OrderProcessorService(paymentRepository) // dependency injection paymentRepository

Unit test

Codebase tuân theo SOLID principles luôn luôn nhấn mạnh tính dễ bảo trì, linh động và khả năng test cao. Vì thế mình luôn luôn cung cấp unit test để trình diễn khả năng này.

describe("SmsSenderRepository", () => {
    it("able to send SMS", () => {
        const smsSenderRepo = new SmsSenderRepository()
        expect(smsSenderRepo.send("test")).not.toThrow()
    })
})

describe("EmailSenderRepository", () => {
    it("able to send email", () => {
        const emailSenderRepo = new EmailSenderRepository()
        expect(emailSenderRepo.send("test")).not.toThrow()
    })
})

describe("NotificationService", () => {
    it("able to send sms", () => {
        const smsSenderRepository = new SmsSenderRepository()
        const notiServiceSMS = new NotificationService(smsSenderRepository)
        expect(notiServiceSMS.send("test")).not.toThrow()
    })

    it("able to send email", () => {
        const emailSenderRepository = new EmailSenderRepository()
        const notiServiceEmail = new NotificationService(emailSenderRepository)
        expect(notiServiceEmail.send("test")).not.toThrow()
    })
})

Hỏi đáp

Q: Làm sao để ứng dụng nguyên tắc đảo ngược phụ thuộc vào code của bạn?

A: Để ứng dụng nguyên tắc đảo ngược phụ thuộc, tôi làm theo các bước sau:

Tạo ra các module cấp cao phụ thuộc vào lớp trừu tượng chứ không phụ thuộc vào lớp cụ thể.
Tạo ra các module cấp thấp implements/extends lớp trừu tượng mà module cấp cao phụ thuộc vào.
Sử dụng kỹ thuật dependency injection để cung cấp object của module cấp thấp cho module cấp cao.

Kết luận

Nguyên tắc đảo ngược phụ thuộc (Dependency Inversion Principle) giúp chúng ta thiết kế ra các module/class theo hướng dễ dàng mở rộng và không bị ràng buộc chặt chẽ vào module khác.

Đây là cũng nguyên tắc cuối cùng trong bộ 05 nguyên tắc SOLID. Mong các bạn đọc kỹ từng bài và thực hành thuần thục hơn.

Nếu bạn phát hiện sai sót, đừng ngần ngại báo lại cho mình qua các kênh mạng xã hội bên dưới website.

Tiếp nối chủ đề SOLID principles, bài viết tiếp theo mình sẽ tạo ra một ứng dụng cơ bản ứng dụng các nguyên tắc SOLID để các bạn có cái nhìn tổng thể.

Chúc bạn ngày mới tốt lành, nếu thấy bài viết hữu ích đừng quên chia sẻ và lan tỏa nhé.

Bài viết gốc tại đây

Interface Segregation Principle (ISP)

Nguyễn Anh Tuấn — Tue, 12 Dec 2023 09:49:19 +0000

Tiếp theo chuỗi bài về SOLID principles, bài này chúng ta sẽ tìm hiểu về nguyên tắc phân tách Interface nhé

Interface Segregation Principle (ISP) là gì?

Nguyên tắc phân tách Interface khẳng định rằng không nên buộc các entities (như class, module...) phải phụ thuộc vào các phương thức (method) mà nó không sử dụng đến.

Hay giải thích bằng cách khác: Bạn không nên tạo ra interface lớn, mục đích chung chung bao gồm quá nhiều method, hãy ưu tiên tạo ra nhiều interface nhỏ, mục đích cụ thể. Theo đó các class chỉ cần implement các interface mà nó thực sự dùng đến.

Nguyên tắc này được giới thiệu bởi Robert C. Martin hay còn gọi là Uncle Bob

Nghe có vẻ khó hiểu phải không?

Chúng ta hãy làm rõ vấn đề qua các ví dụ nhé.

Ví dụ về sự vi phạm nguyên tắc phân tách interface (ISP)

interface Worker {
    work(): void;
    eat(): void;
    sleep(): void;
}

class Person implements Worker {
    eat() {
        console.log('Person can eat')
    }

    work() {
        console.log('Person can work')
    }

    sleep() {
        console.log('Person can sleep')
    }
}

class Robot implements Worker {
    eat() {
        // forced to eat => violate
        console.log('Robot cannot eat')
    }

    work() {
        console.log('Robot can work')
    }

    sleep() {
        // forced to eat => violate
        console.log('Robot cannot sleep')
    }
}

Ở ví dụ này ta thấy class Person hoàn toàn có đủ các hành vi như work eat và sleep nhưng điều này không hoàn toàn đúng với class Robot

Robot không eat mà cũng không sleep, việc ép buộc class Robot phải implement 02 method này đã vi phạm nguyên tắc phân tách interface.

Chúng ta cùng thiết kế lại ví dụ trên theo nguyên tắc phân tách interface nhé

Ví dụ tuân theo nguyên tắc phân tách interface

// Adhering

interface Eatable {
    eat(): void;
}

interface Workable {
    work(): void;
}

interface Sleepable {
    sleep(): void;
}

class Person implements Eatable, Workable, Sleepable {
    eat() {
        console.log('Person can eat')
    }

    work() {
        console.log('Person can work')
    }

    sleep() {
        console.log('Person can sleep')
    }
}

class Robot implements Workable {
    work() {
        console.log('Robot can work')
    }
}

Ở ví dụ này chúng ta đã phân tách các hành vi ra thành các interface riêng biệt.

Với class Person, hiển nhiên con người có thể eat work và sleep nên chúng ta implement toàn bộ 3 interface Eatable Workable và Sleepable

Còn với class Robot, rotbot chỉ có thể work nên chúng ta chỉ implement interface Workable

Điều này giúp làm giảm lượng code rác, không cần thiết và cũng khiến cho hệ thống linh hoạt hơn, implement vừa đủ, không thừa không thiếu

Unit test

Tiết mục unit test quen thuộc lại xuất hiện

describe("Person", () => {
  it("able to eat", () => {
    const person = new Person()
    expect(person.eat()).not.toThrow()
  })
  it("able to work", () => {
    const person = new Person()
    expect(person.work()).not.toThrow()
  })
  it("able to sleep", () => {
    const person = new Person()
    expect(person.sleep()).not.toThrow()
  })
})

describe("Robot", () => {
  it("able to work", () => {
    const robot = new Robot()
    expect(robot.work()).not.toThrow()
  })
})

Hỏi đáp

Q: Làm thế nào để có thể ứng dụng nguyên tắc phân tách interface trong code của bạn?

A: Để ứng dụng nguyên tắc phân tách interface, tôi làm theo các bước sau:

Định nghĩa ra các interface nhỏ, tập chung vào yếu tố chuyên biệt, cụ thể của interface đó.
Tránh tạo ra các interface lớn (gồm nhiều method) mà các class phải implements những method không cần dùng tới.
Ưu tiên sử dụng nhiều interface chuyên biệt thay vì sử dụng một interface lớn hoặc interface mang tính chất chung chung.

Tổng kết

Nguyên tắc phân tách interface (ISP) giúp hạn chế code rác, tập chung vào sự chuyên biệt của từng interface, nâng cao nhận thức với từng hành vi.

Điều này rất tốt cho việc tổ chức code và bảo trì cũng như khả năng kiểm thử (test)

Nếu bạn phát hiện sai sót, đừng ngần ngại báo lại cho mình qua các kênh mạng xã hội bên dưới website.

Các bài viết tiếp nối chủ đề SOLID principles sẽ sớm được cập nhật.

Chúc bạn ngày mới tốt lành.

Đọc bài gốc tại đây

Liskov Substitution Principle (LSP)

Nguyễn Anh Tuấn — Tue, 12 Dec 2023 09:22:09 +0000

Tiếp nối chuỗi bài viết SOLID principles, hôm nay chúng ta sẽ tìm hiểu về Nguyên tắc thay thế Liskov (Liskov Substitution Principle)

Liskov Substitution Principle (LSP) là gì?

Nếu S là kiểu con của T thì các đối tượng kiểu T trong chương trình có thể được thay thế bằng các đối tượng kiểu S mà không làm thay đổi bất kỳ thuộc tính/hành vi mong muốn nào của chương trình.

Hay nói cách khác, Liskov Substitution Principle định nghĩa ra một hợp đồng mà các lớp dẫn xuất (derived classes) phải tuân thủ để có thể thay thế thực sự cho các lớp cơ sở của chúng.

Mục tiêu của LSP

Khả năng thay thế: đối tượng (object) của lớp dẫn xuất có thể thay thế các đối tượng của lớp cơ sở mà không ảnh hưởng tới tính chính xác của chương trình. Điều này cho phép đa hình (polymorphism) và tăng cường tính linh hoạt của chương trình.
Bảo tồn hành vi: các lớp dẫn xuất nên duy trì hoặc mở rộng hành vi của lớp cơ sở.
Dễ dàng hoán đổi: các lớp dẫn xuất dễ dàng hoán đổi cho lớp cơ sở trong mọi ngữ cảnh. Điều này thúc đẩy mức trừu tượng cao, và cho phép viết mã code được viết theo cách độc lập và triển khai cụ thể. (specific concrete implementation)
Tính nhất quán: LSP giúp tạo ra hành vi nhất quán và có thể đoán trước được trong hệ thống phân cấp của các lớp. Nó ngăn chặn tác dụng phụ không mong muốn hoặc ngăn chặn thay đổi hành vi khi sử dụng các lớp dẫn xuất.

Nguyên tắc thay thế Liskov được Barbara Liskov giới thiệu trong một hội nghị năm 1987.

Ví dụ

Hãy tìm hiểu sâu hơn về nguyên tắc này qua ví dụ sau

Vi phạm nguyên tắc thay thế Liskov

// Violating LSP
class Rectangle {
    protected width: number = 0
    protected height: number = 0

    setWidth(width: number) {
        this.width = width;
    }

    setHeight(height: number) {
        this.height = height;
    }

    area(): number {
        return this.width * this.height;
    }
}

class Square extends Rectangle {
    // Violates LSP by changing behavior
    setHeight(height: number) {
        this.height = height;
        this.width = height;
    }

    // Violates LSP by changing behavior
    setWidth(width: number) {
        this.height = width;
        this.width = width;
    }
}

function printArea(shape: Rectangle): void {
    shape.setWidth(5);
    shape.setHeight(10);
    console.log(`Area: ${shape.area()}`);
}

const rect = new Rectangle()
const square = new Square()
printArea(rect) // 50 correct
printArea(square) // 100 => What the heck is that?

Ở ví dụ này mình đã ép 2 cạnh width và height bằng nhau khi setWidth, setHeight trong class Square. Hành vi setWidth, setHeight của lớp cơ sở (class Rectangle) đã bị thay đổi.

Điều này rõ ràng là đã vi phạm nguyên tắc Liskov Substitution.

Tuân theo nguyên tắc thay thế Liskov

Chúng ta hãy cùng thiết kế lại các class trong ví dụ trên nhé

// Adhering to LSP with an abstract class
abstract class Shape {
    protected width: number = 0;
    protected height: number = 0;

    setDimensions(width: number, height: number): void {
        this.width = width;
        this.height = height;
    }

    abstract area(): number;
}

class Rectangle extends Shape {
    area(): number {
        return this.width * this.height;
    }
}

class Square extends Shape {
    setDimensions(side: number): void {
        // Adheres to LSP by maintaining the base class behavior
        super.setDimensions(side, side);
    }

    area(): number {
        return this.width * this.height;
    }
}

// Function expecting a Shape
function printArea(shape: Shape): void {
    shape.setDimensions(5, 10);
    console.log(`Area: ${shape.area()}`);
}

// Create an instance of Square (derived class)
const square = new Square();

// Use the function with the derived class object
printArea(square);
// Output: Area: 50 (adheres to LSP)

Ở ví dụ này chúng ta bảo tồn được hành vi setDimensions(number, number) và area() ở lớp cơ sở (class Shape), bạn có thể mở rộng thêm nữa sang các class như Hexagon, Circle nếu muốn.

Unit test

Vẫn như mọi khi, unit test là điều không thể thiếu khi tuân theo SOLID principles.

it('able to calculate square area', () => {
    const square = new Square()
    square.setDimentions(5)
    expect(square.area()).toEqual(25)
})

it('able to replace subtype by base class instance', () => {
    const square = new Square()
    const shape = square as Shape;
    shape.setDimentions(5, 10)
    expect(shape.area()).toEqual(25)
})

Hỏi đáp

Q: Làm thế nào để ứng dụng nguyên tắc thay thế Liskov trong code của bạn?

A: Để ứng dụng nguyên tắc thay thế Liskov, tôi làm theo các bước sau:

Đảm bảo các object của lớp con có thể thay thế bằng object của lớp cha mà không làm thay đổi bất kỳ thuộc tính, hành vi nào của chương trình.
Các lớp con không được thay đổi hành vi của lớp cha.
Các lớp con không được đưa ra các ngoại lệ mới mà nó không tồn tại trong lớp cha.

Tổng kết

Nguyên tắc thay thế Liskov (Liskov Substitution Principle) hữu ích trong việc đảm bảo hành vi luôn nhất quán và dễ dàng đoán trước xuyên suốt chương trình.

Việc thực hành nguyên tắc này giúp bạn nhận thức rõ ràng hơn về tính mạch lạc, tin cậy, đồng thời cũng giúp viết unit test dễ dàng hơn.

Nếu bạn phát hiện sai sót, đừng ngần ngại báo lại cho mình qua các kênh mạng xã hội bên dưới website.

Các bài viết tiếp nối chủ đề SOLID principles sẽ sớm được cập nhật.

Chúc bạn ngày mới tốt lành.

Đọc bài gốc tại đây

Open Close Principle (OCP)

Nguyễn Anh Tuấn — Tue, 12 Dec 2023 09:21:13 +0000

Tiếp nối chuỗi bài viết SOLID principles, hôm nay chúng ta sẽ tìm hiểu về Nguyên tắc đóng mở (Open Close Principle)

Định nghĩa

Nguyên tắc đóng mở (Open Close Principle) khuyến khích việc thiết kế các thực thể (entities) như class, module... theo hướng mở cửa cho việc mở rộng (open for extension) và đóng cửa với việc sửa đổi (close for modification)

Hay đơn giản hơn là mỗi khi muốn thêm chức năng nào đó, bạn hãy viết class mới để mở rộng bằng cách kế thừa class cũ, không được sửa class cũ.

Nguyên tắc này được giới thiệu bởi Bertrand Meyer năm 1988.

Chúng ta hãy tìm hiểu kỹ hơn qua ví dụ thực tế nhé.

Ví dụ vi phạm nguyên tắc đóng mở (OCP)

// Violating OCP

class Shape {
    constructor(protected width: number, protected height: number) {}

    getArea(): number {
        return this.width * this.height
    }
}

class Square extends Shape {
    constructor(private side: number) {
        super(side, side);
    }
}

class Rectangle extends Shape {
    constructor(private width: number, private height: number) {
        super(width, height);
    }
}

class Circle extends Shape {
    constructor(private radius: number) {
        super(radius, radius)
    }
}

Ở ví dụ này, class Shape vẫn ổn cho tới khi mở rộng tới class Circle. Cách tính diện tích của hình tròn hoàn toàn khác biệt với hình vuông và hình chữ nhật. Khi này bạn cần sửa đổi method getArea ở class Shape để có thể chứa được trường hợp lớp mở rộng là hình tròn (Circle)

Việc sửa đổi này hoàn toàn đi ngược lại với nguyên tắc đóng mở vì cần phải sửa đổi class Shape.

Ví dụ tuân theo nguyên tắc đóng mở (OCP)

Chúng ta hãy thiết kế lại các class này để giúp nó dễ dàng mở rộng mà lại không cần sửa đổi nhé.

// Adhering OCP

interface Shape {
    getArea(): number;
}

class Square implements Shape {
    constructor(private side: number) {}

    getArea(): number {
        return this.side * 2
    }
}

class Rectangle implements Shape {
    constructor(private width: number, private height: number) {}

    getArea(): number {
        return this.width * this.height;
    }
}

const square = new Square(20);
const rect = new Rectangle(20, 40);

console.log('area of square', square.getArea())
console.log('area of rectangle', rect.getArea())

Ở lần sửa đổi này mình dùng interface (các bạn cũng có thể dùng abstract class, miễn sao các class kế thừa từ abstract class có thể tự triển khai business logic mà không cần sửa đổi ở lớp abstract).

Bạn có thể mở rộng ra các class mới như Hexagon (hình lục giác) hay nhiều hình dạng khác (Circle, Square, Rectangle, Hexagon, Triangle, Star, etc...) mà vẫn tuân theo Open Close Principle, không cần sửa đổi gì ở interface Shape.

// Adhering OCP

abstract class Shape {
    abstract getArea(): number
}

class Square extends Shape {
    constructor(private width: number, private height: number) {
        super()
    }

    getArea(): number {
        return this.width * this.height
    }
}

class Circle extends Shape {
    constructor(private radius: number) {
        super()
    }

    getArea(): number {
        return Math.PI * Math.pow(this.radius, 2)
    }
}

class Hexagon extends Shape {
    constructor(private side: number) {
        super()
    }

    getArea(): number {
        return ((3 * Math.sqrt(3) * (this.side * this.side)) / 2);  
    }
}

Ở ví dụ này mình dùng abstract class và mở rộng ra tận class Hexagon, kết quả tương tự ví dụ trên. Tất cả class đều tuân theo nguyên tắc Mở cho việc mở rộng, và đóng với việc sửa đổi.

Các bạn có nhận ra các class này có điều gì quen quen không nhỉ?

Bật mí nhé, đó là mỗi class đều đảm nhiệm một và chỉ một nhiệm vụ riêng. VD class Square thì chỉ tính diện tích cho Square, class Rectangle chỉ tính diện tích cho Rectangle.

Bạn hãy nhớ tới bài viết trước Single Responsibility Principle (SRP) xem có đúng nó không nào?

Việc áp dụng thành thục các tập nguyên tắc SOLID (principles) sẽ giúp bạn rất nhiều đó, cố gắng luyện tập thành thói quen tốt nhé.

Unit test

Đây là phần không thể thiếu và luôn được nhấn mạnh (emphasize) khi tuân theo SOLID principle.

it('calculate square area correctly', () => {
    const square = new Square(4)
    expect(square.getArea()).toEqual(16)
})

it('calculate rectangle area correctly', () => {
    const rect = new Rectangle(4, 8)
    expect(rect.getArea()).toEqual(32)
})

Unit test mình luôn sử dụng Jest nhé. Các bạn muốn tìm hiểu thêm về jest thì mình sẽ viết riêng một hoặc vài bài về jest.

Hỏi đáp

Q: Làm thế nào để ứng dụng nguyên tắc đóng mở vào code của bạn?

A: Để ứng dụng nguyên tắc đóng mở, tôi thực hiện các bước sau:

Thiết kế class có thể dễ dàng mở rộng
Sử dụng các abstract class hoặc interface để định nghĩa phần mở rộng
Tránh sửa đổi code cũ khi thêm tính năng hay chức năng mới.

Kết luận

Nguyên tắc đóng mở (Open Close Principle) mang lại rất nhiều lợi ích khi bạn mở rộng mà không phá vỡ hệ thống. Đảm bảo hệ thống hoạt động ổn định đồng thời dễ bảo trì, dễ kiểm thử (unit test), dễ đọc và dễ nắm bắt.

Nếu bạn phát hiện sai sót, đừng ngần ngại báo lại cho mình qua các kênh mạng xã hội bên dưới website.

Các bài viết tiếp nối chủ đề SOLID principles sẽ sớm được cập nhật.

Chúc bạn ngày mới tốt lành.

Đọc bài gốc tại đây

Single Resonsibility Principle (SRP)

Nguyễn Anh Tuấn — Tue, 12 Dec 2023 09:20:22 +0000

Tiếp diễn chuỗi bài viết về SOLID principle, bài này mình sẽ đi sâu vào Single Responsibility Principle (SRP)

Single Responsibility Principle (SRP) là gì?

SRP được dịch một cách ngắn gọn là nguyên tắc đơn nhiệm. Mỗi class chỉ nên chịu trách nhiệm về một và chỉ một nhiệm vụ cụ thể.

Nguyên tắc này được Robert C. Martin giới thiệu năm 2003, ông còn hay được gọi với cái tên Uncle Bob

Vì sao lại đơn nhiệm?

Vì nó đơn giản, dễ hiểu và dễ nắm bắt, dễ dàng bảo trì và mở rộng, đồng thời dễ dàng trong việc viết unit test.

Ví dụ

Dưới dây là ví dụ về class vi phạm (violate) nguyên tắc đơn nhiệm (Single Responsibility Principle)

// Violating SRP

class OrderProcessor {

    checkout(total: number, address: string) {
      const result = this.processPayment(total)
      if (result) {
          this.processShipping(address)
      }
    }

    processPayment(total: number): boolean {
      console.log('processing payment with paypal or momo', total)
      return true
    }

    processShipping(address: string) {
    console.log('processing shipping', address)
    }
}

Class OrderProcessor bên trên đang đảm nhiệm 03 nhiệm vụ (checkout, processPayment và processShipping), vậy class này đã vi phạm nguyên tắc đơn nhiệm.

Chúng ta sẽ thiết kế lại class này tuân theo (adhere) nguyên tắc đơn nhiệm nhé

// Adhering SRP

class PaymentProcessor {
    process(total: number): boolean {
        console.log('processing payment with paypal or momo', total)
        return true
    }
}

class ShipppingProcessor {
    process(address: string): void {
        console.log('processing shipping', address)
    }
}

class OrderProcessor {
  constructor(
    private payment: PaymentProcessor,
    private shipping: ShippingProcessor
  ) {}

  checkout(total: number, address: string) {
    const result = this.payment.process(total);
    if (result) {
      this.shipping.process(address);
    }
  }
}

Mình tách nhiệm vụ process payment ra một class độc lập là PaymentProcessor, làm tương tự với process shipping mình tạo ra class ShipppingProcessor. Vậy là 02 class này đã tuân theo nguyên tắc đơn nhiệm.

Tiếp theo đó, mình chỉ định class OrderProcessor chỉ làm một nhiệm vụ duy nhất là checkout , việc payment diễn ra như thế nào thì để cho PaymentProcessor đảm nhiệm, với kết quả payment nhận được, mình sẽ tiếp tục cho class ShippingProcessor đảm nhiệm việc ship hàng.

Vậy class OrderProcessor cũng đã tuân theo nguyên tắc đơn nhiệm rồi.

Unit test

Việc viết unit test bây giờ trở nên cực kỳ dễ dàng vì chúng ta đã phân tách ra 03 class, mỗi class đảm nhiệm một nhiệm vụ riêng biệt.

// PaymentProcessor
it('able to process payment', () => {
    const payment = new PaymentProcessor()
    expect(payment.process(1000)).toBe(true)
})

// ShipppingProcessor
it('able to process shipping', () => {
    const shipping = new ShipppingProcessor()
    expect(shipping.process("Hanoi, Vietnam")).not.toThrow();
})

// OrderProcessor
it('able to checkout', () => {
    const payment = new PaymentProcessor()
    const shipping = new ShipppingProcessor()
    const orderProcesser = new OrderProcessor(payment, shipping)
    expect(orderProcesser.process(1000, "Hanoi, Vietnam")).not.toThrow();
})

Các bạn xem, chúng ta vừa có code tường minh, dễ nắm bắt, lại dễ dàng viết unit test.

Nếu như bạn bị lỗi ở khâu payment, bạn biết ngay rằng mình sẽ cần tìm class Payment để kiểm tra mà không cần đọc code dài dòng khó hiểu nữa.

Trong ví dụ trên mình sử dụng jest để viết unit test, bạn có thể tìm thấy tài liệu tại đây: Getting Started · Jest (jestjs.io)

Hỏi đáp

Q: Làm thế nào để đảm bảo code của bạn tuân theo nguyên tắc đơn nhiệm (Single Responsibility Principle)?

A: Để đảm bảo code tuân theo nguyên tắc đơn nhiệm, tôi thực hiện các bước sau:

Đảm bảo rằng mỗi class chỉ làm một nhiệm vụ duy nhất. Nếu có nhiều hơn một nhiệm vụ thì chứng tỏ cần phải phân tách ra nhỏ hơn nữa.
Mỗi class chỉ có duy nhất một lý do để thay đổi.
Mỗi class chỉ làm duy nhất một việc, và làm việc ấy thật tốt.

Kết luận

Tuân theo nguyên tắc đơn nhiệm có nhiều lợi ích như: code đơn giản, dễ đọc, dễ nắm bắt, dễ viết unit test.

Tuy nhiên đi kèm đó là việc số lượng file phát sinh ra cũng lớn.

Nếu bạn cảm thấy bài này hữu ích thì hãy chia sẻ, lan tỏa tới cộng đồng nhé.

Nếu bạn phát hiện sai sót, đừng ngần ngại báo lại cho mình qua các kênh mạng xã hội bên dưới website.

Các bài viết tiếp nối chủ đề SOLID principles sẽ sớm được cập nhật.

Chúc bạn ngày mới tốt lành.

Bạn có thể đọc bài gốc ở đây

SOLID principles là gì?

Nguyễn Anh Tuấn — Tue, 12 Dec 2023 09:18:22 +0000

SOLID principles là gì?

SOLID principles là một tập các nguyên tắc (principle) giúp tổ chức code theo cách dễ bảo trì, linh động và dễ dàng kiểm thử hơn.

SOLID là viết tắt chữ cái đầu tiên của các nguyên tắc sau:

S: Single Responsibility Principle(SRP)
O: Open Close Principle(OCP)
L: Liskov Substitution Principle(LSP)
I: Interface Segregation Principle(ISP)
D: Dependency Inversion Principle(DIP)

Lưu ý: một vài thuật ngữ mình sẽ không dịch ra Tiếng Việt, hoặc dịch nhưng vẫn để từ khóa Tiếng Anh bên cạnh để tránh hiểu lầm hoặc sai ý nghĩa. Mong các bạn thông cảm.

Ưu và nhược điểm của SOLID principles?

Mặc dù SOLID sinh ra là để tổ chức code tốt hơn, tuy nhiên điều đó không có nghĩa là bạn nên tuân theo trong mọi trường hợp, đặc biệt khi team của bạn không hiểu rõ về SOLID, project nhỏ hoặc gấp gáp về thời gian.

Hãy đảm bảo rằng bạn thảo luận kỹ với team của mình để chỉ ra được những lợi ích mà SOLID thực sự mang lại trong project mà team sắp triển khai.

Ưu điểm

Dễ bảo trì (Maintainability): Code tuân theo SOLID principles dễ bảo trì và dễ thay đổi hơn do được tổ chức rõ ràng và tường minh
Linh hoạt và thích ứng (Flexibility & Adaptability): SOLID code rất linh hoạt, việc thay đổi một phần của hệ thống ít có khả năng gây ra hậu quả ngoài ý muốn ở các phần khác của hệ thống.
Kiểm thử dễ dàng (Testability): SOLID code thực sự dễ dàng để viết test case do được tổ chức phân tách mối lo ngại (separation of concerns) và phụ thuộc nghịch đảo (dependency inversion)
Tái sử dụng code (Code reusability): Nguyên tắc đóng mở (Open Close Principle) khuyến khích tạo ra những class dễ dàng mở rộng nhưng lại không khuyến khích sửa đổi các lớp đó. Điều này tạo điều kiện (facititate) cho việc tái sử dụng code sẵn có khi mở rộng tính năng thay vì sửa đổi code cũ.
Dễ đọc và dễ hiểu (Readability and understandability): SOLID principles thúc đẩy (promote) thiết kế rõ ràng (clear), trực quan (intuitive). Code được tổ chức theo cách phản ánh (reflects) quan hệ giữa các thành phần (components), điều này khiến lập trình viên dễ hiểu toàn bộ cấu trúc cũng như hành vi tổng thể của hệ thống.
Giảm thiểu code trùng lặp (Reduce code duplication): Bằng cách tuân theo DRY principle (Don't Repeat Yourself), SOLID principles giúp giảm thiểu code trùng lặp, các function có thể được đóng gói trong các thành phần có thể chia sẻ (sharable components) , tái sử dụng và tránh dư thừa (redundancy) code.
Phân tách mối lo ngại (Separation of concerns): SOLID principles phân tách rõ ràng các mối lo ngại (separation of concerns), đảm bảo rằng mỗi thành phần (components) có trách nhiệm riêng cụ thể (specific responsibility). Sự phân tách này giúp dễ dàng suy luận về các thành phần của hệ thống, đơn giản hóa (simplifies) việc gỡ lỗi (debugging) và bảo trì (maintenance)
Dễ dàng hợp tác (Easier to collaboration): Một cấu trúc code được tổ chức tốt, tuân theo SOLID principles giúp các lập trình viên dễ dàng hợp tác, phối hợp với nhau. Thiết kế mô đun cho phép các nhóm hoặc các lập trình viên có thể làm việc trên những phần của hệ thống với sự can thiệp tối thiểu, không bị block chéo.
Phụ thuộc nghịch đảo (Dependency inversions): Nguyên tắc phụ thuộc nghịch đảo (Dependency Inversion Principle) khuyến khích sử dụng các lớp trừu tượng và phụ thuộc trực tiếp (dependency injection) vốn giúp giảm thiểu sự liên kết giữa các thành phần (loosely coupled components). Điều này khiến cho việc thay thế (substitution), nâng cấp (upgrade) các gói phụ thuộc trở nên dễ dàng hơn mà không làm ảnh hưởng tới toàn bộ hệ thống.

Bên cạnh hàng loạt những ưu điểm thì SOLID principles cũng bộc lộ những nhược điểm nhất định. Không có nguyên tắc thiết kế nào hoàn hảo cho mọi hoàn cảnh, mọi project. Chính vì vậy mình luôn khuyên các bạn nên thận trọng và cân nhắc kỹ trước khi áp dụng.

Nhược điểm

Phức tạp hóa vấn đề thái quá (Over-engineering): Ứng dụng toàn bộ SOLID principles một cách nghiêm ngặt (rigorously) trong mọi trường hợp có thể dẫn tới việc phức tạp hóa vấn đề một cách thái quá trong những dự án đơn giản, những dự án nhỏ. Không phải dự án nào cũng nhận được lợi ích từ tất cả các nguyên tắc (principle), bạn cần phải cân bằng những nguyên tắc đó dựa trên quy mô và độ phức tạp của dự án.
Tốn thời gian học tập (Learning curve): Với những lập trình viên chưa từng ứng dụng SOLID principles, họ cần phải bỏ thời gian ra để học thêm, điều này khiến cho chi phí thời gian tăng cao trong khi dự án cần phải đẩy tiến độ nhanh, đồng thời sẽ gặp khó trong việc ứng dụng SOLID principle triệt để và đúng cách, thậm chí nếu họ hiểu không sâu còn có thể ứng dụng sai cách.
Gia tăng số lượng class và abstraction (Increase number of class and abstraction): Tuân theo SOLID principles thường dẫn tới việc tăng đáng kể số lượng các class, abstraction class/interface. Mặc dù SOLID giúp codebase trở nên dễ bảo trì hơn, nhưng lại gia tăng sự phức tạp với các dự án nhỏ.
Tiềm tàng abstraction quá mức (Potential for abstraction overhead): Đưa ra quá nhiều lớp trừu tượng (abstraction class/interface) để tuân theo SOLID principle có thể gia tăng sự phức tạp. Nó có thể khiến code trở nên khó hiểu hơn, đặc biệt là với những lập trình viên không quen với những lớp trừu tượng (abstract class/interface) được sử dụng.
Tốn thời gian khởi tạo hơn (Increase initial development time): Tuân theo SOLID principles một cách nghiêm ngặt có thể cần nhiều thời gian hơn trong quá trình khởi tạo dự án. Lập trình viên cần thiết kế những lớp trừu tượng (abstract class/interface) một cách cẩn thận, và cơ chế phụ thuộc trực tiếp. Điều này làm giảm đáng kể tốc độ phát triển dự án tại pha khởi tạo (initial phase).
Quá lệ thuộc vào các gói phụ thuộc trực tiếp (Dependency Injection overhead): Việc sử dụng các gói phụ thuộc trực tiếp được khuyến khích theo nguyên tắc SOLID, tuy nhiên đôi khi việc dùng quá nhiều gói phụ thuộc trực tiếp lại làm cho lập trình viên khó cấu hình cũng như hiểu flow của các gói này. Trong vài trường hợp, một dự án đơn giản không hề nhận lại được lợi ích khi sử dụng kiểu phụ thuộc này.
Thách thức trong việc ứng dụng vào dự án cũ (Challenging in legacy codebase): Ứng dụng SOLID principle vào dự án cũ là một thách thức lớn. Code cũ có thể không tuân theo SOLID một chút nào, và việc tái cấu trúc (refactoring) và tuân theo (adhere) tốn nhiều thời gian cũng như gây ra các lỗi tiềm tàng.
Gia tăng thời gian nhận thức (Increase cognitive load): Với những lập trình viên có ít kinh nghiệm hoặc không có kinh nghiệm với SOLID principles thì họ cần thêm thời gian để hiểu các quy tắc (rules) và các hướng dẫn (guidelines). Điều này có thể dẫn tới việc hiểu sai (misunderstanding) hoặc vi phạm (violates) các nguyên tắc một cách vô ý (unintentional).

Tổng kết

Việc ứng dụng SOLID principles cần được thảo luận và cân nhắc kỹ càng về nguồn lực, sự hiểu biết cũng như quy mô và sự phức tạp của dự án.

Nếu team của bạn triển khai dự án nhỏ, đơn giản và cần ít người thực hiện thì câu trả lời là bạn không nên áp dụng hoặc áp dụng một cách cơ bản, không quá nghiêm ngặt.

Nếu bạn muốn triển khai SOLID, hãy đảm bảo rằng team của bạn triển khai đào tạo nội bộ và ứng dụng SOLID trong các dự án bên lề (side project) trước khi triển khai cho khách hàng. Điều này sẽ cứu bạn một bàn thua trông thấy.

Chi tiết về 5 nguyên tắc SOLID sẽ được mình trình bày trong các bài viết tiếp theo do bài này đã quá dài rồi.

Cảm ơn bạn đã quan tâm, theo dõi.

Nếu bạn cảm thấy bài này giúp ích cho bạn, hãy chia sẻ, lan tỏa tới mọi người giúp mình nhé.

Trân trọng,

Đọc bài gốc tại đây

Xin chào

Nguyễn Anh Tuấn — Tue, 12 Dec 2023 09:17:38 +0000

Giới thiệu

Cảm ơn bạn đã ghé thăm blog công nghệ của mình.

Mình xin giới thiệu, mình là Nguyễn Anh Tuấn. Một kỹ sư phần mềm tràn đầy nhiệt huyết có sự quan tâm sâu sắc về các nguyên tắc thiết kế phần mềm, các ngôn ngữ lập trình TypeScript Javascript Kotlin Swift và các framework ReactJS React Native Expo Svelte SvelteKit Elysia

Tuấn phát triển app di động với React Native Expo bên cạnh phát triển web app với ReactJS SvelteKit

Không ai là hoàn hảo và chính bản thân mình cũng vậy. Tuấn luôn luôn làm mới bản thân, cập nhật kiến thức mới cũng như rèn luyện và thực hành thật nhiều để hiểu sâu hơn.

Dấu ấn

Dự án đáng ghi nhớ trong sự nghiệp của mình là app Equilab, mình theo dự án hơn 5 năm cho tới tháng 03 năm 2023. Đây là một hành trình đầy màu sắc và đáng quý. Mình được làm chung với đồng nghiệp từ Thụy Điển, Pháp, Đức và Mỹ. Sản phẩm chuyên biệt dành cho việc huấn luyện ngựa từ 15 nghìn users và đạt 1 triệu 500 nghìn users vào cuối 2022.

Mình đảm nhiệm vị trí React Native Leader, giúp phát triển các tính năng như Training Calendar, Social Feed, Stable Chat, Challenges và nhiều đóng góp vào native iOS/Android project. Tại đây mình còn phát triển cả backend nữa nhé.

Bên cạnh đó, với vai trò là quản trị viên dẫn dắt cộng đồng React Native Vietnam trên Facebook với hơn 31 nghìn thành viên, mình luôn chia sẻ mẹo, kinh nghiệm làm việc với React Native, Swift, Kotlin đồng thời giúp các member gỡ lỗi cũng như giới thiệu các công nghệ mới.

Lời kết

Gần đây Tuấn quyết định mở kênh Youtube, Tiktok và viết Blog tại địa chỉ anhtuank7c.dev với mục tiêu lưu lại những kiến thức mình mình lĩnh hội được, cũng như chia sẻ chúng với cộng đồng lập trình viên Việt Nam.

Nếu bạn có bất kỳ dự án mobile app, web app cần triển khai, đừng ngần ngại liên hệ với mình tại địa chỉ email: anhtuank7c@hotmail.com nhé.

Tuấn rất mong nhận được sự hỗ trợ về nội dung cũng như về các dự án, công việc từ các bạn, các quý công ty.

Một lần nữa cảm ơn bạn đã ghé thăm.

Chúc bạn ngày mới tốt lành và gặt hái nhiều thành công.

Tuấn Nguyễn

DEV Community: Nguyễn Anh Tuấn

Lynx: Giải pháp mới cho ứng dụng đa nền tảng - JS Engine

Lynx: Giải pháp mới cho ứng dụng đa nền tảng - Giới thiệu

Review code

Review code là gì?

Vì sao cần review code?

Các vấn đề chính khi review code

Những lưu ý khi review code

Để lại review chi tiết

Giữ thái độ đúng mực, cầu tiến

Không review đoạn code dài hơn 200 dòng

Mỗi commit chỉ nên chứa một ý nghĩa

Tự động hóa quá trình review codeTrên thị trường có nhiều công cụ review code tự động có thể kể đến SonarQube, ESLint, SwiftLint, JSHint, Codestriker, Deepscan etc...

Developer cần hiểu rõ trách nhiệm

Kết bài

Dependency Inversion Principle (DIP)

Dependency Inversion Principle (DIP) là gì?

Module cấp cao (high-level modules) là gì?:

Module cấp thấp (low-level modules) là gì?:

Ví dụ vi phạm nguyên tắc đảo ngược phụ thuộc (DIP)

Ví dụ tuân theo nguyên tắc đảo ngược phụ thuộc (DIP)

Một vài khái niệm nhắc đến trong bài:

Unit test

Hỏi đáp

Kết luận

Interface Segregation Principle (ISP)

Interface Segregation Principle (ISP) là gì?

Ví dụ về sự vi phạm nguyên tắc phân tách interface (ISP)

Ví dụ tuân theo nguyên tắc phân tách interface

Unit test

Hỏi đáp

Tổng kết

Liskov Substitution Principle (LSP)

Liskov Substitution Principle (LSP) là gì?

Mục tiêu của LSP

Ví dụ

Vi phạm nguyên tắc thay thế Liskov

Tuân theo nguyên tắc thay thế Liskov

Unit test

Hỏi đáp

Tổng kết

Open Close Principle (OCP)

Định nghĩa

Ví dụ vi phạm nguyên tắc đóng mở (OCP)

Ví dụ tuân theo nguyên tắc đóng mở (OCP)

Unit test

Hỏi đáp

Kết luận

Single Resonsibility Principle (SRP)

Single Responsibility Principle (SRP) là gì?

Ví dụ

Unit test

Hỏi đáp

Kết luận

SOLID principles là gì?

SOLID principles là gì?

Ưu và nhược điểm của SOLID principles?

Ưu điểm

Nhược điểm

Tổng kết

Xin chào

Giới thiệu​

Dấu ấn​

Lời kết​

Giới thiệu

Dấu ấn

Lời kết