Joel Test: 12 bước để có mã nguồn tốt hơn.

Bạn đã từng nghe nói về SEMA ? Đó là một hệ thống khá huyền bí để đo lường mức độ tốt của đội ngũ phát triển phần mềm. Nhưng không, chờ đã! Đừng vội vào link đó! Sẽ mất khoảng sáu năm để hiểu những thứ đó. Vì vậy, tôi đã đưa ra thử nghiệm của riêng mình để đánh giá chất lượng của một đội phần mềm. Phần lớn chỉ mất khoảng 3 phút cho mỗi phần. Với tất cả thời gian bạn tiết kiệm, bạn có thể đến trường y khoa học thêm

1. Có dùng chương trình quản lí source code không?
2. Có chương trình build tự động không?
3. Có build tự động hàng ngày không?
4. Có ghi lại bug không?
5. Có sửa bug cũ trước khi viết code mới không?
6. Có thường xuyên cập nhật lịch cho đúng với tình hình thực tế không?
7. Có spec không?
8. Phòng cho lập trình viên có yên tĩnh không?
9. Có mua các công cụ giúp lập trình tiện lợi hơn không?
10. Có người chuyên test không?
11. Có bắt ứng viên viết code khi tuyển dụng không?
12. Có mời ngẫu nhiên ai đó dùng thử chương trình không?

Cái hay của Joel test là có thể trả lời ngay có hoặc không cho mỗi câu hỏi. Bạn không cần xác định xem mỗi ngày một lập trình viên viết được bao nhiêu dòng code. Với mỗi câu có, team của bạn được 1 điểm. 12 điểm là hoàn hảo, 11 là có thể vẫn chấp nhận được, 10 trở xuống thì bạn đang gặp nguy đó. Sự thật là hầu hết công ty chỉ được 2 hoặc 3 điểm, nghĩa là các công ty này cần được cứu giúp, bởi vì những công ty như Microsoft luôn đạt 12 điểm. Tất nhiên, đây không phải là toàn bộ yếu tố quyết định thành công hay thất bại: cụ thể, nếu team của bạn siêu hạng, nhưng lại đang hì hục làm sản phẩm chẳng ai muốn dùng chẳng hạn. Và cũng có trường hợp team làm ăn rất chậm chạp chẳng được điểm nào, nhưng lại làm ra được phần mềm làm cả thế giới kinh ngạc. Nhưng đi nói lại, thì nếu đạt 12 điểm, thì bạn có team rất kỉ luật không bao giờ làm hỏng project.

1. Có dùng chương trình quản lí source code không?

Tôi đã từng dùng những chương trình quản lý source thương mại và cả CVS miễn phí và nhận thấy CVS khá ổn. Nếu không có chương trình quản lý source, bạn sẽ điên đầu khi các lập trình viên làm việc với nhau. Các lập trình viên sẽ không có cách nào biết được những gì mà người khác đã làm. Lỗi lầm sẽ không được phục hồi dễ dàng. Cái hay của chương trình quản lý source chính là chúng sẽ tự lấy mã nguồn từ ổ cứng của mọi lập trình viên -- tôi chưa từng nghe nói dự án nào có sử dụng chương trình quản lý source mà lại thất lạc nhiều code cả.

(Thời điểm tác giả viết là hơi lâu rồi, giờ thì mọi người ai cũng biết là nên dùng Git rồi phải không?)

2. Có chương trình build tự động không?

Ý của tôi là: bạn mất bao nhiêu bước để build thành công mã nguồn mới nhất để tạo thành sản phẩm cuối cùng để giao cho khách hàng? Ở team giỏi, có một script duy nhất để làm mọi thứ: check out mã nguồn từ đầu, build lại mọi dòng code, tạo ra các file chạy, tạo ra tất cả các phiên bản, cho mọi ngôn ngữ, theo mọi tổ hợp #ifdef, tạo ra gói cài đặt, và lưu ra sản phẩm cuối cùng khách hàng có thể dùng ngay – CDROM, trang web cho phép download… mọi thứ.

Nếu qui trình diễn ra hơn một bước thì dễ xảy ra lỗi. Và khi bạn sắp hoàn thành sản phẩm, bạn muốn có cách để đẩy nhanh tốc độ sửa lỗi "cuối cùng", tạo các file EXE... Nếu phải mất đến 20 bước để biên dịch code, chạy các phần cài đặt... bạn sẽ stress (thuật ngữ giới trẻ bây giờ hay dùng) và phạm sai sót ngốc nghếch.

