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

101

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

Những huyền thoại / quan niệm sai lầm phổ biến và lâu dài nào mà bạn thấy khó để các 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.

experience  self-improvement  code-quality  mistakes 
— bigown
nguồn
24
Tôi muốn thấy Mythbuster đảm nhận một số trong số này.
— bọt biển
8
Bất cứ ai cũng lên cho một kênh YouTube của Mythbuggers? :-)
— Tamara Wijsman
1
Ooooh, MythBuster và điều kiện chủng tộc! Meesa thích!
@TomWij thật tuyệt vời khi có một trang web với tên như vậy!
— Junior M

Câu trả lời:

272

Điều đó bởi vì bạn là một lập trình viên, bạn biết cách khắc phục máy bị virus của người đó.

— Neth
nguồn
34
Điều khoản tương tự xe hơi / ra ngoài: "Tôi là một tay đua không phải là thợ máy."
— Peter Boughton
15
Truyện tranh này có liên quan: theoatmeal.com/comics/computers
— lunixbochs
16
— back2dos
21
@Tim nếu cô ấy có thể nấu ăn, hãy bắt đầu tình nguyện cô ấy phục vụ các bữa tiệc của bạn bè
— Steven A. Lowe
19
Không phải là tôi không biết làm thế nào ... Tôi không muốn lãng phí hàng giờ để sửa máy mà bạn sẽ hỏng trong 2 tuần nữa.
— ChaosPandion
267

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à đặc thù ngôn ngữ, 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 về 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. "

— BlairHippo
nguồn
91
+ INF cho khỉ nhân sự.
— Rusty
67
Tôi đã có một anh chàng nhân sự từ chối vai trò của tôi vì tôi biết C # như thế nào, nhưng anh ta đang tìm kiếm một người có thể viết mã trong dotNet.
— burnt_hand
11
@burnt_hand: Vâng, tôi biết dotNet. Tôi cũng biết Excel và Internet Explorer. Tôi có thể haz hợp đồng bây giờ?
— Alan Plum
Mặc dù tôi đồng ý rằng có sự trùng lặp rất lớn với cú pháp, cấu trúc, SDLC, v.v., giữa Java và C #, nếu chúng cung cấp cho bạn bất kỳ bài kiểm tra C # hợp lý nào trong cuộc phỏng vấn của bạn, bạn sẽ trả giá như thế nào?
— JBRWilkinson
2
@Kyralessa - Tôi nghĩ rằng bây giờ tôi đã biết đủ về lý thuyết cơ bản về điện toán và chức năng của máy tính để không mắc lỗi cơ bản trong bất kỳ ngôn ngữ lập trình nào. Tôi có thể đọc tài liệu. Tuy nhiên, điều mà một người thuê ngôn ngữ cụ thể với kỹ năng / ý chí / kỹ thuật hạn chế là mắc các lỗi cơ bản trong cấu trúc, thiết kế, tính chính xác, khả năng mở rộng, độ tin cậy và khả năng duy trì của chương trình có khả năng sẽ phải trả số tiền lớn để khắc phục. Nếu bạn không mất tất cả khách hàng do chất lượng phần mềm thấp trong thời gian này (giả sử dự án của bạn thực sự có được ở bất cứ đâu).
— flamingpenguin
261

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 dạo 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ọ.

— bàn tay bị cháy
nguồn
9
Trang lên, trang xuống ... trang lên, trang xuống ...
— adolf tỏi
139
Tôi không được trả tiền để đánh máy, tôi được trả tiền để suy nghĩ. Tôi cung cấp đánh máy như một phần thưởng.
— Kevin Laity
11
— Tobias Kienzler
11
Đây là lý do tại sao tôi không nghĩ rất cao về các thị trường tự do trực tuyến cung cấp ghi âm "thời gian làm việc" với một screengrabber và webcam. WTF? Nếu bạn nghĩ rằng trích dẫn của tôi là tốt, tại sao bạn quan tâm chính xác những gì tôi làm trong thời gian tôi đang sạc?
— Alan Plum
10
"Nếu tôi có nhiều thời gian hơn để viết mã, tôi sẽ viết ít dòng hơn." - cất cánh trên trích dẫn của Abe Lincoln.
— JeffO
158

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

