Trong lập trình: giải pháp tồi hơn đôi khi lại tốt hơn
Có 2 người nổi tiếng, một người đến từ trường đại học danh tiếng MIT và người kia đến từ một nơi danh tiếng không kém là Berkeley (nhưng đang làm việc trên hệ điều hành Unix), một lần nọ họ gặp nhau và thảo luận về các vấn đề của hệ điều hành. Người đến từ MIT thông thạo về ITS (hệ điều hành MIT AI Lab) và cũng đã đọc mã nguồn của hệ điều hành Unix. Anh ta cảm thấy thích thú về cách mà Unix giải quyết vấn đề PC loser-ing. Vấn đề PC loser-ing xuất hiện khi mà một chương trình sử dụng triệu gọi đến một thủ tục hệ thống để thực thi một hoạt động có thời gian kéo dài và có trạng thái quan trọng, như là bộ đệm nhập xuất chẳng hạn.
Nếu có một đứt quãng xuất hiện trong suốt quá trình hoạt động đó, thì trạng thái của chương trình sử dụng phải được lưu lại. Bởi vì lời triệu gọi thủ tục hệ thống thường là một lệnh đơn, nên máy PC không đủ khả năng để bắt lại trạng thái của tiến trình đó. Thủ tục hệ thống sẽ hoặc là hoàn nguyên hoặc là ép buộc hoạt động tiếp.
Giải pháp đúng đắn ở đây là hoàn nguyên và phục hồi lại lệnh mà đã triệu gọi thủ tục hệ thống để hồi phục lại chương trình sử dụng sau khi bị ngắt quãng. Nó được gọi là “PC loser-ing” bởi vì máy PC đó đang trở nên bị ép buộc vào trong “loser mode (mô hình mất mát),” nơi mà “loser (kẻ mất mát)” thường được đặt một cái tên trìu mến là “user (người dùng)” tại MIT.
Gã đến từ MIT không nhìn thấy bất kỳ đoạn code nào quản lý phần này và đã hỏi gã đến từ New Jersey rằng vấn đề đó được quản lý bằng cách nào. Gã New Jersey nói rằng những người quen thuộc với hệ điều hành Unix biết rất rõ vấn đề đó, nhưng giải pháp là họ cho thủ tục hệ thống luôn luôn kết thúc, nhưng đôi khi một mã lỗi sẽ được trả về để báo hiệu rằng thủ tục hệ thống đã thất bại trong việc hoàn thành các hoạt động của nó. Một chương trình sử dụng đúng đắn, sẽ phải kiểm tra mã lỗi trả về và xác định xem liệu có nên thử triệu gọi lại thủ tục hệ thống lần nữa hay không. Gã MIT không thích giải pháp này bởi vì cách làm đó không đúng đắn lắm.
Gã New Jersey nói rằng giải pháp Unix đã đúng bởi vì triết lý thiết kế của Unix là đơn giản hóa và nếu làm theo cách đúng đắn thì quá phức tạp. Bên cạnh đó, các lập trình viên có thể dễ dàng chèn thêm các đoạn kiểm tra và vòng lặp. Gã MIT chỉ ra rằng việc thực thi kiểu đó thì đơn giản nhưng interface của chức năng thì lại phức tạp ra. Gã New Jersey nói rằng có một sự đổi chác đúng đắn đã được lựa chọn trong cái tên Unix, việc thực thi đơn giản thì quan trọng hơn nhiều so với interface đơn giản.
Gã MIT sau đó đã lẩm bẩm rằng “đôi khi cần phải có những người mạnh mẽ mới có được món thịt gà ngon mềm”.
Và đây là câu chốt đáng tiền:
TUY NHIÊN, TÔI TIN RẰNG TỒI-HƠN-THÌ-TỐT-HƠN, THẬM CHÍ TRONG HÌNH THÁI TIÊU CỰC CỦA NÓ, NHỮNG ĐẶC TRƯNG KIỂU NÀY ĐÃ SỐNG SÓT TỐT HƠN LÀ NHỮNG-THỨ-ĐÚNG-ĐẮN, VÀ HƯỚNG TIẾP CẬN CỦA GÃ NEW JERSEY KHI SỬ DỤNG CHO PHẦN MỀM LÀ HƯỚNG TIẾP CẬN TỐT HƠN SO VỚI CÁCH CỦA GÃ MIT.
Nghe có vẻ giống như là một fan hâm mộ Linux vậy, nhưng tôi tin điều này với tất cả bản thân mình. Bạn muốn có những ví dụ không? Hãy nhìn xung quanh bạn mà xem.
- Kiến trúc x86 mà có thể bạn đang đọc trang web này dựa trên nó thường được thừa nhận rộng rãi như là một thứ hoàn toàn vớ vẩn. Và nó đúng là như vậy thật. Nhưng nó là một thứ vớ vẩn đã được mài giũa để có một cạnh sắc không thể tin được. x86-64? Con của chúng ta sẽ có thể vẫn sử dụng nó cũng nên. Trong khi đó, kiến trúc Itanic thì ngày càng chìm sâu hơn vào Biển Bắc sau mỗi tháng.
- Registry của Windows. Bạn có bao giờ để ý rằng mọi thứ trong .NET thường hoàn thành thông qua một số file text đơn giản có đuôi .config không? Điều đó có gợi cho bạn nhớ lại tất cả những file .INI cũ kỹ? Hoặc có lẽ một file cấu hình của Apache? Trong khi Registry về mặt lý thuyết là cao cấp hơn, nhưng nó lại là nguyên nhân của rất nhiều vấn đề hầu như liên quan đến sự phức tạp– chỉ cần mất một vài byte là nó sẽ bị hỏng; và bạn sẽ phải “vẫy tay vẫy tay chào nhau” tới tất cả dữ liệu registry của bạn. Và vâng, dĩ nhiên là bạn phải cài lại hệ điều hành. Nó giống như là kiểu giải pháp “hai bước tiến và một bước lùi” vậy.
- COM thì tự bản thân nó đã nói lên tất cả. Bạn không muốn chỉ việc xây dựng một Web Service hơn sao?
- Java. Bạn đã nghe điệp khúc này lặp đi lặp lại bao nhiêu lần rồi. Java thì quá hàn lâm, quá phức tạp không cần thiết. J2EE ư? Bất cứ thứ gì cùng với chữ “Enterprise” trong tiêu đề, thì nên thay thế bằng từ “Complicated (phức tạp)”. Như tôi đã chỉ ra trước đây, các tổ chức đang trích dẫn rằng cần giảm độ phức tạp và tăng năng suất khi chuyển đổi sang sử dụng .NET.
Bất cứ khi nào có thể, hãy luôn hướng về phía đơn giản. Tại sao lại sử dụng kế thừa khi mà một object đơn giản sẽ làm? Tại sao lại sử dụng kế thừa khi mà bạn có thể sử dụng một interface? Tại sao thậm chí lại đi viết code khi mà bạn có thể mua hoặc đánh cắp (hoặc open-source) nó? Trên tinh tần của Strunk and White, thì hãy tránh xa sự phức tạp, và giống như các từ trên một trang vậy, khi mà bạn không thể loại bỏ thêm từ nào nữa– thì lúc đó bạn đã hoàn thành công việc.
Các giải pháp đơn giản sống sót và thịnh vượng bởi vì chúng hoạt động tốt, và mọi người có thể thực sự hiểu chúng. Đừng cho rằng bất kỳ ai cũng đủ thông minh để quản lý những giải pháp phức tạp đến mức khó tin– lạc quan là một mối nguy hiểm nghề nghiệp đối với các lập trình viên. Chúng ta nên cố gắng xây dựng những giải pháp đơn giản bất cứ khi nào có thể, thậm chí nếu đôi khi chúng ta phải bịt mũi khi làm nó.
Bài viết gốc được viết vào năm 1991; có một bài kéo theo rất hay là Back to the Future: Is Worse (Still) Better?, và cũng có một Wiki về chủ đề này cùng với nhiều link trỏ đến.
(Vinacode)
Có thể bạn quan tâm:
- Sách hướng dẫn lập trình game trên Android, Beginning Android 4 Games Development
- Biến Google Drive thành server phim online như thế nào?
- Quản lý tiệm làm móng(nails salon) dễ dàng và chuyên nghiệp trên iPad với Ez NailSoft
- Wrapify thành Uber trong ngành quảng cáo
- Tài liệu Unity3D, phần mềm làm mobile game và game online chuyên nghiệp
- Các xu thế chi phối sự chuyển dịch của di động năm 2014
- Quá trình kết nối và các giao tiếp giữa mạng với máy điện thoại
- Cấu hình scheduled tasks Mautic - marketing automation software trên Windows
- Hướng dẫn quản trị và sử dụng VTigerCRM 5.4
- Tài liệu hướng dẫn qui trình kết nối Ngân Lượng với Magento, flow with NganLuong Magento
- Trao đổi dữ liệu điện tử theo chuẩn EDI là gì?
- Những tình huống “đứng hình” trong JavaScript
DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...
Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…
Quý khách xem Hồ sơ năng lực của DVMS tại đây >>
Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>