Chính vì lý do này, công ty tôi làm trước công ty hiện tại đã chuyển từ chương trình WISE sang chương trình InstallShield: chúng tôi cần chương trình cài đặt (tạo ra bởi WISE và InstallShield) có thể chạy từ script (để có thể chỉnh sửa dễ dàng) tự động suốt đêm thông qua chương trình scheduler của Windows NT, mà WISE không đáp ứng yêu cầu này nên chúng tôi cho nó nghỉ chơi. (Những gã ở WISE đảm bảo với tôi là phiên bản mới nhất sẽ hổ trợ chế độ build tự động vào ban đêm).

3. Có build tự động hàng ngày không?

Khi bạn sử dụng chương trình quản lý mã nguồn, thỉnh thoảng, lập trình viên lỡ tay commit bậy, làm gián đoạn quá trình build tự động. Ví dụ, họ thêm tập tin mới vào chương trình, và biên dịch thành công trên máy của họ nhưng quên commit tập tin này. Sau đó, họ tắt máy về nhà, ngây thơ vô số tội. Những người khác cũng về nhà, nhưng bởi vì không thể viết chương trình tiếp được nên phải về.

Việc gián đoạn khi build tự động là điều rất tồi tệ và cần build hàng ngày để đảm bảo không có sai sót nào bị quên. Ở những team lớn, cách hay nhất để đảm bảo gián đoạn được khắc phục ngay là phải build tự động vào buổi trưa. Mọi người cố commit càng nhiều càng tốt trước giờ ăn trưa. Để khi trở lại làm việc, thì mọi thứ đã build xong. Nếu không có lỗi, quá tốt! Mọi người kiểm tra cập nhật lên mã nguồn phiên bản mới nhất và tiếp tục làm việc. Nếu có lỗi, thì sửa. Nhưng mọi người đều có thể tiếp tục làm việc với mã nguồn của phiên bản không có sai sót trước lần build vừa rồi.

Ở team viết chương trình Excel, chúng tôi có luật là để “phạt” bất kỳ ai làm gián đoạn quá trình build tự động, sẽ bắt người này trông chừng chương trình build cho đến khi có người khác lại làm gián đoạn. Điều này khích lệ việc tránh làm gián đoạn quá trình build, và cũng là cách hay để mọi người nên luân phiên tìm hiểu chương trình build tự động làm việc thế nào.

Đọc thêm: Daily Builds are Your Friend

4. Có ghi lại bug không?

Tôi không quan tâm bạn nói gì. Nếu bạn đang phát triển mã, ngay cả khi trong nhóm chỉ có một thành viên, nếu không có bản ghi nhớ liệt kê tất cả các bug có trong mã, bạn sẽ giao cho khách sản phẩm có mã chất lượng thấp. Nhiều lập trình viên cứ nghĩ rằng họ có thể nắm hết danh sách các bug trong đầu. Thật vô lý! Tôi không thể nhớ hơn 2 hoặc 3 bug cùng lúc vào sáng hôm sau, hoặc trong trường hợp chạy đua vì sắp đến hạn giao sản phẩm, chúng có thể bị bỏ sót. Tuyệt đối, bạn phải theo dõi ghi lại các bug.

Bản ghi nhớ bug có thể phức tạp hoặc đơn giản. Bản ghi nhớ hữu ích phải kèm cho mỗi bug dữ liệu sau:

• các bước đầy đủ để tái tạo lại bug
• hành vi được mong đợi
• hành vi quan sát được (bug)
• ai được giao sử bug
• nó đã được sửa chưa

Nếu sự phức tạp của phần mềm quản bug là thứ duy nhất ngăn bạn theo theo dõi các bug, thì chỉ cần tạo một bảng đơn giản 5 cột với các trường cốt yếu này và bắt đầu dùng nó.

Đọc thêm: Painless Bug Tracking.

5. Có sửa bug cũ trước khi viết code mới không?

Phiên bản đầu tiên của Microsoft Word dành cho Windows là một dự án death march (biết là không khả thi, biết chết mà vẫn làm). Sẽ không bao giờ xong. Nó cứ trượt dài. Cả đội phải làm ngày làm đêm, dự án bị trì hoãn đi trì hoãn lại và sự căng thẳng lên đến tột độ. Khi sản phẩm chó chết đó hoàn thành, Microsoft cho cả đội đi Cancun nghỉ mát, rồi ngồi lại xem xét nghiêm túc.

