Có phải lập trình nói chung trở nên dễ đọc, viết và hiểu hơn khi bạn có kinh nghiệm? [đóng cửa]


80

Tôi là người mới bắt đầu lập trình và tôi đã đọc sách, nghiên cứu, đọc các bài báo và không có gì. Tôi nhận được kết quả tuyệt vời kể từ khi tôi bắt đầu học lập trình, và khi tôi mới bắt đầu, tôi đã từng nghĩ rằng tôi biết mọi thứ về lập trình, nhưng khi tôi học được nhiều hơn, tôi nhận ra lĩnh vực này khó khăn như thế nào (Thực tế tất cả các lĩnh vực đều khó khăn, nhưng đó không phải là vấn đề)

Ngày nay, tôi đã viết phần mềm chức năng và tôi đã học CƠ BẢN của 3 ngôn ngữ và tôi là trung gian chỉ trong một ngôn ngữ. Khi tôi nhìn vào những thứ nâng cao như MYSQL, hoặc lập trình OpenGL, hoặc thậm chí mã C ++ của studio trực quan, nó làm tôi đau đầu và ngay cả khi hình dung mã nguồn HTML của nhiều trang web (Hầu hết các mã nguồn trên các trang web, được thấy bởi google chrome có vẻ rất lộn xộn và không có tổ chức ) nó làm tôi bối rối đến giới hạn của bộ não. Tất cả ban đầu có vẻ đơn giản, nhưng khi nhìn vào những điều tiên tiến này, nó chỉ khiến tôi tự hỏi làm thế nào người ta có thể học được nhiều như vậy.

Câu hỏi, một cách ngắn gọn, là nếu những điều này trở nên rõ ràng hơn đối với một lập trình viên khi anh ta tiến bộ trong sự nghiệp. Các chủ đề phức tạp như những chủ đề được liệt kê ở trên (OpenGL, MySQL, các trang html nâng cao) trở nên dễ đọc, viết và hiểu hơn khi bạn tìm hiểu thêm hay nó chỉ trở nên phức tạp hơn khi bạn đi qua? Làm thế nào bạn có thể chống lại cảm giác rằng bạn là một con kiến ​​trong thế giới lập trình và công cụ này là bàn chân sắp đè bẹp bạn?


24
Tôi đề nghị bạn đọc cái này: norvig.com/21-days.html
James P.

Giống như bất cứ điều gì khác, vâng. Cho đến khi công nghệ thay đổi trên bạn. :-)
MathAttack

3
Miễn là "trải nghiệm" của bạn không đọc đi đọc lại những điều tương tự. Căng mình với những thứ mới.
JeffO

một mẹo nhỏ, để phân tích các trang HTML phức tạp, bạn muốn sử dụng Firebird của Firefox hoặc Thành phần kiểm tra của Chrome.
Lie Ryan

6
"Khi tôi mới bắt đầu, tôi đã từng nghĩ rằng tôi biết mọi thứ về lập trình." Ở đó và càng học, tôi càng nhận ra mình biết ít như thế nào.
Lieven Keersmaekers

Câu trả lời:


134

Câu trả lời ngắn gọn: không.

Câu trả lời dài:

Đọc mã của người khác trở nên dễ dàng hơn, vâng. Nhưng chỉ đọc thôi. Khi bạn có được kinh nghiệm và kỹ năng, các yêu cầu cá nhân của bạn với tư cách là một nhà phát triển sẽ tăng lên.

  • Bạn không muốn chỉ viết mã. Bạn muốn viết mã đẹp .

  • Bạn không cho rằng mã của bạn chạy trong điều kiện lý tưởng . Bạn bắt đầu suy nghĩ về tất cả những điều tồi tệ có thể xảy ra khi chạy mã của bạn, xử lý các trường hợp ngoại lệ, suy nghĩ về các vấn đề phần cứng, độ trễ mạng và vấn đề phát triển khi kỹ năng của bạn phát triển.

  • Bạn không đọc và viết mã bằng ngôn ngữ duy nhất bạn biết. Là một nhà phát triển khéo léo, bạn biết rằng để giải quyết vấn đề cụ thể này bạn có ngay bây giờ, lập trình chức năng là một giải pháp thay thế tốt hơn nhiều , vì vậy bây giờ bạn phải đọc và viết mã bằng ngôn ngữ lập trình chức năng.

  • Bạn không giới hạn bản thân trong một bộ thư viện nhỏ mà bạn biết. Nếu bạn viết mã bằng C #, bạn muốn biết và sử dụng toàn bộ sức mạnh của nhiều thư viện của .NET Framework.

  • Bạn không sử dụng notepad nữa. Bạn cần IDE mạnh mẽ của mình và bạn muốn biết cách kiểm tra mã đơn vị, số liệu mã là gì và ý nghĩa của hàng trăm tùy chọn và cửa sổ mà IDE của bạn có thể hiển thị cho bạn.

  • Bạn không muốn giới hạn bản thân một cách khiêm tốn vào một bộ công cụ cơ bản mà ngôn ngữ mang lại cho bạn . Trong C #, bạn muốn sử dụng thuốc generic, hợp đồng mã, phản ánh, phát triển theo hướng sự kiện, các khía cạnh chức năng với LINQ, tiện ích mở rộng Reactive và hàng tấn thứ khác bạn đã học, tất cả trong một dự án, nếu những điều đó giúp bạn viết tốt hơn mã.

  • Bạn không bắt đầu viết mã . Bạn dành 80 đến 90% thời gian để thu thập các yêu cầu của mình , tạo kiến trúc cho ứng dụng của bạn, viết bài kiểm tra đơn vị, viết tài liệu, v.v. và chỉ 10 đến 20% thời gian của bạn để viết mã thực tế .

  • Bạn quan tâm về an ninh . Bạn biết các vấn đề pháp lý có thể phát sinh với dữ liệu bị các ứng dụng của bạn thao túng. Bạn biết ITIL là gì . Bạn biết một số tiêu chuẩn ISO và bạn áp dụng chúng hàng ngày trong công việc của bạn.

Vâng, bạn có được kinh nghiệm và kỹ năng, và nó trở nên dễ dàng hơn để giải quyết một vấn đề nhất định với tất cả các kiến ​​thức và khả năng trí tuệ bạn có được. Nhưng vấn đề bạn cũng phải giải quyết tăng lên và bạn không hào hứng giải quyết vấn đề ở cấp độ của những vấn đề tôi đã giải quyết khi bạn bắt đầu lập trình.

Trong khi đạt được các kỹ năng, bạn cũng có được cái nhìn sâu sắc về sự phức tạp của việc phát triển phần mềm, tìm hiểu các khía cạnh bạn thậm chí không thể tưởng tượng được khi bắt đầu học lập trình, và bạn muốn và cần áp dụng tất cả những thứ bạn học hàng ngày.

Nói ngắn gọn:

  1. Ngày đầu tiên bạn bắt đầu học lập trình, nhiệm vụ liệt kê tất cả các số từ 1 đến 100 chia hết cho hai là rất phức tạp: bạn chỉ học cách tạo vòng và hiển thị số trên màn hình, nhưng bạn không biết làm thế nào để tìm nếu số chia hết cho hai.

  2. Mười năm sau, bài tập tương tự dường như cực kỳ đơn giản. Nhưng mười năm sau, bạn đang viết các ứng dụng phải sử dụng giao dịch, được lưu trữ trên một số máy chủ và phải xử lý trạng thái phiên giữa các máy chủ và lưu trữ chi tiết tài khoản ngân hàng của khách hàng của bạn, với tất cả các khía cạnh bảo mật và pháp lý.

  3. ... Và bạn đang tự hỏi "Làm thế nào tôi có thể làm điều đó?" giống hệt như cách bạn đã làm mười năm trước khi bạn phải hiển thị số cho màn hình bằng một vòng lặp.

Khi mọi thứ trở nên dễ dàng với bạn trong một miền, điều đó có nghĩa là bạn đã đạt được sự hoàn hảo trong miền này hoặc bạn không quan tâm nữa.

Đạt được sự hoàn hảo trong một lĩnh vực rộng lớn như phát triển phần mềm là không thể, bất kể bạn thông minh đến đâu.


36
Đi bộ trên nước và phát triển phần mềm từ một đặc điểm kỹ thuật rất dễ dàng nếu cả hai đều bị đóng băng (điều đó cho thấy rằng "Bạn không bắt đầu viết mã. Bạn dành nhiều tháng để thu thập các yêu cầu" là một chút phi thực tế)
jfs

9
"Lập trình chức năng là một sự thay thế tốt hơn nhiều " đang gây tranh cãi.
jfs

15
Tôi chắc chắn hy vọng bit "lập trình chức năng" chỉ là một ví dụ về "sử dụng công cụ phù hợp cho công việc" hơn là ngụ ý rằng lập trình chức năng thực sự tốt hơn cho sử dụng chung.
Ben Brocka

7
Tôi cũng sẽ lưu ý rằng "các yêu cầu thu thập tháng" không có sự phát triển sẽ chỉ xảy ra trong một mô hình Thác nước lý tưởng hóa. Nếu bạn không lặp đi lặp lại, bạn đang tự giết mình và dự án.
Ben Brocka

8
"Nó không bao giờ dễ dàng hơn, bạn chỉ cần đi nhanh hơn." / Greg LeMond /
daGrevis

20

Khi còn nhỏ, bạn học nói và sau đó đọc ngôn ngữ mẹ đẻ của mình. Cơ học đơn giản của nó là một cuộc đấu tranh lúc đầu, nhưng đến một lúc nào đó nó trôi chảy. Tuy nhiên, bạn vẫn có một nguồn cung cấp vô hạn những cuốn sách bạn chưa đọc và về một số chủ đề bạn phải tăng vốn từ vựng trước tiên để có thể hiểu cuốn sách.

Điều tương tự cũng xảy ra với lập trình máy tính. Tại một số thời điểm, ngôn ngữ tự dừng lại giống như một ngôn ngữ nước ngoài, nhưng vẫn còn rất nhiều thứ được viết bằng ngôn ngữ đó mà bạn chưa biết. Nhưng tất cả mọi thứ có thể truy cập với bạn với một số nỗ lực.

Một số công việc lập trình rất lặp đi lặp lại, về cơ bản triển khai lại phần mềm rất giống nhau cho các khách hàng khác nhau. Trong những công việc đó, bạn có thể cảm thấy như bạn đạt đến một cao nguyên học tập. Những công việc khác bạn đang làm một cái gì đó mới và độc đáo mọi lúc, và không bao giờ ngừng học hỏi những điều mới.


18

Có một số câu trả lời thực sự tốt ở đây đã có nhưng tôi nghĩ rằng tôi có thể thêm một vài điểm ngắn hơn:

Khi tôi mới bắt đầu, tôi đã từng nghĩ rằng tôi biết mọi thứ về lập trình, nhưng khi tôi học được nhiều hơn, tôi nhận ra lĩnh vực này khó khăn như thế nào

Đây được gọi là hiệu ứng Dunning-Kruger . Nó là cực kỳ phổ biến trong số các lập trình viên mới bắt đầu, và trên thực tế, người mới bắt đầu trong nhiều lĩnh vực.

Hầu hết các mã nguồn trên các trang web, được xem bởi google chrome có vẻ rất lộn xộn và không có tổ chức

Có phải những người đã viết những trang web đó muốn bạn có thể hiểu chúng? Chắc là không. Đó là lợi ích của họ để có mã là khó hiểu.

nó chỉ khiến tôi tự hỏi làm thế nào người ta có thể học được nhiều như vậy.

Bởi chuyên . Tôi là một chuyên gia trong một lĩnh vực cực kỳ hẹp: thiết kế và triển khai các máy phân tích ngữ nghĩa của trình biên dịch C #. Nếu tôi đã dành mười lăm năm để nghiên cứu OpenGL hoặc XML hoặc HTML hoặc bất cứ điều gì, tôi sẽ là một chuyên gia về điều đó và bị phân tích bởi các máy phân tích ngữ nghĩa. Nhưng tôi đã không làm, và do đó tôi chỉ có hiểu biết rất cơ bản về OpenGL, XML và HTML.

Câu hỏi, một cách ngắn gọn, là nếu những điều này trở nên rõ ràng hơn đối với một lập trình viên khi anh ta tiến bộ trong sự nghiệp.

Vâng, bởi vì bạn bắt đầu thấy các mẫu lớn hơn. Lấy OpenGL làm ví dụ. Bạn có thể đã thấy một loạt các "thư viện API" - những đoạn mã lớn có liên quan trong đó cách bạn giao tiếp với mã bằng cách gọi một loạt các hàm được đặt tên với các đối số cụ thể. Và bạn có thể có được sự hiểu biết cơ bản về OpenGL chỉ từ việc hiểu rằng đó là một API.

Khi bạn đã có thêm kinh nghiệm và thấy một loạt các kỹ thuật lập trình khác nhau, bạn sẽ nhận ra rằng các công nghệ dường như không liên quan - giả sử, OpenGL và LINQ trong C # - có những điểm tương đồng. Cả hai đều là các API nơi bạn xây dựng các luồng công việc mà dữ liệu xung quanh và bạn có thể chạy các trình tối ưu hóa và chuyển đổi khác trên quy trình công việc theo những cách thú vị và phong phú. Khi bạn có khái niệm đó trong hộp công cụ của mình, đột nhiên việc khai thác toàn bộ sức mạnh của bất kỳ API nào sử dụng mẫu đó sẽ trở nên dễ dàng hơn nhiều.

Các chủ đề phức tạp như những chủ đề được liệt kê ở trên (OpenGL, MySQL, các trang html nâng cao) trở nên dễ đọc, viết và hiểu hơn khi bạn tìm hiểu thêm hay nó chỉ trở nên phức tạp hơn khi bạn đi qua?

Chúng trở nên dễ dàng và phức tạp hơn. Dễ dàng hơn bởi vì, như tôi đã nói, bạn bắt đầu nhận ra các kiểu suy nghĩ lớn hơn theo thiết kế của hệ thống, cho phép bạn sử dụng hệ thống hiệu quả hơn. Phức tạp hơn vì bây giờ bạn có thể sử dụng hệ thống để giải quyết các vấn đề phức tạp hơn , và sau đó bạn bắt đầu gặp phải những hạn chế của hệ thống.

Làm thế nào bạn có thể chống lại cảm giác rằng bạn là một con kiến ​​trong thế giới lập trình và công cụ này là bàn chân sắp đè bẹp bạn?

Bạn là một con kiến; chúng ta đều là kiến. Nhưng những thứ không phải là bàn chân đè bẹp bạn; đó là thế giới mà bạn có thể khám phá, sống, hưởng lợi và cải thiện. Bạn, kiến, chỉ được khám phá một phần nhỏ xíu của nó. Chọn một phần bạn thích nơi bạn có thể thêm giá trị thực và trở thành một chuyên gia trong đó.


2
Cảm ơn rất nhiều vì câu trả lời này, nó vượt trên những câu hỏi còn lại bởi vì nó không chỉ trả lời câu hỏi chính của tôi, mà còn mở mắt tôi về những điều nhất định. +1
Bugster

@Eric: Bạn sẽ nói gì với một người trong loại chủ đề này, nơi anh ta nói "chuyên môn hóa là dành cho côn trùng chứ không phải con người"?
Joan Venge

@JoanVenge Có ai nói vậy không? Thông thường mọi người đều chuyên về và là duy nhất, và nhiều hơn nữa nếu họ cảm thấy cần phải phân biệt với động vật (hoặc côn trùng).
Matthew đọc

1
bạn hiểu sai về Hiệu ứng Dunning-Kruger, nó được định nghĩa là sự bất lực của người không có kỹ năng nhận ra sự bất lực của chính họ và đánh giá chính xác khả năng của họ . Nếu bạn không thể nhận ra bạn không biết mọi thứ bạn không bao giờ có thể học được bất cứ điều gì mới. Nếu bạn có thể nhận ra nó, nó không phải là DKE.

+1 cho Chọn một phần bạn thích nơi bạn có thể thêm giá trị thực và trở thành chuyên gia trong đó.
Akshay Khot

14

Câu trả lời ngắn gọn, Có.

Cho thời gian và tiếp xúc những điều này trở nên dễ hiểu hơn.

Hãy nhớ rằng khi bạn đang xem các trang web từ các công cụ dev trong trình duyệt của bạn, chúng thường được tạo bởi một khung. Hãy để đó là bất kỳ số lượng nào ... ASP.NET, JSP, RoR, Django, ... ai biết được. Một số khung này tạo mã sạch hơn các khung khác.

Khi kết thúc ... tiếp xúc dẫn đến sự thành thạo. Không có cách nào để dập tắt cảm giác đó. Chỉ cần trải nghiệm và học hỏi. Phải mất thời gian để di chuyển, có được kiến ​​thức về miền và học các kỹ năng mà môi trường của bạn sử dụng.


1
Có một số sự thật cho điều này miễn là người viết mã đã sử dụng các thực tiễn tốt và các thành ngữ thông thường của cả ngôn ngữ nói riêng và các lập trình viên nói chung. Mã hóa xấu và / hoặc obfuscation có chủ ý có thể làm chậm bạn trở lại để thu thập dữ liệu. Hãy thử ghé qua CodeGolf.SE . Ngay cả các phiên bản "rõ ràng" cũng có thể gây khó khăn vì các thông lệ tốt đã bị hy sinh khi anh ta thay đổi chỉ số của cuộc thi.
dmckee

@dmckee Ngay cả mã xấu cũng trở nên dễ đọc hơn rất nhiều với kinh nghiệm. Tôi nhận thấy điều này đặc biệt trong C ++ (và tôi đã phải đọc rất nhiều mã xấu). Tất nhiên đó là một trở ngại cực lớn nhưng nó vẫn trở nên dễ dàng hơn nhiều khi bạn bắt đầu phát hiện ra các mẫu thiết kế xấu và các lỗi phổ biến. Chúng cũng tạo thành một loại thành ngữ mà bạn sẽ học.
Konrad Rudolph

2

Tôi đồng ý với một số câu trả lời đã được đưa ra nhưng tôi nghĩ chúng cũng là một điểm cơ bản không được thảo luận về việc đọc mã. Khi tôi lần đầu tiên bắt đầu nhìn vào một số mã nguồn mở, nó có vẻ quá lớn và to lớn. Nhưng đoán xem? nó sẽ luôn luôn rất lớn Tại một số điểm bạn nhận ra rằng bạn trở nên tốt hơn trong việc trích xuất những gì bạn đặc biệt muốn biết và tiếp tục.

Tuy nhiên, một ví dụ bạn đã đưa ra là xem xét một loạt mã HTML:

Tại sao bạn nhìn vào mã HTML? Có lẽ không phải vì bạn muốn tìm hiểu HTML của toàn bộ trang web. Có lẽ có một mẹo cụ thể mà bạn đang hy vọng nhặt được. Trong trường hợp đó, chỉ cần tìm HTML có liên quan với một công cụ như fireorms.

Nếu bạn thực sự muốn tìm hiểu làm thế nào toàn bộ trang web được tạo ra, bạn nhận ra HTML được kết xuất không phải là cách để làm điều đó. Bạn sẽ tốt hơn nếu nhìn vào một dự án nguồn mở sử dụng công nghệ tương tự. Tuy nhiên, cố gắng học toàn bộ mã của dự án không đáng giá như âm thanh. Thật nhàm chán, tốn thời gian, dễ quên những gì bạn đã học và cuối cùng bạn không có gì để thể hiện. Bạn sẽ học được ít hơn từ việc đọc mã của người khác vô tận và nhiều hơn nữa bằng cách sử dụng các phần cụ thể, thú vị của nó để viết plugin, bổ sung tính năng hoặc làm giàn giáo và lời khuyên cho các dự án của riêng bạn.

Cố gắng học tối thiểu tuyệt đối để có được một cái gì đó làm việc của riêng bạn. Chỉ quay lại điểm tham chiếu của bạn khi bạn gặp khó khăn hoặc muốn tìm hiểu một điều mới cụ thể. Điều này đi ngược lại với một số sự khôn ngoan thông thường rằng bạn phải hiểu mọi thứ nếu không bạn đang lập trình trong bóng tối. Nhưng cuối cùng bạn nhận ra rằng mục tiêu là không thể và bạn học cách cân bằng các mục tiêu để biết mọi thứ và mục tiêu thực sự hoàn thành những gì bạn đang làm.


2

Câu trả lời ngắn gọn là CÓ nhưng rất nhiều câu hỏi phụ thuộc vào cách bạn xác định kinh nghiệm.

Tôi nghĩ có ít nhất 3 phần để phát triển. Khi bạn trở nên tốt hơn ở mỗi phân khúc, một số điều sẽ trở nên rõ ràng hơn.

  1. Hiểu các yêu cầu KINH DOANH . Điều này cung cấp cho bạn cái nhìn tốt hơn về ứng dụng. Bạn càng có thể hiểu rõ hơn tại sao các quy tắc kinh doanh là những gì chúng là, bạn càng nhanh chóng nhận ra lý do tại sao một số điều được thực hiện theo một cách nhất định. Ví dụ: Khách hàng của bạn cần tuân thủ quy định X của chính phủ, đó là lý do tại sao họ cần chuẩn bị tài liệu Y, đó là lý do tại sao họ cần thông tin dường như vô dụng này được lưu trữ.

  2. Hiểu các yêu cầu KỸ THUẬT . Điều này giống như # 1 ngoại trừ việc hiểu thêm về lý do tại sao ở cấp độ kỹ thuật. Một số công cụ và công nghệ có những đặc điểm riêng, cho đến khi bạn xử lý chúng trước khi khó hiểu tại sao mọi việc được thực hiện theo một cách nhất định. Điều này là rõ ràng hơn khi bạn đối phó với các hệ thống di sản. Ví dụ: Ứng dụng sử dụng một bus dịch vụ cụ thể chỉ lấy XML.

  3. Hiểu các yêu cầu NGÔN NGỮ . Giống như những người khác đã đề cập, bạn càng có nhiều kinh nghiệm với một ngôn ngữ, bạn càng có thể đọc nhanh những gì mà lập trình viên gốc đang cố gắng đạt được. Tuy nhiên, nếu không có # 1 và # 2, bạn sẽ thấy rằng khả năng tăng lên này đạt đến đỉnh điểm khá nhanh.

Cố gắng tham gia vào nhiều khía cạnh của sự phát triển bởi vì nó thực sự không trở nên dễ dàng hơn cho đến khi bạn đã thực hiện tất cả các lĩnh vực ít nhất một vài lần.

Hãy nhớ rằng sự hoàn hảo (và mục đích) trong mã của người khác luôn liên quan đến # 1 và # 2. Đây là các trình điều khiển chính về lý do tại sao mã ở trạng thái. Nó thay đổi thường xuyên trong hai lĩnh vực đó là lý do lớn nhất khiến chúng tôi nhận được mã spaghetti mọi lúc. Vì vậy, trừ khi bạn thành thạo trong việc đọc các yêu cầu kinh doanh và kỹ thuật, nhiệm vụ đọc mã sẽ luôn là một PITA hoàng gia.


2

Nó trở nên dễ dàng và phức tạp hơn cùng một lúc!

Biết người khác là khôn ngoan;
Biết tự ngã là giác ngộ.
Làm chủ người khác đòi hỏi phải có lực lượng;
Làm chủ bản thân đòi hỏi sức mạnh;
Ai biết mình có đủ thì giàu.
Sự kiên trì là một dấu hiệu của sức mạnh ý chí.
Người ở lại nơi anh ta chịu đựng.
Chết nhưng không diệt vong là hiện diện vĩnh cửu.

dịch sang Phát triển phần mềm

Biết nhiều công nghệ là sự khôn ngoan. (Mọi thứ bắt nguồn từ ALGOL)
Biết những gì bạn không biết là sự giác ngộ. (LISP)
Nắm vững nhiều ngôn ngữ, khung và nền tảng đòi hỏi nhiều nỗ lực. (Java)
Chỉ làm chủ những gì bạn cần biết và chỉ điều đó đòi hỏi sức mạnh. (và Google hoặc stackoverflow.com)
Biết khi nào nên ngừng mã hóa và phân phối thứ gì đó là khi bạn biết đủ tốt. (Không phân tích tê liệt hoặc mạ vàng)
Tiếp tục làm việc với những gì bạn đang cố gắng để đạt được, nó đòi hỏi sự tập trung và sức mạnh ý chí. (Mọi thứ liên tục thay đổi, bạn không bao giờ kết thúc)
Gắn bó với một hoặc hai công nghệ và bạn sẽ chịu đựng. (COBOL vẫn thanh toán tốt, cũng như C)
Từ bỏ lập trình và chuyển sang quản lý là phải có mặt vĩnh viễn. (hoặc để lại một phần mềm FOSS mà mọi người sẽ tiếp tục sử dụng tốt sau khi bạn chết).


Vì vậy, thay vì là một con kiến, bạn nên là một con gián và chỉ đứng dậy khi nó đè bẹp bạn, phải không? :-P
Bugster

"Paralysis phân tích"! = "Biết khi nào nên ngừng mã hóa". Đó là "biết khi nào bắt đầu mã hóa".
Ben Voigt

0

Câu hỏi, một cách ngắn gọn, là nếu những điều này trở nên rõ ràng hơn đối với một lập trình viên khi anh ta tiến bộ trong sự nghiệp. Các chủ đề phức tạp như những chủ đề được liệt kê ở trên (OpenGL, MySQL, các trang html nâng cao) trở nên dễ đọc, viết và hiểu hơn khi bạn tìm hiểu thêm hay nó chỉ trở nên phức tạp hơn khi bạn đi qua? Làm thế nào bạn có thể chống lại cảm giác rằng bạn là một con kiến ​​trong thế giới lập trình và công cụ này là bàn chân sắp đè bẹp bạn?

Tôi sẽ thực hiện một chiến thuật hơi khác so với những người được hỏi khác; Tôi tin rằng việc đọc và viết mã trên thực tế trở nên dễ dàng hơn khi bạn làm điều đó nhiều hơn và tôi sẽ chứng minh điều đó bằng một sự tương tự đơn giản.

Hãy nghĩ về khi bạn mới bắt đầu chơi thể thao. Lúc mới bắt đầu với môn thể thao đầu tiên bạn học, phối hợp cơ bản cho các nhiệm vụ đơn giản của một môn thể thao có lẽ thực sự khó khăn. Khi bạn có nhiều kinh nghiệm hơn, bạn bắt đầu thành thạo các nhiệm vụ đơn giản để không phải suy nghĩ về chúng nữa và bạn nhận thấy rằng có những nhiệm vụ phức tạp hơn mà bạn có thể chú ý (như xem người chơi khác dự đoán hành vi của họ).

Sau đó, khi bạn thử sức mình ở một môn thể thao khác, có lẽ bạn đã thấy mình không bị bỏ lại quá xa khi bạn bắt đầu. Bắt bóng rổ khác nhiều so với bắt bóng chày, nhưng ai đó thành thạo một trong số họ sẽ có thời gian dễ dàng hơn để nhặt người khác so với người chưa từng làm trước đây. Với kinh nghiệm luyện tập môn thể thao thứ hai, bạn phát hiện ra rằng môn thể thao đầu tiên mang đến cho bạn cả những kỹ năng cụ thểchung chung . Các kỹ năng cụ thể (bắt bóng rổ) chỉ hữu ích trong miền của họ, nhưng các kỹ năng chung (theo dõi một đối tượng chuyển động nhanh tiếp cận trong không gian ba chiều và phát triển kế hoạch đối phó với nó) giúp bạn trở nên tốt hơn trong tất cả các lĩnh vực liên quan.


Điều này có liên quan gì đến lập trình? Dòng mã đầu tiên bạn đọc đưa bạn đến một thế giới được xây dựng theo các quy tắc nhất định. Bạn đã học các quy tắc đó (cú pháp và thành ngữ của ngôn ngữ đó) như các kỹ năng cụ thể, nhưng bạn cũng đã học được một số kỹ năng chung có giá trị: hiểu cách máy tính vận hành nội bộ và cách thể hiện ý định của bạn theo cách mà máy tính có thể hiểu. Mỗi ngôn ngữ mới bạn học cung cấp cho bạn một số kỹ năng cụ thể mới, nhưng nó cũng củng cố các kỹ năng chung của bạn và giúp bạn thấy các mẫu được bắn qua tất cả các ngôn ngữ máy tính như mỏ khoáng sản nằm dọc theo một bức tường hẻm núi. Khi bạn đã thực sự quen thuộc với một vài ngôn ngữ khác nhau, bạn bắt đầu có thể nhận ra "hình dạng" của hầu hết mọi mã, nếu bạn tha thứ cho sự mơ hồ, ngay cả khi bạn không biết gì về ngôn ngữ được viết bằng ngôn ngữ đó.

Chẳng hạn, cả ba ngôn ngữ bạn đã đề cập (MYSQL, OpenGL, C ++) đều có một số tính năng phổ biến:

  • Có thể tính riêng các phần nhỏ của thuật toán và kết hợp chúng thành một giải pháp hoàn chỉnh sau này
  • Máy tính thường yêu cầu một số lượng chuẩn bị chung trước khi bạn có thể bắt đầu làm việc với vấn đề cụ thể của mình (tạo bảng, khởi tạo canvas hoặc có thể tải các thư viện chung)
  • Các câu lệnh trước được ưu tiên và ảnh hưởng đến các câu lệnh sau, tức là máy tính khởi động ở đầu mã và hoạt động theo cách của nó

Bạn càng lập trình nhiều, bạn sẽ càng nhận ra rằng dù quả bóng có hình dạng như thế nào, nó vẫn chỉ là một quả bóng tiến về phía bạn, và bạn biết phải làm gì với nó mà không phải suy nghĩ quá nhiều về nó. Tất cả các chương trình là về việc cố gắng thể hiện ý định của bạn theo cách mà máy tính có thể hiểu được; học đủ và bạn sẽ bắt đầu có thể đọc được ý định thay vì mã.

Tái bút- Mỗi lần, khi cuối cùng bạn bắt đầu cảm thấy như bạn biết đường đi, bạn sẽ gặp phải điều gì đó hoàn toàn phá vỡ não bộ của bạn và khiến bạn cảm thấy như một người mới bắt đầu xếp hạng. Đó là những gì chúng tôi yêu thích về công việc này, luôn có những điều mới mẻ để học hỏi.


0

Trả lời ngắn gọn: , nói chung

Tuy nhiên, bạn sẽ không trở thành một chuyên gia nếu bạn khái quát. Trở thành một chuyên gia cũng có nghĩa là nhận ra tất cả những điều bạn không biết: đây có thể là một cảm giác quá sức.

Khi bạn di chuyển qua thời gian, bạn có được kinh nghiệm.

Khi bạn di chuyển theo thời gian, các ngôn ngữ / mẫu khác, vv đang phát triển song song với sự phát triển của bạn.

Một biến khác cho câu hỏi của bạn, là nếu bạn đang có được kinh nghiệm có ý nghĩa liên quan đến ngành công nghiệp vì nó cũng di chuyển trong cùng một thời gian liên tục. Ngành công nghiệp công nghệ là một mục tiêu di chuyển và không giống như hầu hết các ngành công nghiệp khác.

Một câu hỏi hay cũng có thể là, bạn tự trải mình quá mỏng hoặc quá dày trên một ngôn ngữ nhất định.


0

Đó là một nguồn tự hỏi không bao giờ kết thúc (và lo lắng) có bao nhiêu ngôn ngữ máy tính và mức độ chúng tiếp tục thay đổi. Thêm vào đó, số lượng các khung khác nhau trong mỗi ngôn ngữ và cho mỗi khung, rất nhiều thư viện và trình cắm có sẵn. Thêm vào đó là số lượng các trình soạn thảo mã và IDE.

Tất cả các biến thể này có hai chiều phức tạp.

  1. Từ vựng và cú pháp của họ là khác nhau.
  2. Các khái niệm trừu tượng (khái niệm cấp cao) mà họ hỗ trợ là khác nhau.

Họ cũng có một điểm chung. Turing hoàn chỉnh. Với đủ nỗ lực từ phía một lập trình viên, tất cả họ có thể được sử dụng để giải quyết tất cả các vấn đề! Vì vậy, nếu bạn bắt đầu với một ngôn ngữ như C (vocab nhỏ, cú pháp phức tạp và hầu như không trừu tượng), bạn chắc chắn có được cảm giác bạn có thể làm bất cứ điều gì (hoàn toàn đúng).

Sau đó chuyển sang "công cụ dễ dàng" như CSS, HTML, Javascript và có thể cả các khung như Bootstrap và React, và bộ não của bạn sẽ rán - như của Albert Einstein. Mọi người nghĩ rằng "Tôi biết tiếng Pháp, vì vậy học tiếng Đức nên dễ dàng". Không!

Nhiều tóm tắt lập trình có thể được học từ các mẫu phần mềm . Có một số cuốn sách dành riêng cho chủ đề này. Các mô hình ở khắp mọi nơi, là ngôn ngữ bất khả tri và có thể được học và hiểu một lần . Nếu bạn biết các mẫu của mình, bạn có thể sử dụng chúng trong bất kỳ ngôn ngữ nào và nhận ra chúng khi được tích hợp vào các ngôn ngữ và thường xuyên hơn vào các khung khác nhau.

Hầu hết mọi người phải mất 1-2 năm để thành thạo một ngôn ngữ mới và nhà tuyển dụng biết điều đó. Đó là lý do tại sao họ không thuê những người không có kinh nghiệm về ngôn ngữ của họ, bởi vì nhân viên mới sẽ dành nhiều thời gian để vật lộn với ngôn ngữ và không đủ thời gian thực sự giải quyết các vấn đề kinh doanh.

Tóm lại, các nguyên tắc / trừu tượng của khoa học máy tính, các mẫu phần mềm và loại vấn đề kinh doanh bạn gặp, tất cả đều thay đổi từ từ. Bạn có thể học một lần và tích lũy kiến ​​thức mới tăng dần. Ngược lại, ngôn ngữ máy tính, khung, được gọi là "hệ sinh thái" và thư viện thành phần thay đổi rất nhanh cũng như tất cả các công cụ bao quanh chúng. Ở đây mong đợi tốc độ học tập sẽ chậm và tốn thời gian!


-1

Các chủ đề phức tạp như những chủ đề được liệt kê ở trên (OpenGL, MySQL, các trang html nâng cao) trở nên dễ đọc, viết và hiểu hơn khi bạn tìm hiểu thêm hay nó chỉ trở nên phức tạp hơn khi bạn đi qua? Làm thế nào bạn có thể chống lại cảm giác rằng bạn là một con kiến ​​trong thế giới lập trình và công cụ này là bàn chân sắp đè bẹp bạn?

Khi bất kỳ tiến bộ nào được thực hiện, chúng tôi không học và học lại những gì chúng tôi nghĩ rằng chúng tôi biết trước đây. - Henry David Thoreau

Có một câu chuyện về thiền sư và Teacup tràn .

Đôi khi, chúng ta cần buông bỏ những quan niệm và ý kiến ​​định sẵn từ quá khứ để có thể cho phép bản thân tìm hiểu các khái niệm mới.

Hãy nhớ rằng: Nếu bạn đang cảm thấy choáng ngợp trước một khái niệm mới, bạn cần tìm kiếm nhiều giáo viên.

Gần đây, khi được giao nhiệm vụ cập nhật một số phần mềm nội bộ của công ty sử dụng ngôn ngữ kịch bản mà tôi không quen thuộc. Ban đầu nó rất căng thẳng. Tuy nhiên, sau khi tôi thay đổi thái độ, tôi bắt đầu tìm tài nguyên giải thích cú pháp và các khái niệm cơ bản. Tôi đã hoàn thành dự án và bây giờ sử dụng ngôn ngữ kịch bản này như một trong những công cụ của tôi để hoàn thành nhiều việc hơn.

Thái độ của bạn làm cho tất cả sự khác biệt.

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.