Trần Ngọc Minh

Dịch từ bài: The Joel Test: 12 Steps to Better Code trên bolg Joel On Software của Joel Spolsky

Bạn từng nghe về SEMA chưa? Đó là một hệ thống khá hóc búa để đánh giá mức độ tốt của một đội ngũ phần mềm. Không, chờ đã! Đừng nhấp vào liên kết đó! Điều đó sẽ mất khoảng sáu năm của bạn chỉ để hiểu được những thứ đó. Vì vậy, tôi đã tạo ra một bài kiểm tra của riêng mình (The Joel Test), không chính thống, không ngăn nắp để đánh giá chất lượng của một đội ngũ phần mềm. Phần tuyệt vời của nó là bạn chỉ cần khoảng 3 phút. Với thời gian bạn tiết kiệm được, bạn có thể vào học y khoa.

Điều thú vị về “The Joel Test” là bạn có thể dễ dàng nhận câu trả lời “có” hoặc “không” cho mỗi câu hỏi. Bạn không cần phải tính số dòng mã mỗi ngày hoặc số lỗi trung bình mỗi điểm uốn cong. Gán 1 điểm cho đội của bạn với mỗi câu trả lời “có”. Điều không hay về “The Joel Test” là bạn thực sự không nên sử dụng nó để đảm bảo rằng phần mềm cho nhà máy điện hạt nhân của bạn là an toàn.

Điểm số 12 là hoàn hảo, 11 là chấp nhận được, nhưng nếu điểm số 10 hoặc thấp hơn, bạn gặp vấn đề nghiêm trọng. Sự thật là hầu hết các tổ chức phần mềm đang chạy với điểm số 2 hoặc 3, và họ cần sự giúp đỡ nghiêm túc, vì các công ty như Microsoft chạy ở mức 12 liên tục.

Tất nhiên, đây không phải là những yếu tố duy nhất quyết định sự thành công hoặc thất bại: đặc biệt, nếu bạn có một đội ngũ phần mềm xuất sắc làm việc trên một sản phẩm mà không ai muốn, người ta sẽ không muốn sử dụng nó. Và có thể tưởng tượng được một đội ngũ “gunslinger” (ND: Từ “gunslinger” được sử dụng để chỉ một người chuyên nghiệp hoặc kỳ cựu trong việc sử dụng súng, thường được liên kết với các hình ảnh của người hùng miền Tây hoặc du côn trong các truyện và phim về miền Tây Mỹ. Từ này thường ám chỉ sự thành thạo, tự tin và tinh thần đấu tranh trong việc sử dụng vũ khí hoặc giải quyết vấn đề một cách nhanh chóng và hiệu quả. Trong ngữ cảnh đại chúng, “gunslinger” thường được sử dụng để mô tả các nhân vật hoạt động nhanh và chính xác, đặc biệt trong các tình huống căng thẳng hoặc đối đầu.) không làm bất kỳ điều gì trong danh sách này nhưng vẫn có thể sản xuất ra phần mềm tuyệt vời thay đổi thế giới. Nhưng, tất cả như nhau, nếu bạn làm đúng 12 điều này, bạn sẽ có một đội ngũ có kỷ luật có thể liên tục cung cấp sản phẩm.

1. Bạn có sử dụng hệ thống quản lý mã nguồn không?

Tôi đã sử dụng các gói phần mềm quản lý mã nguồn thương mại và tôi đã sử dụng CVS, một hệ thống miễn phí, và hãy để tôi nói với bạn, CVS hoàn toàn ổn. Nhưng nếu bạn không có hệ thống quản lý mã nguồn, bạn sẽ gặp khó khăn khi cố gắng kết hợp công việc của các lập trình viên. Các lập trình viên không có cách nào để biết được công việc của người khác. Lỗi lầm không thể dễ dàng quay lại trạng thái trước. Một điểm khác thú vị về các hệ thống quản lý mã nguồn là mã nguồn chính được kiểm tra và lưu trữ trên ổ đĩa của mỗi lập trình viên — tôi chưa bao giờ nghe nói về một dự án sử dụng hệ thống quản lý mã nguồn mà mất mất nhiều mã nguồn đến vậy.

2. Bạn có thể tạo build chỉ trong một bước không?

