#laptrinhapptrenios

[tronglambmtico0503-blog]

Học lập trình app Mobile trong bao lâu thì "kiếm được tiền”

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ó thời cơ học tập và nhận ra nhiều điều về Android.

Khi mới khởi đầ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 tuấn kiệt 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 thời đ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ì. 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 khởi đầ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, tôi lập trình app trên ios và android đã có cơ hội được xúc tiếp 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, thời đ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ì. 3. Đọc code nhiều hơn cái 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.

Làm app ios / android có một lợi thế rất lớn, đó chính là nền mó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 chọn lựa 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 tiếp, và đây là hồ hết ứng dụng Android open-source bây giờ.

4. Lạy chúa, code theo chuẩn, đừng hứng lên là viết bậy 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 độc giả 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 cộng 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 hoài đặ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 trò chuyện với bạn vài ngày sau, lúc đó đừng có than.

5. Bạn cần ProGuard, đúng vậy, cần lắm lắm! Đừng, đừng bao giờ phạm sai trái tung vận 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. Áp 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.

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. 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ỉ” cáng đáng việc lập trình và phát triển trong tổ chức, 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ô bổ.

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 dung nhan trong mắt người dùng, từ đó học có thể tiếp tục quay lại vời áp dụng và có tỷ lệ convert (sang bản premium chẳng hạn) cao hơn.

Theo xu hướng bây chừ, 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 áp 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 vận dụng (thông qua phương tiện 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 khởi đầu sử dụng bắt đầu sử dụng áp 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ả vận dụng đi xuống.

dụ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 khởi đầ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 áp 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 tẹo, và đương 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 chỉnh 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 kì và tiền bạc để marketing vận dụng cho ra hồn. Nhưng trước khi khởi đầu chiến dịch marketing, hãy bảo đảm rằng áp 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 dụng cụ phân tích thị trường khá hay nên dùng.

10. Đến lúc tối ưu áp dụng rồi đấy phần đông chúng ta không hề để ý đến khâu này, nhưng bạn nên và cần làm ngay từ bữa 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 để vận dụng chạy nhanh, tiêu thụ bộ nhớ ít hơn và chiếm ít dung lượng.

Dưới các cảnh huống thông thường, áp 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 đánh giá lượng bộ nhớ được áp 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 khôn cùng thuận lợi.

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à ngày một chậm hơn khi dự án khởi đầ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 thông thường, tính ra là mỗi tuần đã mất 5 tiếng chả làm được gì rồi.

Nhưng cố 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 yếu bằng testing cả. Hãy test vận 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 kì ra để viết các trường hợp test tự động. Tạo nhiều cảnh huống “khó nhằn” cho áp 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 kì 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 kì cho testing, nhưng bạn có thể mất gấp đôi khoảng thời kì 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.

bây giờ, 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 toá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 dưng 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.

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

Hãy lưu ý đến các layout khác nhau cho từng kích tấ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.

14. Dancing 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 khởi đầ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ẽ giải đáp 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 chi phí BitBucket.

15. Làm khó Hackers bản tính open source của Android khiến môi trường này rất dễ bị tấn công. Mọi áp 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 vận 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 áp 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 áp 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ý, đương 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ự bền chí và tài nguyên hợp lý đề có thể crack tan hoang ứng dụng của bạn. Nguon : techtalk cham vn