Initiatives to Improve Code Integrity to Continue Providing New Value -Yahoo! JAPAN Weather App

OHMAE Ryosuke (Yahoo! JAPAN / Development Division 1, Media Services Group, Media Group / Android App Engineer)

https://tech-verse.me/ja/sessions/142
https://tech-verse.me/en/sessions/142
https://tech-verse.me/ko/sessions/142

Transcript

1. OHMAE Ryosuke Development Division 1, Media Services Group, Media Group, Yahoo! JAPAN Initiatives to Improve Code Integrity to Continue Providing New Value - Yahoo! JAPAN Weather App -
2. Self-introduction OHMAE Ryosuke https://github.com/ohmae Twitter: ryo_mm2d Qiita: ryo_mm2d Yahoo! JAPAN @Osaka Android App Engineer Yahoo! JAPAN Weather App
3. Initiatives to Improve Code Integrity to Continue Providing New Value
4. Continue providing new value Improve Code Integrity Development of new feature New value
5. 写真：アフロ Yahoo! JAPAN Weather App
6. Changes in Yahoo! JAPAN weather app 2019 2022
7. Do ordinary things as a matter of course
8. Agenda Specification s and design Framework and code design App lifespan
9. Agenda Specification s and design Framework and code design App lifespan
10. It doesn't look like Android app..?
11. Standard UI components + Design guidelines
12. A lot of knowledge is required
13. Material Design Jetpack AppCompat Button Toolbar Elevation Dialog Typography Shadow Layout ProgressBar TextView ColorSystem Shape Theme Style Mode Icon ConstraintLayo CoordinatorLayout
14. iPhone
15. "Make it the same as for the iPhone"
16. iOS > Android
17. “Not possible?” “Sure it is!”
18. What's wrong with a UI like the iPhone?
19. Android iOS
20. Android iOS
21. Android iOS
22. Pixel 7 iPhone 14
24. Straightforward use of standard components Maintenance costs Convenience Accessibility Completeness
25. An Android app should be like an Android app
26. Specification and design OS compatibility vs
27. Specification and design OS compatibility +
28. Healthy specifications and design lAssertively introducing design guidelines and libraries and learning how to use them appropriately lAchieving a high level of completeness with straightforward implementation and strong OS compatibility lWe share specification and design intent, and our engineers propose specifications with strong OS compatibility
29. Agenda Specification s and design Framework and code design App lifespan
30. Lifecycle and threads Single package Wide range of support Difficulties in Android app development
31. Technical debt has an overall effect l Wrong abstruction / commonization l BaseActivity l BaseFragment Proper scoping is essential Implementing everything in a single package 写真：アフロ
32. Lifecycle and threads Understand the lifecycle and treat it appropriately Rotating the screen regenerates the instance Status handover Callback reconnection Handle threads properly Only the main thread can control the UI No network access allowed on the main thread onCreate() onStart() onResume() onPause() onStop() onDestroy() Activity launched Activity running Activity shutdown
33. Wide range of support Android 13 API 33 Android 12L API 32 Android 12 API 31 Android 11 API 30 Android 10 API 29 Android 9 API 28 Android 8.1 API 27 Android 8 API 26 Android 7.1 API 25 Android 7 API 24
34. Use what is available + Fit into the mold
35. Use what is available Actively introduce existing systems such as OSS and maintain a modern development environment RxJava Kotlin RxKotlin Retrofit OkHttp Room ViewModel LiveData Jetpack Material components Lottie Firebase
36. Kotlin lGoogle I/O 2017 Official support lGoogle I/O 2019 Kotlin-first lSecure code lDistinguishes Nullable/NonNull lExpressive and concise description lExtensive standard library
37. Fit into the mold Architecture
38. Architecture l Strategies for how to organize modules l We don't have to think about them each time l Can be made by imitation lLimits the scope naturally l Does not fall into local optimums
39. Work hard and have fun or Have fun and work hard
40. Use what is available + Fit into the mold lAvoid to do difficult things lTotal optimum instead of local optimum lSparing no effort to make things easy lAdding up lots of "betters" instead of a one-time "best"
41. Agenda Framework and code design Specification s and design App lifespan
42. "QQ
    MJGFTQBO 2022 2010 First release Now ,FFQ
    VQEBUJOH
    UIF
    TBNF QBDLBHF
    GPS
    
    ZFBST
    PS
    NPSF *U
    JT
    OPU
    JNQPTTJCMF
    UP
    NJHSBUF
    CZ
    DSFBUJOH
    B
    DPNQMFUFMZ
    TFQBSBUF
    BQQMJDBUJPO :PV
    IBWF
    UP
    CF
    EFUFSNJOFE
    FOPVHI
43. App lifespan Invisible specifications Irreversible elements Users who do not update
44. Irreversible elements lExternal protocol lAndroidManifest lPersistence information App specifications that have gone outside the app
45. Invisible specifications lCoordination information lCustom scheme lInter-process communication lPast persistence information App specifications that have gone outside the app
46. App specifications placed outside the app continue to affect the app even if the process disappears from the app
47. Users who do not update lOutdated information remains in the market lSupport cannot be easily cut off The problem becomes more complex
48. Just looking at it does not make the code healthy
49. Sorting out puzzling specifications lIs it being used? lEstablishment of overall consistency lAwareness of the end Past
50. Gradually suppressing the impact lSupport for both & penetration of migration processing lAllowing for temporary waste lEnd of support lSupport limit： 2 years Current
51. Do not bring external specification s inside lExternal specifications are absorbed in the outer-most portion of the application lSeparate from internal specifications lArchitecture Current
52. Specifications that do not result in future technical debt l Preparing for migration l What we are making now will definitely become obsolete someday l Proposing specifications that do not leave debts to the future l Will anyone in the future be able to maintain it? Future
53. To maintain code health l Identifying unnecessary specification l Tenacious migration over a long span of time l Looking to the future and considering specifications that will not cause technical debt
54. Summary Specifications and design Proposing healthy specifications to maintain healthy code Framework and code design Sparing no effort to make things easy App lifespan Clean the slate and create specifications that do not cause future debt
55. Do ordinary things as a matter of course
56. Thank You