Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Make Your App Production Ready

Make Your App Production Ready

A brief synopsis of the session:
1. How to scale production apps
2. How to maintain a good architecture and manage the states
3. How to write clean code and follow Solid principles
4. What mistakes to avoid when writing code for a feature
5. How to not lose calm when Adhoc tasks come up
6. How to balance working in a team and progress towards leadership and ownership
7. Roadmap to becoming a better developer

Session Link : https://www.youtube.com/watch?v=OuafF5Q_qUg&t=426s&ab_channel=KotlinKolkata

38f77168b7c5802adc9cc3a5cfcf031b?s=128

Niharika Arora

November 28, 2020
Tweet

Transcript

  1. Make your App Production Ready

  2. Agenda Process & Execution Mistakes to Avoid Architecture & Maintenance

    01 03 04 02 05 Error Handling Team work & Balance 06 Best Practices
  3. Hello! Niharika Arora Google Developer Expert , Android @1mg @theDroidLady

  4. Architecture & Maintenance Why do we care??? 01

  5. Excuses • We don’t need an architecture.

  6. Excuses • We don’t need an architecture. • Don’t have

    enough time for architecture.
  7. None
  8. Software Architecture 01.1

  9. A plan that describes a set of aspects and decisions

    that are important to a software.
  10. Why is Software architecture important? • A Basis for Communication

  11. Why is Software architecture important? • A Basis for Communication

    • Early Design Decisions
  12. Why is Software architecture important? • A Basis for Communication

    • Early Design Decisions • Transferability of the model
  13. App Architecture Let’s understand the significance 01.2

  14. — App architecture Placement of classes in the system and

    how they communicate. We draw an overview of roles and responsibilities of these classes while grouping them
  15. None
  16. Few things to better understand it !! • Language &

    Platform Agnostic
  17. Few things to better understand it !! • Language &

    Platform Agnostic Clean Code & S.O.L.I.D Principles
  18. Clean Code • Modular

  19. Clean Code • Modular • Stable

  20. Clean Code • Modular • Stable • Scalable

  21. Clean Code • Modular • Stable • Scalable • Testable

  22. Clean Code • Modular • Stable • Scalable • Testable

    • Maintainable
  23. S.O.L.I.D Principles • Single Responsibility Principle

  24. S.O.L.I.D Principles • Single Responsibility Principle

  25. S.O.L.I.D Principles • Single Responsibility Principle Bad Code

  26. S.O.L.I.D Principles • Single Responsibility Principle

  27. S.O.L.I.D Principles • Single Responsibility Principle Good Code

  28. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle

  29. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle

  30. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle
  31. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle
  32. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle
  33. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle • Interface Segregation Principle
  34. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle • Interface Segregation Principle
  35. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle
  36. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle Bad Code
  37. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle
  38. S.O.L.I.D Principles • Single Responsibility Principle • Open/Closed Principle •

    Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle Good Code
  39. Few things to better understand it !! • Language &

    Platform Agnostic • Improves Changeability
  40. Few things to better understand it !! • Language &

    Platform Agnostic • Improves Changeability • Learn when it is important and essential both.
  41. —Robert C.Martin The Goal of an architecture is to minimize

    the human resources required to build and maintain the required system
  42. Process & Execution How to plan, process and execute? 02

  43. Few things to keep in mind • Make & Test

    for a variety of devices
  44. Few things to keep in mind • Make & Test

    for a variety of devices • Keep your early apps with minimal features
  45. Few things to keep in mind • Make & Test

    for a variety of devices • Keep your early apps with minimal features • Proguard Rules
  46. Few things to keep in mind • Make & Test

    for a variety of devices • Keep your early apps with minimal features • Proguard Rules • Different Production and Pre-Production environments.
  47. None
  48. None
  49. Same will be there for DevConfig with different URLs

  50. Few things to keep in mind • Make & Test

    for a variety of devices • Keep your early apps with minimal features • Proguard Rules • Different Production and Pre-Production environments. • Be careful with what you declare in Manifest.
  51. Few things to keep in mind • Make & Test

    for a variety of devices • Keep your early apps with minimal features • Proguard Rules • Different Production and Pre-Production environments. • Be careful with what you declare in Manifest. • Keystore : Own it, secure it.
  52. Few things to keep in mind • Make & Test

    for a variety of devices • Keep your early apps with minimal features • Proguard Rules • Different Production and Pre-Production environments. • Be careful with what you declare in Manifest. • Keystore : Own it, secure it. • Cover your business logic in Unit Tests.
  53. None
  54. Learn Unit Testing • Slides : https://speakerdeck.com/niharika28/unit-testing-what-why-and-how • Source Code

    : https://github.com/niharika2810/UnitTesting-MVVM-Kotlin-Koin-Coroutines-Sample • Blog : https://medium.com/1mgofficial/unit-testing-in-mvvm-kotlin-databinding-ba3d4ea08f0e
  55. Error Handling 03 Handle Errors elegantly.

  56. None
  57. Error Handling • Explain what went wrong with a meaningful

    message.
  58. Error Handling • Explain what went wrong with a meaningful

    message.
  59. Error Handling • Explain what went wrong with a meaningful

    message.
  60. Error Handling • Explain what went wrong with a meaningful

    message. • No message is bad.
  61. Error Handling • Explain what went wrong with a meaningful

    message. • No message is bad. • Show messages elegantly.
  62. Mistakes 04 Key points to consider while developing app for

    billions
  63. Key points to consider: • Test thoroughly.

  64. Key points to consider: • Test thoroughly • Beta testing.

  65. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there.
  66. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there. • Handle No- Internet cases.
  67. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there. • Handle No- Internet cases. • Keep your splash screen with minimal overhead
  68. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there. • Handle No- Internet cases. • Keep your splash screen with minimal overhead • Use Play store Rollout feature
  69. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there. • Handle No- Internet cases. • Keep your splash screen with minimal overhead • Use Play store Rollout feature • Keep releasing patch for major fixes.
  70. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there. • Handle No- Internet cases. • Keep your splash screen with minimal overhead • Use Play store Rollout feature • Keep releasing patch for major fixes. • Develop for multiple platforms after analyzing user behavior only.
  71. Key points to consider: • Test thoroughly • Beta testing.

    • Use what’s already there. • Handle No- Internet cases. • Keep your splash screen with minimal overhead • Use Play store Rollout feature • Keep releasing patch for major fixes. • Develop for multiple platforms after analyzing user behavior only. • Many more….
  72. Team Work & Balance 05 How to work in a

    team & progress towards leadership and ownership?
  73. None
  74. — Steve Jobs Great things in business are never done

    by one person.
  75. Team Work • Know and respect other team member’s work

  76. Team Work • Know and respect other team member’s work.

    • Avoid criticism.
  77. None
  78. Team Work • Know and respect other team member’s work

    • Avoid criticism. • Communicate everyday, everyway.
  79. Team Work • Know and respect other team member’s work

    • Avoid criticism. • Communicate everyday, everyway. • Avoid conflicts.
  80. Team Work • Know and respect other team member’s work

    • Avoid criticism. • Communicate everyday, everyway. • Avoid conflicts. • Creativity and innovations are the norms.
  81. Team Work • Know and respect other team member’s work

    • Avoid criticism. • Communicate everyday, everyway. • Avoid conflicts. • Creativity and innovations are the norms. • Show gratitude.
  82. Best Practices 06

  83. Suggestions • Try to keep your app size small, Learn

    App bundles
  84. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code
  85. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code • Don’t try to include everything just because it's in trend.
  86. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code • Don’t try to include everything just because it's in trend. • Use Third party libraries wisely.
  87. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code • Don’t try to include everything just because it's in trend. • Use Third party libraries wisely. • Handle Configuration changes
  88. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code • Don’t try to include everything just because it's in trend. • Use Third party libraries wisely. • Handle Configuration changes • Keep buffer for ad-hoc tasks
  89. None
  90. Ad-hoc tasks Is all the work feasible? Redirect from your

    leaders. Know the impact and weightage. Retrospect
  91. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code • Don’t try to include everything just because it's in trend. • Use Third party libraries wisely. • Handle Configuration changes • Keep buffer for ad-hoc tasks • Try to implement Unit tests and CICD
  92. Suggestions • Try to keep your app size small, Learn

    App bundles • Keep committing code • Don’t try to include everything just because it's in trend. • Use Third party libraries wisely. • Handle Configuration changes • Keep buffer for ad-hoc tasks • Try to implement Unit tests and CICD • Handle security decision on server side if possible.
  93. Just writing the code is not enough, Writing in an

    efficient way is the real challenge. Do mistakes & learn.
  94. Let’s Catch up • Github : https://medium.com/@nik.arora8059 • Medium :

    https://medium.com/@nik.arora8059 • LinkedIn : https://www.linkedin.com/in/thedroidlady/ • Twitter : https://twitter.com/theDroidLady • Portfolio : https://thedroidlady.com/
  95. CREDITS: This presentation template was created by Slidesgo, including icons

    by Flaticon, and infographics & images by Freepik. Thank You nik.arora8059@gmail.com @theDroidLady Do you have any questions?