Những nỗ lực nghiên cứu nhằm thay đổi cách con người thiết kế phần mềm dường như đều bắt đầu với chung một vấn đề: Code quá khó để nghĩ.
Trước khi nói đến những nghiên cứu thay đổi cách thiết kế phần mềm trên, chúng ta thật sự nên hiểu rõ vấn đề chung này. Điều gì đã làm code trở nên xa lạ với suy nghĩ con người và không giống bất cứ thứ gì trước đó?
Khi phần mềm là…cái chốt của thế giới
Các tiến bộ công nghệ thường mang lại những thay đổi dễ nhận thấy đối với diện mạo thế giới xung quanh chúng ta. những con đường được trải nhựa, hay nhiều toà nhà chọc trời đang mọc lên. Ngày nay, thật khó để nhận ra sự thay đổi, bởi chúng diễn ra trên những dòng lệnh lập trình. Chẳng hạn, khi đạp chân ga của xe hơi, người lái không còn điều khiển trực tiếp bất cứ thứ gì, không có liên kết cơ học từ bàn đạp đến ga. Thay vào đó, người lái đang phát lệnh cho một phần mềm quyết định lượng không khí được đưa vào động cơ. Chiếc xe bây giờ như một chiếc máy tính mà người ta có thể ngồi vào trong. Vô lăng và bàn đạp chính là bàn phím.
Giống như mọi thứ khác, chiếc xe được vi tính hóa để kích hoạt các tính năng mới. Khi một phần mềm quản lý ga và phanh, nó có thể cho xe chạy chậm lại khi đến quá gần xe khác hoặc điều khiển chính xác việc phun nhiên liệu để tiết kiệm xăng. Khi nó điều khiển bánh lái, phần mềm có thể giúp người lái đi đúng làn và đưa xe tự động vào vị trí đỗ. Hiển nhiên, chiếc xe sẽ không có những tính năng trên nếu không có code.
Phần mềm đã cho phép chúng ta tạo ra những cỗ máy phức tạp nhất, mà hầu như chúng ta chẳng hề để ý đến. Bởi vì tất cả sự phức tạp đó được gói gọn trong những con chip bé tẹo chứa hàng triệu dòng mã. Tuy nhiên, chúng ta không thấy sự phức tạp đó, không có nghĩa là nó biến mất.
Lập trình viên, nhà khoa học máy tính nổi tiếng người Hà Lan, Edsger Dijkstra đã viết vào năm 1988, “cần phải suy nghĩ về phân cấp nhận thức (conceptual hierarchies) sâu sắc hơn nhiều, so với những gì một khối óc mỗi cá nhân cần phải đối mặt trước đây.” (nguyên văn: “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.”). Dijkstra nói điều này như một lời cảnh báo. Khi các lập trình viên hăm hở đưa phần mềm vào hầu hết các hệ thống quan trọng. Chúng - phần mềm - càng lúc càng trở thành như những cái chốt của thế giới. Dijkstra nghĩ chúng ta có lẽ đang tự tin thái quá vào bản thân mình.
Điều làm cho việc lập trình trở nên rất khó là nó đòi hỏi người lập trình phải suy nghĩ như một chiếc máy tính. Sự kì lạ của nó thể hiện rõ hơn cả trong những ngày đầu của máy tính, khi mà những đoạn mã đúng nghĩa chỉ xoay quanh những con số 1 và 0. Bất cứ ai nhìn qua vai lập trình viên khi họ đang nghiên cứu từng dòng mã theo kiểu “100001010011” và “000010011110”, sẽ thấy lập trình viên đang đi xa khỏi vấn đề thật sự mà họ phải giải quyết như thế nào. Nhìn những đoạn mã này hoàn toàn không thể nói nếu họ đang tính toán quỹ đạo tên lửa, hay đang lập trình trò chơi đánh caro. Việc giới thiệu các ngôn ngữ lập trình như Fortan và C, sử dụng tiếng Anh, và các công cụ, được biết như “môi trường phát triển tích hợp”, hay lập trình, phần mềm giúp sửa các lỗi đơn giản hầu như không giúp thay đổi gì, mà chỉ che đậy phần nào thực tế, rằng các lập trình viên không thật sự xử lý trực tiếp vấn đề, mà họ dành cả ngày trời chỉ để viết hướng dẫn cho cổ máy.
“Vấn đề là những kỹ sư phần mềm không hiểu vấn đề mà họ đang cố gắng giải quyết, và cũng chẳng thèm quan tâm,” Leveson, chuyên gia an toàn phần mềm của MIT chia sẻ. Lý do là họ đã quá bận rộn trong việc làm cho các đoạn mã chạy được. “Những kỹ sư phần mềm thích cung cấp tất cả các loại công cụ xử lý các lỗi lập trình,” cô chia sẻ, đề cập đến lập trình. “Vấn đề nghiêm trọng xảy ra với phần mềm liên quan đến yêu cầu sử dụng, chứ không phải từ lỗi lập trình.” Chẳng hạn, khi lập trình viên viết mã điều khiển một bộ ga xe hơi, điều quan trọng nhất là các quy tắc về thời điểm và cách thức và mức độ mở của nó. Nhưng những hệ thống này đã dần trở nên phức tạp đến mức khó có ai có thể hiểu, ghi nhớ chúng trong đầu. “Ngày nay có đến hơn 100 triệu dòng mã trong xe hơi,” Leveson nói. “Bạn không thể lường trước tất cả những sai sót có thể xẩy ra.”
Khi nâng cấp phần mềm trở thành thảm Họa
Vào tháng 9 năm 2007, Jean Bookout đang lái xe trên đường cao tốc cùng với người bạn thân nhất của mình trong một chiếc Toyota Camry. Chiếc xe bị kẹt chân ga. Khi cô rời chân khỏi bàn đạp, chiếc xe không hề chạy chậm lại. Cô cố gắng phanh xe lại nhưng cũng không ăn thua gì. Cô rẽ vào một đoạn đường thoát với tốc độ 80 km/h và kéo phanh khẩn cấp. Chiếc xe để lại một vết trượt dài gần 50 mét trước khi đâm vào bờ kè bên đường. Người bạn thiệt mạng. Bookout tỉnh dậy trong bệnh viện hơn một tháng sau đó.
Vụ việc là một trong nhiều cuộc điều tra kéo dài gần một thập kỷ về các tuyên bố về thứ gọi là khả năng tăng tốc ngoài ý muốn trong xe hơi của Toyota. Về phía mình, Toyota đổ lỗi cho các sự cố trên thảm sàn bị thiết kế kém, bàn đạp bị dính và lỗi tài xế lái xe, nhưng một vài người ngoài cuộc nghi ngờ rằng đây có thể là sự cố do lỗi phần mềm. Cơ quan Quản lý An toàn Giao thông Đường cao tốc Quốc gia Mỹ đã mời các chuyên gia phần mềm từ NASA để thực hiện đánh giá chuyên sâu về mã lập trình xe của Toyota. Sau gần 10 tháng, nhóm NASA không tìm thấy bằng chứng cho thấy phần mềm là nguyên nhân gây ra tai nạn nhưng cũng thể bác bỏ được khả năng này.
Chính trong vụ kiện của vụ tai nạn Bookout, cuối cùng cũng có người tìm thấy một mối liên hệ thuyết phục. Michael Barr, một nhân chứng, chuyên gia cho nguyên đơn, đã có một nhóm các chuyên gia phần mềm dành 18 tháng với mã Toyota, thu thập những thứ NASA đã để lại. Barr mô tả thứ họ tìm thấy như một đĩa spaghetti, ngôn ngữ lập trình cho phần mềm đã trở nên hỗn độn. Những đoạn code trở thành như một đĩa spaghetti sau nhiều năm chồng chất lên nhau. Khi càng nhiều tính năng mới được thêm vào, chồng lên các đoạn code cũ. Dần dần, các đoạn code trở nên khó để theo dõi và kiểm tra lỗi một cách toàn diện.
Sử dụng mô hình tương tự như chiếc Camry liên quan đến vụ tai nạn, nhóm Barr đã chứng minh rằng thực sự có hơn 10 triệu cách để phần mềm trên xe gây ra sự tăng tốc ngoài ý muốn. Họ đã cho thấy rằng chỉ một thay đổi rất nhỏ là đủ khiến cho số một trong bộ nhớ của máy trở thành con số không hoặc ngược lại - khiến cho chiếc xe bị mất kiểm soát. Đoạn mã back-up mà Toyota đã đưa vào hoàn toàn không đủ sức để chặn nó. “Họ để phần mềm theo dõi một phần mềm,” Barr tiết lộ. “Nếu một phần mềm bị trục trặc thì nó chẳng thể cứu bạn khi nguy cấp xảy đến. Vì nó đâu có hoạt động.”
Lời khẳng định trước toà của Michael Barr đã giúp gia đình Bookout và bạn cô nhận 3 triệu USD tiền bồi thường. Theo tờ New York Times, đây là trường hợp đầu tiên trong số nhiều trường hợp tương tự kiện Toyota đưa ra các vấn đề thử nghiệm với hệ thống điều khiển bướm ga điện tử, và lần đầu tiên Toyota bị buộc chịu trách nhiệm về vụ tai nạn liên quan đến việc tăng tốc ngoài ý muốn. Hai bên đã quyết định bồi thường trước khi quyết định trừng phạt được ban xuống. Tổng cộng, Toyota đã thu hồi hơn 9 triệu xe ô tô và trả gần 3 tỷ USD cho các gia đình và tiền phạt liên quan đến việc tăng tốc ngoài ý muốn.