Là lập trình như một nghề trong một cuộc đua xuống đáy? [đóng cửa]

Dường như với tôi rằng ngành lập trình đang trong một cuộc đua xuống đáy. Nếu chúng ta thực hành:

1. Không dành thời gian để thực hiện các thực tiễn tốt nhất
2. Sử dụng mã người khác càng nhiều càng tốt (mã tùy chỉnh như một trách nhiệm pháp lý)
3. Sử dụng các ngôn ngữ ngày càng cao hơn để cải thiện năng suất
4. Các "công cụ" phát triển dựa trên GUI giúp đơn giản hóa rất nhiều "lập trình" và không yêu cầu mọi người hiểu hệ thống ống nước đằng sau mã

Những điều này ngụ ý với tôi rằng chúng ta đang trong một cuộc đua để trở nên giống như bất kỳ nhân viên văn phòng nào khác. Đó là lợi ích của người sử dụng lao động đối với những thứ không yêu cầu kỹ năng (dễ thay thế hơn), cho những thứ được xây dựng sẵn (thời gian dự án ít hơn).

Quan điểm của tôi ở đây là a) có sự sai lệch giữa kỹ năng và lợi ích kinh tế của người sử dụng lao động không? và b) nếu có, làm thế nào để bạn giảm thiểu nó để thực thi các tiêu chuẩn chuyên nghiệp?

Tôi nghĩ bạn đã hỏi một câu hỏi rất sâu sắc.

Tạo các công cụ mã hóa GUI khiến các lập trình viên mất việc cũng như các robot đưa các công nhân dây chuyền lắp ráp ra khỏi công việc. Theo tôi, trong khi mất việc làm, thì cũng có một sự thay đổi trong đó các công việc tiếp theo là.

Công nghệ để thực hiện một nhiệm vụ thay đổi, nhưng nhiệm vụ vẫn cần phải hoàn thành: Những chiếc xe vẫn cần được chế tạo / lắp ráp trước khi chúng có thể được lái; mã / logic nghiệp vụ vẫn cần phải được đặt cùng nhau để ứng dụng hoạt động.

Sự thay đổi trong lựa chọn công nghệ hiện tại cho các lập trình viên: Tìm hiểu các công cụ GUI lập trình hoặc lập trình dựa trên GUI ... hoặc ... một cái gì đó hoàn toàn khác.

