Làm thế nào quan trọng là một phong cách mã hóa tốt cho quyết định thuê một lập trình viên? [đóng cửa]

Ngay cả khi còn là sinh viên, tôi được yêu cầu xem lại mã của các lập trình viên đã (chưa) vượt qua một bài kiểm tra (tạo danh sách các số Fibonacci trên Android).

Mặc dù tôi rất nghiêm khắc về phong cách mã hóa, tôi chỉ đọc về phong cách "chặn" mà ai đó đã sử dụng (đọc các bình luận!) .

Ở vị trí của mình, tôi khuyên bạn không nên thuê một anh chàng sử dụng kiểu này. Mã này hoàn toàn trái ngược với phong cách mã hóa được sử dụng trong công ty của tôi.

Trong khi tìm kiếm phong cách mã hóa và cách đối phó với việc thiếu nó, tôi tò mò về một điều: tôi có nên thuê một anh chàng sẽ córắc rối nghiêm trọng thích ứng với phong cách mã hóa được sử dụng trong các công ty?

Xin vui lòng: Đây không nên là một cuộc thảo luận về phong cách mã hóa nói chung và tốt hơn. Đó là về tầm quan trọng của phong cách mã hóa đối với quyết định thuê một ai đó!

Thêm thông tin:

Tôi không phải là người đưa ra quyết định, tôi chỉ đưa ra ý kiến ​​của mình dựa trên mã. Anh chàng phải vượt qua một cuộc phỏng vấn trong đó người đứng đầu của chúng tôi kiểm tra các kỹ năng mềm. Nếu anh ta vượt qua điều này, anh ta phải vượt qua bài kiểm tra kỹ năng nhỏ của chúng tôi và đó là nơi đôi khi tôi được yêu cầu xem lại mã viết. Tôi không ở vị trí để nói có hay không. Tôi chỉ muốn biết phong cách mã hóa quan trọng như thế nào đối với đánh giá của tôi ...

Làm thế nào để bạn biết rằng anh ấy sẽ gặp khó khăn trong việc thích nghi? Chỉ vì họ sử dụng một phong cách mã hóa khác nhau? Đó là khá tự phụ. Tôi đã là một nhà thầu trong một thời gian dài, và cho dù sử dụng phong cách mã hóa nào, bạn đều thích nghi. Có thể mất một chút thời gian, nhưng các thói quen hình thành khá nhanh.

Tôi hy vọng rằng theo phong cách mã hóa, bạn không chỉ có nghĩa là thụt lề và bố trí mã. Điều đó dễ dàng được xử lý bằng cách sử dụng một trình định dạng mã và tích hợp nó vào hệ thống kiểm soát phiên bản của bạn.

Lấy phong cách mã hóa có nghĩa là những thứ như đặt tên, đặt hàng chung, tách đơn vị và mọi thứ khác liên quan đến khả năng đọc và bảo trì, điều quan trọng nhất về phong cách mã hóa là bạn có một. Không phải cái nào. Không có một phong cách mã hóa là một lá cờ đỏ xác định.

Điều quan trọng thứ hai về bất kỳ phong cách mã hóa nào mà ai đó sử dụng, là họ sử dụng nó một cách nhất quán. Khi ai đó dường như sử dụng một phong cách mã hóa, nhưng thường xuyên "phạm tội" chống lại nó, đó là một lá cờ đỏ xác định khác.

Đã được lập trình tại hàng trăm dự án khác nhau cho gần một trăm khách hàng khác nhau, hãy để tôi nhấn mạnh một điểm.

Phong cách mã hóa (và ngụy biện cho phong cách mã hóa) là một sự lãng phí hoàn toàn thời gian.

Hãy vượt qua nó.

Tôi đã đọc rất nhiều mã từ rất nhiều lập trình viên khác nhau. (Giả sử quy mô nhóm trung bình gồm 5 và 100 đội khác nhau. Đó là 500 đồng nghiệp.) Phong cách không thành vấn đề.

