Các kỹ sư phần mềm có thực sự cần biết những thứ cấp thấp nữa không? [đóng cửa]

Khi các ngôn ngữ lập trình cấp cao như C #, Java, v.v. đang phát triển, nhiều người cho rằng chúng sẽ thay thế cho các ngôn ngữ như ngôn ngữ hợp ngữ và C / C ++, cho phép bạn truy cập và kiểm soát phần cứng máy tính, vì các lập trình viên nên tập trung về việc tạo chương trình và giải quyết vấn đề, không lãng phí thời gian xử lý máy tính để làm cho nó hoạt động. Khi phần cứng tiếp tục được cải thiện, sự khác biệt về hiệu năng giữa C / C ++ và Java sẽ không đáng kể và các trò chơi lớn có thể được lập trình bằng một ngôn ngữ như Java.

Đó là ý tưởng chung tôi tóm tắt ngắn gọn sau khi xem chủ đề này trên Internet. Bạn có nghĩ rằng nó sẽ trở thành hiện thực trong tương lai gần? Điều đó có nghĩa là mọi thứ chúng ta học về công cụ cấp thấp không còn thiết thực cho ngành công nghiệp phần mềm nữa? Điều đó có nghĩa là, ngôn ngữ lắp ráp và C / C ++ sẽ chỉ liên quan đến các kỹ sư điện, vì họ sẽ là những người duy nhất cần lập trình cho các thành phần điện của họ?

---

Học bao nhiêu là đủ? Nếu chúng ta học quá nhiều thứ cấp thấp, cuối cùng chúng ta sẽ trở nên định hướng hơn trong kỹ thuật điện hoặc nếu chúng ta học quá nhiều toán, chúng ta có thể học để trở thành nhà toán học chứ không phải lập trình viên. Tôi chỉ muốn biết liệu những thứ Toán học tôi đã học (tôi đã tham gia một khóa học Toán bao gồm các tài liệu tương tự như cuốn sách này (họ đã sử dụng sách giáo khoa khác nhau): Toán học rời rạc và ứng dụng của nó) thực sự hữu ích như bộ kỹ năng lập trình của chúng tôi. Nhiều bài tập toán có thể mất hầu hết thời gian của chúng tôi để làm điều đó và nếu bạn nghiêm túc với nó, bạn sẽ có ít thời gian hơn để học lập trình. Trong diễn đàn gamedev của chúng tôi, ngay cả Toán và Vật lý cũng chỉ có một phần để so sánh với phần lập trình.

Ngay bây giờ tôi mới bắt đầu đọc "Nghệ thuật lập trình máy tính". Toán học chỉ được đề cập trong khoảng một phần tư của cuốn sách, nhưng bài tập này rất khó đối với những người không phải là nhà toán học. Ngay cả toán học "cơ bản" như vậy, chúng ta có sử dụng nó nhiều như vậy trong sự nghiệp không? Một số người có thể bảo tôi đọc cuốn sách TACOP là một sự lãng phí thời gian và có lẽ nên dành thời gian cho những thứ khác thực tế hơn, mặc dù cuốn sách chỉ nói về lập trình (một chút hàn lâm so với cuốn sách giải thích những điều tương tự). Nhưng tôi nghĩ rằng tác giả đã dành thời gian và nỗ lực lớn để sản xuất nó. Anh ấy thậm chí có thể viết trọn bộ 5 cuốn sách, trong khi chúng tôi - khán giả - chỉ có nhiệm vụ đọc nó. Tại sao không?

Câu hỏi thú vị. Tôi là một lập trình viên C ++ lâu năm, hiện đang làm việc trong C # (với một chút C ++ không được quản lý cho công việc quan trọng về hiệu năng), và trong lịch sử đã phải thêm một chút mã lắp ráp, thường là vì lý do hiệu năng.

Một vài điểm trong việc chuẩn bị trả lời cho câu hỏi:

• Để so sánh với bạn, tôi đề nghị rằng sự khác biệt chính giữa các ngôn ngữ bạn đề cập, C # và Java, từ tập hợp khác, hội, C / C ++ là trước đây sử dụng thời gian chạy được quản lý để cung cấp bộ sưu tập rác. Có những khác biệt khác (ví dụ tính di động nhị phân, kích thước khung và tính di động), nhưng khi bạn xem xét so sánh sự khác biệt về hiệu suất, đây là một đóng góp chính (?).

