Tại sao các nhà phát triển lại ghét việc thay đổi các phiên bản ngôn ngữ

Người lập trình

Tiến bộ thúc đẩy công nghệ tiến lên. Nhưng sự tiến bộ cũng có cái giá phải trả: bằng cách thêm các khả năng và tính năng mới, cộng đồng nhà phát triển liên tục điều chỉnh các khối xây dựng. Điều đó bao gồm các ngôn ngữ cơ bản được sử dụng để viết mã các giải pháp công nghệ.

Khi các khối xây dựng thay đổi, mã đằng sau giải pháp công nghệ cũng phải thay đổi. Đó là một bài tập đầy thách thức và tốn thời gian, tiêu hao tài nguyên. Nhưng nếu có một giải pháp thay thế thì sao?

Sự cố: đọc mã người khác đã viết

Hãy lùi lại một bước và xem xét một trong những thách thức cơ bản trong quá trình phát triển: chỉnh sửa mã của người khác. Chỉnh sửa mã bạn vừa viết hoặc đã viết một vài tuần trước, đều tốt. Nhưng chỉnh sửa mã của chính bạn được viết từ nhiều năm trước – đừng bận tâm đến mã của người khác – đó là một câu chuyện khác.

Các quy tắc kiểu mã nội bộ có thể hữu ích nhưng luôn có các quy ước đặt tên kỳ lạ cho các biến và hàm hoặc các lựa chọn bất thường cho các thuật toán. Có thể cho rằng, khả năng đọc mã của một viên là một kỹ năng quan trọng – nhưng nó khó đối với tất cả mọi người.

Các nhà phát triển gọi quá trình chỉnh sửa mã cũ là “tái cấu trúc” và đó là một quá trình thường đưa ra các lỗi mới hoặc các vấn đề về hiệu suất. Vì vậy, đó là lý do tại sao, quay lại và chỉnh sửa mã cũ – đó là điều cuối cùng mà hầu hết các nhóm phát triển muốn làm, đặc biệt là khi cơ sở mã hiện có đang chạy ổn định và thực hiện công việc của nó.

Đó là một cơn đau đầu thực sự, nhưng đôi khi không có giải pháp thay thế

Tái cấu trúc là điều mà mọi nhà phát triển muốn tránh càng lâu càng tốt vì nó có thể cảm thấy lãng phí thời gian. Tuy nhiên, các nhà phát triển phải cấu trúc lại theo thời gian vì nhiều lý do và một trong những lý do phổ biến nhất là do những thay đổi trong các khối xây dựng của nhà phát triển.

Xem tiếp:   Đo điểm chuẩn Bảo mật Linux - Phát hiện nghiên cứu mới nhất

Điều đó bao gồm những thay đổi đối với ngôn ngữ lập trình được sử dụng để xây dựng phần mềm, điều này chắc chắn sẽ phát triển theo thời gian. Các phiên bản mới của một ngôn ngữ thường sẽ không còn áp dụng các cách làm cũ trong khi giới thiệu các tính năng mới. Nếu các nhà phát triển không áp dụng phiên bản ngôn ngữ mới, họ sẽ bị loại khỏi bộ tính năng mới.

Tuy nhiên, mã hiện tại thường cần điều chỉnh để chạy trên phiên bản mới của ngôn ngữ và điều đó ngụ ý quá trình tái cấu trúc. Và đó là câu hỏi hóc búa: để áp dụng phiên bản mới, nâng cao hơn của ngôn ngữ, các nhà phát triển cần phải cấu trúc lại và trên đường đi, họ sẽ tốn rất nhiều công sức – và phá vỡ mọi thứ không mong muốn, đưa các lỗi mới vào một ứng dụng đã chạy tốt.

Tệ hơn nữa, việc tái cấu trúc lại không mang lại cho bạn những lợi thế của phiên bản ngôn ngữ mới, thay vào đó bạn cần phải phát triển lại cơ sở mã của mình để khai thác các cải tiến. Nếu không, mặc dù đã điều chỉnh mã để phù hợp với phiên bản ngôn ngữ mới, nhưng bạn vẫn như trước đây: một cơ sở mã chạy trên phiên bản ngôn ngữ mới, nhưng không có tính năng mới.

Các nhà cung cấp thường để người dùng cuối giải quyết

Nó có vẻ như là một bài tập vô nghĩa nhưng, với sự thay đổi liên tục của công nghệ, thường có rất ít sự lựa chọn trong vấn đề này – với các đối tác công nghệ của bạn sẽ lựa chọn cho bạn.

Giả sử chúng ta vừa chuyển từ Python 2.7 sang Python 3.0. Nếu bạn đang phát triển các ứng dụng của mình trong nhà, bạn có toàn quyền kiểm soát và có thể thay đổi hoặc không thay đổi. Mặt khác, các nhà phát triển có thể quyết định để mọi thứ như vậy. Nếu một ứng dụng được phát triển và chạy trên Python 2.7, nhà phát triển sẽ chỉ để nó ở đó – và cho người dùng biết một ứng dụng được phát triển cho Python 2.7, không hỗ trợ các phiên bản khác.

