Pull request hay gọi tắt viết tắt là PR là gì ?

Thuật ngữ này đã quá thân thuộc với các người thực hiện dev như chúng ta khi mà chúng ta dùng nó hầu như hằng ngày hằng giờ còn có thể là vài phút một lần cũng thực sự có thể nghe những câu đại loại như “Anh êiiiii, review giúp em cái pull request XXX điiiiiii”. Mặc dù thế dù là sử dụng quá hàng ngày như vậy tuy nhiên bạn có thật sự hiểu hết về nó, mục tiêu xây dựng PR, xây dựng PR ra làm sao cho thật xịn hay review PR ra làm sao là nhanh , đúng cách nhất. Hôm nay, qua bài viết bên dưới mình xin được chia sẻ một vài sự hiểu của bản thân mình về PR mà mình từng có thông qua những kinh nghiệm thực tế tại bản kế hoạch mình từng thực hiện. Người khác sau khi đọc xong bài viết này hãy cùng share những kinh nghiệm với PR với mình và nhé. khởi đầu thôi nào!

Mục đích tạo pull request

Pull request hay PR là khái niệm không liên quan đến logic source code và thường hay được để ý sau cùng khi dev đã hoàn tất việc code và sẵn sàng chuyển tiếp sang bước để mọi người review, mặc dù vậy “Last but not least” – đây hầu như là bước sau cuối có ảnh hưởng không kém để đưa source code của mỗi dev chúng ta đến gần với người tiêu dùng vì với các kế hoạch có quý khách hàng trực tiếp review source code thì dù logic , code của bạn có xịn đến mấy nhưng bạn không gửi PR đúng chuẩn đã được define theo rule thì khách hàng cũng sẽ chuẩn bị và sẵn sàng reject ngay không cho merge vào source code chung đâu đó nhé

Vì sao mình lại dùng câu “đưa source code của mỗi dev chúng ta đến gần với team với khách hàng” ?

Vì thực tế khi mà bạn làm việc tại team có không ít người, mỗi một chức năng bạn làm xong code và cần được team review, bạn không thể gọi mọi người đến máy tính của bạn , ngồi đó review từng dòng code cho người dùng đâu nhỉ. Bạn cũng không được gửi từng tệp source code cho người review để họ Tải về về máy , review được – quá tốn thời gian và thật sự không chuyên nghiệp. , tất nhiên khi quý khách hàng (đang ở một nơi nào đó rất rất xa bạn) muốn tham gia review code của bạn thì chuyện này càng gian khó hơn. Đấy là thời điểm cần tận dụng đến Pull request.

Pull request được tạo ra để đưa các tệp source code của bạn lên 1 host chung nơi mọi người có quyền truy cập sẽ truy cập vào và cùng review, để lại bình luận trên các file source code đó. Lúc này thời gian review , địa điểm review source code không còn là vấn đề – đó cũng chính là mục đích tạo ra pull request!

1. Khả năng communication cần có cho dev

Lập trình viên không giản đơn chỉ là thầm lặng viết code, mà cần có phải có năng lực giao tiếp . Năng lực giao tiếp được hiểu như một kỹ năng khá trừu tượng nhưng nếu như xét tại hoàn cảnh , mục đích nhất định , chúng ta đều thực sự có thể học một cách cụ thể . Trong bài viết bên dưới, trường hợp cụ thể là review code . Ở hầu hết những môi trường, công ty phát triển , đều sử dụng Pull request của GitHub , tiến hành review code của member . Đối với một người lập trình viên và thì có thể nói khả năng giao tiếp chiếm tỉ trọng khá cao.

Dựa vào đặc trưng mỗi công ty và của từng team , ở mỗi ngôn ngữ mà có nhiều văn hoá communication review code khác nhau. Do đó , toàn bộ không có rule nào là đúng cả nhưng với những người lập trình viên trẻ thông qua đó có thể tham khảo cách làm khi khởi đầu tham gia cùng đội tăng trưởng

2. Nâng cao level thông qua những lần review

Điều đầu tiên mà mọi người nghĩ đến đấy là mục tiêu review code là gì ?

Đó là phát hiện ra bug và tốc độ hơn fix bug sớm . Để làm được như thế thì chúng ta phải hiểu được đoạn code viết gì , rà soát ra được các chỗ không ổn ,có khả năng gây ra bug . Dẫu thế, mục tiêu của review code không chỉ như vây. Mà nó còn cùng bàn thảo tri thức lập trình, chỗ này nên xử lý theo kiểu A , chứ không phải kiểu B …. đó là cách nâng cao skill lập trình của từng người trong team , nâng cao giá trị hàng hóa . Do vậy, không đơn giản là chỉ ra các chỗ thiếu sót, bug mà thông qua giao tiếp hợp lý, cần phát huy tinh thần teamwork .

Vậy khi pull request /review chúng ta chú ý những điều gì

3. Khi PR

Khi pull request mà chỉ bình luận là [Đã làm ABC] thì với người review là quá ít nội dung để hiểu , reivew code . Khi nào review, vì sao cần đoạn code này … khá nhiều thông tin bị thiếu. Vì thế để giúp cho người review nhanh chóng hiểu mục tiêu, độ quan trọng của task thì chúng ta cùng thực hiện bình luận code theo template 5W1H bên dưới

• When

lúc nào cần reivew
Ngày dự định phát hình

• Where

Phạm vi chỉnh sửa, update
các bước tái hiện bug

• Who

Phần chỉnh sửa này liên quan đến các ai

• What

Đứng trên quan niệm người dùng thì có cái gì thay đổi
Đứng trên quan điểm của người phát triển thì có cái gì thay đổi

• Why

Nguyên nhân chọn cách này để hóa giải

• How

Bổ sung phương pháp thực hiện

với cách comment theo trật tự như trên sẽ khá hiệu quả trong việc đẩy nhanh tốc độ review. ưu điểm của phương pháp này là trước khi đọc code người review đã có một image toàn cục về nội dung xử lý của PR. trong hoàn cảnh có nhiều cách xử lý sẽ không cần lặp lại những câu hỏi kiểu dạng tại sao lại sự chọn lựa cách này …

Bày tỏ nghĩ ngợi với những đoạn code thấy bất ổn

Với những đoạn code, những phần setting cảm giác thấy bất ổn hãy đòi hỏi sự support từ các người có kinh nghiệm 。Nếu cứ để nguyên phát triển theo phương pháp không được chi tiết , rõ ràng thì khả năng phải phát triển và thực hiện lại là khá cao 。Trong thực tế, với bất kì ai cũng có nhiều case không được giải quyết được vì vậy không có gì đáng xấu hổ mà không hỏi cả . Khi đó,trong ý kiến hãy truyền tải rõ lý do , phần giải quyết mà bản thân thấy có lỗi lo .

• Trình bày phần thấy bất ổn

Function này vì viết không thể đẹp nên muốn có lời khuyên
Cần ý tưởng cho những phần xử lý phức tạp

• Nguyên nhân vì sao lại thấy xử lý có vấn đề

Có một vài phương pháp tuy nhiên không được đưa rõ ra phương pháp nào là tốt nhất trong đó
Đưa ra điểm mạnh, nhược điểm cho mỗi phương pháp

Bằng cách biểu diễn ước muốn được khắc phục vấn đề theo teamwork dường như trên thì sẽ tạo đươc thái độ đơn giản dễ dàng cộng tác, đơn giản đưa ra quan niệm từ các member khác

Pull Request thay đổi thì nhỏ nhưng tần suất là khá lớn

Trong lúc team phát triển thì phạm vi của Pull Request tuy là nhỏ nhưng số lần thì càng tăng thêm . Trong trường hợp 1 Pull Request lớn hàng mấy chục file thì time review sẽ rất lớn 。Trong trường hợp review trên 100 dòng code thì khả năng tập trung đã giảm và nên cũng vô cùng hay dẫn đến tình trạng sót bug 。Do đó , nên Pull các PR nhỏ, giảm tải lượng review 、review chi tiết từng tí một , đến đâu chắc đến đấy là một giải pháp hay 。Nếu phân chia một PR khoảng 10 dòng code thì tốc độ review cũng nhanh hơn, cũng sẽ nhanh được meger hơn 。

Một điều nữa là , setting khung thời gian ngắn để đưa ra PR。Trong nhiều hoàn cảnh chúng ta phải đưa rõ ra quyết đinh ngày release và nếu như đưa ra quyết định muộn thì cả team sẽ thường phải đổ xô vào cover。Trong tình trạng này, nếu người chịu trách nhiệm làm task đấy 3 ngày mới PR 1 lần thì khi họ vắng mặt thì sẽ không. Nhìn thấy Content tăng trưởng trong 3 ngày đó để member khác cover phần chậm trễ đó là rất khó khăn.

Tóm lại ,nếu mang PR theo mỗi task theo số giờ không quá dài thì tiến độ đấy member khác đều Quan sát phát hiện được nên việc cover không quá khó khăn 。Ngay cả trong hiện trạng tất cả code đang là WIP (Work in Progress) thì cũng nên PR 。Làm như thế này theo kiểu trực quan hoá tiến độ , Content nội dung tăng trưởng , thì các member khác cũng đơn giản support tại trường hợp khẩn cấp .

4. Khi review

Tiếp tục, chúng ta cùng tìm và phân tích các điểm cần chú ý khi review code .Những đoạn code nguy hiểm , rất dễ gây bug và thông qua review sẽ được cải thiện .Tuy nhiên, còn nếu không chú ý khi bình luận review code rất dễ gây cảm thấy cho người được review là đang bị soi mói, bới lông tìm vết

Review code không mang nghĩa tiêu cực là soi mói

Điều kiện tiền đề thứ nhất phải hiểu rằng mục tiêu review là sự hợp tác của rất nhiều người để đưa rõ ra chất lương code tốt nhất có thể 。Chứ không phải là soi mói, mệnh lệnh bắt buộc phải làm 。Cần chỉ ra những đoạn code chưa lý tưởng để cải thiện nhưng không phải là thể hiện ý kiến chủ quan mà hãy truyền đạt theo hướng khách quan .

Bên dưới là một VD .

Bad

Đoạn xử lý này khó hiểu, có nhiều đoạn code phức tạp như nhau . Hãy sửa lại

Trong ví dụ này , người đọc sẽ không hiểu cụ thể là cần thay đổi cho tốt hơn cái gì 。Những cụm từ ‘khó hiểu’, ‘phức tạp’ , ‘sửa’ là những từ thể hiện có tính sức ép trên mức cần thiết 。Đối với các người phát triển đang còn non trẻ thì sẽ có cảm giác bị khó chịu chẳng hề nhẹ .

Good

Về phần xử lý , phần xử lý lồng nhau khá sâu dẫn đến sẽ mất nhiều time giải quyết . Hãy thử check lại lại để sau này phần xử lý này maintain được đơn giản hơn. Tôi nghĩ là thực sự có thể cải thiện các phần code như nhau .

Với đoạn bình luận trên đã nêu cụ thể ra điểm cần phải cải thiện .Cùng với cách sử dụng các từ positive , cách ý kiến này giúp người đọc hiểu là không phải mệnh lệnh là giải pháp đề xuất để sửa chữa .

Bằng cách bình luận này thì sẽ khá mất giờ giấc . Bản thân chúng ta vì không có dài hạn nên hay giữ thói quen comment theo cách không tốt như bên trên . Tuy nhiên nếu cứ duy trì theo ý kiến này và thì nó sẽ thực hiện cho member cảm thấy code của bản thân mình đang bị soi mói, lặp đi lặp lại nhận feedback tiêu cực thì motivation của không chỉ người review mà cả người đc review cũng bị đi xuống . Review code là communication hằng ngày và nên nếu cứ tận dụng mãi những từ ngữ negative thì ngay chính bản thân mình cũng negavite theo. Thế nên và dù ko có khung thời gian chúng ta cũng tự tạo thói quen communication theo hướng positive .