Có thể có sự sai lệch giữa các kỹ năng của nhân viên và lợi ích của người sử dụng lao động, nhưng không lâu dài, đặc biệt nếu người sử dụng lao động hiểu biết. Do đó, lợi ích tốt nhất của cả chủ lao động và nhân viên là họ theo đuổi lợi ích chung của họ. Nhưng người này chắc chắn sẽ đi trước người kia. Hy vọng rằng đó là bạn (-:

Lời chúc tốt nhất,

Quốc gia

Theo xu hướng bạn đề cập, tôi sẽ thêm một xu hướng nữa, mà IMHO giải thích chúng:

Có rất nhiều lập trình viên (cần thiết) hơn bao giờ hết.

Số lượng các nhiệm vụ yêu cầu hoặc bao gồm lập trình ngày càng tăng, và với tốc độ thậm chí cao hơn số lượng lập trình viên. Ngày nay có một số vi mạch trong một chiếc xe trung bình. Trong 5 năm có thể có một con chip trong tủ lạnh và máy nướng bánh mì của bạn. Trong 10 năm, đồ lót của bạn? ... Và ai đó cần sản xuất tất cả phần mềm đó để làm cho những thứ này hoạt động. Vì vậy, có mọi nỗ lực có thể được thực hiện để tự động hóa bất cứ thứ gì có thể tự động hóa và để cải thiện "năng suất" (tuy nhiên nó được xác định). Và ngày càng nhiều bộ não mới được tuyển dụng.

Điều này ngụ ý rằng phần lớn các lập trình viên tích cực ngày nay thiếu kinh nghiệm và / hoặc không chuẩn bị cho công việc của họ. Phải mất vài năm để có được một mức độ kinh nghiệm đầy đủ và phải học hỏi không ngừng để giữ mình ở đó. Điểm mấu chốt là, ngày càng nhiều công việc lập trình đang ngày càng trở nên ít thách thức hơn. Nhưng vẫn còn đủ thách thức cho bất cứ ai đang tìm kiếm chúng .

Hãy để tôi chơi người ủng hộ của quỷ chống lại quan điểm của bạn ở trên:

Không dành thời gian để thực hiện các thực tiễn tốt nhất

Rất nhiều người không, rất nhiều người làm. Mười năm trước khi tôi lần đầu tiên phát hiện ra thử nghiệm đơn vị và cách tiếp cận nhanh, không ai trong số các đồng nghiệp của tôi có ý tưởng nhỏ nhất về nó. Ngày nay nó gần như là tài liệu tiêu chuẩn tại các trường đại học, vì vậy nhiều sinh viên mới tốt nghiệp đã hiểu nó.

Sử dụng mã người khác càng nhiều càng tốt (mã tùy chỉnh như một trách nhiệm pháp lý)

Trái ngược với những gì? Phát minh lại bánh xe? Hoặc sử dụng mã của người khác để tránh điều đó?

Tôi nghĩ điều quan trọng cần lưu ý là chúng tôi được trả tiền (hầu hết) để giải quyết vấn đề và viết mã không phải là kết thúc, chỉ có nghĩa là điều đó . Nếu một vấn đề có thể được giải quyết mà không cần viết một dòng mã, nó vẫn khiến khách hàng hài lòng. Đặc biệt là nếu cách này chúng tôi quản lý để tạo ra một giải pháp đáng tin cậy nhanh hơn và rẻ hơn. Tôi không thấy bất kỳ vấn đề với điều đó.

Sử dụng các ngôn ngữ ngày càng cao hơn để cải thiện năng suất

Trái ngược với mã hóa mọi thứ trong lắp ráp? ;-)

Các "công cụ" phát triển dựa trên GUI giúp đơn giản hóa rất nhiều "lập trình" và không yêu cầu mọi người hiểu hệ thống ống nước đằng sau mã

IMHO bất kỳ công cụ có thể được sử dụng sai. Điều đó không có nghĩa là các nhà xây dựng GUI nhất thiết phải hoàn hảo hoặc thậm chí là tốt - hầu hết (hoặc ít nhất là một số) trong số họ có thể sử dụng được trong giới hạn của họ. Nhưng nếu ai đó không biết những giới hạn đó, thì đó có phải là vấn đề của công cụ hoặc người dùng không?

Nói chung, tôi tin rằng (mặc dù không có bằng chứng để chứng minh điều đó) rằng trong những ngày sử dụng thẻ đục lỗ và mã máy, gần như tỷ lệ mã hiện tại là khủng khiếp như bây giờ, chỉ cả hai

• tổng số lượng mã và
• cơ hội người ngoài nhìn thấy mã như vậy

ít hơn nhiều

Bây giờ, với Internet và WTF hàng ngày, chúng ta tiếp xúc với những ví dụ tồi tệ nhất từng ngày. Nó giống như xem tất cả các tin tức về khủng bố và động đất và ly dị người nổi tiếng, và kêu lên rằng thế giới này trở nên nguy hiểm và vô đạo đức như thế nào.

Bạn tóm tắt tình huống một cách chính xác, nhưng hoàn toàn hiểu sai ý nghĩa.

Khi phần mềm trở nên mạnh mẽ hơn, các nhiệm vụ sẽ thực hiện theo quy mô với nó. Vì vậy, chắc chắn, ngày nay có thể không cần thiết phải là một lập trình viên cơ sở dữ liệu để tạo cơ sở dữ liệu liên hệ điện thoại khi bạn có thể sử dụng Access. Và có thể không cần thiết phải là một lập trình viên web để thiết lập một blog khi bạn chỉ có thể đi đến wordpress. Nhưng, trong khi 15 năm trước cần phải là một lập trình viên để làm những việc đó, thì những gì lập trình viên làm bây giờ là những mệnh lệnh lớn hơn những gì có thể làm được 15 năm trước.

