Bài học sau 2 năm lập trình Android

Chào các bạn!

Hôm nay mình sẽ trích dẫn một bài viết mà nội dung của nó khá giống với những kinh nghiệm mà mình đã trải qua. Bài viết đã được phiên dịch sang tiếng Việt, điều này giúp các bạn mới dễ tiếp cận và có thể tránh được những sai lầm khi triển khai. Đây là những kinh nghiệm mà phải mất 2 năm mình mới có thể có được. Trong bài viết này, mình đã bổ sung thêm những góc nhìn cá nhân, mong rằng sẽ có ích với bạn.

Chúng ta cùng bắt đầu nhé

Tôi vẫn nhớ ngày đó, năm 2014, khi tôi quyết định dấn thân vào lập trình Android, và đó là một trong những quyết định thành công nhất trong đời tôi. Với hai năm rưỡi trong ngành, tôi đã có cơ hội học tập và nhận ra nhiều điều về Android.

Khi mới bắt đầu, vì không có đàn anh nào chỉ dẫn cả, nên tôi phạm rất nhiều lỗi và mất rất nhiều thời gian mò mẫm.

Một năm rưỡi sau, khi đã có cơ hội được tiếp xúc và học tập từ một số lập trình viên Android rất tài năng và kinh nghiệm, giai đoạn này tôi học được nhiều hơn và nhanh hơn. Qua cả hai giai đoạn, tôi dần biết được mình NÊN và đặc biệt là KHÔNG NÊN LÀM gì.

Bài viết này là những kinh nghiệm tôi học được, hy vọng kiến thức trong bài sẽ giúp bạn tránh được nhiều đoạn đường vòng không nên có.

1. Có sẵn rồi thì dùng đi

Khi mới vào nghề, tôi có suy nghĩ không dùng đến thư viện nguồn mở, cần cái gì là tự làm cái nấy. Quả thật, đây là ý tưởng vô cùng dở tệ.

Nếu bạn có vấn đề khi phát triển ứng dụng, và vấn đề này đã được người khác xử lý triệt để rồi, thì tại sao lại không dùng giải pháp của họ? Bạn có thể tiếp kiệm rất, rất, rất nhiều thời gian đấy.

Tập trung hơn vào business logic lõi của ứng dụng. Nếu bạn muốn thực hiện network call trong ứng dụng, bạn không cần tự làm Retrofit của riêng mình đâu.

Bonus: Android Arsenal maintain cả một database của hầu hết tất cả thư viện Android từng xuất hiện. Bạn nào cần thì xem thử nhé.

Kinh nghiệm cá nhân: Trong quá làm việc với các bạn mới, mình đã thấy rất nhiều trường hợp như thế này. Khi mới bắt đầu, chúng ta hãy tập trung vào việc phát triển phần lõi của ứng dụng thay vì làm lại những thư viện, logic sẵn có.

Tốc độ tìm kiếm thư viện/giải pháp phù hợp phụ thuộc vào kỹ năng tìm kiếm của bạn. Đây chính là chìa khóa giúp chúng ta khai mở những giới hạn của bản thân. Mở ra những góc nhìn mới và cơ hội mới.

2. Chọn thư viện cho khôn ngoan

Có rất rất nhiều thư viện nguồn mở trong GitHub mà bạn có thể dùng miễn phí. Nhưng đừng quá phấn khích mà lựa chọn mù quáng.

Hãy kiểm tra số sao mà thư viện đó có, càng nhiều càng tốt. Xem thử liệu tác giả của thư viện đó có tạo thêm thư viện nào nổi tiếng nữa không. Xem trước các sự cố (cả mở và đóng), để từ đó biết được tình trạng hiện nay của thư viện như thế nào.

Nếu có thể, bạn cần đảm bảo rằng những code bạn định dùng phải đáng tin, không bug, và chất lượng cao.

Pro Tip: Hãy thử bất kỳ thư viện nào được host trực tiếp từ command line với Dryrun.

Kinh nghiệm cá nhân: Bạn có thể tìm nhanh những bài tổng hợp những thư viện/công cụ hay ho bằng từ khóa awesome. Ví dụ, bạn đang muốn tìm hiểu về những thư viện, kiến thức hay về Android. Bạn hãy search từ khóa awesome android. Tin mình đi, kết quả mà bạn tìm được sẽ giúp bạn tiết kiệm được rất nhiều thời gian.

3. Đọc code nhiều hơn

Chúng tôi dành hầu hết thời gian để đọc code của nhau, còn nhiều hơn là ngồi viết code nữa. Nếu bạn vẫn chưa làm thế này, hãy bắt đầu ngay đi.

Bất cứ đoạn code nào mà bạn viết được ngày nay là chỉ vì bạn đã đọc và học thứ gì đó, từ đâu đó, và từ lúc nào đó mà thôi. Đó chỉ là sự phản ánh của những gì bạn đã biết. Bạn chỉ có thể phát triển và cải thiện bản thân bằng cách học và đọc từ tác phẩm của người khác mà thôi.

Android có một lợi thế rất lớn, đó chính là nền tảng nguồn mở hoàn toàn. Với lợi thế này, bạn có thể nghiên cứu code xem họ đã thực hiện framework đó như thế nào. Có đến hàng nghìn thư viện nguồn mở trong Github. Chỉ việc lựa chọn thư viện phù hợp và tham khảo.

Bonus: Đây là danh sách các thư viện được cập nhật liên tục, và đây là hầu hết ứng dụng  Android open-source hiện nay.

Kinh nghiệm cá nhân: Khi mới đọc code có thể bạn sẽ rất nhàm chán và buồn ngủ, những lúc như thế bạn nên thả lỏng cơ thể và di chuyển để thoải mái hơn nhé. Khi đọc code của người khác, bạn sẽ có được những kiến thức hay ho mà trước giờ mình chưa được biết.

Nếu bạn cần tham khảo code của một ứng dụng bất kỳ trên Google Play, việc đầu tiên là bạn cần download APK bằng công cụ APKCOMBO. Sau khi có APK, bạn mở file bằng công cụ JADX-GUI là có thể xem được nhé. Mình đã học được rất nhiều cách xử lý hay bằng cách làm này.

4. Code theo chuẩn

Nếu bạn so sánh code với văn viết, thì chuẩn code cũng giống như chữ viết của bạn vậy.

Khi bạn đọc code của người khác nhiều hơn, người ta cũng sẽ đọc lại rất nhiều code của bạn, bạn không muốn dọa người đó sợ vãi c*t đúng không nào? Và nếu bạn đang hợp tác cường độ cao với các lập trình viên khác tại nơi làm việc, bạn càng phải quan tâm đặc biệt đến điểm này. Hãy viết code ngắn, sạch, và dễ đọc dể làm cuộc sống của người khác trở nên tươi đẹp hơn. Đọc code phải như đọc thơ.

Một ngày đẹp trời, đồng nghiệp đọc code của bạn rồi không nói chuyện với bạn vài ngày sau, lúc đó đừng có than.

Kinh nghiệm cá nhân: Code ngon nó còn thể hiện đẳng cấp cá nhân, nâng cao hiệu suất làm việc. Chuẩn của code là không cố định. Nó có thể do Team hoặc công ty mà bạn đang làm việc quy định. Do đó khi bạn gia nhập công ty, bạn sẽ được đào tạo để làm quen với những chuẩn này.

5. Bạn cần ProGuard, đúng vậy, cần lắm lắm!

Đừng, đừng bao giờ phạm sai lầm tung ứng dụng lên Play Store mà không dùng ProGuard.  ProGuard không chỉ tối thiểu hóa code của bạn, mà còn “tung hỏa mù” trong code khiến đối thủ khó lòng, hiểu, tái hiện và kiểm soát code của bạn.

Công cụ hoàn toàn miễn phí và đính kèm với Android SDK, và hoàn toàn không có lý do nào khiến bạn không nên dùng đến nó cả.

