Xây dựng các ứng dụng và framework iOS/macOS lớn, có khả năng mở rộng với Thiết kế theo miền (Domain-Driven Design).
Dành tặng
“Cho mẹ và cha tôi, vì họ thực sự đã cố gắng.”
“Cho cộng đồng, quy tắc số 5 của người hùng thời thơ ấu của tôi – Arnold Schwarzenegger – là: Đừng chỉ nhận, hãy cho đi điều gì đó. Đây là cách tôi cho đi.”
“Cho những đồng nghiệp tuyệt vời của tôi, những người với sự cống hiến và tinh thần làm việc nhóm đã giúp dự án của chúng tôi thành công, để cuốn sách này có thể được viết nên.”
“Và cuối cùng, cho bạn gái hiện tại của tôi… bất kể cô ấy là ai vào thời điểm này.”
Về tác giả
Chào bạn, tôi là Cyril Cermak, một kỹ sư phần mềm đúng nghĩa và cũng là tác giả của cuốn sách này. Phần lớn sự nghiệp của tôi gắn liền với việc xây dựng các ứng dụng và framework cho iOS.
Tôi bắt đầu sự nghiệp chuyên môn tại Skoda Auto Connect App ở Prague, sau đó tiếp tục tại Freelancer Ltd ở Sydney với vai trò xây dựng nền tảng iOS, trải qua nhiều start-up khác nhau, và hiện tại tôi đang là Kiến trúc sư iOS tại Porsche AG, Stuttgart.
Trong cuốn sách này, tôi trình bày các cách tiếp cận khác nhau để xây dựng kiến trúc iOS dạng mô-đun, đồng thời cung cấp những cơ chế và kiến thức cốt lõi giúp bạn lựa chọn phương pháp phù hợp nhất hoặc nên cân nhắc cho dự án của mình.
Về người phản biện
Xin chào, tôi là Kristopher K. Kruger, một người phản biện “tình cờ” nhưng luôn biết ơn sâu sắc khi được tham gia đánh giá cuốn sách này, cả ở phiên bản hiện tại lẫn các phiên bản trước đó.
Hành trình nghề nghiệp của tôi với tư cách là một lập trình viên iOS đã rẽ sang một hướng bất ngờ khi tôi gặp Cyril – người tài ba – trong lúc cả hai cùng tham gia một dự án đột phá. Chúng tôi lần đầu làm việc cùng nhau giữa “cơn lốc” của mã Swift, mã Ruby và các thao tác trên GitHub Actions trong quá trình phát triển dự án nói trên.
Trong cuốn sách này, tôi đã thực hiện một quá trình phản biện kỹ lưỡng – tuy có phần dí dỏm – về kiến trúc iOS dạng mô-đun, đóng góp không chỉ bằng các góc nhìn kỹ thuật mà còn bằng những hiểu biết sâu sắc, đôi khi huyền bí, đúc kết từ kinh nghiệm phong phú và đa dạng của bản thân.
Các bài đánh giá của tôi nổi tiếng với sự kết hợp độc đáo giữa phân tích sắc bén và khiếu hài hước kỳ lạ, bảo đảm rằng ngay cả những chủ đề khô khan nhất cũng có thể khiến bạn bật cười.
Giới thiệu
Trong lĩnh vực kỹ thuật phần mềm, con người thường chuyển từ dự án này sang dự án khác, tích lũy những kinh nghiệm khác nhau. Đặc biệt trong iOS, phần lớn các dự án hiện nay vẫn sử dụng kiến trúc nguyên khối (monolithic). Trong một số trường hợp, điều này hoàn toàn hợp lý và không có gì sai. Tuy nhiên, khi quy mô nhóm phát triển tăng lên – hoặc thậm chí là nhiều nhóm phát triển cùng phối hợp – thì việc duy trì một ứng dụng xây dựng theo kiểu nguyên khối trở nên kinh hoàng, gần như bất khả thi nếu không phải hy sinh đáng kể về thời gian build mỗi ngày.
Rất nhiều vấn đề sẽ phát sinh, làm giới hạn cách thức xây dựng hoặc quản lý các dự án iOS ở cấp độ tổ chức.
Nếu cố gắng mở rộng một ứng dụng nguyên khối với nhóm gồm hơn 10 lập trình viên, khả năng cao bạn sẽ rơi vào “địa ngục”. Ở đây, “địa ngục” là tình huống phải xử lý các lỗi của xcodeproj, nơi mà tệ nhất là cả hai bên đều đổi tên, chỉnh sửa, hoặc xóa cùng một file mã nguồn, hoặc cùng thao tác trên một file {storyboard|xib}. Nghĩa là cả hai cùng làm việc trên một file, dẫn đến xung đột merge kinh điển. Một cách nào đó, chúng ta dần quen với những vấn đề đó và chấp nhận rằng chúng ta phải sống chung với nó.
Điều thật sự tạo bước ngoặt là khi PO/PM/CTO/CEO – hoặc bất kỳ ai “ở trên” bạn trong chuỗi thức ăn của công ty – đến và thông báo rằng họ muốn phát hành một phiên bản mới của ứng dụng, hoặc tách ứng dụng hiện tại thành hai phần riêng biệt. Khi đó, nhóm kỹ thuật phải đưa ra quyết định: tiếp tục với kiến trúc nguyên khối hay áp dụng một hướng đi mới. Nếu tiếp tục với cách cũ, khả năng cao là sẽ tạo thêm các targets mới, phân chia file cho từng phiên bản ứng dụng mới, và tiếp tục sống trong “địa ngục nhân bản”, với hy vọng rằng những yêu cầu như chia sẻ các thành phần lõi cho công ty con hoặc mã nguồn mở dưới dạng framework sẽ không xuất hiện.
Không có gì ngạc nhiên khi giải pháp tốt hơn là bắt đầu tái cấu trúc ứng dụng theo hướng mô-đun, nơi mỗi nhóm chịu trách nhiệm cho một framework (tức là một phần riêng của ứng dụng) và sau đó liên kết chúng lại để tạo nên sản phẩm cuối cùng hướng đến người dùng. Dù việc chuyển đổi không hề dễ dàng và sẽ mất thời gian, nhưng tương lai của kỹ thuật di động trong công ty sẽ nhanh hơn, có khả năng mở rộng tốt hơn, dễ bảo trì hơn, và thậm chí sẵn sàng để phân phối hoặc mã nguồn mở một số SDK ra bên ngoài.
Một tình huống khác có thể là bạn đang làm việc trên một ứng dụng đã được thiết lập theo hướng mô-đun, nhưng lại mất khoảng 20 phút để build vì đó là một mã nguồn cũ khổng lồ đã được phát triển trong suốt mười năm qua và tích hợp gần như tất cả các thư viện bên thứ ba có thể. Quyết định trước đây là mô-đun hóa ứng dụng bằng CocoaPods, vì vậy bạn không thể dễ dàng liên kết các thư viện đã được biên dịch sẵn bằng Carthage, và mỗi lần clean project là một lần bạn có thể tự thưởng cho mình một ly espresso kép. Tôi đã trải qua rồi, tin tôi đi, đó là một kiểu “địa ngục” khác – chắc chắn không phải nơi ai muốn ở lại lâu.
Tôi đã mô tả toàn bộ quá trình chuyển đổi của một dự án như vậy trong một bài viết trên Medium vào năm 2018. Tất nhiên, trong cuốn sách này bạn sẽ đọc được chi tiết hơn về điều đó.
Ngày nay, với vai trò là một Kiến trúc sư hệ thống iOS, tôi thường xuyên nhận được những câu hỏi lặp đi lặp lại từ các nhóm mới hoặc đồng nghiệp mới liên quan đến các chủ đề này. Vì vậy, tôi quyết định tổng hợp lại và cố gắng trình bày toàn diện chủ đề này trong cuốn sách.
Mục tiêu của cuốn sách là giúp các lập trình viên đang làm việc với những kiến trúc như vậy có được kiến thức nền tảng và kinh nghiệm thực tế để có thể triển khai đúng và nhanh hơn những ý tưởng này.
Hy vọng phần giới thiệu này đủ để tạo động lực để bạn muốn khám phá sâu hơn cuốn sách.
Bạn cần gì
Bạn cần phiên bản Xcode mới nhất để biên dịch các ví dụ minh họa, brew để cài đặt một số phụ thuộc bắt buộc, Ruby và bundler để chạy các script và tải xuống một số thư viện Ruby (ruby gems).
Cuốn sách này nói về điều gì
Cuốn sách này trình bày những kiến thức cốt lõi trong việc xây dựng kiến trúc mô-đun trên iOS, và có thể mở rộng sang tất cả các nền tảng của Apple. Bạn sẽ tìm thấy các ví dụ về những cách tiếp cận khác nhau, các loại framework, ưu nhược điểm, các vấn đề thường gặp, v.v.
Kết thúc cuốn sách, bạn sẽ có cái nhìn rõ ràng về những lợi ích mà kiến trúc mô-đun mang lại cho dự án của bạn, liệu nó có thực sự cần thiết hay không, và hướng tiếp cận nào là phù hợp nhất để áp dụng mô-đun hóa vào dự án. Cuốn sách tập trung vào kiến trúc ở mức cao, cách mô-đun hóa một dự án, và cách cộng tác để đạt hiệu quả tối ưu nhất.
Cuốn sách này không nói về
SwiftUI.