Hãy để tôi nói theo cách này, 100 năm nữa, việc thiết lập một hệ thống phức tạp như facebook hay google sẽ là chuyện nhỏ. Tôi không nói các trang web của họ, ý tôi là trung tâm dữ liệu của họ. Bất cứ ai cũng sẽ có thể làm điều đó. Nó sẽ được tích hợp vào điện thoại, giả sử chúng ta vẫn sử dụng chúng. NHƯNG, vẫn sẽ có các lập trình viên, và trong khi họ có thể không làm việc trên các hệ thống 'tầm thường' như vậy 100 năm nữa, họ sẽ làm việc trên các hệ thống phức tạp và phức tạp hơn nhiều đến mức không ai ở đây có thể bắt đầu hiểu được phạm vi của họ và tỉ lệ. Và những hệ thống đó, giống như các hệ thống hiện nay, sẽ nằm ngoài tầm với của một nhân viên văn phòng trung bình bởi vì một số người, được gọi là lập trình viên, sẽ chọn chuyên môn hóa để đẩy công nghệ của thời đại đó đến cực điểm.

Tôi đã đọc những thứ đó trong bốn mươi năm nay và tôi đã không bắt đầu dự đoán. Nó chưa xảy ra.

COBOL là công cụ phát triển ban đầu nhằm loại bỏ nhu cầu lập trình viên kinh doanh và là ngôn ngữ cấp cao hơn nhiều so với trình biên dịch. Các thư viện mã (để tránh phải viết mã riêng của một người) có tính cổ đại tương tự.

Mỗi lần như vậy, một cái gì đó xuất hiện cho phép những người không lập trình thực hiện một cái gì đó giống như công việc lập trình. Có những "ngôn ngữ thế hệ thứ tư" thập niên 1980, các bảng tính ưa thích như Excel, trình tạo báo cáo và những thứ tương tự. Những gì họ đã làm một cách thống nhất, nếu thành công, sẽ loại bỏ một số mánh khóe khỏi lập trình và cho phép các lập trình viên làm những việc khác thú vị hơn.

Mô hình này sẽ không tồn tại mãi mãi, nhưng tôi sẽ cần một cái gì đó hơn là những lập luận và dự đoán lý thuyết để thuyết phục tôi rằng lập trình thực sự đang xuống dốc.

Vấn đề từ COBOL đến các công cụ phát triển hiện đại là chúng không thay thế khả năng lấy một đặc tả không chính xác và biến nó thành một thứ gì đó chính xác và hữu ích. Đó là khả năng cơ bản của các lập trình viên, và tại sao chúng ta sẽ không biến mất trong một thời gian dài.

Các lập trình viên của hội và FORTRAN có thể đã nói những điều tương tự khi lập trình có cấu trúc và các thông dịch viên rộng rãi được đưa vào bức tranh.

Vào cuối ngày, phần mềm là một sáng tạo có nghĩa là tự động hóa một cái gì đó mà trước đây đã được thực hiện bằng tay. Một bộ phận kế toán trong một tập đoàn vừa phải trước đây cần hàng chục người, bây giờ tất cả công việc đó có thể được hoàn thành bằng công việc của một hoặc hai. Do đó, các bài viết mục tiêu đã được chuyển và bây giờ chúng tôi mong đợi rằng tiêu chuẩn khả năng bổ sung từ một kế toán viên.

Pixar mất nhiều thời gian hơn để kết xuất phim hơn bao giờ hết. Mặc dù tốc độ tính toán tăng lên rất nhiều, cùng với nó, các nhà làm phim hoạt hình đã đòi hỏi sự phức tạp và chi tiết ngày càng tăng trong các cảnh của họ. Hoạt hình tầm cỡ Toy Story không được chấp nhận vào năm 2010 như năm 1995. Vì các công cụ của họ đã tiến bộ, do đó, có khả năng của họ và do đó kỳ vọng.

Khi kéo và thả hoặc các phương pháp lập trình khác là phổ biến, thế giới sẽ yêu cầu các giải pháp cho các vấn đề phức tạp và khó khăn hơn, và họ sẽ cần các lập trình viên sử dụng các công cụ ưa thích mới hơn đó để giải quyết chúng. Các bài viết mục tiêu sẽ di chuyển.

Mặc dù tôi đồng ý với hầu hết các câu trả lời chỉ ra rằng vẫn còn nhiều việc phải làm, tôi sẽ đưa ra một câu trả lời khác để bạn xem xét:

Đúng vậy, và nó NÊN

Tôi ở đây để thiết kế một giải pháp cho những vấn đề mà người khác không thể. Bất cứ điều gì trong bộ công cụ làm tôi mất thời gian để giải quyết các vấn đề để giải quyết tất cả các chi tiết nhỏ về cách thực hiện thiết kế của tôi là lãng phí.

Lý do duy nhất tôi sợ đi đến một ngôn ngữ cấp cao hơn hoặc một công cụ đơn giản và trừu tượng hơn là những công cụ đó thường đưa ra các giả định cản trở tôi và đòi hỏi thời gian của tôi để làm việc xung quanh các giả định để có được triển khai mong muốn.

Luôn luôn có nhiều vấn đề cần giải quyết hơn là có những người giải quyết vấn đề tốt. Ngay cả khi toàn bộ chuỗi nhà phát triển trở nên đơn giản như vậy, trẻ mẫu giáo có thể sử dụng nó, hầu hết các giải pháp được thiết kế sẽ không đủ hoặc không hiệu quả đến mức mọi người sẽ trả tiền cho một giải pháp tốt hơn bởi vì hầu hết mọi người đều rất tệ khi nhìn thấy giải pháp chính xác cho các vấn đề cạnh tranh và what-ifs mà bạn cần xem xét để đưa ra một giải pháp tốt.

Công việc của chúng tôi là giải quyết vấn đề tốt hơn hầu hết các công việc còn lại, độ phức tạp của toolchain không liên quan khủng khiếp trong chế độ xem hình ảnh lớn miễn là nó tránh được và cho phép bạn xây dựng và bạn xây dựng một cái gì đó tốt.

Mặc dù các công nghệ lập trình có thể thay đổi, sự phức tạp tiềm ẩn của một sản phẩm phần mềm vẫn còn đó. Nếu phần mềm có thể được viết hoàn toàn bằng sơ đồ hoặc biểu đồ dòng chảy (hoặc một số cách 'đơn giản' khác), thì tất cả sự phức tạp của phần mềm vẫn cần được hiểu và giải quyết. Vì lý do đó, điều quan trọng là nhà tuyển dụng phải có (các) lập trình viên biết rõ các sản phẩm của công ty để cập nhật hoặc thêm các tính năng mới. Và có thể mất khá nhiều thời gian để nhân viên học một sản phẩm phần mềm.

Không có vấn đề gì bạn có thể tự động hóa hoặc kéo ra khỏi kệ, hầu hết các phần mềm đóng gói đều thuộc hai loại:

1. Cách sử dụng đơn giản nhưng không phù hợp với những gì doanh nghiệp thực sự cần
2. Nó có khả năng tùy biến cao, nhưng cần một chuyên gia để hiểu và tận dụng sự tùy biến

