Định luật Murphy hay được gọi là định luật bánh bơ được phát biểu: "Bất cứ thứ gì đó có thể sai, nó sẽ xảy ra" (tiếng Anh: Anything that can go wrong, will go wrong.)

Người ta đã kiểm tra định luật này bằng cách thả một miếng bánh mì có bơ từ trên xuống và chẳng hiểu sao số lần mặt dính bơ chạm đất lúc nào cũng nhiều hơn. Đó là lý do định luật này còn có tên là định luật bánh bơ. Cái tên rất ngọt ngào cho một trong những định luật cay đắng nhất của cuộc sống.

Sự thật rằng phần mặt bánh dính bơ luôn nặng hơn bên còn lại. Điều này đã phản ánh về sự tác động của trọng lực làm mặt bánh nặng hơn sẽ luôn rơi xuống đất mà không phải lúc nào nó cũng sẽ rơi ở mặt ngược lại với lý do tương tự. Dù sao thì hiển nhiên mặt bánh dính bơ vẫn luôn nặng hơn mặt bánh bên kia.

Và trong cuộc sống thì những điều tệ hại, tiêu cực luôn làm cho con người mình nặng hơn. Nên nếu có hai giải pháp công nghệ tốt thì phải chọn giải pháp tốt nhất trong những giải pháp tốt nhất (Theo định luật Murphy 5: "Nếu bất cứ thứ gì đó không thể sai thì nó vẫn sẽ sai").

Trên nền tảng định luật Murphy, năm 2003, giải thưởng Nobel Cơ khí một lần nữa vinh danh Edward A. Murphy cùng 2 nhà khoa học quá cố khác - John Paul Stapp và George Nichols - những đồng sự giúp ông chứng minh Luật Murphy. Mãi 54 năm sau khi công bố, Định luật Murphy mới được công nhận.

Những giải pháp chống lại định luật Murphy trong lĩnh vực Công nghệ phần mềm sẽ giúp hiểu rõ lý do tại sao cần có những biện pháp an toàn và căn cơ trong lĩnh vực phát triển phần mềm. Một lĩnh vực lưu giữa một phần tri thức, văn minh của nhân loại qua từng thời kỳ từ lúc chưa có loài người tới lúc thời hiện đại như hiện nay và trong tương lai.

1. Bối cảnh ra đời

Định luật này được đặt ra bởi Edward Murphy là một kỹ sư hàng không vũ trụ, cho vụ đáp lại một vụ thử tên lửa thất bại vào đầu những năm 50.

Vào năm 1949, tại căn cứ không quân Edward ở California (Mỹ), các sĩ quan đang thực hiện thử nghiệm dự án MX981 để xác định lần cuối xem tỉ số gia tốc trọng trường (kí hiệu G: Gravitational acceleration) mà một người có thể chịu đựng được khi máy bay rơi là bao nhiêu. Họ hy vọng rằng nghiên cứu của họ sẽ được áp dụng trong các thiết kế máy bay sau này.

Để mô phỏng sự tác động của va chạm máy bay, họ đã sử dụng tàu tên lửa mang tên Gee Whiz. Tàu bay với tốc độ hơn 200 dặm/giờ dưới chặng đường dài nửa dặm, rồi đột ngột dừng lại trong chưa đầy 1 giây. Vấn đề là ở chỗ, thay vì chỉ cần tìm tỉ số gia tốc mà một người có thể chịu đựng được thì họ lại cần một người thật để thử nghiệm điều đó. Đại tá John Paul Stapp – chuyên gia nghiên cứu vật lý cho lực lượng không quân – lúc ấy tình nguyện làm người thử nghiệm. Trong suốt các chuyến bay vắt kiệt thể chất diễn ra vài tháng trời ấy, Stapp bị chấn thương rất nặng. Ông bị gãy xương, chấn động và vỡ mạch máu trong mắt, tất cả chỉ vì hy sinh cho khoa học.

Đây là hình ảnh Đại tá John Paul Stapp thử nghiệm tàu tên lửa Gee Whiz tại căn cứ không quân Edward (Mỹ)

Murphy có nảy ra một ý tưởng: Đặt một bộ cảm biến ở đai cố định giáo sư Stapp vào tàu tên lửa. Những máy cảm biến này có tác dụng đo đạc chính xác số liệu của lực gia tốc trọng trường khi tàu tên lửa bị dừng đột ngột, như vậy dữ liệu phần nào sẽ rõ ràng hơn.

Có vài lời đồn xung quanh sự kiện xảy ra ngày hôm đó, về người nào đóng góp những gì vào công cuộc cho ra đời định luật Murphy. Và kết quả cuối cùng gần như là xấp xỉ.

Trong lần thử đầu tiên, sau khi Murphy lắp các thiết bị cảm biến này vào các đai cố định, họ không thu về bất cứ một kết quả nào. Mọi bộ cảm biến đều không được lắp đặt đúng cách. Mỗi bộ đều có 2 đường lắp đặt và cả hai đều bị lắp sai.

Khi Murphy tìm hiểu nguyên nhân, ông cứ lẩm bẩm khiển trách lỗi là do các nhà kỹ thuật. Ông nói: “Nếu có hai cách để làm thứ gì đó, mà một trong hai cách dẫn đến hậu quả tệ hại, thì chắc chắn hắn ta sẽ làm theo cách tệ hại đó”.

Đây là lý do dẫn tới việc là mình nên TẬP TRUNG hay là chết. Và trong lập trình có một best practices cho việc xây dựng hàm là mỗi hàm chỉ chịu một trách nhiệm duy nhất để khi có chỉnh sửa hệ thống thì chỉ có một cách chỉnh sửa mà thôi.

Không lâu về sau, Murphy quay trở lại trường sân bay Wright nơi ông ấy đóng quân. Nhưng Stapp, người đàn ông hài hước với trí thông minh sáng suốt của mình, đã nhận ra tính chất chung trong câu nói của Murphy. Trong một buổi họp báo, ông ấy đã nói mọi kết quả số liệu an toàn chính xác mà đội nghiên cứu thu được đều dựa vào sự nhận thức về định luật Murphy, có nghĩa là: “Nếu một việc đã có diễn biến xấu thì nó sẽ diễn biến đúng như thế”.

2. Diễn giải định luật Murphy

Định luật Murphy cho ta thấy cái nhìn đời không như là mơ và hư hư thực thực, rất thực mà hư và rất hư mà thực

Định luật Murphy thực chất được hỗ trợ bởi một định luật tự nhiên xác thực đó là sự mất trật tự của hệ thống

Định luật này được sử dụng thường xuyên trong nghiên cứu về nhiệt động lực học nhằm giải thích nguyên nhân năng lượng chuyển hóa từ dạng này sang dạng khác. Nó chứng minh rằng trong vũ trụ của chúng ta, các hệ thống thường đi đến cái kết của sự mất trật tự và hỗn độn.

Trong kỹ thuật phần mềm cũng có một định luật entropy được ứng dụng phổ biến dựa theo định luật entropy trong nhiệt động lực học. Nó nói về hệ thống phần mềm khi được cập nhật và sửa đổi thì sự rối loạn trong hệ thống sẽ tăng lên, Và điều đó được gọi là entropy phần mềm. Nên trong lĩnh vực phát triển phần mềm thì viết code đơn giản, dễ đọc đáp ứng được 99% về hiệu năng của hệ thống và khi nâng cấp hệ thống sẽ đỡ tốn thời gian và sẽ cải thiện đáng kể khả năng bảo trì phần mềm. Bắt đầu với một giải pháp đơn giản cũng sẽ giúp dễ dàng lặp lại, tối ưu và cải thiện khi phát sinh vấn đề hiệu suất.

Định luật Murphy cũng nhắc nhở cho các kỹ sư, người lập trình máy tính và các nhà khoa học về một sự thật hiển nhiên: Hệ thống hư hỏng. Trong một vài trường hợp, hệ thống hư hỏng báo hiệu rằng cuộc thử nghiệm đó sẽ còn lặp lại nhiều hoặc sẽ làm hao tốn rất nhiều kinh phí đầu tư.

3. Ứng dụng định luật Murphy trong lĩnh vực công nghệ phần mềm

Khi người dùng sử dụng phần mềm, họ sẽ tìm ra những cách sáng tạo để nhập một thứ gì đó vào input mà không nằm trong kế hoạch kiểm thử và làm phá vỡ hệ thống. Vì vậy, bạn cần làm cho phần mềm của mình đủ mạnh để phát hiện và cảnh báo các hành vi không mong muốn.

Khi phần mềm chạy trên máy, bất kỳ thứ gì cũng có thể bị hỏng. Từ các ổ đĩa hỗ trợ hệ điều hành, lỗi hệ điều hành, RAM, CPU, ổ cứng lưu trữ, mainboard đến nguồn cung cấp điện của server, data center và những rủi ro bất khả kháng. Vì vậy, cần đảm bảo rằng bạn có thiết kế tốt cho hệ thống phòng thủ và thiết kế tốt cho thất bại ở mọi cấp độ kiến trúc hệ thống.

Ví dụ:

• Việc đặt giá trị mặc định null cho chuỗi trong framework lại là một sự bất lợi cho hệ thống giao dịch khi một người nào đó có nick name là Null hoặc tên thật có chứa từ Null được truy cập vào hệ thống và gây ra nhầm lẫn trong báo cáo là có người truy cập nhưng ngôn ngữ lập trình lại nhận dạng là có một chuỗi không có gì (null)