Tôi từng thấy nhiều bạn tung ứng dụng lên market mà không có ProGuard. Ứng dụng “trần trụi” như vậy chỉ mất vài tiếng để hack (với hacker có trình độ tay ngang).

Pro Tip: ProGuard đôi khi cũng chỉ là muỗi, Nếu bạn muốn bảo mật siêu cấp, hãy dùng DexGuard.

Kinh nghiệm cá nhân: Với những phần lõi của ứng dụng mà bạn muốn che giấu string thì bạn có thể sử dụng thư viện Cipher hoặc sử dụng bộ thư viện mã hóa ZKM – thư viện mất phí nhưng rất bá đạo. ZKM có thể mã hóa toàn bộ string trong code Java. Ví dụ như url của API chẳng hạn.

6. Dùng đúng kiến trúc

Khi chọn đúng kiến trúc ngay từ đầu project, bạn sẽ cảm thấy “làm lập trình viên thật tuyệt”. Bạn có thể sử dụng kiến trúc MVP (Model-View-Presenter) , có thể decouple code thành nhiều lớp dễ quản lý, từ đó cải thiện độ linh hoạt của code và giảm đang kể thời gian cho maintain.

Kinh nghiệm cá nhân: Với các sản phẩm cần thử sai nhanh thì chúng ta không nên quá quan trọng về kiến trúc. Phụ thuộc vào từng bài toán, độ phức tạp, nguồn lực mà bạn chọn mô hình cho phù hợp.

7. User Interface giống như chuyện đùa, nếu bạn phải giải thích, thì chuyện ấy nhạt tuếch

Nếu bạn “chỉ” đảm nhiệm việc lập trình và phát triển trong công ty, có lẽ bạn sẽ không cần lo về khoản này, vì đã đã có UI/UX designer trợ giúp rồi.

Nhưng nếu là lập trình viên “đánh lẻ”, bạn cần phải rất chú ý đến UI và UX nữa, nếu thiếu hai điểm này, tính năng hay cũng vô dụng.

Hãy thiết kế một giao diện sạch, đơn giản, đẹp và dễ nhìn. Không chỉ nên nghĩ như lập trình viên, mà còn phải đánh thức tâm hồn thiết kế bên trong bạn nữa.

Với một UI đẹp và hợp lý, bạn có thể để lại ấn tượng sâu sắc trong mắt người dùng, từ đó học có thể tiếp tục quay lại vời ứng dụng và có tỷ lệ convert (sang bản premium chẳng hạn) cao hơn.

Theo xu hướng hiện nay, bạn nên đi theo xu hướng tối giản, thay vì thêm thắt quá nhiều chi tiết rườm rà.

8. Analytics là người bạn thân nhất

Nếu muốn làm ra một ứng dụng thật sự tuyệt vời, bạn cần phải theo dõi sát sao hiệu năng và tần suất sử dụng của các phần khác nhau của ứng dụng (thông qua công cụ analytics uy tín).

Với analytics, bạn cần cả crash reporting lẫn app usage tracking.

Dù có làm gì đi chăng nữa, bạn sẽ chả bao giờ đạt đến mức “hoàn hảo”. Khi người dùng thật bắt đầu sử dụng bắt đầu sử dụng ứng dụng của bạn trên nhiều thiết bị và phiên bản Android khác nhau, bạn sẽ bắt đầu thấy nhiều đoạn code mình từng “tấm tắc tự khen” dần dần kéo cả ứng dụng đi xuống.

Công cụ report crash có thể giúp bạn theo dõi và fix chúng, từng crash một.

Bạn cũng phải bắt đầu suy nghĩ như một marketer và phân tích tiêu thụ phần cứng của từng phần trong ứng dụng. Khi đã có những số liệu cần thiết, bạn sẽ có thể rút ngắn khoản cách giữa thứ mình làm ra với thứ người dùng thật sự mong muốn.

Pro Tip: Firebase Crash Reporting and Analytics là công cụ tuyệt vời nhất cho mọi người mọi nhà.

9. Biến thành Marketer thứ thiệt

