Chiến lược theo kịp sự thay đổi ngôn ngữ (Python)

Viết mã vẫn sẽ chạy nhiều năm kể từ bây giờ

Ngôn ngữ lập trình thay đổi. Thư viện thay đổi. Một số mã từ 5, 10 hoặc thậm chí 20 năm trước vẫn có thể chạy và tạo ra kết quả như mong đợi, trong khi một số mã từ 2 năm có thể không thành công với lỗi cú pháp. Điều này là một phần không thể tránh khỏi, vì các ngôn ngữ phát triển (ít nhất, hầu hết làm). Các nhà phát triển có trách nhiệm duy trì mã của họ. Nhưng đôi khi, sự ổn định là một yêu cầu quan trọng trong mã sản xuất và mã chỉ cần chạy trong 10 năm mà không cần ai đó thông qua mã hàng năm để điều chỉnh nó để thay đổi ngôn ngữ. Hoặc tôi có thể có các tập lệnh nhỏ, ví dụ để phân tích dữ liệu khoa học, tôi cần xem lại sau khi không chạm vào chúng trong nhiều năm. Ví dụ, tại các cơ quan khí tượng có rất nhiều mã Fortran hoạt động ngay cả đối với các bộ phận không cần thiết về tốc độ và tính ổn định của mã là một trong những lý do. TÔI' Đã nghe thấy nỗi sợ về sự không ổn định là một trong những đối tượng họ có chống lại việc chuyển sang Python (tất nhiên ngoài quán tính ngôn ngữ; chỉ có thể mã mới không phụ thuộc vào mã cũ). Tất nhiên, một chiến lược cho mã ổn định là đóng băng toàn bộ hệ điều hành. Nhưng điều đó không phải lúc nào cũng khả thi.

Tôi đang sử dụng Python như ví dụ, nhưng vấn đề không chỉ giới hạn ở Python.

Tài liệu về các vấn đề tương thích Python

Trong trường hợp của Python, có một số tài liệu phác thảo chính sách cho các thay đổi không tương thích ngược.

PEP-5

Theo PEP 5 :

Phải có ít nhất một giai đoạn chuyển tiếp một năm giữa việc phát hành phiên bản chuyển tiếp của Python và phát hành phiên bản không tương thích ngược. Người dùng sẽ có ít nhất một năm để kiểm tra các chương trình của họ và di chuyển chúng từ việc sử dụng cấu trúc không dùng nữa sang cấu trúc thay thế.

Cá nhân, tôi cho rằng một năm là khá ngắn. Điều đó có nghĩa là tôi có thể viết một số mã và 1 năm rưỡi nữa nó sẽ không chạy nữa.

PEP 291

PEP 291 chứa một danh sách không đầy đủ các hướng dẫn về những điều nên tránh để duy trì khả năng tương thích ngược. Tuy nhiên, nó chỉ liên quan đến Python 2.x. Vì Python 2.7 là bản phát hành cuối cùng trong loạt 2.x và Python 2.7 chỉ có lỗi, PEP này hiện chỉ được quan tâm trong lịch sử.

PEP 387

Ngoài ra còn có PEP 387 về các thay đổi không tương thích ngược. PEP 387 là một dự thảo và không phải là chính sách chính thức. Vào tháng 6 năm 2009, điều này đã được thảo luận trong danh sách gửi thư ý tưởng Python . Một phần của cuộc thảo luận tập trung vào cách các nhà phát triển có thể viết mã mạnh mẽ chống lại sự thay đổi ngôn ngữ. Một bài viết liệt kê một số lời khuyên về những điều không nên làm :

Cùng với điều này, có một số quy tắc bạn có thể suy ra có lẽ đúng trong hầu hết thời gian: không gọi công cụ bắt đầu bằng "_", không sửa lỗi bất cứ điều gì, không sử dụng thay thế lớp động trên các đối tượng từ các lớp khác ngoài chính bạn , không phụ thuộc vào độ sâu của hệ thống phân cấp thừa kế (ví dụ: không ".__bases__[0].__bases__[0]"), đảm bảo các thử nghiệm của bạn chạy mà không tạo ra bất kỳ Khấu hao nào, hãy chú ý đến xung đột không gian tên tiềm năng khi thêm thuộc tính vào các lớp kế thừa từ các thư viện khác. Tôi không nghĩ rằng tất cả những điều này được viết ra ở một nơi.

Ngoài ra, có một số điểm về "trường mỏ" (tính năng mới có khả năng thay đổi) và "khu vực đóng băng" (API được bán rất nhiều đảm bảo không thay đổi). Trích dẫn Antoine Pitrou :

Tôi nghĩ rằng "khu vực đóng băng" nên được xác định một cách tích cực (API công khai rõ ràng và hành vi được bảo đảm rõ ràng) chứ không phải tiêu cực (một "trường khai thác" rõ ràng). Nếu không, chúng ta sẽ quên đặt một số thứ quan trọng vào bãi mìn và bị cắn sau đó khi chúng ta cần thay đổi những thứ đó theo cách không tương thích ngược.

Dường như không có bất kỳ kết luận nào từ chủ đề này, nhưng nó khá gần với cốt lõi của những gì tôi đang tìm kiếm. Sợi chỉ gần bốn năm tuổi, nên có lẽ tình hình đã thay đổi hoặc được cải thiện. Loại mã nào có khả năng tồn tại và loại mã nào dễ vỡ hơn?

Hướng dẫn chuyển

Ngoài các tài liệu được nêu ở trên, mỗi phiên bản Python đều có một hướng dẫn chuyển : chuyển sang Python 3.2 , chuyển sang Python 3.3 , v.v.

Tương thích hữu ích

PEP 3151 đã giới thiệu cho tôi khái niệm về khả năng tương thích hữu ích . Nói theo cách riêng của tôi, điều này rút ra ý tưởng rằng chỉ khi mã được viết cẩn thận, các nhà phát triển ngôn ngữ cần phải cẩn thận để duy trì khả năng tương thích. Nó không thực sự xác định khả năng tương thích hữu ích , nhưng tôi nghĩ nó tương tự như những ý tưởng tôi đã trích dẫn từ cuộc thảo luận PEP 387 ở trên.

Từ quan điểm của các lập trình viên

Là một lập trình viên, tôi biết rằng Python sẽ thay đổi trong tương lai và mọi người - đặc biệt là bản thân tôi - sẽ cố gắng chạy mã của tôi có lẽ vài năm nữa trong phiên bản Python là một, hai hoặc có thể là ba phiên bản nhỏ trở lên. Không phải mọi thứ đều tương thích, và trên thực tế, thật dễ dàng để đưa ra mã sẽ thất bại (tôi đã từng gặp phải mã nêu rõ if sys.version[:3] != '2.3': print 'Wrong version, exiting'). Những gì tôi đang tìm kiếm là một bộ hướng dẫn về những gì nên làm và không nên làm để tăng cường khả năng mã của tôi sẽ vẫn không thay đổi trong tương lai.

Có bất kỳ hướng dẫn như vậy? Làm cách nào để viết mã Python vẫn sẽ chạy trong tương lai?

Câu hỏi của tôi liên quan đến cả cốt lõi Python, vào thư viện tiêu chuẩn của nó, mà còn để thường được sử dụng add-on thư viện, đặc biệt là numpy, scipy, matplotlib.

EDIT : Cho đến nay, hai trong số các câu trả lời liên quan đến python2 so với python3. Đây không phải là ý tôi. Tôi biết về các công cụ để di chuyển từ Python2 sang Python3. Câu hỏi của tôi liên quan đến những thay đổi ngôn ngữ chưa đến . Chúng ta có thể làm tốt hơn một quả cầu pha lê trong việc tìm kiếm các hướng dẫn mã hóa ổn định hơn. Ví dụ:

• import modulelà bằng chứng trong tương lai nhiều hơn from module import *, bởi vì cái sau có thể phá vỡ mã nếu modulephát triển một hoặc nhiều hàm / lớp mới.

• Sử dụng các phương pháp không có giấy tờ có thể ít bằng chứng trong tương lai hơn so với sử dụng các phương pháp được lập thành tài liệu, vì một cái gì đó không có giấy tờ có thể là một dấu hiệu của một cái gì đó chưa ổn định.

Đây là loại lời khuyên mã hóa thực tế mà tôi đang theo đuổi. Vì đó là về hiện tại → tương lai, chúng ta có thể giới hạn bản thân mình với Python3, vì Python2 sẽ không thay đổi nữa.

Đây là một vấn đề chưa được giải quyết trong lĩnh vực của chúng tôi. Không có cách nào để chắc chắn rằng mã của bạn sẽ hoạt động vô thời hạn. Ngay cả khi mã của bạn thực sự hoàn hảo theo nghĩa tương thích về phía trước (và nếu có, vui lòng đến làm việc cho công ty của tôi !;)), Nếu nó chạy, sử dụng hoặc được sử dụng bởi bất kỳ phần mềm nào khác có lỗi hoặc thay đổi trong bất kỳ cách nào, mã của bạn có thể không hoạt động.

Vì vậy, tôi không thể cung cấp cho bạn một danh sách những điều cần làm, nếu bạn làm theo chúng, sẽ đảm bảo thành công. Nhưng những gì bạn có thể làm là giảm thiểu rủi ro vỡ trong tương lai và giảm thiểu tác động của chúng. Một Pythonist có kiến ​​thức hơn sẽ có thể cho bạn lời khuyên cụ thể hơn về Python, vì vậy tôi sẽ phải nói chung hơn:

• viết bài kiểm tra đơn vị. Ngay cả đối với những thứ mà bạn biết không cần chúng.

• sử dụng các thư viện và công nghệ phổ biến / được thiết kế tốt / ổn định, tránh các thư viện không phổ biến (và do đó có thể sẽ sớm không được hỗ trợ)

• tránh viết mã khai thác chi tiết thực hiện. Mã để giao diện, không thực hiện. Mã chống lại nhiều triển khai của cùng một giao diện. Ví dụ: chạy mã của bạn trong CPython, Jython và IronPython và xem điều gì sẽ xảy ra. Điều này sẽ cung cấp cho bạn một số phản hồi tuyệt vời về mã của bạn. Điều này có thể không hữu ích cho Python3 mặc dù - lần trước tôi nghe nói, một số triển khai vẫn còn trong Python2.

• viết mã đơn giản, rõ ràng rõ ràng về các giả định của nó

• viết mô-đun, mã tổng hợp. Nếu một số mã phải làm điều gì đó nguy hiểm (theo nghĩa chứng minh trong tương lai), hãy tách nó ra để ngay cả khi nó phải thay đổi, phần còn lại của mã không.

• có một đặc điểm kỹ thuật của một số hình thức. Điều này tương tự với các điểm về kiểm tra đơn vị, nếu bạn sử dụng các kiểm tra làm thông số kỹ thuật và giao diện, cũng có thể được sử dụng làm thông số kỹ thuật. (Ý tôi là giao diện theo nghĩa chung, không phải nghĩa của từ khóa Java).

Làm bất cứ điều gì trong số này có thể / sẽ làm tăng số lượng công việc bạn phải làm. Tôi nghĩ điều đó có ý nghĩa - rất nhiều trong số những điểm này cũng có thể được tạo ra để làm thế nào để viết mã tốt, điều này khá khó khăn (theo ý kiến ​​của tôi). Đôi khi bạn có thể cần phải vi phạm một số đề xuất này. Điều đó là hoàn toàn chấp nhận được, nhưng hãy chú ý đến các chi phí.

Thật tuyệt khi nhóm Python đang nghĩ về điều này, và chắc chắn họ tài năng và tài giỏi hơn tôi từng có. Tuy nhiên, tôi sẽ ước tính có 100% rằng mã của ai đó ở đâu đó sẽ ngừng hoạt động theo cách mà nó muốn khi Python được nâng cấp.

Nó được gọi là Quản lý cấu hình. Nếu hệ thống không bao giờ thay đổi, nó không nên bị hỏng. Vì vậy, đừng thay đổi hệ thống. Lo lắng về các bản phát hành Python mới? Đừng nâng cấp. Lo lắng về trình điều khiển thiết bị mới? Đừng nâng cấp. Lo lắng về các bản vá Windows? ...

Đối với Python 2 -> Python 3, đã có thư viện Python 2to3 đã được cài đặt (đi kèm với gói Python gốc).

Dựa vào đó, ngay sau khi các phiên bản mới được phát hành, cần có các thư viện tương tự đi kèm với mỗi phiên bản mới. Tuy nhiên, như Martijn đã nêu, các thư viện như thế này sẽ chỉ được phát hành cho các phiên bản chính (như phiên bản 3.0) chứ không phải cho các phiên bản nhỏ (như 3.2). Tuy nhiên, giữa 3.0 và 3.2 (hoặc bất kỳ phiên bản nhỏ nào khác), không nên có bất kỳ vấn đề tương thích nào, vì vậy chuyển đổi sang phiên bản 3.0 sẽ ổn.

Ngoài ra, tôi đề nghị bạn nhìn vào câu hỏi này .

Tôi không có nhiều thứ để thêm, "chương trình cho 2 và sử dụng 2to3" dường như là một bổ sung phổ biến trên internet gần đây. Tuy nhiên, có một cái gì đó bạn nên xem xét:

Nó được gọi là sáu (trang pypi) . Đó là một thư viện python dành để giúp viết mã chạy trên cả python 2 & python 3. Tôi đã thấy nó được sử dụng trong một số dự án trong khi lướt qua mạng, nhưng tên này thoát khỏi tôi vào lúc này.