Discuss.Plan.Code.Review.Test.

Introduction to the software development platform Phabricator and how we use it dkd Internet Service GmbH.

Transcript

1. discuss. plan. code. review. test. introduction to Phabricator dkd Internet Service GmbH TYPO3 Developer Days 2017 1
3. agenda • what’s that thing called Phabricator • on code reviews and tracking • Phabricator applications 3
4. 4 who`s that guy?
5. Peter Foerger • DevOps Engineer • dkd Internet Service GmbH • TCCI • TCCD • @bauschan 5
6. introduction 6
7. introduction • started as Diffcamp at Facebook • open source • written in PHP • users: Dropbox, Asana, Quora, Uber, … • supports Git, Mercurial, SVN for SCM • for developers from developers • moderate plugin system • use as many or as few Phabricator services as you like • supports: issue tracking, scrum boards, source auditing, code review, more! 7
8. under the hood • depends on 3 packages • libphutil • phabricator • arcanist
 • source • https://github.com/phacility 8
9. > 60 databases $ /core/lib/phabricator/bin/storage databases secure_audit secure_calendar secure_chatlog secure_conduit secure_countdown secure_daemon secure_differential secure_draft secure_drydock secure_feed ...<dozens more databases>... 9
10. 10 code reviews
11. so, what exactly is a code review questions • are there any obvious logic errors in the code? • looking at the requirements, are all cases fully implemented? • are the new automated tests sufficient for the new code? • do existing automated tests need to be rewritten? • does the new code conform to existing style guidelines? 11
12. pros • code reviews share knowledge • code reviews make for better estimates • code reviews mentor newer engineers • code reviews should happen across the team in every direction 12
13. 13 »But code reviews take time!« Sure, they take time. But that time isn't wasted–far from it.
14. 14 »When done right, code reviews actually save time in the long run«
15. in practise • share the load • review before merging • use peer pressure to your advantage 15
16. best practise 16
17. everyone 17
18. everyone • accept that many programming decisions are opinions. Discuss tradeoffs. • Ask good questions; don't make demands. • Ask for clarification. ("I didn't understand. Can you clarify?") • Avoid selective ownership of code. ("mine", "not mine", "yours") • Avoid using terms like ("dumb", “stupid"). • Be explicit. Remember people don't always understand your intentions online. • Be humble. ("I'm not sure - let's look it up.”) • Don't use sarcasm. • Keep it real. If emoji, animated gifs, or humor aren't you, don't force them. 18
19. having your code reviewed 19
20. having your code reviewed • be grateful for suggestions. ("Good call. I'll make that change.") • if a review seems aggressive or angry or otherwise personal, consider if it is intended to be read that way and ask the person for clarification of intent • explain why the code exists. • extract some changes and refactorings into future tickets/stories. • link to the code review from the ticket/story. • seek to understand the reviewer's perspective. • try to respond to every comment. 20
21. reviewing code 21
22. having your code reviewed • understand why the change is necessary • communicate which ideas you feel strongly about and those you don't. • identify ways to simplify the code while still solving the problem. • offer alternative implementations, but assume the author already considered them. ("What do you think about using a custom validator here?") • seek to understand the author's perspective. • sign off on the pull request with a or "Ready to merge" comment. 22
23. 23 implementation
24. Phabricator applications • Differential: code reviews • Diffusion: browse repository • Maniphest: tasks and bugs • Herald: notifications • Conduit: API • Arcanist: command line interface • Owners, Calendar, Wiki, Blog, lots more 24
32. dkd sagt Danke 32