Lập trình viên cũng là người sử dụng

Bài viết được dịch từ blog Coding Horror

Hiện tại tôi đang phụ trách việc xây dựng một API nhỏ cho BetaBrite-specific một tập con của Alpha Sign Communications Protocol. Về mặt tự nhiên, tôi muốn nó trở nên dễ dàng sử dụng và dễ hiểu đối với những lập trình viên khác– đó là một vấn đề về usability (tính dễ sử dụng) kinh điển. Bạn sẽ áp dụng hướng tiếp cận usability nào khi mà độc giả của bạn lại là những nhà phát triển phần mềm khác?

Lập trình viên cũng chính là người sử dụng khi dùng các API của các đồng nghiệp khác viết ra.Lập trình viên cũng chính là người sử dụng khi dùng các API của các đồng nghiệp khác viết ra.


Câu trả lời thì cũng không mấy ngạc nhiên, nó chính xác giống như cách mà bạn thực hiện đối với người dùng bình thường. Steven Clarke của công ty Microsoft có một blog hoàn toàn tập trung vào chủ đề này, và ông ta hiện đang tiến hành những nghiên cứu về tính usability (tính dễ hiểu) đều đặn trên toàn bộ các sản phẩm công nghệ sắp ra lò của hãng Microsoft. Có một cái gì đó tóm tắt dày đặc trong những kết quả của ông ta (trong file powerpoint), và tất cả nó giống như là bánh-mì-và-bơ của các nghiên cứu về tính usability vậy. Không có thứ gì là quá thiên về các lập trình viên ở trong đó cả. Nó tập trung vào con người, các use case, các tác vụ, và có rất nhiều sự quan sát. Ở đây là một ít ví dụ tiêu biểu từ blog của ông ta, cái mà tôi đề xuất bạn nên xem qua.

Về các Attribute (thuộc tính):

Tôi nghĩ rằng một yếu tố trong vấn đề này đó là khả năng khó nhìn thấy của các attribute (thuộc tính). Ví dụ, một người tham gia trong cuộc nghiên cứu tuần này đã sử dụng debugger để duyệt qua những dòng code khi anh ta để ý thấy một hành vi (behavior) không mong đợi tại một thời điểm trong suốt quá trình thực thi của đoạn code đó. Anh ta đã tập trung vào một khối code riêng biệt và sử dụng nỗ lực của mình vào việc tìm hiểu xem liệu có phải khối code đó có thể là nguyên nhân của cái hành vi (behavior) mà anh ta đã quan sát thấy hay không. Nguyên nhân của cái hành vi đó là do bởi một thuộc tính (attribute) đã được áp dụng tới class đó để định nghĩa phương thức mà anh vừa mới duyệt qua. Vì vậy khi anh ta đọc đoạn code của mình, thì cái thuộc tính đó lại nằm ngoài sự tập trung chú ý của anh.

trên ADO.NET:

Trong một nghiên cứu về tính dễ sử dụng (usability) khác mà tôi tiến hành trên ADO.NET, những người tham gia đã được yêu cầu viết code để truy vấn một table và xuất ra các kết quả trên màn hình console. Những kết quả này được lưu trữ trong một DataReader. Nhiều người tham gia mong chờ tìm thấy một thuộc tính Count trên DataReader đó để họ có thể sử dụng một vòng lặp qua nội dung của DataReader, và đánh chỉ số mỗi thành phần trong mỗi lần lặp của vòng lặp đó. Tuy nhiên, không có thuộc tính nào như vậy tồn tại cả. Những người tham gia đã dành một số lượng lớn thời gian để tìm kiếm một số thuộc tính tương tự khác như là Length, NumberOfRows, v.v… nhưng vẫn không tìm thấy bất cứ cái gì có thể giúp ích cho họ.

Đến lúc này, thì hầu hết những người tham gia sẽ tìm đến tài liệu trợ giúp (help docs) để tìm một đoạn code mẫu có thể giúp họ. Ngay khi người tham gia tìm thấy một đoạn code mẫu mà chỉ cho họ rằng họ cần sử dụng một IEnumerator để duyệt qua nội dung của DataReader đó, họ hiểu chính xác điều cần phải làm. Thậm chí mặc dù giải pháp đó có khác một chút so với giải pháp mà những người tham gia đã thử ban đầu, nhưng họ cũng không gặp khó khăn gì trong việc hiểu hướng tiếp cận mới này.

Khi nói đến tính usability (tính dễ sử dụng), thì không có cái nào có thể thay thế được sự quan sát. Nó là tuyệt đối quan trọng.

Có một thứ đã xuất hiện trong đầu tôi hầu như ngay lập tức đó là sự quan trọng của những đoạn code mẫu tốt. Chúng là những thứ đầu tiên mà tôi tìm kiếm trong bất kỳ một môi trường mới nào mà mình bị đặt vào, và dù cho là tốt hơn hoặc tồi hơn, chúng lên dây cho kinh nghiệm của tôi. Nhưng, như Steven đã mô tả trong bài viết Dr. Dobb’s Journal, là Measuring API Usability (Đo lường tính dễ sử dụng của API) (PDF), bạn phải cẩn thận rằng bạn không thể che lấp được những quyết định thiết kế API tồi thông qua những đoạn code mẫu tốt được:

Kinh nghiệm đã thực sự giúp đỡ chúng tôi nhận ra nguyên nhân gốc của vấn đề mà chúng tôi đã quan sát thấy trong phòng thí nghiệm về tính usability (tính dễ sử dụng). Ví dụ, trong một nghiên cứu, chúng tôi quan sát thấy có rất nhiều các lập trình viên đang dành một phần lớn thời gian để tìm kiếm trong các tài liệu trợ giúp một vài đoạn code mẫu mà sẽ chỉ cho họ cách làm thế nào để có thể hoàn thành một tác vụ được yêu cầu. Cách hiểu đầu tiên của dữ kiện này chỉ đơn giản là “Hãy sửa lại tài liệu trợ giúp đó sao cho dễ hiểu!” Tuy nhiên, khi chúng tôi sử dụng framework kinh nghiệm để mô tả vấn đề này, thì nó trở nên rõ ràng rằng lý do mà các lập trình viên đã không thành công khi họ tìm kiếm qua tài liệu trợ giúp là bởi vì cái mà họ đang tìm kiếm thì đơn giản lại không tồn tại. Cái API mà họ đang làm việc trên đó cung cấp một tập các sự trừu tượng với mức sai lệch đối với những lập trình viên sử dụng nó. Họ mong chờ một kiểu trừu tượng đặc biệt được đưa ra bởi API nhưng nó lại không có, bởi vậy họ không thể tìm thấy bất cứ thứ gì về nó trong tài liệu trợ giúp. Theo suy luận đó, nhóm phát triển API đã thiết kế lại API để đưa ra những thứ mà giống với các lập trình viên sử dụng API đang mong chờ. Khi chúng tôi kiểm thử lại API đó, thì đúng là nó đã hoạt động tốt hơn rất nhiều.

Đây là một vấn đề mà tôi đã từng được tiếp xúc trước đây. Nếu bạn đang phải trả lời cho rất nhiều câu hỏi từ những lập trình viên khác về một số thứ mà bạn đã viết ra, thì nó có thể không phải bởi đồng nghiệp của bạn kém cỏi đâu.

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s