Làm thế nào tôi có thể chắc chắn rằng tôi thực sự đang học cách lập trình chứ không chỉ đơn giản là học các chi tiết của ngôn ngữ? [đóng cửa]


82

Tôi thường nghe rằng một lập trình viên thực sự có thể dễ dàng học bất kỳ ngôn ngữ nào trong vòng một tuần. Ngôn ngữ chỉ là công cụ để hoàn thành công việc, tôi nói. Lập trình là kỹ năng cuối cùng phải được học và thành thạo.

Làm thế nào tôi có thể chắc chắn rằng tôi thực sự đang học cách lập trình chứ không chỉ đơn giản là học các chi tiết của ngôn ngữ? Và làm thế nào tôi có thể phát triển các kỹ năng lập trình có thể áp dụng cho tất cả các ngôn ngữ thay vì chỉ một ngôn ngữ?


25
Cố gắng học một ngôn ngữ khác. Cố gắng giải quyết các vấn đề mà bạn đã biết cách giải quyết bằng ngôn ngữ đầu tiên bằng ngôn ngữ mới của bạn. Nó sẽ không dễ dàng ngay từ đầu. Nhưng bạn sẽ biết bạn đang học một khi giải quyết lại các vấn đề cũ theo cách mới trở nên dễ dàng hơn đáng kể (lưu ý: việc này có thể mất một chút thời gian).
Thất vọngWithFormsDesigner

42
Ngoài ra, những người tuyên bố có thể học một ngôn ngữ trong một tuần cần xác định ý nghĩa của họ khi họ nói "Học". "What do you mean you're not an expert in LanguageX?!? I can learn a language in a Week!". 1 tuần sau:"See, I've learnt the language, and here's a Hello World example I copied from Wikipedia to prove it!"
JohnL

9
Một câu hỏi cần phải được hỏi. Bạn có xây dựng logic của mình theo cú pháp hay bạn sử dụng một mô hình tinh thần nhanh hơn và hiệu quả hơn? Tôi thấy rằng các lập trình viên mới làm quen có xu hướng suy nghĩ bằng cách sử dụng cú pháp.
ChaosPandion

10
@PaulR: Tôi đã không mất 10.000 giờ để học cách đi xe đạp. Hoặc bơi, cho vấn đề đó.
Robert Harvey

7
@PaulR Câu nói là về nó lấy 10k giờ để làm chủ một kỹ năng, không chỉ đơn thuần là "học" nó
Tobias KIENZLER

Câu trả lời:


96

Đừng lo lắng về việc đáp ứng một số khái niệm lố bịch về "kỹ năng" thường được nghe trong các câu như:

  • Tất cả các ngôn ngữ lập trình về cơ bản là giống nhau.
  • Khi bạn chọn một ngôn ngữ tốt, bạn có thể chọn bất kỳ ngôn ngữ nào một cách nhanh chóng và dễ dàng.
  • Ngôn ngữ chỉ là công cụ, có một số phép thuật bao quát thực sự tạo ra phần mềm.

Những tuyên bố này đều dựa trên một tiền đề thiếu sót và phản bội sự thiếu kinh nghiệm trên một phổ rộng hơn của các ngôn ngữ lập trình. Chúng là những tuyên bố rất phổ biến và được các lập trình viên tin tưởng mạnh mẽ, tôi sẽ không tranh cãi về điều đó, nhưng tôi sẽ tranh luận về tính chính xác của chúng.

Điều này được chứng minh đơn giản: Dành một tuần (hoặc thực sự là bất kỳ khoảng thời gian nào lớn hơn một vài ngày) để cố gắng tìm hiểu các nguyên tắc cơ bản của Haskell , Prolog hoặc Agda . Bạn sẽ sớm bắt đầu nghe bài hát Sesame Street cũ phát trong đầu "Một trong những điều này không giống với những người khác ...".

Hóa ra, có rất nhiều ngôn ngữ lập trình, kỹ thuật và phương pháp tiếp cận rất xa lạ với những gì 95% chúng ta làm hoặc đã từng làm. Nhiều người hoàn toàn không biết rằng bất kỳ khái niệm nào khác thậm chí còn tồn tại, điều này cũng ổn và những khái niệm này không cần thiết để trở thành một lập trình viên được tuyển dụng và thậm chí hiệu quả.

Nhưng sự thật vẫn là: Những kỹ thuật và cách tiếp cận này tồn tại, chúng tốt cho nhiều thứ khác nhau và có thể rất hữu ích, nhưng chúng không giống như những gì bạn đã quen và mọi người không thể đơn giản đón chúng vào một buổi chiều nghịch ngợm.

Hơn nữa, tôi sẽ nói rằng phần lớn các trường hợp mọi người tuyên bố rằng họ có hoặc có thể học những thứ phức tạp như ngôn ngữ lập trình nhanh như vậy trong một tuần, họ đang chịu một chút Hiệu ứng Dunning Kruger , Wikipedia (nhấn mạnh của tôi):

