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
   

   View Slide

2. View Slide

3. agenda
   • what’s that thing called Phabricator
   • on code reviews and tracking
   • Phabricator applications
   3
   

   View Slide

4. 4
   who`s that guy?
   

   View Slide

5. Peter Foerger
   • DevOps Engineer
   • dkd Internet Service GmbH
   • TCCI
   • TCCD
   • @bauschan
   5
   

   View Slide

6. introduction
   6
   

   View Slide

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
   

   View Slide

8. under the hood
   • depends on 3 packages
   • libphutil
   • phabricator
   • arcanist

   • source
   • https://github.com/phacility
   8
   

   View Slide

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
   ......
   9
   

   View Slide

10. 10
    code reviews
    

    View Slide

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
    

    View Slide

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
    

    View Slide

13. 13
    »But code reviews take time!«
    Sure, they take time. But that time isn't wasted–far from it.
    

    View Slide

14. 14
    »When done right, code reviews actually
    save time in the long run«
    

    View Slide

15. in practise
    • share the load
    • review before merging
    • use peer pressure to your advantage
    15
    

    View Slide

16. best practise
    16
    

    View Slide

17. everyone
    17
    

    View Slide

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
    

    View Slide

19. having your code reviewed
    19
    

    View Slide

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
    

    View Slide

21. reviewing code
    21
    

    View Slide

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
    

    View Slide

23. 23
    implementation
    

    View Slide

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
    

    View Slide

25. View Slide

26. View Slide

27. View Slide

28. View Slide

29. View Slide

30. View Slide

31. View Slide

32. dkd sagt Danke
    32
    

    View Slide