Khi ai đó sẽ được coi là một lập trình viên xấu? [đóng cửa]

Làm thế nào bạn sẽ xem xét rằng một lập trình viên là xấu ở những gì anh ấy hoặc cô ấy đang làm?

Nếu có thể ... Anh ấy / cô ấy nên cải thiện như thế nào?

Khi họ không học hỏi từ những sai lầm của họ và từ đánh giá ngang hàng.

Tất cả chúng ta đều xanh ở một số điểm; tuy nhiên, nếu bạn không khá hơn hoặc đang cố gắng cải thiện thì bạn là một lập trình viên tồi.

Một lập trình viên không biết những gì anh ta không biết và không quan tâm chút nào để tìm hiểu.

Một dấu hiệu cảnh báo lớn là nếu họ là một lập trình viên "sùng bái hàng hóa" - nghĩa là họ làm mọi việc nhưng không biết tại sao họ làm những việc đó (đó chỉ là "ma thuật"). Bài viết tuyệt vời của Eric Lippert ở đây .

Từ bài viết:

lập trình viên, những người hiểu những gì mã làm, nhưng không làm thế nào nó làm điều đó.

Một lời khuyên lớn cho tôi là khi họ hỏi bạn hoặc các câu hỏi phát triển lập trình viên khác cho thấy rõ ràng họ đã nỗ lực hoàn toàn bằng không để tự mình tìm ra.

Một hệ quả là khi họ hỏi cùng một câu hỏi lập trình nhiều lần cho thấy họ không tiếp thu thông tin.

Khi họ mất nhiều thời gian để giải quyết vấn đề FizzBuzz.

Các lập trình viên từ chối học các công nghệ / ngôn ngữ mới và khăng khăng bám vào những gì họ đã biết.

Phụ lục: (thêm những gì gạch ngang nói dưới đây trong các bình luận)

Một phần mở rộng của điều này là những người biết một tập hợp con về chức năng của một số công nghệ nhưng không muốn tìm hiểu thêm về nó. Ngôn ngữ lập trình, trình soạn thảo, các công cụ khác ...

Khi một thành viên trong nhóm là nhà phát triển sản xuất tiêu cực .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Có nghĩa là phần còn lại trong nhóm của bạn phải làm nhiều việc hơn vì nhà phát triển tồi. NNPP

Khi họ sản xuất những thứ thuộc về WTF hàng ngày một cách thường xuyên.

Khi họ biết có những cách tốt hơn để làm mọi thứ nhưng vẫn từ chối làm chúng ngay cả khi thời gian cho phép.

Cá nhân tôi nghĩ rằng bất kỳ lập trình viên nào có thể nhìn vào mã của riêng họ mà họ đã viết cách đây một thời gian và không tìm thấy điều gì sai với nó không phải là một điều tốt. "Một thời gian" có thể mở rộng theo kinh nghiệm ... Tôi muốn nói trong khoảng vài tuần cho đến một năm hoặc lâu hơn.

Những người bỏ qua cảnh báo về mã của họ và chỉ quan tâm đến lỗi.

Khi tôi là trưởng nhóm trong một cửa hàng nhỏ, có một vài người mà tôi phải phân công lại (cả tôi và người giám sát trực tiếp của tôi đều không có khả năng chấm dứt mà không có một tấn Băng đỏ và một đống tài liệu.) Hoặc không được gia hạn hợp đồng. vào cuối của sự tham gia hiện tại. Một số loại được liệt kê cũng làm việc cho các trưởng nhóm khác, và họ cũng có cùng quan điểm. Những điều đưa mọi người vào danh mục "Lập trình viên xấu" trong cuốn sách của tôi:

1. Không thể kiểm soát hoặc Ossified trong quá khứ
   Khi 'lập trình viên' dường như không thể tiếp thu hệ thống mới, công cụ mới hoặc bất cứ điều gì đang được triển khai, bất kể việc đào tạo / giáo dục được thực hiện như thế nào. Phải lặp lại nói đào tạo một cách thường xuyên.
   Khi 'lập trình viên' chỉ biết mô hình công nghệ hoặc mã hóa mà họ đã sử dụng 10 hoặc 15 năm trước. Thế là đủ tốt rồi, vậy tại sao họ phải thay đổi?
