“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 tại 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 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ả.

G Process — Quy trình làm việc cho một release ở Got It

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 DesignerHTML/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 Front-end cho những sản phẩm world class tại Got It thì cùng join với bọn mình nhé!

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ế

Nếu bạn quan tâm, hãy xem các vị trí đang tuyển dụng của Got It và đọc thêm về quy trình tuyển dụng tại đây.

Tìm hiểu thêm về Got It tại:

 

Facebook

LinkedIn

Instagram

YouTube

Gmail

Zalo

 

Đăng ký nhận newsletter để không bỏ lỡ các bài viết bổ ích và thông tin mới nhất từ Got It

* indicates required

Nếu bạn quan tâm, hãy xem các vị trí đang tuyển dụng của Got It tại: bit.ly/gotit-hanoi và đọc thêm về quy trình tuyển dụng tại đây.

https://vn.got-it.ai/blog/wp-content/uploads/2021/04/1_QAG9RXQyyMAY7i9OYo84FA.png
Got It Vietnam
January 07, 2020
Share this post to:
Tags:
0 Comments
Inline Feedbacks
View all comments
Các bài viết liên quan
Hành trình ở Got It tác động thế nào đến phong cách và tư duy lập trình viên?

Hành trình ở Got It tác động thế nào đến phong cách và tư duy lập trình viên?

Tư duy lập trình viên và phong cách làm việc của họ có sự thay đổi thế nào trước và sau khi làm việc tại Got It? Hãy cùng lắng nghe những chia sẻ từ góc nhìn của cả trainer và trainee tại Got It trong bài viết dưới đây để biết được những điểm […]
Làm đồng thời Manual và Automation Tester là trải nghiệm thế nào?

Làm đồng thời Manual và Automation Tester là trải nghiệm thế nào?

Manual và Automation Testing vốn có nhiều điểm khác biệt, nhưng nếu làm song song cả hai công việc này một lúc, một người Tester sẽ có trải nghiệm thế nào? Câu chuyện dười đây kể về Samsam – một người trẻ gắn bó với cả hai mảng kiểm thử từ những ngày đầu tiên, […]
Khi con gái làm IT: Thách thức và bài học?

Khi con gái làm IT: Thách thức và bài học?

Dù xu hướng ngày nay đã có ít nhiều thay đổi, song con gái làm IT vẫn có thể được coi là “những bông hoa hiếm có khó tìm”. Uyên Trần: Cuộc trò chuyện ngày hôm nay của chúng ta có chị Hoà, người đã làm Developer hơn 10 năm và cả Sam, Ellie, những […]
Software Engineer và câu chuyện làm sản phẩm

Software Engineer và câu chuyện làm sản phẩm

Làm sản phẩm hay outsource tốt hơn? Đó là một chủ đề vẫn luôn được bàn luận cùng những ý kiến trái chiều. Bài viết dựa trên những quan điểm cá nhân nên chỉ mang tính tham khảo, hy vọng bạn sẽ đón nhận với một tâm thế cởi mở và comment bên dưới để […]
Chuyện làm HR trong ngành IT

Chuyện làm HR trong ngành IT

Q: Vốn tốt nghiệp Ngoại thương, cánh cửa nào đã đưa Hiền đến với công việc HR trong ngành IT? Khởi đầu của bạn diễn ra như thế nào? A: Lúc đầu, mình chỉ nghĩ muốn làm việc gì liên quan đến con người thôi, vì tính mình dễ hoà đồng, chứ cũng không đặt […]
Con đường IT nào dành cho dân kinh tế?

Con đường IT nào dành cho dân kinh tế?

Cơ hội mới dành cho ai không biết lập trình, ghét việc “bàn giấy"!