Thiết kế kĩ thuật cấp cao (Tech Stack)
Có vô số các phương pháp, công nghệ và ngôn ngữ lập trình có thể được dùng để xây dựng app mobile. Mỗi loại đều có những điểm mạnh và thiếu sót riêng. Một số thì rẻ hơn nhưng hiệu năng thấp, trong khi những thứ khác lại mất nhiều thời gian để triển khai và quá mức cần thiết. Tệ nhất là xây dựng trên technology stack lỗi thời (sắp chết) hoặc không đáng tin. Nếu bạn đã lỡ theo hướng này, bạn có thể phải “đập đi xây lại” app của mình hoặc trả phí duy trì cho các lập trình viên tiếp tục làm tiếp. Đó là lý do vì sao có được một đối tác phát triển tin cậy dày dặn trong việc đưa ra những quyết định là sự sống còn ở tiến trình này.
Front-end
Khi phát triển front-end (app mobile), có 3 phương án cơ bản đó là: platform-specific native, cross-platform native và hybrid. Ở đây, tác giả trình bày tổng quan một cách ngắn gọn về từng cách tiếp cận và các bài viết kỹ chi tiết hơn.
- Platform-specific Native — Apps: phương án viết riêng cho từng nền tảng di động (android và iOS). Code không thể tái sử dụng giữa Androdi và iOS nhưng những app như vậy có thể được tối ưu hóa hoàn toàn cho mỗi nền tảng. Phần UI có thể trông hoàn toàn nguyên bản (vì vậy nó thích ứng với hệ điều hành) và app sẽ hoạt động mượt mà. Cách này thường tốn kém nhất nhưng nó đáng được áp dụng và thử nghiệm.
- Cross-platform Native — Apps: phương án một phần hoặc hoàn toàn code dùng chung được giữa các hệ điều hành nhưng vẫn chạy như code thuần túy. Các công nghệ thường được dùng hiện nay là React Native, Xamarin, và Native Script. Đây là một nền tảng trung gian giữa các phương án khác biệt mà lại tiết kiệm được chi phí hơn, không những thế vẫn có thể tối ưu và tạo style cho từng platform.
- Hybrid — Các ứng dụng lai được xây dựng bằng các công nghệ web (HTML, CSS, Javascript) và được cài đặt qua một wrapper gốc. Các công nghệ được dùng như Cordova, Phone Gap, và Ionic. Lựa chọn này tuy là rẻ nhất nhưng hiện tại vẫn còn nhiều vấn đề thực sự gây khó khăn.
Back-end (Web API & Server)
Phần server chịu trách nhiệm về hiệu suất và khả năng co giãn app của bạn. Các công nghệ được sử dụng ở đây tương đương những thứ được dùng để làm các ứng dụng trên nền tảng web. Ở đây có vài điều bạn phải quyết định trước khi viết code:
- Ngôn ngữ — Có hàng tá ngôn ngữ có thể được sử dụng để xây dựng API cho app của bạn. Các ngôn ngữ thường dùng là Java, C#, Go-lang, Javascript, PHP và Python. Hầu hết các ngôn ngữ đều có nhiều framwork có thể làm việc.
- Cơ sở dữ liệu (Databases)— Có 2 kiểu db hiện nay là SQL và noSQL. SQL truyền thống hơn và thường là lựa chọn tốt nhất cho các bài toàn. Các SQL thực thi thông thường bao gồm MSSQL, MySQL và PostgreSQL. Ngoài việc chọn lựa một db engine, bạn phải thiết kế lược đồ cụ thể db của mình. Có được dữ liệu được tổ chức tốt và tin cậy là cực kì quan trọng cho thành công lâu dài của bạn. Vì vậy, đảm bảo chắc chắn rằng điều này được làm cẩn thận kĩ càng.
- Cơ sở hạ tầng (môi trường hosting)— Ở khâu này bạn cần xác định API và db của bạn được lưu trữ ở đâu và như thế nào. Các quyết định trên đây sẽ giúp xác định chi phí hosting, khả năng mở rộng, hiệu suất và độ tin cậy của app của bạn. Các nhà cung cấp hosting thông thường bao gồm Amazon AWS and Rackspace (trên thế giới).
Ngoài việc lựa chọn nhà cung cấp, bạn cần lên kế hoạch cách hệ thống của bạn sẽ scale như nào khi user base tăng trưởng. Các giải pháp nền tảng đám mây cho phép bạn chi trả tài nguyên hữu dùng (dùng bao nhiêu trả bấy nhiêu) và scale up/down khi cần thiết. Họ cũng cho phép bạn backup DB, theo dõi thời gian hoạt động server và cập nhật hệ điều hành.
Phát triển và Lặp lại
Phát triển mobile app “chuẩn” là một tiến trình lặp lại. Có thể bạn đã nghe quen các thuật ngữ như “sprint” hay “phương pháp agile” (hoặc bây giờ có thêm “phiên bản MVP”). Về cơ bản, điều này dựa trên việc bạn chia nhỏ tất cả các công việc phát triển thành các milestone nhỏ hơn và xây dựng app trong một chuỗi các chu kì. Mỗi chu kì sẽ bao gồm lên kế hoạch, phát triển, kiểm thử và duyệt lại. Phần này tác giả trình bày tổng quan ngắn gọn mỗi bước (có khá nhiều sách nói về điều này, bạn có thể tự tìm đọc). Mỗi công ty sẽ có một qui trình thực hiện các bước và trình tự khác nhau và có thể không giống nhau được trình bày dưới đây.
Lập kế hoạch
Pha lập kế hoạch của sprint tương ứng chia danh sách các task được thực hiện trong tiến trình lặp hiện tại. Mỗi task cần được xác định rõ ràng các yêu cầu. Khi các developer hiểu được các yêu cầu này, họ sẽ thường ước tính thời gian để hoàn thành mỗi task, do đó các task có thể được phân bố đồng đều để khối lượng công việc được cân bằng trong một sprint.
Các developer cũng bắt đầu lên kế hoạch tiếp cận để giải quyết các vấn đề được giao trong pha đó. Các lập trình viên phần mềm có kĩ năng tìm cách khôn khéo tái sử dụng code mọi nơi của app. Điều này đặc biệt quan trọng trong việc thực thi các style và các chức năng đã chia sẻ. Nếu một thiết kế cần được thay đổi (luôn luôn là như vậy), bạn không muốn phải cập nhật lại mã ở nhiều nơi. Thay vào đó, phần mềm được thiết kế tốt có thể thay đổi được những chỗ đã chọn để thực hiện hàng loạt thay đổi đó.
Phát triển
Trong suốt pha phát triển, dev team sẽ bắt đầu thực hiện các style và chức năng của app. Ngay khi họ hoàn thành, họ sẽ giao lại cho PM hoặc QA tester để review. PM làm hiệu quả là người có thẻ tối ưu hóa khối lượng công việc của developer trong suốt tiến trình đó bằng cách phân phối lại các assignment của cả sprint. Điều quan trọng là dev team của bạn thực sự hiểu được các mục tiêu của app nói chung và các tính năng cụ thể mà họ đang làm nói riêng. Không ai thích hợp hơn với tính năng đó so với develper đã được assign. Họ nên hiểu mục đích của các yêu cầu. Nếu thứ gì đó bắt đầu vô nghĩa, các developer thường sẽ là người cho bạn biết đầu tiên.
Phần tiếp theo tác giả gợi ý dùng một platform tên là Hockey App, nó cho phép họ có thể phân phối một cách riêng tư và an toàn phiên bản in-devlopment (demo) của app tới các tester, client và các developer khác. Hockey tự động thông báo người dùng các bản build mới (vì vậy mọi người được thử nghiệm bản build gần nhất và tốt nhất), cung cấp các báo cáo về crash, và có thể đảm bảo chỉ những tester được chỉ định mới có thể truy cập vào app của bạn. Đó là một cách tuyệt vời giúp mọi người luôn tăng tốc trên tiến trình. Trong quá trình phát triển, sẽ update Hockey 1 hoặc 2 lần một tuần.
Thử nghiệm
Hầu hết việc kiểm thử phải do những người không phải developer hoặc chí ít là những người không phải developer chính của app của bạn. Điều này sẽ đảm bảo việc kiểm thử thuần khiết hơn. Có một vài loại kiểm thử nên có trong mỗi sprint. Thông thường gồm:
- Functional Testing — Kiểm thử chắc chắn rằng tính năng hoạt động đúng như mô tả trong các yêu cầu đặt ra. Thường team QA sẽ có một kế hoạch test với một danh sách các hành động và hành vi app mong muốn .
- Usability Testing — Kiểm thử chắc chắn rằng tính năng là thân thiện với người dùng và trực quan nhất có thể. Thường thì việc này nên được mang đến tester mới để cho một trải nghiệm dùng đầu tiên.
- Performance Testing — App của bạn có thể hoạt động hoạt hảo, nhưng nếu nó cần 20 giây để hiển thị một danh sách đơn giản, không ai muốn dùng nó. Kiểm thử hiệu năng thường rất quan trọng ở những sprint cuối, nhưng hãy theo dõi phản hồi của app ngay khi bạn thao tác.
- Fit and Finish Testing — chỉ vì pha thiết kế đã hoàn thành ở quá khứ, không có nghĩa là bạn có thể “cất” các designer trong một cái tủ. Các designer nên review lại từng tính năng và đảm bảo rằng vision của họ đã được thực hiện đúng như đã mô tả trong bản thiết kế. Đó là một lý do nữa tại sao có một đối tác (hoặc team) cả design và developement là một lợi thế.
- Regression Testing (kiểm thử hồi qui)— Nhớ rằng có những tính năng đã có từ sprint trước. Đừng cho rằng nó vẫn hoạt động chỉ vì tháng trước bạn đã kiểm tra nó. Team QA tốt sẽ có một danh sách các testcase (issue) để thực hiện vào cuối mỗi sprint, chúng sẽ bao gồm cả các issue từ những sprint trước đó.
- Device-Specific Testing — Có hàng chục nghìn các tổ hợp thiết bị và hệ điều hành trên thế giới. Khi kiểm thử, hãy đảm bảo chắc chắn rằng bạn đã thử lần lượt các kích thước màn hình và phiên bản OS. Có các tool mà có thể giúp tự động hóa việc này, chẳng hạn Firebase của Google, nhưng nên luôn kiểm tra app bằng tay tối thiểu một vài thiết bị vật lý.
- User Acceptance Testing — Việc kiểm thử này được thực hiện bởi owner hoặc những người dùng tương lai tới đây của app. Nhớ rằng bạn là người đang xây dựng app này và nhận feedback từ họ trong suốt quá trình. Nếu có một tính năng pass tất cả các kiểm thử trên, nhưng fail ở đây, vậy dùng nó để làm gì?
Nếu như các vấn đề được phát hiện ở pha này, assign lại các task cho các developer những vẫn đề có thể xử lý được và các issue đóng lại. Một khi việc kiểm thử đã hoàn thành và từng task là done, chuyển đến bước review.
Review
Ở cuối mỗi sprint, trò chuyện hoặc họp trao đổi với mỗi một trong các liên quan và xác định sprint ngay sau đó. Nếu có những khó khăn, có gắng loại bỏ chúng trong các sprint sau này. Nếu mọi thứ êm đẹp ở một điểm nào đó, hãy cố gắng áp dụng chúng ở những nơi khác. Không có 2 dự án nào là giống nhau và mọi người nên luôn luôn tiến bộ trong bổn phận của mình (sự học hỏi), nhằm cải thiện trong khi bạn lặp lại. Một khi review hoàn tất, bắt đầu lại với giai đoạn lập kế hoặc và lặp lại quá trình này trước khi app hoàn tất!
Mở rộng review
Tại thời điểm này, app của bạn nên được test đầy đủ và hoàn thành tính năng (tối thiểu cho bản MVP). Trước khi bạn tiêu một khoản tiền bạc và thời gian khá lớn vào marketing, hãy dành một thời gian để test app của bạn với một tập mẫu người dùng tiềm năng. Ở đây có 2 cách để làm điều đó.
Các nhóm tập trung
Các nhóm tập trung liên quan đến việc tiến hành một cuộc phỏng vấn với một hoặc một nhóm người thử nghiệm– những người chưa từng xem app trước đó và tiến hành cuộc phỏng vấn. Bạn muốn hiểu được những tester này là ai, họ tìm hiểu về app mới như nào, và nếu họ đã từng dụng các app tương tự. Thử lấy một vài thông tin cơ bản của họ trước cả khi họ đến với sản phẩm của bạn. Tiếp theo, để cho người thử nghiệm của bạn bắt đầu dùng app. Họ không nên được huấn luyện trong suốt tiến trình này. Thay vào đó, hãy để họ dùng app như thể họ vừa tìm thấy nó trên chợ ứng dụng. Xem cách họ dùng app, và tìm những điểm không hài lòng chung. Sau khi họ hoàn tất sử dụng app, đi lấy feedback từ họ. Nhớ không để chỉ dẫn quá nhiều bởi bất kì tester nào, nhưng tổng hợp feedback và đưa ra những quyết định thông minh bằng cách sử dụng tất cả feedback sẵn có.
Beta Testing
Ngoài ra, thay vì các nhóm tập trung, bạn có thể launch bản beta của app. Beta test liên quan đến việc có được một nhóm người thử nghiệm dùng app của bạn trong môi trường thực tế. Họ dùng app giống như khi nó được ra mắt, nhưng với số lượng nhỏ hơn. Thường những người thử nghiệm beta này sẽ là những người dùng chi phối, những người trải nghiệm đầu tiên và có khả năng là những khách hàng tốt nhất của bạn (VIP member hay “fan” của app). Đảm bảo chắc chắn rằng họ cảm thấy có giá trị và được tôn trọng. Đưa cho họ nhiều cơ hội để cung cấp feedback và để họ thấy rằng bạn đang thay đổi app như thế nào và khi nào. Hơn nữa, beta testing là thời điểm tuyệt vời để xem app của bạn hoạt động như nào trên nhiều thiết bị, các vị trí địa lý, các hệ điều hành và những điều kiện mạng. Bước này bắt buộc bạn phải báo cáo các sự cố, nếu có điều gì đó không đúng, chứng tỏ app của bạn chưa tốt, và còn những vấn đề chưa được chẩn đoán và phát hiện ra.
Tinh chỉnh
Sau các chu kì mở rộng review đó, thường có một sprint phát triển cuối cùng để giải quyết mọi vấn đề mới được phát hiện. Song song với thử nghiệm beta testing trong suốt tiến trình này và đảm bảo rằng các sự cố và các báo cáo issue giảm dần. Một khi bạn đã clear mọi thừ từ những người thử nghiệm, đó là lúc để bắt đầu chuẩn bị cho deployment.
Triển khai (Deployment)
Ở đây có 2 thành phần chính để triển khai app mobile của bên trên toàn thế giới (on-air). Đầu tiên là triển khai web server (API) đến một môi trường sản phẩm mà có thể mở rộng. Thứ hai là triển khai app của bạn lên Google Play Store và Apple App Store.
Web API (Server)
Hầu hết các ứng dụng monile require một server back-end để gọi hàm. Các web server phản hồi truyền nhận dữ liệu tới và từ app. Nếu server của bạn bị quá tải hoặc ngừng hoạt động, app cũng sẽ ngừng hoạt động. Những server được cấu hình có thể co giãn (scalable) đáp ứng hiện tại của bạn và cơ sở người dùng tiềm năng, trong khi đó tiết kiệm được chi phí. Đó chính là nơi mà “cloud” xuất hiện. Nếu server của bạn được triển khai trên một môi trường có thể co giãn (Amazon Web Services, RackSpace, v.v), khi đó nó có thể có khả năng xử lý tốt hơn trong các trường hợp đột biến về lượng traffic. Không phải quá khó đến mức khủng khiếp để scale cho hầu hết các ứng dụng mobile, nhưng bạn muốn chắc chắn rằng team của bạn biết những gì mà họ đang làm hoặc app của bạn có thể “ngỏm” ngay khi nó trở nên thông dụng.
App Stores
Submit app của bạn lên các chợ ứng dụng là một tiến trình liên quan nhiều thứ. Bạn cần đảm bảo chắc chắn rằng app của bạn được cấu hình chuẩn xác để release, điền đầy đủ các form riêng cho mỗi store, gửi các ảnh screenshot, các thứ cho marketing và viết mô tả. Ngoài ra, Apple review thủ công mọi app được gửi lên chợ ứng dụng của họ. Có thể họ sẽ yêu câu bạn thực hiện các thay đổi app của bạn để tuân thủ tốt hơn những qui định của họ. Đôi khi, bạn có thể trao đổi lại những thay đổi đó với Apple (người review app) khiến họ chập nhận ứng dụng của bạn. Có những lúc bạn phải thực hiện các thay đổi để được cấp quyền truy cập. Một khi app của bạn được phê duyệt, nó sẽ lên Google vào cuôiis ngày (trong 24 tiếng) và với Apple thì mất vài ngày để lên nếu như mọi thứ đều trơn tru.
Giám sát
Đừng nghĩ đơn giản rằng quá trình phát triển app kết thúc khi app đã bàn giao. Hãy xem mọi app thông dụng cỡ vừa và bạn sẽ thấy lịch sử update của app. Những update này bao gồm fix, cải thiện hiệu năng, thay đổi và các tính năng mới. Giám sát kĩ lưỡng là cách tốt nhất để hiểu được những update nào là cần thiết. Dưới đây là một số thứ mà bạn cần phải giám sát.
Các lỗi Crash
Có nhiều thư viện tin cậy có thể được dùng để theo dõi các lỗi crash của app. Những thư viện này chứa thông tin về các hoạt động của user, những device nào đang active, và nhiều thông tin kĩ thuật quan trọng đối với đội development cho việc giải quyết các vấn đề. App có thể được cấu hình để gửi email/văn bản/cảnh báo khi xảy ra crash. Những lỗi crash này có thể phân loại và xem chi tiết được.
Tool sử dụng: Sentry và HockeyApp
Phân tích
Các hệ thống phân tích app tiên tiến chứa một kho tàng thông tin. Chúng có thể giúp bạn hiểu được ai là người đang dùng app (độ tuổi, giới tính, vị trí địa lý, ngôn ngữ, v.v) và họ dùng nó như thế nào (thời gian sử dụng trong ngày, thời gian bỏ ra để dùng app, những màn hình nào được xem, v.v). Một vài công cụ thậm chí còn cho bạn xem heat map (bản đồ nhiệt) của app, vì vậy bạn biết được những button nào thường xuyên đươck click/tap ở mỗi màn hình. Những hệ thống như vậy cung cấp một cái nhìn nhanh chóng app của bạn được dùng như thế nào. Dùng thông tin đó để hiểu rõ chỗ nào sẽ được đầu tư nhiều hơn sau này. Đừng xây dựng trên những vị trí ít khi được sử dụng, mà hãy đầu tư vào những chỗ “đáng tiền”- có tiềm năng nhất.
Tool sử dụng: Facebook Analytics, Apptentive, Google Analytics, va Appsee
Performance
Một thông số quan trọng không được nói tới ở 2 phần giám sát trước đó là công nghệ và hiệu năng của app mà bạn sử dụng, tương đương làm thế nào để nó làm việc mượt mà. Mọi hệ thống (tác giả) triển khai đều có giám sát mở rộng hiệu năng tại chỗ. Ta có thể theo dõi xem bao nhiêu lần một action xuất hiện và hành động đó kéo dài bao lâu. Sử dụng điều này để tìm những khu vực nào đã đến lúc được tối ưu. Cũng luôn luôn đặt cảnh báo tại chỗ để chúng ta biết nếu có một action nhỏ nào chậm hơn mong muốn, khi đó ta có thể nhanh chóng phát hiện nếu gặp bất cứ vấn đề nào. Những công cụ này thường có dash boarding, reporting và các chức năng cảnh báo đi kèm.
Tool sử dụng: Prometheus
Quản lý chợ ứng dụng
Những review và rating trên app store cực kì quan trọng, nhất là những app mới. Bất cứ khi nào một review mới cũng để lại một danh sách (trên chợ ứng dụng), đảm bảo chắc chắn rằng nhằm thu hút được người review. Cảm ơn tới những người dùng những người mà review tốt cho bạn và thử hỗ trợ tận tình những người cảm thấy thất vọng về app. Có nhiều trường hợp người dùng review lại thành 5 sao khi họ được phục vụ bà cảm thấy “có hy vọng” trở lại. Hỗ trợ bằng “cơm” (những người support trực tiếp) la một cách giúp thúc đẩy độ thông dụng (online) của app.
Tiếp tục lặp lại và cải thiện
Mục đích của tất cả công đoạn giám sát này là để biết bạn cần phải làm gì tiếp theo. Luôn luôn có những tính năng mới mà có thể được thêm vào và những thứ có thể được cải thiện. Sẽ thật là lãng phí nếu app của bạn xây dựng một cách mù mờ. Dùng thông tin bạn nhận được từ người dùng và những platform giám sát của bản. Sau đó, lặp đi lặp lại tiến trình này (sau mỗi lần như vậy, các bước sẽ càng nhẹ nhàng hơn nhiều so với lần đầu). Tiếp tục cải thiện app, các chỉ số conversion, install base và dĩ nhiên là doanh thu toàn app của bạn. Các app mobile khá linh hoạt trong mọi hoàn cảnh, nắm lấy lợi thếđó bằng việc cải thiện và tăng trưởng (sự học hỏi).
Kết luận
Quá trình phát triển ứng dụng mobile trông có vẻ rắc rối và “quá tải” . Có rất nhiều khâu và những quyết định khó khăn cần được đưa ra. Nhưng những công việc này đáng được thử và rất nhiều điều thú vị. Có thể có những “cám dỗ” khiến những bước này bị bỏ quả trong quá trình đó, nhưng tác giả tin rằng hướng dẫn trên được xây dựng dựa trên kinh nghiệm lâu năm làm việc với các owner và họ đã lựa chọn bỏ qua một số bước nhất định.
Bình luận