Mã nguồn cho bạn biết chương trình đang làm gì, còn lịch sử thay đổi cho bạn biết vì sao nó làm như vậy. Khi gặp một dòng mã lạ, trước khi xoá hay viết lại, hãy xem ai đã sửa nó, sửa lúc nào, kèm lời nhắn gì và sửa cùng với những gì. Rất nhiều dòng tưởng thừa thật ra là vết sẹo của một lỗi đã từng xảy ra.
Chào bạn, đây là Nhà Lập Trình. Hầu hết các đội phần mềm ngày nay dùng một hệ thống quản lý phiên bản, lưu lại mọi lần thay đổi mã. Nhiều người chỉ dùng nó để lưu và gộp mã, mà quên rằng nó còn là một cuốn nhật ký. Tập này mình kể cách đọc cuốn nhật ký đó.
Hàng rào giữa cánh đồng
Có một ẩn dụ quen thuộc trong nghề. Bạn đi qua một cánh đồng và thấy một hàng rào chắn ngang, không hiểu để làm gì. Người vội sẽ phá đi cho tiện đường. Người cẩn thận sẽ hỏi trước: ai dựng nó, dựng để làm gì. Nếu biết lý do mà thấy không cần nữa thì hãy phá.
Mã cũ đầy những hàng rào như vậy. Một dòng kiểm tra nếu số điện thoại bắt đầu bằng một ký tự lạ thì bỏ đi. Một lệnh chờ nửa giây trước khi gọi dịch vụ bên ngoài. Một cột được ghi hai lần. Nhìn vào, bạn thấy thừa, thấy xấu, muốn xoá.
Nhưng rất nhiều khi, dòng đó được thêm vào sau một đêm có sự cố. Số điện thoại từ một đối tác gửi sang có ký tự ẩn làm hỏng việc gửi tin nhắn. Dịch vụ bên ngoài từ chối nếu gọi quá nhanh. Xoá đi là mời lỗi cũ quay lại.
Lịch sử thay đổi là cách để hỏi ai dựng hàng rào này, khi mà người dựng không còn ở đó để trả lời.
Tìm xem ai sửa dòng này và lúc nào
Hầu hết hệ thống quản lý phiên bản có một chức năng cho bạn xem từng dòng trong tệp được sửa lần cuối bởi ai, vào lúc nào, trong lần thay đổi nào. Trình soạn thảo mã thường hiện thông tin này ngay bên cạnh dòng mã.
Khi gặp một dòng lạ, hãy xem nó thuộc lần thay đổi nào, rồi mở lần thay đổi đó ra. Bạn sẽ thấy lời nhắn đi kèm, và quan trọng hơn, thấy những tệp khác được sửa cùng lúc. Một dòng lạ trong tệp xử lý đơn hàng được sửa cùng lúc với tệp gửi tin nhắn và một tệp thử nghiệm mới, ba thứ đó kể chung một câu chuyện.
Đôi khi dòng bạn thấy đã bị sửa nhiều lần, lần cuối chỉ là đổi khoảng trắng hay đổi tên biến. Hãy đi ngược tiếp tới lần thay đổi thật sự đưa ý tưởng đó vào.
Nếu đội có dùng hệ thống quản lý công việc và lời nhắn có ghi mã số công việc, hãy mở công việc đó ra. Thường ở đó có mô tả lỗi, cuộc trao đổi, thậm chí ảnh chụp màn hình của người dùng gặp lỗi.
Khi lời nhắn chỉ ghi là sửa lỗi
Tất nhiên, không phải lời nhắn nào cũng tử tế. Rất nhiều lần thay đổi chỉ ghi sửa lỗi, cập nhật, hoặc một chữ chấm. Đọc những lời nhắn đó thì không học được gì.
Khi đó, hãy nhìn vào nội dung thay đổi. Trước và sau khác nhau chỗ nào? Thêm điều kiện gì? Nếu lần thay đổi có kèm một bài thử nghiệm mới, bài thử nghiệm đó thường mô tả chính xác tình huống lỗi. Đọc nó là hiểu vì sao có dòng mã kia.
Nhìn cả những lần thay đổi xung quanh về thời gian. Nếu trong cùng một tối có năm lần thay đổi liên tiếp vào cùng một khu vực, tất cả ghi sửa lỗi, rất có thể tối đó có sự cố và đội đang chữa cháy. Những dòng sinh ra trong đêm chữa cháy thường thiếu gọn gàng, nhưng lại chứa kiến thức đắt giá.
Và nếu người viết vẫn còn trong công ty, dù đã chuyển sang đội khác, bạn biết chính xác cần hỏi ai, hỏi về lần thay đổi nào. Câu hỏi cụ thể như vậy ai cũng sẵn lòng trả lời.
Đọc lịch sử để hiểu sự tiến hoá của dự án
Ngoài việc tra từng dòng, lịch sử còn cho bạn thấy bức tranh lớn. Lướt qua các lần thay đổi theo thời gian, bạn thấy dự án lớn lên thế nào: giai đoạn nào thêm nhiều tính năng, giai đoạn nào sửa lỗi dồn dập, giai đoạn nào có người mới vào và thay đổi phong cách viết.
Xem những tệp nào bị sửa nhiều nhất. Tệp nào tuần nào cũng có người sửa thì đó là trái tim của dự án, hoặc là chỗ rối nhất, hoặc cả hai. Đó là nơi bạn nên hiểu kỹ nhất, và cũng là nơi cần cẩn thận nhất khi đụng vào.
Xem ai đã viết phần nào. Nhiều dự án có dấu vết của vài người với vài phong cách khác nhau. Biết phần này do một người thích viết gọn, phần kia do một người thích tách nhỏ, giúp bạn đọc mỗi phần với đúng kỳ vọng.
Có lần mình ngồi đọc lịch sử một dự án cả buổi chiều, không sửa dòng nào. Nhưng sáng hôm sau, khi bắt tay vào làm, mình tránh được ít nhất hai cái bẫy mà người trước đã sa vào.
Viết lời nhắn cho người đọc sau
Đọc lịch sử nhiều rồi, bạn sẽ tự nhiên muốn viết lời nhắn tử tế hơn cho chính những thay đổi của mình. Người đọc lời nhắn đó có thể là đồng nghiệp năm sau, hoặc chính bạn khi đã quên sạch.
Một lời nhắn tốt trả lời câu hỏi vì sao, không chỉ cái gì. Cái gì thì nhìn nội dung thay đổi là thấy. Vì sao thì chỉ bạn biết, ở thời điểm này. Sửa lỗi gửi tin nhắn thất bại khi số điện thoại từ đối tác có ký tự ẩn ở đầu. Chỉ một câu như vậy, cứu người sau cả giờ tìm hiểu.
Mỗi lần thay đổi nên làm một việc. Gộp sửa lỗi, đổi tên biến và thêm tính năng vào cùng một lần khiến người đọc sau không tách được đâu là thay đổi quan trọng.
Lịch sử thay đổi là kho trí nhớ tập thể của một đội. Mỗi lời nhắn tử tế là một viên gạch góp vào trí nhớ đó.
Câu hỏi thường gặp
Hệ thống quản lý phiên bản là gì?
Là phần mềm lưu lại mọi lần thay đổi của mã nguồn, cho phép xem lại, so sánh, quay về phiên bản cũ và cho nhiều người cùng làm trên một dự án. Hầu hết các đội phần mềm hiện nay đều dùng.
Làm sao biết ai đã viết một dòng mã?
Hệ thống quản lý phiên bản có chức năng hiện người sửa lần cuối và lần thay đổi tương ứng cho từng dòng. Nhiều trình soạn thảo hiện sẵn thông tin này khi bạn đặt con trỏ vào dòng mã.
Có nên xoá dòng mã trông vô nghĩa không?
Nên tìm hiểu lý do trước bằng cách xem lịch sử thay đổi, bài thử nghiệm liên quan hoặc hỏi người viết. Nếu xác nhận nó không còn cần, hãy xoá và ghi rõ lý do trong lời nhắn thay đổi.
Lời nhắn thay đổi nên viết bằng tiếng Việt hay tiếng Anh?
Theo quy ước chung của đội. Điều quan trọng hơn ngôn ngữ là nội dung: nói rõ vì sao thay đổi và thống nhất một cách viết trong cả dự án.
Đọc lịch sử thay đổi có tốn thời gian không?
Có tốn một chút, nhưng thường ít hơn nhiều so với thời gian sửa lại lỗi cũ do xoá nhầm một dòng quan trọng. Chỉ cần đọc lịch sử ở những chỗ bạn sắp sửa, không cần đọc toàn bộ.
