Có rất nhiều yếu tố cần cân nhắc mỗi khi bắt đầu 1 dự án mới nên việc lựa chọn Objecitve-C hay Swift không phải là quyết định rõ ràng. Vì đây là 1 trong những câu hỏi phổ biến nhất trong giới lập trình iOS nên chúng ta đã quyết định đưa ra nhiều khía cạnh đa dạng để bàn thảo chủ đề này lần cuối.
Nên nhớ rằng, không có luận điểm nào đóng vai trò chính trong quyết định của bạn. Quyết định của bạn chỉ đến ngay sau khi đã cân đo đong đếm các yếu tố sau:
Kinh nghiệm với Objective-C vs Swift
Điểm đầu tiên chính là kinh nghiệm hiện tại của bạn. Nếu bạn có kinh nghiệm tương đương với cả hai ngôn ngữ thì lựa chọn ngôn ngữ sẽ phụ thuộc vào các yếu tố khác sẽ được liệt kê bên dưới như: khả năng tương thích thư viên với bên thứ 3, hỗ trợ API, các thành viên trong team…
Ngược lại, nếu chỉ biết 1 trong 2 ngôn ngữ và các yêu cầu của dự án hoặc của team không phản đối, hãy chọn ngôn ngữ mà bạn đã quen thuộc nếu . Tất nhiên, nếu lựa chọn ngôn ngữ không quen thuộc để làm app thì bạn sẽ có cơ hội để tìm hiểu về ngôn ngữ đó, nhưng khả năng cao là bạn sẽ gánh technical debt – món nợ kỹ thuật (trong lập trình, đôi khi ta chọn cách giải quyết “mì ăn liền”, giải quyết được vấn đề ngay, nhưng sẽ gây khó khăn cho quá trình phát triển và bảo trì về sau. Techinical Debt tích lũy sẽ gây ra nhiều hậu quả nguy hiểm khôn lường) hoặc làm chậm trễ tiến độ dự án.
Đôi khi bạn gặp tình huống như đang xây ngôi nhà trên cát mà không khả năng tái cấu trúc nào có thể cứu vãn nổi. Nói cách khác, “món nợ kỹ thuật” ban đầu này sẽ khiến bạn không còn sự lựa chọn nào khác ngoài việc viết lại ứng dụng từ đầu.
Mặt khác, nếu bạn quyết định tạo 1 prototype – thử nghiệm cho production app của mình, bạn có thể lập trình với ngôn ngữ mà bản thân ít quen thuộc nhất. Cách này giúp bạn làm quen với ngôn ngữ mới, hỗ trợ production app vì bạn sẽ tiếp cận ứng dụng, tiếp cận các tính năng và giải quyết các vấn đề của nó từ 2 góc độ insight.
Khung thời gian, phạm vi và scale của dự án
Trước tiên hãy xem các yêu cầu và ràng buộc đặc biệt trong dự án. Kinh nghiệm của bạn, các thành viên trong nhóm, quy mô dự án sẽ giúp bạn nghiêng về 1 trong 2 ngôn ngữ.
► Khung thời gian
Lập trình production apps trong 1 ngôn ngữ bạn chưa quen thuộc sẽ dẫn đến các món nợ kỹ thuật lớn. Món nợ này phải được nỗ lực trả đúng hạn. Nếu timeline gấp gáp, bạn sẽ phải chọn ngôn ngữ mình có nhiều kinh nghiệm hơn. Trong trường hợp bạn chưa có kinh nghiệm gì nhiều, hãy chọn Swift.
Nếu bạn có lịch trình nhẹ nhàng, bạn có thể cân nhắc lập trình ngôn ngữ mà bạn chưa biết gì hết (để học hỏi thêm). Và nếu bạn vô tình rơi vào dự án “bí ẩn” không có timeline cố định, bạn chắc chắn nên chọn ngôn ngữ mà mình hoàn toàn không biết. Đây là cơ hội vàng, không thường xuyên có được trong sự nghiệp của bạn để tối ưu hóa khả năng mở rộng ngôn ngữ và nâng cấp cuộc chơi.
► Đội ngũ làm app
So với các vấn đề về kĩ thuật, đây là 1 topic thường bị bỏ qua nhưng đáng lẽ ra không nên như vậy. Bạn cần nói chuyện với đội ngũ của mình trước khi đưa ra các quyết định lựa chọn ngôn ngữ – dù cho bạn đang làm việc trong vùng codebase độc lập.
Ví dụ, nếu bạn đang làm trong 1 công ty với đội ngũ dev Objective-C có nhiều năm kinh nghiệm? Nếu bạn bắt đầu với Swift mà cả đội ngũ vẫn chưa hoàn toàn làm quen với nó thì cũng không phải là ý kiến tốt. Dù cho bạn có đủ lý do, khả năng tranh luận và dự báo mọi thứ đi nữa thì bạn cũng không nên đi 1 mình với ngôn ngữ riêng. Xung đột đội ngũ có thể dẫn đến các hậu quả tệ hai và cuối cùng, chẳng ai chiến thắng cả. Miễn là bạn chịu lắng nghe các thành viên và làm theo 1 kế hoạch dân chủ thì tất cả sẽ ổn.
► Phạm vi dự án
Các dự án nhỏ có quyền lựa chọn được ngôn ngữ phù hợp vì những chi phí phát sinh khi chuyển đổi code Swift nếu có thay đổi là không đáng kể. Mặc khác, các dự án lớn cần phải cẩn trọng khi tiếp nhận ngôn ngữ này. Swift vẫn chưa hoàn thiện và mỗi phiên bản (thậm chí là các phiên bản nhỏ) có thể kéo theo hàng loạt thứ chuyển đổi liên quan đến syntax và cách diễn đạt mới. Không ai lại muốn code của mình bị phá vỡ chỉ trong vài ngày mỗi khi phiên bản Swift mới ra mắt. Hoặc tệ hơn, trở thành lập trình viên suốt ngày đi giải thích với cấp quản lý hoặc các bên liên quan lý do tại sao code bị hỏng.
Xcode cung cấp các công cụ chuyển đổi Swift x code thành Swift x+1. Tuy nhiên, các công cụ lại không nắm bắt được hết mọi thứ. Đây không phải điều gì tồi tệ với đội ngũ Xcode vì đơn giản, 1 vài thay đổi liên quan đến ngôn ngữ gần như không thể tự động chuyển đổi nếu không hiểu rõ context đằng sau các dòng code đó.
Các mối bận tâm về kỹ thuật
Tự bản thân 2 ngôn ngữ Objective-C và Swift đã có rất nhiều ưu điểm kỹ thuật khác nhau.
► Hỗ trợ Tooling
Team Xcode đã cập nhật thành công quy trình lập trình để hỗ trợ Swift. Họ đã hoàn thiện được 1 ngôn ngữ phức tạp và hỗ trợ nó làm việc với 1 ngôn ngữ hoàn toàn khác (Objective-C). Thậm chí IDE còn chậm trễ và khả năng hỗ trợ tooling cho Swift cũng không đáng kể. Thỉnh thoảng, bạn may mắn có được syntax highlighting. Đôi khi, bạn vẫn code tiếp mà không autocomplete được. Và các công cụ refactoring lại không hoạt động. Nếu bạn muốn được hỗ trợ mạnh mẽ bởi các IDE hiện đại, bạn nên làm việc với Objective-C hoặc xem xét các IDEs khác.
► Runtime
Runtime của Objective-C mạnh mẽ hơn Swift. Trong những năm tới, runtime của Swift nhiều khả năng vẫn không bắt kịp được Objective-C. Nếu bạn đang có kế hoạch viết code để tận dụng reflection và nội quan (introspection) của các đối tượng và các types (thường xuất hiện ở các SDKs mạnh, nhưng thỉnh thoảng cũng có trong các ứng dụng thông thường), thì Objective-C rất vô dụng. Nếu bạn không hiểu câu vừa rồi đang đề cập đến vấn đề gì thì bạn nên bắt đầu với Swift.
► Tính ổn định của code
Swift là 1 ngôn ngữ lập trình an toàn, nhờ hệ thống typing và khắc phục lỗi mạnh mẽ. Nếu bạn đang nghiên cứu idiomatic và muốn tránh các operators ! trong code, chắc chắn không ít thì nhiều code của bạn cũng sẽ gặp những trường hợp lỗi tiềm tàng. Rò rỉ bộ nhớ từ 1 retain cycle là 1 ví dụ thường thấy trong code Swift và Objective-C. Lý do là vì hệ thống quản lý bộ nhớ tự đông (automatic reference counting system) không thay đổi.
► Làm việc với Foundation APIs
Nếu ứng dụng của bạn chủ yếu sử dụng foundation APIs (như CoreFoundation, AVFoundation và CoreAnimation), bạn nên nghiêng về phương án Objective-C. Swift có các wrappers bền vững và giúp quản lý bộ nhớ mượt mà hơn, như đây vẫn là những function calls dựa trên C APIs và C, nên sẽ tự động tương thích với Objective-C codebase.
► Dùng code C++
Tương tự như Foundation APIs, sử dụng các thư viện C++ hoặc lập trình trên nền tảng chéo C++ SDK sẽ tự thích ứng với dự án Objective-C. Bạn không thể nhập C++ vào các file Swift. Để dùng được Swift, bạn phải trải qua nhiệm vụ buồn chán, mệt mỏi, thường phải gặp bug là tạo wrapper classes Objective-C hoặc Objective-C++. Bạn phải bắt cầu, bổ sung thêm mỗi lần muốn dùng 1 phần khác của 1 thư viện C++. Nếu bạn định tận dụng C++ thì Objective-C sẽ phù hợp hơn.
► Phiên bản hệ thống vận hành
Swift chạy trên iOS 7+, Mac OS 10.9+ và tất cả các phiên bản của tvOS và watchOS. Nếu dự án cần hỗ trợ hệ điều hành thấp hơn, thì bạn không có lựa chọn nào khác ngoài việc sử dụng Objective-C.
► Bằng chứng cho tương lai (Future-proofing)
Hầu hết các dự án bảo chứng cho tương lai đều được viết bằng Swift. Trong 2 năm trở lại đây, việc sử dụng Swift đã mở rộng sang 1/3 các dự án Cocoa nguồn mở. Với tốc độ này, trong 4 năm tới, số lượng dự án Cocoa nguồn mở dùng Swift sẽ bằng với Objective-C. Thêm nữa, hầu hết các tutorials, blogs mới đều đã được viết bằng Swift. Chúng tôi tin rằng 5-10 năm nữa sẽ có đủ thông tin Swift để các dev không nhất thiết phải biết về Objective-C nữa. Vì vậy, bạn có đủ thời gian để chuyển đổi code trước khi vai trò của Objective-C phai mờ đi.
Phần bổ sung: Bạn có nên chuyển dự án Objective-C hiện tại sang Swift?
Trước khi trả lời câu hỏi này, bạn cần hiểu được tại sao nên sử dụng cả Swift và Objective-C trong dự án. Concept này có tên gọi là “bridging”. Khi bạn thêm 1 file Swift vào dự án Objective-C, Xcode sẽ tạo “bridging header file”, không khác gì với headers Objective-C thông thường, trừ trường hợp bạn chỉ sử dụng nó để nhập headers ObjectiveC mà bạn muốn thể hiện trong code Swift của bạn. Xcode sẽ tự động tạo headers kết nối tất cả code Swift với Objective-C. Bạn có thể sử dụng chức năng này bằng cách thêm 1 dòng ModuleName-Swift.h (ví dụ: Mail-Swift.h nếu đang làm việc với dự án tên là Mail) vào những nơi bạn muốn dùng code Swift trong các file Objective-C.
Điều tiếp theo cần để tâm là quy mô dự án. Một dự án lớn sẽ không phù hợp với việc bridging, vì code Objective-C thường bị rò rỉ trừu tượng (leaky abstractions) nên code Swift ít có đặc tính rõ rệt hơn. Ví dụ, nếu bạn có 1 protocol mở rộng NSObjectProtocol để sử dụng Objective-C runtime trong các đối tượng thực thi protocol, Swift class thực thi protocol sẽ phải thừa hưởng NSObject hoặc class khác trong phân cấp NSObject. Hỗ trợ Objective-C runtime như thế này sẽ khiến hiệu suất hoạt động của các method calls bị chậm đi 4 lần (vì nó sử dụng dynamic dispatch thay vì static). Một dự án quy mô nhỏ có thể phối hợp code Objective-C mượt mà hơn so với 1 dự án lớn. Tuy nhiên, kinh nghiệm cho thấy, cuối cùng thì bạn sẽ muốn chuyển đổi code hiện tại sang Swift và 1 dự án nhỏ rốt cuộc cũng sẽ trở thành 1 danh sách to-do-list của code Objective-C mà bạn muốn chuyển sang Swift.
Những vấn đề khác gồm thành viên của nhóm và độ cấp thiết của dự án. Nếu đang làm việc với 1 team, thì bạn cần có được sự đồng thuận trước khi làm phức tạp thêm mọi thứ bằng cách bridging 1 dự án Objective-C sang Swift. Nếu đang bắt đầu viết Swift mà không có team buy-in (được hiểu là 1 hình thức có sự review và đồng ý của team), bạn sẽ được gắn mác là 1 cowboy coder và nhanh chóng phải kiếm công việc mới. Ngoài ra, bridging code cũng là vấn đề nhức nhối hơn những gì bạn nghĩ. Nếu 1 dự án khẩn cấp hoặc có deadline cố định, hãy chọn Objective-C. Trái lại, hãy bắt đầu code với Swift.
Kết
Trên đây là những yếu tố thông thường mà các dev cần xem xét trước khi chọn Objective-C hay Swift cho dự án mới và dự án hiện tại của mình. Tất nhiên, dự án của bạn có thể sẽ có những vấn đề không giống so với nhiều dự án khác. Nhưng 2 điểm mà bạn cần lưu ý nhất chính là: thực trạng của dự án và quyết định của các thành viên trong team.
Nguồn: IDE Academy via SavvyApps
