AppCode đã kết thúc. Tuy nhiên, AI còn gì để thay thế? Nếu bạn đã xem bất kỳ video lập trình trực tiếp nào của tôi, bạn sẽ biết rằng AppCode là IDE ưa thích của tôi cho Swift. Có rất ít công việc (chẳng hạn như thay đổi cài đặt dự án) mà tôi thích Xcode hơn. Nhưng đối với việc viết mã, không có sự cạnh tranh nào. Và với sự thêm vào của Inline refactorings, quá trình viết mã Swift của tôi còn nhanh hơn nữa. Nhưng khi JetBrains thông báo về bản cập nhật mới nhất của AppCode, họ đã gây sốc khi cho biết đây cũng là bản cập nhật cuối cùng của họ. Họ sẽ cung cấp các bản cập nhật tối thiểu để đảm bảo tương thích và bảo mật đến cuối năm 2023. Và rồi, kết thúc. Tôi cảm thấy chán nản.
Tại sao AppCode chết?
Swift một mình đã gần như chết chống lại AppCode. Nhưng tôi nghĩ SwiftUI đã gây đòn chí mạng cuối cùng. Hãy nhớ trước thời Swift? Objective-C là công cụ cho việc làm việc với hầu hết mọi thứ trong hệ sinh thái Apple. Hãy nhớ, Objective-C đã xuất hiện từ thập kỷ 1980. Một sự chuyển đổi lớn sang Objective-C 2.0 đã diễn ra vào năm 2007. Bạn vẫn có thể xây dựng dự án Objective-C cũ ngày nay, mà không cần thay đổi gì. Mặc dù người dùng AppCode chỉ chiếm một số ít trong số đó, một số đồng nghiệp của tôi đã sử dụng nó ít nhất là đôi khi. Điều đó là vì so với Xcode, hỗ trợ tự động refactor của nó mạnh hơn. Rồi Swift xuất hiện. ngôn ngữ lập trình mới này có kiểu dữ liệu chặt chẽ, với nhiều cú pháp hơn. JetBrains, nhà sản xuất của AppCode, bỗng dưng bị bỏ lại với một IDE không hoạt động với phát triển Apple hiện đại. Vì vậy, họ phải đuổi kịp bằng cách thêm hỗ trợ Swift cơ bản. Nhưng Swift là một con vật nặng nề về hiệu suất. Sự tiện ích của AppCode đã bị ảnh hưởng và đồng nghiệp của tôi ngừng sử dụng nó. Và đây không chỉ là sự hỗ trợ cho một ngôn ngữ duy nhất. Chúng tôi cũng cần hỗ trợ đa ngôn ngữ: Swift gọi Objective-C và Objective-C gọi Swift. Các tính năng của AppCode đã bị ảnh hưởng khi vượt qua ranh giới ngôn ngữ này, vì một IDE tốt trả lời những câu hỏi cơ bản sau:
- Thứ này được định nghĩa ở đâu?
- Thứ này được sử dụng ở đâu?
- Thứ này không được sử dụng? Trên ranh giới ngôn ngữ này, câu trả lời đôi khi không đầy đủ - và do đó sai. Từ quan điểm của một người lập trình viên , những tính năng Objective-C đáng tin cậy đã trở nên tồi tệ hơn. Vì vậy, đây là một vấn đề tiếp theo mà JetBrains phải giải quyết. Ngay cả khi họ làm điều này, Apple tiếp tục thay đổi để cải thiện cú pháp với các quy tắc chuyển đổi đặc biệt, mà AppCode phải thêm vào (sau khi đã hoàn thành). Nhưng qua một số phiên bản, AppCode đã cải thiện cả về hiệu suất và độ tin cậy. Nó đã trở thành một công cụ có thể sử dụng trong các dự án thực tế. Tôi đã nói với đồng nghiệp của mình: "Bạn có thể trở lại ngay bây giờ, nó xử lý Swift rất tốt." Nhưng họ không trở lại. Rồi Swift trở thành mã nguồn mở.
SwiftUI đã làm hai việc. Đầu tiên, nó đã tăng tốc các thay đổi cho Swift, bổ sung tính năng và cú pháp mà SwiftUI cần. Nhưng cũng có thêm Xcode's built-in Preview (xem trước giao diện người dùng) đã làm Xcode trở nên hấp dẫn hơn đối với SwiftUI. JetBrains đã đăng một bài viết chỉ ra cách sử dụng InjectionIII để xem các bố cục SwiftUI của bạn mà không cần Xcode. Nhưng InjectionIII là một thư viện của bên thứ ba - đó là sự cản trở để ngăn các nhà phát triển chấp nhận AppCode. Với JetBrains, chi phí phát triển AppCode tiếp tục tăng lên, trong khi doanh thu giảm đi. Kết thúc trò chơi.
Refactorings Swift chúng ta sẽ không bao giờ thấy trong AppCode
Với sự kết thúc phát triển AppCode, có các refactorings chúng tôi có cho Objective-C mà chúng tôi sẽ không bao giờ thấy cho Swift. Các refactorings này bao gồm:
- Giới thiệu tham số (di chuyển định nghĩa biến vào chữ ký)
- Trích xuất superclass
- Trích xuất subclass
- Kéo thành viên lên (thuộc tính hoặc phương thức)
- Đẩy thành viên xuống
- Di chuyển thành viên sang một loại khác (hiện có hoặc mới). Điều này kiểm tra xem những thành viên đã tham chiếu cũng nên di chuyển.
- Xóa các import không sử dụng Tôi đã viết ở trên, "So với Xcode, sự hỗ trợ cho việc refactor tự động của nó mạnh hơn." Trước khi AppCode kết thúc, điều này chỉ đúng với Swift. Nhưng việc refactor Swift vẫn chỉ là một mảnh mỏng trong những gì nó có thể làm với Objective-C. Và bạn biết không? Sự refactor Objective-C mạnh mẽ chính nó cũng chỉ là một mảnh mỏng của những gì bạn có thể làm trong các IDE khác của họ, đặc biệt là IntelliJ. Tôi đau lòng vì những gì đã có thể xảy ra.
Tương lai của Refactoring và Code Generation trong Swift là gì?
Vậy bây giờ thì sao? Tôi đoán rằng hầu hết các nhà phát triển trong hệ sinh thái Apple chỉ từng làm việc trên Xcode. Không có yêu cầu cần cải thiện công cụ. Liệu những nhà phát triển Apple có tiếp tục thiếu kiến thức về refactor tự động hoặc sinh mã từ điểm gọi không? Tôi chắc chắn hy vọng không. Có hai cách để giải quyết vấn đề này. Một cách là Apple làm việc chăm chỉ để cải thiện việc refactor trong các công cụ của họ. Điều này sẽ có nghĩa là:
- Cải thiện các refactorings hiện tại chỉ là đủ (nếu chúng thực sự hoạt động)
- Thêm các refactorings mới
- Cung cấp chúng trong một cửa sổ pop-up được kích hoạt bằng bàn phím thay vì truy cập chậm chạp bằng chuột
Nhưng với sự chống đối của Apple với các quy tắc lập trình tốt (và thiếu kiến thức về các ý tưởng bên ngoài hệ sinh thái của họ), khả năng thành công nhỏ. Và những thay đổi ít ỏi mà họ mang lại chỉ xảy ra mỗi năm một lần.
Nhưng họ không phải là người chơi duy nhất. Còn nhớ cách Swift trở thành mã nguồn mở không?
Chúng ta có cơ hội để cộng đồng mã nguồn mở phản hồi. Hiện đã có một plugin Swift chính thức cho IDE VSCode. Mặc dù vẫn còn ở giai đoạn đầu, điều này xứng đáng được theo dõi.
Làm thế nào nếu cộng đồng tụ họp để tạo ra:
- Một cách chuyển đổi mã nguồn Swift thành cây cấu trúc cú pháp trừu tượng (AST)
- Một cách chuyển đổi cây cấu trúc cú pháp trừu tượng trở lại mã nguồn Swift
- Những biến đổi giữ nguyên hành vi của cây cấu trúc cú pháp trừu tượng
Có lẽ đã đến lúc các nhà phát triển đòi lại quyền tạo công cụ trong hệ sinh thái Apple và để Apple bắt kịp.
Bạn có biết những công cụ để refactor mã nguồn Swift, hoặc tạo ra code mới từ điểm gọi? Xin hãy chia sẻ bất kỳ công cụ nào trong phần bình luận dưới đây.
