#262 - 5 ways to review code without wasting everyone’s time
📰Những bài viết hay
5 ways to review code without wasting everyone’s time
(by quangle)
Là một developer, chắc hẳn review code là công việc mà chúng ta sẽ gặp hằng ngày. Sau đây là 5 gợi ý mà tác giả - kỹ sư tại Volvo Cars đúc kết trong quá trình làm việc để có thể review code một cách hiệu quả:
Kiểm tra pull requests có đáp ứng được các yêu cầu đặt ra của team (ví dụ: có unit tests chưa, có documentation chưa, v.v)
Cung cấp thêm nhiều góc nhìn mới về pull request của người khác (ví dụ: các vấn đề về lỗi chính tả, đặt tên biến, khoanh vùng những context khó hiểu, v.v)
Không ngại đặt câu hỏi và cung cấp feedbacks cho người được review code
Nói “không” với những pull requests chưa rõ ràng (ví dụ: pull request có hơn 5,000 file changes, v.v)
Viết comment code “nhẹ nhàng”, mang tính xây dựng và đóng góp để người được review code có thể cải thiện
Để tìm hiểu chi tiết hơn về từng key point, mời bạn đọc cùng tham khảo bài viết
Getting More from Your Team Health Checks
(by steven.do)
Tại Spotify việc theo dõi và kiểm tra tính hiệu quả (health-check) trong các đội nhóm đã được triển khai áp dụng trong một thời gian dài. Các team đội sẽ tạm dừng các hoạt động hàng ngày của để tiến hành việc đánh giá hiệu quả nhằm giúp các đội có cái nhìn bao quát hơn về cách các thành viên trong mỗi đội nhóm đang làm việc. Với mục đích cải thiện sự tự nhận thức của mỗi thành viên đồng thời cho phép họ nhìn thấy rõ hơn các cơ hội cải thiện, phát triển các kỹ năng cá nhân và phối hợp làm việc với đội nhóm hiệu quả và giải toả các mâu thuẫn bất đồng nảy sinh trong quá trình làm việc. Các kết quả tổng hợp từ các kiểm tra đánh giá tình trạng dội nhóm này cũng cung cấp cho trưởng bộ phận quản lý các đội một cách để theo dõi các mô hình và xu hướng phát triển trên nhiều đội nhóm theo thời gian để có thêm dữ liệu nhằm hỗ trợ các hoạt động của các đội nhóm kịp thời.
Nhìn chung, hoạt động đánh giá sức khỏe đội nhóm tại Spotify bao gồm các bước như sau:
Khảo sát dựa trên một bảng câu hỏi về tech đội nhóm đang sử dụng, đánh giá tình hình hoạt động của đội nhóm, đánh giá tình trạng của sản phẩm của đội nhóm.
Tổ chức buổi thảo luận về kết quả của bản khảo sát giữa các thành viên trong đội nhóm và thảo luận đưa ra hướng xử lý khắc phục.
Tổng hợp kết quả các ý kiến đóng góp và khảo sát từ nhiều đội nhóm nhằm xác định các đặc trưng và điểm tương đồng giữa các vấn đề các đội nhóm đang gặp phải ở mức độ tổng quan.
Bài viết cũng cung cấp thêm nhiều thông tin và phương pháp giúp việc trao đổi và khuyến khích các thành viên trong mỗi đội nhóm nêu lên ý kiến và quan điểm nhận định cá nhân nhằm giúp cho các nhà quản lý nắm bắt được rõ ràng hơn về các vấn đề đang tồn tại và gây ảnh hưởng đến hiệu quả hoạt động của đội nhóm.
💭Góc bạn đọc
Nhóm biên tập có nhận được nội dung chia sẻ từ bạn đọc T đang làm việc ở một công ty công nghệ với quy mô trên 1000 nhân sự dưới vai trò Engineer Manager. Nhóm sẽ bắt đầu trích đăng nội dung chia sẻ của bạn viết về công việc hàng ngày của mình trong các số newsletter tới.
Ngoài ra, để nội dung thêm phong phú nhóm cũng hy vọng có dịp phỏng vấn các bạn đang làm việc ở các công ty công nghệ với các vai trò khác nhau như Software Engineer, QA, Manager, Product Owner, ML Ops, DevOps… chia sẻ thêm về công việc hằng ngày và những thách thức trong công việc của mình. Bạn nào sẵn lòng chia sẻ vui lòng reply email này, nhóm sẽ sắp xếp một buổi phỏng vấn để tìm hiểu về công việc của bạn để viết lại và gửi đến cho cộng đồng.
Một tuần làm việc của Engineer manager ra sao? (p2)
Thứ ba
Sáng thứ ba thường sẽ bắt đầu bằng họp stand-up online với team nhỏ đang trực tiếp phụ trách. Trong buổi stand up các thành viên sẽ mở tasks board ra, sau đó từng thành viên sẽ lần lượt điểm qua các việc đã làm ngày hôm trước cũng như nêu ra các vấn đề cần xử lý. Nếu có vấn đề cần thảo luận thì các thành viên có thể tự hẹn để thảo luận riêng sau đó. Trong hoạt động này thì với vai trò EM, bản thân chỉ tham gia để cập nhật thông tin là chủ yếu, hoặc thỉnh thoảng có thể đưa ra góp ý về hướng xử lý một ticket là thoả đáng hay chưa.
Phần còn lại của buổi sáng sẽ là họp Operational Excellent của toàn công ty. Trong buổi họp này, các team phụ trách về vận hàng sẽ điểm qua nhiều vấn đề như tình hình cost, các incidents, các vấn đề về security, các vấn đề về độ ổn định chung của toàn hệ thống theo các nhóm service khác nhau. Ngoài ra, các team nào có sự cố sẽ trình bày Post Mortem của team mình.
Nói thêm một tí về Post-Mortem (PM), cấu trúc thường có của một PM thường bao gồm:
Giới thiệu tổng quan về sự cố
Timestamp các sự kiện diễn ra trước, trong và sau khi sự cố
Phân tích sâu về nguyên nhân gốc rễ dẫn đến sự cố
Các hành động đã làm để phục hồi hệ thống cũng như giảm thiểu thiệt hại (mitigate)
Bài học kinh nghiệm cần rút ra.
Đối với một tổ chức lớn vận hành nhiều service phức tạp thì các PM là một hoạt động rất quan trọng vì nó sẽ giúp chúng ta rút kinh nghiệm mỗi khi có sự cố xảy ra. Một PM tốt cần phân tích sâu và đến gốc rễ vấn đề (Root-cause) để từ đó có thể rút ra bài học cho các service khác có thể áp dụng. Quá trình phân tích cũng có thể áp dụng nhiều kỹ thuật nhưng phổ biến nhất là 5-whys: đặt liên tục 5+ câu hỏi tại sao cho đến khi có thể chạm đến gốc rễ.
Ví dụ về quá trình đặt câu hỏi 5-whys được đơn giản hoá để có thể dễ hình dung:
Tại sao lại service A lại có gặp lỗi 500 liên tục trong khung thời gian 15 phút từ thời điểm 11:00am đến 11:15am? → Tại vì service A gọi đến service B, service B trả về kết quả với độ trễ p99=800ms trong khi yêu cầu từ service A là 150ms.
Tại sao service B lại trả về kết quả với độ trễ p99=800ms trong khung thời gian đó? → Tại vì database service B đang dùng trả về kết quả cho endpoint XX với độ trễ p99=700ms, cao hơn thường lệ.
Tại sao database service B đang dùng lại trả về kết quả có độ trễ cao p99=700ms và cao hơn thường lệ? → Tại vì một partition của database đang dùng bị overload dẫn đến các request đến partition này có độ trễ cao hơn.
Tại sao partition lại bị overload? → Tại vì có một lượng request tăng đột biến đến từ service C cũng gọi qua service B, trong lượng request này có kèm một số lệnh update đến từ partition tương ứng dẫn đến overload partition này.
Tại sao lại có một lượng request tăng đột biến đến từ service C? → Tại vì redis cluster của service C bị down dẫn đến một lượng lớn request vốn nên được cache bởi service C bị đẩy sang service B.
Trong thực tế, việc đặt câu hỏi có thể nhiều hơn hoặc ít hơn. Nhưng nhìn chung khi phân tích, đặt câu hỏi đúng thì sẽ dẫn đến các bài học kinh nghiệm phù hợp để từ đó ngăn chặn các vấn đề phát sinh trong tương lai.
Kết thúc buổi sáng thứ ba, buổi chiều thường sẽ bắt đầu bằng buổi họp Operational Excellent của platform đang phụ trách. Trong đó, các thành viên sẽ review các thông số vận hành như SLI, SLO, các vấn đề mới phát sinh cần đào sâu, … Nếu chỉ số nào không đạt SLO thì sẽ cần điều tra nguyên nhân.
Tiếp đến sẽ là họp dành cho leader của platform đang phụ trách trong đó sẽ điểm qua các chủ đề tổng quan của platform như các use-case mới cần xử lý, thông tin từ các platform liên quan, chốt OKR, thảo luận milestone tiếp theo của các dự án đang triển khai, …
Phần còn lại của buổi chiều là xen kẽ 1:1 với leader hoặc coordinator cùng team, team khác để cập nhật tình hình lẫn nhau cũng như thảo luận về các dự án đang phụ trách của nhau. Đối với bản thân thì các buổi 1:1 là một hoạt động không thể thiếu đặc biệt là đối với các team liên quan để có thể tập trung thảo luận các chủ đề tổng quan về problem space của từng team, hoặc các vấn đề mang tính chất dài hạn hơn (3-6 tháng) thay vì các hoạt động hàng ngày vốn đã có quy trình tương ứng để xử lý.
(còn tiếp)
Quotes
“Measure. Don’t tune for speed until you’ve measured.”