Là lập trình viên “đánh lẻ”, bạn cần phải có hiểu biết hơi “toàn diện” một chút, và tất nhiên, marketing cũng nằm trong số đó.

Tôi đã từng thấy rất nhiều sản phẩm tốt thất bại vì không được marketing đúng cách, còn một số sản phẩm không-tốt-lắm lại nổi như cồn vì biết cách marketing.

Nếu bạn nghiêm túc về sản phẩm của mình và muốn tiếp cận lượng người dùng lớn hơn nữa, bạn cần phải đầu tư thời gian và tiền bạc để marketing ứng dụng cho ra hồn. Nhưng trước khi bắt đầu chiến dịch marketing, hãy đảm bảo rằng ứng dụng của bạn đã có đầy đủ các tính năng ổn định.

Bạn cũng nên để ý xem đối thủ đang làm gì, nếu có thể thì cạnh tranh hết mức, còn nếu đối thủ quá “khó nhằn”, bạn có thể tạm gác lại rồi “chiến” sau.

Pro Tip: Đây là một công cụ phân tích thị trường khá hay nên dùng.

10. Đến lúc tối ưu ứng dụng rồi đấy

Đa số chúng ta không hề để ý đến khâu này, nhưng bạn nên và cần làm ngay từ hôm nay đi.

Có sự khác biệt rất lớn giữa viết code và viết code “tối ưu”. Hãy viết code làm sao để ứng dụng chạy nhanh, tiêu thụ bộ nhớ ít hơn và chiếm ít dung lượng.

Dưới các tình huống thông thường, ứng dụng chưa tối ưu vẫn chạy tốt, nhưng khi đặt vào nhiều tính huống “căng như dây đàn”, vấn đề sẽ liên tục xuất hiện.

Bạn có thể bắt đầu bằng việc kiểm tra lượng bộ nhớ được ứng dụng tiêu thụ và tìm memory leaks. Bạn cũng nên biết cách vận hành của Garbage Collector trong Java, tạo heap dumps và phân tích live objects.

Pro Tip: Leak Canary có thể giúp bạn tự động xác định memory leaks vô cùng tiện lợi.

Kinh nghiệm cá nhân: Giờ đây với công cụ Android Studio vô cùng hiện đại, chúng ta đã có Profiler. Công cụ này có thể giúp bạn biết chính xác ở thời điểm nào thì ứng dụng bị chậm.

11. Tiếp kiệm khối thời gian với Gradle Builds

Rất có thể bạn đang sử dụng Android Studio để phát triển ứng dụng Android và dùng Gradle làm build system. Gradle rất tốt nhưng lại chậm, và càng ngày càng chậm hơn khi dự án bắt đầu phình ra.

Tôi còn nhớ hồi ngồi “dài cổ” đợi Gradle build xong. Mấy ngày nhiều việc, mỗi ngày mất cả tiếng đồng hồ là chuyện bình thường, tính ra là mỗi tuần đã mất 5 tiếng chả làm được gì rồi.

Nhưng tất nhiên vẫn có cách tăng tốc rồi.

Bạn có thể làm theo bài viết này và này để cải thiện đáng kể build speed. Build time của tôi giảm mạnh từ 4 phút đến ít hơn 30 giây sau khi được tối ưu đúng cách.

12. Test, Test và khi Test xong, Test lại lần nữa!

Trên đời không có gì quan trọng bằng testing cả. Hãy test ứng dụng của bạn kỹ càng nhất có thể, tốt nhất là bạn nên dành thời gian ra để viết các trường hợp test tự động. Tạo nhiều tình huống “khó nhằn” cho ứng dụng, thử xem bạn có sống sót được không.

Hồi trước cũng có lần tôi vội đưa ứng dụng lên mà không dành đủ thời gian test. Lúc đó tâm lý của tôi là ngồi chờ người dùng gặp lỗi, report, rồi mới fix. Đừng, đừng, đừng bao giờ làm như vậy nha. Bạn có thể tiếp kiệm một hai ngày, hay một tuần từ việc cắt giảm thời gian cho testing, nhưng bạn có thể mất gấp đôi khoảng thời gian này sau đó.

