Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

iOSDC 2018 Presentation - Casual Talk

304 vues

Publié le

Working with a global app in a multi-cultural environment, I believe the most important thing is communication

Publié dans : Ingénierie
  • Soyez le premier à commenter

iOSDC 2018 Presentation - Casual Talk

  1. 1. Working with a global app @iOSDC Tokyo 2018 Wu Cheng Yuan / Kimi LINE Corporation 2018/08/30
  2. 2. First time to iOSDC •
  3. 3. First time to iOSDC • w
  4. 4. Situation setup • Imagine you’re working on an app that releases worldwide. And you have colleagues in several offices in Japan, Taiwan, USA working on the same code base. • What problems you may encounter and how to prevent them?
  5. 5. Requirement Case – Different User Preference • Users may have different preference about data, layout, and even view flows • To understand the user preference of a new feature/function: • We can do user sampling and user study to understand user preference • We can do A/B testing to acquire more user preference data
  6. 6. Requirement Case – Different User Preference 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Japan User preference Type A Type B • What would you do?
  7. 7. Requirement Case – Different User Preference (cont.) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Japan Taiwan Korea USA User preference Type A Type B • What would you do?
  8. 8. Requirement Case – Different User Preference (cont.) • 1) provide a default layout , but allow user to customize • • Too many combination of customization could be hard to testing and extend new features in the future
  9. 9. Requirement Case – Different User Preference (cont.) • 1) Provide a default layout , but allow user to customize • • Too many combination of customization could be hard to testing and extend new features in the future • 2) Design different layout for different country • Still raise some complexity of code and testing
  10. 10. Requirement Case – Different User Preference (cont.) 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Japan Taiwan Korea USA User preference Type A Type B • When you add more metrics, things get more complicated… Income/user B > A Income/user B > A Income/user A > B Income/user A > B
  11. 11. Requirement Case – Different User Preference (cont.) • 1) Provide a default layout , but allow user to customize • • Too many combination of customization could be hard to testing and extend new features in the future • 2) Design different layout for different country • Many location control, still raise the complexity of code and testing • 3) Design different layout or separate features for different user targets – e.g., QQ messenger – normal, lite, international, work
  12. 12. Requirement Case – Different User Preference (cont.) • 1) Provide a default layout , but allow user to customize • • Too many combination of customization could be hard to testing and extend new features in the future • 2) Design different layout for different country • Many location control, still raise the complexity of code and testing • 3) Design different layout or separate features for different user targets – e.g., QQ messenger – normal, lite, international, work • 4) Provide a unique layout for all users & countries • You have confidence what you provide is best, or you want to train users
  13. 13. Requirement Case – Different User Preference (cont.) • There’s no one best solution for all cases • Every decision you made at requirement will affect your future development, testing and maintenance • You should let planner know the technical issues, concerns and boundary to help decision making
  14. 14. Implementation & Testing Case – Coding style & PR review • Uniform coding style is important • Use some documentation guidelines with PR reviews • When there are several teams, spread in different offices, and that might even have time difference, usually each team would do it’s own PR review.
  15. 15. Implementation & Testing Case – Coding style & PR review • Uniform coding style is important • Use some documentation guidelines with PR reviews • When there are several teams in different offices that might even have time difference, usually each team would do it’s own PR review. • Human are not machines, and it’s time wasting to make comments on every style mistake • To be more strict on the style: • Some helpful 3rd library style enforcement tool like SwiftLint • Make a specific group of people do a final review for all code diff before each app release • Do not merge code before it passes the style check.
  16. 16. Things only gets worse when you leave it for tomorrow I will start diet tomorrow… Photo by Tristan Gassert on Unsplash
  17. 17. Implementation & Testing Case - I found a bug • One day John found a small bug on his app. Although it’s not within his responsibility, it’s simple so he spent 20 minutes and solves it. He feels so good to make the app become better!
  18. 18. Implementation & Testing Case - I found a bug • One day John found a small bug on his app. Although it’s not within his responsibility, it’s simple so he spent 20 minutes and solves it. He feels so good to make the app become better! • No communication, his colleague who is responsible for the feature also tries to solve the bug at the same time but end up with code conflicts. • No tracking record, QA didn’t know the bug and didn’t test the affecting scope. • At the end the fix causes some side effects and makes the app crash… • A small mistake could snowballing into a big loss
  19. 19. Maintenance Case – who can tell me what is the feature? • Another day John is refactoring a snap of code that has dependencies with a US-limited feature developed by some US engineers. He asks his japan colleagues and find out no one knows it… He then tries to ask US colleagues but find out there’s time difference… so he has to wait another day for the answer…
  20. 20. Maintenance Case – who can tell me what is the feature? • Another day John is refactoring a snap of code that has dependencies with a US-limited feature. He asks his japan colleagues and find out no one knows it because it was developed by some US engineers. He then tries to ask US colleagues but find out there’s time difference… so he has to wait another day for the answer… • There might be no documentation • There is documentation, but John cannot find it • It is important to write document, and also make it readable and searchable
  21. 21. Summary
  22. 22. Summary
  23. 23. Summary
  24. 24. Summary (cont.) • Many tools and ways to facilitate communication • code comments • documentation, UML • PR reviews • project management tools • face-to-face & instant messaging tools • etc. • Many standard rules and processes should be setup with those tools. • Making some template format for documentation
  25. 25. Summary (cont.) • Communication is not only with your engineer colleagues • With future engineers • With planners to do project scheduling • With QAs to do regression testing • Communication takes time, but it will save more time.
  26. 26. Thank you! Wu Cheng Yuan / Kimi Cases used in the slide are personal experience, not directly related to LINE Corporation

×