Tôi đang bị khủng hoảng niềm tin vào khả năng là một lập trình viên máy tính.

Hôm qua tôi đã cố gắng đưa ra thuật toán đường đi ngắn nhất của riêng mình cho một biểu đồ và sau vài giờ, tôi chỉ đơn giản ném vào khăn và học thuật toán của Dijkstra.

Đây có phải là điều mà một lập trình viên giỏi sẽ có thể "phát minh lại" trong vài giờ hay tôi không thực tế?

Ồ, ít nhất tôi đã có thể phát minh lại loại bong bóng: D

Một lập trình viên giỏi nên nhận ra rằng một thuật toán tuyệt vời đã được viết để giải quyết vấn đề và không lãng phí thời gian để phát minh lại bánh xe.

Tôi nghi ngờ Dijkstra đã đưa ra thuật toán đường dẫn ngắn nhất trong vài giờ, vì vậy đó có vẻ như là một tiêu chuẩn thực sự cao để sử dụng để xác định xem ai đó có phải là một 'lập trình viên giỏi' không

Đây có phải là điều mà một lập trình viên giỏi sẽ có thể "phát minh lại" trong vài giờ hay tôi không thực tế?

Đầu tiên, có lẽ bạn đang nhầm lẫn lập trình với khoa học máy tính lý thuyết. Một lập trình viên tuyệt vời cần một nền tảng tốt trong khoa học máy tính nhưng anh ta không cần phải tuyệt vời. Dijkstra là tuyệt vời về khoa học máy tính.

Thứ hai, tôi mong mọi người có hiểu biết về đồ thị sẽ phát triển biểu đồ của riêng họ sau một chút suy nghĩ. Nhưng không phải là một thuật toán đường dẫn ngắn nhất. Thuật toán của Dijkstra nói riêng rất tinh vi. Một khi bạn hiểu nó, nó rõ ràng rõ ràng. Nhưng hầu hết mọi thứ là như vậy.

Bạn có thể có thể rút ra một số loại thuật toán đường dẫn ngắn nhất sau khi thử một số thứ và đưa ra ý tưởng một thời gian. Nhưng đừng thất vọng nếu điều đó mất hàng giờ, hoặc thậm chí vài ngày. Điều này là hoàn toàn OK và bình thường.

(Hãy cẩn thận: tốt, bạn sẽ có thể giải quyết vấn đề trong vài giờ nữa, nhưng điều này sẽ không mang lại thuật toán hoạt động ngay cả trên các biểu đồ khá nhỏ.)

Đây có phải là điều mà một lập trình viên giỏi sẽ có thể "phát minh lại" trong vài giờ hay tôi không thực tế?

Chắc chắn là không thực tế. Mọi người không chỉ "nghĩ ra" với các thuật toán trong một vài giờ. Phải mất rất nhiều nỗ lực và công việc. Để trích dẫn blog này :

Trong Lập trình Pearls, Bentley, trích dẫn Donald Knuth, nói rằng "Trong khi tìm kiếm nhị phân đầu tiên được xuất bản vào năm 1946, thì tìm kiếm nhị phân đầu tiên hoạt động chính xác cho tất cả các giá trị của n đã không xuất hiện cho đến năm 1962".

và phiên bản của Bentley cũng có vấn đề khi được triển khai cho các bộ lớn.

Hơn nữa, một lập trình viên giỏi biết những công cụ nào theo ý mình và khi nào nên sử dụng những công cụ đó. Bạn không nhận được thêm điểm cho sự độc đáo hoặc làm những điều khác biệt - bạn muốn nó hoạt động và hoạt động tốt.

Rất có khả năng là bạn sẽ không thể tìm ra giải pháp tốt hơn giải pháp bạn có thể chọn.

Xuất hiện với một thuật toán tốt hơn một thuật toán được coi là "tốt nhất" (trong trường hợp của bạn, ngắn nhất) là điều không phải ai cũng làm được. Có lẽ nó thậm chí không thể.

Một lập trình viên giỏi sẽ có thể hiểu logic đằng sau thuật toán và tại sao nó tốt hơn hay tệ hơn (hoặc đơn giản là không đủ cho vấn đề cụ thể đó) so với các thuật toán khác cố gắng giải quyết vấn đề tương tự.

(s) Anh ấy cũng có thể biết liệu đó có thực sự là cách tốt nhất để giải quyết vấn đề cụ thể đó không.

Dù sao, nếu bạn muốn thực hành, bạn vẫn có thể cố gắng viết bài thực hiện thuật toán cá nhân của mình, cố gắng giải quyết vấn đề bằng tâm trí của bạn. Nó có thể không phải là tốt nhất, nhưng đó là một thực hành tốt để giải quyết vấn đề.

Điều này nhắc nhở tôi về một cái gì đó tôi đọc về sự khác biệt giữa "công nghệ phần mềm" (cái mà tôi sẽ gọi là lập trình) và các ngành kỹ thuật khác. Nghĩ về nó, tôi nghĩ đó là cuốn sách Mẫu thiết kế ban đầu. Tôi chắc rằng ai đó ở đây có thể trích dẫn nó ra khỏi đỉnh đầu.

Dù sao, điểm (mặc dù không chính xác hướng đến thiết kế thuật toán) là các ngành kỹ thuật được mã hóa; không có kỹ sư dân sự nào có thể dành thời gian cố gắng phát minh lại I-tia, nhưng các lập trình viên làm điều đó mọi lúc. Vấn đề (và tôi nhận ra rằng tôi chỉ đơn thuần lặp lại tình cảm của nhiều người) là hành vi này là lãng phí và dễ bị lỗi, và phục vụ bản ngã nhiều hơn giải pháp.

Khoa học máy tính dẫn tôi đến lập trình, và tôi yêu cả hai. Tuy nhiên, tôi là một lập trình viên giỏi hơn nhiều so với nhà khoa học máy tính. Tôi sẽ không bao giờ buộc tội bạn là bất tài vì bạn không thể phát minh lại thuật toán của Dijkstra vào một buổi chiều. Tôi sẽ đặt câu hỏi về năng lực của bạn với tư cách là một lập trình viên nếu bạn không thể nhận ra một vấn đề có thể được giải quyết thông qua thuật toán đồ thị đường đi ngắn nhất.

Điều đó nói rằng, tôi tin rằng suy nghĩ về các thuật toán và cố gắng thiết kế và thực hiện những thuật toán mới là (có khả năng) thú vị và (hầu như) luôn mang tính hướng dẫn. Tôi chỉ cố gắng tách sạch thời gian CS của tôi khỏi thời gian lập trình. Đối với các lập trình viên, thời gian (đặc biệt là trả tiền) của chúng tôi tốt hơn dành cho việc giải quyết các vấn đề thực tế thay vì giải quyết vấn đề. Bên cạnh đó, thời gian CS hầu như luôn đè bẹp sự tự tin của tôi.

Bạn sẽ không nhận thấy những điều tương tự như những người khác làm. Tôi nghĩ đó chỉ là một thực tế của cuộc sống mà chúng ta phải sống cùng. Phần lớn đến từ việc học thụ động của bạn và các mô hình tinh thần mà bạn đã phát triển như là kết quả của chúng.

Tôi biết một số lập trình viên rất thông minh và có năng lực, những người phải được dạy luật DeMorgan ở trường trước khi họ có thể làm điều đó một cách nhất quán. Tôi tình cờ tự mình tìm ra Thuật toán của Dijkstra (và tôi phải thừa nhận rằng tôi hơi tự hào về nó), nhưng tôi đã mất một thời gian rất dài cho đến khi tôi có thể hiểu được loại bong bóng.

Nổi tiếng hơn, Einstein, người mà bạn nghĩ sẽ là một chuyên gia về lý thuyết thắt nút, không thể buộc dây giày của mình cho đến khi ông khoảng mười tuổi.

Rất có thể là bạn đã vô tình phát minh lại nhiều thứ mà nhiều người khác sẽ không bao giờ nghĩ ra nếu không được dạy một cách rõ ràng.

Tôi cầu xin khác nhau cho những gì hầu hết các câu trả lời nói. Mặc dù tôi không mong muốn một lập trình viên ở bất kỳ cấp độ nào có thể tự mình đưa ra thuật toán của Dijkstra, tôi chắc chắn sẽ mong đợi anh ta đưa ra bất kỳ cách nào (hiệu quả hay không) để giải quyết vấn đề.

Ví dụ, bạn đã nói như một nhận xét phụ rằng bạn có thể tự mình đưa ra loại bong bóng. Tôi biết nó là thuật toán sắp xếp dễ hiểu nhất, nhưng bạn đã tìm ra cách giải quyết vấn đề và đó là điều tôi mong các lập trình viên có thể: tìm cách giải quyết vấn đề.

Tất nhiên, điều tra và tìm giải pháp được thực hiện bởi những người khác cũng có hiệu quả, nhưng điểm cực đoan đó là một anh chàng không nghĩ về bản thân mình và những chương trình của họ là một bản tóm tắt các tìm kiếm của Google.

Tôi nghĩ rằng tôi nghe có vẻ khắc nghiệt hơn tôi thực sự muốn, nhưng quan điểm của tôi là: Tôi mong muốn một lập trình viên đủ sáng tạo để đưa ra giải pháp cho một vấn đề, ngay cả khi giải pháp đó có lỗi hoặc lộn xộn.

Vì vậy, quay trở lại trường hợp của bạn, tôi không nghĩ bạn nên nghĩ ra thuật toán của Dijkstra, nhưng nếu bạn có khả năng viết một thuật toán để thử một vài khả năng và tìm ra con đường ngắn nhất mà không kết thúc trên một vòng lặp vô hạn, sau đó bạn đã được tôi chấp thuận.

(BTW sự chấp thuận của tôi được tính theo thứ tự quan trọng như một phiếu giảm giá rửa xe miễn phí.)

Có, anh ấy / cô ấy nên.

Nó có thể tương đương với đạo đức của loại bong bóng, nhưng tôi nghĩ một lập trình viên giỏi nên có thể đưa ra ít nhất một cái gì đó hoạt động, tuy nhiên nó không hiệu quả.

Không cần phải nói, nếu vấn đề cụ thể đó xuất hiện, một lập trình viên giỏi sẽ tìm kiếm trước nếu có một thư viện để làm điều đó cho anh ta, hoặc các thuật toán được xuất bản làm điều đó và dễ thực hiện.

Tất nhiên, nhiều nhiệm vụ lập trình ít khó khăn hơn nhiều và không phải ai cũng cần có khả năng giải quyết các vấn đề khó khăn như vậy. Nhưng bạn sẽ muốn có một người có suy nghĩ như vậy trong nhóm của mình, bởi vì bạn có thể có một số vấn đề cụ thể của dự án phức tạp mà bạn không thể dựa vào vô số nghiên cứu khoa học trước đây.

Đừng lo

Là một lập trình viên Perl, tôi hoàn toàn không bao giờ phát minh lại bánh xe. Đó là công việc của CPAN. Nếu có một thuật toán hoặc mô-đun đơn giản, được hỗ trợ tốt, chúng tôi sử dụng nó. Nếu không có một mô-đun tốt, thì chúng tôi phát minh ra bánh xe. Đó là một trong những điều tuyệt vời nhất về Perl.

Vì vậy, những gì tôi đang nói là đây:

1. Tôi không khuyên bạn nên phát minh lại bánh xe nhưng khi bạn làm ...
2. Cố gắng không hoàn toàn phát minh lại nó và ...
3. Đừng lo lắng nếu bạn không thể làm điều đó. Đó là lý do tại sao chúng tôi có một cộng đồng lập trình :-).

Lý thuyết đồ thị, và các thuật toán áp dụng cho nó, trông đơn giản trên bề mặt nhưng nhìn chung cách xa nó. Bạn sẽ nghĩ rằng việc hình thành các đồ thị không cắt ngang (mặt phẳng) là đơn giản, chẳng hạn, thoạt nhìn. Năm ngoái tôi đã xem xét sâu rộng vấn đề này (tính đồng nhất thông qua việc loại bỏ các sơ đồ con Kuratowski). Tôi có thể nói với bạn, từ kinh nghiệm đó, rằng những người viết các thuật toán này thường dành thời gian nghiên cứu tiến sĩ của họ để làm như vậy, và đôi khi nghiên cứu đó được thực hiện theo nhóm. Và như các nhà nghiên cứu , đó là trọng tâm làm việc duy nhất của họ trong khoảng thời gian đó. Thật không hợp lý khi nghĩ rằng các kỹ sư trên mặt đất của chúng ta có thể mong đợi điều tương tự. Như một người khác ở đây đã nói đúng, rõ ràng một cách rõ ràng một khi giải pháp đang ở trước mặt bạn. Đó dường như luôn luôn là trường hợp!

Đây có phải là điều mà một lập trình viên giỏi sẽ có thể "phát minh lại" trong vài giờ hay tôi không thực tế?

Tôi có thể nói rằng nếu bạn có thể phát minh ra một thuật toán cho một vấn đề nổi tiếng như Con đường ngắn nhất của riêng bạn, thì bạn là một lập trình viên tồi .

Điều đó có nghĩa là bạn đang bỏ qua khá nhiều lịch sử về vấn đề Đường dẫn ngắn nhất , đi từ thuật toán O (| V | ^ 4) được xuất bản năm 1955 sang thuật toán O (E + V log V) được xuất bản năm 1984 (là Dijkstra thuật toán với các cây Fibonacci). Bạn gần như đảm bảo sẽ làm tồi tệ hơn các thuật toán đã nghĩ ra. Tệ hơn nữa, có khả năng thuật toán của bạn có những khoảng trống hoặc lỗi khiến nó không chính xác. Ngoài ra, bạn gần như chắc chắn sẽ dành nhiều thời gian hơn để nghĩ ra thuật toán của mình, thực hiện nó và thử nghiệm nó so với thời gian sử dụng lại thuật toán hiện có.

Để lại việc thiết kế các thuật toán cho các nhà thiết kế thuật toán. Các lập trình viên là người tiêu dùng của kết quả của họ. Các lập trình viên kết hợp các thuật toán và đưa chúng vào làm việc với các nhiệm vụ trong thế giới thực. Một sĩ quan cảnh sát không cần phải có khả năng tái tạo luật để có thể làm việc, hoặc trở thành một sĩ quan tốt.

Tôi thậm chí còn khuyến khích bạn sử dụng các triển khai được thực hiện bởi các chuyên gia thay vì tự thực hiện các thuật toán cho bất kỳ thuật toán phức tạp vừa phải nào. Có nhiều khả năng là chính xác, rất có thể họ đã làm nó nhanh hơn bạn từng làm và nó giúp bạn tiết kiệm rất nhiều thời gian. Điều này đặc biệt đúng đối với các thuật toán mã hóa, bởi vì bạn nhận được nhu cầu bảo mật bổ sung, điều mà thường chỉ các chuyên gia mới có thể cung cấp cho bạn.