Ý tôi là: cần bao nhiêu bước để tạo ra phiên bản cuối cùng từ bản mã nguồn mới nhất? Trong các đội ngũ xuất sắc, có một tập lệnh đơn bạn có thể chạy, thực hiện việc kiểm tra hoàn toàn từ đầu, xây dựng lại từng dòng mã, tạo ra các tệp thực thi (EXEs) ở tất cả các phiên bản, ngôn ngữ, và kết hợp #ifdef khác nhau, tạo gói cài đặt và tạo ra các phương tiện cuối cùng — bố trí CDROM, trang web tải xuống, hoặc bất kỳ điều gì khác.

Nếu quá trình này cần nhiều hơn một bước, nó sẽ dễ gây lỗi. Và khi bạn gần đến thời điểm xuất bản, bạn muốn có một chu trình sửa lỗi “cuối cùng” nhanh chóng, tạo ra các tệp thực thi cuối cùng, v.v. Nếu việc biên dịch mã mất 20 bước, chạy trình xây dựng cài đặt, v.v., bạn sẽ trở nên điên đảo và bạn sẽ mắc các lỗi ngớ ngẩn.

Chính vì lý do này, công ty cuối cùng mà tôi làm việc đã chuyển từ WISE sang InstallShield: chúng tôi đòi hỏi quá trình cài đặt có thể chạy từ một tập lệnh, tự động, qua đêm, sử dụng lịch trình NT, và WISE không thể chạy từ lịch trình qua đêm, vì vậy chúng tôi đã bỏ nó đi. (Các bạn tại WISE bảo đảm rằng phiên bản mới nhất của họ hỗ trợ việc xây dựng qua đêm.)

3. Bạn thường xuyên tạo build hàng ngày không?

Khi bạn sử dụng hệ thống quản lý mã nguồn, đôi khi một lập trình viên vô tình commit một điều gì đó làm hỏng quá trình xây dựng. Ví dụ, họ đã thêm một tệp nguồn mới và mọi thứ biên dịch bình thường trên máy của họ, nhưng họ quên thêm tệp nguồn đó vào kho mã nguồn. Vì vậy, họ khóa máy và về nhà, không để ý và hạnh phúc. Nhưng không ai khác có thể làm việc, vì vậy họ cũng phải về nhà, và họ không hạnh phúc.

Việc làm hỏng quá trình xây dựng là một việc tồi tệ (và thường gặp) đến nỗi việc tạo build hàng ngày giúp đảm bảo rằng không có lỗi nào bị bỏ qua. Trong các nhóm lớn, một cách tốt để đảm bảo rằng lỗi sẽ được sửa ngay lập tức là thực hiện việc xây dựng hàng ngày vào mỗi buổi chiều, ví dụ như vào lúc trưa. Mọi người sẽ commit càng nhiều mã càng tốt trước khi tới giờ trưa. Khi họ trở lại, quá trình xây dựng đã hoàn tất. Nếu nó hoạt động, tuyệt vời! Mọi người cập nhật phiên bản mới nhất của mã nguồn và tiếp tục làm việc. Nếu quá trình xây dựng thất bại, bạn sửa chữa nó, nhưng mọi người vẫn có thể tiếp tục làm việc với phiên bản mã nguồn trước khi xây dựng, không bị lỗi.

Trong đội ngũ Excel, chúng tôi có một quy tắc: ai là người làm hỏng quá trình xây dựng, như một “hình phạt”, phải chịu trách nhiệm giữ gìn quá trình xây dựng cho đến khi ai đó làm hỏng nó. Điều này là một động lực tốt để không làm hỏng quá trình xây dựng và cách tốt để lần lượt mọi người trải qua quy trình xây dựng để mọi người đều học cách nó hoạt động.

Đọc thêm về việc tạo build hàng ngày trong bài viết của tôi: “Daily Builds are Your Friend“.

4. Bạn có cơ sở dữ liệu lỗi không?

Tôi không quan tâm bạn nói gì. Nếu bạn đang phát triển mã nguồn, ngay cả khi chỉ là một người làm việc, mà không có một cơ sở dữ liệu tổ chức liệt kê tất cả các lỗi đã biết trong mã nguồn, bạn sẽ xuất bản mã nguồn chất lượng thấp. Nhiều lập trình viên nghĩ họ có thể nhớ danh sách lỗi trong đầu mình. Là lời nói vô nghĩa. Tôi không thể nhớ nhiều hơn hai hoặc ba lỗi một lúc, và vào buổi sáng hôm sau hoặc khi đang vội vã chuẩn bị xuất bản, chúng ta quên mất chúng. Bạn hoàn toàn phải theo dõi các lỗi một cách chính thức.

