it-swarm-vi.com

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

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?

57
Tamara Wijsman

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.

134
ist_lion

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.

125
Graviton

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 đăng tuyệt vời của Eric Lippert tại đâ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 đó.
75
Marcel Lamothe

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.

45
JohnFx

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

21
EpsilonVector

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 ...

21
missingfaktor

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

18
danivovich

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

18
Billy ONeal

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.

15
JeffO

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.

15
Daenyth

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

15
Reigel

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 khi kết thúc hợp đồng 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. Cao bồi
    [.___.] 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à người chơi theo nhóm. Không cần không có đội ngũ của stinkin.
  3. Cánh gió
    [.__.] 'Lập trình viên' này say mê với "công nghệ du jour " và thấy mọi khuôn khổ, ngôn ngữ, phương pháp mới hoặc bất cứ điều gì mới và nóng
  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 ta đến mức 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 thư viện chuẩn "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. Bao cát
    [.__.] 'Lập trình viên' này sử dụng obfuscation và định 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ỉ có 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 đề của 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à thảm họa đi bộ
    [.__.] 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ó một phần mở rộng một tuần sau đó một tuần thứ hai. Vào cuối tuần thứ hai, tôi được cử đi tiếp quả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  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 ngờ và nhận thấy rằng ứ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 một số logic bổ sung, ngay cả khi không đầy đủ.
    [.__.] Tôi thấy, không phải logic xấu, mà là 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. Anh ấy đã không được trả tiền trong hai tuần qua.

Đâ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

14
BezantSoft

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.

10
Chinmay Kanchi

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

10
Gopi

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.

10
stevenvh

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òng 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.
7
tia

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".

7
talonx

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 việc đưa vào 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ó.

4
Bobby Tables

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ó.

4
Dean Higginbotham

Được nhắc lại một cách rõ ràng phải cách thực hiện và lặp đi lặp lại chỉ là cách dễ dàng.

3
DaveDev

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 thêm 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.

3
user2528

Tôi đang chuyển câu trả lời của mình đến đây từ một chủ đề trùng lặp đã đóng Bạn có thể nhận ra nếu bạn là một lập trình viên tồi không? Chủ đề khác đã bị đóng khi tôi đang soạn phản hồi của mình. 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" hoặc "xấu", "lành mạnh" hoặc "điên rồ", "tốt" hoặc "xấu xa", "thông minh" hoặc "ngu ngốc", "béo" 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ể đưa 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 bây giờ 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!

3
John Tobler

Những người không biết các nguyên tắc như RẮN, DRY, 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ể. 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.

2
Giorgi

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 nào trong bộ sưu tập Java đượ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).

Các ứng dụng anh ấy viết trong hệ thống này có các menu thanh lite và sẽ mở một hình thức 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.

2
sal

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 ngôn ngữ MS-Access hoặc hội, đó 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.

2
Dan Williams

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.

2
Chankey Pathak

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

2
Gratzy

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.

2
tcrosley

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."

2
Robert Rossney

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

2
Nick Pierpoint

Ngày nay, nhiều lập trình viên tin rằng sự phức tạp này được quản lý tốt nhất bằng cách chỉ sử dụng một nhóm nhỏ các kỹ thuật được hiểu rõ trong các chương trình của họ. Họ đã soạn ra các quy tắc nghiêm ngặt về các chương trình biểu mẫu nên có, và những người nhiệt tình hơn trong số họ sẽ tố cáo những người phá vỡ các quy tắc này là những lập trình viên tồi

1
Pir Abdul

Một lập trình viên chỉ sao chép và dán mã từ những nơi khác và không hiểu cách mã thực sự hoạt động, được gọi là một lập trình viên tồi! Tôi thường thấy điều này với javascript.

1
Pir Abdul

Tôi nghĩ rằng cách duy nhất để lập trình viên có thể tệ trong lập trình là nếu anh ta ngừng lắng nghe những gì người khác nói.

Lập trình là về thông tin. Một người cần phải giữ cho đôi tai, và đôi mắt mở to.

Một lập trình viên chỉ có thể cải thiện bằng cách nhấn vào sách và làm việc chăm chỉ. Nhưng, bạn cũng nên tập trung vào việc học những điều mới, không học đi học lại nhiều lần (tìm kiếm những trải nghiệm mới trong lĩnh vực/ngành cụ thể của bạn).

Chúc may mắn.

0
Pablo