Làm thế nào để bạn xác định chất lượng của mã nhà tuyển dụng tiềm năng trước khi bạn đảm nhận vị trí này? [đóng cửa]

Theo kinh nghiệm của tôi trước khi bạn bắt đầu làm việc cho một công ty, bạn không có cơ hội xem xét cơ sở mã (tôi đã hỏi và vì lý do bảo mật, mọi người luôn nói không, tôi nghĩ đó là công bằng), vì vậy trong quá trình phỏng vấn Bạn có nghĩ rằng những câu hỏi quan trọng nhất cần đặt ra để tìm hiểu loại mã nào trong đó (rốt cuộc, nếu đó là một con chó, thì bạn sẽ gặp phải những người không may nghèo phải đi bộ mỗi ngày)?

CẬP NHẬT:

Một danh sách kiểm tra: Hỏi;

• Có gì họ nghĩ về codebase. Và khi bạn làm, hãy chú ý đến biểu cảm trên khuôn mặt và thời gian cần thiết để họ phản hồi. [Anon]
• Cấp CMM của công ty [DPD] là gì (và nếu bạn nghe thấy Cấp 5 chạy theo cách khác [Doug T])
• Họ sử dụng vòng đời nào [DPD] (Và nếu bạn nghe thấy "Agile", đó là khi bạn bắt đầu hỏi một số câu hỏi thâm nhập để cố gắng tìm hiểu xem "Agile" có nghĩa là "Agile hay" mã hóa cao bồi "[Carson63000])
• Những công cụ họ sử dụng để khẳng định chất lượng mã? [DPD]
• Những công cụ họ sử dụng để phát triển? [DPD] (Tìm kiếm các công cụ tái cấu trúc và máy chủ xây dựng liên tục)
• Họ sử dụng hệ thống mã nguồn (kiểm soát phiên bản) nào và theo dõi tốt là hỏi tại sao họ sử dụng nó. [Zachary K].
• Thủ tục kiểm tra của họ như thế nào? [Karl Bielefeldt] (Đặc biệt là các đội sử dụng các khung mô phỏng và nhấn mạnh vào kiểm tra đơn vị tự động kỹ lưỡng thông qua các khung được thiết lập như NUnit / JUnit; đừng bỏ qua các nhóm không sử dụng TDD phát triển theo hướng kiểm tra, nhưng hãy cảnh giác nếu họ không coi việc kiểm thử là không thể thiếu và là nền tảng của sự phát triển phần mềm vững chắc. Hãy tìm các nhóm có người kiểm thử chuyên dụng.)
• Những loại bài tập nào được trao cho các nhà phát triển mới? Để các nhà phát triển có kinh nghiệm? [Karl Bielefeldt]
• Có bao nhiêu người làm việc trong một dự án? [Karl Bielefeldt]
• Tái cấu trúc có được phép không? Khuyến khích? [Karl Bielefeldt]
• Những thay đổi liên quan đến chất lượng hoặc kiến ​​trúc đang được xem xét hoặc đã được thực hiện gần đây? [Karl Bielefeldt]
• Các cá nhân có bao nhiêu quyền tự chủ đối với các mô-đun của họ? [Karl Bielefeldt]
• Bạn sẽ phát triển các dự án mới hơn (phát triển trường xanh) hay các dự án cũ (phát triển trường nâu)? (Phát triển Greenfield thường vui hơn và có ít vấn đề hơn khi bạn không dọn dẹp những sai lầm của người khác).
• Là tỷ lệ doanh thu nhân viên cao trong tổ chức hoặc nhóm? (Điều này thường cho thấy chất lượng mã thấp hơn) [M.Sameer]
• Một số vấn đề lập trình của riêng bạn; nhưng tránh có vẻ như một jerk. [Lấp lánh]
• Làm thế nào để các nhà phát triển hợp tác và kiến ​​thức được chia sẻ giữa các nhóm như thế nào? (Điều này phù hợp với tính cách của bạn; tôi sẽ nói rằng sự kết hợp giữa hoạt động solo và ghép đôi có lẽ là tốt nhất, với tỷ lệ phù hợp với nhu cầu xã hội của bạn)
• Làm thế nào gần cơ sở dữ liệu của họ với Mẫu thường thứ 3 (3NF), và nếu nó lệch ở đâu và tại sao? (Nếu họ nói "3NF ???", hãy rời đi. Nếu không, và có thể có lý do chính đáng cho việc đó không, sau đó tìm hiểu xem họ là gì).

LƯU Ý: Tôi đã chấp nhận câu trả lời của Anon vì sau khoảng một tuần, cộng đồng nghĩ rằng đó là câu trả lời hay nhất - tôi nghĩ điều này cho thấy rằng đó chỉ là thứ mà bạn cần phải phát triển giác quan thứ sáu. Nhưng, tôi nghĩ rằng tất cả mọi người đã có một cái gì đó có giá trị để nói.

Thay vì yêu cầu xem mã của họ, hãy hỏi họ nghĩ gì về cơ sở mã. Và khi bạn làm, hãy chú ý đến biểu cảm trên khuôn mặt và thời gian cần thiết để họ phản hồi.

Sau đó, áp dụng kiến ​​thức của bạn về cử chỉ phi ngôn ngữ của văn hóa của bạn để diễn giải những gì họ thực sự nói. Đối với một công ty Bắc Mỹ, những điều sau đây phải chính xác:

• Một cái nhún vai nhỏ, và phản ứng nhanh của "nó có thể tốt hơn": nó có thể khá tốt.
• Một khoảng dừng dài, hít thở, có lẽ là một tiếng cười nhỏ: thật không dễ chịu gì, và những người mà bạn đang phỏng vấn không cảm thấy thoải mái khi nói với bạn điều đó.
• Đôi mắt tròn xoe, phản ứng nhanh của "nó hút": có thể tốt, có thể xấu, nhưng có những trò chơi chính trị đang diễn ra. Trừ khi bạn sẵn sàng chơi trò chơi đó hoặc là một người im lặng, hãy tránh xa.
• Lông mày mọc lên hoặc co lại: họ không hiểu câu hỏi và codebase gần như chắc chắn bị thối rữa.

Tất nhiên, nếu bạn gặp rắc rối với giao tiếp giữa các cá nhân, điều này có thể không phù hợp với bạn.

Tôi ngạc nhiên khi bạn thậm chí đã hỏi. Không có công ty nào sẽ cho bạn thấy mã trước khi bạn tham gia. Thậm chí không cho các chuyên gia tư vấn được gọi trong quá trình, trừ khi họ đã ký một thỏa thuận bảo mật.

Đây là những gì bạn có thể yêu cầu để tìm hiểu.

• Cấp độ CMM của công ty là gì (lý tưởng là 5)
• Quá trình được thực hiện trong dự án tiềm năng của bạn là gì (BTW, yêu cầu điều này là tốt bởi vì nó cho thấy bạn quan tâm đến công việc "này" chứ không phải bất kỳ công việc nào)
• Họ sử dụng vòng đời nào (Đừng phán xét nếu bạn không nghe thấy "Agile". Họ có thể có lý do hợp lệ để sử dụng các mô hình trường học cũ)
• Hỏi xem họ có sử dụng bất kỳ công cụ và số liệu nào để kiểm tra chất lượng mã không. Và nếu có cái nào (nếu họ sử dụng ít nhất một công cụ cho số liệu và một công cụ khác cho chất lượng thì đó là một dấu hiệu tốt.)
• Cũng lưu ý những công cụ họ sử dụng. Nếu nó là một công cụ đắt tiền như Resharper thay vì một số công cụ phần mềm miễn phí thì chúng thực sự nghiêm trọng về chất lượng.

1. Hỏi họ nếu họ sử dụng kiểm soát nguồn.
   • Không kiểm soát nguồn? -> mã rất có thể shitty
2. Hỏi họ tần suất làm mã đánh giá.
   • Không xem lại mã? -> mã có thể bị nghi ngờ (nhưng không nhất thiết phải như vậy, đặc biệt nếu đó là một nhóm nhỏ được tạo thành từ các nhà phát triển phong nha.)
3. Hỏi họ xem họ đã thử nghiệm và triển khai như thế nào trước khi đi vào sản xuất?
   • Không có môi trường thử nghiệm? Triển khai trực tiếp vào sản xuất? -> mã rất có thể shitty.
4. Hỏi họ nếu họ thực hiện tích hợp liên tục (.ie. Chạy bản dựng với Hudson)
   • Không tích hợp liên tục? -> mã có thể bị nghi ngờ, nhưng không nhất thiết phải như vậy.
5. (Liên quan đến # 3), hãy hỏi họ xem môi trường thử nghiệm của họ có tách biệt với môi trường phát triển của bạn không?
   • Kiểm tra là dev? -> không phải là một dấu hiệu tốt, trừ khi chúng thực sự bị thiếu tiền mặt, nhưng một hộp thêm sẽ đắt đến mức nào?
6. Hỏi họ nếu họ xem lại một danh sách hành động trước khi triển khai vào sản xuất.
   • Không xem xét lại các hành động trước khi triển khai sản xuất? -> juju xấu.
7. Hỏi họ cần bao nhiêu bước để họ thực hiện việc xây dựng.
   • Hơn 3? -> điển hình là juju xấu.
8. Do họ lấy (hoặc dự đoán) các số liệu mã như độ phức tạp chu kỳ hoặc LCOM (thước đo sự gắn kết của lớp).
   • Vâng? -> có lẽ (nhưng không chắc chắn) một dấu hiệu tốt về chất lượng mã của họ.
   • Không, nhưng họ hiểu các khái niệm (ít nhất là độ phức tạp chu kỳ)? -> khó nói
   • Họ nghĩ rằng sự phức tạp theo chu kỳ là một món ăn kỳ lạ hoặc thuốc kích thích tình dục từ Timbuktu (nói cách khác, họ không biết đó là gì)? -> juju xấu có thể.
   • Họ nghĩ rằng đó là shit không liên quan (hoặc một số hành động khác của loại)? -> chạy đi.
9. Hỏi họ làm thế nào để theo dõi các lỗi.
   • Họ theo dõi # lỗi đối với một số số liệu (.ie. Mỗi dự án, số lượng mô-đun thay đổi hoặc số lượng yêu cầu / yêu cầu thay đổi, một cái gì đó!)? -> dấu hiệu tốt về mã của họ (và quy trình phần mềm của họ).
   • Họ thực hiện một trong những điều trên và cố gắng dự đoán số lượng lỗi có thể gặp phải trong một dự án trong tương lai (hoặc đang diễn ra) dựa trên một số liệu dự kiến ​​(# yêu cầu thay đổi, quy mô dự án, v.v.)? -> dấu hiệu rất tốt.
   • Họ theo dõi lỗi chỉ để giải quyết lỗi? -> khó nói
   • Không theo dõi nhất quán? -> chạy đi.

Đó là từ đỉnh đầu của tôi. Bạn sẽ nhận thấy rằng một số câu hỏi của tôi liên quan đến quá trình phát triển phần mềm, và không chỉ nghiêm túc về mã hóa. Chất lượng của cái sau là một chức năng trực tiếp của chất lượng của cái trước.

Như đã nói, khi bạn hỏi những câu hỏi này, hãy tiến hành thận trọng. Nghiên cứu chúng và chọn một vài tại thời điểm một cuộc phỏng vấn.

Một vài điều bạn nên ghi nhớ. Một nhóm phát triển tốt sẽ rất vui khi nghe một người được phỏng vấn hỏi những câu hỏi này ... miễn là họ được hỏi một cách khéo léo. Làm sai, và bạn sẽ tạo cho người phỏng vấn ấn tượng về sự kiêu ngạo và cầu toàn. Cho dù một nhóm phát triển giỏi đến đâu, không có nhóm nào hoàn hảo và tất cả họ đều có vấn đề cần giải quyết, thỏa hiệp về chất lượng và như vậy. Họ muốn một cầu thủ đội bóng có phẩm chất, không phải là người cầu toàn. Vì vậy, hãy cẩn thận.

Ngoài ra, có thể có trường hợp bạn có một nhóm người tốt mà trong hoàn cảnh bên ngoài phải làm việc với mã có chất lượng phụ (họ có thể là nhà phát triển cơ sở hoặc đơn giản là họ thừa hưởng một đống rác mà bây giờ họ phải làm việc với giới hạn tài nguyên dành cho việc cải thiện chất lượng.) Bạn có thể làm việc với mã shitty và vẫn có kinh nghiệm làm việc tốt nếu những người xung quanh bạn cũng là người tốt (cả cá nhân và chuyên nghiệp). Tạo cho họ ấn tượng sai khi bạn đặt câu hỏi và họ có thể tránh việc thuê bạn hoàn toàn (cướp đi cơ hội làm việc với những người tốt trong một tình huống rất khó khăn và đầy thách thức.)

• Tuy nhiên, tôi hoàn toàn tin tưởng rằng một nhà phát triển phần mềm phải làm việc ít nhất một lần với một loại mã vượt quá hy vọng (hoặc gần ngoài hy vọng). Bạn tồn tại điều đó và làm một công việc tốt, đó là một bài học quý giá.

Bạn cũng có thể gặp phải một nhóm phát triển shitty với những người shitty. Rõ ràng sau đó, mã của họ sẽ rất tệ, và họ sẽ bỏ qua bất kỳ câu hỏi nào trong số này. Họ có thể coi thường bạn vì đã hỏi họ những câu hỏi khó (và do đó có thể giúp đỡ bạn), hoặc họ sẽ thuê bạn vì họ cần bạn (ngay cả khi họ không / sẽ không thể làm việc với bạn.)

Khi điều đó xảy ra, sau đó bạn phải tự hỏi liệu bạn có cần công việc này xấu không. Đôi khi bạn làm, và bạn phải lao vào một đống mỳ spaghetti. Đôi khi bạn không (có nghĩa là, bạn có thể không đủ khả năng.)

Đó là những điều bạn cần xem xét khi / nếu bạn chọn hỏi người phỏng vấn về chất lượng mã và quy trình phần mềm của họ.

Thay vì chất lượng mã thực tế, tôi muốn tìm một công ty nơi tầm quan trọng của chất lượng mã được hiểu rõ.

Ví dụ: giả sử công ty A có các nhà quản lý tin rằng "lập kế hoạch là lãng phí thời gian" và "chúng ta có thể khắc phục các sự cố thiết kế sau này (ví dụ: khi địa ngục đóng băng. Chúng ta sẽ có thời gian)". Ngay cả khi công ty đó tình cờ có một cơ sở mã tốt bây giờ, họ sẽ không có nó lâu dài. Và bạn sẽ là người sẽ (bị ép buộc) làm cho nó tồi tệ hơn.

Mặt khác, giả sử công ty B có cơ sở mã xấu, nhưng ban quản lý hiểu rằng chất lượng mã đang gây ra tất cả các lỗi và sự chậm trễ, họ thấy cần phải thay đổi và họ sẵn sàng làm điều gì đó (ví dụ: quy mô lớn tái cấu trúc hoặc thậm chí viết lại). Công ty đó sẽ cải thiện cơ sở mã của mình và bạn có thể giúp họ thực hiện điều đó.

Tôi biết nơi tôi muốn làm việc.

Có 99,9% cơ hội bạn sẽ không thể xem mã trước khi bắt đầu. (Tất nhiên trừ khi họ đưa ra sản phẩm phần mềm miễn phí)

Vì vậy, những gì bạn có thể làm, tôi sẽ hỏi về quá trình, nói chung quá trình tốt sẽ tạo ra mã tốt. Tôi sẽ bắt đầu với bài kiểm tra Joel và hỏi về phương pháp phát triển. Cũng vượt ra ngoài những điều cơ bản. Ví dụ, tôi luôn hỏi họ sử dụng hệ thống mã nguồn nào, vì vậy, theo dõi tốt là hỏi tại sao họ sử dụng nó.

Nơi tôi làm việc với mã chất lượng rất cao về cơ bản không cho phép hai phần ba các nhà phát triển chạm vào mã. Những người khác đã viết kịch bản kiểm tra hộp đen tự động thay thế. Nếu bạn chứng tỏ mình xứng đáng với việc thay đổi mã thực tế, thì các yêu cầu cực kỳ quá cụ thể đến nỗi về cơ bản nó không có gì khác hơn là phiên âm thành mã nguồn. Các kịch bản thử nghiệm đã thực sự thú vị hơn để viết.

Những nơi tôi đã thấy mã chất lượng thấp nhất hoàn toàn ngược lại: chỉ những lập trình viên tương đối chưa được đào tạo hoặc chưa được kiểm tra mới chạm vào mã, thường là vì đó là công cụ không liên quan trực tiếp đến sản phẩm của công ty hoặc được coi là thử nghiệm.

Những nơi dễ chịu nhất để làm việc có một sự cân bằng. Các nhà phát triển mới được giao nhiệm vụ thực sự, nhưng được cố vấn. Có một bộ phận QA tốt và quy trình đánh giá ngang hàng để bắt lỗi của bạn. Bạn không bị trừng phạt vì đã phạm sai lầm, nhưng dự kiến ​​sẽ sửa chúng và học hỏi từ chúng. Đôi khi, một mô-đun được viết xấu rơi vào các vết nứt, nhưng bạn không bị chỉ trích vì đã dành thời gian cải thiện chất lượng mã khi bạn gặp những thứ đó. Công ty nói chung đang tiếp tục phấn đấu để tìm ra những cách mới để làm cho mã tốt hơn.

Do đó, các câu hỏi tôi sẽ hỏi để đánh giá chất lượng mã là:

• Thủ tục kiểm tra của bạn như thế nào?
• Những loại bài tập nào được trao cho các nhà phát triển mới? Để các nhà phát triển có kinh nghiệm?
• Có bao nhiêu người làm việc trong một dự án?
• Tái cấu trúc có được phép không? Khuyến khích?
• Những thay đổi liên quan đến chất lượng hoặc kiến ​​trúc đang được xem xét hoặc đã được thực hiện gần đây?
• Các cá nhân có bao nhiêu quyền tự chủ đối với các mô-đun của họ?

Như @DPD và @Zachary đã nói, quy trình và SDLC là các yếu tố rất quan trọng nhưng tôi muốn thêm một số yếu tố khác mà theo kinh nghiệm của tôi có tác động đáng kể đến chất lượng mã:

• Hỏi xem bạn sẽ làm việc trong sự phát triển trong một dự án tương đối mới hơn hay trong việc duy trì ứng dụng cũ. Các ứng dụng kế thừa có xu hướng ít sạch hơn dự án mới hơn.
• Hãy thử để biết nếu tỷ lệ doanh thu của nhân viên cao trong tổ chức hoặc nhóm. Điều này rất có thể sẽ làm giảm chất lượng của mã là tốt.

Lưu ý rằng một quy trình sẽ giúp ích rất nhiều nhưng nó sẽ không cung cấp miễn dịch hoàn toàn cho các yếu tố trên. Khi nhiều nhà phát triển vượt qua một dự án, mỗi người đi kèm với một suy nghĩ khác nhau. Kiến trúc sư và nhà phát triển sẽ không tuân theo cách chính xác mà người tiền nhiệm của họ đã làm sẽ dẫn đến một số mâu thuẫn.

Thái độ của tôi là thế này, mã là mã, nếu nó xấu, thì đó là một thách thức để làm cho nó tốt hơn. Nếu nó tốt, thì đó là một thử thách khó khăn hơn để làm cho nó tốt hơn!

Quan trọng nhất đối với tôi là liệu tôi có muốn làm việc cho công ty và những người mà tôi có cơ hội tiếp xúc hay không. Mã có thể được thay đổi, mọi người không thể ...

Tôi nói đùa một chút, phỏng vấn tôi .

Tôi thường sử dụng một lỗi thực tế (đã được sửa) trong cơ sở mã của chúng tôi làm bài kiểm tra phỏng vấn, vì vậy bạn thấy một số mã thực tế. Nói chung mã hơi phức tạp, và nó có một lỗi trong đó.

Tôi khuyến khích tất cả mọi người sử dụng kỹ thuật này, vì bạn đã biết lỗi là có thật, vấn đề là có thật và bạn biết phải mất bao lâu để tìm và sửa.

Điều tuyệt vời là bạn có thể có một vấn đề khó đo lường.

Tôi đã sử dụng một vấn đề rất khó khăn như một câu hỏi phỏng vấn cuối cùng để tách các chuyên gia khỏi khá tốt.

Sự liên quan đến câu hỏi của OP là mọi người tham gia phỏng vấn thực tế đều được xem một số mã. (Không phải bất cứ điều gì với nội dung bí mật của công ty)

Nếu bạn không thể sử dụng kỹ thuật này, do nói, những lời tục tĩu trong cơ sở mã, thì thử nghiệm sẽ hoạt động, vì các nhân viên tương lai sẽ hỏi "tôi có thể xem mã không" và câu trả lời sẽ là "ồ, bạn không thể đầy thô tục ".

Tất nhiên, câu trả lời tiêu chuẩn "tất cả là bí mật của công ty" là tổng số ngựa-puckey.
Bằng chứng của tôi: tại nhà tuyển dụng trước đây của tôi, một phần không bảo mật của sản phẩm quân sự là mẫu mã cho câu hỏi phỏng vấn. [May mắn không được phân loại]

Tôi để lại vấn đề xác định chất lượng của các thiết kế được phân loại trước khi làm việc ở đó với một người thông minh hơn tôi. Tôi đề nghị có thể phổ biến rằng phân loại đồng nghĩa với miễn phí giám sát.

Nghi ngờ rằng họ sẽ cho bạn xem mã của họ, nhưng bạn có thể biết được ý tưởng của nó sẽ như thế nào nếu bạn giao cho họ bài tập về nhà lập trình. Nhiều nơi cung cấp cho người được phỏng vấn một bài tập lập trình mang về nhà mà họ có thể sử dụng để đánh giá bạn. Trả lại sự ủng hộ - mong đợi một trong số họ để bạn có thể đánh giá tốt hơn những gì bạn có thể nhận được cho mình.

Hỏi những gì cần thiết cho mã để đưa nó vào bản dựng sản xuất. Nếu bạn nhận được 'uhh ... nhà phát triển cam kết ...' thì đó gần như chắc chắn là rác.

Có một số điều có xu hướng tăng chất lượng mã (rõ ràng, không có gì đảm bảo).

• Phân tích tĩnh (trong .NET đây là những thứ như fxcop / stylecop)
• Một tập hợp con (hoặc bộ đầy đủ) của bộ kiểm tra - đơn vị / tích hợp / hồi quy / hướng dẫn, v.v.
• Xây dựng Buddy (một nhà phát triển khác trong nhóm xây dựng các thay đổi để xem liệu có bất kỳ vấn đề nào phụ thuộc vào máy / người dùng hay không - đôi khi cũng chạy rất nhanh)
• Đánh giá mã

Những điều này có thể giúp cải thiện, không chỉ sức mạnh của mã, mà cả chất lượng của mã.

Hỏi họ về thử nghiệm đơn vị. Nếu họ nghiêm túc thực hiện, thì người phỏng vấn có thể sẽ có một số ý kiến ​​nhất định về chủ đề này, và sẽ vui mừng chia sẻ chúng. Nếu câu trả lời mơ hồ, đó là một dấu hiệu cảnh báo lớn.

Nếu đó là cửa hàng Java, hãy hỏi họ thư viện ORM nào họ đang sử dụng. Nếu họ đã tự lăn, thì nó có thể đi theo bất kỳ cách nào - nó có thể hút hoặc nó có thể ổn. Nếu họ không sử dụng bất kỳ, hãy chạy ra cửa ngay.

Đây là một nhiệm vụ khó khăn vì có rất nhiều thực tiễn mã hóa xấu khác nhau, mà bạn sẽ không bao giờ có thể dự đoán được tất cả chúng.

Thật không may, bạn không thể. Không có công ty nào cho phép bạn xem mã của họ (nhưng họ sẽ yêu cầu xem mã CỦA BẠN ...), và rất có thể nếu bạn hỏi họ câu hỏi về môi trường, bạn sẽ hoàn toàn bị lừa dối ("Kiểm soát phiên bản? Chắc chắn .. chúng tôi sử dụng .. uhh .. suy nghĩ Sub .. Sub-Something ") hoặc hiểu sai về chất lượng (" Chúng tôi đang sử dụng .NET 4 mới nhất và tốt nhất "chỉ để biết rằng trong khi họ đang sử dụng .NET 4, họ ' viết lại như .NET 1.1).

Tôi đã từng bị nó đốt cháy nhiều lần trong quá khứ và tôi vẫn chưa tìm ra cách nào tốt để đánh giá chất lượng. Thông thường cách tốt nhất là sử dụng phán đoán của riêng bạn và nếu nó sôi sục với nó, hãy rời đi ngay lập tức nếu nó tồi tệ hơn bạn nghĩ; bạn có thể kết thúc một phễu công việc nhưng bạn sẽ giữ được sự tỉnh táo của mình.