Giúp lập trình viên cơ sở vượt qua những thiếu sót của họ? [đóng cửa]

Nắm bắt phổ biến của bạn về các nhà phát triển cơ sở tham gia nhóm của bạn hoặc người mà bạn phải làm việc với là gì? Rõ ràng là họ thiếu kinh nghiệm nên bạn không thể mong họ biết tất cả mọi thứ, nhưng kỹ năng nào thường thiếu một cách khó hiểu - và cụ thể, chúng ta có thể giúp họ xây dựng những kỹ năng còn thiếu này như thế nào?

Tôi không có nghĩa là các kỹ năng liên cá nhân như 'lắng nghe lời khuyên', ý tôi là các vấn đề kỹ thuật như (nếu có):

• 'bạn chưa bao giờ thực hiện SQL?'

• 'bạn chưa bao giờ viết một bài kiểm tra đơn vị?'

• 'bạn không biết cách sử dụng dòng lệnh Unix?'

Mọi thứ mà bạn làm mong đợi - Tôi muốn nghe những quan sát và kỹ thuật của mình để dạy lập trình viên mới để vượt qua những thiếu sót nhất định.

Không biết kiểm soát phiên bản là gì, hoặc sử dụng đúng cách .

Một trong những nhà phát triển cơ sở đã ở công ty tôi vài tháng gần đây đã được dạy về những điều rất cơ bản của Subversion. Nó thực sự khiến tôi co rúm lại ... cô ấy đã kiểm tra mã cho các dự án trực tiếp suốt thời gian đó ... và không biết cô ấy đang làm gì ...?

Không hỏi đủ câu hỏi

Tôi biết họ là đàn em, tôi hy vọng rằng họ sẽ phạm sai lầm và chỉ không biết mọi thứ. Vì vậy, rất nhiều hoàng gia f ** k có thể tránh được bằng cách chỉ hỏi một câu hỏi thay vì giả định điều gì đó. Thành thật mà nói, tôi không thể bị làm phiền đủ.

Tôi đã có TONNES các câu hỏi khi tôi bắt đầu - yêu cầu họ lưu mông của tôi trong một số dịp. Chết tiệt, tôi vẫn còn rất nhiều câu hỏi ... Tôi chỉ muốn nghĩ rằng bây giờ chúng là những câu hỏi hay hơn.

Sao chép dán và dùng thử và lỗi thay vì tìm cách hiểu các nguyên tắc cơ bản cơ bản

Nhiều nhà phát triển cơ sở sẽ sao chép mã trông gần gũi, sau đó gần như ngẫu nhiên thử các hoán vị khác nhau của các sửa đổi bằng vũ lực cho đến khi chúng đánh vào một mã hoạt động. Nếu bạn không biết tại sao nó hoạt động, rất có thể bạn đang giới thiệu các lỗi trong các trường hợp ranh giới mà ai đó hiểu nó sẽ phải dọn dẹp sau.

Giữ "bản nháp" đầu tiên của họ

Khi một nhà phát triển có kinh nghiệm viết một hàm mới có độ phức tạp nhất định, họ bắt đầu với một sơ khai không có gì ngoài biên dịch, sau đó viết lại để thêm các nhận xét mã giả cấp cao cho thuật toán tổng thể, sau đó viết lại các bình luận đó cùng một lúc mã thực tế, thêm và loại bỏ mã giả khi cần để thử nghiệm, sau đó viết lại để loại bỏ sự dư thừa xuất hiện trong quá trình thực hiện, v.v. trong một loạt các cải tiến liên tiếp và tăng dần.

Các nhà phát triển cơ sở có xu hướng viết nó thành một khối lớn, sau đó thực hiện gỡ lỗi vũ lực lớn. Họ không muốn xóa một dòng mã một khi nó được nhập vào trình chỉnh sửa, và rất vui vì cuối cùng họ đã làm cho nó hoạt động đến mức họ không muốn viết lại để cải thiện phi chức năng, nhưng họ là những người cần phải làm vì vậy nhất

Tin rằng bạn là người đầu tiên gặp phải một tình huống.

Mọi vấn đề lập trình mà bạn gặp phải đều phải đối mặt với người khác, dưới một hình thức chung nào đó. Có rất nhiều điều để học hỏi từ các lập trình viên giàu kinh nghiệm. Tôi đủ lớn để nhớ lập trình trước khi Google, và nó hút . Thậm chí còn tệ hơn khi chúng tôi có các công cụ tìm kiếm, nhưng vẫn chưa có nhiều thông tin tốt trên web. Lập trình bây giờ hiệu quả hơn nhiều vì bạn có quyền truy cập vào kiến ​​thức toàn cầu trong vài giây. Những người không sử dụng nó đang phớt lờ nó trong tình trạng nguy hiểm.

Chỉnh sửa :

Để rõ ràng, tôi không ủng hộ lập trình sao chép / dán. Tuy nhiên, tôi chắc chắn rằng bạn cần xem lại kiến ​​thức hiện có trước khi bạn có thể tự đưa ra quyết định tốt.

Suy nghĩ rằng họ biết tất cả mọi thứ.

Tôi đã có một jr. thực tập sinh đã cố gắng giải quyết mọi thứ với javascript. Đã cố gắng để giải thích một số khái niệm, nhưng anh ấy luôn nghĩ rằng anh ấy có thể làm điều đó tốt hơn. Bây giờ anh ấy đã nghỉ việc và đang làm lại một chương trình lớn mà anh ấy đã xây dựng cho đầu ra in bằng HTML thay vì một công nghệ in sẵn như PDF. Chưa kể một đống vấn đề lớn khác.