Đừng làm gì quá vội vàng, cứ từ từ và nghĩ theo “đường dài”. Gieo trước, gặt hái sau.

13. Phân Mảnh Android là quỷ đội lốt người

Phân mảnh thiết bị là một trong những vấn đề lớn nhất trong Android, và có vẻ như Google lại lưỡng lự không muốn giải quyết.

Hiện nay, lượng thiết bị Android với các kích thước màn hình và thông số phần cứng khác nhau đã lên đến một con số khổng lồ. Và tệ hơn nữa, nhà nào nhà ấy còn thi nhau tinh chỉnh OS tán loạn cả lên để có cái gọi là “điểm riêng cho thương hiệu”.

Không dừng lại ở đó, có nhiều phiên bản Android mà Google bỗng nhiên thêm/bớt tính năng API để làm cuộc sống của chúng ta khó khăn hơn nữa.

Ví dụ như, chưa từng có lập trình viên Android nào làm xong một ứng dụng mà không dùng đến SharedPreferences API. API này vô cùng thường thấy, ấy vậy mà cũng bug đầy trong bản Android 2.2 cho Samsung Galaxy S (bug report đây).

Hãy chú ý đến các layout khác nhau cho từng kích thước màn hình, test trên các thiết bị với các phiên bản khác nhau, nhiều thông số và từ nhiều OEMs.

Kinh nghiệm cá nhân: Bạn có thể đọc bài Hướng dẫn hỗ trợ đa màn hình trong lập trình Android của mình để biết cách tối ưu nhé.

14. Nhảy vào Git ngay và luôn!

Nếu bạn vẫn chưa biết đến Git, còn chờ gì nữa nào?

Khi mới bắt đầu lập trình Anroid, tôi có biết Git là cái giống quái gì đâu. Tôi từng copy cả một project của mình mỗi ngày và giữ một bản backup trong ổ cứng, một bản nữa trên cloud. Nghe ngu quá ha? Thì đúng là ngu thật mà.

Git có thể cải thiện mạnh mẽ workflow của bạn. Nếu ai đó hỏi tôi tôi tên của công cụ mà tôi sử dụng mỗi ngày và không thể ngừng sử dụng? Tôi sẽ trả lời là Git và luôn luôn là Git.

Nếu bạn muốn tìm hiểu kết cấu bên trong của Git, đây là nơi bạn cần tới. Còn nếu bạn bắt đầu chuyển qua những dự án lớn mà không biết nên maintain một model phân nhánh như thế nào, hãy tham khảo ở đây nhé.

Bonus: Nếu không đủ nguồn lực tài chính trả phí cho private repo trong GitHub, bạn có thể dùng thử miễn phí BitBucket.

15. Làm khó Hackers

Bản chất open source của Android khiến môi trường này rất dễ bị tấn công. Mọi ứng dụng Android đều có thể bị decompiled, kiến trúc ngược, xé toạc, phân tích và chi phối rất dễ dàng.

Tất nhiên, bạn không muốn điều này xảy ra với ứng dụng của mình đúng không nào?

Bạn cần biết cách lưu trữ API key cục bộ, bảo mật trong ứng dụng. Với dữ liệu nhạy cảm của người dùng, bạn bắt buộc phải biết cách mã hóa chúng, và biết nên chọn thuật toán nào (vừa an toàn vừa nhanh).
Bạn cũng nên lưu trữ encryption key thật an toàn trong server hoặc cục bộ (nếu cần thiết), và tránh để dữ liệu của ứng dụng bị ADB (Android Debug Bridge) back up.

Hơn nữa, với những ứng dụng có phiên bản premium, việc phiên bản này bị crack và phát tán trên mạng sẽ gây tổn thất tài chính rất lớn. Để giải quyết tính trạng này, bạn có nhiều hướng xử lý, tất nhiên là không thể đạt 100% bảo mật rồi. Bất cứ hacker nào với kỹ năng cao, sự kiên trì và tài nguyên hợp lý đề có thể crack tan hoang ứng dụng của bạn.

Như vậy, bạn phải làm sao để hacker khó crack, cực kỳ khó crack được ứng dụng mới thôi.

16. Phát triển trên thiết bị “lỗi thời”

Ai cũng thích dùng smartphone “tối tân” nhất, tôi cũng vậy. Nhưng nên nhớ, chỉ nên dùng những thiết bị mới nhất cho mục đích cá nhân, và đừng bao giờ dùng cho mục đích phát triển ứng dụng.

Thết bị mới, cao cấp hơn sẽ “giấu” đi nhiều lỗi của ứng dụng. Giả sử như, bạn “phá” UI thread như thế nào đó, từ đó khiến UI lag hơn, nhưng khi test trên một thiết bị mạnh mẽ, có khả năng cao bạn sẽ không bao giờ nhận thấy thiếu sót này.

Một thiết bị cũ, tốc độ thấp, được cài trước nhiều ứng dụng sẽ là một môi trường lý tưởng cho mục đích phát triển/lập trình.

17. Đầu tư học Design Patterns

Đây là khoản đầu tư sẽ giúp bạn sinh lời cả đời.

Trong quá trình phát triển các ứng dụng lớn và phức tạp, bạn sẽ đối mặt với nhiều vấn đề có thể đã được ai đó giỏi hơn bạn giải quyết, và đây là lúc kiến thức thiết kế sẽ giúp bạn rất nhiều.

Hãy dành một ít thời gian ngay từ hôm nay để học Java Design Patterns. Đây là một dự án Github mô tả tất cả design patterns mà loài người từng biết đến.

Để bắt đầu, bạn cần biết một số pattern quen thuộc như Singleton, Adapter, Factory Method, Iterator, Dependency Injection, Event Driven Architecture, Builder, Callback, Strategy, Facade and Producer Consumer.

Nhiều quá hả? Thật ra như vậy là ít rồi đấy. Tìm hiểu nhiều đảm bảo bạn sẽ thích thôi.

Pro Tip: Design Patterns của GoF, Refactoring của Martin Fowler và Effective Java của Joshua Bloch là một số cuốn sách hay.

Kinh nghiệm cá nhân: Bạn có thể tham khảo thêm ở các trang web dưới dây:

https://refactoring.guru/design-patterns/java

https://sourcemaking.com/design_patterns

https://java-design-patterns.com/patterns/

18. Đến lúc cho đi rồi

Hãy thú nhận đi, ai trong chúng ta cũng đã được những người lạ mặt trên internet giúp đỡ rất nhiều.

Khi nào bạn gặp vấn đề, điều đầu tiên bạn sẽ làm là Google vấn đề đó và tìm đường link đầu tiên từ StackOverflow. Đôi khi bạn quá vội vàng nên chỉ copy và paste giải pháp từ câu trả lời có lượt vote cao nhất.

Tại sao những thư viện tiện lợi và hay ho bạn sử dụng lại được cung cấp miễn phí như vậy? Đó là vì có những con người vị kỷ luôn dành thời gian quý báu của mình để xây dựng và đóng góp cho cộng đồng.

Bạn có nhớ, khi bạn vào ngõ cụt, không thể hiểu được khái niệm khó hiểu hay hoàn toàn lạ lẫm nào đó, và bỗng đâu bạn tìm được được một bài blog cực hay khiến mọi thứ dễ hiểu hơn bao giờ hết. Đó là nhờ một “thánh nhân” nào đó đã dành ra một ngày xem phim để chia sẻ cho bạn đọc.

Cũng đã đến lượt bạn phải cho đi rồi đấy. Bạn cho đi càng nhiều, bạn sẽ nhận lại càng nhiều.

Trích dẫn

https://tranvantoanblog.wordpress.com/2019/09/03/bai-hoc-rut-ra-sau-2-nam-lap-trinh-android/

https://blog.aritraroy.in/what-my-2-years-of-android-development-have-taught-me-the-hard-way-52b495ba5c51#.yg7t3g5un