it-swarm-vi.com

Điều gì là huyền thoại ngớ ngẩn nhất về các vấn đề lập trình?

Nói cách khác ... Sự hiểu lầm phổ biến nhất và bực bội nhất về lập trình, bạn đã gặp phải là gì?

Những huyền thoại/quan niệm sai lầm phổ biến và lâu dài nào bạn tìm thấy khó để lập trình viên xua tan/sửa sai.

Xin vui lòng, giải thích tại sao đây là một huyền thoại.

101
Maniero

Điều đó bởi vì bạn là một lập trình viên, bạn biết cách sửa máy vi rút của người đó.

272
Neth

Một điều nhân sự phổ biến khiến tôi phát điên khi tôi tìm việc: giả định ngầm định rằng tất cả các kỹ năng mã hóa là ngôn ngữ cụ thể, rằng không có chuyên môn kỹ thuật phần mềm nào vượt qua các bộ lệnh. Đó là mười năm kinh nghiệm trong Java và năm năm khác trong Perl có nghĩa là bạn hoàn toàn vô dụng đối với một dự án sử dụng, giả sử, C #.

"Vâng, có một đường cong học tập. Nhưng tôi đã thực hiện các chuyển đổi khó hơn thế này. Tôi sẽ thỏa thuận với bạn, trả cho tôi 80% cho tháng đầu tiên và vào cuối thời gian đó nếu tôi không ... oh Đợi đã, chúng tôi thực sự không có cuộc trò chuyện này, vì khỉ nhân sự của bạn chỉ đơn giản là đã xóa ứng dụng của tôi. "

266
BlairHippo

Nếu bạn không gõ, bạn không làm việc.

Tôi tin rằng zombie nhìn chằm chằm và đi cà phê là điều cần thiết cho các lập trình viên sắp xếp mọi thứ trong đầu họ.

260
burnt_hand

rằng bạn có thể tăng tốc một dự án muộn, chỉ đơn giản bằng cách ném thêm người vào đó.

158
chrmue

Phần mềm viết đó rất dễ.

Làm thế nào để bạn giải thích tất cả các dự án chạy theo thời gian và ngân sách và con người (chính trị gia, phương tiện truyền thông, v.v.) vẫn ngạc nhiên, và khách hàng phàn nàn khi bạn nói với họ rằng "trang web nhỏ" của họ (hoặc bất cứ điều gì) sẽ thực sự mất 6 tháng để phát triển và tiêu tốn vài nghìn đô la (bảng Anh, Euro, [chèn tiền tệ lựa chọn])

Với những yêu cầu mờ nhạt và luôn thay đổi, đôi khi tôi nghĩ rằng thật tuyệt vời khi bất kỳ phần mềm nào cũng được hoàn thành!

Tôi biết nó phức tạp hơn thế một chút;)

132
ChrisF

Độ phức tạp của ứng dụng tỷ lệ thuận với độ phức tạp của giao diện người dùng. Theo lý do này, bạn sẽ có thể xây dựng Google hoặc Twitter vào cuối tuần.

114
JohnFx

Tất cả các lập trình viên đều giỏi toán. :-)

95
David Cary

Bất kỳ đứa trẻ tuổi teen nào hack máy tính đều tương đương (hoặc vượt trội) về kỹ năng với một lập trình viên làm việc kỳ cựu.

Cháu trai 14 tuổi của tôi rất giỏi với máy tính và tôi đang trả cho nó 10 đô la/giờ để cắt cỏ. Tại sao tôi phải trả cho bạn sáu con số để viết FaceBook tiếp theo?

95
JohnFx

Điều đó thời gian thực có nghĩa là nhanh chóng.

Nói rằng "Các gói cần được xử lý trong thời gian thực." là vô giá trị và cặp song sinh độc ác ... đang trả lời "X cần xảy ra nhanh như thế nào?" với "Thời gian thực" có thể ít hơn vô giá trị. .. giáp với ngu ngốc hơn là không biết gì.

Thời gian thực có nghĩa là, chỉ cần đặt, hàm Y đó sẽ luôn mất X lượng thời gian và bất kỳ sai lệch nào cho thấy một lỗi nghiêm trọng. Thời lượng của X không định nghĩa "thời gian thực", nó có thể là sáu micro giây hoặc sáu ngày. Rằng bạn có thể xác định hàm Y sẽ mất thời gian X định nghĩa "thời gian thực". Hệ thống thời gian thực được xác định theo định nghĩa này.

Vì vậy, gõ nó đi ..

69
Rusty

Tại sao các bạn không chỉ đơn giản là viết nó ngay lần đầu tiên, thay vì dành quá nhiều thời gian để nhập mã lỗi và sau đó đọc mã cố gắng tìm lỗi?

:-) :-) :-) :-)

69
David Cary

Nếu bạn chưa đi học đại học, bạn không phù hợp với công việc

64
user2528

Tối ưu hóa sớm đó có nghĩa là bạn không nên tối ưu hóa tất cả. Tôi đã thấy các cơ sở dữ liệu tồi tệ hơn vì không ai muốn xem xét hiệu năng (quan trọng đối với bất kỳ hệ thống cơ sở dữ liệu nào) trong thiết kế vì đó là tối ưu hóa sớm hơn bất kỳ vấn đề thiết kế cơ sở dữ liệu nào khác. Rác, có những kẻ giết người hiệu suất được biết đến, ngừng sử dụng chúng như là lựa chọn đầu tiên của bạn.

Một huyền thoại khác, quá khó để cấu trúc lại cơ sở dữ liệu. Không nhưng bạn phải xem xét làm thế nào để tái cấu trúc trong giai đoạn thiết kế để thực hiện nó một cách hiệu quả. Và BTW, bạn càng chờ đợi để khắc phục vấn đề hiệu năng dựa trên thiết kế gây phiền nhiễu đó, thì càng khó khắc phục.

Một huyền thoại xấu khác, thiết kế cơ sở dữ liệu nên phản ánh các nguyên tắc OOP. Không, cơ sở dữ liệu được thiết kế để hoạt động với các bộ không OOP nguyên tắc. Một số OOP mọi thứ sẽ gây ra các vấn đề hiệu suất khủng khiếp và những thứ khác chỉ là nỗi đau ngớ ngẩn trong các điều khoản cơ sở dữ liệu.

Cuối cùng, bạn nên thực thi toàn vẹn dữ liệu trong ứng dụng. Cơ sở dữ liệu sẽ vượt qua ứng dụng và sẽ mất các quy tắc khi ứng dụng được thay thế, các ứng dụng mulitple sẽ truy cập chúng và thường sẽ cần phải chạy các truy vấn trực tiếp để sửa những thứ không đi qua ứng dụng. Tôi chưa bao giờ thấy một cơ sở dữ liệu từ chối thực thi tính toàn vẹn dữ liệu trong cơ sở dữ liệu có dữ liệu tốt.

61
HLGEM

Đó là một số nguồn huyền thoại của thực hành tốt nhất tuyệt đối.

Không có sự sai lệch bao giờ có thể được biện minh.

Không có tài liệu nào tuyên bố định nghĩa một cái gì đó là một thực tiễn tốt nhất có thể được đặt câu hỏi.

53
Bill

Thực tế là tiếp thị dường như nghĩ rằng việc thêm một tấn các tính năng nhỏ sẽ làm việc ít hơn so với việc thêm một tính năng, nhưng khá nặng nề. Mà có lẽ là một trường hợp cụ thể hơn của quan niệm sai lầm rằng "chuyển đổi nhiệm vụ không có chi phí".

51
Giel

Mã nhận xét đó là không cần thiết hoặc "mã tốt không cần bình luận". Đôi khi bạn cần giải thích những gì một đoạn mã phức tạp đang làm. Hơn nữa, các phần bình luận của mã giúp bạn đọc lướt hiệu quả hơn nhiều.

50
DisgruntledGoat

Huyền thoại tồi tệ nhất: Nếu bạn lập trình trong một thời gian dài thì bạn có thể trở thành Quản lý dự án một cách dễ dàng.

Và rằng bạn nên trở thành một người quản lý dự án nếu bạn đã lập trình trong một thời gian dài.

50
Namwar Rizvi

Nếu chúng tôi sử dụng một cái gì đó ngoài Java, C # và C++ trong dự án của chúng tôi, chúng tôi sẽ không tìm thấy bất kỳ lập trình viên nào hỗ trợ nó.

50
P Shved

Java chỉ là C++ với các lớp khác nhau.

42
Gordon
33
TheLQ

Có lẽ điều nguy hiểm nhất tôi từng thấy, bởi vì nó được chấp nhận rất dễ dàng, là việc có thể viết mã nhanh là tốt, và do đó bạn càng nhanh chóng có thể mã hóa [chèn tính năng ở đây] bằng ngôn ngữ nhất định, ngôn ngữ càng tốt Là.