Họ nhận thấy, những người quản lý dự án cứ khăng khăng làm theo thời gian biểu, bắt các lập trình viên hoàn thành vội vã quá trình viết code, nên họ viết ra mã cực tệ, bởi vì khâu chỉnh sửa bug không là một phần của thời gian biểu chính thức. Đã không có sự cố gắng nào để hạn chế số bug. Hoàn toàn trái ngược. Chuyện này còn tệ đến mức có lập trình viên nọ khi viết mã để tính chiều cao của một dòng văn bản, đã viết “return 12” và chờ báo cáo kết quả bug là mã anh ta viết không phải lúc nào cũng chạy đúng. Thời gian biểu chỉ đơn thuần là bản liệt kê những tính năng chờ biến thành bug. Trong cuộc giám định pháp y này, đây được quy là “phương pháp gây ra vô hạn sai sót”.

Để sửa chữa vấn đề, Microsoft đã áp dụng trên toàn cầu thứ gọi là “phương pháp 0 sai sót”. Nhiều lập trình viên trong công ty cười rúc rích, bởi vì điều này nghe như giới quản lí nghĩ có thể giảm bug bằng mệnh lệnh quản lí. Thực ra, “0 sai sót” nghĩa là tại bất kỳ thời điểm nào, ưu tiên cao nhất là sửa bug cũ trước khi viết tiếp mã mới. Dưới đây là lí do.

Nói chung, càng lâu sửa bug thì càng tốn kém (về thời gian và tiền bạc) để sửa.

Ví dụ khi bạn gõ nhầm hoặc viết sai cú pháp mà trình biên dịch bắt lỗi được, việc sửa lỗi về căn bản rất dễ.

Khi trong mã có bug mà bạn thấy ngay khi thử chạy lần đầu, bạn có thể sửa được ngay bởi tất cả mã vẫn còn nằm trong đầu bạn.

Nếu bạn phát hiện ra bug trong mã viết cách đây vài ngày, sẽ mất một lúc để lùng sục kiếm chỗ để sửa, nhưng khi bạn đọc lại mã bạn viết, bạn sẽ nhớ mọi thứ và có thể sửa bug trong thời gian vừa phải.

Nhưng nếu bạn phát hiện bug trong mã viết cách đây vài tháng, bạn sẽ quên nhiều thứ về đoạn mã tương ứng, và sửa sẽ khó hơn nhiều. Mà lúc đó, bạn có thể đang phải sửa code của người khác, và họ có thể đang trong kỳ nghỉ ở Arabu, trong trường hợp này, việc sửa bug giống như khoa học: bạn phải từ từ, có phương pháp, tỉ mỉ, và bạn không thể chắc chắn sẽ mất bao lâu để phát hiện ra cách chữa.

Và nếu bạn tìm thấy bug trong sản phẩm đã đến tay khách hàng, bạn sẽ chịu nhiều phí tổn để chữa.

Đó là lý do phải sửa bug ngay tức thì: vì mất thời gian ít hơn. Lý do khác nữa liên quan tới việc dự đoán mất bao lâu để viết mã mới dễ hơn hơn là dự đoán mất bao lâu để sửa bug cũ. Ví dụ, nếu tôi hỏi bạn dự đoán mất bao lâu để viết mã sắp xếp một danh sách, bạn có thể cho tôi ước lượng khá tốt. Nhưng nếu tôi hỏi bạn làm dự đoán mất bao lâu để sửa bug xảy ra nếu cài trình duyệt IE 5.5, thậm chí bạn không thể đoán được, bởi vì bạn không biết cái gì gây ra bug. Có thể sẽ mất 3 ngày để mò ra, hoặc có thể chỉ mất có 2 phút.

Điều này có nghĩa nếu bạn có thời gian biểu với nhiều bug phải sửa, thì thời gian biểu đó không chắc chắn. Nhưng nếu bạn đã sửa tất cả bug đã phát hiện, và tất cả chỉ còn là viết mã mới, thì thời gian biểu của bạn sẽ cực kỳ chính xác.