• Hội, C và C ++ khác xa so với "cấp thấp". Tôi nghĩ rằng bạn đã đúng khi kết hợp các ngôn ngữ hội và C với các nhà phát triển phần cứng / phần sụn / trình điều khiển, nhưng C ++ thường được sử dụng ở tầng cao hơn và vẫn còn được sử dụng nhiều - mặc dù rõ ràng C # / Java đang loại bỏ nó theo TIOBE mục lục.

• Trong lớp C ++, tôi sẽ thêm Objective-C, vì nó gần giống với C ++ hơn C # / Java. Cuối cùng, tôi lưu ý rằng với việc bổ sung shared_ptr <> và các tính năng quản lý tài nguyên tự động khác, các ngôn ngữ này có hỗ trợ cho một cái gì đó gần với bộ sưu tập rác.

OK - với câu hỏi chính của bạn: Các kỹ sư phần mềm có thực sự cần biết những thứ cấp thấp nữa không?

Câu trả lời của tôi: Có

Lý do:

• Ngay cả khi sử dụng C # / Java, bạn có thể sẽ chạy vào các thực thể khung yêu cầu quản lý tài nguyên rõ ràng và / hoặc gặp phải các vấn đề về đồ thị bộ nhớ "được ghim" trên bất kỳ ứng dụng không tầm thường nào. Bạn cần hiểu làm thế nào các hệ thống này hoạt động để tránh và gỡ lỗi một cách hiệu quả những vấn đề này.
• Các nền tảng di động có nguồn lực hạn chế hơn và mặc dù có hỗ trợ cho các phiên bản Java và .NET hạn chế trên một số, nhưng sự thống trị hiện tại của iOS và Objective-C cho thấy sự đổi mới lâu dài đối với nó.
• Hiệu suất: bất cứ khi nào bạn chạm vào một bức tường hiệu suất, bạn có thể sẽ cần phải rơi vào một đoạn mã được biên dịch nguyên bản để đi xung quanh nó.
• Hỗ trợ kế thừa: bất cứ khi nào bạn cần can thiệp để có quyền truy cập vào một tính năng chưa được hiển thị (chưa) trong mã được quản lý, bạn sẽ cần phải làm như vậy.

Câu hỏi hay - nhưng tôi không thấy các ngôn ngữ không được quản lý sẽ biến mất trong thời gian tới.

• Rằng ai đó hợp pháp sẽ không tìm hiểu và không hiểu chức năng cấp thấp hơn, và vẫn là một nhà phát triển rất năng suất và có giá trị, đã là trường hợp như vậy.
• Rằng không ai sẽ cần phải học hoặc hiểu chức năng cấp thấp hơn, rằng nó sẽ luôn lãng phí thời gian, sẽ không bao giờ là trường hợp.

Như trong bất kỳ ngành kỹ thuật nào, có nhiều bước để sản phẩm cuối cùng, tất cả đều quan trọng, chuyên môn về nhu cầu và có giá trị. Trong công nghệ phần mềm nói riêng, chúng ta có nhiều lớp trừu tượng. Tất cả đều cần thiết, và không ai có thể là một chuyên gia về tất cả chúng.

Điều đó đang được nói, chúng tôi cần nhiều nhà phát triển C # / Java / Ruby hơn so với các nhà phát triển Assemby / C. Đối với chúng tôi, các nhà phát triển "cấp cao hơn", hiểu thêm về những gì xảy ra "dưới mui xe" là hữu ích và sẽ giúp chúng tôi phát triển tốt hơn. Nhưng nhiều thứ khác cũng vậy . Là một nhà phát triển .NET, ví dụ, có rất nhiều thứ tôi có thể học sẽ giúp tôi làm việc hiệu quả hơn, đó là việc học Ngôn ngữ Trung cấp của chúng tôi (ít C ++ / C / Assmebly), mặc dù rất hữu ích, thường phải ngồi ở ghế sau.

Bạn có thể kiếm sống ngay hôm nay với tư cách là một lập trình viên mà không cần biết những thứ cấp thấp. Tôi nghĩ rằng nó chỉ làm cho bạn một lập trình viên tốt hơn để biết nó.

Tuy nhiên, việc duy trì mức độ năng lực cao với các công cụ cấp thấp đang ngày càng trở nên ít quan trọng hơn. Ý tôi là, tôi đã không làm bất cứ điều gì trong quá trình lắp ráp trong 20 năm và có lẽ sẽ cần phải bồi dưỡng nghiêm túc trước khi tôi có thể làm việc hiệu quả trở lại, nhưng những khái niệm chung về cách mọi thứ hoạt động ở cấp độ đó vẫn là một phần trong ý thức của tôi và tôi thấy nó hữu ích theo thời gian ngay cả khi làm việc trong các ngôn ngữ cấp cao hơn.

Tôi không nghĩ vậy, các nhà phát triển kernel sẽ luôn cần những thứ cấp thấp. Cũng không hại gì khi hiểu mọi thứ hoạt động như thế nào, nếu về cơ bản bạn hiểu mã bạn đang viết thực sự đang làm gì, bạn sẽ học cách viết mã tốt hơn. Tôi nghĩ rằng loại bỏ các công cụ cấp thấp là một ý tưởng khủng khiếp vì suy nghĩ trừu tượng này đôi khi hữu ích nhưng thực sự có thể là một trở ngại nếu bạn muốn giải quyết vấn đề theo cách tốt nhất. Ví dụ, để hiểu rằng khi bạn nối các chuỗi, bạn thực sự đang tạo các chuỗi mới rất quan trọng nhưng nếu bạn không hiểu cách các chuỗi được triển khai, bạn có thể chỉ cần nối lại và đợi 5 phút để chương trình của bạn chạy. Đây là một bài viết tuyệt vời về những thứ như thế này: http://www.joelonsoftware.com/articles/fog0000000319.html

Điều này phụ thuộc vào những gì kỹ sư phần mềm đang thực sự làm việc. Bây giờ có thể có một sự nghiệp hiệu quả, hạnh phúc và có lợi nhuận mà không bao giờ chạm vào bất cứ điều gì cấp thấp, nhưng đó không phải là tất cả các công việc lập trình. Để có hệ điều hành và trình biên dịch, phải có các kỹ sư làm việc trên các hệ điều hành và trình biên dịch, và họ sẽ cần biết C, C ++ và ngôn ngữ lắp ráp máy của họ.

Hiệu suất cũng có thể quan trọng. Máy tính xách tay hiện tại của tôi mạnh hơn khoảng một triệu lần so với máy tính gia đình đầu tiên của tôi và phần mềm chạy vẫn có thể mất thời gian. Tôi vẫn có thể bị lag trong các trò chơi video. Tất nhiên, các trò chơi video trông đẹp hơn, bởi vì mỗi hơn một triệu pixel trên màn hình có thể được cung cấp một trong hàng triệu màu (trái ngược với một nghìn vị trí ký tự đen trắng, với một số ký tự được sử dụng cho đồ họa ). Tôi nghi ngờ chúng ta sẽ tăng thêm một nghìn lần sức mạnh máy tính trong tương lai gần, và nếu chúng ta hy vọng nó sẽ được sử dụng bởi phần mềm ngày càng phức tạp.

Mặc dù phần lớn phần mềm kinh doanh sẽ tiếp tục được viết bằng những gì nhanh nhất được sản xuất và ra khỏi cửa, thường không phải là C, nhưng sẽ tiếp tục có nhiều chỗ cho các chuyên gia C và C ++.

"Với phần cứng tiếp tục được cải thiện, hiệu suất giữa C / C ++ và Java sẽ không đáng kể và trò chơi lớn có thể được lập trình bằng ngôn ngữ như Java."

Tôi không tin rằng tuyên bố đó sẽ chính xác bất cứ lúc nào. Luôn có một điểm nhấn trong mã được quản lý vì các kiểm tra được thực hiện phía sau hiện trường. Đây cũng không phải là vấn đề về phần cứng tốt hơn, vì phần cứng trở nên tốt hơn nên các ứng dụng được mong đợi sẽ chạy trên chúng. Một hệ thống được viết bằng mã gốc phải có giao diện với mã được quản lý. Có một hit hiệu suất xảy ra khi chuyển đổi giữa hai.

Tuy nhiên, chỉ có một tỷ lệ nhỏ các ứng dụng thực sự cần mã được tối ưu hóa này. Hầu hết các dòng ứng dụng kinh doanh đều ổn với bất kỳ mã được quản lý, .net, java, v.v. Điều đó không có nghĩa là mặc dù các ứng dụng cần nó sẽ sớm chuyển đổi bất kỳ lúc nào. Tuy nhiên, lắp ráp bằng tay hiện nay ít được sử dụng hơn với trình biên dịch C / C ++ tối ưu hóa rất tốt. Gần đây có một hệ điều hành được viết hoàn toàn bằng cách lắp ráp, vì vậy vẫn còn một số hệ điều hành. Nó cũng khá quan trọng trong lĩnh vực bảo mật.

Mặc dù vậy, tôi muốn nói rằng, để trở thành một nhà phát triển thực sự giỏi, người ta nên hiểu những gì đang diễn ra ở mức độ thấp. Nó giúp khắc phục một số vấn đề khó khăn, đặc biệt là khi gọi vào mã gốc.

Tôi nghĩ rằng việc biết một số công cụ cấp thấp rất hữu ích cho việc gỡ lỗi, ví dụ như với lập trình nhúng, hầu hết được thực hiện với C, tuy nhiên khi gỡ lỗi biết lắp ráp cho bộ điều khiển Micro cụ thể đó là cực kỳ hữu ích.

Khi máy tính lần đầu tiên được phát minh, chỉ có một vài người biết cách sử dụng chúng. Bây giờ, hầu hết mọi nhà ở một quốc gia giàu có đều có từ 1 máy tính trở lên mà người bình thường có thể sử dụng được. Nhiều người bình thường có công việc làm việc trên máy tính hàng ngày. Người bình thường có khả năng sử dụng máy tính, nhưng chúng ta vẫn cần lập trình viên.

Tương tự, lập trình viên trung bình không cần biết hoặc thường xuyên lập trình bằng ngôn ngữ hợp ngữ. Đây chỉ là một điều kiện của các kỹ năng thị trường vì nó là một lời chào cho đến nay chúng ta đã đi được bao xa trong thế giới công nghệ. Doanh nghiệp cần máy tính để tự động hóa các nhiệm vụ. Do đó, các lập trình viên có thể lập trình bằng .NET / Java đang có nhu cầu rất lớn.

Các nhiệm vụ có thể được tự động hóa, sẽ được tự động. Không phải tất cả các nhiệm vụ có thể được tự động. Không phải tất cả tự động hóa là hoàn hảo. Vì vậy, lắp ráp có quan trọng? Tất nhiên. Có bắt buộc phải là một "lập trình viên". Tất nhiên là không.

Hmmm tôi thực sự thích học những thứ cấp thấp.

Có lẽ nó không phải là simile chính xác nhất, nhưng với tôi nó giống như học các âm mưu trong xe hơi. Tôi có thể không biết làm thế nào tất cả các mảnh hoạt động với nhau, nhưng thật vui khi biết rằng có một động cơ, trục khuỷu, xi lanh, vi sai, cần cẩu, phanh, dầu, đốt, làm lạnh, và sau đó ma sát, căng thẳng, nhiệt, lực, khoa học nhiệt động lực học, vật lý, cơ học chất lỏng ...

Có lẽ không hữu ích lắm (tôi sẽ không thể sửa xe bằng cách biết tất cả những điều này), chắc chắn không thực tế về mặt chuyên môn, nhưng, tốt, vui. L'art pour l'art: la Connaashing pour la Connaurg.

Tôi nghĩ rằng một quy tắc hữu ích là - nó cần phải nhanh hơn, mức độ thấp hơn bạn cần có.

Vì vậy, game bắn súng góc nhìn người thứ nhất chuyên sâu hoặc hệ thống giao dịch FX thuật toán của bạn, chúng vẫn ở mức khá thấp (C ++, v.v.) vì tốc độ là chìa khóa. Nhưng ứng dụng web nào đưa ra báo cáo bán hàng đúng hạn? Quỷ thần, bạn có thể viết điều đó trong Sinclair BASIC, và nó vẫn được chấp nhận.

Không phải tất cả các công việc kỹ thuật phần mềm đều giống nhau . Những người làm việc trên các hệ điều hành, trình biên dịch, khung, trình điều khiển thiết bị, hệ thống nhúng và máy tính khoa học hiệu năng cao rất cần phải biết 'công cụ cấp thấp'. Những người viết biểu mẫu Access CRUD hoặc giỏ mua hàng PHP cho các cửa hàng Mom và Pop, có thể không quá nhiều. Bạn muốn làm loại kỹ thuật phần mềm nào và bạn có muốn làm phần còn lại của cuộc đời không?

Ý kiến ​​của tôi là bạn cần học ít nhất một mức độ trừu tượng dưới mức bạn thường làm việc. Nếu bạn làm việc trong C / C ++ thì bạn nên chọn một số kiến ​​trúc và lắp ráp máy. Nếu bạn làm việc trong PHP thì bạn nên hiểu HTTP và một chút C / C ++ hoặc Perl. Nếu Access là bánh mì và bơ của bạn thì tốt hơn bạn nên biết một số lý thuyết RDB và có thể một chút về COM hoặc .Net. Đôi khi trong sự nghiệp của bạn, cuối cùng bạn sẽ bị chặn đứng trong các bài hát của mình bởi một vấn đề ở mức độ trừu tượng thấp hơn, và bạn sẽ cần có thể giao tiếp ít nhất một chút với ai đó là chuyên gia trong lĩnh vực đó. Bạn có thể 'nhận được' mà không có công cụ này? Chắc chắn, nhưng lập kế hoạch chỉ "có được" trong một thị trường việc làm cạnh tranh là nguy hiểm.

Bản thân tôi làm việc rộng rãi trong C # .NET và luôn tránh xa C, C ++. Gần đây bắt đầu tìm việc và rất ngạc nhiên khi thấy có bao nhiêu công việc có sẵn và yêu cầu kinh nghiệm cho C, C ++. Tôi ban đầu mặc dù C, C ++ đã trở nên lỗi thời nhưng nhìn vào các công việc có sẵn, có vẻ như đó không phải là trường hợp.

Tất cả các ngôn ngữ được quản lý mà bạn liệt kê đều có trình thông dịch hoặc máy ảo được viết bằng C / C ++. Với hai thứ đó, hầu hết các ngôn ngữ được quản lý hoặc giải thích thậm chí sẽ không tồn tại. Tôi sẽ nói rằng bạn đánh giá thấp giá trị của họ.

Tôi thực sự ghét khái niệm về một kiến thức "thực tế" . Tất cả mọi thứ bạn từng học là thực tế như nhau. Không có vấn đề gì nếu bạn sẽ không hoạt động ở mức độ trừu tượng gần với phần cứng, chỉ cần biết các khái niệm từ miền đó luôn có lợi cho việc xây dựng kiến ​​thức mới ở mức độ trừu tượng khác. Càng nhiều khái niệm liên quan bạn biết, càng tốt.

Đối với những gì tôi thường làm, C # là một ngôn ngữ cấp thấp và tôi coi nó như một thứ gì đó rất gần với phần cứng. Nhưng tôi vẫn tin rằng ngay cả kiến ​​thức thô sơ, thô sơ của tôi về điện tử kỹ thuật số, thiết kế CPU, v.v., cũng rất hữu ích cho mọi thứ tôi từng làm.

Không có đa số không cần. Mặc dù thực hành các kỹ thuật cấp thấp giúp nhà phát triển hiểu biết tốt hơn về những gì có thể ảnh hưởng đến toàn bộ chu kỳ, nhưng ngày nay, nhà phát triển có thể sử dụng thời gian đó để nghiên cứu các công nghệ mới hơn, do đó cần có kiến ​​thức về các công cụ cấp thấp để phát triển nhưng không được dựa vào trên.

Theo quan điểm của tôi, khi bạn sử dụng một từ "Kỹ sư", bạn có nghĩa là người đàn ông / phụ nữ là người thiết kế và xây dựng mọi thứ từ đầu. Vấn đề thực sự của Kỹ sư phần mềm là giải quyết vấn đề, nhưng vấn đề gì? Đó là một câu hỏi lớn.

Nhà phát triển khác với Kỹ sư theo nhiều cách. "Nhà phát triển" là người thường xây dựng mọi thứ trên các nền tảng đã có sẵn. Anh ta phát triển các nền tảng hiện có hoặc xây dựng các nền tảng mới kế thừa từ những nền tảng cũ hơn chắc chắn sử dụng thành phần của hệ thống mẹ.

Một nhà phát triển thường nghĩ từ góc độ kinh doanh, anh ta không phải là Nhà khoa học. :) Nhà phát triển gần gũi hơn với người dùng hệ thống, họ nghĩ mọi thứ từ góc độ người dùng và do đó cuối cùng giải quyết vấn đề của người dùng bằng công nghệ.

Một kỹ sư một thông minh. Anh ấy là một nhà khoa học, anh ấy giải quyết một vấn đề rất chân thật. Hầu hết các vấn đề, mà chính máy tính có nó là một tính năng .. Người dùng chúng tôi không bao giờ gần gũi với vấn đề đó, nó được gói gọn. Các kỹ sư là những người bỏ lại nghiên cứu của họ sau khi nghiên cứu rất nhiều về hệ thống hiện có và đưa ra một cái gì đó mới để giải quyết vấn đề, nếu cần giải pháp, nếu hệ thống của họ cần ngôn ngữ mới, họ phát minh ra ngôn ngữ mới vì hệ thống hiện tại không có khả năng giải quyết vấn đề đó .. Các kỹ sư đã kết thúc việc xây dựng một hệ thống mà Nhà phát triển xây dựng hệ thống của họ.

Thật vậy, một Kỹ sư phần mềm cần phải học và thành thạo các công cụ cấp thấp ... :)

Trong khi một Nhà phát triển, điều đó hoàn toàn phụ thuộc vào sở thích của anh ta. :)