Bài học là yêu cầu người cao niên hướng dẫn bao quát chính trong một dự án, đừng tắt kiến ​​trúc mà không có sự giúp đỡ. Bạn có thể viết mã và chi tiết một mình, nhưng hãy chắc chắn rằng bạn ít nhất sử dụng đúng công nghệ.

Tôi hiếm khi cảm thấy khó chịu khi đàn em không biết những điều cơ bản, họ không được dạy các kỹ năng công nghiệp như SCC ở trường đại học. Đó là công việc của các nhà phát triển cấp cao để dạy họ. Tôi chỉ thấy khó chịu bởi những cuộc đụng độ cá tính. Nhưng tôi cảm thấy khó chịu nhất bởi các nhà phát triển cấp cao, những người không biết những điều cơ bản.

Không muốn nâng cao kiến ​​thức của họ - thay vào đó là con đường ít kháng cự nhất.

Một ngày khác, một thực tập sinh cùng với nhà thiết kế đồ họa (người có kỹ năng lập trình đáng ngạc nhiên) đã yêu cầu trợ giúp vì họ gặp rắc rối khi thực hiện một cái gì đó trong jQuery - việc đóng cửa có thể gây đau đớn nếu bạn không thể thấy nó đến.

Tôi ngồi xuống với thực tập sinh và giải thích chính xác những gì đang xảy ra và tại sao. Chúng tôi đã sửa lỗi, sau đó tôi đã chỉ ra một số cải tiến bổ sung có thể được thực hiện ("vì tôi ở đây") và cuối cùng chúng tôi đã viết lại chức năng có tội trong 10 dòng thay vì 20 và không có lỗi. Sau khi trả lời bất kỳ câu hỏi nào, hài lòng rằng mọi thứ đều ổn trên thế giới một lần nữa, tôi rời đi.

Ngày hôm sau, nhân viên thực tập đến với một câu hỏi tiết lộ rằng anh ta "ừm, muốn thực hiện một số thay đổi và viết lại chức năng theo cách của tôi vì tôi thấy khó hiểu" (phần lớn là hoàn tác những cải tiến của tôi).

Ông hoặc có thể đã cố gắng chăm chỉ hơn để thay thế (đặt câu hỏi thêm, đọc lên trên khái niệm tôi đã đề cập) - Mã quá ngắn có thể không bao giờ có điều đó khó có thể hiểu được - hoặc đi lối thoát dễ dàng. Nó làm tôi buồn mỗi khi tôi thấy ai đó làm sau.

Không hiểu OOP. Đáng buồn thay, đây là cách phổ biến hơn hầu hết chúng ta có thể nhận ra.

Biết cách tạo ra một lớp, lớp trừu tượng, giao diện hoặc thậm chí biết đa hình là một điều; hiểu làm thế nào để sử dụng chúng đúng cách cho lợi ích của chương trình của bạn là một cách khác .

Nếu bạn muốn tránh câu hỏi này, tôi đã tìm thấy những câu hỏi này và câu trả lời cho chúng khai sáng:

• Mùi mã: Lạm dụng thừa kế - Những hiểm họa của thừa kế
• Khái niệm "thành phần ủng hộ thừa kế" này đến từ đâu? - Những hiểm họa của thần chú về việc tránh thừa kế

Không biết những gì bạn không biết, và trong sự thiếu hiểu biết, bạn biết tất cả mọi thứ.

(Và anh em họ thân thiết của nó, không muốn hỏi.)

Một phần đây là một điều có tổ chức - một cảm ứng đến thích hợp sẽ đi một chặng đường dài để ngăn chặn một số điều này trở thành vấn đề. Nhưng rất ít công ty có thời gian hoặc người sẵn sàng cho một cảm ứng đến - một cái gì đó sẽ mất từ ​​vài ngày đến vài tuần và khiến các nhà phát triển nghỉ việc. Vì vậy, chúng tôi phải dập tắt đám cháy thay thế.

Tôi ngạc nhiên khi thấy nhiều lập trình viên cơ sở tương đối mới trong một chương trình CS yếu về thuật toán. Lựa chọn thuật toán kém có thể không thực sự nổi bật trong các ứng dụng kinh doanh, nhưng khi xử lý hàng tỷ yêu cầu dịch vụ web mỗi ngày, điều đó thực sự quan trọng.

Đây là một câu hỏi phỏng vấn tôi sử dụng mà hầu hết tất cả các lập trình viên Junior đều bỏ lỡ vấn đề nổi bật:

Viết mã tính toán số Fibonacci thứ N.

Họ hầu như luôn luôn viết những điều rõ ràng nhất nhưng không hiệu quả

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Khi được yêu cầu nhận xét về độ phức tạp của thuật toán, tôi thường nhận được "nó tệ hơn O (N) ... uhm ... O (N logN)". Nó thực sự còn tệ hơn thế nữa ...

Làm thụt mã ngược!

Tất nhiên đó không phải là "điển hình". Tôi không bao giờ có thể tin nó thậm chí có thể, nhưng những gì một nhà phát triển bình thường sẽ viết như thế nào

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

cô ấy sẽ viết như thế (Chúa ơi, dường như tôi vẫn không thể!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Thất vọng phải không?