Điều thú vị khác về việc giữ cho số bug luôn ở số 0 là bạn có thể phản ứng nhanh hơn trong cuộc cạnh tranh. Một số lập trình viên nghĩ việc này như là lúc nào cũng giữ sản phẩm ở trạng thái sẵn sàng có thể giao cho khách hàng. Vậy thì nếu đối thủ của bạn giới thiệu tính năng mới rất "khủng", mà tính năng này có thể cướp khách của bạn, bạn có thể thực hiện tính năng này và giao hàng ngay, mà không phải sửa nhiều bug được tích lũy.

6. Có thường xuyên cập nhật lịch cho đúng với tình hình thực tế không?

Bây giờ ta bàn về lịch làm việc. Nếu chương trình bạn viết rất quan trọng với phòng kinh doanh, có nhiều lí do tại sao việc bộ phận kinh doanh cần biết khi nào chương trình hoàn thành. Lập trình viên hiển nhiên thường cằn nhằn về việc lập lịch làm việc. "Khi nào xong thì nó sẽ xong!", họ hét toáng với nhân viên phòng kinh doanh.

Thật không may, điều này không như ý muốn. Có quá nhiều quyết định liên quan đến kế hoạch mà phòng kinh doanh làm xong càng sớm càng tốt trước khi bàn giao sản phẩm: trình diễn demo, triển lãm thương mại, quảng cáo… Và chỉ có một cách để làm điều này, là phải có một lịch trình thích hợp, và cập nhật nó cho đúng thực tế.

Điều cực kì quan trọng khác về lịch là nó buộc bạn ra quyết định về tính năng mà bạn sẽ làm, nó buộc bạn loại bỏ những tính năng kém quan trọng nhất, hơn là cứ làm hì hục rùa bò làm mãi không xong.

Việc duy trì theo thời gian biểu là không khó. Hãy đọc bài viết Painless Software Schedule của tôi, nó miêu tả cách đơn giản để lập lịch tốt.

7. Có spec không?

Có một thực tế: ai cũng đồng ý là nên có spec, nhưng chẳng ai làm cả.

Tôi không chắc là vì sao, có thể là do các lập trình viên đều rất ngại viết document. Điều này dẫn tới khi có sự cố, lập trình viên thường comment luôn vào trong source. Đó là xu hướng thường thấy.

Trong giai đoạn design nếu phát hiện sự cố, ta có thể chỉ cần viết lại vài dòng. Nhưng khi đã viết thành code, việc sửa chữa không còn đơn giản nữa. không ai muốn xóa hẳn những đoạn code mình đã viết, dẫn tới tâm lý fix bug không thực sự hiệu quả. Các sản phẩm tạo ra mà không có spec thường gây khó khăn cho việc cập nhật lịch làm việc. Công ty Netscape đã trải qua đau thương này, 4 version đầu tiên của Mozzila thực sự là 1 đống hỗn tạp, và ban quản lý đã quyết định được cho là ngu ngốc là bỏ toàn bộ code cũ đi, viết lại từ đầu. Nhưng họ không cải thiện cách làm việc nên đương nhiên lặp lại những lỗi lầm cũ, thế là phải mất vài năm Mozzila mới có phiên bản Alpha.

Có 2 cách để giải quyết vấn đề này, đó là đào tạo các coder cách viết document, hoặc chỉ thuê những người đã có kĩ năng viết document tốt. Ở cách nào thì cũng nên thêm vào nội qui “code phải có spec”.

Xem thêm về spec tại 4 –part series

8. Phòng cho lập trình viên có yên tĩnh không?

Rất nhiều tài liệu nói về việc tăng năng suất lao động nhờ cung cấp không gian rộng rãi, yên tĩnh, và riêng tư cho nhân viên như cuốn sách cổ điển về kĩ nghệ phần mềm Peopleware chẳng hạn.

Chúng ta đều biết nhân viên làm việc hiệu quả nhất khi đã vào "guồng" - tức là khi tập trung cao độ, khi mà họ toàn tâm toàn ý vào công việc và hoàn toàn thoát ra khỏi ngoại cảnh. Khi tập trung tuyệt đối, họ quên đi khái niệm về thời gian và làm ra những thứ tuyệt nhất. Đó chính là lúc họ giải quyết công việc với năng suất cao nhất. Nhà văn, lập trình viên, nhà khoa học và cả cầu thủ bóng rổ sẽ chỉ cho bạn thế nào là tập trung.

