Ở thời điểm này, Apple đang rơi vào tính huống tương đối khó xử. Nếu không ra mắt bản cập nhật hệ điều hành mới hoặc ra mắt mà không có tính năng đột phá, họ sẽ bị phàn nàn. Nếu ra mắt iOS và macOS có tính năng đột phá nhưng tồn tại đầy lỗi lúc ra mắt, họ vẫn sẽ bị phàn nàn. Bằng chứng nhãn tiền là Apple đã cho ra mắt iOS 13.1 beta trước cả khi iOS 13 chính thức ra mắt. Ở trường hợp của Mac, mọi thứ cũng có vẻ tệ không kém. Ngay cả khi macOS Catalina không có nhiều tính năng mới, vẫn có không ít người gặp phải những vấn đề khác nhau sau khi cập nhật.
Apple chắc chắn sẽ sửa được những lỗi đó trong các bản cập nhật kế tiếp. Nhưng câu hỏi vô tình trở thành, vì sao Apple không tạo ra bản cập nhật hệ điều hành hoàn thiện ngay từ đầu, đỡ mất công tung ra bản vá? Để trả lời cho câu hỏi này, mới đây David Shayer, cựu kỹ sư từng có 18 năm gắn bó với mảng phần mềm ở Apple đã có một bài viết đưa ra những nguyên do khiến iOS và macOS mỗi lần ra mắt đều có lỗi. Sáu nguyên nhân chính được đề cập như thế này:
Thời gian biểu ra mắt cập nhật phần mềm mới của Apple, cộng với những tính năng cần phải ra mắt có phần tham vọng đã khiến cả các kỹ sư phần mềm lẫn bên quản lý chất lượng phải làm việc cả vào ban đêm lẫn cuối tuần khi có deadline. Hệ quả là vài tính năng bị dời sang bản cập nhật sau, ví dụ như iCloud Drive Folder Sharing chẳng hạn. Trong những dự án được quản lý thời gian hiệu quả, những tính năng phát triển chậm chạp bị dời lại, để tập trung cho những tính năng sắp hoàn thiện. Nhưng đôi khi các vị giám đốc thích chơi đuổi bắt, làm khổ nhân sự vì không ai muốn thừa nhận trong cuộc họp rằng phần việc của họ đang bị bỏ lại phía sau. Vài sản phẩm không có ngày ra mắt chính thức như AirPods có thể dời được, nhưng iPhone thì không. Nó phải được ra mắt vào cuối tháng 9 hàng năm, bất kể đã hoàn thiện hay chưa. Tương tự như thế với hệ điều hành, phần mềm và những tính năng mới.
Hệ thống thông báo lỗi của phần mềm do Apple phát triển thường tự động gửi thông tin lỗi về cho công ty. Crash report thường có rất nhiều dữ liệu. Hữu ích nhất là stack trace, theo dõi dòng code nào khiến phần mềm bị crash, và thậm chí còn cho kỹ sư biết vì sao nó lại crash nữa. Nhờ đó việc sửa lỗi diễn ra nhanh hơn. Đây là nguyên do Apple thường sửa lỗi crash phần mềm rất nhanh, và phần mềm của họ “có vẻ” hoạt động mượt mà hơn. Vấn đề lại nằm ở chỗ, crash report không thông báo những lỗi không gây crash phần mềm. Lấy ví dụ dữ liệu danh bạ không sync từ Mac sang iPhone, hay quá trình setup điện thoại tạo ra lỗi bắt anh em phải đăng nhập iCloud liên tục. Đó vẫn là lỗi, nhưng chúng không bị phát hiện bởi crash report.
Việc giải quyết trước những lỗi nghiêm trọng của Apple vẫn là việc đúng. Nhưng khi là một kỹ sư phần mềm, mỗi lần thay đổi code, nguy cơ lỗi mới xuất hiện luôn tồn tại. Chúng sẽ khiến tất cả kỹ sư và quản lý chất lượng phải ngồi test lại. Trước ngày phần mềm ra mắt rất gần kề, sửa một lỗi mà họ đã biết nguyên nhân, hậu quả và cách xử lý luôn hợp lý hơn là tìm sang một lỗi khác ít được biết đến. Sửa lỗi mới hoàn toàn có thể có nguy cơ tạo ra một lỗi nữa mà các kỹ sư chưa biết. Những lỗi bị nhiều người phàn nàn sẽ được tập trung sửa trước. Trong khi đó những lỗi được coi là ít quan trọng sẽ bị đẩy xuống dưới danh sách.
Số lượng lỗi mới tồn tại khiến Apple gần như lờ đi những lỗi cũ, miễn là chúng chỉ xuất hiện trên số ít máy, hoặc không quá trầm trọng. Quay lại phần thứ 3 ở trên, khi một kỹ sư lỡ tay đổi code và tạo ra một lỗi mới, anh ta sẽ phải sửa nó. Cái này gọi là “hồi quy” (regression). Nhưng kỹ sư bên quản lý chất lượng sẽ đánh giá xem một lỗi có phải do kỹ sư phần mềm tạo ra hay không. Đôi khi, sẽ có những lỗi không một ai được giao để sửa chữa cả. Tâm lý cha chung không ai khóc đúng trong trường hợp này. Nếu một nhóm kỹ sư không tạo ra lỗi khiến họ phải “regression”, thì họ sẽ không phải đụng vào và sửa nó.
Hiện giờ iPhone, iPad, Apple Watch, MacBook đều được test tự động để kiểm tra thời lượng pin, lần mò trong những dòng code để phát hiện ra những vấn đề có thể gây ảnh hưởng tới pin, ví dụ như pin sụt nhanh một cách bất thường vì lỗi phần mềm chẳng hạn. Nhưng ngoài ra, hiếm khi thấy các nhóm kiểm tra chất lượng phần mềm của Apple sử dụng công cụ tự động, dù chúng rất đáng tin cậy. Trong số hiếm hoi những nhóm phát triển dùng công cụ tự động, có lẽ phải kể đến nhóm phát triển Safari. Họ cùng công cụ này để tìm kiếm những dòng code khiến hiệu năng trình duyệt bị ảnh hưởng, sau đó loại bỏ hoặc sửa chúng.
Rất nhiều năm trước, Apple chỉ bán Mac. Giờ họ có thêm iPhone, AirPods, HomePod, iPad, Apple Watch. Một HĐH mà Apple viết ra có hàng chục triệu dòng code, để tất cả các sản phẩm Apple sản xuất đều có thể tự tương tác với nhau, và tương tác thông qua tài khoản iCloud của chủ sở hữu. Tất cả các ứng dụng đều đa luồng và tương tác với nhau thông qua internet. Hệ sinh thái của Apple càng lúc càng phức tạp, khiến cho việc phát triển và tìm lỗi phần mềm khó hơn xưa rất nhiều. Họ không chỉ phải tìm lỗi ảnh hưởng tới phần mềm, mà còn phải tìm cả những lỗi ảnh hưởng tới tính tương thích giữa các sản phẩm Apple nữa.
Devmaster Academy via TinhTe