Cơ sở dữ liệu lỗi có thể phức tạp hoặc đơn giản. Một cơ sở dữ liệu lỗi hữu ích tối thiểu phải bao gồm các dữ liệu sau cho mỗi lỗi:

• Bước đầy đủ để tái hiện lỗi
• Hành vi dự kiến
• Hành vi quan sát (lỗi)
• Người được giao nhiệm vụ
• Lỗi đã được sửa hay chưa

Nếu độ phức tạp của phần mềm theo dõi lỗi là điều duy nhất ngăn cản bạn theo dõi lỗi, chỉ cần tạo một bảng đơn giản với 5 cột chính này và bắt đầu sử dụng nó.

Để biết thêm về việc theo dõi lỗi, đọc bài viết của tôi về “Painless Bug Tracking“.

5. Bạn sửa lỗi trước khi viết mã mới không?

Phiên bản đầu tiên của Microsoft Word cho Windows được coi là dự án “dành cho tử thần”. Nó kéo dài vô thời hạn. Dự án lúc nào cũng trễ tiến độ. Toàn bộ đội ngũ làm việc với những giờ làm việc phi lý, dự án bị trễ tiến độ điều này lặp đi lặp lại, và căng thẳng ngày càng tăng. Khi phiên bản cuối cùng được xuất bản, sau nhiều năm trễ tiến độ, Microsoft đã gửi cả đội ngũ đến Cancun để nghỉ mát, sau đó ngồi xuống để tự vấn tâm hồn một cách nghiêm túc.

Những gì họ nhận ra là các quản lý dự án đã ép buộc việc tuân thủ “lịch trình” đến mức mà các lập trình viên chỉ viết mã một cách vội vã, tạo ra mã rất kém chất lượng, vì giai đoạn sửa lỗi không được tính vào lịch trình chính thức. Không có nỗ lực để giữ số lỗi thấp. Ngược lại, câu chuyện được kể lại rằng một lập trình viên, người phải viết mã để tính chiều cao của một dòng văn bản, đơn giản viết “return 12;” và đợi báo cáo lỗi về cách hàm của anh ấy không luôn chính xác. Lịch trình chỉ là một danh sách các tính năng đang chờ đợi để biến thành lỗi. Trong quá trình tổng kết, điều này được gọi là “phương pháp vô số lỗi”.

Để sửa vấn đề này, Microsoft đã chấp nhận một phương pháp được gọi là “phương pháp không lỗi”. Nhiều lập trình viên trong công ty cười lớn, vì nó nghe có vẻ như là quản lý nghĩ họ có thể giảm số lỗi thông qua quyết định của ban lãnh đạo. Trên thực tế, “không lỗi” có nghĩa là vào bất kỳ thời điểm nào, ưu tiên hàng đầu là loại bỏ lỗi trước khi viết mã mới. Dưới đây là lý do tại sao.

Nói chung, bạn đợi lâu trước khi sửa một lỗi, chi phí (về thời gian và tiền bạc) để sửa lỗi đó càng lớn.

Ví dụ, khi bạn gặp lỗi đánh máy hoặc lỗi cú pháp mà trình biên dịch phát hiện, việc sửa chúng thực sự là chuyện dễ dàng.

Khi bạn gặp lỗi trong mã nguồn của bạn ngay từ lần chạy đầu tiên, bạn có thể sửa nó ngay lập tức, vì toàn bộ mã vẫn còn tươi mới trong tâm trí của bạn.

Nếu bạn phát hiện một lỗi trong mã nguồn mà bạn viết cách đây vài ngày, việc tìm lỗi đó sẽ mất một thời gian, nhưng khi bạn đọc lại mã bạn đã viết, bạn sẽ nhớ tất cả và bạn có thể sửa lỗi trong khoảng thời gian hợp lý.

Nhưng nếu bạn phát hiện một lỗi trong mã nguồn mà bạn viết cách đây vài tháng, bạn có thể đã quên nhiều điều về mã đó, và việc sửa lỗi trở nên khó khăn hơn nhiều. Đến thời điểm đó, bạn có thể đang sửa lỗi trong mã nguồn của người khác, và họ có thể đang ở Aruba nghỉ mát, trong trường hợp đó, việc sửa lỗi giống như một quy trình khoa học: bạn phải làm chậm, phương pháp và tỉ mỉ, và bạn không thể chắc chắn mất bao lâu để phát hiện ra giải pháp.

Và nếu bạn phát hiện một lỗi trong mã nguồn đã được xuất bản, bạn sẽ phải chi trả một số tiền không tưởng để sửa nó.

Đó chính là một lý do để sửa lỗi ngay lập tức: bởi vì việc sửa lỗi đó mất ít thời gian. Còn một lý do khác, liên quan đến việc dự đoán thời gian cần để viết mã mới so với việc sửa một lỗi hiện tại. 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ể đưa tôi một ước lượng khá tốt. Nhưng nếu tôi hỏi bạn làm thế nào để dự đoán mất bao lâu để sửa lỗi mà mã của bạn không hoạt động nếu đã cài đặt Internet Explorer 5.5, bạn không thể đoán được, vì bạn không biết (theo định nghĩa) nguyên nhân gây ra lỗi đó là gì. Có thể mất 3 ngày để theo dõi nó, hoặc có thể mất 2 phút.

Điều này có nghĩa là nếu bạn có một lịch trình với nhiều lỗi cần được sửa, lịch trình đó là không đáng tin cậy. Nhưng nếu bạn đã sửa tất cả các lỗi đã biết và chỉ còn lại mã mới, thì lịch trình của bạn sẽ chính xác đáng kinh ngạc hơn.

Một điều tuyệt vời khác khi giữ số lỗi ở mức không: bạn có thể phản ứng nhanh hơn đối với sự cạnh tranh. Một số lập trình viên nghĩ về điều này như việc giữ cho sản phẩm luôn sẵn sàng để xuất bản. Sau đó, nếu đối thủ của bạn giới thiệu một tính năng mới tuyệt vời đang ăn mòn khách hàng của bạn, bạn có thể chỉ cần triển khai tính năng đó và xuất bản ngay lập tức, mà không cần phải sửa một số lỗi tích luỹ lớn.

6. Bạn có một lịch trình cập nhật không?

Điều này dẫn chúng ta đến lịch trình. Nếu mã nguồn của bạn quan trọng đối với doanh nghiệp, có nhiều lý do tại sao việc biết khi nào mã nguồn sẽ hoàn thành là quan trọng đối với doanh nghiệp. Lập trình viên thường rất khó chịu khi phải đặt lịch trình. “Nó sẽ hoàn thành khi nó hoàn thành!” họ la ó với những người kinh doanh.

Thật không may, điều đó không đủ. Có quá nhiều quyết định lập kế hoạch mà doanh nghiệp cần phải đưa ra trước khi mã nguồn được xuất bản: các buổi trình diễn, hội chợ, quảng cáo, v.v. Và cách duy nhất để làm điều này là có một lịch trình và duy trì nó cập nhật.

Điều quan trọng khác về việc có lịch trình là nó buộc bạn phải quyết định những tính năng bạn sẽ thực hiện và sau đó nó buộc bạn phải chọn những tính năng ít quan trọng nhất và cắt chúng thay vì rơi vào tình trạng “thèm tính năng (featuritis)” (hay còn gọi là mở rộng phạm vi không kiểm soát).

Việc duy trì lịch trình không cần phải khó khăn. Đọc bài viết của tôi về Painless Software Schedules, mô tả cách đơn giản để tạo lịch trình tuyệt vời.

7. Bạn có một bản thiết kế không?

Việc viết bản thiết kế giống như việc đánh răng: mọi người đều đồng lòng rằng đó là điều tốt, nhưng không ai thực hiện.

Tôi không chắc tại sao điều này lại như vậy, nhưng có lẽ do hầu hết các lập trình viên ghét viết tài liệu. Kết quả là, khi các nhóm chỉ gồm các lập trình viên tấn công một vấn đề, họ thích diễn giải giải pháp của mình bằng mã nguồn, chứ không phải tài liệu. Họ muốn đào sâu và viết mã nguồn hơn là tạo ra một bản thiết kế trước.

Ở giai đoạn thiết kế, khi bạn phát hiện ra vấn đề, bạn có thể dễ dàng sửa chúng bằng cách chỉnh sửa vài dòng văn bản. Khi mã nguồn đã được viết, chi phí để sửa chữa các vấn đề tăng đáng kể, cảm xúc (mọi người không muốn vứt bỏ mã nguồn) và thời gian, vì vậy có sự chống đối đối với việc sửa chữa các vấn đề. Phần mềm không được xây dựng từ một bản thiết kế thường kết thúc với thiết kế kém và lịch trình mất kiểm soát. Điều này dường như là vấn đề tại Netscape, nơi bốn phiên bản đầu tiên trở nên hỗn loạn đến mức quản lý ngớ ngẩn quyết định vứt bỏ mã nguồn và bắt đầu lại từ đầu. Và rồi họ lại phạm sai lầm này ở Mozilla, tạo ra một quái vật trở nên không kiểm soát và mất vài năm để đạt đến giai đoạn alpha.

Lý thuyết cá nhân của tôi là vấn đề này có thể được giải quyết bằng cách dạy lập trình viên ít từ bi về viết bằng cách đưa họ tham gia một khóa học viết sâu rộng. Một giải pháp khác là thuê quản lý dự án thông minh để tạo ra bản thiết kế. Trong cả hai trường hợp, bạn nên tuân thủ quy tắc đơn giản “không có mã nguồn nếu không có bản thiết kế”.

Tìm hiểu tất cả về việc viết bản thiết kế bằng cách đọc chuỗi bài viết của tôi trong loạt bài 4 phần của tôi.

8. Có điều kiện làm việc yên tĩnh cho lập trình viên không?

Có rất nhiều nghiên cứu đã chứng minh rằng việc cung cấp không gian, yên tĩnh và riêng tư làm tăng hiệu suất cho những người làm công việc tri thức. Cuốn sách quản lý phần mềm kinh điển Peopleware đã rộng rãi ghi chép những lợi ích về hiệu suất này.

Đây là vấn đề. Chúng ta đều biết rằng những người làm công việc tri thức làm việc tốt nhất khi họ đang “trong dòng chảy” (flow), nơi họ tập trung hoàn toàn vào công việc của họ và hoàn toàn loại trừ môi trường xung quanh. Họ mất khả năng đánh giá thời gian và tạo ra những sản phẩm xuất sắc thông qua sự tập trung tuyệt đối. Đây chính là lúc họ hoàn thành được công việc hiệu quả của mình. Người viết, lập trình viên, nhà khoa học và ngay cả các cầu thủ bóng rổ sẽ kể về việc “trong dòng chảy” (flow).

Vấn đề ở đây là, việc bắt đầu “trong dòng chảy” (flow) không dễ dàng. Khi bạn cố gắng đánh giá nó, nó mất khoảng 15 phút trung bình để bắt đầu làm việc với hiệu suất tối đa. Đôi khi, nếu bạn mệt mỏi hoặc đã thực hiện nhiều công việc sáng tạo trong ngày, bạn không thể vào “trong dòng chảy” (flow) và bạn sẽ dành phần còn lại của ngày làm việc để lảng vảng, đọc web, chơi Tetris.

Vấn đề khác là việc bị loại khỏi “dòng chảy”. Tiếng ồn, cuộc gọi điện thoại, ra ngoài ăn trưa, phải lái xe 5 phút đến Starbucks mua cà phê và sự gián đoạn từ đồng nghiệp — đặc biệt là sự gián đoạn từ đồng nghiệp — tất cả khiến bạn bị loại khỏi “dòng chảy”. Nếu một đồng nghiệp hỏi bạn một câu hỏi, gây ra gián đoạn 1 phút, nhưng điều này làm bạn rơi khỏi “dòng chảy” đến mức mất 30 phút để trở nên hiệu quả lại, tổng hiệu suất của bạn sẽ gặp vấn đề nghiêm trọng. Nếu bạn đang làm việc trong một môi trường ồn ào như những công ty “dotcom” thích tạo ra, với các chuyên viên tiếp thị ồn ào trên điện thoại bên cạnh lập trình viên, hiệu suất của bạn sẽ giảm sút khi những người làm công việc tri thức bị gián đoạn lần lượt và không bao giờ vào “trong dòng chảy”.