Vấn đề là muốn tập trung cũng không dễ. Nếu tính thử, có khi mất khoảng 15 phút để đạt năng suất cao nhất. Nhiều khi đang mệt hoặc sau khi vừa mới làm xong nhiều công việc đòi hỏi sáng tạo trong ngày hôm đó, bạn không thể tập trung nổi và thế là giành nốt thời gian còn lại trong ngày để lan man, lướt web, chơi xếp hình.

Vấn đề nữa là rất dễ mất tập trung. Tiếng ồn, chuông điện thoại, giờ ăn trưa, 5 phút đi lấy cà phê, đặc biệt là bị đồng nghiệp làm phiền... tất cả sẽ khiến bạn mất tập trung. Đồng nghiệp hỏi bạn một câu làm mất 1 phút nhưng tệ thay, bạn phải mất nửa tiếng để tập trung trở lại, năng suất tổng thể giảm nghiêm trọng. Nếu phải làm việc trong môi trường ồn ào kiểu như nhân viên marketing nói chuyện điện thoại ồn ào ngay bên cạnh lập trình viên, năng suất làm việc sẽ giảm nghiêm trọng vì không thể tập trung nổi. Với lập trình viên lại càng khó. Năng suất làm việc phụ thuộc vào khả năng nhớ rất nhiều chi tiết nhỏ nhặt cùng một lúc trong trí nhớ ngắn hạn. Bất kì sự ngắt quãng nào cũng làm cho tất cả những chi tiết này tan biến. Khi quay trở lại làm việc, bạn không thể nhớ nổi chi tiết nào (như tên biến đang dùng, hay không biết đã viết thuật toán tìm kiếm đến đâu rồi) và lại phải mò lại từ đầu khiến công việc bị chậm lại rất nhiều.

Thử làm bài toán đơn giản. Giả sử khi làm gián đoạn công việc của một lập trình viên dù chỉ một phút, sẽ làm anh ta mất 15 phút không tập trung. Giả sử Jeff và Mutt ngồi ở 2 khoang cạnh nhau trong một phòng lớn kiểu như thế này. Mutt không nhớ tên phiên bản Unicode của hàm strcpy. Nếu Mutt tự tra cứu thì mất 30 giây, nếu hỏi Jeff thì chỉ mất 15 giây. Vì ngồi ngay cạnh Jeff, anh ta hỏi Jeff. Jeff bị phân tâm và mất 15 phút chỉ để tiết kiệm cho Mutt 15 giây.

Nếu để hai người làm việc ở 2 phòng riêng biệt có tường và cửa kín. Mutt không nhớ tên hàm đó. Nếu Mutt tự tra cứu thì mất 30 giây, nếu hỏi Jeff thì mất tới 45 giây tính cả thời gian đứng dậy và đi sang phòng Jeff. Thế là Mutt tự tra cứu. Bây giờ, Mutt mất 30 giây nhưng lại tiết kiệm cho Jeff 15 giây. Ahh!

9. Có mua các công cụ giúp lập trình tiện lợi hơn không?

Lập trình bằng ngôn ngữ biên dịch vẫn là một trong những việc không thể thực hiện trên máy tính cá nhân thông thường. Nếu quá trình biên dịch quá lâu thì việc trang bị máy tính tối tân nhất có thể giúp tiết kiệm thời gian cho bạn. Nếu biên dịch mất tới 15 giây, lập trình viên sẽ chán nản trong khi chờ đợi và tranh thủ đọc tờ The Onion, việc này khiến cho anh ta mất tập trung và làm giảm năng suất làm việc.

Debug phần giao diện người dùng với hệ thống chỉ có 1 màn hình là rất khó khăn nếu không muốn nói là không thể. Nếu bạn phải thực hiện công việc này, 2 màn hình sẽ làm mọi việc trở nên dễ dàng hơn rất nhiều.

Hầu hết lập trình viên phải xử lý hình ảnh các biểu tượng, thanh công cụ, và đa số không có một phần mềm xử lý ảnh tốt. Cố dùng Ms Paint để xử lý ảnh đúng là một trò hề nhưng lại là cách mà hầu hết lập trình viên vẫn làm.

Trong một công việc gần đây, lão quản trị hệ thống liên tục spam hòm thư của tôi phàn nàn là tôi sử dụng nhiều hơn ... 220 MB ổ cứng trên server. Tôi cãi lại rằng với giá ổ cứng rẻ bèo như hiện nay, giá cho không gian ổ cứng còn thấp hơn với số tiền trả cho giấy vệ sinh tôi dùng. Thậm chí mất 10 phút để dọn dẹp các thư mục cũng quá ư là lãng phí thời gian.

Đội phát triển Top notch không bao giờ tra tấn lập trình viên kiểu ấy. Ngay cả những rắc rối nhỏ nhặt do công cụ cũng sẽ tích lũy lại, khiến lập trình viên cảm thấy khó chịu. Và một lập trình viên khó chịu là một lập trình viên làm việc không hiệu quả.

Tóm lại thì.... lập trình viên rất dễ mua chuộc bằng cách đưa cho họ công cụ làm việc xịn và tối tân nhất. Chi phí đó rẻ hơn nhiều so với cách đưa ra một mức lương cạnh tranh!

10. Nhóm phát triển có người chuyên test không?

Nếu đội phát triển không có một tester chính thức tương ứng với mỗi 2 hoặc 3 lập trình viên thì hoặc là sản phẩm làm ra đầy lỗi, hoặc là lãng phí tiền bạc khi cho lập trình viên làm 1 công việc 100$/h trong khi nó có thể hoàn thành bởi 30$/giờ của tester. Hà tiện việc sử dụng tester là một phương án sai lầm nghiêm trọng mà thật đáng ngạc nhiên khi ngày càng nhiều người không nhận ra điều này.

Đọc Top 5 lý do (sai lầm) để không có tester, một bài viết của tôi về chủ đề này.

11. Những người đến xin việc có phải viết code trong buổi phỏng vấn không?

Bạn có thuê một nhà ảo thuật mà không bảo anh ta biểu diễn thử vài trò không? Tất nhiên là không.

Bạn có thuê nhà bếp chuẩn bị đồ ăn cho tiệc cưới của mình mà không nếm thử trước thứ ăn? Rõ ràng là không. (Trừ phi đó là cô Marge, và cô ấy sẽ thù bạn mãi mãi nếu bạn không để cô ấy làm món bánh "nổi tiếng" của mình).

Hàng ngày, các lập trình viên vẫn được thuê dựa vào resume ấn tượng hay do người phỏng vấn thích nói chuyện với anh ta. Hoặc là họ chỉ bị hỏi những câu hỏi tầm thường ("CreateDialog() khác gì DialogBox()?") mà đáp án có ngay trong tài liệu. Bạn không cần quan tâm liệu họ có nhớ hàng ngàn những thứ không quan trọng về lập trình, bạn cần quan tâm liệu học có thể lập trình thực sự không. Hay có khi tệ hơn, họ bị hỏi những câu kiểu "AHA!": kiểu câu hỏi chỉ rất dễ nếu bạn đã biết câu trả lời, nhưng nếu bạn không biết đáp án thì họ càng không thể.

Làm ơn, đừng làm những việc đó. Trong cuộc phỏng vấn, làm gì cũng được nhưng hãy yêu cầu ứng viên viết một vài đoạn code. (Để có thêm những lời khuyên, đọc bài Chiến thuật du kích trong phỏng vấn của tôi.)

12. Có các cuộc kiểm tra tính khả dụng hành lang không?

Một cuộc kiểm tra tính khả dụng hành lang là việc bạn vớ đại một người ngoài hành lang vừa đi ngang qua và yêu cầu họ sử dụng chương trình mà bạn vừa viết. Nếu làm như vậy với 5 người, bạn sẽ khám phá ra 95% những điều cần biết về các vấn đề về tính khả dụng mắc phải.

Thiết kế giao diện người dùng tốt không khó như bạn tưởng, và đó là cốt yếu nếu bạn muốn khách hàng thích thú và mua sản phẩm của mình. Bạn có thể đọc cuốn sách online miễn phí về thiết kế giao diện người dùng của tôi, hướng dẫn ngắn gọn nhất cho lập trình viên.

Nhưng điều quan trọng nhất về giao diện người dùng là nếu bạn đưa chương trình của mình cho một số nhóm người (khoẳng 5 hay 6 người là đủ), bạn sẽ nhanh chóng tìm ra những vấn đề lớn nhất mà những người này gặp phải. Đọc Bài viết của Jakob Nielsen để xem giải thích tại sao. Ngay cả khi không có kĩ năng thiết kế giao diện người dùng thì với việc thực hiện các kiếm tra tính khả dụng hành lang, giao diện người dùng bạn tạo ra cũng sẽ tốt hơn rất nhiều.

Nguồn tham khảo : The Joel Test: 12 Steps to Better Code