Đây là một ví dụ nghiêm túc về tối ưu hóa sớm, vì có nhiều công việc đi vào duy trì mã hơn là tạo nó. Điều này có nghĩa là việc viết mã dễ đọc, dễ hiểu và gỡ lỗi quan trọng hơn nhiều so với mã dễ viết nhanh và tạo điều kiện cho mã dễ đọc là một phép đo chất lượng ngôn ngữ hữu ích hơn nhiều.

33
Mason Wheeler

rằng là một lập trình viên, bạn biết mọi thứ về xu hướng phần cứng mới nhất, ép xung, mod trường hợp, v.v ... bạn bè và người thân tư vấn cho bạn khi họ mua bánh răng của họ.

31
setzamora

Bài học sản xuất có thể được áp dụng cho quy trình phát triển phần mềm.

31
Mike King

Rằng khi các lập trình viên nói rằng rất khó để làm/đơn giản là không thể, HR nghĩ rằng họ lười biếng và không có động lực

30
koos303

Phải có một chương trình nguồn mở cho doanh nghiệp của tôi. Bạn không thể tải nó xuống và Tweak theo yêu cầu của tôi.

28
Tim Murphy

Tôi đã có nhiều hơn một người hỏi tôi về việc lập trình chỉ để nhận ra giữa chừng cuộc trò chuyện mà họ thực sự nghĩ rằng chúng tôi lập trình trực tiếp trong hệ nhị phân hoặc sử dụng các ký hiệu toán học.

Tôi không biết nếu tôi muốn xua tan huyền thoại đó, nó khiến tôi trông thực sự thông minh!

27
JohnFx

Tôi nghĩ quan niệm sai lầm lớn nhất là việc viết mã xuống một cách dễ dàng hơn là có thể đọc và hiểu mã.

26
LennyProgrammers

Lập trình cũng giống như công việc dòng hội. Bạn đang làm việc trên một sản phẩm trong một thời gian nhất định (có thể với đồng nghiệp) và cuối cùng bạn gửi nó. Cũng giống như xây dựng một ngôi nhà bằng gạch.

Contra: Lập trình chứa rất nhiều sáng tạo và lập kế hoạch. Đó là nghệ thuật. Giống như thợ xây, cũng là một lập trình viên biết sự khác biệt giữa việc tạo hình một viên gạch và lên kế hoạch cho cả một nhà thờ.

24
Josua Schmid

Chuyển một chương trình sang C++ sẽ tự động làm cho nó chạy nhanh hơn.

24
JohnFx

Bất kỳ môi trường lập trình nào với một nhà thiết kế trực quan nào đó sẽ làm cho nó để người dùng doanh nghiệp có thể "viết" chương trình và các lập trình viên thực tế không cần thiết.

21
Jesse C. Slicer

Tái sử dụng OOP. Đó là sai lầm lớn nhất được tiếp thị trong lập trình.

20
clrod

Học cú pháp là phần khó.

19
palto

2 huyền thoại tôi muốn tiết lộ. Rất nhiều bạn bè của tôi không hiểu rằng Java và JavaScript hoàn toàn khác nhau và rất nhiều người không lập trình mà tôi biết không hiểu rằng có nhiều hơn một ngôn ngữ. Một trong những người bạn của tôi chỉ mới tham gia lập trình và cần sự giúp đỡ của tôi, 'dĩ nhiên anh ta thậm chí không biết mình đang làm việc với ngôn ngữ nào.

Cả hai đều đến với tôi rất nhiều.

15
Doug

Việc chỉ định mức độ ưu tiên khác với "1" có nghĩa là nhiệm vụ sẽ không bao giờ được thực hiện.

Tôi đã có một người quản lý yêu cầu tôi tùy chỉnh công cụ theo dõi lỗi với các ưu tiên 1a, 1b, 1c, 1d và 1e để anh ta có thể chỉ định mọi thứ là một số biến thể của ưu tiên 1, nhưng chúng tôi vẫn có thể tổ chức công việc.

Và vâng, tôi đã vượt qua tất cả các vấn đề "ưu tiên 1". Nhưng trước khi tôi có thể tiến hành các vấn đề vẫn còn ưu tiên 2-5, người quản lý đã cho tôi gán lại các ưu tiên của các vấn đề đó vào năm cấp độ ưu tiên 1.

(Tôi nhận ra huyền thoại này không cụ thể để lập trình, nhưng điều đó đúng với một số câu trả lời khác về chủ đề này.)

