iOS Dev cần biết những gì để thực hiện công việc hàng ngày? (P1)

Thảo luận trong 'iOS' bắt đầu bởi nhatlectv, 3/2/18.

  1. nhatlectv

    nhatlectv Stanford - Nâng tầm tri thức Thành viên BQT

    Để công việc của một iOS dev diễn ra suôn sẻ ngày qua ngày, bài viết dưới đây liệt kê các topic mà mỗi iOS dev bình thường nhất cần phải nắm rõ.
    Topic bao gồm:

    [Source Control | Architecture Patterns | Objective-C vs Swift | React | Dependency Manager | Storing Information | CollectionViews & TableViews | UI | Protocols | Closures | Schemes | Tests | Location | Localizable Strings]

    1. Soure Control

    Mỗi dự án đều luôn cần phải có Source Control, thậm chí nó vẫn cần thiết nếu chỉ có một dev phát triển nó. Hầu hết các dự án đều sử dụng GIT hoặc SVN.
    SVN dựa vào hệ thống tập trung để quản lý phiên bản mã nguồn. Đây được coi là kho lưu trữ tập trung, nơi mà các bản sao làm việc được tạo ra và được phép truy cập từ xa bằng cách uỷ quyền quyền truy cập thông qua một URL. Đồng thời cho phép theo dõi sự thay đổi mã nguồn bằng cách đăng ký từng file trong kho lưu trữ (repository). Phiên bản làm việc được phải là phiên bản mới nhất.
    Tool SVN phổ biến nhất mà dev hay dùng là bản Mac Subversion Client

    GIT, ngược lại, là dựa vào hệ thống phân tán để quản lý phiên bản mã nguồn. Giả sử là bạn có một bản lưu trữ mã nguồn dưới local, là mã nguồn mà bạn đang làm việc trực tiếp, với kết nối mạng khi cần yêu cầu đồng bộ. Việc uỷ quyền truy cập là cho cả kho lưu trữ, theo dõi thay đổi mã nguồn bằng cách đăng ký nội dung, bao gồm cả repository.

    2. Architecture patterns
    Công việc lập trình cũng giống như việc xây nhà, đầu tiên chúng ta cần phải biết kiến trúc chúng ta định xây là gì, hoặc là sửa nhà cũng thế, cũng cần phải biết kiến trúc của nó, nên sửa chỗ nào, đập chỗ nào mà không ảnh hưởng/phá vỡ kiến trúc tổng thế của nó.
    Khi bắt đầu được giao việc, sau khi lấy source code về, chúng ta cần tìm hiểu xem mã nguồn dự án đang được build theo pattern nào. Trong các ứng dụng mobile phổ biến hay dùng các pattern như là MCV, MVP, MVVM, VIPER, v.v… Tôi sẽ liệt kê dưới đây tổng quan chung chung về các pattern phổ biến này.

    • MVC – Tức là Model, View, Controller. Controller sẽ tạo ra “cầu nối” giữa Model và View. Mối quan hệ giữa View và Controller khá là chặt chẽ, do đó, Controller phải kết thúc xử lý khá nhiều vấn đề. Có nghĩa là, khi bạn build một view phức tạp, Controller có thể sẽ dẫn đến tình trạng mất kiểm soát vì phải xử lý quá nhiều thứ. Có nhiều cách để phá vỡ điều này, nhưng lại không tuân theo luật của MVC. Một nhược điểm khác của MVC là vấn đề kiểm thử. Nếu bạn phải thực hiện test, bạn chỉ có thể thực hiện test với Model, vì nó là phần duy nhất tách biệt với các phần còn lại. Điểm cộng của việc sử dụng MVC là nó có tính trực quan, dễ hiểu, dễ sử dụng với hầu hết các iOS dev bình thường.[​IMG]
    • MVVM – Tức là Model, View, ViewModel. Kỹ thuật binding (cơ chế ràng buộc data – ý tưởng cơ bản trong lập trình reactive) sẽ được thiết lập giữa View và ViewModel, nó cho phép ViewModel thực thi thay đổi tới Model, sau đó lại update lại ViewModel, và tự động update lên View theo cơ chế bindings. Thành phần ViewModel sẽ không hay biết gì về View. Điều này là điểm cộng khi thực hiện Unit-test và cơ chế binding nhằm giảm thiểu khá nhiều dòng code.[​IMG]
    • Việc cấu trúc và tổ chức code tốt giúp dev đỡ đau đầu, đỡ mất thời gian debug để tìm luồng xử lý. Một lỗi lớn của dev là commit một vài đoạn code để cố hoàn thành kết quả nhìn thấy được mà quên đi phải tổ chức code theo pattern ban đầu đã chỉ định.
    3. Objective-C hay Swift?
    Khi mà bạn phải quyết định lựa chọn ngôn ngữ nào để build ứng dụng, bạn cần phải biết mỗi ngôn ngữ thì có ưu nhược điểm gì? Theo ý kiến cá nhân, tôi muốn dùng Swift hơn cả. Tại sao vậy? Thực lòng mà nói, Objective-C có nhiều ưu điểm hơn Swift.

    Swift là ngôn ngữ có nhiều cải tiến hơn hẳn, là ngôn ngữ hiện đại, dễ đọc, ngắn gọn và trong sáng, nó gần với ngôn ngữ quốc tế hơn ( english), bởi vì nó ko được build từ C, nó đã lược bỏ bớt đi một số cú pháp kế thừa. Swift cũng khá dễ để maintain, chỉ cần 1 file .swift, không cần đến .h và .m như bên Objective-C. Bởi vì XCode và bộ biên dịch LLVM có thể tìm ra các dependency và thực hiện tăng tốc độ build một cách tự động.
    Tổng quát lại, bạn không cần tốn qua nhiều công sức để viết nhiều code mà vẫn đạt được kết quả tương đương với ít code hơn, tất nhiên là với Swift.
    Swift nhanh hơn, an toàn hơn, kiểm soát tốt vấn đề quản lý bộ nhớ hơn. Bạn biết điều gì sẽ xảy ra trong Objective-C khi bạn gọi một method mà chưa khởi tạo biến con trỏ? Ko sao cả, một đoạn mã sẽ được bỏ qua. Nghe có vẻ ok đấy, nó ko bị crash app, tuy nhiên nó sẽ dẫn đến khá nhiều bug và dẫn đến nhiều hành vi thất thường. Swift xử lý vấn đề này bằng cách đưa ra khái niệm Optional. Không chỉ là bạn có một ý tưởng tốt hơn là cái gì đó có thể là nil và đảm bảo rằng nó được đặt vào vùng nào đó được ngăn chặn khi nil được sử dụng, nhưng nếu nil optional được sử dụng, Swift sẽ trigger được crash, tạo điều kiện cho dev gỡ lỗi. ARC hoạt động hiệu quả hơn trong Swift. Với Objective-C, ARC không hoạt đọng được với các hàm C và APIs như kiểu Core Graphic, đôi lúc chúng ta phải release thủ công.

    4 .  To React or not to React?
    Functional Reactive Program (FRP), như một kiểu thời trang lập trình mới nổi. Ý tưởng của nó là cho phép dễ dàng kết hợp operation bất đồng bộ với luồng event/data. Với Swift, nó là một tính trừu tượng kiểu generic của một cách thể hiện tính toán thông qua giao diện kiểu Observable<Element>.

    Cách giải thích dễ hiểu nhất chúng ta sẽ xem một đoạn code. Chẳng hạn A, và B, muốn mua một game console mới. A lấy 5 từ bố của A hàng tuần, B cũng được bố cho 5 như thế. Tuy nhiên, B kiểm thêm được 5$ bằng việc đi bán báo dạo hàng tuần. Nếu như tuần nào cũng có tiền như vậy, tuần nào cũng check xem đã đủ tiền để mua được game hay chưa? Bằng cách tạo 1 var để “lắng nghe (hoăc là “đăng ký”) sự thay đổi số tiền và A, B có được. Khi giá trị đó đủ để mua game thì sẽ hiển thị message
    Về code thì như thế này:

    // Savings
    let timmySavings=Variable(5)
    let jennySavings=Variable(10)
    varisConsoleAttainable=
    Observable
    .combineLatest(timmy.asObservable(),jenny.asObservable()){$0+$1}
    .filter{$0>=300}
    .map{"\($0) is enough for the gaming console!"}
    // Week 2
    timmySavings.value=10
    jennySavings.value=20
    isConsoleAttainable
    .subscribe(onNext:{print($0)})// Doesn't print anything
    // Week 20
    timmySavings.value=100
    jennySavings.value=200
    isConsoleAttainable
    .subscribe(onNext:{print($0)})// 300 is enough for the gaming console!
    (Còn tiếp)
     

Chia sẻ trang này