Gerrit/Code review/cs

Toto je průvodce revizí a slučováním příspěvků do úložišť kódu Wikimedie, napsaný primárně pro vývojáře "provádějící" recenze kódu.


 * Vývojáři, kteří odesílají kód ke kontrole, viz Kontrola kódu.
 * Úvod do nástroje Gerrit (komentování kódu; porovnání sad patchů) najdete ve webovém průvodci Gerritem.

Cíle

 * Poskytujte rychlé recenze, abyste se vyhnuli bitrotu a pocitům opuštěnosti. Rychlá zpětná vazba povzbuzuje vývojáře, aby nadále přispívali, a pomáhá tak rozšířit naši základnu přispěvatelů.
 * Buď milý. Přispěné záplaty jsou dárky. Recenze ovlivňují vnímání dobrovolníka o celém projektu.
 * Z dlouhodobého hlediska povzbuzujte přispěvatele kódu, aby se také stali recenzenty.



Hledání oprav ke kontrole
Je zde spousta kódu ke kontrole. Jak rozdělit úkol na lépe zvládnutelné části?

Existuje několik základních vzorů:



Podle projektu
Pokud jste správce, zvažte nastavení e-mailových upozornění na nové sady patchů ve vašich projektech (úložištích) prostřednictvím "Watched Projects" v Gerritu. Případně se můžete přidat do Gerrit Reviewer Bot, který vás automaticky přidá jako recenzenta do každé nové sady patchů.


 * Identifikujte hlavní části práce nebo sady souvisejících revizí. Dobrým způsobem, jak toho dosáhnout, může být rychlý chronologický přehled. Nebo si můžete vybrat úložiště s mnoha otevřenými sadami změn.
 * Otevřete všechny stránky changesetů jako karty v okně prohlížeče. Otevřete příslušné soubory v textovém editoru.
 * Zkontrolujte nové nebo neznámé soubory jako celek. Vyberte sadu změn s hlavní změnou v příslušném souboru a zkontrolujte ji.



Podle autora

 * Vyberte autora s (mnoha) otevřenými sadami změn, načtěte jej do Gerritu.
 * Procházejte revize chronologicky nebo postupujte po jednom tématu/úložišti.
 * Tato metoda umožňuje recenzentovi poznat jednotlivé vývojáře: Jejich dovednosti, chyby a zájmy. Práce má smysl pro pokrok a kontinuitu.

Pokud vás již někdo přidal jako potenciálního recenzenta a víte, že patch nebudete recenzovat, odeberte se ze seznamu recenzentů.



Noví přispěvatelé do našich projektů
You can add (some of) the queries below to your menu by editing your user preferences. A "new contributor" is defined as a person who has contributed five or less changesets in total.


 * Open changesets by new contributors successfully verified by Jenkins bot and awaiting reviewer feedback
 * Review the patch if you are familiar with the repository and make a decision (CR±1 or CR±2).
 * Open changesets by new contributors successfully verified by Jenkins bot and approved by a reviewer (CR>0)
 * Help make a decision (CR±1, or CR-2, or CR+2 if you have +2 rights for the repository).
 * Open changesets by new contributors successfully verified by Jenkins bot and disapproved by a reviewer (CR<0)
 * Ask if the contributor needs any help and if the contributor plans to continue improving the changeset.
 * Open changesets by new contributors not successfully verified by Jenkins bot
 * Ask if the contributor needs any help and if the contributor plans to continue improving the changeset.
 * The results of the queries above are all included in this single query: All open changesets by new contributors

Chronological (and Reverse Chronological)

 * Start at the oldest open changeset, review until you finish the queue. Alternately, start at the latest revision and read each diff in turn until you reach the end. This approach is good for minor revisions, but requires constant switching between projects and their contexts.

Is it wanted

 * The very first question is whether the contribution is a good idea. If the contribution is not helpful or does not align with the direction and scope of the project, explain and provide feedback on better ideas.

General

 * Contributed code should work as advertised, that is, any bugs found in the code should be fixed. (But be careful not to blame the current developer for code written by a previous developer.)
 * Maintain backwards compatibility for stable interfaces if this is relatively simple to do.
 * If a breaking change is required in order to make significant improvements, make sure the Stable interface policy is followed.
 * Read relevant bug reports or documentation.
 * Familiarise yourself with any relevant technical issues. Read relevant specifications or manual sections.

Performance

 * Code that is run many times in a request, or code that is run on startup, should be reviewed for performance (e.g. by a member of the Wikimedia Performance Team). Suspicious code may need to be benchmarked.
 * Any web-accessible code which is very inefficient (in time, memory, query count, etc.) should be flagged for a fix (e.g. by creating a task for Performance Team in Phabricator).
 * Database schema changes or changes to high-traffic queries should be reviewed by a database expert. (A corresponding Phabricator task should have the tag "schema-change" associated.)

Design

 * Does this change make the user experience better or worse for end users? If it has a user experience or visual design impact, consider consulting or the design mailing list, or one of the design maintainers.

