Archimedes cùng lối suy nghĩ đầu vào - đầu ra trong lập trình

Vấn đề

"Hãy cho tôi một điểm tựa, tôi sẽ nhấc bổng quả đất lên" là câu nói nổi tiếng của Archimedes. Nhiều minh chứng cho rằng kể cả có cho ông ta điểm tựa thì cũng phải mất nhiều nghìn năm mới có thể nhấc được. Chưa kể, một đòn bẩy có độ dài không thể tưởng tượng được thì lấy đâu ra. Nhưng trong bài viết này tôi không bàn luận về tính đúng sai của câu nói, có một điều mà tôi thấy suy nghĩ của ông hết sức thú vị: Hãy cho tôi...tôi sẽ...

Hãy cho tôi x, tôi sẽ trả về y là một suy nghĩ đầu vào - đầu ra trong lập trình. Đây là một lối tư duy giải quyết vấn đề rất thông dụng. Thay vì bắt tay ngay vào viết mã, hãy dành thời gian để đánh giá và xem chỗ nào có thể áp dụng được cách hỏi "hãy cho tôi x, tôi sẽ trả về y". Nghe thì quen đấy, có phải bạn từng nghe đến trong bài viết Code thì cứ code nhưng đã bao giờ bạn dành thời gian khai phá tư duy lập trình của mình chưa?.

Một ví dụ đơn giản

Cho dễ hình dung, tôi lấy một ví dụ về tính năng mua hàng đơn giản. Logic của nó trông như thế này:

function createOrder(product, quantity, customer) {
  // tìm thông tin product
  const productInfo = ProductModel.findOne({
    where: {
      product_id: product,
    }
  });
  if (!productInfo) {
    throw new Error('Product not found');
  }

  // kiểm tra số lượng tồn kho
  if (productInfo.quantity < 1) {
    throw new Error('Not enough product in stock');
  }

  // tạo order
  const order = OrderModel.create({
    customer: customer,
    product_id: product,
    quantity: quantity,
    total_price: productInfo.price * quantity,
  });

  return order;
}

Nếu suy nghĩ đầu vào - đầu ra, bạn có thể làm cho mã bên trên trông ngắn gọn và có thể tái sử dụng được. Để làm được điều đó, hãy nghĩ cách tách các phần logic càng nhỏ càng tốt, sao cho chúng thành Pure function được thì càng tốt. Nếu chưa biết đến "hàm thuần khiết" là gì, bài viết Pure Function trong Javascript. Tại sao chúng ta nên biết càng sớm càng tốt? là dành cho bạn.

Ví dụ trên, chúng ta thấy có 3 logic rất rạch ròi: lấy thông tin sản phẩm, kiểm tra số lượng tồn kho và cuối cùng là tạo đơn. Từ đó tách ra thành 3 hàm nhỏ hơn.

Cho tôi id sản phẩm, tôi sẽ trả về thông tin của sản phẩm đó.

function getProductInfo(product) {
  return ProductModel.findOne({
    where: {
      product_id: product,
    },
  });
}

Cho tôi thông tin sản phẩm, tôi sẽ kiểm tra được hàng còn tồn kho không

function checkProduct(productInfo) {
  return productInfo.quantity > 0;
}

Cho tôi tin tin tạo đơn hàng, tôi sẽ tạo đơn hàng và trả về nó.

function createOrder(productInfo, customer) {
  return OrderModel.create({
    customer: customer,
    product_id: productInfo.id,
    total_price: productInfo.price,
  });
}

3 hàm với 3 mục đích rõ rệt, giúp bạn tái sử dụng chúng. Bất cứ khi nào lấy thông tin sản phẩm thì dùng getProductInfo, kiểm tra lượng hàng tồn kho thì dùng checkProduct... Có người hỏi tại sao checkProduct lại phải nhận cả producInfo chứ không phải là mỗi thuộc tính quantity thôi? Để trả lời cho câu hỏi này còn phụ thuộc vào kinh nghiệm của bạn trong dự án. Việc nhận cả productInfo giúp tăng khả năng mở rộng sau này. Ví dụ sau này phát sinh thêm logic phải những sản phẩm có thời gian tạo sau một tuần mới được tạo đơn.

function checkProduct(productInfo) {
  return productInfo.quantity > 0 && productInfo.created_at < moment().subtract(7, "d").toISOString();
}

Dĩ nhiên, bạn có thể tiếp tục tách checkProduct thành những hàm nhỏ hơn nữa nếu đánh giá là cần thiết.

function checkProduct(productInfo) {
  return checkQuantity(productInfo.quantity) && checkDate(productInfo.created_at);
}

Lợi ích của viết hàm đầu vào đầu ra là rất dễ tạo unittest. Vì không có thành phần phụ thuộc (ví dụ như trong hàm lại sử dụng một biến nào đó ở bên ngoài hàm) nên bạn có thể viết các trường hợp để kiểm tra tính đúng đắn của hàm.

Ví dụ, để kiểm tra xem checkProduct có hoạt động đúng như mong đợi, chỉ cần truyền vào productInfo có các trường quantity và created_at, hàm sẽ trả về kết quả là true/false. Với một đầu vào sẽ cho một đầu ra tương ứng, không phải lo lắng liệu hàm có dùng biến bên ngoài hàm hoặc side effect hay không.

Tóm lại, việc suy nghĩ đầu vào - đầu ra, cùng với khả năng tạo ra các Pure function, hạn chế side effect giúp chúng ta viết ra được chức năng có tính tái sử dụng và dễ unittest.

Cho đến bây giờ, câu nói của Archimedes vẫn không ai kiểm chứng được liệu ông có nhấc được quả đất lên khi có đủ các điều kiện cần hay không. Nhưng hàm của bạn viết ra, chắc chắn có thể kiểm chứng được tính đúng đắn một cách dễ dàng hơn bao giờ hết.

Làm thế nào để suy nghĩ đầu vào đầu ra?

Có một một số cách để giúp bạn rèn luyện suy nghĩ đầu vào - đầu ra. Sau khi đọc những gợi ý dưới đây, điều quan trọng là bạn phải luyện tập bằng cách áp dụng nó thật nhiều trong dự án cá nhân hoặc dự án mà bạn tham gia.

Thứ nhất, dành thời gian để tìm hiểu xem Pure function là gì? Lợi ích của nó mang lại là như thế nào.

Thứ hai, trước khi bắt tay vào làm bất cứ điều gì, hãy dành thời gian đánh giá lại tính năng chuẩn bị triển khai. Tôi đã có bài viết về 4 bước rèn luyện tại Code thì cứ code nhưng đã bao giờ bạn dành thời gian khai phá tư duy lập trình của mình chưa?.

Trong quá trình viết mã, hãy viết một cách tự nhiên. Sau đó kiểm tra lại xem liệu có logic nào có thể tách ra được không? Nếu được thì tách thành Pure function càng tốt.

Lặp lại các bước trên, dần dần bạn sẽ hình thành lối viết đầu vào đầu ra. Sau này, khi chuẩn bị làm một tính năng mới hoặc có tính tương tự như trước, lối tư duy đó ùa về giúp bạn tiết kiệm thời gian khi bắt đầu đánh giá và viết mã.

Tổng kết

Suy nghĩ đầu vào đầu ra không mới, có thể bạn từng sử dụng rồi nhưng chưa để ý đến mà thôi, hy vọng qua bài viết này giúp bạn đọc nhận ra tầm quan trọng của phương pháp suy nghĩ này, từ đó rút ngắn thời gian viết mã và tổ chức mã được tốt hơn.