Một nửa tất cả những gì bạn biết sẽ bị lỗi thời sau 18-24 tháng. = (Đúng hay Sai?) [Đã đóng]

Chỉ cần chạy qua điều này, và tự hỏi nếu có ai có cách để chứng minh hoặc từ chối tuyên bố này:

Một cái gì đó để ghi nhớ ... những gì nửa đời của kiến ​​thức trong công nghệ cao? Nó theo dõi theo Định luật Moore: một nửa mọi thứ bạn biết sẽ bị lỗi thời sau 18-24 tháng.

NGUỒN: Trong câu trả lời của Craig Trader cho câu hỏi này " Điều duy nhất hiệu quả nhất bạn đã làm để cải thiện kỹ năng lập trình của mình là gì? "

Tuyên bố này chỉ áp dụng cho các công nghệ phù du, mà bạn chỉ nên học khi cần thiết. Điều đó nói rằng, bạn sẽ học được rất nhiều trong số họ trong sự nghiệp của bạn.

Nguyên tắc và kỹ thuật lập trình cơ bản là vĩnh cửu.

Vô lý

Những người nói những điều như thế chỉ đang cố gắng trở thành người theo chủ nghĩa giật gân, nếu không họ đang học những điều sai trái.

Bài kiểm tra tốt nhất (tệ nhất?) Mà tôi có thể nghĩ đến là chỉ nghĩ lại một năm. Bao nhiêu kiến ​​thức lập trình bạn sử dụng mỗi ngày đã được học trong 18 - 24 tháng trước? Hơn nữa, bao nhiêu đã được phát minh trong 18-24 tháng trước? Nguyên tắc này có vẻ rất đáng ngờ đối với tôi, vì phần lớn kiến ​​thức lập trình và kỹ thuật tôi sử dụng hàng ngày đã có được sau 5-10 năm.

Bây giờ nếu bạn đang phát triển cho một thứ gì đó như một nền tảng điện thoại di động, có lẽ đó là một trò chơi bóng khác.

Theo kinh nghiệm của tôi, có một sự mất kết nối lớn giữa hình ảnh truyền thông / công cộng về công nghệ mới là Điều mới và những gì thực sự được sử dụng trong thế giới thực ngoài kia.

Lấy một cái gì đó như Visual C ++ / MFC trong không gian ứng dụng máy tính để bàn. Mặc dù nó có vẻ cũ và lỗi thời, và có lẽ không phải là thứ mà một lập trình viên mới nên học ngay bây giờ để phát triển máy tính để bàn, nhưng vẫn còn rất nhiều dự án và công việc trong thế giới thực được viết trong đó đang được duy trì - và có lẽ sẽ được duy trì trong nhiều năm và nhiều thập kỷ tới. Tôi sẽ lấy ví dụ về COBOL, nhưng về mặt lý thuyết thì có thể nói - tôi thực sự biết rất rõ về ví dụ VC ++ / MFC.

Về cơ bản, không phải công nghệ trở nên vô dụng và không được sử dụng khi chúng trở nên "lỗi thời", mà chúng không còn được coi là cách làm việc cập nhật nhất và bắt đầu các dự án mới. Nhưng việc ngừng hoạt động của các hệ thống phần mềm lớn trong thế giới thực không bị hỏng và không cần sửa chữa xảy ra chậm hơn nhiều. Nhiều dự án Visual C ++ / MFC mà tôi đã làm (bắt đầu từ đầu những năm 1990) vẫn còn rất nhiều và sử dụng nhiều lập trình viên (cả trong bảo trì và phát triển mới), và dường như không đi đến đâu bất cứ lúc nào sớm Trên thực tế, tôi chắc chắn rằng hầu hết những người tôi nghĩ sẽ vẫn còn khoảng năm 2020 và lâu hơn nữa.