Với lập trình viên, điều này càng khó khăn. Hiệu suất phụ thuộc vào việc có thể điều chỉnh nhiều chi tiết nhỏ trong bộ nhớ ngắn hạn một lúc. Bất kỳ loại gián đoạn nào cũng có thể làm cho những chi tiết này sụp đổ. Khi bạn tiếp tục công việc, bạn không thể nhớ bất kỳ chi tiết nào (như tên biến cục bộ bạn đang sử dụng hoặc bạn đang ở đâu trong việc triển khai thuật toán tìm kiếm) và bạn phải tiếp tục tìm kiếm những điều này, điều này làm chậm bạn đến mức bạn mất thời gian đáng kể cho đến khi bạn quen với tốc độ ban đầu.

Dưới đây là phép toán đơn giản. Hãy giả sử (như những bằng chứng dường như ngụ ý) rằng nếu chúng ta gián đoạn một lập trình viên, ngay cả trong một phút, thì chúng ta đang thực sự làm mất đi 15 phút hiệu suất. Ví dụ này, hãy đặt hai lập trình viên, Jeff và Mutt, trong các văn phòng mở cùng nhau trong một trang trại vỗ béo bê Dilbert tiêu chuẩn. Mutt không thể nhớ tên của hàm strcpy phiên bản Unicode. Anh ấy có thể tìm kiếm nó, mất 30 giây, hoặc anh ấy có thể hỏi Jeff, mất 15 giây. Vì anh ấy ngồi ngay bên cạnh Jeff, anh ấy hỏi Jeff. Jeff bị phân tâm và mất 15 phút hiệu suất (để tiết kiệm cho Mutt 15 giây).

Bây giờ hãy chuyển họ vào các văn phòng riêng biệt với tường và cửa. Bây giờ khi Mutt không thể nhớ tên của hàm đó, anh ấy có thể tìm kiếm nó, vẫn mất 30 giây, hoặc anh ấy có thể hỏi Jeff, điều này giờ đây mất 45 giây và bao gồm việc đứng dậy (không phải nhiệm vụ dễ dàng đối với sức khỏe trung bình của lập trình viên!). Vì vậy anh ấy tìm kiếm nó. Vì vậy giờ đây Mutt mất 30 giây hiệu suất, nhưng chúng ta tiết kiệm 15 phút của Jeff. Ahhh!

9. Bạn sử dụng những công cụ tốt nhất có thể mua được không?

Viết mã trong một ngôn ngữ biên dịch là một trong những công việc cuối cùng mà máy tính cá nhân phổ thông hiện nay vẫn không thể thực hiện ngay lập tức. Nếu quá trình biên dịch của bạn mất nhiều giây đến chục giây, việc sở hữu máy tính mới nhất và tốt nhất sẽ giúp bạn tiết kiệm thời gian. Nếu việc biên dịch mất 15 giây, lập trình viên sẽ chán chường khi trình biên dịch chạy và chuyển sang đọc The Onion, điều này sẽ cuốn họ vào và làm mất hàng giờ năng suất làm việc.

Sửa lỗi mã GUI trên một hệ thống chỉ có một màn hình là đau đớn, nếu không nói là không thể thực hiện. Nếu bạn viết mã GUI, hai màn hình sẽ làm mọi thứ dễ dàng hơn nhiều.

Hầu hết các lập trình viên cuối cùng đều phải thao tác các hình ảnh bitmap cho các biểu tượng hoặc thanh công cụ, và hầu hết các lập trình viên không có một chương trình chỉnh sửa hình ảnh bitmap tốt. Cố gắng sử dụng Microsoft Paint để chỉnh sửa hình ảnh bitmap là một trò đùa, nhưng đó lại là điều mà hầu hết các lập trình viên phải làm.

Ở công việc trước đó của tôi, quản trị hệ thống liên tục gửi cho tôi thư rác tự động khiếu nại rằng tôi đang sử dụng hơn… nghe cái này… 220 megabyte không gian đĩa cứng trên máy chủ. Tôi chỉ ra rằng với giá của ổ cứng ngày nay, chi phí cho không gian này thấp hơn đáng kể so với chi phí của cuộn giấy vệ sinh tôi sử dụng. Dành thậm chí chỉ 10 phút để dọn dẹp thư mục của tôi sẽ là một lãng phí năng suất đáng kinh ngạc.

Những đội ngũ phát triển hàng đầu không làm đau nhức lập trình viên của họ. Ngay cả những phiền toái nhỏ do sử dụng các công cụ không đủ mạnh mẽ cũng tích tụ, khiến lập trình viên trở nên cáu kỉnh và không hạnh phúc. Và một lập trình viên cáu kỉnh là một lập trình viên không hiệu quả.

