Tác giả Joel Spolsky
2000/08/09
Hiện nay có rất nhiều đội phần mềm, công ty phần mềm Việt Nam muốn làm cho các khách hàng Mỹ, nói tiếng Anh. Rào cản lớn nhất không phải là ngôn ngữ vì tiếng Anh rất phổ thông, dễ học hơn tiếng Nhật. Khách hàng Mỹ thường yêu cầu chất lượng sản phẩm và quy trình làm phần mềm năng động, cạnh tranh và hiện đại hơn rất nhiều. Thời gian giao sản phẩm cũng ngắn hơn nhiều. Joel Test là danh sách các câu hỏi để các công ty phần mềm tự đánh giá năng lực, quy trình phát triển phần mềm của mình. Joel Test được đưa ra từ năm 2000, đến nay đã có nhiều công nghệ thay đổi, hiện đại hơn, nhưng nó vẫn giữ nguyên giá trị căn bản.
Bạn đã bao giờ nghe về SEMA chưa? Nó là một hệ thống khá bí truyền để đánh giá một đội phần mềm có tốt hay không. Từ từ, bình tĩnh! Đừng mở đường link đó! Nó sẽ làm bạn mất tới 6 năm chỉ để hiểu cái mớ đó. Vì thế tôi đã tự nghĩ ra một bài kiểm tra thô thiển và vô trách nhiệm để đánh giá chất lương của một đội phần mềm. Và phần hấp dẫn nhất là nó chỉ mất có 3 phút thôi. Với tất cả thời gian mà bạn tiết kiệm được, bạn có thể đi học Y (^・ω・^ ).
Bài kiểm tra của Joel
- Bạn có sử dụng công cụ quản lý mã nguồn không?
- Bạn có thể build chỉ trong một bước không?
- Bạn có thực hiện build hàng ngày không?
- Bạn có cơ sở dữ liệu về lỗi không?
- Bạn có sửa lỗi trước khi viết code mới không?
- Bạn có lịch trình sát với thực tế hiện tại không?
- Bạn có tài liệu yêu cầu không?
- Lập trình viên của bạn có môi trường yên tĩnh không?
- Bạn có những công cụ tốt nhất có thể mua bằng tiền không?
- Bạn có người thử nghiệm phần mềm không?
- Ứng viên mới có viết code trong bài phỏng vấn không?
- Bạn có thử nghiệm hành lang với người ngoài không?
Điểm hay ho về bài kiểm tra này là rất dễ để trả lời “có” hoặc “không”. Bạn không cần phải tính ra số dòng code/ngày hay trung bình số lỗi/thay đổi định hướng. Hãy cho đội của bạn 1 điểm mỗi câu trả lời “có”. Vấn đề lớn nhất của bài kiểm tra là bạn tuyệt đối không nên sử dụng nó để đảm bảo rằng phần mềm điều khiển nhà máy điện nguyên tử của bạn chạy an toàn.
12 điểm là hoàn hảo, 11 là chấp nhận được, nhưng 10 trở xuống là bạn có vấn đề nghiêm trọng rồi đấy. Sự thật là phần lớn các tổ chức làm phần mềm đang hoạt động chỉ với 2 hoặc 3 điểm, và họ thật sự cần hỗ trợ, bởi vì những công ty như Microsoft vận hành với 12 điểm toàn thời gian.
Tất nhiên, đó không phải là tất cả các yếu tố tạo nên thành hay bại, lấy ví dụ như đội phần mềm tuyệt vời của bạn đang tạo nên một phần mềm mà chẳng ai muốn dùng, thì quả thật là sẽ chẳng có ai muốn dùng đâu. Và hoàn toàn có thể tưởng tượng ra một đội “đánh thuê” chẳng thực hiện bất kỳ điểm nào trong bài kiểm tra này nhưng vẫn tạo ra được phần mềm xuất sắc làm thay đổi thế giới. Nhưng nếu đem mọi thứ ngang bằng ra so, thì nếu đội của bạn thực hiện tốt 12 điểm trên, bạn sẽ có một đội ngũ nghiêm túc, tạo ra sản phẩm đều đặn.
1. Bạn có sử dụng công cụ quản lý mã nguồn không?
Tôi đã từng sử dụng các công cụ thương mại, và tôi cũng đã dùng đồ miễn phí như CVS, và để tôi nói với bạn một câu, CVS là đủ. Nhưng nếu bạn không có công cụ, bạn sẽ vô cùng đau khổ để cho lập trình viên có thể làm việc cùng nhau. Lập trình viên sẽ không có cách nào để biết người khác đã làm gì, sai sót sẽ không dễ dàng để lật lại. Và điểm hay nữa của các hệ thống quản lý mã nguồn là code được tải về ổ cứng của mọi lập trình viên — và tôi chưa bao giờ nghe nói một dự án nào sử dụng công cụ này mà bị mất nhiều code cả.
Chú thích: Hiện nay các công ty phần mềm Hoa Kỳ và châu Âu hầu hết đã chuyển qua dùng GIT thay cho CSV
2. Bạn có thể build chỉ trong một bước không?
Khi hỏi câu này, ý của tôi là bạn cần thực hiện bao nhiêu bước để tạo ra phần mềm phát hành được từ phiên bản code mới nhất? Với những team tốt, họ sẽ tạo ra một script mà bạn có thể chạy để lấy code về, biên dịch tất cả, tạo ra file EXE, cho mọi phiên bản, với mọi ngôn ngữ, tính hết mọi khả năng #ifdef, tạo ra bản cài, và thậm chí là chuẩn bị cho định dạng cuối cùng (đĩa CD, trang web download, v.v.).
Nếu quy trình của bạn cần nhiều hơn một bước, sẽ rất dễ xảy ra lỗi. Và bạn càng gần tới ngày phát hành, bạn càng cần xoay vòng nhanh hơn quy trình sửa lỗi “cuối cùng”, tạo ra các file EXE cuối cùng, v.v. Nếu bạn cần tới 20 bước để biên dịch code, chạy phần mềm tạo bộ cài, v.v., bạn sẽ phát điên sớm và bạn sẽ vấp phải những sai lầm ngớ ngẩn.
Bởi vì thế mà công ty gần đây nhất tôi làm việc đổi từ WISE sang InstallShield: chúng tôi cần quá trình tạo bộ cài có thể chạy từ script tự động qua đêm, sử dụng công cụ NT Scheduler. Và WISE không chạy được trong lịch buổi đêm nên chúng tôi quẳng nó ra. (Những người bạn dễ mến ở WISE trấn an tôi rằng phiên bản mới nhất của họ đã hỗ trợ build đêm) (ND: năm 2000)
3. Bạn có thực hiện build hàng ngày không?
Khi bạn dùng công cụ quản lý mã nguồn, đôi khi một lập trình viên nhập vào thứ gì đó làm cho bản build bị hỏng. Ví dụ như họ thêm 1 tệp mã nguồn, mọi thứ biên dịch tốt trên máy họ, nhưng họ quên không thêm tệp đó lên kho lưu trữ. Rồi sau đó họ khóa máy lại và đi về nhà, vô tư và vui vẻ. Nhưng tiếc thay không ai làm việc được, và họ cũng phải về nhà, dù buồn bực.
Làm hỏng build thật là tệ hại (và hay gặp) đến nỗi việc thực hiện build hàng ngày mang lại giá trị đơn giản chỉ để đảm bảo rằng không có hỏng hóc nào lọt lưới. Với những đội lớn, một cách tốt để đảm bảo hỏng hóc được sửa chữa ngay là chạy build hàng ngày vào bữa trưa. Mọi người nhập hết code có thể về kho lưu trước giờ ăn. Khi họ quay về thì build đã hoàn thành. Nếu nó chạy thì tốt! Mọi người lấy phiên bản mới nhất về và làm việc tiếp. Nếu không được, người làm hỏng sẽ sửa, còn mọi người khác thì làm việc tiếp với phiên bản không bị hỏng từ trước khi build.
Trong đội làm Excel, chúng tôi có một quy luật là bất kỳ ai làm hỏng build, sẽ bị phạt bằng cách phải ngồi canh các bản build cho đến bao giờ có người khác làm hỏng nó. Đây là động lực tốt để tránh làm hỏng build, và là cách tốt để xoay vòng mọi người qua quy trình build để ai cũng hiểu nó hoạt động thế nào.
Hãy đọc thêm về build hàng ngày trong bài viết của tôi Build hàng ngày là bạn của bạn.
4. Bạn có cơ sở dữ liệu về lỗi không?
Tôi không cần biết bạn có ý kiến gì, nhưng nếu bạn viết code, ngay cả khi đội của bạn chỉ có một người, mà bạn không có một cơ sở dữ liệu liệt kê toàn bộ các lỗi đã biết, thì tôi đảm bảo là bạn sẽ phát hành code chất lượng kém. Rất nhiều lập trình viên nghĩ rằng họ có thể nhớ hết các lỗi trong đầu. Vớ vẩn. Tôi không thể nhớ nhiều hơn 2 hay 3 lỗi một lúc, và sáng hôm sau, khi vội vã phát hành, chúng sẽ bị quên mất. Bạn tuyệt đối cần phải theo dõi lỗi một cách có tổ chức.
Cơ sở dữ liệu về lỗi có thể phức tạp hoặc đơn giản. Một cơ sở dữ liệu đơn giản dễ xài cần ít nhất những thông tin sau:
- Các bước để tái tạo lỗi
- Kết quả mong đợi
- Kết quả quan sát được (lỗi)
- Được giao cho ai
- Đã sửa chưa
Nếu sự phức tạp của phần mềm theo dõi lỗi là thứ duy nhất ngăn cản bạn làm chuyện này, thì hãy tạo một bảng đơn giản có 5 cột với những dữ liệu trên và hãy sử dụng nó.
Để đọc thêm về theo dõi lôi, hãy đọc Theo dõi lỗi nhẹ nhàng.
5. Bạn có sửa lỗi trước khi viết code mới không?
Phiên bản đầu tiên của MS Word cho Windows từng bị coi là dự án “hành quân đến chết”. Nó dài vô tận. Nó liên tục trượt mốc. Cả đội phải làm ngoài giờ điên cuồng, và dự án thì vẫn bị chậm, hết lần này đến lần khác, và áp lực thì khủng khiếp. Và khi mà cái của nợ đó được phát hành, chậm nhiều năm trời, MS cho cả đội đi nghỉ mát ở Cancun, và ngồi lại nghiền ngẫm sâu sắc về dự án.
Điều họ nhận ra là PM đã quá tập trung vào việc theo đúng lịch trình khiến cho lập trình viên phải cắm đầu viết code, viết code cực dở, và bởi vì phần sửa lỗi không nằm trong lịch trình chính thức. Chẳng ai cố gắng kìm hãm số lỗi cả, mà có khi còn ngược lại. Chuyện kể là có một lập trình viên cần phải viết code để tính chiều cao của một dòng chữ, chỉ viết đơn giản là “return 12;” và chờ cho bản báo cáo lỗi gửi về nói rằng hàm của anh ta không phải lúc nào cũng đúng. Lịch trình trở thành một bản đánh dấu các tính năng đang chờ đến lượt để được biến thành lỗi. Và trong buổi đánh giá hậu dự án, người ta gọi nó là “phương thức tạo ra lỗi vô tận”.
Để sửa chữa sai lầm, MS đã cho toàn công ty đi theo một hướng mới gọi là “phương thức không lỗi”. Rất nhiều lập trình viên đã cười thầm, vì nghe nó như thể tầng lớp quản lý mơ rằng họ có thể giảm số lỗi bằng vài lời tuyên bố. Thực tế là, “không lỗi” muốn nói rằng tại bất kỳ thời điểm nào, ưu tiên cao nhất cũng luôn là sửa hết lỗi trước khi viết code mới. Lý do như sau.
Kinh nghiệm cho thấy, bạn càng chờ lâu để sửa lỗi, thì chi phí bỏ ra (tính bằng tiền và thời gian) để sửa nó càng tăng. Lấy ví dụ, khi bạn gõ nhầm hoặc viết sai quy định, công cụ biên dịch phát hiện ra thì việc sửa nó chỉ trong nháy mắt.
Khi bạn có lỗi trong code và phát hiện ra khi bạn chạy nó lần đầu, bạn sẽ sửa nó trong giây lát, vì code vẫn còn nguyên trong đầu bạn. Nếu bạn tìm thấy lỗi trong code bạn viết vài ngày trước, nó sẽ làm bạn mất một lúc để tìm ra, nhưng vì bạn đọc code của chính mình, bạn sẽ nhớ mọi thứ và bạn sẽ sửa được trong khoảng thời gian hợp lý.
Nhưng nếu bạn tìm thấy lỗi trong code bạn viết vài tháng trước, bạn có lẽ đã quên gần hết về đoạn code đó, và nó sẽ khó sửa hơn. Và có khi lúc đó bạn đang phải sửa code của người khác, vì họ đang đi nghỉ mát ở Aruba, và trong trường hợp đó thì sửa lỗi giống như một nghiên cứu khoa học vậy: bạn phải làm từ từ, đúng quy trình, hết sức cẩn thận và bạn không thể biết trước được bao lâu mới sửa xong.
Và nếu bạn tìm ra lỗi trong sản phẩm đã phát hành, thì việc sửa nó sẽ tiêu tốn khủng khiếp.
Và đó là lý do nên sửa lỗi ngay lập tức: nó tốn ít thời gian hơn. Và cũng còn một lý do khác, đó là bạn dễ dự đoán thời gian viết code mới hơn là thời gian sửa một lỗi đang tồn tại. Ví dụ tôi hỏi bạn dự đoán thời gian viết một đoạn code để sắp xếp một danh sách, bạn sẽ cho tôi một dự đoán tương đối chuẩn. Nhưng nếu tôi hỏi bạn dự đoán thời gian cần để sửa một lỗi code của bạn không hoạt động nếu IE5.5 được cài trên máy, bạn thậm chí còn không đoán được, vì bạn không biết (theo định nghĩa) cái gì gây ra lỗi. Nó sẽ tốn khoảng 3 ngày để tìm ra chỗ lỗi, hoặc có khi chỉ 2 phút.
Điều này có nghĩa là nếu bạn có một lịch trình với hàng đống lỗi cần sửa, lịch trình đó không đáng tin cậy. Nhưng nếu bạn đã sửa hết những lỗi đã biết, và những gì còn lại chỉ là code mới, thì lịch trình của bạn sẽ chính xác đến mức bất ngờ.
Một ưu điểm nữa về việc luôn giữ cho số lỗi bằng 0 đó là bạn có thể phản ứng nhanh hơn với đối thủ cạnh tranh. Một số lập trình viên coi đây là đảm bảo sản phẩm luôn sẵn sàng phát hành tại mọi thời điểm. Nếu đối thủ của bạn tạo ra một tính năng siêu phẩm và hút khách hàng của bạn, bạn có thể phát triển tính năng tương tự và phát hành ngay lập tức mà không cần phải đợi sửa một số lượng lớn lỗi còn tồn đọng.
Nguồn: JoelOnSoftware
Bình luận