Tôi đoán tôi đã quên phần ba Đó là phần mềm năng suất tiêu chuẩn (email, trình duyệt, từ Proc, v.v ... Phần mềm trong danh mục một dẫn đến các doanh nghiệp thuê các nhà phát triển phần mềm để tùy chỉnh phần mềm tắt (nếu có thể). họ cũng có thể thuê một nhà phát triển vì người biết rằng hệ thống có thể tùy chỉnh bên trong và bên ngoài được tìm kiếm rất cao (nghĩ rằng SAP, PeopleSoft, v.v.) hoặc một giống chó sắp chết (nghĩ rằng bất kỳ hệ thống nào tương tự như SAP và PeopleSoft không hoàn toàn có sự thâm nhập thị trường như nhau).

Sẽ luôn có một nhu cầu cho các nhà phát triển. Những gì tôi đang thấy là phần lớn những gì từng là thủ công, tẻ nhạt, lặp đi lặp lại đã trở thành tự động (nghĩ rằng viết mã để truy cập dữ liệu bằng tay so với sử dụng O / RM). Điều này cho phép các nhà phát triển cung cấp nhiều giá trị hơn cho doanh nghiệp với ít nỗ lực hơn.

Tôi không lấy lý lẽ của bạn:

1. Không dành thời gian để thực hiện các thực tiễn tốt nhất

ngoại trừ việc.

1. Sử dụng mã người khác càng nhiều càng tốt (mã tùy chỉnh như một trách nhiệm pháp lý)

Tái sử dụng mã là một thực hành tốt nhất. Mã được sử dụng được thử nghiệm. Tất nhiên bạn nên sử dụng mã từ các nguồn tốt, được duy trì và sử dụng bởi nhiều người.

1. Sử dụng các ngôn ngữ ngày càng cao hơn để cải thiện năng suất

Năng suất không tệ mỗi se - phải không?

1. Các "công cụ" phát triển dựa trên GUI giúp đơn giản hóa rất nhiều "lập trình" và không yêu cầu mọi người hiểu hệ thống ống nước đằng sau mã

Nếu công cụ thực hiện công việc: Sử dụng nó. Nếu không: từ chối nó. Nếu lời hứa giữ và mọi người thực sự không cần phải hiểu mã - được thực hiện tốt! Bạn dường như nói rằng đây là một lời hứa không giữ?

(Các số ở đây được tự động đăng ký lại sai. :))

Lập trình trực quan không kém phần hợp lệ hoặc đáng bị khinh miệt so với lập trình dựa trên văn bản.

Có những thiếu sót và thách thức nhất định khi lập trình trực quan, nhưng hệ thống ống nước thành phần tiềm ẩn nguy hiểm khi bị bỏ qua không bị độc quyền bởi các thành phần thị giác và các nhà thiết kế hình ảnh phù hợp hơn. Theo dõi hệ thống ống nước bị bỏ qua là một rủi ro cho bất kỳ sự phát triển.

Nếu bạn có cơ hội dùng thử Labview, bạn có thể thấy tiềm năng (hoặc thậm chí là một biến thể chuyên biệt trong môi trường Lego NXT). Trong khi không phải không có sai sót hoặc thiếu sót, có những lợi ích kế thừa. Nhìn thấy là tin tưởng.

Thực hành lập trình không chỉ tăng năng suất và giảm chi phí cho một số loại phát triển nhất định (cuộc đua của bạn xuống đáy), mà còn tăng khả năng ứng dụng và kỳ vọng của khách hàng (do đó khuyến khích một cuộc đua lên đỉnh cao). Chứng kiến ​​những phần thưởng mà Goole và Facebook đang trả để có được những nhà công nghệ hàng đầu.

Không có nghề nào khác liên quan đến kỹ thuật tồn tại mà cố gắng hướng tới thay đổi nhiều như lập trình. Ngay khi bạn đơn giản hóa một cái gì đó, bạn chỉ cần mở một hộp cho các vấn đề mới nảy sinh ý tưởng mới.

Vì vậy, tôi sẽ không nỗ lực chia sẻ mã và giải pháp của người khác để giúp chúng tôi tiến tới những thách thức mới, ý tưởng và trải nghiệm người dùng với các thực hành xấu của từng học viên, thói quen xấu và cách cư xử không có chủ nghĩa nhân văn.

Nếu chúng ta thực hành:

WTF? Ý của bạn là danh sách này không nhất quán? Danh sách nên đến từ cùng một phía cho mỗi yếu tố thay vì chuyển đổi qua lại mà không có cảnh báo. Do đó, danh sách của bạn nên đọc:

Nếu chúng ta thực hành: