Python at Facebook

Editor's Notes

• #21: The three basic components of Configerator are: Configuration composition: it’s the part of the framework that deals with how configuration "source" is composed. Configuration consists of a flat file, which is code reviewed and checked into Git. The source file is validated and compiled into a JSON file, which is also code reviewed and checked into Git. Configuration distribution: A system to detect config file updates in Git, and promptly make them available to all interested clients (usually in approx. 10 seconds for average-sized configs). Uses local disk for fallback if upstream system is unavailable. A Client library: provides a mean to access configs and get notification on configuration updates.
• #22: Configerator provides a library to subscribe and consume configuration (and it supports our main languages, PHP, C++, Python and Go soon). In this picture you see a snippet of Python code that use that library (the ConfigeratorThriftClient class)
• #24: Code review of config changes Configuration changes are subtle and can break things in a very bad way, core reviewing config changes helps. Both source and compiled config files are code-reviewed in Git, changes/history can be much easier to visualize and understand. Automated validation You can import a common library that can be used to make simple tests like validating that a variable is a positive integer, or that some string matches a given regular expression, but you can also write your own complex business logic (people in the Traffic team use configerator to configure internal/external VIPs and drain/undrain traffic on clusters).
• #25: Abstract complexity Using Python as a DSL enables you to abstract away complexity. You only need to know the dial of knobs of an application to configure it, all the nitty gritty complex details are hidden from non-eng or Engs not familiar with the system. Configs can be composed and included in each other, and can be structured hierarchically. Config hierarchies may be independent of the hierarchy of the service that uses it. Client fallback If the configerator infrastructure is down configuration files are still being served (as files are stored in the machine’s file system)
• #29: Code reviews are really important part of our engineering process. However it can become onerous with certain attitudes and disposition by code reviewers. If approached with the wrong attitude it can become counterproductive, demoralize and slow down things unnecessarily. The goal, reviewing code is not writing code Good reviewers should keep in mind that the goal of a reviewers is not to make it so that the code you review looks as if you wrote it. The goal is to agreed on overall direction and ensure certain quality bars are hit. Suggestions are fine, common style guidelines are fine. Nit are not enough If you review comments only include nitpicks or minor style issues that is not a sufficient bar to request changes. Caring about nits is important, you should care, but you shouldn’t allow it to unnecessarily slow down things. You can make those comments still accepting the diff. Trust that your colleague are respectful of the code base and that they will do the right thing. If you don’t trust your colleagues than you and your team should work on that. Stop typing and have a conversation You should avoid long winded discussion on diffs whenever possible. If you are not reaching convergence quickly in a review don’t spent hours debating on comments, just go and talk to the author of the diff  Build trust Often the root cause of code review issues is the a lack of trust. If that’s the case no matter how good the code is, you’ll have hard time reviewing it. Especially true when changing code that someone else owns. You can assume people trust reviewers to be good engineers and make sane decisions but you cannot assume they trust reviewers to have all the knowledge they have when making those decisions. So you should build trust and the best way to do is is to talk and be ready to listen and be open to change. If you think the discussion is going to be controversial you should go to the discussion assuming your are wrong  That doesn’t mean you should not defend your position, they are important but not more important than others.  Find people to emulate. The best way to learn how to review code effectively is to find people who do a good job and emulate and learn from them. It’s a soft skill that is developed with time, good reviewers always make suggestions respectfully, they focus on the more salient and important part of a diff, and never slow people down.
• #30: Making diffs easier to be reviewed: One and Only one thesis: Each diff you send out should endeavor to do only one thing. Do No Harm: your code should follow the Hippocratic Oath: first and foremost do no harm, each diff you send should be a net improvement to the codebase (adding more useful code or remove unused code, or refactoring old code) It is a good reason to mix and match the reviewers to whom you send code. That’s because teammate have a high likelihood to have a direct interest in getting your code shipped. On the other hands non-teammates may have better knowledge of the right way to write the code, but have less of an idea about your end goal, hence why it is always a good idea to mix and match. Write a good test plan You are not your code: code reviews are better when both parties go into the process realizing that only the integrity of the code is at stake, not the one of the coder or reviewer 