Đoạn bad code lớn nhất bạn từng thấy là gì?

 (news.ycombinator.com)
21 điểm bởi xguru 2020-09-21 | 8 bình luận | Chia sẻ qua WhatsApp

"Là 25 triệu dòng mã của Oracle Database 12.2."

Một câu trả lời của cựu nhân viên Oracle để lại trong câu hỏi từng được đăng trên HN.

"Đó là nỗi kinh hoàng không thể tưởng tượng nổi. Không thể viết nổi dù chỉ một dòng mã nếu không vượt qua được 1.000 bài kiểm thử hiện có.

Có những macro bí ẩn mà nếu không tự tay ghi chép ra sổ rồi lần theo thì không thể hiểu nổi; chỉ để thực sự hiểu cách macro hoạt động cũng mất từ một đến hai ngày.

Đôi khi phải hiểu giá trị và tác động của 20 cờ khác nhau để dự đoán mã sẽ hoạt động ra sao trong các tình huống khác nhau.

Thỉnh thoảng con số đó còn vượt quá 100. Không hề cường điệu.

Lý do duy nhất khiến sản phẩm này vẫn sống sót và tiếp tục hoạt động, theo đúng nghĩa đen, là nhờ hàng triệu bài kiểm thử."

Cuộc sống của một lập trình viên phát triển Oracle DB.

  1. Bắt đầu xử lý một bug mới.

  2. Mất 2 tuần để hiểu 20 cờ khác nhau tương tác với nhau theo những cách bí ẩn và gây ra bug này.

  3. Thêm một cờ nữa để xử lý một kịch bản đặc biệt mới. Viết thêm vài dòng mã để kiểm tra cờ này, rồi thêm vài dòng nữa để giải quyết tình huống có vấn đề và ngăn bug.

  4. Submit phần thay đổi mã lên một test farm gồm 100~200 máy. Sau đó build Oracle DB mới và phân tán chạy hàng triệu bài kiểm thử.

  5. Về nhà. Hôm sau quay lại và bắt đầu việc khác. Kiểm thử cần 20~30 giờ mới hoàn tất.

  6. Về nhà. Hôm sau quay lại kiểm tra kết quả test. Ngày tốt thì khoảng 100 test thất bại. Ngày xấu thì khoảng 1.000 test thất bại. Chọn vài test trong số đó để tìm xem giả định của mình sai ở đâu. Có lẽ sẽ còn thêm khoảng 10 cờ nữa cần phải tính đến để hiểu bản chất của bug.

  7. Thêm vài cờ nữa để giải quyết issue này. Submit lại thay đổi lên test farm. Lại chờ thêm 20~30 giờ.

  8. Lặp đi lặp lại việc chỉnh sửa suốt 2 tuần để các tổ hợp cờ này hoạt động đúng.

  9. Cuối cùng, vào "một ngày đẹp trời nào đó", toàn bộ test đều không còn thất bại nữa.

  10. Thêm hơn một trăm bài kiểm thử cho phần thay đổi mình đã làm để nhà phát triển xui xẻo tiếp theo không phá vỡ bản sửa lỗi này.

  11. Submit lại để kiểm thử cuối cùng. Và submit để review. Review lại có thể mất từ 2 tuần đến 2 tháng, nên chuyển sang bug khác và bắt đầu làm việc.

  12. Sau 2 tuần đến 2 tháng, khi mọi thứ kết thúc, mã được merge vào nhánh chính.

Đó là cuộc sống của một lập trình viên Oracle khi sửa bug. Không hề cường điệu.

Vậy hãy thử tưởng tượng việc phát triển một tính năng mới sẽ là nỗi kinh hoàng đến mức nào.

Phát triển một tính năng nhỏ mất từ 6 tháng đến 1 năm, đôi khi tới 2 năm. (Chẳng hạn như thêm một phương thức xác thực mới như xác thực Active Directory.)

Việc sản phẩm này hoạt động được đúng là một phép màu.

Giờ tôi không còn làm ở Oracle nữa, và cũng sẽ không bao giờ làm ở Oracle nữa.

Bài viết liên quan

8 bình luận

 
neocoin 2020-09-28

Vòng lặp kiểm thử là

  1. Viết code

  2. Viết test

  3. Refactor code, quay lại 1

Nhưng vì 1 và 2 tốn quá nhiều thời gian, nên kết cục cộng dồn là bước 3 cứ liên tục bị bỏ sót.
 
kunggom 2020-09-21

Bài nói của Martin Fowler đáng để xem lại vào lúc này. Có vẻ như Oracle Database có "chất lượng nội tại" (Internal Quality) không được tốt cho lắm.

https://vi.news.hada.io/topic?id=2752
 
kbumsik 2020-09-21

Từ góc nhìn của Oracle thì có vẻ như đó là điều hiển nhiên, thậm chí còn khiến người ta cảm thấy phần mềm đó đúng là dành cho doanh nghiệp... đến mức thấy khá yên tâm.

Nhưng như bài viết đó, tôi lại không muốn làm việc ở chỗ đó.
 
exitmusic 2020-09-21

Tôi lại có cảm giác phải chăng chính văn hóa phát triển lấy test làm trung tâm đã khiến quy trình phát triển bị phá hỏng.

Kiểu phát triển theo hướng miễn là pass test thì làm thế nào cũng được... chắc trong môi trường như vậy thì đừng mơ tới chuyện refactoring.
 
sduck4 2020-09-22

Có lẽ thay vì vấn đề ở khâu kiểm thử, vấn đề lớn hơn là lỗi thiết kế khiến mỗi khi sửa/thêm tính năng phải cân nhắc tới 20~100 cờ khác nhau, đúng không?

Dù vậy, có vẻ đây cũng là điều khó tránh khỏi vì độ phức tạp của DBMS.
 
kunggom 2020-09-21

Xét cho cùng thì test cũng là code do lập trình viên viết. Nhân tiện nghĩ đến chuyện này, tôi xin giới thiệu một bài viết về test.

https://vi.news.hada.io/topic?id=2883
 
ffdd270 2020-09-21

Nếu dự án không đến mức như thế thì nhờ có test liên tục đảm bảo rằng dù có mổ xẻ và sửa lại interface, hành vi vẫn giữ nguyên như trước, nên ngược lại có lẽ sẽ có thêm dũng khí để refactor. Dạo gần đây tôi có sửa các tham số trong trình giả lập mình đang làm từ giá trị BYTE sang Enum Value. Build thì thành công nhưng test lại thất bại, nên tôi đã có lúc giật mình nghĩ rằng nếu không có test thì mình đã làm sao đây.

Với một codebase cỡ đó thì ngay cả khi có nghĩ đến chuyện refactor... cũng sẽ bỏ cuộc vì nó quá đồ sộ, rồi lại tiếp tục chồng thêm code lên. Tôi đoán khá thận trọng rằng có lẽ họ đã rơi vào một vòng lặp vô tận như vậy.
 
xguru 2020-09-21

Tôi cũng hiểu vì sao người đó đã rất vất vả,

nhưng trớ trêu thay, đây lại là một bài viết khiến tôi nghĩ rằng "kiểm thử hóa ra quan trọng đến mức này", nên tôi đã thử dịch nó.

Bài đăng câu hỏi gốc của câu trả lời này có tổng cộng 578 phản hồi.

Ask HN: What's the largest amount of bad code you have ever seen work?

https://news.ycombinator.com/item?id=18442637

Chỉ cần đọc các phản hồi cấp 1 thôi cũng đã rất thú vị. Cảm giác là con người sống ở đâu thì cũng giống nhau cả...