Tôi đã thấy mã đẹp nhưng sai bệnh lý.

[Có một giới hạn. Obfuscation cố ý là căn cứ để chấm dứt. Nói tóm lại, phong cách là một sự lãng phí thời gian.]

Phong cách mã hóa là "biên giới cuối cùng"

Nếu bạn đã giải quyết tất cả các vấn đề về phát triển phần mềm; nếu bạn có thể tạo mã không có lỗi nhiều hơn hoặc ít hơn ngay lập tức; nếu mức chất lượng của bạn quá cao, bạn không còn có hàng đợi sửa lỗi; nếu khả năng sử dụng của bạn rất tuyệt vời, bạn không còn có bàn trợ giúp; nếu bạn có thể tối ưu hóa một cách tàn nhẫn đến mức bạn không có trang trại máy chủ, nhưng điều hành doanh nghiệp từ iPad ...

Khi không còn gì để sửa, cuối cùng bạn cũng có thể tập trung vào phong cách mã hóa.

Cho đến lúc đó, có rất nhiều vấn đề lớn hơn và có giá trị hơn phong cách.

Đánh giá các lập trình viên dựa trên phong cách mã hóa là 50% hợm hĩnh và 50% không an toàn.

Tôi thích mã của mình trông gọn gàng và sạch sẽ, và có vẻ như anh chàng OP rách rưới trong liên kết cũng vậy. Mã của chúng tôi trông không giống nhau, nhưng cả hai chúng tôi đều sử dụng một kiểu giúp chúng tôi hiểu mã khi chúng tôi quay lại. Tôi hoàn toàn không gặp khó khăn gì trong việc hiểu mã của anh ấy và tôi nghi ngờ OP cũng vậy. "Lời khuyên" theo kiểu mã hóa không gì khác ngoài một cú đánh rẻ tiền dễ dàng, nơi bạn có thể truyền đạt sự khôn ngoan to lớn của mình về lý do tại sao nên niềng răng xoăn trên dòng tiếp theo. Nó không quan trọng chút nào. Điều làm cho mã khó đọc là:

• quy ước đặt tên điên rồ (hoặc thiếu nó) không mô tả những gì họ đại diện.
• dòng chương trình điên rồ gây khó khăn cho việc nói những gì đang xảy ra (goto, thử / bắt với logic kinh doanh, v.v.).
• các chức năng cực kỳ dài làm nhiều việc hơn bộ não có thể theo dõi.

Tôi gặp khó khăn khi tưởng tượng bất kỳ mã nào không làm bất kỳ điều gì được liệt kê ở trên, nhưng vẫn khó đọc, đặc biệt là với một công cụ như Style Cop.

Thật lố bịch khi định dạng mã là một yếu tố khi quyết định thuê một ai đó.

1. Có nhiều yếu tố quan trọng hơn để xem xét.
2. Hầu hết các nhà phát triển có thể điều chỉnh phong cách của họ.
3. Nếu định dạng là quan trọng, hãy sử dụng bộ định dạng lại mã và trình kiểm tra xơ.

Không thuê một nhà phát triển giỏi vì anh ta không thêm khoảng trắng sau dấu phẩy là ngớ ngẩn.

Tôi cho rằng bạn có một phong cách định dạng chính thức trong công ty.

Sau đó, làm cho nó cực kỳ dễ dàng định dạng lại bất kỳ nguồn nào thành kiểu chính thức và tốt nhất là làm cho nó tự động xảy ra mỗi khi tệp nguồn được lưu.

Bất kỳ lập trình viên nào xứng đáng với muối của mình sẽ phát triển để yêu thích điều này bởi vì nó đảm bảo chất lượng cao hơn bằng cách giảm thiểu các khác biệt cho các cam kết.

Sử dụng StyleCop