2. Cowboy coder
   Người mã hóa đầu tiên, không có kế hoạch. 'Lập trình viên', người thực hiện các thay đổi chưa được kiểm tra đối với mã sản xuất và / hoặc dữ liệu "bởi vì chúng tôi phải sửa nó ngay bây giờ" và sau đó rất ngạc nhiên khi "sửa lỗi" không thành công.
   Cowboy cũng chắc chắn không phải là một người chơi theo đội. Không cần không có đội ngũ của stinkin.
3. Thời tiết-cánh
   này 'lập trình' là say mê với "công nghệ du jour " và nhìn thấy tất cả các khuôn khổ mới, ngôn ngữ, phương pháp hoặc bất cứ điều gì là mới và nóng như
4. "Bộ não lớn"
   'lập trình viên' này rất chắc chắn về tài năng và khả năng của anh ấy đến nỗi mọi thứ được thực hiện mà không có nhiều ý nghĩa của dự án. ví dụ: Viết lại một thư viện chuẩn "bởi vì nó không hiệu quả đối với hệ thống của chúng tôi" hoặc giới thiệu các công cụ và kỹ thuật không phù hợp với vấn đề hiện tại. ví dụ: Giới thiệu Lisp hoặc Forth trong môi trường máy tính lớn.
5. LỘC ^a. Sandbagger
   'lập trình viên' này sử dụng obfuscation và hướng sai để tăng ^a. LỘC: Dòng mã được trả tiền. Tôi đã thấy mã trong tình huống này là trang sau trang, màn hình sau màn hình của cấu trúc và logic trùng lặp, chỉ với các tên biến đoạn hoặc điều khiển được thay đổi để tăng số lượng dòng.
6. Chuyên gia không thể thiếu
   'Lập trình viên' có kiến ​​thức về miền để giải quyết các vấn đề trong tay, nhưng vì họ "biết" mọi thứ về nó. Như một vấn đề thực tế, nếu họ bị xe buýt đâm, thì toàn bộ tổ chức sẽ sụp đổ. { Quan sát: Những người nghĩ rằng họ không thể thiếu thường là. (Bất cứ ai cũng có nguồn về câu cách ngôn này?)}
7. Đầu bếp Pasta
   'lập trình viên' này chuyên về mã spaghetti, được thêm vào các mã định danh quá khó để theo dõi nếu không có IDE được triển khai theo cú pháp. ví dụ: IndexI1O0, Index1I0O, v.v.
8. Thực tập mùa hè - Cụ thể là tiểu cảnh đi bộ Thảm họa
   Cửa hàng cũ của tôi đã từng thuê một số thực tập sinh cuối cấp trung học hoặc đại học. Một lần, một bộ phận cần một cơ sở dữ liệu nhỏ để theo dõi một số cách sử dụng thiết bị, (bây giờ điều này đã trở lại và nó đang sử dụng dBase III). Anh chàng mã hóa suốt mùa hè, nhưng không được thực hiện khi đại học bắt đầu vào mùa thu. Anh ấy được gia hạn thêm một tuần sau đó đến tuần thứ hai. Vào cuối tuần thứ hai, tôi được cử đi nhận dự án của anh ấy và mang nó trở lại Hệ thống phát triển để hoàn thành. Anh chỉ cho tôi những thứ anh đã làm, rồi phần còn dang dở. Những gì đã làm việc có kẹo mắt đẹp, nhưng ứng dụng làchưa hoàn thiện. Khi tôi mở hộp đĩa mềm được định dạng mới để lấy bản sao, anh ta nói, "chỉ một giây thôi, để tôi xóa các tệp kiểm tra của mình ..." và trước khi tôi có thể nói bất cứ điều gì, anh ta đã xóa một loạt các tệp.
   Là loại người đáng ngờ và nhận thấy ứng dụng của anh ta gần như không có gì ngoài mắt khi tôi quay lại cửa hàng của mình, tôi quay lại bộ phận và rút Norton ra và xóa các tập tin anh ta đã xóa, cố gắng tìm thêm logic, ngay cả khi không đầy đủ.
   Tôi thấy, logic không tệ, nhưng hành vi xấu. Máy in được gắn vào PC anh đang sử dụng là máy in bánh xe daisy. Bộ ký tự thường được gắn là một biến thể swiss. Đầu ra của các chương trình đã xóa đưa ra một tên, địa chỉ, DOB, một số mã chữ cái và một số loại số id. Các định dạng và bố trí làm phiền tôi. Tất cả các ngày sinh cho nhiều người hầu như không đủ tuổi uống rượu hợp pháp. Hầu hết các địa chỉ không có ở đó, khi tôi tìm chúng trong thư mục chéo của chúng tôi. Khi tôi đưa bản in cho người giám sát của anh ta, anh ta nhìn tôi và nói "Bằng lái xe, anh không nghĩ sao?" Tôi nói tôi đã làm như vậy. Anh ấy nói rằng đó là lý do tại sao anh ấy tìm thấy tất cả các cổ phiếu trong suốt bị cắt trong thùng rác bên cạnh Xerox. Cậu bé hư của chúng tôi đã thực hiện các lớp phủ để điều chỉnh độ tuổi của mình và bạn bè trên giấy phép lái xe. Chúng tôi đã báo cáo với chính quyền.không được trả tiền cho hai tuần qua của mình.

Đây chỉ là một số nhân vật xấu mà tôi đã phải làm việc với ....

/ s / BezantSoft

Không thể tự thích ứng với các công nghệ sắp tới

Ngoài việc thiếu kiến ​​thức / khả năng rõ ràng, một lập trình viên là một người xấu, nếu mã của họ khó đọc và / hoặc duy trì hơn mức cần thiết.

Khi không ai khác có thể đọc mã của mình. Không quan trọng bạn sáng đến mức nào; không có lập trình viên là một hòn đảo.

Một người không chú ý đến các chi tiết và luôn ở chế độ "nó hoạt động, vì vậy tôi để nó một mình. Tất cả những ngoại lệ trong nhật ký không quan trọng".

Có hai loại dành cho lập trình viên cho tôi - solo và team.

Lập trình viên solo tệ là

• Những người mất quá nhiều thời gian để hoàn thành nhiệm vụ đơn giản.
• Những người không thể tự nghiên cứu cho những gì họ đang làm.
• Những người sẽ quên những gì đã được mã hóa ngày hôm nay trong vài ngày và không thể duy trì cơ sở mã của riêng mình rất tốt.
• Những người không thể thích ứng với những thay đổi yêu cầu.

Lập trình viên nhóm xấu là những người rơi vào nhóm lập trình viên solo tồi, bao gồm

• Những người không thể phối hợp với các thành viên khác trong nhóm.
• Những người không hoan nghênh những lời chỉ trích.
• Những người không biết làm thế nào để hữu ích cho người khác và làm thế nào để hưởng lợi từ các thành viên khác trong nhóm.
• Những người không thể viết mã có thể đọc được.
• Những người không bình luận vì mục đích dễ đọc cho người khác.

Không sẵn sàng thừa nhận họ không biết câu trả lời và / hoặc không muốn tìm kiếm mọi thứ.

Nếu bạn không biết điều đó, đừng từ bỏ - hãy tìm ra và hoàn thành nó.

Một dấu hiệu cảnh báo lớn trong kinh nghiệm của tôi là khi họ không bình luận về hack của họ ....

Bạn biết ý tôi là gì: khi bạn bị buộc phải làm điều gì đó rất hack vì đơn giản là không có cách nào tốt hơn để làm điều đó.

Các lập trình viên giỏi sẽ ghét phải làm điều đó và đưa ra các bình luận nội tuyến nói rằng họ ghét phải đưa loại hack đó đến mức nào, nhưng không có lựa chọn nào khác. Các lập trình viên xấu sẽ chỉ đưa vào hack và không bình luận nó.

