Android for workgroups

People don't work alone in a company. Working in a proactive way it's really important. Working as a team is a key feature inside a company.

Transcript

1. Android for WorkGroups: Organizing the Code and the Team Jorge Juan Barroso Carmona Android Expert @flipper83 jorge@karumi.com
2. Most software is created by teams. Teams are most effective when the team members collaborate professionally. It is unprofessional to be a loner or a recluse on a team. Uncle Bob
3. • XP • Scrum • Pair Programming • Lean • Kanban Work methodology Image credit: http://www.maxxor.com/software-development-process
4. • Distributed version control • Branch per feature • MicroComits • Pull Request • Code Reviews • Travis Green • CheckStyle Version control system Integration branch2 branch1 Release Al market branch3
5. • two engineers review you code • Guidelines • Feedback • “It’s nothing personal” • Code smells Code reviews You are not your code
6. • static code analysis • Follow you own guidelines • Easy to read / Easy for talk • Lint • square check style: https://github.com/square/java-code-styles Check style
7. • Continuous Inspection of code quality • SonarQube • Take decision based on code quality • Do refactors Code quality
8. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." Martin Golding
9. • Safe Refactor • “Having a strong test suite that covers your code is a precondition for refactoring” @Fernando_cejas • Eating your own dog food • Testable code write test
10. • Unit Test • Integration test • Mocks. Mockito and Robolectrics • Acceptance test • Robotium. Calabash-cucumber Kind of test
11. • Jenkins • Save integration and live • nightly build • build broken Continous integration
12. • Design methodology • Write code base on test. • BDD. Acceptance criteria TDD and BDD
13. A good architecture allows you to defer framework decisions. A good architecture allows frameworks to act as plugins to the app. Robert Martin “The database is a detail, a hardware detail. We would not use one at all if all our data could fit in memory for ever”
14. Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
15. • Most problems has been resolved • Easy for talk • Antipatterns Design patterns
16. • based on TDD • GUI is difficult to test • Think on business logic • Events uncouple our presenter Presenter First V P M Dashed lines are events, solid are object messaging
17. • Independent framework • Testable • Independent of UI • Independent of Database/external agency Clean architecture
18. • Hexagonal architecture aka Ports and adapters • Onion Architecture • Screaming Architecture • DCI • BCE Other architectures
19. • Clean Code, Robert C. Martin • Clean Coders, Robert C. Martin • Refactoring, Improving the design of existing code. Martin Fowler • Design Patterns: Elements of Reusable Object- Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides • Code complete 2. Steve McConnell • Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin • Real world git workflows. Stefan Saasen • Integrated Tests Are A Scam. J.B. Rainsberger Some links and books
21. QUESTIONS? @flipper83 jorge@karumi.com