“Nghề” Front-end #2: Team Front-end ở Got It làm việc như thế nào?

Như đã hứa ở phần 1, ở bài viết này mình sẽ mô tả chi tiết quy trình làm việc của team Front-end ở Got It.

“Nghề” Front-end #1: Tưởng tượng và thực tế

3. Quy trình làm việc của team Front-end ở Got It như thế nào?

Mặc dù các thành viên trong team Front-end rất yêu thương và đùm bọc lẫn nhau trong những buổi họp về yêu cầu sản phẩm với Technical Product Manager (TPM) (luôn đồng thanh kêu ca phản đối những requirement trên trời), thì công việc của cả team vẫn luôn được thực hiện nghiêm túc và hiệu quả.

Trong quy trình 10 bước ở Got It, Front-end Engineer chủ yếu tham gia vào những bước ở giữa. Và mình sẽ mô tả những bước này dưới dạng kể một câu chuyện (có thật) như sau:

Bước “Đọc requirement và cãi nhau”

• Một ngày đẹp trời, có một cậu Front-end Intern tại Got It, mình tạm gọi là Erico, đang miệt mài ngồi viết unit test cho các file còn thiếu, với mục tiêu khá rõ ràng là để coverage của test đạt trên 80%. Khi đó code của cậu ít bug hơn hay không, cậu cũng không biết, nhưng vì 80 là một con số đẹp nên cậu chọn.
• Đùng cái, một sản phẩm mà cả team ươm mầm ý tưởng đã lâu nay được thông báo sẽ triển khai và đã đến bước Estimation. Cả công ty hào hứng vì sắp được bắt tay vào làm 1 sản phẩm hay ho, Erico cũng rất mong đợi.

Erico trong một Hackathon nội bộ ở Got It

• Cả team Back-end, Front-end và QA cùng ngồi lại để ngồi nghe anh Technical Product Manager — TPM (mình tạm gọi là anh Franky) mô tả về hình thù của sản phẩm sắp tới. Buổi họp hẳn là một cuộc chiến giữa 2 phe: Engineer muốn bớt requirement, còn PM thì muốn thêm, trong khi team QA là tổ tư vấn tại chỗ, chuyên đặt những câu hỏi hóc búa để làm rõ yêu cầu. Nói vậy thôi chứ cuộc họp có tính xây dựng rất cao, và sau khoảng “vỏn vẹn” 8 tiếng là tất cả đã hiểu và thống nhất được những feature nào sẽ có mặt trong release này (team Engineer thường thắng khi lượng feature giảm đáng kể so với ban đầu).
• Sau đó, Tech Lead cùng team engineer sẽ ngồi lại với nhau để giao việc cho từng cá nhân sẽ tham gia làm release, và các thành viên phải tự ước tính chi tiết phần của mình làm để đảm bảo tiến độ luôn chính xác (Erico do mắc bệnh thành tích nên rất hay estimate thiếu ngày).

Bước “Design review”

• Trước khi bắt tay vào việc, cả team Front-end sẽ ngồi với nhau để làm khâu Design Review — đặc sản tại Got It. Mỗi cá nhân sẽ tự thiết kế xem phần của mình sẽ làm như thế nào một cách chi tiết, sau đó cả team sẽ thảo luận để đưa ra cách làm phù hợp nhất. Sau khi đã thống nhất xong xuôi một bộ các cấu trúc component, logic xử lý, convention khi code… cho các feature lần này, thì mới đến bước bắt tay vào code.

Team Front-end bọn mình

Bước “Em bị block bởi HTML”

• Team Front-end mỗi khi cần xây dựng một Web App mới thì sẽ set up codebase khá nhanh nhờ vào boilerplate và một private npm package chứa những thành phần code JS và React hay được tái sử dụng mà team đã và đang xây dựng.

Ngày Design System ra đời!

• Mặc dù code giao diện nhưng team Front-end lại không phải làm quá nhiều về giao diện bởi đã có thế lực thần thánh: team Designer và HTML/CSS Engineer. Ngay ở bước Estimation, những giao diện đã được team Designer vẽ lên nhanh chóng nhờ có một sản phẩm nhà làm cực cool của Designer song kiếm hợp bích với Front-end tạo nên: Got It Design System. Mình sẽ để dành content phần này cho bài viết sắp tới của team Design, mọi người đón đọc nhé!
• Tuy nhiên, nếu chỉ có bản design thì đôi mắt trần tục của Front-end team cũng không thể code lên những giao diện đó ngay được. Đó chính là lúc HTML/CSS Engineer ra tay. Nhờ có những guideline của Design System, các HTML/CSS Engineer đã xây dựng lên các thư viện React Component có thể tái sử dụng được. Chúng giống như những viên gạch mà Front-end engineer có thể dễ dàng lắp ghép để tạo nên giao diện. Nếu bạn đã từng sử dụng các UI Library nổi tiếng như Ant Design, hay MaterialUI, thì Design System của Got It cũng cool như thế, chỉ việc lắp vào với logic là đã có giao diện rồi!
• Tuy nhiên, bàn tay gỗ của Front-end Engineer chỉ quen viết những logic phức tạp, vẫn cần HTML/CSS Engineer xây lên các layout để giống 100% so với design, và vì thế 2 team cùng sử dụng storybook, một công cụ giúp nhanh chóng tạo layout không chứa logic từ các React component một cách dễ dàng.
• Chính vì 2 team cùng làm việc với nhau như hình với bóng như thế, nên nhiều khi Front-end làm nhanh quá, vẫn hay kêu với anh Franky rằng “em bị HTML block, anh giục team design làm nhanh lên với ạ”. Nhưng ít lắm, hầu như chỉ cần hú một cái là cả team design và HTML/CSS đều làm nhanh thoăn thoắt để support các team khác (Yayyy!).

Những ngày GitHub và Slack lên ngôi…

Bước “Mạng xã hội GitHub”

• Sau khi các cá nhân đã code xong phần của mình, là đến lúc Review Pull Request. Các anh em vẫn thường ví von đây là lúc mọi người “lướt GitHub”, do những request thay đổi khá nhiều, cùng với rất nhiều những lời bào chữa cho những dòng code xấu của mình (chủ yếu là của Erico và anh Robeto) khiến GitHub những ngày này rất sôi động.
• Khi mà code đã được sửa sạch đẹp, mọi người sẽ cùng ngồi tích hợp lại để chuẩn bị cho một bước quan trọng cuối cùng: ghép với Back-end.

Bước “Bug của ai đây?”

• Sau khi đã code xong Front-end chỉ từ API spec mà Back-end đưa, thì giờ là lúc 2 team ngồi lại để ghép ra sản phẩm (có thể) chạy được. Mà thường là nó sẽ không chạy, nên “Lỗi xảy ra ở code của ai đâyyy?” là câu sẽ được hỏi định kỳ mỗi 10 phút. Với kinh nghiệm 1 năm làm Front-end tại Got It thì mình có thể khẳng định team Back-end thường tạo ra nhiều bug hơn 😬.

Bước “Nhuộm xanh bug list”

• Sau khi ghép xong sản phẩm và được deploy lên môi trường development, team QA sẽ bắt tay vào test và log bug vào bug list với sự giúp đỡ của Engineer. Mỗi khi một bug mới được log vào, là Front-end và Back-end lại tiếp tục cãi nhau xem bug của ai (Front-end thường sẽ ít bug) và sửa rất nhanh trước khi nhuộm xanh dòng bug bằng status FIXED.

Trước và sau công cuộc nhuộm xanh bug list!

• Nếu tất cả các bug đã được fix, thì công việc của Engineer nói chung và Front-end nói riêng đã hết cho release này rồi (nếu không phải hotfix bug trên production, cầu trời 🙏). Giờ là lúc để chiêm ngưỡng thành quả cố gắng của cả team — sản phẩm siêu xịn được đưa đến tay end user!

Vậy là sau bài viết cũng hơi dài, mình đã chia sẻ được phần nào cuộc sống thú vị của một Front-end Engineer tại Got It cho các bạn cùng biết. Nếu muốn trực tiếp cảm nhận niềm vui khi làm ở team Front-end ở Got It cho những sản phẩm world class thì cùng join với bọn mình nhé! (Các vị trí: bit.ly/gotit-jobs-hanoi)

Nhắn nhủ của tác giả:

– Front-end tại Got It không phải chỉ ngồi code HTML/CSS.

– Viết unit test để kiểm soát được bug, không phải để đạt coverage lấy thành tích.

– Đừng bệnh thành tích như Erico và anh Robeto!

• Đọc “Nghề ” Front-end #1: Tưởng tượng và thực tế