Style

 * Ensure the coding style conventions are followed, such as whitespace, line length, brace placement, etc.

Readability

 * Functions should do what their names say. Choosing the correct verb is essential, a get* function should get something, a set* function should set something.
 * Variables names should use English, abbreviations should be avoided where possible.
 * Doc comments on functions are preferred.
 * Overly-complicated code should be simplified. This usually means making it longer. For instance:
 * Ternary operators (?:) may need to be replaced with if/else.
 * Long expressions may need to be broken up into several statements.
 * Clever use of operator precedence, shortcut evaluation, assignment expressions, etc. may need to be rewritten.
 * Duplication, whether within files or across files, should be avoided.
 * It is bad for readability since it's necessary to play "spot the difference" to work out what has changed. Reading many near-copies of some code necessarily takes longer than reading a single abstraction.
 * It is bad for maintainability, since if a bug (or missing feature) is found in the copied code, all instances of it have to be fixed.
 * Some new developers might copy large sections of code from other extensions or from the core, and change some minor details in it. If a developer seems to be writing code which is "too good" for their level of experience, try grep'ing the code base for some code fragments, to identify the source. Guide the developer towards either rewriting or refactoring.
 * Taking shortcuts can be counterproductive, since the amount of time spent figuring out the shortcut and verifying that it works could have been spent just typing out the original idea in full.

Security

 * The reviewer should have read and understood the security guide and should be aware of the security issues discussed there.
 * There should not be the remotest possibility of arbitrary server-side code execution. This means that there should be no eval or create_function, and no /e modifier on preg_replace.
 * Check for text protocol injection issues (XSS, SQL injection, etc.) Insist on output-side escaping.
 * Check any write actions for CSRF.
 * Be wary of special entry points which may bypass the security provisions in WebStart.php.
 * Be wary of unnecessary duplication of security-relevant MW core functionality, such as using $_REQUEST instead of $wgRequest, or escaping SQL with addslashes instead of $dbr->addQuotes.
 * Only if you work on ancient code: Check for register_globals issues, especially classic arbitrary inclusion vulnerabilities. (Register Globals has been removed in PHP 5.4.0 and MediaWiki ≥1.27 requires PHP ≥5.5.9.)
 * If in doubt, consider contacting the Wikimedia Security Team.

Architecture

 * Names which are in a shared (global) namespace should be prefixed (or otherwise specific to the extension in question) to avoid conflicts between extensions. This includes:
 * Global variables
 * Global functions
 * Class names
 * Message names
 * Table names
 * The aim of modularity is to separate concerns. Modules should not depend on each other in unexpected or complex ways. The interfaces between modules should be as simple as possible without resorting to code duplication.
 * Check against the Architecture Principles.

Logic

 * Point out shortcuts and ask the developer to do a proper job.

Giving positive feedback

 * If you want to help to review the code, but don't feel comfortable (yet) making the final decision, you can use  in Gerrit and indicate whether you've "verified" and/or "inspected" the code.
 * If the revision is good and has passed all tests above, mark it  in Gerrit. If you are particularly impressed by someone's work, say so in a comment. When you mark a commit with , you're saying:
 * I've inspected this code, and
 * the code makes sense, and
 * the code works and does something that we want to do, and
 * the code doesn't do anything that we don't want it to do, and
 * the code follows our development guidelines, and
 * the code will still make sense in five years.

Giving negative feedback

 * If the revision is trivial, broken and has no obvious value, mark the commit as "Code-Review -2"
 * If the revision has issues but also has some utility, or is showing signs of heading in the right direction, mark it  and add a comment explaining what is wrong and how to fix it.  Never mark something   without adding a comment. If someone marks your code   it means that your code is good, but needs improvement.

You have to weigh up the costs and benefits of each course of action. If you reject the change completely, then that change will be lost, and the developer may be discouraged. If you tolerate the fault, the end product will suffer. If you fix it yourself, then you're letting yourself get distracted, and perhaps you're making the developer believe that it is acceptable to submit low-quality code and then let someone else worry about the details.

General guidelines on comment style, especially when giving negative feedback:
 * 1)  Focus your comments on the code and any objectively-observed behavior, not motivations; for example, don't state or imply assumptions about motivating factors like whether the developer was too lazy or unexperienced to do things right. Ask questions instead of making demands to foster a technical discussion: "What do you think about...?" "Did you consider...?" "Can you clarify...?"
 * 2)  Be empathetic and kind. Recognise that the developer has probably put a lot of work in their idea, and thank them for their contribution if you feel comfortable and sincere in doing so. "Why didn't you just..." provides a judgement, putting people on the defensive. Be positive.
 * 3)  Let them know where they can appeal your decision. For example, invite them to discuss the issue on wikitech-l or on IRC.
 * 4)  Be clear.  Don't sugarcoat things so much that the central message is obscured.
 * 5)  Most importantly, give the feedback quickly. Don't just leave negative feedback to someone else or hope they aren't persistent enough to get their contribution accepted.