Xem tiếp:   Mới mẻ

Nó có thể khiến người dùng rơi vào tình thế khó khăn – ở trên phiên bản cũ hơn của Python 2.7 để thích ứng với ứng dụng, bỏ lại tiến độ hoặc chuyển sang Python 3.0 và có nguy cơ xảy ra một loạt các điểm không tương thích với các ứng dụng.

Kết quả ròng: một rủi ro bảo mật lớn

Các ngôn ngữ lập trình (và các loại thư viện của chúng) không tránh khỏi các lỗ hổng bảo mật. Khi những lỗ hổng này xuất hiện, nhà phát triển có thể buộc bạn phải nâng cấp phiên bản ngôn ngữ.

Nhưng những nâng cấp này sẽ không giới hạn ở các bản sửa lỗi đơn giản – chúng sẽ kéo theo việc ngừng sử dụng các cấu trúc ngôn ngữ với các cấu trúc mới được đưa vào và điều đó sẽ buộc các nhà phát triển phải thực hiện các thay đổi đối với mã hiện có, một lần nữa với tất cả các vấn đề tiềm ẩn. mang lại.

Tình hình thậm chí còn trở nên tồi tệ hơn khi bạn nghĩ về hiệu ứng kép của các thư viện được bao gồm. Sau khi thay đổi ngôn ngữ, các thư viện này cũng phải được cập nhật – nhưng nếu một trong các thư viện đang sử dụng không được tác giả của nó cập nhật, nhà phát triển sẽ không thể sử dụng nó sau khi nâng cấp phần còn lại của mã lên phiên bản mới hơn, một lần nữa dẫn để viết mã nhiều hơn.

Thật dễ dàng để thấy tất cả dẫn đến đâu: nỗ lực nhiều hơn, rủi ro bổ sung về việc tạo ra lỗi… và sự miễn cưỡng phải thực hiện cấu trúc lại để phù hợp với các bản cập nhật. Tiếp theo? Các bản cập nhật chỉ đơn giản là không được thực hiện, có nghĩa là khối lượng công việc dựa vào các khối xây dựng lỗi thời, không an toàn.

Xem tiếp:   Phát hiện lỗ hổng Log4j thứ hai (CVE-2021-45046) - Đã phát hành bản vá mới

Câu chuyện tương tự như những gì chúng ta thấy đang diễn ra trên khắp thế giới công nghệ, khi các khối xây dựng cũ kỹ và dễ bị tấn công để ngỏ cánh cửa cho các cuộc . Tuy nhiên, có một số tin tốt đang xuất hiện.

Có giải pháp nào tốt hơn không?

Lấy ví dụ như các hệ điều hành không được hỗ trợ. Trước đây, khi một hệ điều hành hết tuổi thọ, sự lựa chọn duy nhất là nâng cấp lên một hệ điều hành mới hơn – một khoản đầu tư lớn và đầy rủi ro. Kết quả thực tế là nhiều tổ chức dựa vào các hệ điều hành chưa được vá lỗi, không được hỗ trợ ngay cả đối với khối lượng công việc quan trọng. Nếu bạn không có ứng dụng cập nhật, bởi vì các nhà phát triển sẽ không cấu trúc lại cơ sở mã cũ, bạn không thể chuyển ứng dụng của mình sang hệ điều hành mới hơn không hỗ trợ các phiên bản cũ của ngôn ngữ – và do đó sẽ phá vỡ ứng dụng.

Rất may, kịch bản này đã thay đổi vì hỗ trợ hết hạn hiện đã trở thành hiện thực đối với nhiều hệ điều hành Linux, có nghĩa là các tổ chức có thể mua thời gian để chuyển từ một hệ điều hành không được hỗ trợ sang một hệ điều hành có sự hỗ trợ của nhà cung cấp chính thức mà không phải chịu bất kỳ rủi ro bảo mật nào.

Điều gì đó tương tự có thể được thực hiện cho các phiên bản ngôn ngữ? Một cách hiệu quả để “nâng cấp” thời gian chạy ngôn ngữ với các bản sửa lỗi bảo mật mới nhất đồng thời không thay đổi cách thức hoạt động của phiên bản ngôn ngữ cụ thể hoặc các thư viện, do đó loại bỏ nhu cầu cấu trúc lại?

Việc lặp lại những gì đã đạt được cho các hệ điều hành và áp dụng nó vào các phiên bản ngôn ngữ sẽ mang lại cho các nhà phát triển không gian thở rất lớn, giảm nhu cầu liên tục tái cấu trúc. Đổi lại, có khả năng cao hơn là khối lượng công việc chạy một cách an toàn và bảo mật.

Nó có khả thi không? Chà, những gì đạt được cho hệ điều hành có thể được mở rộng sang các lĩnh vực khác. Xem không gian này.

.

Related Posts

Check Also

Nhà phát triển tiền mặt Tornado bị bắt sau lệnh trừng phạt của Hoa Kỳ Máy trộn tiền điện tử

Các nhà chức trách Hà Lan hôm thứ Sáu đã thông báo về việc bắt …