Tất nhiên, đây thậm chí không phải là vấn đề chính. Vấn đề chính là rất nhiều khái niệm tương tự hoặc liên quan và bạn không "bắt đầu từ đầu" khi tìm hiểu một số công nghệ mới. Ví dụ: một khi bạn hiểu các ngôn ngữ đánh dấu và những gì chúng nói về, việc học những ngôn ngữ mới rất dễ dàng. Vì vậy, JSON không phải là vấn đề mới và tất cả những gì bạn đã sử dụng trong nhiều năm là XML. Đó chỉ là vấn đề học cú pháp mới - trái ngược với việc một số người không phải là lập trình viên không biết gì về ngôn ngữ đánh dấu là gì, hoặc các khái niệm nội bộ đằng sau dữ liệu mà họ đại diện, v.v.

TL; DR: 1) Có rất nhiều công nghệ "lỗi thời" được sử dụng ngoài kia, nhưng vì nó không phải là thứ mới gợi cảm, bạn không nghe về nó nhiều - nhưng nó không có giá trị đối với những người làm việc với nó . 2) Các khái niệm lập trình xây dựng chồng lên nhau và phát triển. Vài điều thực sự là thứ bạn phải học hoàn toàn từ đầu và quên đi cái cũ.

Tất cả phụ thuộc vào những gì bạn tập trung vào việc học, ghi nhớ và nói chung là lấp đầy bộ não của bạn. Chi tiết có thể trở nên lỗi thời một cách nhanh chóng, nhưng các nguyên tắc sẽ tồn tại lâu hơn nhiều.

Ví dụ từ những điều tôi đã tham gia sâu sắc gần đây:

• Cú pháp chung của Java so với các thùng chứa được gõ
• Kiểu dữ liệu MySQL, giới hạn lưu trữ, v.v. so với nguyên tắc khả năng mở rộng cơ sở dữ liệu
• Lớp trừu tượng cơ sở dữ liệu nhẹ Tôi đã giúp tạo so với các nguyên tắc độ cứng / tính linh hoạt của cơ sở dữ liệu

Những điều tôi học được in đậm sẽ tồn tại lâu hơn nhiều so với những thứ ở phía bên trái. Nếu bạn muốn tránh những cạm bẫy của sự lạc hậu trong lập trình, hãy tập trung vào các nguyên tắc .

Robert Harvey đóng đinh cái này , nhưng sau khi nghĩ về nó, tôi buộc phải ném gió và trả lời.

Tôi phải thêm từ chối trách nhiệm, tôi đã không đào sâu vào Perl On Rails ngay khi nó được công bố. Tôi có cảm giác rằng nó hoạt động tốt cho việc sử dụng rất cục bộ mà nó được thiết kế và ghi chú về nó để tham khảo trong tương lai.

Tôi cũng không chịu thua hơn 50 hoán vị cho thư viện C tiêu chuẩn trong suốt hai thập kỷ qua, tôi ước tôi có thể liên kết với họ, nhưng dường như họ đang bị thách thức.

Chèn một câu nói dài ở đây về việc tin tất cả những gì bạn đọc hoặc nghe.

Khi một cái gì đó mới xuất hiện, lấy nó và có một cái nhìn. Nếu bạn nói 'ick', hãy bỏ nó đi. Nếu bạn nói 'wow', hãy cải thiện nó. Nếu bạn không thể suy nghĩ về một quyết định như vậy, hãy chọn bộ não của những người có thể.

Đánh giá tất cả mọi thứ về công đức một mình . Đáng giá thời gian của bạn có nghĩa là nó giúp bạn tiết kiệm thời gian trong khi nhận được sự ủng hộ từ phần lớn các đồng nghiệp của bạn.

Bây giờ, tôi sẽ giải quyết câu hỏi của bạn trực tiếp:

Một nửa tất cả những gì bạn biết sẽ bị lỗi thời sau 18 - 24 tháng, đúng hay sai?

Bạn sẽ phải cho chúng tôi biết sau 18 - 24 tháng. Các công ty trả một khoản tiền đáng kể để khiến mọi người nói về sản phẩm của họ tuyệt vời như thế nào. Chúng tôi phải lội qua không chỉ các công ty mới thành lập mà còn thành lập những người khổng lồ bỏ ra số tiền đáng kể để:

• Có [sic] các blogger được kính trọng lấy lại doanh số cho độc giả của họ
• Gửi thiết bị miễn phí có thương hiệu đắt tiền để có được vị trí thương hiệu nơi có thể nhận thấy thông qua khoe khoang hoặc sử dụng
• Trả tiền cho mọi người để đảm bảo bạn thấy một 'giải pháp hoạt động' trong top 10 của Google khi nghiên cứu vấn đề
• Trả tiền cho 'giải thưởng' từ các trang web 'mười thư mục hàng đầu' và giả vờ những người có thẩm quyền
• Rất nhiều phương tiện thực sự để thuyết phục mọi người ngừng suy nghĩ và chỉ đi theo đám đông

Tất nhiên, bạn có thể hình thành quyết định của riêng mình dựa trên kinh nghiệm trước đây và thử nghiệm của bạn với một cái gì đó mới. Trong khi làm điều đó, các nhà tuyển dụng eschew có những người quản lý đưa ra các điều răn dựa trên trình đọc RSS của họ.

Tôi có, tuy nhiên có thư viện xây dựng cây cầu mới tuyệt vời này đủ thông minh để chuyển đổi giữa Brooklyn và London dựa trên địa phương của bạn. Nó sẽ rất lớn, bạn có muốn vào tầng trệt không?

Câu trả lời của tôi thực sự là cố ý mỉa mai và có lẽ là chống boolean, nhưng thực sự? Đối với mục đích xử lý ngoại lệ, câu trả lời của tôi là một sai lầm vang dội .

Nếu bạn nghĩ rằng một cái gì đó là âm thanh kỹ thuật - hãy nắm lấy nó, nếu không thì đó là kinh doanh như bình thường. C là ngôn ngữ chính của tôi, nó hoạt động tốt như cách đây gần hai thập kỷ, trong khi tôi được trả tiền gấp đôi cũng như tôi đã làm gần hai thập kỷ trước.

Tôi ngưỡng mộ hình thức và trích dẫn ngắn gọn của bạn, nhưng điều này dường như là một thử nghiệm vi phạm .

Làm tốt :)

Nó phụ thuộc vào những gì bạn dành thời gian học tập. Tôi đã học lập trình Bourne shell và C vào năm 1980. Tôi vẫn sử dụng nó mỗi ngày. Mặt khác, thời gian tôi dành cho việc học các cấu trúc menu Compuserve là một sự mất mát hoàn toàn và nó thực sự không hữu ích lắm ngay cả vào thời điểm đó. Sau đó, giữa những thứ như pin-out cáp RS-232 và các giao thức nối tiếp: vô dụng ngày nay, nhưng cần thiết cho khoảng mười năm của cuộc đời tôi. Chọn các công nghệ bạn dành nhiều thời gian để cẩn thận.

Nguyên tắc là đúng. Giá trị thực tế là - theo hiểu biết của tôi - lớn hơn nhiều.

Tôi nhớ lại một bài thuyết trình Lập trình viên thực dụng nơi họ nói khoảng bảy năm, nhưng tôi không thể xác định vị trí của nó bây giờ, vì vậy giá trị có thể hơi khác nhau.

Chỉ cần nghĩ công nghệ đã thay đổi như thế nào: Mười lăm năm trước web là hoàn toàn mới và tất cả chúng ta đã cố gắng viết các trang web - có lẽ ngay cả với các bảng - và một gif hoạt hình. Bảy năm trước, AJAX đã cất cánh. Ngày nay, một số người viết các trò chơi giống như Doom cho điện thoại di động.

Đặt cược tốt nhất của bạn là tìm hiểu những thứ chung có thể áp dụng với công nghệ tiếp theo thay vì nói "Bắt đầu! Tôi chỉ biết Visual Basic!" (hoặc tương đương trong 15 năm).

Tôi không nghĩ nó chính xác chút nào.

Nó đã từng gần với sự thật hơn - từ lâu, bạn có rất ít sự lựa chọn ngoài việc lập trình ở mức độ trừu tượng tương đối thấp, điều đó có nghĩa là biết một số lượng lớn các chi tiết không còn phù hợp trên nền tảng mới.

Tuy nhiên, theo thời gian, ngày càng có nhiều chương trình được thực hiện ở mức độ trừu tượng ngày càng cao. Một mức độ trừu tượng cao hơn chuyển trực tiếp ít nhiều đến ít quan tâm hơn với các chi tiết có khả năng thay đổi và trở nên lỗi thời một cách nhanh chóng.

Rõ ràng có những người làm việc trên những thứ như trình điều khiển thiết bị hoặc các hệ thống nhúng nhỏ vẫn phải làm việc ở mức độ trừu tượng thấp. Tuy nhiên, bên ngoài các khu vực như thế, có khá ít lý do cho những điều đó. Vâng, có rất nhiều người làm học hỏi được rất nhiều đố họ không bao giờ cần, nhưng nếu bạn đang thực sự sử dụng công cụ như vậy trong mã của bạn nhiều, rất có thể là khá tốt mà bạn chỉ cần không đưa ra quyết định rất tốt. Hầu hết những điều như vậy có thể (và quan trọng hơn, nên) thường được tránh.

Có thể đúng, có thể không; tuy nhiên, ngay cả khi những điều thực tế đã học trở nên lỗi thời ngay sau khi học chúng, các khái niệm và ý tưởng đằng sau chúng có thể được sử dụng lâu hơn nhiều.

Nếu đó là trường hợp chỉ 5,39x10 ^-6 của Tháng huyền thoại sẽ có liên quan ngày hôm nay. Vì có rất ít nguyên tắc chính mà Fred Brooks chi tiết đã có niên đại hoặc được chứng minh là sai về cơ bản.

Phần lớn kiến ​​thức của bạn sẽ có liên quan trong quá trình kiểm tra thời gian (mặc dù có thể cần một số cập nhật theo thời gian), các nguyên tắc cơ bản đặc biệt, chẳng hạn như cấu trúc dữ liệu, v.v.

Tất nhiên, nếu bạn biết ngôn ngữ lập trình X và Y, việc học ngôn ngữ Z sẽ dễ dàng hơn nếu bạn không biết X hoặc Y, vì vậy bạn có thể sử dụng kiến ​​thức trước đây của mình để điều chỉnh kiến ​​thức mới.

Điều đáng nói là nhiều kỹ năng có liên quan từ nhiều thập kỷ trước vẫn còn phù hợp cho đến ngày nay, ngay cả những công nghệ cụ thể, như C (đầu năm 1970, vẫn còn liên quan đến ngày nay).

Có thể một nửa những gì bạn biết sẽ bị lỗi thời trong một thời gian và có thể nhiều hơn chỉ một nửa, nhưng mỗi 18-24 tháng nghe có vẻ cực kỳ.

Sự thật duy nhất không có liên quan lớn. Bạn lấy chúng, hiểu chúng, áp dụng chúng cho hiện tại mà thôi.

Nhưng làm như vậy dạy cho bạn quá trình xử lý sự thật hoặc ít nhất là xử lý một tập hợp con nhất định của sự kiện. Tôi đã học được rất nhiều môn toán ở trường mà tôi thực sự không bao giờ sử dụng. Tôi vẫn học và rèn luyện tư duy toán học.

Tôi đã làm việc như một lập trình viên web với Ruby on Rails. Và trong khi tôi không viết các trang web vào lúc này, nó đã ảnh hưởng lớn đến mã bout suy nghĩ của tôi và khiến tôi trở thành một lập trình viên C ++ tốt hơn. (Sử dụng thêm STL chẳng hạn).

Tương tự như vậy đối với việc học vợt. Tôi chưa bao giờ viết bất kỳ chương trình lớn nào, nhưng nó cho tôi một quan điểm mới để áp dụng vào một số không gian vấn đề.

Nó chỉ là về việc rèn luyện tâm trí của bạn ...

Tôi nghĩ rằng bạn có thể dễ dàng từ chối tuyên bố bằng cách chơi xung quanh với đối tượng bạn trong 'một nửa của tất cả mọi thứ bạn biết'.

Có một số phân phối kiến ​​thức nhất định, một số trong đó sẽ trở nên lỗi thời (bất kể tỷ lệ.) Vì vậy, nếu một người nhất định chỉ chứa kiến ​​thức từ một nửa phổ này sẽ tồn tại sau 18-24 tháng, họ sẽ phá vỡ tuyên bố.

Đây là phiên bản tốt hơn của câu: một nửa của tất cả mọi thứ bạn đã học ngày hôm nay (hoặc tuần này hoặc tháng này hoặc năm nay) sẽ bị lỗi thời trong một hoặc hai năm. Điều đó đúng - bạn học cách làm một cái gì đó trong phiên bản 5 của một công cụ và khi 6 xuất hiện, nó sẽ tự động làm điều đó hoặc bạn học cách làm một thứ gì đó bằng ngôn ngữ không bắt kịp, vì vậy bạn không bao giờ sử dụng nó nữa. Nhưng nửa còn lại của những gì bạn học được mỗi ngày vẫn ở bên bạn, và phát triển, và là điều làm cho một nhà phát triển 20 năm kinh nghiệm tốt hơn một hai năm kinh nghiệm.

Có một chút sự thật hoặc sự liên quan ở đây nhưng tôi nghĩ nó được trình bày không chính xác.

Một cách tốt hơn để trình bày này sẽ là

Bao nhiêu kiến ​​thức bạn sử dụng ngày hôm nay bạn có 18-24 tháng trước?

hoặc là

Trong thời gian 18-24 tháng, bạn sẽ biết bao nhiêu kiến ​​thức mà bạn sẽ áp dụng? Bạn cần học bao nhiêu từ hôm nay để hoàn thành những nhiệm vụ đó?

Nó có thể phụ thuộc vào lĩnh vực bạn đang làm việc, nhưng tôi biết rằng tôi liên tục làm việc trên công nghệ mới. Mỗi dự án dường như có một khối lượng lớn các công cụ mới mà tôi cần tìm hiểu - khuôn khổ & mô hình mới, cách tiếp cận mới cho các vấn đề hơi khác nhau hoặc chỉ là các công cụ mới (được cho là!) Tốt hơn so với những gì chúng ta đã sử dụng trước đây.

Nếu mỗi dự án sáu tháng chỉ cần 12,5% kiến ​​thức mới, thì sau hai năm, toàn bộ 50% kiến ​​thức được sử dụng sẽ là 'mới'.

Phải nói rằng, điều này không có ý nghĩa hay chính xác.

• Những thứ 'cũ' không lỗi thời.
• Những thứ 'mới' có sự trùng lặp lớn với những thứ cũ
• Các nguyên tắc thường được chuyển nhượng

Chúa ơi, câu trả lời thông thường, tuyệt vời như vậy ở trên. Công việc tốt đẹp.

Nói một cách đơn giản, nếu đó là một mốt hay xu hướng hot, nếu bạn là một lập trình viên giỏi, bạn sẽ đọc về nó, sau đó quay lại với những gì bạn thường làm hoặc làm việc với.

Trừ khi có một cái gì đó quan trọng đối với những gì bạn làm, hoặc các thực hành mới có ý nghĩa đối với bạn.

Chỉ vì một cái gì đó mới, hơi mới hoặc hơi cũ, không làm cho nó trở thành giải pháp phải sử dụng cho bất cứ điều gì.

Tôi có một cụm từ đơn giản, đó là tất cả những điều này.

"Nếu nó hoạt động, sử dụng nó"

Điều đó có nghĩa là, nếu công nghệ mới này cực kỳ tuyệt vời, nhưng không phải bất cứ điều gì làm cho công việc của bạn hiệu quả hơn, chất lượng cao hơn hoặc ít bị lỗi hơn hoặc giải quyết các vấn đề kỹ thuật như giải pháp máy khách hoặc máy chủ. Tốt nhất là đọc nó, sau đó bỏ qua nó, cho đến khi bạn có một ứng dụng thực tế cho nó.

Tôi đã thấy và đọc nhiều người lãng phí thời gian, cố gắng tìm những thứ mới nóng hổi, ​​sau đó sử dụng những thứ mới nóng hổi. Mà thường kết thúc là một sự lãng phí hoàn toàn thời gian và tiền bạc.

Điều quan trọng là luôn luôn học hỏi, thực hành và cải thiện kỹ năng và kỹ năng của bạn.

Tuy nhiên, bạn nên tìm hiểu những gì hữu ích hoặc những gì mang lại cho bạn những quan điểm khác nhau để giải quyết các vấn đề bạn thường gặp phải.

Nhưng khác với điều đó, nên quay trở lại những điều cơ bản để trở thành một lập trình viên tuyệt vời.

1. http://www.joelonsoftware.com/articles/fog0000000043.html
2. Lập kế hoạch
3. Quy trình quản lý dự án - để đảm bảo không có mã nào được bắt đầu trước khi kế hoạch rõ ràng được thực hiện và được chấp thuận bởi những người yêu cầu bạn làm việc.
4. Cải thiện khả năng đọc mã của bạn - Bởi vì tất cả chúng ta đều làm việc với mã của người khác
5. Được tổ chức, hiệu quả

Tôi đang làm theo cách thông thường tốt nhất, rằng tất cả chúng ta đều học hỏi từ kinh nghiệm của mình. Không lãng phí thời gian vào những thứ chỉ là mát mẻ.

Bởi vì thành thật mà nói, mát mẻ chỉ là không mát mẻ.

Tôi đã nghe cụm từ này được quy cho các lĩnh vực kỹ thuật, không phải lập trình. Cụ thể hơn, tôi đã nghe nói, "Vào thời điểm bạn nhận được bằng Cử nhân Kỹ thuật, hai năm học đầu tiên của bạn sẽ dựa trên công nghệ cũ." (Hoặc một thứ gì đó hiệu quả.)

Tôi không nghĩ rằng nó áp dụng cho lập trình. Cách khả thi duy nhất tôi có thể thấy nó liên quan là khi các tính năng bị phản đối hoặc bị xóa khỏi ngôn ngữ lập trình / thư viện / bất cứ điều gì.

Nền tảng công nghệ trung bình tồn tại trong khoảng từ 10 đến 25 năm, vì vậy điều này dường như không thể xảy ra với tôi, ngay cả khi bạn hoàn toàn giảm giá thực tế rằng kiến ​​thức về các mẫu vẫn tồn tại thông qua các công nghệ. Nếu bạn đang ở trên bất kỳ loại nền tảng chính nào, bạn có thể tin tưởng rằng ngăn xếp đó trở nên phổ biến trong AT LEAST 5 hoặc 6 năm trước khi nó bắt đầu biến mất. Tôi biết các lập trình viên đã mã hóa trong RPG trong 30 năm bằng cách sử dụng các công cụ phần cứng và phần mềm gần như giống hệt nhau.