Hiệu ứng Dunning của Kruger là một thiên kiến ​​nhận thức trong đó những người không có kỹ năng phải chịu sự vượt trội về ảo tưởng, đánh giá sai khả năng của họ cao hơn nhiều so với mức trung bình. Sự thiên vị này được quy cho một sự bất lực siêu nhận thức của những người không có kỹ năng nhận ra sai lầm của họ.

Tôi muốn giới thiệu cho mọi người về perview có kinh nghiệm hơn này về khái niệm học lập trình của Peter Norvig: Học lập trình trong mười năm .

Các nhà nghiên cứu (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) đã cho thấy phải mất khoảng mười năm để phát triển chuyên môn trong bất kỳ lĩnh vực nào, bao gồm chơi cờ, âm nhạc thành phần, hoạt động điện báo, vẽ tranh, chơi piano, bơi lội, quần vợt, và nghiên cứu về khoa học thần kinh và cấu trúc liên kết. Chìa khóa là thực hành có chủ ý: không chỉ thực hiện lặp đi lặp lại mà còn thử thách bản thân với một nhiệm vụ vượt quá khả năng hiện tại của bạn, thử nó, phân tích hiệu suất của bạn trong và sau khi thực hiện, và sửa chữa bất kỳ sai lầm nào. Sau đó lặp lại. Và lặp lại lần nữa.


Chắc chắn, có một bộ các nguyên tắc bao quát sẽ làm cho tất cả các ngôn ngữ dễ học!

Có lẽ, nhưng tôi sẽ cho rằng bộ nguyên tắc này quá lớn đến nỗi hầu như sẽ luôn có những ngôn ngữ ngoài tầm với một tuần của bạn. Khi bạn thêm các khái niệm mới vào danh sách mà bạn quen thuộc và thoải mái, danh sách các ngôn ngữ ngoài tầm với của bạn có thể bị thu hẹp, nhưng tôi có một thời gian khó tin rằng nó sẽ biến mất. Danh sách các phương pháp tiếp cận điện toán khái niệm cho mọi thứ rất rộng, nó khó hiểu, từ ngôn ngữ ghép nối đến ngôn ngữ dựa trên vectơ đến ngôn ngữ chuyên về AI hoặc siêu lập trình ( hoặc ngôn ngữ tồn tại hoàn toàn để hỗ trợ các biểu thức chính quy ).

Sau mười năm, bạn sẽ có thể lập trình nói chung. Điều này có nghĩa là bạn có thể viết một số mã khá trong một số ngôn ngữ hoặc phong cách ngôn ngữ. Vì vậy, sau 10 năm, bạn đã sẵn sàng để bắt đầu giải quyết vô số khái niệm xuyên suốt này cho đến hết cuộc đời và không còn là Edsger W. Dijkstra , Donald Knuth hay John D. Carmack , bạn sẽ không thể hiểu được tất cả của họ.


11
Tăng cường. Có một sự khác biệt giữa "biết" một ngôn ngữ và đủ thành thạo để khám phá và sửa một lỗi nhỏ trong một ngôn ngữ. Một lập trình viên giỏi có thể thực hiện sau này khá nhanh, ngay cả trong các ngôn ngữ cổ xưa.
Telastyn

5
@ CharlesE.Grant Tôi nghĩ bạn đánh giá quá cao những gì đa số học được ở trường đại học, cũng mất bao lâu để trở nên bán thành thạo một ngôn ngữ như Haskell hoặc Prolog. Tôi cho rằng một kỹ sư có kinh nghiệm trong ngành không có kinh nghiệm lập trình chức năng sẽ mất hơn một tuần để có thể sửa lỗi đầu tiên của mình trong chương trình Haskell.
Jimmy Hoffa

11
Tôi vẫn cho rằng tập hợp các khái niệm cơ bản là khá nhỏ gọn. Khi bạn hiểu cách viết lại thuật ngữ , bạn có một công cụ để xác định phép tính lambda, phép tính SK, máy Turing, thuật toán Markov, v.v. Một số ít ý tưởng thực sự cơ bản có thể bao quát hầu hết khoa học máy tính. Nhưng, tất nhiên, kinh nghiệm là cần thiết để có thể nhìn thấy các mẫu đơn giản trong những điều có vẻ phức tạp.
SK-logic

4
Tôi muốn nói rằng đó không phải là hiệu ứng Kruger của Dunning, vì đơn giản giả sử rằng "ngôn ngữ lập trình" = "ngôn ngữ lập trình kiểu c". Sau khi biết một lượng c ++ kha khá, một lượng C # kha khá và một vài mảnh vỡ của perl và python, tôi hy vọng tôi có thể trở nên thông thạo Java, PHP, v.v. trong một tuần. Không nhất thiết là chuyên gia, nhưng ít nhất là khá trôi chảy. Tôi đã chọn javascript trong một vài ngày. Tại thời điểm đó, chủ yếu là về việc tìm hiểu sự khác biệt giữa chúng. Lưu ý: ngôn ngữ trong thế giới thực phổ biến nhất giống như c. Điều tương tự sẽ không nhất thiết đúng với Prolog.
neminem