Im lặng rõ ràng khi một lập trình viên viết RẤT NHIỀU mã. Các hàm rất lớn, có thể sao chép / dán các dòng hoặc khối mã, sử dụng nhiều if nếu cần thiết, v.v. Điều này có thể là do lập trình viên không biết một hàm tiêu chuẩn để làm những gì anh ta muốn nhưng phần lớn thời gian không phải vậy.

Được nhắc lại một cách chính xác cách thức đúng đắn để làm điều đó, và lặp đi lặp lại chỉ cần làm điều đó một cách dễ dàng.

Tôi đang chuyển câu trả lời của mình đến đây từ một chủ đề trùng lặp khép kín hỏi Bạn có thể nhận ra nếu bạn là một lập trình viên tồi? Các chủ đề khác đã được đóng lại khi tôi đang soạn phản hồi của tôi. Câu trả lời của tôi trực tiếp hơn giải quyết câu hỏi vì nó được đặt ra bởi người hỏi khác và sẽ đọc tốt hơn nếu bạn hiểu điều đó.

Thở dài! Một phần trong tôi không muốn thêm vào chủ đề đã bận rộn này, nhưng phần khác của tôi đã thắng! Tại sao nó lại thắng; Tại sao tôi lại bận tâm thêm nhiều từ hơn cho đa cấp đặc biệt này? Vâng, bởi vì, ở một mức độ nào đó, tôi có thể có một chút khác biệt về điều này so với nhiều nhà bình luận trước đây.

Nhị phân hoạt động tốt trong máy tính: đó là '1' hoặc '0', "bật" hoặc "tắt". Chúng ta có thể trừu tượng hóa và mã hóa rất nhiều thông tin bằng cách sử dụng hai trạng thái nổi tiếng đó. Nhưng, nó không có xu hướng hoạt động tốt cho các vấn đề của con người: "tốt" hay "xấu", "lành mạnh" hay "điên rồ", "tốt" hay "xấu xa", "thông minh" hay "ngu ngốc" hoặc "mỏng", "còn sống" hay "chết?" Những kiểu đánh giá phân cực này luôn khiến con người chu đáo trở thành một phần của tôi không được thỏa mãn một cách khủng khiếp. Bằng bất cứ phương án đo lường nào tôi chọn để áp dụng, tôi thường thấy rằng các câu trả lời cho sự tương phản rõ rệt như vậy thực sự nằm ở đâu đó dọc theo sự liên tục giữa cực này và cực kia, không phải ở hai đầu.

Bây giờ tôi đã chiến đấu với xu hướng phân cực này khá lâu và giải pháp cá nhân của tôi là tôi thấy hữu ích hơn nhiều khi áp dụng ba từ cho bất kỳ đánh giá nào như vậy: " ở mức độ nào!"

Vì vậy, câu trả lời của tôi cho câu hỏi của bạn là đề nghị bạn viết lại nó và tự hỏi mình điều này: "Tôi là một lập trình viên tồi đến mức độ nào?" Hoặc, thậm chí tốt hơn, để hỏi nó theo hướng khác: "Tôi là một lập trình viên giỏi đến mức độ nào?" Nếu bạn theo đuổi sự thật, có lẽ bạn sẽ tìm thấy chính mình ở đâu đó dọc theo sự liên tục giữa việc trở thành một lập trình viên "xấu" và một người "tốt". Sau đó, khi bạn xoay sở để xác định vị trí của mình dọc theo con đường này, bạn có thể xác định được một điểm gần với điểm cuối "tốt", một điểm mà bạn muốn tìm thấy chính mình trong tương lai gần.

