Tôi đặt câu hỏi này cho các lập trình viên C ++ vì: a) Chỉ có lập trình viên C ++ mới có thể đánh giá giá trị kỹ thuật của các ví dụ; b) Chỉ có một lập trình viên sẽ có cảm giác về tính khí của một lập trình viên khác viết mã như thế này.
Nhân sự và các giám đốc nhận thức được rằng có một vấn đề đơn giản chỉ vì họ thấy bằng chứng trong lĩnh vực này. Đó là cuộc gọi của tôi cho dù chúng tôi cung cấp cho các lập trình viên trong câu hỏi nhiều thời gian hơn. Nhiều lỗi ở mức rất cơ bản - câu hỏi của tôi (với các lập trình viên) là liệu ai đó tự xưng là nhà phát triển C ++ cao cấp có nên được đưa ra một lợi ích của sự nghi ngờ dựa trên các mẫu mã hiện tại của họ hay không. Những người không lập trình - ngay cả những người ngoài lập trình C ++ - không thể đưa ra bất kỳ phán xét nào về việc này.
Đối với nền tảng, tôi đã được giao nhiệm vụ quản lý các nhà phát triển cho một công ty được thành lập tốt. Họ có một nhà phát triển duy nhất chuyên về tất cả mã hóa C ++ của họ (mãi mãi), nhưng chất lượng công việc thì rất tệ. Đánh giá và kiểm tra mã đã tiết lộ nhiều vấn đề, một trong những điều tồi tệ nhất là rò rỉ bộ nhớ. Nhà phát triển chưa bao giờ kiểm tra mã của mình để tìm rò rỉ và tôi phát hiện ra rằng các ứng dụng có thể rò rỉ nhiều MB chỉ với một phút sử dụng. Người dùng đã báo cáo sự chậm chạp lớn, và anh ta nói, "không liên quan gì đến tôi - nếu họ thoát ra và khởi động lại, tất cả sẽ tốt trở lại."
Tôi đã đưa cho anh ta các công cụ để phát hiện và theo dõi rò rỉ, và ngồi lại với anh ta trong nhiều giờ để chứng minh cách các công cụ được sử dụng, nơi xảy ra sự cố và phải làm gì để khắc phục chúng. Chúng tôi còn 6 tháng nữa và tôi đã chỉ định anh ấy viết một mô-đun mới. Tôi đã xem xét nó trước khi nó được tích hợp vào cơ sở mã lớn hơn của chúng tôi và đã mất tinh thần khi phát hiện ra mã hóa xấu như trước. Phần mà tôi thấy không thể hiểu được là một số mã hóa còn tệ hơn cả nghiệp dư. Ví dụ, anh ta muốn một lớp (Foo) có thể cư trú một đối tượng của một lớp khác (Bar). Anh ta quyết định rằng Foo sẽ giữ một tài liệu tham khảo cho Bar, vd:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};Nhưng (vì những lý do khác) anh ta cũng cần một người xây dựng mặc định cho Foo và, thay vì đặt câu hỏi về thiết kế ban đầu của anh ta, anh ta đã viết viên ngọc này:
Foo::Foo() : m_bar(*(new Bar)) {}Vì vậy, mỗi khi hàm tạo mặc định được gọi, một Bar bị rò rỉ. Để làm cho vấn đề tồi tệ hơn, Foo phân bổ bộ nhớ từ heap cho 2 đối tượng khác, nhưng anh ta đã không viết hàm tạo hoặc hàm sao chép. Vì vậy, mỗi lần phân bổ Foo thực sự rò rỉ 3 đối tượng khác nhau và bạn có thể tưởng tượng điều gì đã xảy ra khi một Foo được sao chép. Và - nó chỉ trở nên tốt hơn - anh ta lặp lại mô hình tương tự trên ba lớp khác, vì vậy đó không phải là một lần trượt. Toàn bộ khái niệm là sai trên rất nhiều cấp độ.
Tôi sẽ cảm thấy hiểu hơn nếu điều này đến từ một người mới. Nhưng anh chàng này đã làm điều này trong nhiều năm và đã được đào tạo và tư vấn rất tập trung trong vài tháng qua. Tôi nhận ra rằng anh ấy đã làm việc mà không cần cố vấn hay đánh giá ngang hàng trong thời gian đó, nhưng tôi bắt đầu cảm thấy anh ấy không thể thay đổi. Vì vậy, câu hỏi của tôi là, bạn sẽ tiếp tục với một người đang viết mã rõ ràng như vậy?