Bạn đã hoàn thành một khóa học, xem một loạt video trên YouTube hoặc đọc một loạt bài viết về phát triển iOS và bây giờ bạn cảm thấy sẵn sàng viết dự án thú cưng đầu tiên của mình.

Thứ nhất, làm tốt lắm! Điều đó thật tuyệt vời. Bạn thật tuyệt! 💪

Thứ hai, một dự án thú cưng là một sự thúc đẩy tuyệt vời cho kỹ năng của bạn. Khi bạn bắt đầu tự mình làm một việc gì đó mà không làm theo hướng dẫn - bạn phải tốn rất nhiều thời gian và công sức, tra Google rất nhiều, đọc rất nhiều thông tin mới, cố gắng lọc và đưa nó vào trường hợp của bạn một cách chính xác. Nói tóm lại, đó đã là một nhiệm vụ thực sự sẽ thúc đẩy bạn gấp năm lần.

Tuy nhiên, hầu hết những người mới bắt đầu đều bỏ qua những điều quan trọng (không phải nằm ngoài sáng kiến của họ mà không hiểu tầm quan trọng của chúng). Trong sáu tháng qua, tôi đã tích cực và giúp đỡ những người mới đến giải đáp các thắc mắc và vấn đề của họ, bao gồm cả các dự án thú cưng.

Tôi đã xác định được 3 điểm hàng đầu mà bạn, với tư cách là người mới bắt đầu, nên đưa vào danh sách phải có, nắm vững, hiểu và sử dụng.

Cấp độ truy cập

Lúc đầu, hầu như không ai chú ý đến công cụ sửa đổi private . Trong khi đó, mọi người đều có thể giải thích ngay lập tức về SOLID nếu bạn đánh thức họ vào lúc nửa đêm. Sau khi đọc nhiều bài báo thông minh khác nhau, mọi người cố gắng tạo ra một loạt các lớp theo ý tưởng S (trách nhiệm duy nhất).

Và sau đó, với lương tâm trong sáng, họ đổi thuộc tính của class A từ class B và ngược lại.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

Nói chung, nếu vẫn chưa rõ ràng, thì đây là kế hoạch: luôn viết private ở mọi nơi và khi trình biên dịch phàn nàn - hãy nghĩ xem, truy cập thuộc tính hoặc chức năng này từ bên ngoài có được không? Và nếu có - hãy xóa private .

Khi bạn suy nghĩ, hãy hướng dẫn bản thân bằng những so sánh trong thế giới thực. Ví dụ: nếu lớp của bạn là một cửa hàng thì khách hàng bên ngoài rõ ràng phải có thể truy cập được thuộc tính goods . Nhưng moneyInCashRegister rõ ràng chỉ có thể được thay đổi bởi nhân viên cửa hàng nội bộ.

Rốt cuộc, khách hàng không nên có quyền truy cập vào máy tính tiền, ngay cả với put , chứ đừng fetch .

Người ta có thể lập luận, “Tôi hiểu rất rõ tài sản nào có thể được chạm vào và tài sản nào thậm chí không thể chạm vào nếu không có công cụ sửa đổi private ”. Tuy nhiên, việc viết các công cụ sửa đổi cấp độ truy cập là một phần của thiết kế. Tôi chắc chắn rằng bạn sẽ không tạo ra bản thiết kế cho một ngôi nhà có cửa trên tầng ba dẫn ra ngoài.

Và sau đó, hãy nhớ đừng mở nó. Suy cho cùng, rất có thể những người khác cũng sẽ sử dụng mã của bạn.

Nhân tiện, tình huống tương tự cũng tồn tại với var và let . Một lần nữa, hãy luôn sử dụng let trừ khi bạn chắc chắn ngay rằng mình sẽ thay đổi giá trị.

Kiến trúc đơn giản

Tôi nhận thấy xu hướng những người mới bắt đầu cố gắng lên kế hoạch trước cho mọi thứ. Mặc dù điều này rất đáng khen ngợi nhưng các nhà phát triển vẫn thường mắc sai lầm do thiếu kinh nghiệm. Họ chuẩn bị trước những nhà quản lý quá phức tạp (thường được sao chép từ ) với nhiều phương pháp phức tạp mà cuối cùng họ không bao giờ sử dụng. Kết quả là số lượng và độ phức tạp của mã tăng lên.

Thay vì những gì có vẻ như là một dịch vụ tiện lợi, có sẵn, lập trình viên của chúng tôi lại chỉ gặp phải những vấn đề và hiểu lầm. Kiến trúc cũng vậy.

Hãy để tôi kể ngắn gọn cho bạn về lịch sử lập trình để truyền đạt quan điểm của tôi. Vào cuối những năm 1960, khi việc lập trình bắt đầu trở nên phổ biến, quy mô của các chương trình cũng tăng lên. Như bạn có thể hiểu, kích thước chương trình lớn hơn có nghĩa là nhiều dòng mã hơn, dẫn đến độ phức tạp và khó hiểu chương trình tăng lên.

Để giải quyết vấn đề này, lập trình có cấu trúc đã xuất hiện - các chức năng và quy trình cho phép chia chương trình thành các phần nhỏ hơn, dễ quản lý hơn. Mã đã trở thành mô-đun, có thể tái sử dụng và dễ hiểu hơn.