Nếu bạn đang sử dụng Visual Studio, bạn luôn có thể buộc các quy tắc StyleCop với phần biên dịch của mình, điều này sẽ đảm bảo rằng mã của bạn ít nhất có thể đọc được.

Tôi từ chối mã không thể đọc được theo kiểu không chuẩn , bởi vì nó sẽ trở nên rất khó để duy trì trong tương lai - ngay cả bởi chính các tác giả. Điều này đã được chứng minh nhiều lần trong quá khứ.

Định dạng mã tích hợp CVS = giải pháp tối ưu

Sẽ thực sự tuyệt vời nếu bất kỳ CVS nào hỗ trợ định dạng mã tự động khi đăng ký. Bạn chỉ cần đặt mức độ ưu tiên cho kiểu của mình, mã sẽ được định dạng trước khi lưu. Điều đó sẽ làm cho phong cách cụ thể của nhà phát triển trở nên lỗi thời về định dạng mã. Tôi có thể thấy vấn đề nếu một số nhà phát triển đang sử dụng các ký tự thụt đầu dòng khác nhau. Nó không quá khó để tôi xem xét các mã khác nhau (và tôi có thể dễ dàng và nhanh chóng định dạng lại nó) nhưng DIFF trở nên khó xử lý hơn. Rất nhiều dương tính giả trong công cụ DIFF.

Xa bên dưới các chi tiết quan trọng hơn nhiều sau đây:

• Đội hình phù hợp
• Giải quyết vấn đề
• Giao tiếp

Kiểu mã hóa có thể được học bởi hầu hết những người có hai danh sách cuối cùng được liệt kê ở trên.

Tuy nhiên, tôi thường nhìn thấy một mẫu mã trước cuộc phỏng vấn cuối cùng và nếu phong cách mã hóa là một chặng đường dài so với những gì chúng ta sử dụng, tôi sẽ tập trung vào các câu hỏi thể hiện khả năng thích ứng của họ.

Miễn là phong cách phù hợp và người đó có thể thích nghi (thay đổi) với phong cách khác, tôi không thấy bất kỳ vấn đề nào.

Nếu phong cách hiện tại khác với những gì bạn sử dụng thì điều đó không có nghĩa là xấu. Đối với các ứng cử viên, nó có thể có ý nghĩa hoàn chỉnh.

Giống như những người khác nói, gặp khó khăn trong việc thích nghi có thể là vấn đề duy nhất.

Tôi sẽ không nói rằng đây là một sự thuê mướn nhất định, nhưng đó là một lập luận mạnh mẽ chống lại người này.

Tôi thực sự sẽ không lo lắng về phong cách mã hóa, nhưng về việc không có khả năng thích ứng này là một triệu chứng của một vấn đề chung. Tôi sẽ sợ rằng ứng viên có thể cảm thấy khó thích nghi với các khía cạnh khác của văn hóa đội nhóm.

Nếu bạn không thể tập trung suy nghĩ bằng cách sử dụng kiểu pascal thay vì vỏ kiểu lạc đà, thì bạn rất có thể gặp khó khăn khi nhớ bắt đầu một mẻ cà phê mới nếu bạn uống cốc cuối cùng. Điều đó có thể thực sự có hại cho đội.

(Và vâng, tôi là một người nghiện caffeine.)

Theo tôi, một phong cách mã tốt là điều cần thiết để lập trình viên làm việc.

Có một phong cách mã tốt là một câu hỏi về phát triển cá nhân. Đây là một chỉ số mà cấp độ lập trình viên này đã đạt được.

Câu hỏi là nếu công ty của bạn muốn "chuyên gia cao" hay "tiềm năng cao". Nếu bạn cần "chuyên gia cao" và không có chỗ để học hỏi và phát triển - phong cách mã là một tiêu chí loại trừ.

Nếu có chỗ cho sự phát triển và sự phát triển của các lập trình viên, bạn nên quan tâm đến khả năng học hỏi nhanh hoặc suy nghĩ sáng tạo của anh ấy hoặc cô ấy.