Think.Forget.Do

Tùy

Nguyen Huu Thong -

Có 1 bạn trong team đề nghị viết lại module "tính toán gợi ý đặt hàng" bằng event sourcing, mình chia sẻ một số suy nghĩ cụ thể về bài toán này nói riêng và cách mình tiếp cận việc "viết lại module" như thế nào

Các vấn đề cần giải quyết đối với bài toán tính toán gợi ý đặt hàng

  1. Định nghĩa bài toán: vấn đề cần giải quyết là tính ra gợi ý đặt hàng tốt hơn, vậy "tốt hơn" nghĩa là thế nào ?

    1. Tốt hơn có phải là tỉ lệ sản phẩm "hết hàng" giảm ?
      a. Sản phẩm "hết hàng" có phải lúc nào cũng là xấu ? Ví dụ sản phẩm cả năm không ai mua, vậy hết hàng có nghiêm trọng bằng sản phẩm vừa có người mua lai rai vài tuần trước ?
      b. Tỉ lệ "sản phẩm có sức mua tốt bị hết hàng" giảm <- sounds good

    2. Tốt hơn có phải là sản phẩm nằm trong kho quá nhiều ?
      a. Khi đó, vấn đề "hết hàng" sẽ giảm, ngược lại tồn kho tăng cao, chôn vốn
      b. Hàng đang luân chuyển, RIM thì thế nào
      c. Số lượng hàng trong kho và dự kiến về kho đáp ứng sức bán dự đoán và không nhiều hơn vậy <- sounds good

    3. "Sức bán dự đoán" tính như thế nào ?
      a. Dựa vào sức bán quá khứ ?
      b. Trong tương lai có CTKM khủng thì sao ?
      c. Có SP B nào tung ra làm ảnh hưởng sức bán SP A thì sao ? (ví dụ iPhone 7 đang bán chạy không có nghĩa là nó sẽ bán chạy khi iPhone 8 ra)

    4. Cách tiếp cận hiện tại là tìm ra công thức và có cấu hình các parameter (ví dụ ngày tồn kho tối thiểu, số lượng đặt hàng tối thiểu, hệ số thời vụ). Có cách nào áp dụng machine learning để có 1 model tự thay đổi theo thời gian và giảm việc điều chỉnh cấu hình tay (khó scale) hay không

  2. Sau khi định nghĩa "tương đối" bài toán, các metric dùng để đánh giá "tốt hơn" đã được ghi nhận và theo dõi chưa ?

  3. Event sourcing giải quyết vấn đề "chuẩn bị data chuẩn", có thể coi là điều kiện "cần", nhưng điều kiện "đủ" (và là the hard problem thật sự) là việc định nghĩa bài toán + tìm ra giải thuật tính toán

  4. Nếu muốn viết lại phần tính toán gợi ý đặt hàng, các câu hỏi nên đặt ra

    1. Vì sao viết lại ?
      a. Vì thích áp dụng công nghệ mới ?
      b. Vì công nghệ cũ hoàn toàn không đáp ứng được nhu cầu ?
      c. Vì cách sử dụng công nghệ cũ chưa phải là best practices ? (hint: đa phần là trường hợp này, vấn đề ko phải ở tool mà ở người dùng)

    2. Viết lại mất bao lâu ?
      a. Trong thời gian đó team có dự án nào khác ? Có ảnh hưởng gì không

    3. Khả năng maintain sau này như thế nào ?
      a. Công nghệ mình định áp dụng có dễ học hay không
      b. Có dùng cùng ngôn ngữ với đa số các tool trong cty hay không
      c. Thị trường có nhiều dev biết nó hay không

    4. Nếu không viết lại, có cách nào giải quyết vấn đề mình đang gặp hay không ?

    5. Vấn đề mình đang muốn giải quyết, có phải là vấn đề nhức đầu làm đau khổ người dùng lớn nhất hiện tại hay không ?

kết luận:
Should we worry about how well a certain module was written? Maybe, maybe not. Sometimes the answer really is, "It runs well and isn't hurting anything, so let's leave it alone. Opening up that can of worms dumps 47 new issues into our queue and now is not a good time to do that." Or the answer may be, "This has to be made right before we can add these 27 other things to the system or we'll all be in deep sht." How do you know which? Experience. Understanding the big picture. Understanding your customers and users. Understanding your dev team. You get the idea.
source: The Best of edw519 | A Hacker News Top Contributor

vietsub:
Mình có cần lo nghĩ về việc phải viết lại 1 dự án hay không ? Câu trả lời là … TÙY. Có khi câu trả lời tốt là "nó đang chạy ổn, giờ mà đụng vô có thể ra 69 bug nữa không chừng". Có khi câu trả lời lại là "giờ mà không viết lại thì sau này đứt cước không thêm gì mới vào được nữa (code legacy quá chuối v.v. =)) ).

Vậy làm sao biết câu trả lời nào là đúng ? Kinh nghiệm và (cái này mình thêm vào) cái đầu mở - tức không chỉ nghĩ có 1 con đường là đúng. Mình nhìn vào bức tranh chung, nhìn vào người dùng, nhìn vào vấn đề chính đang gặp, hiểu về team dev, từ đó sẽ có lựa chọn phù hợp.

PS: những cái trên áp dụng cho dự án công ti - tức là tiền tươi thóc thật ảnh hưởng đến nhiều người dùng.

Còn dự án hobby (mình khuyến khích các bạn thực hiện vào thời gian rảnh rỗi) thì cứ thả ga phang đại công nghệ mới cho dù là lấy mã tấu gọt khoai để học nhé :smile: