Là sự phong phú của các khung làm giảm bớt các lập trình viên? [đóng cửa]

Với tất cả các khung có sẵn hiện nay, ORM , tiêm phụ thuộc (DI), Đảo ngược điều khiển (IoC), v.v., tôi thấy rằng nhiều lập trình viên đang mất hoặc không có kỹ năng giải quyết vấn đề cần thiết để giải quyết các vấn đề khó khăn. Nhiều lần, tôi đã thấy hành vi bất ngờ len lỏi vào các ứng dụng và các nhà phát triển không thể thực sự tìm hiểu và tìm ra các vấn đề. Dường như với tôi rằng sự hiểu biết sâu sắc về những gì đang diễn ra dưới mui xe đang bị mất.

Đừng hiểu sai ý tôi , tôi không cho rằng các khung này không tốt và không thúc đẩy ngành công nghiệp tiến lên, chỉ hỏi rằng, do hậu quả không lường trước, các nhà phát triển không đạt được kiến ​​thức và kỹ năng cần thiết để hiểu sâu về hệ thống.

Đã đồng ý. Tôi hiện đang làm việc trên một gói phần mềm bị vướng mắc bởi các khung công tác khiến nó gần như không thể hiểu được doanh nghiệp. Khi các khung công tác loại bỏ bạn khỏi việc giải quyết các vấn đề kinh doanh thực sự thay vì chỉ giải quyết MVC , nó đã đi quá xa. Như bạn nói, IMO, nhiều lập trình viên cố gắng và kiến ​​trúc sư / chương trình để giải quyết ORM và MVC, và họ hiếm khi hỏi liệu điều đó có thực sự giúp giải quyết vấn đề mà phần mềm có ở nơi đầu tiên không.

Vâng, tôi biết việc nhìn thấy một số SQL thô trong trang JSP là "không-không", nhưng nếu bạn là một nhà tư vấn lĩnh vực, thì điều này phù hợp với một giải pháp cụ thể ở đâu? Và không, điều đó không có nghĩa là khung không đúng, không phải tất cả khách hàng đều có 20 nghìn đô la ngồi mỗi lượt để đảm bảo rằng một điểm dữ liệu nhỏ được chiếu trên trang.

Đây là một đối số xuất hiện thường xuyên, trong nhiều lĩnh vực và dưới nhiều hình thức.

Hình thức chung của lập luận này là:

Có [x: công cụ / công nghệ] làm cho mọi người tồi tệ hơn tại [y: chức năng bị ảnh hưởng bởi x] không?

Ví dụ:

• Phần mềm CAD có làm cho các kỹ sư tồi hơn không?
• Làm máy tính ở trường trung học làm cho học sinh kém môn toán?
• Phần mềm xã hội có đóng thế các kỹ năng xã hội trực tiếp của mọi người không?
• Có phải phần mềm kế toán sản xuất kế toán tồi hơn?

Từ bộ nhớ, câu trả lời phổ biến hầu như luôn luôn là: không thực sự. Bạn sẽ luôn có những người giỏi và kém khi làm [y] nhưng bây giờ họ chỉ kém ở một khía cạnh khác của kỹ năng.

Một sự hiểu biết sâu sắc hơn về các nguyên tắc cơ bản với bất kỳ công việc nào sẽ giúp ích, bất kể bạn làm gì - ngay cả những công việc được coi là "khắc phục". Kiến thức luôn giúp ích.

Trừu tượng là một khái niệm quan trọng của lập trình máy tính và khung giúp các lập trình viên đạt được điều này. Đây là một điều tốt. Tôi nghi ngờ nhiều người chúng tôi muốn phát triển các hệ thống phức tạp trong ngôn ngữ lắp ráp! Vấn đề xuất hiện, tôi nghĩ, khi các lập trình viên có ít ý tưởng về lớp trừu tượng đang che giấu. Nói cách khác, bạn cần có một số ý tưởng về những gì diễn ra dưới mui xe, ngay cả khi bạn không trực tiếp tương tác hoặc giao diện với nó.

Tôi nhớ đã phát triển một số trang web động đầu tiên vào giữa những năm 90, sử dụng C và CGI (tại thời điểm phần lớn các trang web vẫn là HTML tĩnh). Thực sự không có bất kỳ ngôn ngữ kịch bản phía máy chủ trưởng thành nào (như PHP hoặc ASP) và rất ít thư viện, do đó bạn phải viết toàn bộ luồng phản hồi HTTP đến máy chủ với mỗi trang. Phân tích các tham số GET và POST yêu cầu viết thư viện của riêng bạn. Đó là tẻ nhạt, chậm, chăm chỉ và rất dễ bị lỗi. Tôi không bỏ lỡ nó một chút!

Tuy nhiên, tôi cũng cảm thấy các khung như các mẫu web ASP.NET trừu tượng toàn bộ bản chất phi trạng thái của web đến mức nhiều nhà phát triển web mới có chút manh mối về những gì thực sự đang diễn ra. Điều này dẫn đến mã không hiệu quả, cồng kềnh hoạt động kém vì nhà phát triển đang kết nối các thành phần bằng cách sử dụng phương pháp "drag'n'drop" mà không nhận ra điều gì đang xảy ra ở cấp HTTP.

Vì vậy, tôi tin rằng các khung công tác rất cần thiết để phát triển phần mềm cấp cao, nhưng chúng không loại bỏ các nhà phát triển có hiểu biết về những gì đang bị trừu tượng hóa. Vâng, khuôn khổ có thể làm bạn chết lặng, nhưng chỉ khi bạn không hiểu chúng.

Liệu hộp số tự động hoặc cần gạt nước cảm biến mưa làm cho chúng ta lái xe tồi tệ hơn?

Tôi không nghĩ mã hóa mà không có khung nhất thiết có nghĩa là hiểu rõ hơn về các hệ thống cơ bản. Điều này được chứng minh bằng việc các nhà tuyển dụng phải hỏi các câu hỏi mã hóa đơn giản tại các cuộc phỏng vấn chỉ để đảm bảo ứng viên có thể kết hợp một phương pháp mạch lạc với nhau.

Cuối cùng, tùy thuộc vào nhà phát triển để tìm hiểu. Người tốt làm, người xấu thì không.

Và trong một mạch tương tự, chọn một khung chỉ vì nó ở đó mà không thực sự phân tích khả năng và ưu / nhược điểm của nó cũng là một dấu hiệu của thực tiễn phát triển kém.

Tôi nghĩ vấn đề là các lập trình viên mới đang bắt đầu ở mức độ trừu tượng ngày càng cao hơn, và do đó không được tiếp xúc với các bit và byte của mọi thứ 'dưới mui xe'. Vì vậy, họ không học một số nguyên tắc cơ bản về mã hóa thực sự sẽ là điều đầu tiên học được trong nhiều năm qua.

Tôi lắc đầu mỗi lần ở đây khi một lập trình viên rõ ràng mới đang hỏi điều gì đó về việc lưu trữ một số dữ liệu và mọi người lập tức bảo họ sử dụng công cụ ORM . Không, không, không, không, không ... họ cần học cách tự làm trước.

Có lẽ sự phân phối của "sự ngu ngốc" đã không thực sự thay đổi, và thay vào đó chúng ta chỉ đơn giản là đưa ra những cách thức lớn hơn và phức tạp hơn cho các nhà phát triển để tự bắn vào chân mình?

Đó không phải là các khung làm giảm bớt các lập trình viên. Lập trình viên câm sẽ câm dù họ có sử dụng khung hay không.

Chắc chắn rằng việc hiểu công việc cấp thấp mà một công cụ hoặc khung giúp bạn hợp lý hóa giúp bạn trở thành người sử dụng tốt hơn các công cụ và khung. Bạn cũng có thể gỡ lỗi các vấn đề dễ dàng hơn và khắc phục các lỗ hổng không thể tránh khỏi của các công cụ.

Ví dụ, tôi đã tham gia một lớp học về Thiết kế trình biên dịch ở trường đại học, nơi chúng tôi đã mã hóa trình phân tích cú pháp LR từ đầu trong C, trước khi học cách sử dụng các trình tạo trình phân tích cú pháp như lex và yacc. Nó rất giáo dục, và kể từ đó tôi đã hiểu và đánh giá cao hơn cho tất cả các ngôn ngữ lập trình tôi đã sử dụng.

Nhưng tôi không nói rằng mọi lập trình viên đều được yêu cầu phải tẩy lông chiếc xe của ông Miyagi trong nhiều năm và nhiều năm trước khi họ có thể được phép làm việc ở cấp độ cao. Rất nhiều công việc lập trình là trí tuệ, quyết định những gì phần mềm cần làm , không phải là công việc cơ học của mã hóa trong một ngôn ngữ hoặc công cụ cụ thể.

Công việc trí tuệ đó ​​là nơi mà sự thông minh so với sự ngu ngốc thậm chí còn quan trọng hơn.

Trích dẫn từ "Chi tiêu cổ tức của Moore" xuất sắc (nhấn mạnh thêm):

Ba mươi năm trước, Bill Gates đã thay đổi lời nhắc trong Altair Basic từ bản S READN SÀNG thành chữ OK OK để tiết kiệm 5 byte bộ nhớ. Ngày nay, không thể tin được rằng các nhà phát triển sẽ nhận thức được mức độ chi tiết này của chương trình của họ, chứ đừng nói đến nó, và đúng như vậy, vì sự thay đổi của cường độ này ngày nay không thể nhận thấy ... Không có cách nào chúng ta có thể tạo ra các hệ thống ngày nay sử dụng các nghệ nhân, thực hành thủ công có thể (cần thiết) trên các máy có bộ nhớ 4K.

Tôi nghĩ có lẽ sai lầm khi nói rằng các khung cho phép bạn tránh các kỹ năng cần thiết để giải quyết các vấn đề khó khăn hoặc để bạn tránh hiểu biết sâu sắc. Thay vào đó, lý do duy nhất chúng ta có thể xây dựng các hệ thống phức tạp ngày nay (sự phức tạp có thể tạo ra các vấn đề khó khăn và thách thức sự hiểu biết sâu sắc) là vì chúng ta có các khung (và các ngôn ngữ thu thập rác OO cấp cao và các IDE có trợ giúp theo ngữ cảnh và kiểm tra cú pháp nhanh chóng và tất cả các tiến bộ phát triển phần mềm khác đôi khi bị chỉ trích là làm giảm bớt các lập trình viên).

Khung là tuyệt vời. Nhưng bạn phải biết những gì dưới mui xe. Vì vậy, vấn đề là các lập trình viên phụ thuộc quá nhiều vào các khung công tác, mà không có đủ kiến ​​thức về hệ thống cơ bản.

Một ví dụ hơi lỗi thời là MFC : một lập trình viên có thể tiết kiệm rất nhiều thời gian bằng cách sử dụng MFC thay vì API Windows, nhưng không có kiến ​​thức về API (có nghĩa là có nền tảng công việc thực sự với API thô), họ thường sẽ bị mắc kẹt . Nó gần như không bao giờ xảy ra, bởi vì một lập trình viên MFC điển hình có kiến ​​thức API Windows.

Tuy nhiên, với Windows Forms trên .NET , nhờ đóng gói tốt hơn và mô hình đối tượng tốt hơn, một lập trình viên gần như có thể bỏ qua rằng anh ta đang sử dụng chỉ một trình bao bọc API Windows khác. Vì vậy, có ít cơ hội bị mắc kẹt, nhưng khi nó xảy ra, nó có thể bị tổn thương.

Thật không may, thời gian để thị trường luôn ngắn hơn và các dự án ngày càng phức tạp, vì vậy các lập trình viên không có thời gian để đi sâu. Đó là trạng thái đáng buồn của ngành công nghiệp phần mềm ...

Nó đặt thông minh nơi cần thiết. Người ta không cần phải hiểu cơ học lượng tử và vật lý Newton để thiết lập một cơ chế thả quả bóng từ đỉnh tòa nhà. Mỗi lớp mới trong phần mềm sẽ được xây dựng sau cùng và loại bỏ bản tóm tắt khỏi việc xây dựng các ứng dụng hữu ích.

Những người cần hoặc muốn biết "công cụ" đằng sau khuôn khổ sẽ nghiên cứu và điều tra bằng cách móc hoặc kẻ gian.

Không, hoàn toàn không. Các khung, ở cốt lõi của chúng, là sự kết hợp của một thư viện chương trình con và một khuôn mẫu, hai công cụ lập trình thử và đúng. 'Đây là một công nhân nghèo đổ lỗi cho các công cụ của mình ...

... và có rất nhiều công nhân nghèo sử dụng và đổ lỗi cho các khung công tác.

Khi xây dựng phần mềm, khung tiết kiệm thời gian. Khi học cách xây dựng phần mềm, các khung có được theo cách hiểu.

Tôi nghĩ vấn đề chủ yếu là một trong những máy tính đã trở nên quá mạnh. Đối với hầu hết các lập trình viên, không còn lý do hợp lý nào nữa để "đi xuống những điều cơ bản". Nó chỉ mất nhiều thời gian hơn để làm những thứ tương tự, và trong thời gian chạy không có sự khác biệt có ý nghĩa. Cách duy nhất để giải quyết đó là giới thiệu các hạn chế nhân tạo, cách các cuộc thi như js1k làm.

Có lẽ các trường nên có một chủ đề chuyên dụng "thiết kế tối ưu hóa" nơi bạn phải xây dựng các chương trình dưới những hạn chế về không gian và thời gian mạnh mẽ?

Không, học các khung cải thiện các kỹ năng của một lập trình viên. Framework là phần mở rộng của ngôn ngữ lập trình. Một số ngôn ngữ đã dựa trên khung. Tôi làm việc với cả PHP và Java. PHP cần một khung như công cụ mẫu (đôi khi). Java không cần một khung công tác (hầu hết các lần), nó đã có nhiều phương thức và thư viện.

Hầu hết các Framework sẽ có các chức năng mà các lập trình viên sử dụng nhiều lần.

Dường như đóng vai người ủng hộ ma quỷ ở đây, tôi nghĩ rằng các khung (dù sao cũng tốt) thực sự có thể đi một chặng đường dài hướng tới việc tiếp tục giáo dục lập trình viên. Một khung công tác được thiết kế tốt sẽ giải quyết được rất nhiều vấn đề và bằng cách sử dụng khung, lập trình viên có thể hiểu được vấn đề nào đang được giải quyết và làm thế nào. Trong tâm trí của tôi, một khung là (/ nên là) một sự kết tinh của các thực tiễn tốt nhất về lập trình và có thể dạy một lập trình viên bằng ví dụ.