Thêm vào đó… lập trình viên rất dễ bị hối lộ bằng cách cho họ những thứ mới nhất và hấp dẫn nhất. Điều này là một cách rẻ tiền hơn để thu hút họ làm việc cho bạn so với việc trả lương cạnh tranh thực sự!

10. Bạn có những người kiểm thử không?

Nếu đội của bạn không có người kiểm thử chuyên nghiệp, ít nhất là một người cho mỗi hai hoặc ba lập trình viên, bạn đang hoặc đang sản xuất ra các sản phẩm lỗi hoặc bạn đang lãng phí tiền bạc bằng cách làm cho những lập trình viên có giá 100 đô la/giờ thực hiện công việc mà có thể được thực hiện bởi những người kiểm thử có giá 30 đô la/giờ. Tiết kiệm chi phí cho việc kiểm thử là một kinh tế giả tưởng sai lầm đến mức độ khiến tôi đơn giản là kinh ngạc vì tại sao không có nhiều người nhận thức được điều này.

Đọc bài viết Top Five (Wrong) Reasons You Don’t Have Testers, một bài viết mà tôi đã viết về chủ đề này.

11. Ứng viên mới có viết mã trong buổi phỏng vấn không?

Bạn có thuê một nhà ảo thuật mà không yêu cầu họ thể hiện một số màn ảo thuật không? Chắc chắn là không.

Bạn có thuê một đầu bếp nấu ăn cho đám cưới của bạn mà không thử thức thức ăn của họ không? Tôi nghi ngờ điều đó. (Trừ khi đó là Cô Marge, và cô ấy sẽ oánh bạn mãi mãi nếu bạn không để cho cô ấy làm chiếc bánh mứt gan “nổi tiếng” của mình).

Tuy nhiên, mỗi ngày, các lập trình viên được thuê dựa trên một bản hồ sơ ấn tượng hoặc vì người phỏng vấn thích trò chuyện với họ. Hoặc họ bị hỏi các câu hỏi về kiến thức chung (“sự khác biệt giữa CreateDialog() và DialogBox() là gì?”) mà có thể được trả lời bằng cách xem tài liệu. Bạn không quan tâm họ có ghi nhớ hàng nghìn câu hỏi về lập trình hay không, bạn quan tâm họ có thể viết mã không. Hoặc còn tồi tệ hơn, họ bị hỏi các câu hỏi kiểu “AHA!”: những câu hỏi dường như dễ dàng khi bạn biết câu trả lời, nhưng nếu bạn không biết câu trả lời, chúng là không thể.

Làm ơn, hãy dừng việc làm này. Làm bất cứ điều gì bạn muốn trong quá trình phỏng vấn, nhưng hãy yêu cầu ứng viên viết mã. (Để biết thêm lời khuyên, hãy đọc The Guerrilla Guide to Interviewing của tôi.)

12. Bạn có thực hiện kiểm tra tính sử dụng bằng cách sử dụng người dùng ngẫu nhiên ở hành lang không?

Một cuộc kiểm tra tính sử dụng tại hành lang là khi bạn chộp lấy người tiếp theo đi qua ở hành lang và ép họ thử sử dụng mã bạn vừa viết. Nếu bạn làm điều này với năm người, bạn sẽ tìm hiểu được 95% về các vấn đề về tính sử dụng trong mã của bạn.

Thiết kế giao diện người dùng tốt không khó như bạn nghĩ, và nó quan trọng nếu bạn muốn khách hàng yêu thích và mua sản phẩm của bạn. Bạn có thể đọc cuốn sách trực tuyến miễn phí của tôi về thiết kế giao diện người dùng, một hướng dẫn ngắn cho các 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 cho thấy chương trình của mình cho một nhóm nhỏ người, (thực sự, chỉ cần năm hoặc sáu người là đủ) bạn sẽ nhanh chóng phát hiện ra các vấn đề lớn mà người dùng đang gặp phải. Đọc bài viết của Jakob Nielsen giải thích vì sao điều này quan trọng. Ngay cả khi kỹ năng thiết kế giao diện của bạn kém, miễn là bạn buộc bản thân phải thực hiện các kiểm tra tính sử dụng tại hành lang, điều này không tốn kém gì, giao diện người dùng của bạn sẽ tốt hơn rất nhiều.