“Bạn có thể mang developer ra khỏi CVS, chứ chả cách nào lấy CVS RA khỏi tay họ được đâu.” – trong trường hợp này là tôi
Sai là sai chỗ nào?
Có lẽ bạn cho rằng tôi kiểu ngạo nhưng tôi cho rằng hầu như mọi người đều đang dùng Github sai cách! Sao mà ta có thể biết được mình đang dùng Github sai? Làm sao để dùng Git hiệu quả?
Xem thêm Git là gì?
Trắc nghiệm thử nhé! Bạn thấy mình trong những trường hợp nào dưới đây?
- Project nào bạn cũng có một cái repository online
- Repository / repositories của bạn có branch mà ai cũng dùng và còn developer nhiều thay đổi khác lên nó.
- Bạn có một process mà ai cũng phải follow để review code; chỉ có một review system và chỉ có một nơi cố định để chạy tất cả các test.
Nếu tất cả những điều trên bạn đều “dính” thì tôi xin chia buồn với bạn đã thuộc nhóm dưới đây:
CVS vs DCVS
Bạn có còn nhớ CVS không? Nó viết tắt cho Concurrent Versions System*. Ở đây, Concurrent chính là từ khoá trọng tâm. Nếu như tất cả những gì bạn thao tác với source control là phải centralize nó, thì concurrency có lẽ là cột mốc xa nhất bạn có thể đạt được.
*Chú thích: CVS cho phép nhiều lập trình viên và các thành viên khác trong một nhóm phát triển phần mềm làm việc trơn tru với nhau. Trong đó, mỗi developer thay đổi nội dung các tập tin bên trong phiên bản copy của dự án của chính họ và sau đó gởi những thay đổi của họ về máy server. Để tránh việc người này ghi đè lên những thay đổi của người khác, server chỉ chấp nhận những thay đổi đối với phiên bản gần đây nhất của một file.
Mặt khác, Git lại áp dụng Distributed version control, hay còn được gọi là Distributed revision control system (DRCS) (Hệ thống các phiên bản phân tán), hoặc Distributed version control system (DVCS).
*Chú thích: Khác với hệ thống tập trung như CVS, với DCVS nếu như máy chủ ngừng hoạt động, thì bạn hoàn toàn có thể lấy kho chứa từ bất kỳ máy khách nào để sao chép ngược trở lại máy chủ để khôi phục lại toàn bộ hệ thống. Mỗi checkout thực sự là một bản sao đầy đủ của tất cả dữ liệu của kho chứa từ máy chủ.
Có lẽ tại một thời điểm nào đó khi Git trở nên nổi tiếng, nhiều người quên mất lí do vì sao nó được ra đời. Và giờ đây họ dùng Git như một CVS gây lãng phí bộ nhớ vì cứ phải copy toàn bộ lịch sử code ở khắp mọi nơi.
Cái mà tôi muốn nhấn mạnh chính là điểm khác biệt giữa Git so với các công cụ quản lý source trước đây nằm ở sự đối lập giữa:
Concurrent Model – tạo ra các thay đổi trong codebase chung tại cùng một thời điểm VS Distributed Model – phát triển code một cách độc lập rồi share các thay đổi sau.
Đây là điểm khác biệt mấu chốt. Trong Distributed Model, từng developer phải càng tự chủ động và tự lập càng tốt, cái gì cần thống nhất thì thông qua việc giao tiếp với nhau chứ không phải là kiểm soát.
Có thể các bạn cho rằng chúng không khác nhau là mấy, nhưng nó ảnh hưởng tới cả văn hóa của dân lập trình. Nó sẽ thay đổi từ việc chọn cái nào để review trên source control system trước, đến cách bạn tạo ra build system, cũng như cách để giao tiếp, review, setup testing, etc.
DVCS chính là phiên bản nâng cấp của CVS. Bạn không nhất thiết phải áp dụng toàn bộ mọi thứ của DVSC model, nhưng dùng nó rồi thì sẽ giúp ích cho bạn rất nhiều.
Những dấu hiệu cho biết nó đang có vấn đề
Bạn đã bao giờ đi review code, rồi phải đưa ra feedback còn dài hơn – lâu hơn việc bạn tự đi sửa nó chưa?
Đã bao giờ bạn đã sửa xong phần mà cả team đang cần, nhưng vẫn chưa dùng được vì bạn chưa “nhập nó lên master branch“, bởi những phiền phức với các tool hiện tại, cũng như các quy trình lằng nhằng mà bạn phải thực hiện?
Bạn có gặp phải bug trên “master branch”, nhưng lại chỉ ảnh hưởng đến một số developer, hay thỉnh thoảng lại fail mà không bị phát hiện ra khi test?
Có khi nào bạn rơi vào tình huống bế tắc không thể làm gì khi master branch hỏng?
Rốt cuộc nên dùng Git hiệu quả kiểu gì?
Model phát triển phần mềm của bạn nên áp dụng theo model phát triển Linux Kernel. Nó chính là cách mà Git được tạo ra và trở nên thịnh hành như bây giờ. Nó cho phép việc phát triển code độc lập, tiện lợi giữa nhiều người. Hoạt động tốt với hơn 15 triệu dòng code, là ngôi nhà chung cho hàng ngàn developer khác nhau, từ không chuyên cho tới chuyên nghiệp. Thế nên nó cũng sẽ rất có lợi cho project của bạn.
Thay đổi code
Đừng nên chỉ có một “master branch” mà tất cả mọi người đều sử dụng chung, bởi nó kết nối tất cả với nhau và chỉ cần “Một con ngựa đâu là cả tàu bỏ cỏ”. Khi code trong master branch thay đổi hay crash thì tất cả mọi thứ xung quanh đều sẽ bị ảnh hưởng.
Việc thay đổi code nên được diễn ra một cách thoải mái và dễ dàng giữa mọi người. các team và developer có thể tự do trao đổi các patches hoặc là cả branch nếu hợp lý tùy theo tình huống. Thường thì những thay đổi này sẽ bắt đầu từ dưới đi lên và lan ra. Nhờ mà ta sẽ có thời gian test và theo dõi trước khi những thay đổi đó được đưa vào “master branch”.
Ví dụ:
- Đi từ dưới lên (Bottom-up): Junior developers nên push những thay đổi trong code qua cho senior developer review chúng. Nếu được chấp nhận thì sẽ đưa lên cho leader xem, rồi manager xem. Cứ thế cho đến hết một qui trình.
- Lan ra (Across): UI team sẽ trao đổi patches, review và test liên tục giữa các thành viên trong nhóm, và thường sẽ phải xin manager phụ trách để merge chúng lại. Các backend developer thì có thể giữ những thay đổi của họ dù UI có thay đổi hay không.
- Kết hợp (Mixed): Những contributor đóng góp feature cross-project sẽ gửi những thay đổi đến chủ của các project đó.
Nghe thì có vẻ rất lộn xộn nhưng trên thực tế nó lại khá đồng bộ, hay nói cách khác: một hệ thống đồng nhất.
Reviews
Tôi không đồng tình lắm với cách sắp xếp và tổ chức code review.
Tôi tin rằng cái giá phải trả để phát triển một software thành công luôn bị đánh giá thấp.
Rõ ràng bạn không hề muốn một app đầy bug, và lập trình viên thì chỉ là con người : mà con người thì luôn luôn mắc lỗi. Vì thế mà việc review là việc rất cần thiết. Thế nhưng nếu developer cho rằng việc này gây phiền hà và không cần thiết thì sẽ ảnh hưởng không nhỏ đến hiệu quả công việc của mình.
Do đó, bản thân code-review cũng chính là một rào cản mà các developer phải vượt qua khi làm project, chúng thường bao gồm:
- Những tool thô, chỉ phù hợp một số trường hợp nhất định
- Web UIs vừa xấu vừa dỏm
- Quan liêu COCC max level
- Trễ nãi do review nhiều vòng và phải fix liên tục từ nhiều phía
Trước tiên, developers đã có git và môi trường để họ phát triển. Đó là tất cả những gì họ cần để thay đổi code, vốn bao gồm phải đọc lại những code cũ. Vậy thì sao họ lại phải cần những tool để đọc code, khi đang review chúng? Việc bắt các developer phải học thêm một phần mềm khác với chức năng tương tự chỉ khiến tổ tốn thời gian thêm.
Và tại sao phải ép buộc developer phải review code như nhau? Làm gì có chuyện ai cũng thích cùng một màu và cùng một web interface mà bạn chọn được? Bạn có ép họ phải xài chung một text editor luôn không?… Trong một team với distributed model thì các developer nên được phép dùng bất cứ tool gì phù hợp với họ để làm việc, bao gồm cả code review.
Quá trình review code diễn ra như sau: Bằng cách tìm output của diff command, nằm trong web-browser, và xác định được những lỗi rõ ràng thì được xem là vừa không hiệu quả vừa thiếu sót. Để review một thay đổi được hiệu quả, hãy download nó xuống, rồi dùng git checkout, mở IDE/text editor lên và xem những đoạn code mới này, chạy test hay thậm chí viết ra một số đoạn mới của chúng để thử, thao tác thỏa ý muốn của bạn. Chỉ khi đó thì ta mới thật sự gọi đó là “review code”.
Review nên tập trung về việc giao tiếp và hợp tác, chứ không phỉa về xăm xoi và chỉ trích. Một khi vấn đề đã được xác định rõ thì người review sẽ có thể sửa chúng ngay và gửi fix đó lại cho team. Nó sẽ nhanh hơn nhiều so với việc viết comment lí giải dài dòng và yêu cầu phải review lại thêm nhiều lần nữa. Hơn thế, kiểu “Tôi nghĩ rằng thay đổi mới này sẽ giúp bạn cải thiện code của mình” luôn dễ nghe hơn là kiểu “Code chú tởm lợm quá, đi mà fix nó đi”.
Testing
Bạn nên xem các developer như những người đóng góp fix sửa cho code chứ đừng cho rằng họ làm được tất cả mọi thứ ngay lập tức. Ngoài ra, hệ thống central testing cần được xem là bước cuối cùng của testing sau một loạt các bài test từ developer cũng như những người đóng góp khác.
Nhờ đó mà nó giúp ta test được kĩ hơn và bảo đảm cho chất lượng của những thay đổi đó trước khi nó đến tay mọi người.
Để cho có hiệu quả, bạn cần phải bảo đảm việc testing giữa các member phải thật kĩ lưỡng, rõ ràng và có ích. Developers nên làm quen với việc chạy test hàng ngày. Những bài test luôn được thiết kế cho con người chứ máy móc không thể dùng test một cách hiệu quả được. Vì thế bạn nên cảm thấy thoải mái và có khả năng xác định những lỗi xuất hiện từ đâu và từ khi nào.
Kết luận
Những điều tôi nói ở trên không thể áp dụng được tất cả mọi tình huống. Và có lẽ nó chỉ đơn giản là vì bạn không khoái cái ý tưởng mà tôi đã đưa ra.
Dù vậy, CVS-es vẫn sẽ là lựa chọn tốt hơn CVS nhiều lần:
- Dùng nó dễ hơn.
- Developer sẽ không mất công cứ download toàn bộ lịch sử lại nhiều lần.
- Bạn có những tính năng như: locking files hay kiểm tra sub-tree của project mình.
Tôi vẫn tin rằng cho dù bạn không thích hay ghét nó thì vẫn sẽ tốt hơn nếu bạn chịu tìm hiểu về chúng!
Hy vọng qua bài viết này các bạn sẽ biết cách dùng Git hiệu quả nhất. Cảm ơn các bạn đã theo dõi bài viết!
Đừng bỏ lỡ những bài viết hay liên quan:
- 10 Vấn đề về Git thường gặp và Giải pháp
- Một vài lệnh Git hữu dụng
- Combo các lệnh Git đủ dùng trong một dự án cho người mới bắt đầu
Xem thêm việc làm Software Developers hấp dẫn tại TopDev
TopDev via Codecamp