Sự ra đời của cơ cấu đã dẫn đến sự phát triển hơn nữa trong các chương trình cho đến khi chúng đạt đến giới hạn về quy mô và độ phức tạp một lần nữa. Vì vậy, đến cuối những năm 1970, đầu những năm 1980, phương pháp lập trình hướng đối tượng đã hình thành. Giải pháp này cho phép tạo ra các hệ thống linh hoạt và có thể mở rộng, giải quyết các nhiệm vụ ngày càng phức tạp.

Trong thập kỷ tiếp theo, chúng ta chứng kiến sự bùng nổ của trò chơi máy tính. Phản ứng đối với hành động của người dùng (nhấp chuột, nhấn) hóa ra là rất quan trọng, dẫn đến sự xuất hiện của Lập trình hướng sự kiện.

Và để tổ chức mã trong các ứng dụng web và máy tính để bàn - khi cùng một dữ liệu cần được sắp xếp lại từ các góc độ khác nhau - đã xuất hiện mẫu MVC (tức là tách mô hình khỏi biểu diễn trực quan của nó).

Bạn đã nắm được ý chính: một vấn đề nảy sinh, -> một giải pháp xuất hiện. Vấn đề -> Giải pháp.

Vậy tại sao các lập trình viên mới bắt đầu bắt đầu áp dụng các giải pháp (kiến trúc) vào thời điểm mà các vấn đề vẫn chưa phát sinh? Hướng dẫn ngay lập tức đề xuất chọn ít nhất một MVP. Nhiệm vụ kiểm tra cho một/hai màn hình luôn chỉ định KHÔNG sử dụng MVC.

Trong các cuộc phỏng vấn, một người đã viết một vài dự án thú vị với một/hai màn hình giống nhau sẽ được hỏi về các vấn đề VIPER. Làm sao anh ta có thể biết về những vấn đề nếu anh ta chưa gặp phải chúng?

Mọi người thường nói về sự tiện lợi của khả năng kiểm thử trong bối cảnh kiến trúc, nhưng họ chưa bao giờ viết bài kiểm thử. Và nếu có, thì nó chỉ dựa trên một số hướng dẫn, chỉ tập trung vào các bài kiểm tra đơn vị mà không ràng buộc chúng với một ứng dụng thực tế.

Họ có thể giải thích sơ đồ MVP bằng những thuật ngữ đơn giản, nhưng họ thường bị nhầm lẫn khi nói đến các giao thức có tên tương tự, như ViewInput và ViewOutput . Trong sâu thẳm, họ đã coi tất cả những điều này chỉ là chi phí chung 🙄🤯

Kết luận: Đừng tạo ra vấn đề cho chính mình. Đừng xấu hổ về MVC. Khi bộ điều khiển của bạn phát triển quá lớn hoặc bạn gặp phải những bất tiện, bạn sẽ hiểu rằng đã đến lúc phải tìm kiếm những cách tiếp cận mới.

Giao diện người dùng đơn giản

Phát triển front-end là thiên đường dopamine cho người mới bắt đầu. Bạn viết mã và ngay lập tức thấy kết quả trên màn hình — nhận phần thưởng 🍭. Không thể phủ nhận đó là động lực. Tuy nhiên, có một mặt trái của đồng tiền này. Những người mới bắt đầu thường cố gắng tạo giao diện người dùng quá phức tạp ngay lập tức.

Hơn nữa, các tính năng phức tạp có xu hướng tuân theo giao diện người dùng phức tạp. Mặc dù SwiftUI ngày nay đã đơn giản hóa công việc, nhưng người ta vẫn có thể mất nhiều thời gian để thêm chuông và còi mà không đạt được tiến bộ thực sự.

Tôi đã học phát triển iOS trong một khóa học nơi chúng tôi thành lập nhóm và làm việc trên một dự án duy nhất. Trong nhóm của tôi, một anh chàng đề xuất bắt đầu phát triển ứng dụng của chúng tôi bằng cách chọn phông chữ và màu sắc cho chế độ tối.

Nhìn chung, anh ấy đã dành toàn bộ khóa học cho nó và điều đáng chú ý là phông chữ và màu sắc trở nên tuyệt vời. Tuy nhiên, anh chàng này đã viết gần như không có dòng mã thực tế nào trong suốt thời gian đó.

Không còn nghi ngờ gì nữa, vẻ đẹp và chức năng của ứng dụng của bạn là rất quan trọng. Cuối cùng, bạn sẽ phải dành thời gian cho khía cạnh này. Sẽ tốt hơn nếu bắt đầu với điều gì đó đơn giản hơn. Phát triển MVP (sản phẩm khả thi tối thiểu), tập trung vào các tính năng quan trọng nhất và khởi chạy từ đó.

Các áp dụng ở đây — tạo nền tảng của ứng dụng, sau đó thêm các tính năng bổ sung. Cách tiếp cận ngược lại sẽ dẫn đến việc phải vật lộn với các sắc thái phức tạp và liên tục phải xử lý một chức năng chính liên tục bị hỏng.

---

Đối với những người mới tham gia phát triển di động, có nguy cơ áp dụng sớm các giải pháp phức tạp. Mặc dù phần thưởng trực quan của việc phát triển front-end có thể hấp dẫn, nhưng bắt đầu với một MVP đơn giản thường sẽ khôn ngoan hơn.

Xu hướng lịch sử cho thấy các giải pháp nên phát triển để đáp ứng những thách thức thực sự.

Hiểu các nguyên tắc cơ bản và giải quyết các vấn đề trong thế giới thực khi chúng phát sinh là rất quan trọng để phát triển hiệu quả.

---

Cũng được xuất bản