Mã nguồn được chạy nhiều hơn được đọc: Một góc nhìn mới về phát triển phần mềm

Mã nguồn được chạy nhiều hơn được đọc: Một góc nhìn mới về phát triển phần mềm

Trong giới lập trình, câu nói "mã nguồn được đọc nhiều hơn được viết" (code is read more than written) đã trở thành một chân lý quen thuộc. Nó nhắc nhở chúng ta rằng người viết code ban đầu không nên đánh đổi sự tiện lợi cho mình làm giảm khả năng đọc hiểu và bảo trì của những người sẽ đến sau. Mặc dù tư duy này rất đúng, nhưng tôi nghĩ chúng ta có thể mở rộng nó hơn nữa để có một cái nhìn toàn diện hơn về vòng đời phát triển phần mềm.

Ý nghĩa thực sự của việc "chạy" mã nguồn

Thực tế là, mã nguồn không chỉ được đọc hay viết, mà quan trọng nhất, nó được chạy. Khi tôi nói "chạy", tôi không chỉ đơn thuần là việc thực thi chương trình, mà là việc vận hành nó trong môi trường production (sản xuất thực tế). Điều này bao gồm tất cả các khâu: triển khai (deploy), nâng cấp, quan sát, kiểm toán, giám sát (monitoring), sửa lỗi và cuối cùng là ngừng hoạt động.

Như Dan McKinley đã từng nói: "Hầu như luôn luôn, chi phí dài hạn để giữ cho một hệ thống hoạt động ổn định vượt xa rất nhiều những bất tiện bạn gặp phải khi xây dựng nó."

Khi áp dụng tư duy này, nguyên tắc KISS (Keep It Simple, Stupid - Giữ cho mọi thứ thật đơn giản) sẽ mang một ý nghĩa hoàn toàn mới. Nó không còn chỉ là việc viết code gọn gàng, mà là giảm thiểu các thành phần chuyển động (moving parts) và hiểu rõ các chế độ lỗi của chúng. Đó là việc đảm bảo hệ thống hoạt động trơn tru ngay cả khi có sự cố xảy ra.

Mô hình ưu tiên: Người dùng > Vận hành > Lập trình

Để đưa ra quyết định tốt hơn, chúng ta có thể xây dựng một mô hình tâm hình thể hiện mức độ quan trọng của các yếu tố trong phát triển phần mềm:

Người dùng > Vận hành > Lập trình

Mã nguồn chỉ là phương tiện để đạt được mục đích cuối cùng. Phần mềm phải có mục đích và cung cấp dịch vụ cho người dùng. Không quan trọng code viết đẹp đến đâu, hay công nghệ hiện đại ra sao, nếu nó không hoàn thành mục đích và mang lại trải nghiệm tốt cho người dùng thì nó vô nghĩa.

Đây là lý do tại sao thay vì đoán mò hoặc hỏi người dùng họ cần gì, tốt nhất là hãy đưa chương trình đến với họ sớm và thường xuyên, đồng thời tích hợp những phản hồi chúng ta học được. Chỉ cần giữ người dùng trong tâm trí khi phát triển, chúng ta đã có thể đi rất xa.

Tuy nhiên, mô hình này có một nhược điểm: nó giả định rằng phần mềm hữu ích và hoạt động tốt sẽ mang lại giá trị cho tổ chức. Đây là sự trừu tượng hóa tiện lợi cho các lập trình viên: chúng ta tạo ra phần mềm tốt, còn doanh nghiệp lo việc biến nó thành tiền. Nhưng cuối cùng, sự trừu tượng này chứng tỏ là quá đơn giản hóa.

Những rối loạn trong phát triển phần mềm

Chúng ta hãy xem xét một số rối loạn phổ biến trong phát triển phần mềm và xem chúng ánh xạ như thế nào đến mô hình này:

• Chỉ quan tâm đến việc viết code: Đây là code thông minh nhưng lười biếng biến thành spaghetti (rối rắm), là tối ưu hóa sớm (premature optimizations), hay những module mà chỉ một người duy nhất có thể chạm vào.
• Công nghệ lên ngôi: Phần mềm từ các đội nhóm không học hỏi từ người dùng hoặc đặt công nghệ lên trên hết. Đó là những chương trình over-engineered (thiết kế quá mức), những "hiện đại hóa" làm giảm trải nghiệm người dùng, hay các ứng dụng web phá vỡ các tính năng của trình duyệt.
• Bỏ quên vận hành: Phần mềm không được thiết kế với việc vận hành trong tâm trí. Đó là phần mềm quá phức tạp với nhiều thành phần, sử dụng cơ sở dữ liệu cầu kỳ cho khối lượng dữ liệu nhỏ, hoặc hệ thống vi dịch vụ (microservices) được quản lý bởi một đội nhóm nhỏ.
• Phần mềm ảo: Đây là phần mềm được xây dựng nhưng hiếm khi (hoặc không bao giờ) được đưa đến production. Charity Majors gọi đây là "sống dối". Một loại khác là phần mềm không có người dùng (nhưng lại scale rất lớn).

Kinh doanh, Đạo đức và Thực tế

Rõ ràng, chúng ta không thể bỏ qua các thực tế kinh tế của ngành. Ví dụ rõ ràng nhất là ngân sách: chúng ta không có nguồn lực vô hạn để thỏa mãn nhu cầu người dùng. Có marketing, có thời hạn (deadline), có các bên liên quan và nhà đầu tư. Đôi khi, chúng ta cần làm việc trên những thứ tạo ra doanh thu, không phải những gì làm hài lòng người dùng.

Điều này dẫn đến một thực tế phũ phàng: Có rất nhiều phần mềm được sản xuất ra không quan tâm đến người dùng, hoặc thao túng họ, hoặc biến họ thành sản phẩm. Không chỉ giới hạn ở mạng xã hội, với tư cách người dùng, đôi khi tôi thậm chí không thể đặt phòng, đặt đồ ăn hay nhấn vào nút Start của Windows mà không bị các cửa sổ pop-up làm phiền.

Có sự lệch pha giữa những gì chúng ta nghĩ là "làm tốt công việc" và những gì một phần lớn ngành công nghiệp coi là có lợi nhuận. Điều này giải thích sự khó chịu ngày càng tăng của nhiều chuyên gia phần mềm.

Mặc dù chúng ta không thể chỉ đơn giản là bỏ qua các thực tế kinh tế, nhưng có lẽ chúng ta nên có lập trường đạo đức mạnh mẽ hơn để không gây hại cho người dùng. Chúng ta cần thừa nhận rằng người dùng không phải lúc nào cũng đến trước doanh nghiệp, nhưng doanh nghiệp cũng không nên vô điều kiện đứng trên hết người dùng.

user > ops > dev

biz > ops > dev

biz ≹ user