Tôi trò chuyện với anh Kiên vào những ngày rất đặc biệt của Hà Nội – đã gần 2 tháng kể từ khi Thủ đô thực hiện giãn cách theo Chỉ thị 16 của Thủ tướng Chính phủ, vậy nên chúng tôi chỉ có thể trao đổi với nhau từ xa. Thế nhưng cũng không quá khó để chúng tôi “vào mood” và bắt chuyện với nhau, bởi dù sao thì những ấn tượng ban đầu của tôi về anh cũng có được theo cách này. Thông qua trang Facebook cá nhân của anh, tôi biết đây chính là một lập trình viên có khả năng viết lách “cực đỉnh”, mà theo người ta nói, đó là kiểu “Khi bạn thích viết nhưng cuộc đời lại bắt bạn phải code”.
Đi cùng Base.vn đã được hơn 4 năm, có thể nói Fullstack Senior Software Engineer Bạch Hưng Kiên là một trong những Baser có rất nhiều đóng góp đối với cả công ty nói chung cũng như với team Product nói riêng, anh cũng chính là người phụ trách phát triển rất nhiều sản phẩm mà hiện nay đã trở thành không thể thiếu của hàng nghìn doanh nghiệp trong quá trình quản trị và vận hành.
Là chàng trai đầu 9x trong một công ty với phần lớn các thành viên thuộc thế hệ Gen Z, thế nhưng Bạch Hưng Kiên lại chính là người phát động các cuộc chơi đậm chất “trẻ trâu” cho anh em. Thậm chí, anh còn tự nhận rằng mình là người có khả năng thiết lập các “kèo” chất lượng nhất và là “nhà cái” uy tín số 1 tại Base.vn.
Tò mò về hành trình gắn bó và làm việc 4 năm có lẻ của anh tại một công ty mới chỉ 5 năm tuổi nhưng đã rất được chú ý trong làng công nghệ, tôi đã “theo đuôi” và không ngừng nài nỉ anh để được làm giàu vốn hiểu biết của mình về thế giới của Dev thông qua những câu chuyện thú vị anh kể trong suốt chặng đường đi tìm lời giải cho các bài toán của doanh nghiệp…
Anh có thể giới thiệu một chút về bản thân và cách mà anh đã “bén duyên” với Base?
Mình là Bạch Hưng Kiên, sinh năm 1990, quê gốc Nghệ An nhưng từ khi sinh ra đã ở Hà Nội. Mình biết đến Base qua anh Dũng – CEO của MOG, anh ấy chia sẻ rất nhiều thông tin về các sản phẩm của Base, cũng như về anh Hùng, khi ấy mình cảm thấy Base rất ấn tượng. Sau đó, mình quyết định nghỉ việc ở công ty cũ và gửi CV để ứng tuyển vào Base, đến nay cũng được hơn 4 năm rồi.
Bộ phận Product được chia thành 5 team PHP, Mobile, Tester, BA và Design. Hiện tại mình đang giữ vị trí PHP Team Leader với công việc chính là phát triển sản phẩm (khoảng 10 apps) cùng với 2 thành viên khác trong team.
Dự án quan trọng nhất mà anh đảm nhận trong hơn 4 năm ở Base là gì?
Dự án quan trọng nhất mà mình từng phụ trách cho tới thời điểm hiện tại là phát triển bộ sản phẩm Base Work+, bao gồm Base Wework, Base Workflow và Base Request.
Có thể nói cả 3 sản phẩm này đã được hoàn thiện hơn rất nhiều so với trước đây, các app đã đủ ổn định để phục vụ cho một lượng người dùng vô cùng lớn. Đây cũng chính là 3 app đứng đầu về số lượt truy cập trong tất cả sản phẩm của Base.
Bên cạnh đó, mình cũng tham gia phát triển thêm rất nhiều tính năng quan trọng, không chỉ trong nội bộ các app, mà còn có cả những tính năng phục vụ cho việc phối hợp, liên kết dữ liệu, luồng công việc giữa các app với nhau…
Vậy thì tổng cộng anh đã tham gia phát triển bao nhiêu phần mềm? Sản phẩm nào khiến anh gặp nhiều khó khăn nhất?
Trong hơn 4 năm qua, mình đã tham gia phát triển rất nhiều sản phẩm, mà bản thân mình cũng không nhớ hết, tổng cộng khoảng 15 apps.
Khó khăn lớn nhất mà mình gặp phải đó là khi phát triển Base Wework. Thời điểm mình bắt đầu tiếp nhận phụ trách sản phẩm này cũng chính là lúc app được nâng cấp version mới, kiến trúc thay đổi nhiều, các tính năng cũng chưa hoàn thiện, và “căng” nhất chính là bởi Base Wework là app có lượng người dùng lớn nhất lúc bấy giờ.
Anh có thể chia sẻ cụ thể hơn về quá trình nâng cấp Base Wework?
Tại thời điểm ấy, có thể nói thử thách lớn nhất chính là trong kiến trúc của app có sự thay đổi rất lớn về cách mã hóa dữ liệu, dẫn tới một loạt dữ liệu cần phải chạy sysfix để có thể chạy đúng trên mã code mới.
Phần cần thay đổi ở đây không liên quan dữ liệu gốc của khách hàng, mà chỉ là phần các khóa liên kết các bảng dữ liệu với nhau. Chẳng hạn như tất cả các công việc được tạo ra trên Base Wework đều có phần bình luận, nếu phần khóa liên kết bị giải mã sai thì khi mở một công việc đã tạo, server sẽ không trả về được các bình luận thuộc về công việc đó.
Vấn đề khiến mình “đau đầu” nhất chính là bởi Base Wework là một app có lượng dữ liệu rất lớn, để chạy xong sysfix thì có thể mất vài tuần. Tại sao ư? Bởi vì mặc dù bản chất của việc sysfix chỉ là viết mã chạy qua tất cả dữ liệu, cập nhật một vài trường theo kiến trúc mới, nhưng phần xử lý liên quan đến mã hóa thì lại cần rất nhiều thời gian, thế nên dù tối ưu theo cách nào thì tổng thời gian cần thiết để hoàn thành nhiệm vụ đó vẫn là quá lớn.
Cuối cùng, sau hơn một ngày mày mò và tìm tòi, thử nghiệm và thảo luận cùng team, mình đã quyết định rằng thay vì cố gắng giảm thời gian xử lý từng data, thì nên giảm phạm vi cần phải sysfix xuống, và chính hành động cập nhật dữ liệu này cũng sẽ không phải do mình làm từ phía server nữa, mà sẽ được thực hiện từ chính hành động truy cập của người dùng.
Có một hệ thống tương đối phức tạp đã được tạo ra để làm nhiệm vụ xác nhận, cập nhật dữ liệu và gắn cờ đánh dấu các dữ liệu đã fix thành công. Phần việc sysfix được chia nhỏ về từng cụm dữ liệu của khách hàng, và chỉ chạy một lần duy nhất do hệ thống đánh dấu nên hầu như không gây ảnh hưởng đến trải nghiệm của khách hàng. Kể từ đó trong team Product xuất hiện một thuật ngữ mới là “hotfix” – chính là tên của kỹ thuật mà team mình đã sử dụng trong thử thách này.
Tất nhiên đó chỉ là kỹ thuật mà team dùng khi lần đầu tiên phải đối mặt với vấn đề kiểu như vậy. Tới thời điểm hiện tại, việc thiết kế hệ thống đã được nâng tầm chiến lược để có thể ngăn ngừa tối đa các trường hợp thay đổi kiến trúc nghiêm trọng. Và ngay cả trong những trường hợp không thể tránh khỏi, thì kỹ thuật để xử lý những case này cũng đã được nâng cấp lên thành một chiến thuật mà mình gọi là “Sysfix 3 giai đoạn” với độ chính xác tuyệt đối và không hề phải lo lắng về thời gian thực thi cho dù dữ liệu lớn đến đâu. Tất cả những điều trên, nếu ai tò mò muốn biết cụ thể nó hoạt động như thế nào thì mình sẵn sàng chia sẻ chi tiết, nhưng tất nhiên là “bí kíp” chỉ dành cho các Dev đã về với nhà Base mà thôi 🙂
Còn hiện nay thì sao, Base đang tập trung phát triển những sản phẩm nào?
Hệ sinh thái của Base gồm hơn 50 sản phẩm được chia thành nhiều bộ khác nhau, tập trung giải quyết 3 bài toán cốt lõi của doanh nghiệp: Quản trị công việc, quy trình và dự án toàn diện, Quản trị thông tin và giao tiếp nội bộ và Quản trị và phát triển nhân sự toàn diện. Trong mỗi bộ cũng sẽ có những app chủ lực, cũng chính là những sản phẩm chiến lược được ưu tiên phát triển.
Hiện tại các bộ sản phẩm đã chính thức ra mắt là Base Platform, Base Work+, Base HRM+, Base Info+ và vẫn còn các bộ khác đang trong quá trình phát triển.
Là người phụ trách chính trong việc phát triển rất nhiều sản phẩm ở Base như vậy, chắc hẳn anh đã rèn luyện cho mình thêm nhiều kỹ năng trong suốt 4 năm qua?
Anh Hùng, CEO của công ty, đã từng nói rằng Base là nơi dành cho những người muốn xây dựng sản phẩm một cách tử tế. Và thực tế đúng là như vậy. Trong hành trình mấy năm luôn tìm kiếm và suy nghĩ để tạo ra được những sản phẩm thực sự tử tế, mình đã được học hỏi và cũng thay đổi không ít.
Việc làm lập trình viên tại Base đã trau dồi cho mình rất nhiều kỹ năng, trong đó quan trọng nhất chính là Khả năng điều tra, dự đoán nguyên nhân bug (Debug, tracking, detection, discovering system logs…), Phân tích, thiết kế tính năng sản phẩm (Business Analysis, Technical, UI, UX…), Phân tích bài toán của khách hàng, lựa chọn giải pháp (cách thức triển khai phần mềm, thiết kế tính năng mới…) và Chiến lược phát triển phần mềm (Project Planning, Launching app…).
Vậy anh có thể chia sẻ một chút về khả năng điều tra và dự đoán nguyên nhân bug của mình không? Khi có lỗi xảy ra, phản ứng của một “chiến binh” lâu năm như anh là gì?
Mindset đầu tiên khi fix bug, đó chính là khi có lỗi xảy ra, chắc chắn phải có nguyên nhân của nó chứ không có cái gì gọi là “magic” ở đây cả. Chúng mình vẫn thường nhắc nhau là “Đừng bao giờ nói rằng code chạy ngon lành trên máy của tôi, không hiểu sao cho lên production lại lỗi?”, và cũng đừng hỏi rằng “Tính năng này mọi người dùng bình thường, không hiểu tại sao chỉ có mỗi người dùng đó, hoặc trình duyệt đó hoặc tại thời điểm đó với công việc, nhiệm vụ đó… lại bị lỗi”. Mọi thứ luôn có nguyên nhân của nó, và việc của bạn là bằng mọi cách phải tìm ra vấn đề đằng sau, bản chất gốc rễ thứ đã gây ra lỗi.
Sau nhiều năm làm nghề, mình đã rút ra được một vài kinh nghiệm “để đời” giúp mình có thể nhanh chóng tìm ra nguyên nhân sâu xa bên trong mỗi lần gặp lỗi. Mình nghĩ các bạn Dev cần phải tích lũy đủ nhiều kiến thức và kinh nghiệm, và cao hơn nữa là chiến lược, chiến thuật để tìm kiếm nguyên nhân và bản chất vấn đề.
Và quan trọng nhất, đó chính là thái độ của các bạn khi đối diện với một bug phức tạp và khó hiểu. Dựa trên trải nghiệm của bản thân, mình chia yếu tố này thành 3 cấp độ, tương đương với mức độ phức tạp tăng dần của bug.
Thứ nhất, bạn đừng tin code của chính mình
Nếu đã có lỗi xảy ra, việc đầu tiên bạn nên làm đó là nghi ngờ code mà mình đã viết ra. Đừng đổ lỗi cho bất kỳ thứ gì mà hãy tự hỏi rằng: “Code bạn viết đã check đủ điều kiện của dữ liệu chưa?, Dữ liệu người dùng nhập vào có đúng định dạng không, có vượt quá giới hạn của hệ thống không, có chứa các ký tự đặc biệt không, hay có đang cố gắng chèn thêm một đoạn script độc hại nào đó hay không?
Mình nghĩ rằng một Dev cần phải nhớ rằng luôn có 1001 kiểu user, và chắc chắn luôn có những người sẵn sàng “nhét” cả một đoạn text dài hơn một bài phóng sự hay một chương tiểu thuyết vào ô input của bạn. Tại sao người dùng lại có những thao tác như vậy? Đó không phải là điều quan trọng nhất lúc này. Điều đầu tiên bạn cần làm nhất trong mỗi lúc như thế chính là check lại tất cả những gì đã viết thật kỹ.
Thứ hai, bạn đừng tin code của người khác
Sau khi đã rà soát vô cùng cẩn thận phần code mình viết mà vẫn không thấy lỗi, hãy nghi ngờ những phần code khác.
Đôi khi chúng ta sẽ cần dùng thư viện của những người khác, nhưng bạn đừng nghĩ rằng vì nó phổ biến hay được nhiều người sử dụng tức là nó không có bug. Rất có thể bên trong đó vẫn có những lỗi liên quan đến xử lý một vài ký tự đặc biệt có thể làm lỗi file khi bạn làm các tính năng xuất nhập dữ liệu file excel, khi in thông tin theo file word mẫu hay khi phải chuyển đổi file word sang pdf.
Hoặc cũng có thể là những thư viện javascript mà phần tương tác với DOM không được tối ưu, dẫn tới thời gian render có thể tăng lên vài chục lần. Tệ nhất chính là một vài extension mà phần style đi kèm có chứa cả những đoạn CSS important! với những class HTML cực kỳ phổ biến, có thể “phá tan tành” giao diện của cả một trang web.
Với những lỗi kiểu như vậy, hoặc là loại bỏ (extension) hoặc là sửa vào core bên trong (library). Những việc đó đối với Dev ở Base đã trở nên hết sức quen thuộc.
Thứ ba, bạn đừng tin bất kỳ ai
Mình nghĩ đã là con người khó tránh khỏi sai lầm, chỉ có dữ liệu là thứ không bao giờ sai. Thực ra bug khó fix nhất chính là thực sự không có bug nào cả, mà chỉ là do người dùng vô tình thực hiện một thao tác nào đó chưa đúng và báo sai, khiến chúng mình phải “bật mode thám tử” để chứng minh được là chẳng có bug nào cả.
Mình có thể lấy ví dụ với Base Wework – app nhiều người nhất và cũng hay có những thông báo kiểu như vậy. Có trường hợp, người dùng tạo task và upload file lên Base Wework nhưng sau vài ngày mở lại task thì không thấy file đâu nữa. “Base đã làm mất dữ liệu của chúng tôi rồi” là câu mà mình đã từng “được” nghe.
Bản thân mình có thể khẳng định rằng Base Wework nói riêng và tất cả các app của Base nói chung không có bất kỳ chức năng nào có thể tác động làm mất dữ liệu của người dùng. Thế nhưng chúng mình luôn đặt vào vị trí của khách hàng và hoàn toàn hiểu họ. Họ đang không tìm thấy thứ mà họ mong muốn, và đương nhiên là sẽ có phàn nàn. Nhưng chúng mình tự tin rằng vấn đề thực tế có nhiều chi tiết phức tạp và có thể khách hàng đã vô tình bỏ qua mất bước nào đó. Nhiệm vụ lúc này là phải tìm ra nguyên nhân thật sự đã dẫn đến sự “biến mất bí ẩn” ấy của các dữ liệu.
Với những trường hợp như thế này, chúng mình sẽ bỏ qua những tình tiết mơ hồ kiểu “tự nhiên lại mất hết tài liệu”, thay vào đó, mình tập trung vào hiện tượng thực tế “đã từng có tài liệu nhưng giờ thì không còn”.
Điều này có nghĩa là đã có hành động Xóa, và may mắn là ở app của Base, tất cả hành động xóa file đính kèm đều được lưu lại trong log. Thế nhưng may mắn ấy cũng không kéo dài được bao lâu, khi mà mình mở phần Activity logs của nhiệm vụ đó trên Base Wework thì không có hành động xóa file đính kèm nào được ghi lại cả.
Nhưng theo mô tả của khách hàng thì chắc chắn đã có một task với tên như vậy đã được tạo ra, cùng với đó là một file được upload lên thuộc task đó. Lúc này, mình nghĩ ngay đến một thứ của Base Wework: tính năng nhân bản dự án. Tính năng này cho phép người dùng nhân bản cả một dự án và tất cả các task trong dự án đó. Thế nhưng, các file đính kèm trong các task thuộc dự án mới thì chưa hỗ trợ nhân bản cùng dự án. Tức là có khả năng đã có hành động nhân bản dự án cũ để tạo ra 1 dự án mới khác, sau đó dự án cũ kia bị xóa đi.
Vậy là giờ mình cần check xem có log nào việc xóa dự án có tên theo như mô tả của khách hàng hay không. Và rất tiếc, cũng không có log nào ghi nhận việc xóa dự án có tên như vậy. Thậm chí ngay cả khả năng là chính người dùng đã xóa task đó và tạo lại task cùng tên cũng không đúng, vì cũng không có log nào ghi nhận việc xóa một task với tên như vậy cả. Vậy là bằng một cách bí ẩn nào đó, task đã được xóa mà không hề có dấu vết !
Rồi mình cũng có một phát hiện đáng ngạc nhiên khác, đó chính là tên của task đang xem xét có chứa thành phần kiểu ngày/tháng/năm. Đây chính là kiểu task được sinh ra từ Tính năng tạo công việc lặp lại của Base Wework. Nó củng cố cho giả thuyết của mình, rằng bằng cách nào đó mà file đã bị xóa mà không được log ghi lại.
Sau khi “lội” qua rất nhiều giả thiết như vậy và tìm ra “thủ phạm” thực sự với rất nhiều nỗ lực và không ít lần “bốc hỏa”, cuối cùng thì chúng mình đã phát hiện ra “thủ phạm”, đó chính là hành động xóa một tasklist (nhóm công việc) có chứa task mà chúng mình cần check. Với hành động này, sẽ chỉ có log xóa tasklist được ghi nhận chứ không có log cho từng task bị xóa. Tất nhiên là như vậy rồi, vì 1 tasklist có thể có đến hàng chục đến hàng trăm task bên trong, nếu xóa thì cũng chỉ có thể log lại thứ đại diện cao nhất chứ không thể lưu hết tất cả chi tiết bên trong được (và hệ thống Base cũng đã hiện ra những màn hình cảnh báo Dangerous rất sống động và cho người dùng 1 khoảng thời gian để suy nghĩ trước khi ấn nút thực hiện những hành động kiểu “Thanos búng tay” như này 🙂 )
Vậy là đã rõ “thủ phạm”, nhưng vẫn còn một “đồng phạm” nữa, đó chính là Tính năng tạo công việc lặp lại. Tính năng này đã tạo ra task mới theo đúng lịch đã được người dùng thiết lập trước đó, và task đã bị xóa trong tasklist kia lại được sinh ra với tên y hệt task lúc đầu, chỉ khác là đã không còn file đính kèm nào cả (vì file là người dùng chủ động upload lên sau khi task được sinh ra chứ không có trong setup của công việc lặp lại). Và rất dễ hiểu khi mà khách hàng không thể nhận ra sự khác biệt giữa 2 task như vậy.
Sau đó, khi chúng mình trình bày với khách hàng nguyên nhân đằng sau “sự mất tích” ấy của dữ liệu, thấy họ từ “mắt chữ O, miệng chữ A” vì quá kinh ngạc, rồi chuyển sang hoàn toàn tin tưởng vào cả hệ thống phần mềm lẫn đội ngũ phát triển sản phẩm của Base, thì mình biết là mọi cố gắng đều rất xứng đáng.
Để có được một tâm lý vững vàng với nguyên tắc 3 “đừng tin” như anh đã chia sẻ ở trên, anh nghĩ các bạn Dev cần có nền tảng như thế nào?
Mình nghĩ để có thể debug được những ca phức tạp như vậy, không chỉ đòi hỏi kiến thức, kinh nghiệm, mà còn cần sự quyết tâm cao độ và một vài chiêu thức, chiến lược, thậm chí là cần cả cảm nhận của một thám tử đang điều tra phá án để tìm ra thủ phạm thực sự để đòi lại công bằng nữa.
Mình tin tưởng vào chất lượng sản phẩm của Base, tin tưởng vào phương pháp luận của mỗi sản phẩm cũng như triết lý xây dựng sản phẩm của Base – nơi dành cho những sản phẩm thực sự tử tế và những người muốn “build” sản phẩm một cách tử tế. Thế nên, mỗi lần xảy ra lỗi gì đó, chúng mình đều bắt tay vào xử lý với quyết tâm cao độ “tìm lại công bằng”.
Mình vẫn thường nói với các thành viên trong team rằng để làm Dev ở Base thì nên đọc thật nhiều Conan để có thêm một vài cách suy luận cơ bản, và nếu muốn tài liệu nâng cao hơn thì nên tìm đến Sherlock Holmes.
Cụ thể hơn, ngoài đọc truyện trinh thám, với vai trò là team leader, anh hi vọng đồng đội mới của mình là những người như thế nào?
Có 3 điều mà mình luôn kỳ vọng ở đồng đội.
Thứ nhất, chắc chắn rồi, phải là những người thực sự có năng lực. Các bài toán mà Base đang giải đều cực kỳ phức tạp và là không giới hạn. Mình hi vọng được làm việc với những cộng sự thông minh, nhanh nhẹn, có nền tảng kiến thức tốt và luôn chăm chỉ, nỗ lực để nâng cao trình độ.
Thứ hai, đó là trách nhiệm. Base luôn sẵn sàng đầu tư vào Dev, từ đào tạo, hướng dẫn, đến trao cơ hội, thử thách để bạn có đủ năng lực làm Product Owner của các sản phẩm. Mỗi một hành động fix bug hay add feature của bạn đều có thể ảnh hưởng đến hàng nghìn doanh nghiệp và hàng triệu người dùng. Chính vì thế, lập trình viên ở Base phải là những người có tinh thần trách nhiệm cực cao.
Cuối cùng, đó là tham vọng. Mình nghĩ rằng thành tích và điểm số trong quá khứ là điều kiện cần để một Dev được tuyển vào Base. Nhưng trong suốt quá trình gắn bó, điều mà công ty coi trọng hơn cả chính là những kết quả bạn ấy đạt được ở hiện tại, là những di sản mà bạn sẽ để lại cho công ty sau này.
Base là một công ty trẻ trong làng công nghệ, con đường phía trước còn dài cùng với đó là rất nhiều thách thức. Thế nên chúng mình rất cần những đồng đội có tham vọng lớn. Dù mục tiêu của bạn là phát triển năng lực bản thân, đạt thành tựu, vinh danh hay bất cứ thứ gì khác, chỉ cần mục tiêu ấy cùng chia sẻ những giá trị chung với mục tiêu của Base, thì mình thực sự sẽ rất tự hào khi có bạn đồng hành trên con đường hoàn thiện hệ sinh thái chuyển đổi số toàn diện cho 800.000 SMEs Việt Nam, và xa hơn nữa là vươn ra thế giới.
—-
Anh Kiên vẫn thường nói với tôi rằng “game của Base rất khó và nhiều thử thách”, và Dev nào cũng luôn tâm niệm “The best or Nothing”. Thế nên tất cả những ai đang tham gia vào “game” này đều là những người dũng cảm và rất được trân trọng ở Base. Ở team Product, chẳng ai nhắc đến 2 chữ “thành công” dù có đạt được những kết quả ấn tượng như thế nào hay được khen ngợi và vinh danh ra sao. Ở đó, tôi vẫn thấy những con người ấy luôn tiến về phía trước, không cho phép bản thân nghỉ ngơi trên vòng nguyệt quế vinh quang.
Từ ngày tìm hiểu về team Product ở Base, tôi bắt đầu hiểu ra rằng họ thực sự không “kỹ thuật” và “khô khan” như những gì mà người ta vẫn miêu tả về “dân code”. Hoặc cũng có thể, chỉ “dân code” ở Base mới không như vậy. Ở đó, vào giờ tan tầm khi những con đường của Hà Nội ùn tắc, tôi vẫn thấy những con người đang mải mê “đá” nhau cực gắt trên bàn cờ cá ngựa, không hề “nương tay” với nhau trong AOE hoặc “ăn thua” với nhau từng lá bài Uno.
