Nhận một dự án cũ không có tài liệu, đừng mở tệp đầu tiên rồi đọc lần lượt tới tệp cuối. Hãy làm cho nó chạy được trên máy mình trước, tìm cửa vào của chương trình, lần theo đúng một chức năng mà người dùng hay dùng nhất, và vừa đọc vừa ghi lại những gì mình hiểu. Những ghi chép đó sẽ thành tài liệu đầu tiên của dự án.
Chào bạn, đây là Nhà Lập Trình. Gần như ai đi làm cũng có ngày được giao một dự án cũ, người viết đã nghỉ, tài liệu thì không có hoặc có mà sai. Cảm giác đầu tiên thường là ngợp. Tập này mình kể cách mình và nhiều đồng nghiệp đi qua cảm giác đó.
Đừng đọc như đọc tiểu thuyết
Người mới hay đọc mã theo thứ tự thư mục, từ trên xuống dưới. Sau nửa ngày, họ đã đọc hai mươi tệp và không nhớ tệp nào làm gì. Mã không phải tiểu thuyết, nó không được viết để đọc từ đầu tới cuối. Nó là một mạng lưới những phần gọi lẫn nhau.
Hãy đọc mã như đọc bản đồ một thành phố lạ. Bạn không đi hết mọi con hẻm. Bạn tìm con đường chính, vài địa điểm quan trọng, và đi theo một lộ trình cụ thể. Những con hẻm để sau, khi nào cần tới thì mới vào.
Chấp nhận rằng bạn sẽ không hiểu hết. Ngay cả người viết ra dự án cũng không nhớ hết từng dòng. Mục tiêu tuần đầu không phải là hiểu toàn bộ, mà là hiểu đủ để sửa được một thứ nhỏ mà không làm hỏng thứ khác.
Cảm giác ngợp sẽ giảm rất nhanh khi bạn có được vài điểm mốc. Mỗi điểm mốc là một chỗ bạn biết chắc nó làm gì, và từ đó bạn lan ra dần.
Việc đầu tiên: cho nó chạy được
Trước khi đọc sâu, hãy làm cho dự án chạy trên máy của bạn. Việc này nghe như việc phụ, nhưng nó dạy bạn rất nhiều. Bạn sẽ biết dự án cần những gì: phiên bản ngôn ngữ nào, cơ sở dữ liệu nào, những dịch vụ bên ngoài nào, những tệp cấu hình nào.
Mỗi lần cài không được là một manh mối. Thiếu một thư viện, bạn biết dự án dùng thư viện đó. Báo lỗi không kết nối được một dịch vụ lạ, bạn biết dự án phụ thuộc dịch vụ đó. Ghi hết lại.
Khi chạy được rồi, bạn có một công cụ quý: được thử. Bạn có thể bấm vào một nút, xem chuyện gì xảy ra, thêm một dòng in ra để xem dữ liệu đi qua đâu. Đọc mã mà không chạy được giống như học lái xe bằng sách.
Nếu dự án có dữ liệu thật, đừng bao giờ chạy thử trên dữ liệu thật. Hãy xin một bản sao, hoặc tự tạo dữ liệu giả. Nhiều sự cố nghiêm trọng bắt đầu từ một người mới vô tình chạy thử lệnh xoá trên cơ sở dữ liệu đang dùng.
Tìm cửa vào và con đường chính
Mọi chương trình đều có cửa vào, chỗ mà nó bắt đầu chạy. Với một trang web, đó là chỗ nhận yêu cầu và quyết định chuyển yêu cầu đi đâu, người trong nghề hay gọi là bảng định tuyến. Với ứng dụng điện thoại, đó là màn hình đầu tiên. Với một công cụ chạy định kỳ, đó là tệp được gọi theo lịch.
Bảng định tuyến của một trang web là tấm bản đồ quý nhất. Nó cho bạn biết trang web có những đường dẫn nào, mỗi đường dẫn được xử lý bởi phần mã nào. Chỉ cần đọc nó, bạn đã hình dung được dự án rộng cỡ nào và có những khu vực chính nào.
Tiếp theo, xem cấu trúc cơ sở dữ liệu. Tên các bảng và các cột kể cho bạn biết dự án quản lý những gì: khách hàng, đơn hàng, sản phẩm, nhân viên. Mối liên hệ giữa các bảng kể cho bạn biết chúng gắn với nhau thế nào.
Có bảng định tuyến và cấu trúc dữ liệu trong tay, bạn đã có khung xương của dự án. Phần còn lại là thịt đắp lên khung đó.
Đi theo một chức năng, từ đầu tới cuối
Giờ hãy chọn một chức năng mà người dùng hay dùng nhất. Với trang bán hàng, có lẽ là xem sản phẩm và đặt hàng. Đi theo nó từ lúc người dùng bấm cho tới lúc dữ liệu được lưu và trang kết quả hiện ra.
Lần theo từng bước, ghi lại: yêu cầu vào đâu, được kiểm tra gì, gọi tới phần nào, đọc và ghi bảng nào, trả ra gì. Không cần hiểu mọi dòng trên đường đi, chỉ cần hiểu dòng chảy.
Sau một chức năng, bạn sẽ thấy dự án có những thói quen riêng: cách đặt tên, cách tổ chức thư mục, cách kiểm tra quyền, cách báo lỗi. Những thói quen đó thường lặp lại ở mọi chức năng khác. Chức năng thứ hai sẽ đọc nhanh hơn chức năng đầu rất nhiều.
Một anh lập trình ở Đà Nẵng kể lần nhận một hệ thống quản lý kho cũ, anh dành cả tuần đầu chỉ đi theo đúng chức năng nhập hàng. Tuần thứ hai anh đọc được gần hết phần còn lại, vì mọi thứ đều viết theo cùng một kiểu.
Hỏi đúng người và viết lại những gì hiểu được
Người viết mã có thể đã nghỉ, nhưng người dùng thì vẫn còn. Hãy nói chuyện với họ. Chị kế toán dùng phần mềm hằng ngày biết rất rõ chức năng nào quan trọng, chỗ nào hay lỗi, có những mẹo gì để lách. Những điều đó không nằm trong mã.
Nếu còn liên lạc được người viết cũ, hãy chuẩn bị câu hỏi thật cụ thể trước khi hỏi. Đừng hỏi anh giải thích hệ thống cho em. Hãy hỏi vì sao bảng đơn hàng có hai cột ngày tạo khác nhau. Câu hỏi cụ thể được trả lời nhanh và chính xác hơn.
Và viết ra. Mỗi điều bạn hiểu được, viết thành vài dòng trong một tệp ghi chú đặt ngay trong dự án: cách cài đặt, cửa vào ở đâu, các bảng chính, những chỗ lạ và lý do nếu biết. Ban đầu nó chỉ là ghi chú cho chính bạn.
Rồi một ngày có người mới vào, và bạn đưa họ tệp ghi chú đó. Họ sẽ đi qua con đường bạn đã đi nhanh gấp mấy lần. Đó là cách một dự án không tài liệu dần có tài liệu.
Câu hỏi thường gặp
Mất bao lâu để hiểu một dự án phần mềm cũ?
Tuỳ quy mô và độ rối của dự án. Hiểu đủ để sửa một lỗi nhỏ có thể mất vài ngày, hiểu tổng thể có thể mất vài tuần đến vài tháng. Đo bằng việc bạn sửa được gì an toàn, không đo bằng số tệp đã đọc.
Có nên viết lại dự án cũ ngay khi thấy mã khó đọc?
Không nên quyết định khi chưa hiểu. Mã khó đọc thường chứa những xử lý cho các trường hợp thật mà bạn chưa biết. Hãy hiểu nó trước, rồi mới bàn chuyện sửa dần hay làm mới.
Công cụ nào giúp đọc mã nguồn nhanh hơn?
Trình soạn thảo có chức năng nhảy tới nơi định nghĩa và tìm mọi chỗ sử dụng là công cụ quan trọng nhất. Công cụ tìm kiếm toàn dự án và trình gỡ lỗi chạy từng bước cũng giúp rất nhiều.
Nên hỏi người viết cũ những gì?
Những câu cụ thể về lý do: vì sao dùng cách này, vì sao có cột này, chỗ nào hay hỏng. Những thứ đọc mã là biết thì tự đọc, để dành thời gian của họ cho những điều chỉ họ mới biết.
Tài liệu đầu tiên cho dự án cũ nên có gì?
Cách cài đặt và chạy dự án, cửa vào của chương trình, các bảng dữ liệu chính, các dịch vụ bên ngoài, và danh sách những chỗ lạ kèm lý do nếu biết. Ngắn và đúng tốt hơn dài mà sai.
