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

Joining an Android Project

Joining an Android Project

Someone asks you to join an existing project. You need to maintain and build new features on an existing app. And you will have new team members to work with. Let's talk about auditing Android projects, create a work plan, collaborate with team mates and get things done.

Sérgio Santos

October 11, 2017
Tweet

More Decks by Sérgio Santos

Other Decks in Technology

Transcript

  1. ➔ Version control ➔ Code reviews ➔ Quality assurance ➔

    Release process ➔ Crash monitoring Development Process
  2. ➔ Layouts ➔ Styles & themes ➔ (Vector) Drawables ➔

    Values (strings, dimens…) Resources
  3. ➔ Dependency injection ➔ MVP/MVVM ➔ Repositories ➔ Abstractions ➔

    UI: fragments, custom views… ➔ RxJava Design Patterns
  4. ➔ API ➔ Offline ➔ Storage ➔ Push notifications ➔

    Location ➔ Camera Custom Complexity
  5. ➔ Manual testing plan ➔ Unit testing ➔ Instrumentation testing

    ➔ Integration testing ➔ Continuous integration Testing
  6. Most times the team already: ➔ knows the state of

    the project ➔ wants to improve things ➔ understands the concepts Now they can use you as leverage to change things. Team effort
  7. Gain trust before changing things. Discuss patterns, share examples. Join

    every team member in the conversation. Discuss, discuss, discuss
  8. Most companies: ➔ Don’t have the budget ➔ Need new

    features and bugs fixed And you still don’t have the bigger picture. Avoid the big rewrite
  9. The goal is for every team member to: ➔ have

    the courage to question decisions to improve the project ➔ not be afraid to change things Continuous improvement
  10. Be thorough but humble in code reviews. Don’t force it,

    it’s all subjective. Be willing to compromise. Be the example. Continuous improvement
  11. Everyone should agree on the best practices. New features should

    follow them, old features should migrate towards them. Make a plan
  12. Suggestions on where to start: ➔ Group features into packages

    ➔ Extract and group external calls: ◆ API, database, storage, preferences ➔ Move code out of Android classes: ◆ Activities, fragments, views, services... Low-hanging fruit
  13. ➔ Break things down ◆ Prefer small and specific, not

    big and general ➔ Abstract use cases ◆ Prefer ErrorDisplayer instead of SnackbarHelper ➔ Extract duplicated code (≧3 times) ➔ Let Android Studio help: ◆ refactor, refactor, refactor Low-hanging fruit
  14. A big effort short term for a long term reward.

    So you need to be persistent. More crucial for some business than others, but always worth doing. Testing
  15. You can write functional tests independently of how bad the

    code is. You might need deal with state, API calls, test servers, etc.. Functional Testing
  16. It depends on good code practices, so it’s harder to

    do on legacy code. Start doing it on new or refactored code. Unit Testing
  17. ➔ Start testing the more valuable and complex parts ➔

    Need to fix a bug? Reproduce it with a test ➔ Make sure the rest of the team runs the tests as well ◆ Aim to have Continuous Integration Testing Best Practices
  18. ➔ Working Effectively with Legacy Code ◆ Book by Michael

    C. Feathers ➔ Karumi’s Android Audit ◆ https://github.com/Karumi/AndroidAudit ➔ Kickstarter’s open source app ◆ https://github.com/kickstarter/android-oss Resources