Nếu bạn không đặt điểm đó quá xa, có lẽ bạn có thể đặt chân sau của mình vào bánh răng và bắt đầu di chuyển nó theo hướng đó. Nếu bạn quản lý để lặp lại thuật toán heuristic khá đơn giản này nhiều lần, bạn có thể sớm thấy mình quá bận rộn để lập trình để hỏi lại câu hỏi này! Ồ, và có lẽ bạn sẽ tiến bộ nhanh hơn nếu bạn bắt đầu đập mã trên bàn phím nhanh và thường xuyên nhất có thể; và, nếu bạn nghỉ ngơi một chút và sau đó, hãy đọc một số mã chất lượng cao được viết bởi các đồng nghiệp của bạn! Trong những ngày phát triển Nguồn mở năng động này, bạn không thiếu mã miễn phí và tinh tế để học hỏi!

Vì vậy, tôi thực sự khuyên bạn nên thử ba từ nhỏ của tôi, "ở mức độ nào" và xem họ có thể đưa bạn đi bao xa theo hướng tốt!

Một người nói "Không thể làm được".

Theo tôi đó là tất cả về giải quyết vấn đề, công cụ nên ít liên quan hơn nhiều so với thực sự hoàn thành công việc. Nếu tôi phải giải quyết nó bằng MS-Access hoặc ngôn ngữ lắp ráp, đó là vấn đề thời gian và tiền bạc, không phải là vấn đề "Không thể thực hiện được"

Một dấu hiệu cảnh báo là quá tập trung vào cách làm việc học tập và "đúng đắn", và không đủ tập trung vào việc hoàn thành công việc.

Nếu anh ta chỉ biết cú pháp của một ngôn ngữ nhưng không biết các khái niệm cơ bản của thuật toán.

Khi họ làm rất nhiều việc nhưng sản xuất rất ít.

! (thông minh và hoàn thành công việc)

Những người không biết các nguyên tắc như RẮN, KHÔ, OOP, v.v. Điều quan trọng là phải hiểu rõ về các nguyên tắc và nền tảng lập trình thay vì biết các công nghệ cụ thể. Những người có nền tảng vững chắc sẽ có thể học các chủ đề mới một cách dễ dàng và sẽ tạo ra mã tốt hơn.

Một lập trình viên nhúng không hiểu ngắt rất tốt hoặc đa nhiệm. Ngoài ra, các lập trình viên cần làm việc với các trường bit nhưng không nắm bắt được các thao tác logic trên chúng và dịch chuyển.

Một tín hiệu nhận biết ngay lập tức là ai đó nói: "Tôi không hiểu tại sao nó không hoạt động. Tôi đã làm mọi thứ đúng."

Một điều khác biệt giữa một lập trình viên tồi với các lập trình viên mới là sự khăng khăng kiên định trong việc thực hiện hệ thống yêu thích của họ bằng bất kỳ ngôn ngữ và API nào họ đang làm việc.

Tôi đã từng thừa hưởng một hệ thống mà nhà phát triển trước đó đã triển khai lại (bằng Java) một bộ lớn api Ashton Tate DBase III + nằm trên thư viện truy cập dbf tùy chỉnh. Không có khung công tác bộ sưu tập Java nào được sử dụng.

Điều này là để anh ta có thể viết một ứng dụng Java / swing trông và hoạt động giống như một ứng dụng DBase III + (hoặc có thể là clipper).

Ứng dụng anh viết trong hệ thống này có các menu thanh lite và sẽ mở một dạng cửa sổ đầy đủ với một hàng nút ở phía dưới khi bạn điều hướng thanh lite đến tùy chọn. Nó giống như một cỗ máy thời gian nhỏ bé trở lại những năm 1980.

Người đàn ông rõ ràng là một nhà phát triển lành nghề. Anh ta biết đủ rằng anh ta có thể tự viết toàn bộ hệ thống đó trong khung thời gian của dự án đó. Ông cũng có thể sử dụng lại nó trên một vài hệ thống nội bộ khác.

Nhưng anh ta là một lập trình viên tồi tệ ở chỗ mã của anh ta đã sử dụng sai các tính năng của các hệ thống mà anh ta làm việc. Anh ta sẵn sàng dành 3 tháng cho một lib tùy chỉnh về lợi ích đáng ngờ hơn là học Java / Swing / SQL.