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.

Transcript

1. Hello! this is Joining an Android Project GDG Devfest Lisboa 2017 Sérgio Santos @sdsantos
2. Founder and Android Developer at Bloco About me
3. Bloco Product studio specialized in Android Coimbra, Portugal
4. Joining an Android Project?
9. Audit
10. ➔ Version control ➔ Code reviews ➔ Quality assurance ➔ Release process ➔ Crash monitoring Development Process
11. ➔ SDK version ➔ Dependencies version ➔ Unusual dependencies ➔ Multidex ➔ Build tasks Build
12. ➔ Package organization ➔ Styleguide ➔ Naming ➔ Architecture Structure
13. ➔ Layouts ➔ Styles & themes ➔ (Vector) Drawables ➔ Values (strings, dimens…) Resources
14. ➔ Dependency injection ➔ MVP/MVVM ➔ Repositories ➔ Abstractions ➔ UI: fragments, custom views… ➔ RxJava Design Patterns
15. ➔ API ➔ Offline ➔ Storage ➔ Push notifications ➔ Location ➔ Camera Custom Complexity
16. ➔ Manual testing plan ➔ Unit testing ➔ Instrumentation testing ➔ Integration testing ➔ Continuous integration Testing
17. Plan
19. You don’t know the: ➔ original requirements ➔ full picture ➔ conditions Be Humble
21. 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
22. Gain trust before changing things. Discuss patterns, share examples. Join every team member in the conversation. Discuss, discuss, discuss
23. 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
24. 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
25. Be thorough but humble in code reviews. Don’t force it, it’s all subjective. Be willing to compromise. Be the example. Continuous improvement
26. Work
27. Everyone should agree on the best practices. New features should follow them, old features should migrate towards them. Make a plan
28. 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
29. ➔ 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
31. Always leave the campground cleaner than you found it.
33. 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
34. 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
35. 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
36. ➔ 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
37. When all else fails...
39. Keep working on it. Be persistent. The best decisions shine in the long run. Just kidding...
40. Resources
41. ➔ 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
42. Thanks! this was Joining an Android Project GDG Devfest Lisboa 2017 Sérgio Santos @sdsantos