2
@WayneWerner Nghiêm túc, sự khác biệt giữa Haskell hoặc Prolog và các ngôn ngữ Algol là nhiều hơn nữa so với cú pháp, bạn chỉ việc duy trì huyền thoại. Làm bài kiểm tra của tôi ở trên: Dành một tuần cố gắng học Haskell và xem cách nó hoạt động với bạn. Thành thật mà nói, nó sẽ tốt cho bạn, rất nhiều điều để học hỏi từ việc đó.
Jimmy Hoffa

51

... Làm thế nào tôi có thể phát triển các kỹ năng lập trình có thể áp dụng cho tất cả các ngôn ngữ thay vì chỉ một ngôn ngữ?

Chìa khóa của câu hỏi này là vượt qua ngôn ngữ và suy nghĩ không phải ngôn ngữ bạn đang mã hóa.

BÌNH THƯỜNG?

Các lập trình viên polyglot có kinh nghiệm nghĩ về cây cú pháp trừu tượng (AST) của mô hình tinh thần của ngôn ngữ. Người ta không nghĩ rằng "Tôi cần một vòng lặp for ở đây", mà là "Tôi cần lặp lại một cái gì đó" và dịch nó thành thích hợp cho, hoặc trong khi, hoặc trình lặp hoặc đệ quy cho ngôn ngữ đó.

Điều này tương tự với những gì người ta nhìn thấy khi học một ngôn ngữ nói. Những người nói nhiều ngôn ngữ lưu loát nghĩ ý nghĩa , và nó phát ra trong một ngôn ngữ nhất định.

Người ta có thể thấy một số manh mối của AST này trong cặp video về khả năng hiểu mã với theo dõi bằng mắtthí nghiệm mã theo dõi mắt (Novice) trong đó các chuyển động của mắt của một người mới bắt đầu và lập trình viên có kinh nghiệm được xem. Người ta có thể thấy lập trình viên có kinh nghiệm 'biên dịch' mã thành mô hình tinh thần của họ và 'chạy' nó trong đầu, trong khi người mới bắt đầu phải lặp lại từ khóa mã theo từ khóa.

Do đó, chìa khóa cho câu hỏi phát triển kỹ năng lập trình để áp dụng cho tất cả các ngôn ngữ là học nhiều ngôn ngữ để người ta có thể tránh xa mô hình tinh thần của một ngôn ngữ và phát triển khả năng tự tạo AST cho một vấn đề một ngôn ngữ đầu sau đó được dịch sang một ngôn ngữ nhất định.

Khi một người có khả năng sử dụng AST trong đầu, việc học một ngôn ngữ khác trong trường phái tư tưởng tương tự (đi đến Befunge là một bước nhảy vọt từ Java, nhưng không nhiều từ Forth ) trở nên dễ dàng hơn nhiều - đó là 'chỉ' dịch AST sang một ngôn ngữ mới dễ dàng hơn nhiều trong lần thứ 3, 4 và 5 (v.v ...).


Có một bài viết kinh điển, Lập trình viên thực sự Đừng sử dụng Pascal . Một phần của điều này đọc:

... Lập trình viên thực sự quyết tâm có thể viết các chương trình Fortran bằng bất kỳ ngôn ngữ nào

Cũng có những bit mà bạn không thể sử dụng AST tinh thần - bạn cũng cần phải suy nghĩ bằng ngôn ngữ. Điều này cần một chút thời gian để hoàn thành (Tôi vẫn bị cáo buộc viết mã Perl bằng Python và mã Lisp đầu tiên của tôi đã được xem xét nói rằng "Đây là một chương trình C rất tốt.").

Về vấn đề này, tôi phải chỉ ra một bài báo được xuất bản bởi ACM, Làm thế nào để không viết Fortran bằng bất kỳ ngôn ngữ nào . Đoạn thứ ba của bài viết (không phải là trích dẫn hàng đầu) trực tiếp giải quyết câu hỏi:

Có những đặc điểm của mã hóa tốt vượt qua tất cả các ngôn ngữ lập trình có mục đích chung. Bạn có thể thực hiện thiết kế tốt và phong cách minh bạch trong hầu hết mọi mã, nếu bạn tự áp dụng nó. Chỉ vì một ngôn ngữ lập trình cho phép bạn viết mã xấu không có nghĩa là bạn phải làm điều đó. Và một ngôn ngữ lập trình đã được thiết kế để thúc đẩy phong cách và thiết kế tốt vẫn có thể được sử dụng để viết mã khủng khiếp nếu người viết mã đủ sáng tạo. Bạn có thể bị chết đuối trong một bồn tắm với một inch nước trong đó, và bạn có thể dễ dàng viết một chương trình hoàn toàn không thể đọc được và không thể nhầm lẫn bằng một ngôn ngữ không có số gotos hoặc số dòng, với xử lý ngoại lệ và loại chung và bộ sưu tập rác. Cho dù bạn đang viết Fortran hay Java, C ++ hay Smalltalk, bạn có thể (và nên) chọn viết mã tốt thay vì mã xấu.

Nó không đủ để có AST - cần có AST để người ta có thể dịch sang các ngôn ngữ khác. Có một Fortran AST trong đầu và viết mã Fortran bằng Java không phải là một điều tốt. Người ta cũng phải đủ quen thuộc với ngôn ngữ và thành ngữ của nó để có thể suy nghĩ bằng ngôn ngữ (bất chấp những gì tôi đã nói ở trên cùng).

Tôi đã thấy mã Java được viết bởi một người chưa ngừng viết mã C. Có một đối tượng với một phương thức chính. Trong đối tượng này là một loạt các phương thức tĩnh được gọi bởi mainvà các lớp bên trong riêng có các trường công khai (và do đó trông rất giống các thanh chống). Đó là mã C được viết bằng Java. Tất cả những gì đã được thực hiện là dịch cú pháp của ngôn ngữ này sang ngôn ngữ khác.

Để vượt qua điểm này, người ta cần tiếp tục viết mã bằng nhiều ngôn ngữ, không nghĩ theo các ngôn ngữ đó khi thiết kế mã, mà hãy nghĩ về chúng khi dịch thiết kế thành mã để làm việc với các thành ngữ ngôn ngữ một cách chính xác.

Cách duy nhất để đạt được điều đó - có thể phát triển các kỹ năng lập trình có thể áp dụng cho tất cả các ngôn ngữ - là tiếp tục học ngôn ngữ và giữ cho ngôn ngữ lập trình tinh thần đó linh hoạt thay vì liên kết với một ngôn ngữ.

(Tôi xin lỗi ChaosPandion vì đã vay mượn rất nhiều từ ý tưởng mà anh ấy trình bày .)


3
Không cần phải xin lỗi. Tôi nghĩ rằng bạn đã viết một câu trả lời ấn tượng.
ChaosPandion

Tôi muốn ghi nhận người đã khiến tôi nghĩ về nó theo hướng đó để viết câu trả lời.

3
Đây là một câu trả lời rất tốt. Ước gì tôi có thể upvote hai lần.
Wayne Werner

2
Trên thực tế đây chính xác là lý do tại sao bạn không nên học OO trước, vì điều này định dạng bộ não của bạn với một trong những điều tồi tệ nhất có thể tưởng tượng được.
Mẹ ơi.

1
@JimmyHoffa - Bạn có thể đúng. Ban đầu tôi luôn được dạy bằng một ngôn ngữ và từ từ giới thiệu thêm về sau. Tuy nhiên, tôi nghĩ rằng nó đáng để khám phá vì tôi luôn có thể nhấn phanh và tập trung vào một ngôn ngữ. (SML có vẻ như là một lựa chọn khá tốt trên thực tế.)
ChaosPandion

12

Chọn một ngôn ngữ và bắt đầu viết mã. Python là một lựa chọn tốt cho người mới bắt đầu và có các hướng dẫn có sẵn trực tuyến , để bạn có thể học cách làm điều đó đúng cách.

Mọi thứ sau đó. Sở thích của bạn sẽ dẫn bạn đến các khung và các khái niệm thiết kế sẽ thêm sự tinh tế cho các chương trình của bạn. Bạn sẽ khám phá ra rằng có những khóa học trực tuyến bạn có thể tham gia sẽ đưa bạn vào các nguyên tắc cơ bản và lý thuyết, và có những mô hình lập trình khác nhau mà bạn có thể khám phá, v.v.

Và vâng, bạn sẽ khám phá các ngôn ngữ như Haskell sẽ dạy cho bạn một cái gì đó mới, một khi bạn có một nền tảng vững chắc về các nguyên tắc cơ bản.

Một số lập trình viên có thể nghĩ rằng tất cả các ngôn ngữ đều giống nhau vì họ không được tiếp xúc với bất kỳ ngôn ngữ nào khiến họ nghĩ khác. Tất cả các ngôn ngữ được sử dụng phổ biến nhất đều có nguồn gốc từ Algol (về cơ bản là các ngôn ngữ thủ tục) và trong số đó, hầu hết là các ngôn ngữ có kiểu xoăn tương tự như C. Tất cả chúng đều có cùng một thứ, mặc dù một số ngôn ngữ có độ tinh vi hơn các ngôn ngữ khác.


2
Điều này không thực sự đúng mặc dù? Một số ngôn ngữ lập trình mã hóa mọi thứ dưới dạng các hàm thuần túy (bao gồm các quyết định + vòng lặp). Những người khác có thể được mô hình hóa bằng cách đẩy và bật các đối tượng từ các bộ, v.v.
jozefg

1
Điều gì không đúng? Bạn phải học cách bò trước khi bạn có thể đi bộ hoặc chạy.
Robert Harvey

1
Ah tôi nên xác định, tôi có nghĩa là đoạn cuối cùng, tôi đồng ý với phần còn lại của câu trả lời
jozefg

1
Tôi đã thay thế đoạn cuối bằng một đoạn thể hiện tốt hơn tình cảm của tôi.
Robert Harvey

5

Lập trình là về giải quyết các vấn đề theo cách mà giải pháp có thể được diễn đạt bằng ngữ pháp hạn chế đến mức có thể thực hiện bằng ngôn ngữ lập trình. Do đó nghệ thuật lập trình là nghệ thuật giải quyết vấn đề.

Một số ngôn ngữ nhất định mời các mô hình lập trình khác như định hướng đối tượng, hướng sự kiện, đa luồng và dựa trên khung MVC. Đây chỉ là các mô hình và mô hình và không có gì thực sự có liên quan đến việc thực hiện.

Nếu bạn có thể ngồi và giải quyết vấn đề trên giấy theo cách có thể dễ dàng dịch thành mã và được liên kết với một mô hình phù hợp cho nền tảng của bạn, thì bạn là một lập trình viên. Nếu tất cả những gì bạn có thể làm là lấy những giải pháp đó và thực hiện chúng bằng ngôn ngữ đã chọn của chúng tôi, thì đó lại là một vấn đề khác.

Tôi đã lập trình được 30 năm (OMFG!) Và vẫn sử dụng php.netđể tra cứu các lệnh trong PHP vì đó không phải là ngôn ngữ đầu tiên của tôi.

Tôi muốn nói rằng chuyên môn về ngôn ngữ tỷ lệ nghịch với tần suất bạn nhìn vào hướng dẫn sử dụng hoặc stackoverflow. Chuyên môn về lập trình là cách bạn dễ dàng giải quyết các vấn đề theo cách tương thích với các ngôn ngữ lập trình máy tính.

Trong các tin tức liên quan, tôi đã học được Ruby tuần trước. Mặc dù tôi không phải là "chuyên gia", tôi có thể giải quyết cho bạn một vấn đề mà tôi có thể viết bằng Perl, nói và sau đó dành một độ tuổi để dịch nó cho Ruby trong khi tôi tìm hiểu thêm.


Nhận xét của bạn là người đầu tiên tôi đọc về các mô hình và các mẫu! Tôi 100% với nhận xét của bạn, một điều là có được một ngôn ngữ và bắt đầu thực hiện một chương trình. Một cách khác là suy nghĩ vấn đề và tìm các công cụ thích hợp để giải quyết nó, sau đó bạn bắt đầu tìm kiếm một ngôn ngữ và bắt đầu lập trình.

3

Tôi nghĩ, như với bất cứ điều gì, thực hành làm cho hoàn hảo. Đừng tự nhốt mình luôn luôn làm điều tương tự hoặc luôn sử dụng cùng một ngôn ngữ và tiếp tục học hỏi mọi thứ trong mọi dự án.

Tôi nghĩ rằng bạn có thể dễ dàng vẽ song song với một cái gì đó như học chơi guitar. Bất kỳ nhạc sĩ giỏi nào cũng có thể học chơi một bài hát mới trong một khoảng thời gian rất ngắn, bởi vì họ đã biết tất cả các hợp âm và tất cả lý thuyết đằng sau lý do tại sao các hợp âm được chơi theo cách của họ. Làm thế nào để họ có được điều đó tốt? Họ chỉ chơi rất nhiều bài hát mà tất cả các mẫu vừa hòa quyện với nhau, đồng thời bổ sung kiến ​​thức của họ với lý thuyết tài liệu thực tế mà những mẫu đó cũng đăng ký.

Vì vậy, có thể bạn có thể chơi một vài bài hát rất hay, nhưng bạn không thể đi chệch hướng hoặc chọn bài hát mới một cách nhanh chóng. Điều này có lẽ tương đương với một lập trình viên .NET tiếp tục tạo ra cùng một ứng dụng CRUD , đôi khi thử một cái gì đó mới, thêm vào một số cuộc gọi dịch vụ web hoặc giao diện người dùng nâng cao hoặc viết bằng ngôn ngữ hoàn toàn mới. Khi bạn nhìn vào lý do tại sao mọi thứ xảy ra theo cách họ làm, hãy đặt câu hỏi trên Stack Exchange, v.v ... Cuối cùng, bạn sẽ thấy tất cả các mô hình liên tục xuất hiện và biết một số lý thuyết cơ bản và học một ngôn ngữ mới sẽ không có vẻ gần như nản chí.


1

Tôi sẽ không nhấn mạnh việc học một ngôn ngữ mất bao lâu hoặc học ngôn ngữ nghĩa là gì, thay vào đó tôi sẽ giải quyết vấn đề thực tế của bạn: làm thế nào để xác định xem bạn đã học lập trình hay học ngôn ngữ lập trình .

Bạn đã học lập trình nếu bạn đã học cách chia nhỏ vấn đề thành các quy trình riêng biệt và sau đó sử dụng các quy trình đó để giải quyết vấn đề của mình. Bạn đã học một ngôn ngữ progamming nếu bạn đã học cú pháp của ngôn ngữ và biết cách điều chỉnh cách một quy trình hoạt động, khi được thực hiện bằng ngôn ngữ đó.

Điều này không có nghĩa là bạn nên lập trình trong Fortan khi sử dụng Lisp hoặc thêm các giá trị của một cột trong bảng trong một db bằng con trỏ. Chỉ cần ngôn ngữ là một chi tiết thực hiện. Một quy trình có thể thay đổi những quy trình cần thiết, nhưng không cần xác định và tạo quy trình - cuối cùng có một triển khai trong thế giới thực, với đầu vào / đầu ra và kết quả mong muốn.


1

Chiến lược của tôi luôn là tập trung vào các kỹ năng thuần túy hơn là các kỹ năng cụ thể.

Thay vì học cú pháp đặc biệt của Python (hoặc bất kỳ ngôn ngữ nào) cho bất cứ điều gì bạn muốn làm, hãy dành thời gian cho bộ não của bạn để giải quyết các vấn đề trừu tượng, như cách giải quyết tốt nhất mọi vấn đề trong danh mục đó.

Bằng cách đó, bạn sẽ biết phải làm gì cho dù là ngôn ngữ và chủ yếu sẽ sở hữu các kỹ năng vượt thời gian có thể được sử dụng để lập trình bằng bất kỳ ngôn ngữ nào.

Cụ thể tránh các công cụ chứa đầy các vấn đề, như MySQL hoặc các ngôn ngữ có ý kiến, như Java, vì bất cứ điều gì bạn học được bằng cách sử dụng các công cụ này sẽ có một tỷ lệ lớn kiến ​​thức cụ thể về công cụ, chắc chắn sẽ trở nên vô dụng khá nhanh.

Trái ngược với những gì đã được nói trong nhiều câu trả lời, KHÔNG lắng nghe các lập trình viên khác, Bạn là một người mới và không có cách nào bạn có thể nói giả từ thỏa thuận thực sự, vì vậy tốt hơn hết bạn nên dùng mọi thứ bằng một thìa muối.

Bạn muốn được đặt câu hỏi mọi lúc và chỉ chấp nhận khi giải pháp nhanh chóng, thanh lịch và đáng tin cậy.


1
"KHÔNG nghe các lập trình viên khác" - vâng chắc chắn. "- Làm thế nào bạn biết nếu bạn đã viết mã có thể đọc và dễ bảo trì? - Bạn bè của bạn nói với bạn sau khi xem lại mã. Đặt vấn đề: Bạn không thể tự xác định điều này vì bạn biết nhiều về tác giả hơn là mã tự nói không thể nói với bạn, vì những lý do tương tự mà nó không thể biết bức tranh có phải là nghệ thuật hay không. Do đó, bạn cần một người khác - có khả năng duy trì phần mềm - để xem những gì bạn đã viết và đưa ra ý kiến ​​của mình ... " ( nguồn trích dẫn )
gnat

@gnat làm bất cứ điều gì bạn thích. Tôi chỉ nói với bạn rằng vì hầu hết các lập trình viên không thể viết mã cho shit, phản hồi của họ có khả năng gây hại và bạn nên mang theo túi và túi muối để giải quyết vấn đề đó. Ngoài ra tôi tin rằng "có thể chỉnh sửa và có thể đọc được bởi các morons" hoàn toàn không phải là dấu hiệu của chất lượng. Hãy tin những gì bạn muốn nhưng đừng đi vòng -1 chỉ vì mọi người không đồng ý với tầm nhìn của bạn.
Mẹ ơi.

phiếu bầu của tôi cho thấy đánh giá về chất lượng bài đăng , không phải là tôi đồng ý hay không đồng ý (thỏa thuận wrt, tôi nghĩ rằng bạn có một điểm ở đây). Tôi đã trích dẫn một ý kiến ​​khác không phải vì nó ngược lại, mà bởi vì nó có một lời giải thích chắc chắn (xem "RATIONALE"). Nếu bạn có thể nghĩ ra lời giải thích vững chắc tương tự để sao lưu ý kiến ​​của mình, hãy xem xét chỉnh sửa bài đăng để thêm nó
gnat

bất cứ điều gì. nội dung> hình thức. giữ hình thức của bạn, tôi sẽ giữ nội dung của tôi.
Mẹ ơi.

0

Có cách tiếp cận lý thuyết. Tìm hiểu về cách máy tính thực sự hoạt động dưới vỏ bọc. Làm thế nào các hướng dẫn bộ xử lý cơ bản được xâu chuỗi lại với nhau để tạo ra các hoạt động và cấu trúc phức tạp hơn mà chúng ta đã được cấp trong vùng lập trình cấp cao.

Sau đó, có cách tiếp cận lập trình thực tế hơn. Điểm chính mà người mắc bệnh dịch hạch thường gọi là "lập trình viên không giỏi" là họ chỉ thực sự biết một ngôn ngữ. Và ngay cả khi họ biết người khác, họ lập trình trong đó giống như cách họ làm với ngôn ngữ mẹ đẻ của họ . Đó là một chu kỳ người ta phải phá vỡ nếu họ thực sự muốn học cách lập trình. Câu trả lời mặc định cho điều đó là học ít nhất một ngôn ngữ từ mỗi mô hình lập trình. Vì vậy, học một ngôn ngữ OOP, một ngôn ngữ chức năng, một ngôn ngữ kịch bản ... vv Và bằng cách học tôi không có nghĩa là học cú pháp . Bạn học một ngôn ngữ bằng cách thực sự sử dụng nó để tạo ra một cái gì đó.

Cá nhân, khi tôi muốn học một ngôn ngữ mới, tôi sử dụng các trình đánh đố Project Euler . Tôi đi đến một câu đố mà tôi đã giải bằng ngôn ngữ OOP (làm ví dụ) và cố gắng giải nó bằng cách sử dụng một chức năng trong khi cố gắng tuân theo các thực tiễn tốt nhất của ngôn ngữ mới. Khi bạn giải quyết cùng một vấn đề bằng hai cách tiếp cận khác nhau cơ bản, bạn không chỉ thấy sự khác biệt thực sự là gì, mà chúng còn cho bạn thấy khu vực chung ở đâu. Những lĩnh vực phổ biến được chia sẻ bởi tất cả các ngôn ngữ là lập trình thực sự , sự khác biệt chỉ là những cách khác nhau để đạt được nó.


4
Tôi sẽ không gọi việc học về hành vi vật lý của máy tính là "cách tiếp cận lý thuyết", "cách tiếp cận lý thuyết" sẽ là học lý thuyết, đọc luận án bảo vệ nhà thờ và tìm hiểu về sự bất đẳng thức của cà ri, học phép tính lambda và cơ bản của lý thuyết số, đây là nền tảng lý thuyết. Không nói câu trả lời của bạn là đúng hay sai, chỉ nói tôi sẽ đề cập đến điều đó như cách tiếp cận cụ thể không phải là lý thuyết vì nó thiếu lý thuyết.
Jimmy Hoffa

@JimmyHoffa - Điểm tốt!
Hệ thống xuống

1
"Làm thế nào các hướng dẫn bộ xử lý cơ bản được xâu chuỗi lại với nhau (...)" có vẻ như là ý tưởng khủng khiếp cho người mới bắt đầu (OP không nói rằng anh ta là một người nhưng hãy giả sử để tranh luận. Nó sẽ dạy 'tối ưu hóa vi mô' mà không thực sự dạy cách để tối ưu hóa (kiến trúc 3-5 giai đoạn có thể được coi là hơi lỗi thời ...). Đừng hiểu sai về tôi - sự hấp dẫn của CA - nhưng 'sự đánh giá đúng' sẽ yêu cầu các từ như 'không theo trật tự' và 'đa tài', và có lẽ đến sau một số kinh nghiệm lập trình cơ bản.
Maciej Piechotka

0

Chà, hầu hết những điều tôi muốn nói đã được nói rồi. Những gì tôi muốn thêm là một tương tự rất đơn giản.

Nếu các ngôn ngữ lập trình được coi là công cụ đơn thuần, thậm chí sau đó hoàn toàn không có logic trong việc giỏi một thứ khiến cho người khác giỏi làm bánh.

Chỉ cần xem xét một nhóm các kiếm sĩ bậc thầy có uy tín, đột nhiên đặt kiếm xuống và chiến đấu với giáo sau 7 ngày huấn luyện. Chuyện gì sẽ xảy ra? Họ sẽ bị tàn sát.

Ngôn ngữ thường không khó học nhưng cần có sự kiên nhẫn và tập thể dục để giỏi về nó. Ngoài ra, không có cách đúng để học lập trình.

Học lập trình cũng giống như chơi một game RPG. Đôi khi bạn sử dụng kiếm, đôi khi là giáo, đôi khi là khiên. Mỗi kẻ thù bạn giết, bạn nhận được điểm kinh nghiệm. Một khi bạn có đủ điểm kinh nghiệm, bạn lên cấp. Bây giờ thành thạo một thanh kiếm sẽ không khiến bạn trở nên xuất sắc với cung tên. Nhưng một phần kinh nghiệm bạn có được trước đây sẽ tăng sức chịu đựng và tốc độ của bạn.

Đây là một vài điều bạn có thể muốn làm khi học một ngôn ngữ.

  • Đọc về ngôn ngữ. Nếu nó có vẻ thú vị, hãy tự mình thử ứng dụng hello world (s).
  • Đọc một số hướng dẫn, thủ thuật, blog.
  • Làm cho các ứng dụng đơn giản trong đó chỉ để cho vui.
  • Kiểm tra các tính năng khác nhau.
  • Nếu bạn thực sự thích nó, hãy mua một số sách và / hoặc video hướng dẫn.
  • Tìm kiếm các thư viện tốt.
  • Tìm kiếm câu trả lời, chỉ hỏi nếu bạn không thể tìm thấy câu trả lời.
  • Giúp người khác yêu cầu câu trả lời (nơi nào tốt hơn ở đây?)
  • Làm một cái gì đó hữu ích. Làm một ứng dụng máy tính có thể là một bài tập tốt nhưng nếu bạn tạo một ứng dụng danh sách TO-DO và thực sự bạn sử dụng trên PC / Điện thoại của mình, cảm giác đó là thỏa đáng gấp 100 lần.

Trải nghiệm ngôn ngữ mới, khám phá thư viện mới, tìm hiểu các thủ thuật mới vào thời gian rảnh của bạn. Trước khi bạn biết điều đó, bạn sẽ ngạc nhiên với kỹ năng của chính mình.


0

Trong trường hợp của tôi, tôi học cách lập trình thực sự thông qua những điều sau đây:

  1. Học hỏi từ các bậc thầy. Nghe podcast lập trình, đọc blog chuyên nghiệp trong chủ đề lập trình mà bạn chọn, đọc / xem các hướng dẫn tuyệt vời được thực hiện bởi các bậc thầy được phân tán trên web và cuối cùng, đọc các cuốn sách sử thi như Lập trình viên thực dụng . Cuốn sách này có rất nhiều viên ngọc lập trình đã được tích lũy trong suốt sự nghiệp của các tác giả. Một cách chắc chắn để học cách thực sự viết mã là để biết các lập trình viên thành công khác làm điều đó như thế nào.
  2. Kinh nghiệm bằng cách làm. Đọc về nó và biết là một chuyện, thực sự đưa nó vào thực tế và làm cho nó hoạt động là một chuyện khác. Không có giáo viên nào tốt hơn kinh nghiệm, vì vậy hãy đặt nắp mã hóa của bạn lên và bắt đầu.
  3. Hỏi ai đó biết. Giống như bạn đang làm bây giờ, đừng ngại hỏi về các thực tiễn tốt nhất hoặc cách tốt hơn để làm những việc từ người cao niên trong nhóm của bạn, hoặc nếu bạn không may không có quyền truy cập vào người cao niên hoặc cố vấn hoặc bậc thầy, sau đó vẫn còn phần còn lại của stackexchange và internet để hỏi.

Ngoài ra, như các bình luận viên của bạn đã đề cập, đừng quên làm chủ các công cụ của bạn. Học tất cả các thực tiễn tốt nhất và lý thuyết tốt nhất đều là vô ích hoặc sẽ được triển khai kém nếu bạn không biết đủ về công cụ của mình, trong trường hợp này là ngôn ngữ lập trình.


0

Tôi nghĩ, nếu bạn có thể suy nghĩ phân tích, bạn có một khởi đầu tốt.

Học bất kỳ ngôn ngữ nào bạn muốn và tự mình làm việc với một loạt các ví dụ, ví dụ như được trình bày trong cuốn sách gần như dạy về lập trình.

Tiếp theo hãy cố gắng giải quyết vấn đề của riêng bạn. Cố gắng tìm các giải pháp khác nhau và so sánh chúng. Tốc độ và sử dụng bộ nhớ là những yếu tố thường được sử dụng. Thảo luận về giải pháp của bạn với các lập trình viên khác.

Đọc mã của các lập trình viên khác và cố gắng hiểu tại sao họ giải quyết vấn đề theo cách này.

Bạn cũng nên đọc một số cuốn sách về các thuật toán để có cái nhìn tổng quan về các phương pháp tiêu chuẩn. Các vấn đề mới thường là sửa đổi các vấn đề cũ.

Rất nhiều thực hành và làm việc với mã cũng trong các nhóm sẽ giúp bạn tăng cường kỹ năng từng bước.

Tôi hy vọng ý kiến ​​của tôi trả lời bạn câu hỏi ít nhất một phần.

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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.