15
Bill Karwin

Miễn là máy tính hiểu mã bạn nhập, đó mới là vấn đề. Do đó, gõ bình luận và sử dụng tên biến dài hơn hai chữ cái là một sự lãng phí thời gian. :-(

13
David Cary

Hình thức bàn phím có liên quan đến khả năng lập trình. Nghiêm túc mà nói, một trong những giáo viên ở trường trung học của tôi nói với tôi, "Bạn không thể viết mã nhanh nếu bạn không thể gõ nhanh." Câu trả lời của tôi là, "Giống như nói rằng tôi chỉ có thể viết Tiểu thuyết vĩ đại của Mỹ nếu tôi làm điều đó một cách khó hiểu."

12
quanticle

Đó là lập trình viên nguyên mẫu:

  • đi làm sau 11 giờ sáng
  • không uống gì ngoài Mountain Dew
  • thích đồ ăn Ấn Độ hoặc sushi
  • sống một mình theo lựa chọn (có cha mẹ và/hoặc dưới tầng hầm)
  • thức đến 3 giờ sáng để chơi trò chơi điện tử
12
Kelly S. French

Ký hiệu Hungary đó chỉ có nghĩa là bạn đặt tiền tố tên biến với một loại (như int iArraylength = 5;) thay vì loại dữ liệu mà nó chứa (như int xcTextfield = getTextfield (). Tọa độ.x;)

"Hệ thống ký hiệu Hungary"! = "Ứng dụng ký hiệu Hungary"

10
Zaz

Lỗi phần mềm miễn phí. Sau này tôi mới biết rằng mọi chương trình vẫn sẽ chạy với Bugs và toàn bộ trò chơi là về việc hoàn thành các Yêu cầu của khách hàng.

10
Gopi

Rằng bất kỳ mã nào được viết bằng ngôn ngữ OOP (C #, C++, Java) bởi bất kỳ ai đều được tự động hướng đối tượng và "Tái sử dụng".

Đó không chỉ là một lần khi tôi được yêu cầu sử dụng lại một nghìn khối mã hoặc một lớp trong một kiến ​​trúc không có bất kỳ mẫu nào ngoại trừ tính kế thừa (thậm chí không được tính). Rõ ràng, dán sao chép cũng được tính là tái sử dụng mã tốt cho bất kỳ ai không biết sự khác biệt giữa ngôn ngữ OO và OOP.

Một TDWTF yêu thích thường xảy ra thường xuyên: Từ chối mã

9
Jonn

Các ứng dụng web đó có thể lên tới "7x24."

Hỏi bất kỳ người kinh doanh nào thời gian chết được cho phép và họ luôn nhấn mạnh 100% thời gian hoạt động. Mặc dù vậy, thời gian chết 1 phút mỗi tuần vẫn là 99,99% và gần như không thể thực hiện được đối với một tổ chức nhỏ hơn một tiện ích chính.

9
bmb

Tất cả các chương trình được viết bằng C/C++ sẽ thực thi nhanh hơn các chương trình tương đương Java/C #.

7
Mohan Narayanaswamy

Rằng có một công cụ/giải pháp/câu trả lời "tốt nhất" cho bất kỳ vấn đề/câu hỏi nào

7
Murph

Huyền thoại lớn nhất là nó dễ dàng.

7
Fortyrunner

Các lập trình viên đã trở thành nhà quản lý nói:

"Ba tuần?! Tôi đã mã hóa trong quá khứ, làm thế nào khó có thể như vậy?"

6
Arcturus

Đó là bất kỳ ThS. với một khóa học lập trình là đủ để được thuê làm nhà phát triển phần mềm.

6
FeatureCreep

Điều đó bởi vì bạn là một lập trình viên, bạn biết cách sửa máy photocopy.

6
Jeff Siver

Những ý tưởng sai lầm đang lan rộng trong thời gian dài

Có một niềm tin rất rộng rãi giữa các lập trình viên về cách tìm ra các vấn đề về hiệu năng. Đó là để tìm thấy chúng, bạn phải đo chúng.

Ví dụ đơn giản nhất là một vòng lặp vô hạn (không mong muốn). Phải mất 100% thời gian, làm những việc hoàn toàn không cần thiết.

Làm thế nào để bạn tìm thấy vấn đề? Bạn nhận được nó dưới một trình gỡ lỗi và tạm dừng, tạm dừng hoặc làm gián đoạn nó. Sau đó, bạn nhìn vào ngăn xếp, bởi vì bạn biết vòng lặp ở đâu đó trên đó. Bạn đã bắt gặp nó trong hành động. Bạn đã đo chưa? hoặc chỉ tìm thấy nó?

Giả sử nó không phải là một vòng lặp vô hạn, nó chỉ mất nhiều thời gian hơn bạn nghĩ là cần thiết. Giả sử công việc không cần thiết là dưới 100%, như 90%, 50% hoặc 20%. Đó là cùng một ý tưởng. Nếu bạn tạm dừng nó, phần trăm đó là cơ hội mà bạn sẽ nắm bắt được trong hành động. (Bạn không cần phải biết bao nhiêu phần trăm để bắt nó.)

Chỉ cần chắc chắn, bạn có thể tạm dừng nó nhiều lần. Ngay khi bạn thấy nó đang làm gì đó, chỉ trong vài hai mẫu, bạn có thể thay thế bằng thứ gì đó nhanh hơn, bạn có thể sửa nó để tăng tốc Nice. Không chỉ vậy, bạn vừa làm cho bất kỳ vấn đề nào khác dễ tìm thấy hơn, vì thời gian ngắn hơn và chúng chiếm phần trăm lớn hơn. Điều này có thể "Snowball" cho đến khi mã rất gần với tối ưu.

Tất nhiên, nếu bạn muốn đo lường vấn đề, chỉ cần lấy thêm mẫu, nhưng đó không phải là điều kiện tiên quyết để tìm ra nó.

Mọi người nói với tôi, mong muốn, đây là những gì các trình lấy mẫu lấy mẫu làm nhưng làm nó tốt hơn. Nhiều người thà tranh luận về vấn đề còn hơn là tự mình nhìn thấy.

4
Mike Dunlavey

Đó là một người quản lý tốt hơn là một lập trình viên. Là một người quản lý là BORING. Bất cứ ai đã đi vào quản lý thuần túy chưa bao giờ yêu thích lập trình.

4
zhenka

Máy tính và phần mềm cải thiện quá trình làm việc của chính nó.

4
aasc

Trong số các lập trình viên: Delphi đó đã chết, sắp chết hoặc đang hỗ trợ cuộc sống.

3
Peter Turner

Người quản lý biết jack-squat về mã mà nhà phát triển của anh ấy/cô ấy đang viết.

3
Mike Mooney

Có một ngôn ngữ gọi là C/C++

Hoặc các ngôn ngữ gần nhau đến mức các kỹ năng có thể thay thế cho nhau.

3
Martin York

Phần mềm viết đó thực sự là về viết mã.

2
Craig Norton

Nhiều người có xu hướng nghĩ rằng JavaScript tương tự như C++ và không hiểu rằng nó thực sự sử dụng kế thừa nguyên mẫu.

1
diadem

Ngôn ngữ lập trình đó luôn thay đổi.

Điều này có thể đã có từ lâu trong quá khứ ...
[.__.] Nhưng ngày nay, những thay đổi chủ yếu là các tính năng bổ sung cố gắng không phá vỡ mã hiện có.

1
Tamara Wijsman

Tại sao các lập trình viên cứ khăng khăng viết lỗi? (Đến từ người tiếp thị + người kiểm tra không bao giờ có thể nhận được báo cáo lỗi đúng).

1
Dorin Lazăr
  • Điều đó OO có nghĩa là chất lượng.
  • Rằng cách tiếp cận OO là cách tiếp cận phù hợp.
  • Rằng công việc của một lập trình viên là viết mã.
  • Ngôn ngữ đó có vấn đề.
0
Fredy

Toàn bộ tâm lý hollywood (vì không có tên hay hơn) rằng bất cứ khi nào một lập trình viên trong một bộ phim/phim truyền hình lên tiếng, anh ta cần phải nói rõ mọi công nghệ anh ta cần ( Tôi cần một PHP front-end và MySQL back-end !!! 11 ) ... Và sau đó một số điều nữa không có ý nghĩa gì tại tất nhiên rồi.

Nếu tôi nói như thế này có lẽ tôi sẽ bị đá.

0
Andreas Johansson

Sử dụng tiếng Anh (hoặc ngôn ngữ mẹ đẻ của bạn) để mô tả một vấn đề:

là hữu ích hơn so với việc cung cấp một ví dụ có thể biên dịch được của mã mà minh họa vấn đề.

0
Martin York