Các giả định lập trình lâu dài, không chính xác [đã đóng]

Tôi đang thực hiện một số nghiên cứu về các lỗi phổ biến và các giả định kém được thực hiện bởi các kỹ sư phần mềm cơ sở (và có lẽ là cấp cao).

Giả định lâu nhất của bạn cuối cùng đã được sửa là gì?

Ví dụ, tôi đã hiểu nhầm rằng kích thước của một số nguyên không phải là một tiêu chuẩn và thay vào đó phụ thuộc vào ngôn ngữ và mục tiêu. Một chút lúng túng để nói, nhưng nó có.

Hãy thẳng thắn; bạn có niềm tin vững chắc nào, và bạn duy trì giả định trong bao lâu? Nó có thể là về một thuật toán, ngôn ngữ, khái niệm lập trình, kiểm tra hoặc bất cứ điều gì khác về lập trình, ngôn ngữ lập trình hoặc khoa học máy tính.

Trong một thời gian dài, tôi cho rằng mọi người khác đều có siêu thành thạo tất cả các khái niệm lập trình (mẫu thiết kế, ngôn ngữ mới nhất, độ phức tạp tính toán, biểu thức lambda, bạn đặt tên cho nó).

Đọc blog, Stack Overflow và sách lập trình dường như luôn khiến tôi cảm thấy rằng mình đứng sau đường cong về những điều mà tất cả các lập trình viên chỉ cần biết bằng trực giác.

Theo thời gian, tôi đã nhận ra rằng tôi đang so sánh hiệu quả kiến ​​thức của mình với kiến ​​thức tập thể của nhiều người, không phải là một cá nhân và đó là một thanh khá cao đối với bất kỳ ai. Hầu hết các lập trình viên trong thế giới thực đều có một bộ đệm kiến ​​thức cần thiết để thực hiện công việc của họ và có nhiều hơn một vài lĩnh vực mà họ yếu hoặc hoàn toàn không biết gì.

Rằng mọi người biết họ muốn gì.

Trong thời gian dài nhất tôi nghĩ rằng tôi sẽ nói chuyện với mọi người, họ sẽ mô tả một vấn đề hoặc quy trình làm việc và tôi sẽ đưa nó vào mã và tự động hóa nó. Hóa ra mỗi khi điều đó xảy ra, những gì họ nghĩ họ muốn không thực sự là những gì họ muốn.

Chỉnh sửa: Tôi đồng ý với hầu hết các ý kiến. Đây không phải là một câu trả lời kỹ thuật và có thể không phải là những gì người hỏi đang tìm kiếm. Nó không chỉ áp dụng cho lập trình. Tôi chắc chắn đó không phải là giả định lâu nhất của tôi, nhưng đó là điều nổi bật nhất tôi đã học được trong 10 năm ngắn ngủi tôi đã làm điều này. Tôi chắc chắn rằng đó là một sự ngây thơ thuần túy từ phía tôi nhưng cách mà bộ não của tôi / có dây và sự dạy dỗ và kinh nghiệm tôi có trước khi bước vào thế giới kinh doanh khiến tôi tin rằng tôi sẽ làm những gì tôi đã trả lời; rằng tôi sẽ có thể sử dụng mã và máy tính để khắc phục sự cố của mọi người.

Tôi đoán câu trả lời này tương tự như của Robin về những người không lập trình hiểu / quan tâm đến những gì tôi đang nói. Đó là về việc học kinh doanh như một quá trình tương tác nhanh, lặp đi lặp lại. Đó là về việc tìm hiểu sự khác biệt giữa việc trở thành một con khỉ lập trình và trở thành một nhà phát triển phần mềm. Đó là về việc nhận ra rằng có một sự khác biệt giữa hai và để thực sự tốt trong lĩnh vực này, nó không chỉ là cú pháp và tốc độ gõ.

Chỉnh sửa: Câu trả lời này hiện là cộng đồng-wiki để xoa dịu những người khó chịu với câu trả lời này cho tôi đại diện.

Rằng tôi biết vấn đề hiệu suất ở đâu mà không có hồ sơ

Rằng tôi chỉ nên có một điểm thoát khỏi hàm / phương thức.

Những người không lập trình đó hiểu những gì tôi đang nói.

Phần mềm bugfree đó là có thể.

Các biến thành viên riêng đó là riêng tư đối với thể hiện chứ không phải lớp.

Tôi nghĩ rằng gõ tĩnh đang ngồi rất yên trên bàn phím của bạn.

Rằng bạn hoàn toàn có thể hiểu một vấn đề trước khi bắt đầu phát triển.

Người thông minh luôn thông minh hơn tôi.

Tôi thực sự có thể đánh bại chính mình khi tôi mắc lỗi và thường bị nói ra vì tự ti. Tôi đã từng ngước nhìn rất nhiều nhà phát triển và thường cho rằng vì họ biết nhiều hơn tôi trên X , nên họ biết nhiều hơn tôi.

Khi tôi tiếp tục tích lũy kinh nghiệm và gặp gỡ nhiều người hơn, tôi đã bắt đầu nhận ra rằng đôi khi, họ biết nhiều hơn tôi trong một chủ đề cụ thể, họ không nhất thiết phải thông minh hơn tôi / bạn.

Đạo đức của câu chuyện: Đừng bao giờ đánh giá thấp những gì bạn có thể mang đến bàn.

Trong thời gian dài nhất tôi đã nghĩ rằng Lập trình xấu là một cái gì đó đã xảy ra ở rìa .. rằng Làm mọi thứ chính xác là chuẩn mực. Tôi không ngây thơ những ngày này.

Tôi nghĩ rằng tôi nên tiến tới trừu tượng hóa càng nhiều càng tốt. Tôi bị đánh vào đầu lớn với điều này, vì có quá nhiều chức năng nhỏ đan xen.

Bây giờ tôi cố gắng giữ mọi thứ đơn giản và tách rời nhất có thể. Tái cấu trúc để làm cho một cái gì đó trừu tượng dễ dàng hơn nhiều so với dự đoán làm thế nào tôi cần trừu tượng hóa một cái gì đó.

Vì vậy, tôi đã chuyển từ phát triển khung quy tắc tất cả, sang các đoạn chức năng để hoàn thành công việc. Không bao giờ nhìn lại, ngoại trừ khi tôi nghĩ về thời gian tôi ngây thơ nghĩ rằng mình sẽ là người phát triển điều lớn tiếp theo.

Phụ nữ thấy lập trình viên máy tính gợi cảm ...

Chất lượng phần mềm sẽ dẫn đến doanh số cao hơn. Đôi khi nó không nhưng không phải lúc nào.

Rằng tất cả các ngôn ngữ (hầu hết) được tạo ra bằng nhau.

Trong một thời gian dài, tôi nhận ra rằng ngôn ngữ của sự lựa chọn không thực sự tạo ra nhiều sự khác biệt về độ khó của quá trình phát triển và tiềm năng thành công của dự án. Điều này chắc chắn là không đúng sự thật.

Chọn ngôn ngữ phù hợp cho công việc cũng quan trọng / quan trọng như bất kỳ quyết định dự án nào khác được đưa ra.

Đó là một tỷ lệ nhận xét / mã lớn là một điều tốt.

Phải mất một thời gian tôi mới nhận ra rằng mã nên tự ghi lại. Chắc chắn, một nhận xét ở đây và có ích nếu mã không thể được làm rõ hơn hoặc nếu có một lý do quan trọng tại sao một cái gì đó đang được thực hiện. Nhưng, nói chung, tốt hơn là dành thời gian bình luận đó để đổi tên các biến. Nó sạch hơn, rõ ràng hơn và các bình luận không nhận được "không đồng bộ" với mã.

Lập trình đó là không thể.

Không đùa, tôi luôn nghĩ rằng lập trình là một thứ không thể học được, và tôi luôn tránh xa nó. Và khi tôi đến gần mã, tôi không bao giờ có thể hiểu được.

Sau đó một ngày, tôi chỉ cần ngồi xuống và đọc một số hướng dẫn cơ bản cho người mới bắt đầu, và làm việc theo cách của tôi từ đó. Và hôm nay tôi làm việc như một lập trình viên và tôi yêu từng phút giây.

Nói thêm, tôi không nghĩ lập trình là dễ dàng, đó là một thách thức và tôi thích học hỏi nhiều hơn và không có gì vui hơn là giải quyết một số vấn đề lập trình.

"On Error Resume Next" là một số cách xử lý lỗi

Phần mềm lập trình đó đòi hỏi một nền tảng vững chắc trong toán học cao hơn.

Trong nhiều năm trước khi tôi bắt đầu viết mã, tôi luôn được bảo rằng để trở thành một lập trình viên giỏi, bạn phải giỏi về đại số, hình học, giải tích, trig, v.v.

Mười năm sau và tôi chỉ có một lần phải làm bất cứ điều gì mà một học sinh lớp tám không thể làm được.

Điều đó tối ưu hóa == viết lại bằng ngôn ngữ lắp ráp.

Khi tôi lần đầu tiên thực sự hiểu về lắp ráp (đến từ BASIC), dường như cách duy nhất để làm cho mã chạy nhanh hơn là viết lại nó trong lắp ráp. Mất vài năm để nhận ra rằng trình biên dịch có thể rất tốt trong việc tối ưu hóa và đặc biệt là với các CPU có dự đoán nhánh, v.v. chúng có thể có thể làm tốt hơn một con người có thể làm trong một khoảng thời gian hợp lý. Ngoài ra, dành thời gian cho việc tối ưu hóa thuật toán có thể mang lại cho bạn một chiến thắng tốt hơn so với việc dành thời gian chuyển đổi từ ngôn ngữ cấp cao sang ngôn ngữ cấp thấp. Ngoài ra, tối ưu hóa sớm là gốc rễ của mọi tội lỗi ...

• Rằng các giám đốc điều hành công ty quan tâm đến chất lượng của mã.
• Càng ít dòng thì càng tốt.

Tôi có thể nói rằng việc lưu trữ phần tử năm của một ngày là 2 chữ số là một giả định ảnh hưởng đến toàn bộ thế hệ các nhà phát triển. Số tiền được thổi vào Y2K khá khủng khiếp.

Rằng bất cứ thứ gì khác ngoài việc chèn / sắp xếp bong bóng khá đơn giản là ma thuật đen tối.

XML đó sẽ là một định dạng dữ liệu thực sự có thể tương tác và có thể đọc được của con người.

C ++ về bản chất là tốt hơn tất cả các ngôn ngữ khác.

Điều này tôi nhận được từ một người bạn vài năm trước tôi ở trường đại học. Tôi đã giữ nó trong một thời gian dài lúng túng (tôi đang đỏ mặt ngay bây giờ). Chỉ sau khi làm việc với nó được 2 năm hoặc lâu hơn trước khi tôi có thể nhìn thấy những vết nứt cho những gì chúng là.

Không ai - và không có gì - là hoàn hảo, luôn có chỗ để cải thiện.

Tôi tin rằng việc tạo ra các chương trình sẽ giống hệt như những gì được dạy trong lớp ... bạn ngồi xuống với một nhóm người, giải quyết vấn đề, đưa ra giải pháp, v.v. Thay vào đó, thế giới thực là "Đây là vấn đề của tôi, tôi cần nó giải quyết, đi "và mười phút sau bạn nhận được một thứ khác, khiến bạn không có thời gian thực sự để lên kế hoạch cho giải pháp của mình một cách hiệu quả.

Tôi nghĩ các mẫu thiết kế chính là tuyệt vời, khi chúng được giới thiệu trong một lớp CS. Tôi đã lập trình khoảng 8 năm như sở thích trước đó và tôi thực sự không có hiểu biết vững chắc về cách tạo ra sự trừu tượng tốt.

Các mẫu thiết kế cảm thấy như ma thuật; bạn có thể làm những thứ thực sự gọn gàng. Sau đó tôi phát hiện ra lập trình chức năng (thông qua Mozart / Oz, OCaml, sau đó là Scala, Haskell và Clojure), và sau đó tôi hiểu rằng nhiều mô hình chỉ là bản tóm tắt, hoặc độ phức tạp bổ sung, vì ngôn ngữ không đủ biểu cảm.

Tất nhiên hầu như luôn có một số kiểu mẫu, nhưng chúng ở cấp độ cao hơn trong các ngôn ngữ biểu cảm. Bây giờ tôi đã thực hiện một số mã hóa chuyên nghiệp trong Java và tôi thực sự cảm thấy đau đớn khi phải sử dụng một quy ước như khách truy cập hoặc mẫu lệnh, thay vì khớp mẫu và các hàm bậc cao hơn.

Trong vài năm đầu tiên tôi đã lập trình, tôi đã không bắt gặp rằng 1 Kbyte về mặt kỹ thuật là 1024 byte chứ không phải 1000. Tôi luôn cảm thấy hơi bối rối vì thực tế là kích thước của các tệp dữ liệu của tôi có vẻ hơi khác so với những gì tôi mong đợi là.

Điều kiện đó kiểm tra như:

if (condition1 && condition2 && condition3)

được thực hiện theo thứ tự không xác định ...

Rằng lập trình của tôi sẽ nhanh hơn và tốt hơn nếu tôi thực hiện nó một mình.