Nội dung bài viết như sau:
- Giới thiệu
- Lập kế hoạch cho trường hợp xấu nhất
- Kiểm tra sớm
- Đừng tin tưởng vào dữ liệu từ bên ngoài
- Chỉ tin cậy những thiết bị là: video, chuột, bàn phím.
- Ghi cũng có thể lỗi, thật vậy.
- Hãy code một cách an toàn
“Phần mềm của tôi không bao
giờ có lỗi”. Các bạn có tin không? Còn tôi thì đang nghe các bạn hét rằng
tôi là kẻ dối trá. “Phần mềm không có lỗi
là một thứ gì đó gần như là không thể”.
Trái ngược với niềm tin thông thường, đang tạo sự tin tưởng, phần
mềm vững chắc không phải là một thứ gì đó gần như là không thể. Chú ý rằng tôi
không đề cập đến phần mềm không có lỗi, dự định để điều khiển những nhà máy nặng
lượng hạt nhân. Tôi đang đề cập đến phần mềm quản lý chung, cái mà có thể bỏ mặc
nó chạy trên máy chủ, thậm chí một máy PC, trong một khoảng thời gian dài và công
việc có thế đoán trước mà không có bất kỳ trục trặc nào đáng kể. Có thể đoán
trước, tôi muốn nói rằng phần mềm có một tỉ lệ lỗi thấp, bạn có thể dễ dàng hiểu
các lỗi là điều kiện để sửa nó nhanh chóng và không bao giờ gây thiệt hại dữ liệu
trong sự phản hồi của một lỗi bên ngoài.
Nói cách khác, phần mềm đó ổn định.
Đang có một lỗi trong phần mềm của bạn là một điều có thể tha thứ
được, thậm chí là bình thường. Cái không thể tha thứ được là đang có một lỗi tuần
hoàn mà bạn không thể sửa nó vì bạn không có đủ thông tin.
Để hiểu tốt nhất những gì tôi đang nói, tôi đã thấy vô số phần mềm
doanh nghiệp có lỗi out of disk space trong DBMS, thông báo một thứ giống thế
này:
“Không thể cập nhật thông
tin khách hàng. Liên hệ quản trị và thử lại sau”.
Trong khi thông báo trên có thể là một thông báo đẩy đủ một lỗi không
rõ nguồn gốc cho người dùng, đây luôn luôn là tất cả các thông tin để gỡ lỗi. Không
có gì được ghi trong lịch sử của phần mềm, để hiểu những gì đang xẩy ra sẻ mất
thời gian và các lập trình viên thường sẽ đoán nhiều nguyên nhân có thể xẩy ra
cho đến khi họ tìm thấy nguyên nhân thật sự.
Chú ý rằng trong bài viết này, tôi sẽ tập trung vào cách làm thế
nào để tạo một ngoại lệ tốt nhất khi dùng .NET: tôi sẽ không bình luận thế nào
là một thông báo lỗi đúng đắn, vì tôi tin rằng nó thuộc về lĩnh vực UI, nó tùy
thuộc nặng vào giao diện đã phát triển và mục tiêu đối tượng; một trình soạn thảo
văn bản mục tiêu nhắm đến thanh thiếu niên nên thông báo lỗi theo một cách hoàn
toàn khác biệt hơn một socket server, cái mà sẽ chỉ sử dụng chủ yếu bởi các lập
trình viên.
Một vài khái niệm thiết kế cơ bản sẽ tạo cho chương trình của bạn vững
chắc hơn và sẽ cải thiện trải nghiệm người dùng khi bất ngờ xuất hiện một lỗi. “cải
thiện trải nghiệm người dùng khi bất ngờ xuất hiện một lỗi” ý tôi muốn nói là
gì? Nó không phải là người dùng sẽ cảm thấy rạo rực khi hộp thoại bạn sẽ cho
anh ta xem. Nó là nhiều hơn về không làm hỏng dữ liệu, máy tính không bị treo
và hành xử một cách an toàn. Nếu chương trình của bạn có thể vượt qua lỗi out
of disk space mà không có bất kỳ tổn hại nào, thì bạn đã cải thiện trải nghiệm
người dùng.
Kiểm tra kỹ càng và xác nhận kiểu dữ liệu là những công cụ mạnh mẽ
để ngăn chặn những ngoại lệ bất ngờ và để tạo tài liệu và kiểm tra code. Trước khi
khởi chạy chương trình bạn phát hiện một vấn đề, thì sửa dễ dàng hơn. Cố gắng để
hiểu điều mà aCustomerID làm trên cột ProductID trong bảng InvoiceItems sau một
vài tháng thì không vui vẻ gì mà cũng không dễ dàng. Nếu bạn đã sử dụng các lớp
để tạo các kiểu dữ liệu tự tạo, thay vì sử dụng những kiểu dữ liệu nguyên thủy (e.g.,
int, string, etc), rất có thể trình biên dịch sẽ không bao giờ cho phép bạn làm
một việc như thế.
Dữ liệu bên ngoài thì không đáng tin cậy, nó phải kiểm tra rất nhiều.
Nó không phải là vấn đề nếu dữ liệu đến từ registry, database, từ một ổ đĩa, từ
một socket, từ một tập tin bạn vừa viết hoặc từ bàn phím. Tất cả dữ liệu ngoài
phải được kiểm tra và chỉ khi đó bạn có thể tin tưởng vào nó. Tôi luôn luôn thấy
rằng các chương trình tin tưởng các tập tin cấu hình bởi vì các lập trình viên không
bao giờ nghĩ rằng một ai đó sẽ sửa tập tin và làm sai nó.
Bất cứ khi nào bạn cần đến dữ liệu ngoài, bạn có thể có những tình
huống sau:
- Không đủ quyền để truy cập.
- Thông tin không có ở đó.
- Thông tin không đầy đủ.
- Thông tin đầy đủ, nhưng vô giá trị.
Thật sự không phải không là vấn đề nếu nó là một registry key, một
tâp tin, một socket, một database, một web service hay một cổng nối tiếp. Tất cả
nguồn dữ liệu ngoài sẽ gặp lỗi, sớm hay muộn. Hãy lập kế hoạch cho một lỗi an
toàn và giảm thiểu thiệt hại.
Ghi cũng có thể lỗi, thật vây.
Không tin vào nguồn dữ liệu cũng không tin vào nơi trữ dữ liệu.
Khi bạn đang lưu dữ liệu, tương tự các tình huống sau có thể xảy ra:
- Không đủ quyền để ghi.
- Thiết bị không có ở đó.
- Không đủ bộ nhớ.
- Thiết bị gặp lỗi vật lý.
Đó là lý do chương trình ép tạo một tập tin tạm thời và đổi tên nó
sau khi chúng xong việc. Thay vì thay đổi một bản gốc, nếu ổ đĩa của bạn (thậm
chí cả phần mềm) gặp lỗi vì một lý do nào đó, bạn sẽ không bị mất dữ liệu gốc của
mình.
Còn nữa....
Còn nữa....
Không có nhận xét nào:
Đăng nhận xét