• Trong dự án điện toán đám mây thì mọi thứ dường như đã sẵn sàng để triển khai môi trường sản xuất tự động hóa cho đến khi máy chủ Azure gặp sự cố cơ sở hạ tầng khiến máy chủ vốn được dùng để chạy các tập lệnh tự động hóa trên đám mây bị trở ngại.

4. Ứng phó với định luật Murphy trong lĩnh vực công nghệ phần mềm

Để có những biện pháp chống lại quy luật này thì có một số kỹ thuật phần mềm được áp dụng như defensive programming, version control, chuẩn bị kịch bản diệt vong cho những cuộc tấn công của máy chủ Zombie, TDD, MDD,... đều là những best practices chống lại đinh luật không phòng thì chắc chắn dính lỗi này.

Là lập trình viên, chúng ta học rất nhiều kiến thức. Chúng ta thu thập, sắp xếp, lưu trữ và khai thác kiến thức từ rất nhiều lĩnh vực để phân tích và thiết kế hệ thống. Nhưng kiến thức là luôn thay đổi từng ngày. Việc bạn vừa học một công nghệ mới ngày hôm nay nhưng có thể lại lỗi thời vào ngày mai. Hoặc những kỹ thuật hạt nhân có thể là cao siêu nhưng bối cảnh kinh tế, xã hội, con người thay đổi thì nó vẫn trở nên lỗi thời. Nên chỉ cần nắm vững những kiến thức căn bản.

Tri thức là luôn luôn thay đổi theo thời gian và quy định pháp luật về công nghệ thông tin của một quốc gia cũng như vậy. Tri thức thay đổi rất nhanh chóng. Sự hiểu biết của bạn về một yêu cầu có thể thay đổi sau cuộc họp với khách hàng. Chính phủ thay đổi một quy định và một số logic kinh doanh trở nên lỗi thời. Và có thể thuật toán được chọn để giải quyết vấn đề có thể không còn phù hợp trong tương lai. Những sự bất ổn này giúp chúng ta rút ra một số kinh nghiệm là chúng ta sẽ dành phần lớn thời gian trong bảo trì hệ thống, nâng cấp hệ thống, kiểm thử hệ thống, tổ chức lại hệ thống, luôn cải thiện code (để code của mình sao cho đơn giản nhất), và thể hiện lại tri thức bên trong hệ thống của mình.

Hầu hết mọi người cho rằng bảo trì bắt đầu khi một ứng dụng được phát hành, bảo trì đó có nghĩa là sửa lỗi và nâng cao tính năng. Chúng tôi nghĩ rằng những người này đã sai.

Các lập trình viên liên tục ở chế độ bảo trì. Với lý do, sự hiểu biết của chúng ta thay đổi từng ngày. Các yêu cầu mới xuất hiện khi chúng ta đang thiết kế hệ thống hoặc viết mã. Có lẽ môi trường liên tục thay đổi. Dù lý do là gì, bảo trì không phải là một hoạt động rời rạc, mà là một phần thường xuyên của toàn bộ quá trình phát triển.

Khi thực hiện bảo trì, chúng ta phải tìm và thay đổi các biểu diễn tri thức và code bên trong ứng dụng. Vấn đề là rất dễ trùng lặp kiến thức trong các thông số kỹ thuật, quy trình và chương trình mà chúng ta phát triển. Và nếu có một vấn đề nào đó không rõ ràng thì theo như định luật Murphy thì chắc chắn sẽ dẫn đến kết quá sai.

Rất nhiều lý do để viết code sao cho trong một thời gian bạn nhìn lại mở mã nguồn của hệ thống lên để bảo trì, nâng cấp sẽ nhìn thấy dễ hiểu, dễ kiểm thử, dễ chỉnh sửa để có thể bảo trì và nâng cấp hệ thống. Nếu không, code của hệ thống sẽ làm bạn bị rối lên và dẫn đến sai sót.

Cách duy nhất để phát triển phần mềm một cách đáng tin cậy và làm cho quá trình phát triển phần mềm của mình dễ hiểu và dễ bảo trì bằng cách tuân theo nguyên tắc DRY (Don't Repeat Yourself).

Có cùng một thứ được thể hiện ở một hoặc nhiều nơi. Nếu bạn thay đổi một cái, bạn phải nhớ thay đổi những cái khác. Nếu bạn quên thì toàn bộ chương trình sẽ sụp đổ.

Hầu hết những sự trùng lặp trong code là một trong những cái sau đây:

• Trùng lặp áp đặt
• Trùng lặp code do vô tình
• Sự trùng lặp do thiếu kiên nhẫn
• Sự trùng lặp giữa các developer

5. Tài liệu tham khảo

• How Murphy's Law Works: https://people.howstuffworks.com/murphys-law.htm
• Mười bốn định luật Murphy: https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy.htm
• The Pragmatic Programmer