— chrmue
nguồn
28
Ah, từ Tháng huyền thoại. vi.wikipedia.org/wiki/The_Mythical_Man-Month
— spong
2
Trên thực tế, uh, bạn có thể. -1 (yeah, kìa, một người mang huyền thoại!)
— P Shved
63
Chúng tôi sử dụng một câu nói đầy màu sắc "Bạn không thể đưa 9 phụ nữ vào phòng và sinh con trong một tháng".
— Walter
10
Tuần trước chúng tôi đã thêm 4 người không có kinh nghiệm dự án để "giúp" đáp ứng một lịch trình không thực tế. Báo cáo tuần này từ dự án dẫn đến danh sách quản lý cấp trên: "Lịch trình trượt do nguyên nhân: Giảm hiệu quả do học tập của các thành viên nhóm mới" và "Kế hoạch phục hồi: Tiếp tục thêm nhiều người khi có cơ hội." Không thể tin được.
— HỎI
7
@Walter, nhưng bạn có thể có 9 em bé trong 9 tháng và một đội bóng chày nhỏ trong 7 năm.
— Huperniketes
132

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;)

— ChrisF
nguồn
11
Và đây là khi họ cố gắng đưa sự phát triển đến các lựa chọn thay thế ngoài khơi rẻ hơn. Chỉ để tìm hiểu nhiều về sau nó hóa ra còn đắt hơn. Và ít hơn những gì họ thực sự cần, bởi vì những thách thức về thể chất và giao tiếp giữa nhóm phát triển và khách hàng.
— 7wp
1
Đây không chỉ là vấn đề giữa các nhà quản lý, mà cả chính các lập trình viên. Vấn đề thực sự có xu hướng là thời gian không tích cực viết mã thường bị bỏ qua (có thể là do huyền thoại định lượng năng suất LỘC = phổ biến rộng rãi).
— Alan Plum
3
Không phải là các yêu cầu thay đổi, đó không phải là những gì họ nghĩ họ muốn.
— JeffO
1
Tôi đã có người bỏ qua lập trình là "chỉ là một loạt các câu lệnh 'nếu'". OK, có lẽ đó là ... trong trường hợp đó, thơ ca "chỉ là một loạt các từ" ... sản xuất phim là "chỉ là một loạt các cảnh", v.v.
— JoelFan
2
Tôi đã làm việc cho kiểu người quản lý, người nghĩ rằng bit lập trình là phần dễ dàng của công việc. Và không, anh ta không có kinh nghiệm lập trình.
— Thuyền trưởng Sensible
114

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

— JohnFx
nguồn
2
Đây là sự thật, tôi có thể xây dựng Twitter và Google trong một ngày cuối tuần. Đây không phải là phần mềm phức tạp; đối với Google, thuật toán tìm kiếm của họ (tương đương với thư viện mã hoặc trình điều khiển cơ sở dữ liệu) và Twitter (cho đến 1,5 năm qua) rất đơn giản, chỉ có vấn đề về khả năng mở rộng và cơ sở dữ liệu là phức tạp. Bây giờ nó phức tạp hơn (đòi hỏi nhiều nhân viên hơn), nó cũng có giao diện người dùng phức tạp hơn nhiều và nhiều giao diện người dùng hơn.
— orokusaki
3
Tôi nghĩ rằng tôi đã đọc nó trên blog của Joel Spolsky nhưng bài viết được đề cập chỉ hiển thị dưới dạng tiến trình GUI liên quan đến tiến trình back-end. Bằng cách đó, bạn có thể đưa ra một ước tính thực tế về sự tiến bộ cho những anh chàng tóc nhọn, những người quá ngu ngốc để hiểu rằng hầu hết các chương trình bao gồm nhiều hơn nhiều so với kẹo mắt.
— Evan Plaice
3
1+ Đã có lúc tôi giới thiệu một dự án liên quan đến SharePoint (một addon đa ngôn ngữ) cho ông chủ cũ của tôi, đã dành hàng giờ để làm việc với mã phụ trợ phức tạp. Kết quả cuối cùng không được thực hiện nhiều trên UI, điều này khiến sếp tôi tin rằng không có nhiều việc đã được thực hiện trong dự án. Điều đó làm tôi bực mình. Anh ta không phải là người ngồi trên bàn phím trong nhiều giờ cố gắng khắc phục sự kỳ quặc của SharePoint, cũng như logic thay thế văn bản.
— Jason Evans
1
Bạn không ghét khi một số yêu cầu lớn, gần như không thể, được đặt ra là "bạn có thể thêm nút để thực hiện ..."
— JoelFan
Tôi tự hỏi những gì tôi đã làm trong vài năm qua. Tất cả những dự án tôi làm việc toàn thời gian nên đã hoàn thành ngay lập tức, bởi vì chúng không có bất kỳ giao diện người dùng nào cả. :-)
— Bart van Ingen Schenau
95

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

— David Cary
nguồn
Bình luận viên : ý kiến ​​có nghĩa là để tìm kiếm làm rõ, không phải để thảo luận mở rộng. Nếu bạn có một giải pháp, hãy để lại một câu trả lời. Nếu giải pháp của bạn đã được đăng, xin vui lòng nâng cấp nó. Nếu bạn muốn thảo luận câu hỏi này với người khác, vui lòng sử dụng trò chuyện . Xem FAQ để biết thêm thông tin.
Tôi nghĩ rằng các khả năng trong toán học bằng cách nào đó có liên quan đến kỹ năng lập trình.
— Diego
@Diego: Mặc dù vậy không nhất thiết có nghĩa là tất cả các lập trình viên đều giỏi toán.
— Omega
95

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?

— JohnFx
nguồn
5
Họ có thể đang ở trong môi trường của riêng họ, tức là tự làm việc theo tiêu chuẩn của riêng họ. Đặt họ vào một đội nơi họ phải giao tiếp và đó là nơi họ phải chịu đựng.
— tỏi adolf
36
Câu hỏi truy cập có thể là: "Bạn sẽ trả anh ta những gì để xây dựng ngôi nhà của bạn?"
7
Một đứa trẻ không có trình độ nhưng viết mã gọn gàng có thể đánh bại ông Spaghetti bất cứ ngày nào.
— Zaz
13
Tôi đổ lỗi cho hollywood vì điều đó
— MAK
6
Khi tôi bắt đầu, tôi đã hy vọng rằng những gì tôi đã tự dạy và nhặt được ở uni sẽ chỉ là sự khởi đầu và tôi sẽ làm việc với những người có kinh nghiệm hơn, là những lập trình viên giỏi hơn và những nhà phát triển hiểu biết hơn, và tôi học hỏi rất nhiều từ họ. Kinh nghiệm đã dạy tôi cách khác. Điều đó thực sự quan trọng, nhưng không có kỹ năng và đam mê, kinh nghiệm chỉ là lãng phí thời gian.
— Peter Boughton
69

Đó là thời gian thực có nghĩa là nhanh.

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 ... trả lời "X cần phải xảy ra nhanh như thế nào?" với "Thời gian thực" có lẽ ít hơn vô giá trị ... giáp với sự 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. 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 ..

— Rỉ
nguồn
thời gian thực = gần thời gian
— brian chandley
4
Tôi luôn nghĩ thời gian thực có nghĩa là bất cứ điều gì đang xảy ra đều xảy ra khi bạn yêu cầu, không phải là tham chiếu đến thời gian thực hiện.
— burnt_hand
14
Đây có lẽ chỉ là một trong những trường hợp mà một khái niệm được đặt tên xấu góp phần gây nhầm lẫn.
— JohnFx
2
@JohnFx Vâng đặt. Các khái niệm cần bối cảnh.
— Rusty
2
@Richard: Thật vậy, iTunes luôn mất vài phút trước khi chơi bất cứ thứ gì. Ồ, đó không phải là ý bạn sao?
— cấu hình
69

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?

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

— David Cary
nguồn
34
Thành thật mà nói, đó là một câu hỏi hay. Thời gian dễ nhất để làm cho mã tốt là khi nó được viết lần đầu tiên.
— DJClayworth
10
Chúng tôi có một cài đặt trong cấu hình ứng dụng: <add Key = "Bugs" Value = "true" />
— burnt_hand
1
@DJClayworth - không phải lúc nào cũng hoạt động. Trong một số trường hợp, vấn đề quá lớn, không rõ ràng hoặc chỉ đơn giản là khó đến mức ngay cả khi "gần đúng" lần đầu tiên là quá nhiều để mong đợi. Trong trường hợp như vậy, tốt hơn là viết "vết cắt đầu tiên" không hoàn toàn sai, hơn là dành nhiều ngày / tuần / tháng để thiết kế và thiết kế lại không ngừng trong lần thử đầu tiên.
— Stephen C
Đây có thể là phiên bản của giáo dân "Tại sao các bạn không làm TDD?" Mà, công bằng mà nói, là một câu hỏi hay, nếu quá đơn giản để phát triển thế giới thực.
— Dan Ray
1
@Stephen C: có, nhưng có một sự khác biệt trong việc làm cho nó hầu như đúng (thay vì hoàn toàn đúng) so với làm hầu hết mọi thứ trái và phải để làm cho nó hoạt động. Tôi biết đây không phải là những gì bạn nói nhưng tôi vẫn nghĩ nó cần phải được nói ra.
— n1ckp
65

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

— người dùng2528
nguồn
27
Ngoài ra: một lập trình viên có bằng cấp tốt hơn một lập trình viên không có và nên được trả lương tương ứng. Điều tương tự có lẽ đi với chủ nghĩa tuổi tác và phân biệt giới tính. Kiểu vô nghĩa này làm tôi bực mình - nếu bạn không biết cách viết mã tốt, tôi không quan tâm đến việc bạn đã đi đâu và làm gì. Đây có thể là một trường hợp khác về văn hóa lập trình / mọt sách (skill == thẩm quyền) xung đột với văn hóa doanh nghiệp (xếp hạng == thẩm quyền).
— Alan Plum
1
Tuy nhiên, những người giảng dạy tại Đại học dường như cũng nghĩ rằng họ có thể khái quát hóa hành vi của các lập trình viên và dự án bằng cách quan sát cách sinh viên vận hành khi hợp tác. Truyền thông của ACM tốt cho 4 - 6 bài báo như vậy mỗi năm.
— MIA
1
@Billy Làm thế nào xung quanh đây, nơi bằng tốt nghiệp đại học có nghĩa là jack, nhưng bằng tốt nghiệp đại học sẽ cấp cho bạn tất cả mọi thứ? Cả hai đều đi học, cả hai đều tốt hơn so với người kia, nhưng có một sự khác biệt về mặt xã hội học
— Tarka
4
@Billy: ở Canada, trường đại học cấp bằng cho bạn và bằng đại học cấp cho bạn bằng cấp. Các trường đại học giống như "trường học nơi bạn học những thứ thực tế". Hãy nghĩ rằng trường cao đẳng cộng đồng ở Mỹ so với trường cao đẳng / đại học bình thường. Ở đây họ thường có các chương trình ứng dụng chuyên ngành hai năm. Bạn không thể lấy bằng cử nhân (thạc sĩ, v.v.) từ trường đại học. Về cơ bản, bạn sẽ học đại học để học cách viết phần mềm và vào đại học để học về khoa học máy tính. Bằng đại học được ưu tiên mạnh mẽ hơn nhiều trong việc tuyển dụng.
— Adam Lear
4
Các trường đại học dạy ít nhất một điều quan trọng: tư duy . Điều này rất quan trọng, nhưng những người không biết rằng ... tốt, không biết điều đó.
61

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 lâu để 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, 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 phải là nguyên tắc OOP. Một số điều OOP 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.

— HLGEM
nguồn
+1 đặc biệt cho các ý kiến ​​xung quanh kiểm tra tính toàn vẹn cơ sở dữ liệu.
— Frank Shearar
+1 Đặc biệt cho đoạn cuối. Tôi đã đánh trống đó hơn một lần.
— Nhị phân nhị phân
5
+1 cho đoạn đầu tiên. Tối ưu hóa sớm là gốc rễ của mọi tội lỗi; viết mã xấu không có lý do đẫm máu thậm chí còn tồi tệ hơn.
— cấu hình
3
"Một số điều OOP 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" - bạn có thể nói điều đó không? Tôi biết về OOP, nhưng không biết nhiều về cơ sở dữ liệu và tôi quan tâm đến việc tôi có thể mang ý tưởng từ bên này sang bên kia bao xa.
— Tom Anderson
@HLGEM Tôi cũng sẽ quan tâm đến các ví dụ @Tom đang tự hỏi về ...
— Armand
53

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

— Hóa đơn
nguồn
1
một thành viên trong nhóm tốt hơn các quản lý của bạn ...
— Bill
5
Bạn có thể chuyển tiếp tài liệu đó cho tôi?
— HỎI
1
Hoàn toàn đồng ý. Ai quan tâm nếu bạn trộn các tab và khoảng trắng trong mã Python?
— Zaz
4
@Josh - ai đó phải xem mã nguồn của bạn bằng chuỗi công cụ có ý tưởng khác nhau về vị trí của các tab.
— Stephen C
1
Tôi hiểu "đó là cách thực hành tốt nhất" là "tôi không thể biện minh cho điều này". Tôi chắc chắn sử dụng nó theo cách đó bản thân mình.
— Tom Anderson
51

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

— Giel
nguồn
12
Và điều thú vị hơn nữa là tiếp thị không có bất kỳ ý tưởng nào là tính năng dễ dàng và bị nguyền rủa gần như không thể.
— derobert
4
@derobert Chính xác, tôi thường có kinh nghiệm rằng một số người tiếp thị quan tâm hơn trong thực tế rất ngại hỏi về một số tính năng đơn giản / dễ dàng mà họ nghĩ là rất khó thực hiện. Mặc dù tôi trải nghiệm điều ngược lại thường xuyên hơn: đây là một loạt các tính năng X "dễ dàng" mà chúng tôi đã bán cho khách hàng, vui lòng hoàn thành nó vào ngày hôm qua ....
— Giel
50

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 phải 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.

— Bất mãn
nguồn
14
@DisgruntledGoad - Mặc dù vậy. Sự hiểu lầm trong "huyền thoại" này xuất phát từ việc quá nhiều lập trình viên coi mã khó hiểu nguyên khối của họ là "tốt". if user.is_logged_in: print('Welcome')không cần bình luận.
— orokusaki
3
@orokusaki Không phải mọi thuật toán đều đơn giản.
— Jouke van der Maas
25
@orokusaki bạn đang nhầm "mã tốt không cần bình luận" với "mã đơn giản không cần bình luận". Mã tốt không phải lúc nào cũng đơn giản.
— DisgruntledGoat
3
@Jouke van der Mass: tất nhiên. Nhưng không quan trọng thuật toán phức tạp như thế nào, mục tiêu là thể hiện thuật toán một cách đơn giản. tức là mã tốt biểu thị các thuật toán phức tạp, quy tắc, tối ưu hóa, theo cách dễ hiểu và đơn giản. Thể hiện những điều đơn giản chỉ đơn giản là tương đối dễ dàng. Thể hiện những điều phức tạp chỉ đơn giản là nơi kỹ năng nằm.
— flamingpenguin
2
@orokuskai: mã tốt thì đơn giản. Những điều nó đang làm có thể phức tạp nhưng sự đơn giản (thanh lịch) của mã là điều làm cho nó tốt theo quan điểm của tôi! Tất nhiên, mã làm rất nhiều thứ khác và mã rác có thể giúp bạn kiếm được nhiều tiền. Nhưng mục tiêu của tôi là viết mã đơn giản ngay cả trong các tình huống phức tạp.
— flamingpenguin
50

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.

— Namwar Rizvi
nguồn
3
Hoặc thậm chí tệ hơn, nếu bạn chưa bao giờ lập trình hoặc quản lý một dự án lập trình, đọc một vài cuốn sách và sẽ làm cho phần mềm xảy ra một cách kỳ diệu. Đã đi xuống con đường đó với một PM trước đó và không quan tâm lặp lại nó miễn là tôi còn sống.
— Evan Plaice
4
Thậm chí tệ hơn: Vì tất cả các lập trình viên tuyệt vời trong nhóm thích viết mã hơn viết báo cáo, chúng tôi nên quảng bá lập trình viên tầm thường lên Quản lý dự án. Ý nghĩ là anh ta sẽ "đủ kỹ thuật". Thực tế là anh ta cuối cùng là một bộ lọc thông tin giữa nhóm và quản lý cấp trên.
— HỎI
2
Ngoài ra: nếu bạn là lập trình viên giỏi nhất, rõ ràng bạn nên trở thành người quản lý dự án và từ đó hãy ngừng thực hiện bất kỳ chương trình thực tế nào! Không, cảm ơn bạn rất nhiều, nhưng tôi vẫn sẽ tăng lương. Lưu ý: Tôi không nói về việc trở thành một dẫn lập trình viên hoặc bất cứ điều gì như vậy, tôi đang nói về các nhà quản lý người nghĩ rằng đó là một ý tưởng thông minh để thúc đẩy mọi người mức độ đủ bất tài.
— Alan Plum
1
Còn được gọi là Nguyên tắc Peter. vi.wikipedia.org/wiki/Peter_Principl
— Spoike
thực sự nói tốt
— Michael Easter
50

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

— Pavel Shved
nguồn
Tôi chưa bao giờ nghe về điều đó, nhưng nó hợp lệ. Tất nhiên nếu bạn sử dụng một ngôn ngữ tối nghĩa thì nó sẽ xảy ra.
— Maniero
5
@bigown, "tối nghĩa"? Làm thế nào tối nghĩa? TCL có bị che khuất không? Haskell? Pascal (Delphi)? Con trăn? Tôi nghĩ rằng chúng không tối nghĩa. Nhiều người nghĩ rằng chúng là như vậy và chỉ một nhóm ngôn ngữ rất hẹp (C ++, C # và Java) mới được phép phát triển "nghiêm túc".
— P Shved
5
@bigown: oh, ý bạn là tối nghĩa như COBOL? : p
— AnonJr
2
Tôi đã từng làm việc cho một công ty nhỏ làm mã Objective-C trên Linux. CEO - người không phải là kỹ sư nhưng có một số kiến ​​thức kỹ thuật - không thể tin rằng có những lập trình viên ObjC xung quanh hoặc bất kỳ ai khác sử dụng nó. Trong thực tế, họ không bao giờ có bất kỳ vấn đề nào khi thuê các nhà phát triển giỏi.
4
Tôi đã đọc một lập luận hoàn toàn ngược lại là đúng: đối với các ngôn ngữ tối nghĩa (hoặc ít nhất là không quan trọng về mặt thương mại) nhưng thú vị, vui vẻ và thú vị (trong bối cảnh đó có nghĩa là Python và Ruby), có nhiều lập trình viên hơn công việc. Thêm vào đó, tất cả họ là những người thích ngôn ngữ thú vị, vui vẻ và thú vị, vì vậy họ phải thông minh. Vì vậy, thực sự, làm việc trong Python có nghĩa là bạn sẽ dễ dàng thuê các lập trình viên thông minh hơn so với khi bạn làm việc trong Java. Không biết tôi có tin không, nhưng ít nhất nó cũng hợp lý như ý tưởng chính thống!
— Tom Anderson
42

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

— Gordon
nguồn
57
+1 Tôi đã từng có một người phỏng vấn hỏi tôi, "sự khác biệt giữa C ++ và Java là gì?" Vì vậy, tôi liệt kê một số khác biệt. Trình biên dịch gốc so với JVM, tiêu chuẩn ANSI so với độc quyền, bộ sưu tập rác, trình nạp lớp, v.v. Anh gầm lên, "SAU! Không có gì khác biệt! Chúng giống hệt nhau!" Anh ta không phải là một sinh viên, anh ta là giám đốc kỹ thuật.
— Bill Karwin
11
@Bill, câu trả lời của tôi sau đó sẽ là "vậy thì tại sao lại đề cập đến chúng với những cái tên hoàn toàn khác nhau?"
— Jesse C. Choper
2
@Bill, vậy bạn thi trượt và được tuyển dụng?
20
Câu trả lời của tôi sẽ là "Tạm biệt."
— Đánh lừa
6
@Foole Ý bạn là System.exit (1)?
— Barry Brown
33

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ể viết mã [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.

— Bánh xe Mason
nguồn
14
đây chính xác là những gì đã xảy ra với một trong những sản phẩm mà công ty tôi làm việc; phát triển vội vã được xem là rực rỡ. Sản phẩm TÌM KIẾM ok và nhà phát triển được ban lãnh đạo cấp trên đánh giá cao. Một nhà phát triển cơ sở khác sau đó được giao nhiệm vụ sửa một lỗi "nhỏ" và sau một tuần cố gắng tìm hiểu mã, đã từ bỏ và tìm kiếm hướng dẫn từ một cấp cao .. những người không thể tin được mã rác như thế nào. Quản lý cấp trên từ chối chấp nhận là một vấn đề lớn trong hai năm, sau đó cuối cùng họ đồng ý rằng đó là một đống rác và cần được mã hóa lại từ đầu - và ngay lúc này
— Sk93
4
Có một huyền thoại được thiết lập tốt giữa các nhà quản lý kỹ thuật rằng các nhà phát triển lành nghề của bạn có năng suất gấp mười lần so với các nhà phát triển không có kỹ năng. Kết quả trực tiếp của huyền thoại này là bất kỳ nhà phát triển nào có thể tạo mã nhanh chóng - bất kể lỗi hay khó bảo trì - đều được khen ngợi và quảng bá.
— rtperson
3
Bạn CẦN một ngôn ngữ mạnh mẽ. Xem thảo luận về ngôn ngữ của Paul Grahams và những gì ti cho phép bạn làm: paulgraham.com/power.html
4
@ Thorbjørn: Tôi đã đọc bài báo đó và Paul Graham đã viết sai. Anh ấy là một người ủng hộ Lisp, vì vậy anh ấy xoắn các sự kiện thành các cuộc tranh luận tự phục vụ để làm cho Lisp trông tốt. Có lẽ thậm chí không thú vị, vì nó thực sự không mất nhiều sức. Có rất nhiều sự trùng lặp giữa khả năng đọc và cô đọng, khi ông chỉ ra đến cuối bài viết. Nhưng những kết luận mà ông rút ra là hoàn toàn không đồng bộ với tình trạng phát triển phần mềm trong thế giới thực. Vâng, bạn cần một ngôn ngữ mạnh mẽ, nhưng anh ta đo lường sức mạnh theo các tiêu chí sai lầm và thật có hại khi tin những gì anh ta nói.
— Mason Wheeler
3
@rtperson: Năng suất đó có thể thay đổi theo hệ số mười là không có gì là hoang đường. Những người hoàn thành nhanh nhất thiết phải có năng suất cao hơn.
— David Thornley
31

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

— Vua Mike
nguồn
6
Phụ thuộc vào các bài học. Khi tôi làm việc tại một nhà máy sản xuất nệm, chúng tôi đã học được rằng chuyển đổi nhiệm vụ có hại cho sản xuất của chúng tôi. Điều quan trọng là chúng tôi đã được trả tiền bằng số lượng nệm được sản xuất chứ không phải theo giờ ... và một bài học áp dụng ở đây cũng vì rất nhiều lý do tương tự.
— AnonJr
Đây là một huyền thoại dai dẳng khi bạn làm việc ở một nơi chủ yếu làm phần cứng. Các vòng quay mà chúng tôi nhảy qua để phù hợp với phần mềm 'xây dựng' của chúng tôi thành cùng một mô hình với phần 'phần cứng' thật đáng kinh ngạc ...
— AShelly
5
Điều đó là, phần mềm sản xuất là tầm thường. Thật dễ dàng để tạo các bản sao và không tốn quá nhiều tiền để tạo ra hàng triệu bản. Điều này khiến mọi người bỏ qua phần sản xuất hoàn toàn và cố gắng áp dụng sản xuất vào quy trình thiết kế.
— David Thornley
+100 cho điều này, đặc biệt là những người nghiên cứu về kinh tế nghĩ rằng điều này
— Kugel
1
Mọi người nên đọc Jack Reeves: developerdotstar.com/mag/articles/reeves_design_main.html - đây là nguồn gốc (hoặc ít nhất là một tuyên bố sớm và mạnh mẽ) của ý tưởng rằng mã nguồn là một thiết kế không phải là một sản phẩm . Các lập trình viên giống như các nhà thiết kế trong phòng soạn thảo, không phải là thợ máy trên sàn nhà máy và việc quản lý lập trình phải giống như quản lý các loại thiết kế kỹ thuật khác, không sản xuất.
— Tom Anderson
31

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

— setzamora
nguồn
5
Tôi đã từng giữ lại một số trong những điều này ở trường trung học, nhưng ngày nay tôi thấy rằng chúng thường không liên quan đến những gì tôi làm và trong khi một số thì gọn gàng, tôi thà trả tiền cho ai đó biết công cụ của họ và sử dụng thời gian tôi lưu làm những gì tôi thích (tức là viết mã). Có thể một sự hiểu lầm "tốt với máy tính".
— Alan Plum
2
+1, hoặc một chút tiếp tuyến - Bởi vì là một lập trình viên của bạn, bạn có một quạt 300 đèn LED làm mát bằng nước siêu tốc nhấp nháy trên đỉnh của dòng sản phẩm mới được vận chuyển từ nhà máy sản xuất trước khi vỏ được phát hành. Erm không thực sự! Đây là một cỗ máy nhanh nhẹn, trong vỏ màu đen rất rẻ. Đừng thực sự quan tâm hơn thế!
— Coder phẫu thuật
Cười, có một trợ lý PM đang làm việc có một dàn máy chơi game toàn năng ở nhà, luôn lăn đến khu vực Dev để hỏi xem anh ta nên mua (Sản phẩm A) hay (Sản phẩm B) ... trong một ghi chú không liên quan, anh ta cũng giả định rằng nhóm phát triển tất cả đi chơi trên 4Chan, (mà anh ấy thực sự làm.) - thở dài
— ocodo
+1 từ. Đây là vị trí trên. Tôi là nhà phát triển phần mềm và tôi đã được yêu cầu định cấu hình internet của ai đó rất nhiều lần và về cơ bản, tất cả những gì tôi làm là dùng thử và lỗi cộng với các tìm kiếm của Google. Tôi thích nó nhất khi một cái gì đó hoàn toàn không liên quan bị phá vỡ sau khi bạn đã giúp đỡ ai đó và đó là lỗi của bạn.
— Anne Schuessler
30

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

— koos303
nguồn
2
Bao gồm cả quản lý
— Prasham
Khi bạn nói không, họ nghĩ bạn đơn giản là một người khó làm việc.
— Thuyền trưởng Sensible
+100 và với đủ "động lực", họ có thể thay đổi câu trả lời của bạn. Hoặc tìm đến một nhà phát triển [ít kinh nghiệm] khác và cố tình bỏ qua một nửa chi tiết để khiến anh ta nói đồng ý, chỉ để kết thúc quá trình phát triển nửa chừng và va vào vấn đề chính xác mà bạn đã cảnh báo họ.
— wildpeaks
28

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à điều chỉnh theo yêu cầu của tôi.

— Tim Murphy
nguồn
2
+1. Ồ, vâng, bất cứ điều gì chúng ta cần làm đều phải có trong nguồn mở.
— sharptooth
7
rất nhiều thời gian có ... ít nhất điều đó đúng với phát triển web.
— WalterJ89
@ WalterJ89: Nó có thể ở đó, nhưng điều đó không có nghĩa là nên sử dụng nó. Nguồn mở không tự động có nghĩa là mã tốt.
— Alan Plum
đúng .. nhưng trong trường hợp Wordpress, Drupal, jQuery, ... có thể có những lĩnh vực miễn phí không tuyệt vời, như Thương mại điện tử nhưng thường xuyên hơn không phải là web rất mở và tôi thấy tôi thích làm việc với cộng đồng nguồn mở xa hơn một bàn trợ giúp propietory.
— WalterJ89
7
Ngược lại là một huyền thoại. Rằng bạn không thể sử dụng FOSS để đáp ứng nhu cầu kinh doanh của bạn.
— bến cuối
27

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!

— JohnFx
nguồn
6
Điều đó không giúp ích gì cho hầu hết mọi người thậm chí không biết lập trình thực sự là gì ... họ có ý tưởng mơ hồ rằng nó tạo ra phần mềm ... nhưng họ không thực sự có ý tưởng rõ ràng phần mềm là gì ...
— Spudd86
7
"Chúng tôi viết công thức đan". Bà ngoại có xu hướng hiểu điều đó.
Tôi biết những người sẽ viết một chương trình bằng C, sau đó làm lại những phần quan trọng nhất về hiệu suất trong hội.
— Zaz
1
@Josh - trừ khi có vấn đề về hiệu suất, điều đó có vẻ như lãng phí thời gian.
— JohnFx
1
@oosterwal - Hội không phải là nhị phân, cũng không sử dụng các ký hiệu toán học.
— JohnFx
26

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

— LennyProgrammer
nguồn
5
* v (int) (void) ++
— Rusty
1
@Rusty: Tôi có thể đưa ra nhiều ví dụ tồi tệ hơn nhiều nếu tôi thậm chí không cần phải đúng về mặt cú pháp.
4
À, vâng, mã "Chỉ viết" ...
— Paddyslacker
24

Lập trình cũng giống như công việc dây chuyền lắp ráp. 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ờ.

— Josua Schmid
nguồn
6
Đồng ý về sự khác biệt so với công việc của dây chuyền lắp ráp - nhưng theo nhiều cách tôi không nghĩ nó khác nhiều so với xây nhà.
— Billy ONeal
24

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

— JohnFx
nguồn
Tôi sẽ mở rộng sang các ngôn ngữ cấp thấp khác. Có thể ngược lại khi lập trình viên không biết nó đang làm gì.
— Maniero
2
Một biến thể phổ biến khác là chuyển sang kiến ​​trúc máy khách-máy chủ. "Nâng cấp lên SQL sẽ giúp ứng dụng của tôi nhanh hơn nhiều!" Không cần thiết.
— JohnFx
Vâng, nó hoàn toàn ngược lại nhiều lần. Cơ sở dữ liệu loại SQL là tốt để được ACID hoặc gần như vậy, nó đi kèm với giá cả. Và có thể là tồi tệ nhất, suy nghĩ sai về các kỹ thuật SQL có thể có hại về hiệu suất.
— Maniero
6
Chuyển sang C ++ / C cho những người được viết bằng Python / Perl / Ruby / etc. Chuyển sang mã asm cho những người viết bằng C / C ++: P. Tôi tự hỏi những gì bạn cổng asm đến? Thiết kế nó vào phần cứng?
— MAK
1
— flamingpenguin
21

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.

— Jesse C. Máy cắt
nguồn
9
À, vâng. Thật thú vị khi một số công ty tạo ra một công cụ tác giả mới để làm cho các lập trình viên trở nên dư thừa và sau đó mọi người áp dụng nó sẽ đi trước và thuê các chuyên gia <công cụ tác giả> được trả lương cao để thực sự sử dụng nó. Trường hợp điển hình: Joomla! và tất cả những điều vô nghĩa đó.
— Alan Plum
HA HA HA HA HA HA HAAA HA +1 :)
— Billy ONeal
Cobol đã thử điều đó :)
— Carra
20

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

— clrod
nguồn
1
Tốt. HP XL WESM gần bằng 85% so với Symbol WS5100 (có OEMming đang diễn ra). Bạn có cho tôi sao chép và dán tỷ lệ phần trăm mã theo dõi và cấu hình của tôi để có số lỗi nhiều gấp đôi không, hoặc bạn muốn tôi viết lại từ đầu và mất gấp bốn mươi lần và có gấp năm lần? Hay bạn chỉ bị áp lực bởi cách quản lý ngu ngốc mà nghĩ rằng đó là một trong những cơn hoảng loạn kỳ diệu để làm cho dự án $ nhanh hơn?
1
Tái sử dụng trong nhỏ đã được giải quyết 40 năm trước và nhiều hơn nữa. Việc sử dụng lại rất khó khăn và chưa được giải quyết IMHO. Giống như Robert Glass nói trong Sự kiện và sai lầm của công nghệ phần mềm
— MarkJ
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.