Các nhà sản xuất công cụ mã thấp và không mã (LC / NC) đang phải đối mặt với một cuộc chiến khó khăn khi cố gắng thuyết phục mọi người, đặc biệt là các nhà phát triển chuyên nghiệp, sử dụng hoặc thậm chí chỉ dùng thử các công cụ và nền tảng của họ. Một số nền tảng đã thâm nhập vào thị trường này, nhưng phần lớn việc phát triển phần mềm chắc chắn vẫn được thực hiện bởi các chuyên gia viết mã. Từ quan điểm của các nhà sản xuất công cụ, sự thiếu quan tâm dường như là một điều khó hiểu. Phát triển nhanh hơn, chi phí thấp hơn, ít lỗi hơn, triển khai dễ dàng hơn, môi trường được quản lý - tại sao mọi người lại từ chối những nhà sản xuất công cụ tầm nhìn không tưởng này muốn trình bày? Tại sao nhiều người lại tiếp tục cuộc chiến với những ngôn ngữ khó, khả năng truy tìm lỗi phức tạp và thiết lập môi trường khó hiểu? Tôi đã nói chuyện với các nhà phát triển, đọc các bài báo và tìm kiếm các diễn đàn thảo luận để tìm câu trả lời cho những câu hỏi này và đã đối chiếu một số lý do đưa ra. Nó không giúp ích gì cho sự nghiệp của họ Học các công cụ mã thấp có thể đòi hỏi đầu tư đáng kể về thời gian và công sức, nhưng có rất ít giá trị chuyên môn trong việc học một công cụ LC / NC cụ thể. Ngay cả trong trường hợp hiếm hoi mà một công ty phát triển phần mềm sử dụng công cụ LC / NC, các kỹ năng mà một nhà phát triển nhân viên có được bằng cách học công cụ đó rất có thể sẽ không được nhà tuyển dụng tiếp theo yêu cầu. Hầu hết các công việc phát triển đòi hỏi kiến thức và kinh nghiệm chuyên sâu với các ngôn ngữ và khuôn khổ được sử dụng rộng rãi và không có công cụ mã thấp nào được sử dụng rộng rãi như React, Angular, Python, Java hoặc C #. Rất ít công việc phát triển yêu cầu kiến thức về các công cụ LC / NC và khả năng một nhà phát triển sẽ tìm được công việc tốt hơn hoặc kiếm được nhiều tiền hơn khi biết một công cụ LC / NC là rất thấp. Vì vậy, các nhà phát triển tốt hơn nên dành thời gian học hỏi và hoàn thiện một trong vô số kỹ năng, khuôn khổ và ngôn ngữ đang có nhu cầu cao trên thị trường việc làm. Các nhà phát triển đã dành nhiều năm để học cách viết mã Gần 70% nhà phát triển đã phản hồi tuyên bố họ có bằng Cử nhân trở lên về Khoa học Máy tính hoặc một môn học liên quan. Điều này có nghĩa là phần lớn các nhà phát triển đã đầu tư nhiều năm vào việc nghiên cứu lập trình, học các ngôn ngữ khác nhau, kiến trúc hệ thống và nói chung là thực hành và hoàn thiện nghệ thuật viết mã. Sử dụng các công cụ LC / NC thường có nghĩa là bỏ qua những lợi thế mà kinh nghiệm và khoản đầu tư khó kiếm được của họ. Vì vậy, không có gì ngạc nhiên khi hầu hết các nhà phát triển thích dựa vào những kỹ năng quý giá mà họ đã dày công tích lũy. Khảo sát dành cho nhà phát triển Stack Overflow năm 2021 Nếu các công cụ LC / NC thực sự cung cấp những gì họ hứa, thì việc viết mã để tạo ứng dụng sẽ không còn được yêu cầu trong tương lai. Lập trình sẽ chuyển sang mức trừu tượng cao hơn và các ứng dụng sẽ được lắp ráp từ các thành phần hiện có chứ không phải được mã hóa. Vì vậy, các lập trình viên về cơ bản đe dọa làm cho các kỹ năng khó kiếm được của họ trở nên thừa bằng cách sử dụng và hỗ trợ việc sử dụng ngày càng nhiều các công cụ LC / NC. Do đó, họ thực sự quan tâm đến việc các công cụ LC / NC không thành công. Các nhà phát triển ít quan tâm hơn đến tốc độ Khi các nhà phát triển làm việc cho các công ty phần mềm, họ được trả tiền để cung cấp mã có các đặc điểm cụ thể. Chúng bao gồm dễ đọc, có thể kiểm tra, có cấu trúc tốt, đáng tin cậy, hiệu quả, tuân theo các tiêu chuẩn, v.v. Các nhà phát triển duy trì các ứng dụng thậm chí phức tạp ở mức độ vừa phải sẽ đánh giá cao tầm quan trọng của việc đảm bảo mã càng đơn giản càng tốt và dễ hiểu. Những phẩm chất này là cần thiết để mã có thể bảo trì được. Mã thường được xem xét bởi một lập trình viên cao cấp hơn, người cũng quan tâm đến những phẩm chất này và củng cố sự nhấn mạnh vào chúng. Họ có thể quan tâm nhiều hơn đến việc hoàn thành công việc nhanh hơn so với nhà phát triển, nhưng họ biết rằng mã lỗi, không hiệu quả, được viết khó hiểu và khó mở rộng là rất khó để duy trì. Mã xấu này có thể gây ra nhiều rắc rối và trở nên rất tốn kém. Mặc dù tốc độ phân phối mã là có liên quan, nhưng cách mã được tổ chức và viết thường được ưu tiên hơn tốc độ mà mã được phân phối. Vì vậy, việc tiếp thị tốc độ phát triển của các công cụ LC / NC cho các nhà phát triển có thể không thực sự có tác động như mong đợi. Các nhà phát triển thích viết mã Con người mơ hồ và dễ xúc động. Họ có những ưu tiên mâu thuẫn nhau, thường không chắc chắn, không chính xác và hay nói dối. Thường thì họ thậm chí không biết họ đang làm gì và tại sao họ lại làm điều đó. Mọi người có thể rất khó hiểu. Máy tính đơn giản hơn nhiều. Máy tính chỉ đơn giản làm theo các hướng dẫn mà lập trình viên đưa ra và nếu những hướng dẫn đó không chính xác, chương trình sẽ không thành công. Sự chính xác trong việc xác định một tập hợp các nhiệm vụ và thấy chúng được thực hiện ngay lập tức và chính xác mang lại cho nhiều người cảm giác an toàn và vui vẻ. Có một yếu tố sáng tạo trong mã hóa mà nhiều nhà phát triển thực sự thích thú. Lập trình là một câu đố rất phức tạp, đầy rẫy những câu đố hóc búa, trải dài hàng chục mô-đun, nhiều lớp và hàng nghìn dòng mã. Một ứng dụng web có thể dễ dàng liên quan đến năm hoặc nhiều ngôn ngữ khác nhau hoạt động cùng nhau (ví dụ: HTML, JS, CSS, C #, SQL). Thời trang hóa các đối tượng phức tạp gồm các bộ phận chuyển động lồng vào nhau và xem chúng hoạt động theo các chu kỳ tinh tế khi chúng phát huy các hệ quả của logic được tích hợp trong chúng có thể rất thú vị và mang lại cảm giác hoàn thành mạnh mẽ. Lý do tại sao phần mềm tồn tại là để làm cho cuộc sống dễ dàng hơn và về cơ bản chúng tôi xây dựng phần mềm để giúp mọi người làm mọi việc tốt hơn. Một khi bạn biết cách viết mã - bằng bất kỳ ngôn ngữ nào - bạn có thể xây dựng bất cứ thứ gì bạn có thể tưởng tượng. Có niềm vui khi tưởng tượng ra điều gì đó và sau đó tạo ra nó từ con số không, đặc biệt là khi nó hữu ích cho người khác và khiến họ hạnh phúc. Các nhà phát triển không chọn ngăn xếp công nghệ Nhà phát triển ở lại một dự án càng lâu thì họ càng có khả năng mở rộng ứng dụng tốt hơn và họ càng trở nên hiệu quả hơn trong việc tìm kiếm và khắc phục sự cố. Khi các nhà phát triển rời bỏ công việc của họ, họ thường mang theo kiến thức sâu sắc về các chi tiết phức tạp của các ứng dụng với họ. Kiến thức này rất khó lấy lại và khi những nhân viên như vậy bị thay thế, các ứng dụng mà họ hỗ trợ thường đi vào giai đoạn không ổn định và đôi khi thậm chí hỗn loạn. Vì vậy, trong khi các nhà phần mềm quan tâm đến sự ổn định, các nhà phát triển phần mềm thường chỉ ở lại với một nhà tuyển dụng trong vài năm. Một chiến lược mà các nhà phần mềm sử dụng để giảm thiểu mất kiến thức là sử dụng các công nghệ được sử dụng rộng rãi và nổi tiếng trong cộng đồng các nhà phát triển. Sử dụng các công ty nổi tiếng giúp tìm kiếm những người có kỹ năng dễ dàng hơn để tuyển dụng. Nó cũng giúp những người đó tìm hiểu thông tin chi tiết về các ứng dụng được xây dựng với họ. Các nhà phát triển có thể là những người có ảnh hưởng trong việc quyết định sử dụng công nghệ nào cho một dự án, nhưng thường thì các kỹ sư cấp cao hoặc thậm chí là ban quản lý mới là người quyết định các công nghệ sử dụng các tiêu chí này. Tiếp thị các công cụ LC / NC cho các nhà phát triển do đó có thể bỏ sót nhãn hiệu. Đặt cược vào một công cụ là rủi ro Khách hàng có xu hướng khó xác định nơi họ có thể đăng ký trong tương lai. Điều này cũng dễ hiểu vì tương lai rất khó đoán định. Vì vậy, chủ sở hữu ứng dụng cần phải thích ứng với các nhu cầu thay đổi để đảm bảo thành công thương mại của một ứng dụng. Điều này thường có nghĩa là sửa đổi các mô hình kinh doanh và thay đổi công nghệ cho phép các mô hình đó. Các nhà phát triển có kinh nghiệm biết điều này và thích xây dựng các hệ thống mở có thể thích ứng với các nhu cầu thay đổi trong tương lai. Cách tốt nhất để tạo ra các hệ thống thích ứng như vậy là viết mã chúng bằng các ngôn ngữ và khuôn khổ được hỗ trợ tốt. Nhiều công cụ LC / NC còn mới, chưa hoàn thiện và đi kèm với những hạn chế kỹ thuật đáng kể. Những giới hạn này thường không được quảng cáo và thường chỉ được ghi chép lại một cách thưa thớt. Cách duy nhất mà các nhà phần mềm thực sự có thể tìm ra những giới hạn này là dùng thử một công cụ và xây dựng một ứng dụng thực sự. Hầu hết các hạn chế sẽ chỉ trở nên rõ ràng sau khi đầu tư đáng kể thời gian và công sức. Phát triển phần mềm rất tốn kém và rủi ro như nó vốn có và những ẩn số này còn làm tăng rủi ro cho các nhà phát triển, nhà phần mềm và khách hàng của họ hơn nữa. Lock-in niêm phong thỏa thuận Nhiều nền tảng không cho phép xuất các ứng dụng được xây dựng trong nền tảng đó sang các định dạng chung, có thể chỉnh sửa. Họ khóa các ứng dụng, do đó ràng buộc nhà phát triển với nền tảng hoặc yêu cầu họ xây dựng lại ứng dụng của mình từ đầu. Xem xét rằng các yêu cầu trong tương lai là không chắc chắn và các hạn chế của các công cụ LC / NC thường vẫn bị che giấu cho đến cuối dự án, không có gì ngạc nhiên khi các nhà phát triển có thể cực kỳ cảnh giác khi bị khóa. LC / NC đã thất bại nhiều lần trong quá khứ Các công cụ phát triển trực quan không phải là mới. Những nỗ lực ban đầu để phát triển trực quan đã được thực hiện cách đây 50 năm. Kể từ đó, rất nhiều môi trường và nền tảng phát triển trực quan tốt và xấu đã xuất hiện và biến mất và không có môi trường và nền tảng nào tạo ra sự khác biệt đáng kể cho cách các ứng dụng được tạo ra. Bất kỳ ai đặt cược vào bất kỳ công cụ nào trong số này, đầu tư thời gian và năng lượng để tìm hiểu chúng và thuyết phục khách hàng xây dựng dự án của họ bằng bất kỳ công cụ nào trong số họ đều thua cuộc đặt cược đó. Lịch sử này cho thấy rằng không có khả năng rằng bất kỳ công cụ nào mà chúng ta bắt gặp ngày nay sẽ vẫn còn tồn tại trong khoảng một thập kỷ kể từ bây giờ. Nhiều nhà phát triển có thể xem xét những sự kiện này một cách cẩn thận và quyết định rằng LC / NC là một ngõ cụt. Giờ thì sao? Vì vậy, LC / NC có phải là một nguyên nhân thất bại, và không có chỗ cho LC / NC trong thế giới phát triển phần mềm nghiêm túc? Liệu các nhà sản xuất công cụ LC / NC bằng cách nào đó có thể vượt qua những rào cản này và thúc đẩy nhiều nhà phát triển sử dụng các sản phẩm LC / NC hơn không? Nhiều nhà phát triển thích mã hơn vì thiếu tin tưởng vào các công cụ LC / NC và phương tiện truyền thông tiếp thị quảng cáo chúng. Để thuyết phục bất kỳ chuyên gia nào sử dụng nền tảng LC / NC, các nhà sản xuất nền tảng yêu cầu các nhà phát triển tin tưởng họ. Để xây dựng lòng tin này, các nhà sản xuất công cụ sẽ làm tốt việc lắng nghe các mối quan tâm của các nhà phát triển và nhà phần mềm đưa ra và tính đến chúng khi lập kế hoạch các tính năng nền tảng và khi giao tiếp với các nhóm mục tiêu. Việc tiết lộ trung thực và trung thực các giới hạn chức năng, công bố các cách khắc phục các hạn chế, làm phẳng đường cong học tập cho các nền tảng và cho phép xuất các ứng dụng sang các định dạng có thể chỉnh sửa, mặc dù chúng có thể không thuyết phục tất cả các nhà phát triển đi đúng hướng.

Stacks

Target

2022 - HackerNoon Contributor of the Year - Coding

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Low Code

2022 - HackerNoon Contributor of the Year - Psychology

2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Low Code

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - HackerNoon Contributor of the Year - Psychology

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Making security fun one episode at a time

8 điều nhà phát triển không thích về mã thấp và không mã

8 điều nhà phát triển không thích về mã thấp và không mã

dài quá đọc không nổi

Company Mentioned

Coin Mentioned

Franz Rodenacker

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

8 điều nhà phát triển không thích về mã thấp và không mã

dài quá đọc không nổi

Company Mentioned

Coin Mentioned

Franz Rodenacker

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN