Kể chuyện viết tool cho kho

Kho bãi - vận hành nếu như người ngoài nhìn vào chắc sẽ thấy khá khô khan, nhàm chán, tuy nhiên khi làm về mảng này mình cũng có 1 vài thứ thấy khá thú vị, áp dụng được vài công nghệ mà theo mình là hay ho và đúc kết 1 vài bài học cũ nhưng không bao giờ hết nóng khi làm phần mềm.

Kỉ niệm thú vị nhất là viết lại hệ thống lấy hàng của Tiki trong 1 thời gian ngắn. Đây là hệ thống giúp nhân viên biết cần đi đến kệ nào lấy món hàng nào cho khách hàng 1 cách tối ưu nhất. Trước đó, nhân viên đơn giản là đi lấy hàng theo từng đơn (pick by order), phù hợp với kho nhỏ, vận hành bằng giấy. Ở giai đoạn tiếp theo khi đầu tư các kho có diện tích rộng hơn, lấy hàng theo từng đơn sẽ rất lâu, không đảm bảo thời gian xử lí đơn hàng, do đó Vận hành chuyển sang lấy hàng theo từng nhóm đơn hàng được tối ưu về đường đi (pick by batch).

Hệ thống mới này ban đầu được thiết kế để có thể hoạt động độc lập, dữ liệu tồn kho và trạng thái đơn hàng sẽ được sync từ ERP (nơi chứa toàn bộ thông tin tồn kho và trạng thái đơn hàng) sang 1 database riêng. Database này dùng RethinkDB với ý định tận dụng các tính năng liên quan real-time.

Tuy nhiên, khi áp dụng vào môi trường thực tế có 1 số vấn đề phát sinh

• việc sync thông tin tồn kho và trạng thái ĐH không đảm bảo chính xác 100%
• khả năng debug và phát triển tính năng khi dùng RethinkDB (hoặc nói chung là NoSQL) không linh hoạt đối với team dev hiện tại
• performance của hệ thống không tốt
• client là mobile app hay bị bug và việc cập nhật khi triển khai trong kho cũng tương đối mất công (phải cài lại app trên từng thiết bị PDA)

Sau khi các team ngồi review lại thì có 1 số giải pháp đưa ra nhằm viết lại hoàn toàn, bài bản hệ thống này và sẽ mất chừng 1-2 tháng. Đây không phải là 1 estimation kém, tuy nhiên tình hình là hệ thống này cần live sớm hơn để phù hợp với tiến độ vận hành của nhà kho mới mở (đây là nhà kho lớn nhất trước giờ của Tiki). Cuối cùng mình đã quyết định chọn 1 solution khác, đơn giản hơn, có các điểm chính sau

• không sync thông tin tồn kho và trạng thái ĐH sang 1 chỗ độc lập mà dùng chung database với hệ thống ERP sẵn có. Việc này sẽ giảm tính độc lập của các hệ thống, khi ERP có sự cố thì việc lấy hàng cũng bị ảnh hưởng, tuy nhiên nó làm giảm rất nhiều vấn đề lỗi và lag cần xử lí khi sync thông tin

• việc chuyển DB sang ERP (dùng PostgreSQL) còn có 1 lợi thế nữa là relational DB sẽ quen thuộc với engineer trong quá trình phát triển hơn. Thế giới luôn có những cuộc tranh cãi về SQL hay NoSQL, đối với mình, cái nào vẫn chạy tốt, dễ hiểu, dễ bảo hành và tuning thì chọn cái đó (thực chất đa phần lí do NoSQL được cho là nhanh, do người dùng chưa tuning hệ thống relational DB đúng mức)

• khi chọn PostgreSQL, mình cũng nhớ lại 1 tool khi trước đã dùng qua khi làm 1 dự án Rails, là PostgREST. Chỉ cần cài tool này thì ta đã có 1 bộ API để thao tác trên dữ liệu Posgres với cú pháp khá linh động, giúp giảm phụ thuộc vào backend dev trong quá trình phát triển

• về phần client, mình chuyển từ mobile app sang web app, như vậy sẽ chạy được trên nhiều thiết bị hơn (cả PDA và laptop). Việc cập nhật phiên bản mới khi này cũng dễ hơn (chỉ việc nhắn người dùng refresh lại trang) và việc phát triển cũng dễ dàng hơn (ngôn ngữ phổ biến với nhiều dev hơn)

• ở webapp, mình thử qua 1 số công nghệ như React, đọc tutorial thấy quá phức tạp (nói đơn giản là đối với nhu cầu hiện tại thì như lấy mã tấu gọt khoai), cuối cùng đọc đến VueJS và cảm thấy đây là solution như sinh ra để áp dụng cho dự án này rồi. VueJs có syntax đơn giản, dễ hiểu dễ viết và phù hợp với các app không phải quản lí state/UI quá phức tạp :) (thời điểm này là đầu năm 2017, khi VueJS vẫn còn chưa phổ biến như hiện nay)

Tóm tắt lại, stack của các tool dùng trong nhà kho Tiki sẽ là client VueJS gọi API thông qua PostgREST đọc DB PostgreSQL. Không phải là fancy gì cả nhưng cũng tương đối là mới mẻ so với các giải pháp thông dụng trong nhà kho như Windows Mobile/Android cho PDA và backend .NET

Về phần deploy thì mình dùng ... Heroku. "git push heroku master" và khi nào có biến bấm nút ở UI phát để revert lại ngay (thực tế đã dùng cũng tương đối nhiều).

Ở backend thì phần thuật toán tính đường đi lấy hàng tối ưu nhất do 1 bạn dev mình khá ưng ý thực hiện. Bạn này đọc CV thì sẽ thấy có vẻ không liên quan IT vì đại học là FTU, có thời gian mở quán cafe, nhưng đọc xa hơn xíu thì cấp 3 học chuyên Lương Thế Vinh và có thi toán quốc gia. Lúc phỏng vấn, mình hỏi về 1 vài dự án, trong đó có dự án phân tích data để giúp user có quyết định mua bán cổ phiếu gì đó hợp lí, bạn bảo là dùng giải pháp của bạn thì quyết định chính xác sẽ là đâu đó 5 mươi mấy %. Mình chấm điểm cộng cho câu này vì 5 mươi mấy % là hợp lí, ai muốn chém mà không thực làm thì khả năng cao sẽ bảo là 70-80%.

Bạn dev này vào Tiki 2 tháng và lúc gần live dự án lấy hàng này thì báo mình xin nghỉ vì có việc cá nhân, nhưng đây là 1 trong những bạn xin nghỉ chuyên nghiệp nhất mình đã gặp. Đến last day, vẫn còn 1 vài vấn đề chưa xử lí tối ưu, bạn ấy nhắn IT giữ laptop thêm 1-2 ngày, và hôm sau vẫn đến kho Tiki ngồi debug xử lí tiếp cho xong cùng mình.

Tổng cộng dự án này từ khi quyết định viết lại cho đến lúc chạy MVP, team mất khoảng 3 tuần và đáp ứng được nhu cầu vận hành của kho theo cách lấy hàng mới, đảm bảo năng suất và thời gian xử lí ĐH.

Mình rất thích dự án này vì nó gắn liền với nhiều phương châm làm phần mềm của mình

• Keep things simple: khi thiết kế không cần phải fancy quá, đừng dùng dao mổ trâu để giết ruồi, đừng chọn 1 công nghệ chỉ vì nó mới hay chỉ vì đọc được 1 vài bài review khen nó hay. Cái quan trọng là cần biết áp dụng công nghệ nào phù hợp nhất, đơn giản nhất vào vấn đề đang cần giải quyết. Phù hợp còn ở những yếu tố như trong team có ai biết ngôn ngữ này không, thị trường có nhiều dev làm về mảng này không, vì 1 tool làm xong không phải là hết mà luôn cần cải tiến phát triển tiếp sau này

• Dám thử dám làm : đây là 1 phần mình thích môi trường làm việc ở Tiki nói chung và team Tech nói riêng. Chắc không có cái nhà kho nào trên thế giới mà hệ thống vận hành lại dùng các stack có vẻ consumer như nhà kho Tiki, đặc biệt là các stack còn ít người biết. Nên việc mình có thể chọn nó để áp dụng thử, và nó đã giải quyết được vấn đề, scale đến giờ cũng là chuyện mình tâm đắc (có thể bạn chưa biết, mobile app dành cho team Vận chuyển Tiki sử dụng Expo, 1 wrapper trên React Native và nó được áp dụng đã gần 2 năm)

• Áp lực : cảm giác khi mà thỉnh thoảng vừa deploy 1 cái gì đó, có bug và các bạn trong kho í ới hú vì hệ thống liên quan tới Vận hành đặc biệt là khâu lấy hàng bị gì là cả kho không hoạt động được. Lúc đó cân nhắc giữa việc debug tiếp hay revert đây. Nếu debug thì xem lỗi gì, đã log lên Sentry chưa, hotfix ra sao. Xong mà nghe bảo "êm rồi anh" thì thật là sảng khoái. Nó giống cảm giác đua xe cảm giác mạnh hay ôn bài thi vào đêm cuối vậy :)

Hiển nhiên, cách tiếp cận vấn đề và solution của mình ở trên nó còn nhiều thứ có thể cải tiến, 1 số chỗ hơi cowboy 1 chút, thậm chí qui trình tuyển dụng bạn dev kia nó cũng có phần may (dựa vào gut feeling) hơn là chuẩn. Nó phù hợp để triển khai dự án trong thời gian ngắn không có nghĩa là nó phù hợp 100% để scale lâu dài và sau này team chịu trách nhiệm cũng đã có nhiều cải tiến tiếp để fix bug và hoàn thiện hơn.

Tuy nhiên, đây là 1 trong những dự án mà mình tâm đắc nhất ở Tiki, hi vọng bạn cũng sẽ thấy gì đó thú vị. Và Tiki vẫn luôn tìm thêm những software engineer giỏi, join us ;)