Merken

Implementing a Strong Code-Review Culture

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
so in a in a in and you should this and that neural scoff overall feeling right after lunch on like somewhat for coming very excited to be here by the prior the developer with pop up in here today to talk to you about code reviews doing them well and what it means for the culture of your team when you type a place that does them well so let's
start with a show of hands just like an idea where raise that some great of the thinking how many of you encode reviews as a regular part of your day every day already OK and how many of you really enjoy doing them a long OK if you less and how many of you do them because you feel like you have to but that's about equal the all the people is that they really do really enjoy them also submitted because they have OK so why is it that we do
reviews in the 1st place and this is pretty easy right it's the catch bugs there are some many look at every
individual line of code in a more refined what's wrong
not really that's not why it's interesting that I've been doing code reviews for over 10 years now I used to hate them and they were the worst part of my day right we did just for compliance documentation of 1 of my former jobs but now I think the code reviews are 1 of the primary ways that I get better my job every single day so sell them yes when we're gonna have have fewer bugs in the code in code that's been peer reviewed think 0 that is not been period but studies on this show that the level of the way that we get out of out of code review doesn't meet the level of expectation that we have as developers and so that is we think by doing inquiry were getting this much QA when in reality we're getting somewhere down here so why is that well the reason we do code reviews were looking at a slice of a change were looking at the the big death essentially and we can catch since actual issues or problems where you might be calling a method on nil but we can catch the really heinous stuff which happens when your whole system interacts and corrupted data so code reviews good for some level of but catching but it's not the end all be all right so what are they good for RE told you that I think that code reviews make me better every day and I want you all to feel the same way well in
2013 Microsoft in the University of St Lugano in Switzerland that came out with this study expectations outcomes and challenges of modern code review so in that what they did was looked at various teams across Microsof at is a huge organization have several teams with different of the of senior developer junior developers managers everybody and all working on different products and they surveyed all these people ask them what is it you get out of code review what you like about what don't you like about it when done surveying and they watched them Duke of reduced and ask them questions afterward and finally they look at all the feedback was given every comment that was logged in their code review system and they manually classified they said this 1 has to do with and about that they found this 1 has to do with the style common this 1 has to do with a possible alternative solutions so after doing all this work what they found was that people consistently ranked finding bugs very high as a reason for doing code review but in the end it was actually lot less about finding bugs anyone thought the chief benefit they soften code review
were knowledge transfer increased team awareness and finding alternative solutions to problems right that's a lot more interesting and even hunting through code looking for bonds this is this through this process we can prove our king 1 person baldness
studies that that's code review with the discipline of explaining your code to your peers the drive a higher standard of coding I think the process is even more important than the result so really do like that last part in the summer the slide right the proper process is more important result we're talking about today just by going through the process of code review in the right way where b improving regardless of the actual results that were seeing I need the individual change well like the definition here right the discipline of explaining your code your peers I tweak it just a little bit to say that code review is the discipline of discussing your code with your peers Eleanor trying to explain it code review of 1 of the few chances we get to have a black and white conversation about a particular change right we often talk abstractions and become the convenors like this we talking large abstractions about things and those are really comfortable conversations in code review we have to get down to the the implementation details and type of how we apply these things so like so much else that we do it the communication issue if we get better improving code reviews the more really doing is improving the technical communication RT so the study also found that the benefits I cited earlier that were particularly were true team that had a strong code review culture so what is it mean to have a strong code review culture the means it means that your entire team has to embrace the process right everybody has to be involved it can't be something that the senior developers do for the junior developers at the discussion a sore after him so as I mentioned earlier I've been doing code reviews for over 10 years now right and but only in the last 2 the 3 and I started to see a real improvement in 1 getting out of them and myself because of and so why is that I think it's because I'm I'm part of a strong code review culture upper and at up but we often go the clients of various sizes to help them with issues of they're happening right and nobody ever comes to us and says I really need help improving the code review my and never happen but we get on the ground with those teams we often find that there isn't a strong code review culture so that 1 of the challenges we have is how do we get people the have this culture around code reviews there are a lot of little rules that we suggest following our guides the but if you look at them you can really boil them down to to the rules of engagement 2 things that you can do today to start
getting better at code reviews with your team the 1st of them is something that you can do as an author the the 2nd is something that you can do as a reviewer when you're preparing for married providing feedback so 1st as an author what we can do to make sure that our code reviews get off on the right foot the
the so this quote years from Gary data check and he was talking about a social media marketing or something not interesting but but it's also laughable to code reviews believe it or not the so in a code review your content is the code of the day what you've changed right the context is why that's changed your code doesn't exist for its own benefit it solves a problem so the context is what problem is itself that study I cited earlier found that insufficient context is where the chief impediments to a quality review so as not the we need to get we need to know this in down from the word provide excellent contacts around the change so let's have a look at our real world examples this is a committee that Europol request
title you might see come across arena right you type column 1st multicolumn index the specifics here are particularly important in understanding me the problem here there's no y so I can look at this change and I can say well yeah this changes the order of the indexes sort order of columns on multicolumn indexes but I can't I can't tell you that was the best solution the problem you're solving I can't tell I can't really learn anything from it so this is a loss it's not interesting for me to review as just gonna get a thumbs up and move on right actually what I would do the genes like this this comment and say can you provide some more context here right a lot of a lot of time we find happens is somebody updates the pull request rather common to say something like this right so OK so I guess you guys think that's not better but is true that's not that so this is probably a link to get harbor maybe link to juror whatever issue tracker it's right a lot of people do this all relieving snow build provide like a short explanation safe for more details see this take but the but what you're doing there is you're making the reviewer hunt for this contact that they click this issue are they see a good description of what you're doing probably not right that there is C-like like 0 and the report of a problem maybe some discussion back-and-forth about how to solve it and then maybe a link to this pull requester something but they gotta go through all this nigger hunt for that context and put together until they're in the right frame of mind to review the change in the tell you whether or not the right solution so users improvements is not important read this again so what we're doing is identifying the problem with index ordering as we do a part that we do 1st why is the problem where back up was post press docks and those link offer more information if you need it and because this particular change was a change to rails and we'd be concerned of multiple adapters were also going to back up with some icicle documentation and finally where tribal why this is the best solution so that's a lot context right but it's important note that now as summaries coming under review this I know why this changes being made and maybe I did can learn something about how will the column indexes work by reading through some was documentation right this value for me to review the the so as an author of water
provide sufficient context what we're trying to do here like you've been working on this change for 4 hours to days whatever how light to it affects us right the what you need to do is bring the reviewer up to speed like let them know what you learned in this process and put them on equal footing with you so I challenge you provide 2 paragraphs in context with every change you make right and forces that we really painful in there are some changes that it's torturous to describe 2 paragraphs and yes it's going to take you more time but how much more time I don't know like 5 minutes maybe right and avoid the whole round of but that rather questioning I described before like why are you making this to trace we've had that off and the extra bonus is that all that context we saw earlier this to live on in the Committee where squash that modernist save that so rather than that 1 we saw before they had initiated a link to juror link to get up right after go away since we stop paying that bill the bargain histories that stay with us the the receipt out there OK so that we can do as not what is a reviewer what can we do June make it so our feedback is well received the but to call this past don't tell
so here I at the start with it's important note that research is shown as the negativity bias in written communication so that is to say if I have a conversation with you face to face and I give you some feedback or maybe even over the phone just the place where you can hear the tone of my voice hear the inflection you're perceive that 1 way if I give you that same feedback written like in the form of a pull request review is gonna person be perceived much more negatively so it's important were cognizant of this negativity bias in a written communication that we have to overcome this if we want our feedback to be taken in the right way 1 way to do that is to offer compliments and I I would suggest that you do that so if you find something a pull request that is something you learned or it's something you think is done particularly well those a great to call out right and lets everybody know that like I yes you taught me something that's great thank you very much but rather just always nit picking up a change but but there's gonna come a time when you need to provide critical feedback the best thing to do here is to ask questions rather than make demands so I've noticed that when I remember to do this again on the same day I'm looking at 2 different pull request and 1 change I remember but I've should be asking questions and exchange I just make commands I can guarantee which 1 could have better technical discussion which 1 getting be more satisfying for the entirety right the middle 1 where I tried to engage in conversations rather than dictating what addition to so the thing at another example there's an example
extractor service to reduce some of this duplication so this is a command there's no discussion here and opened anything up so if I'm the original author of this change my option here is the do it or enter into what seems like an argument or I just ignore you right and ignoring is probably the worst thing you can do and rather see you argue and another thing important portending notice like this comment here from the reviewer give the author no credit for maybe having thought of already extracting the service and maybe they ruled out for some reason they're waiting for more information so they can make a proper abstraction here so how can we improve this what do you think about extracting a service to
reduce some of this duplication all we've done
is formulated as a question but there's also 2 different ways this can go now right we've opened up a conversation so 1 or more likely ways is value right I can expect in eliminate duplication by extracting the service thanks a lot I take that back to your face a great thanks that's great feedback fixed in this I added that now you feel good as the reviewer because you provide something of value that was well received if you disagree with the change while you're just ask your opinion so feel free right this is significantly less negative than the command right we're really doing is fostering technical discussion code reviews are just like a way for us to have excellent technical discussions with each other so what you think
about is a great conversation over in polar requests did you consider as another thing like you are throwing alternative right or if you're getting lost somewhere can you clarify is a lot better than what the hell's going on here right so these are all ways to soften suggestions and avoid negativity which is going to lead to better discussion there are also excellent ways to provide feedback leave if you are new to a team we're a junior member of the team and somebody more senior than you submit a change I think is a little natural to feel a little tentative about providing feedback but doing in the form of a question is a great way right out years looking to learn and you also have nudging the discussion the way you wanna go once you open with the conversational openers yes then you can break into some practical suggestions by but now you get everybody on the right page felt similarly it works very well giving feedback from somebody senior to somebody more junior made an apprentice or something like that right if I give back commands to apprentices they're going to do it and they will feel great about it maybe they will even be entirely sure what or it I ask a question what I'm really hoping that they'll do is engage right not just so this is pretty simple right already
now is ask a bunch of questions was attacked question marks on everything so we need to be really careful about this it's pretty easy for a question to be like and a not so silent judgment so here's what I see a lot why didn't you just as a
couple things wrong with this actually but if 1 of my pet peeves is this were just they
with a man it so every time I see this I think to myself or sometimes out loud why did you do right side and a bit so that word just simply easily words like that those passed judgment about the difficulty of a solution proposed and they make me when I read those feel like I wasted somebody's time or I missed something obvious is not a good way to feel right so let's look at how you can improve this we give a that were
just is this I mean it's it's less judging break that were just as gone that's great were still putting people on the defensive it's still frames and kind of negatively right why didn't you do something this kind a perfect example of the negativity bias in written communication I had this conversation with you and I said of wine comment here that's not so bad right but if I write this down where you lose any sort of sense of my toner inflection it's gonna come off more negatively for
it is B positive rate reuse use those tools we talked about earlier we ask what you think about can you clarify did you consider those types of things were really tiny images asking the right questions in the right way and what we're after is better technical discussion we're talking about here is the Socratic
method Socratic Method according to Wikipedia mean is based on asking and answering questions to stimulate critical thinking and to eliminate ideas that sounds like exactly we're trying to do right right have critical thinking around the code changes were made were making into to eliminate some potentially alternative solutions were stimulating valuable discussion our full request now verses just throwing comes up the Socratic method works pretty well for Socrates and Plato will probably be OK for us a pull request discussions so those are the 2 things that
really do today right rented these are tools for better technical discussion where do well on our way if we start doing these 2 things there's gonna be a couple issues that come up in practice the 1st is how are we can handle disagreements and the 2nd 1 is that I should be reviewing anyway what's a value thing for me to look at what handle
conflict 1st conflict is good your team needs conflict in order to drive a higher standard of code the debate a good debate healthy debate around a change drives quality and leads to learn right but there are 2 types of conflict 1 of them healthy 1 of the not so much so easy type the healthy type of
conflict is that we don't agree on an issue perfectly fine were not always gonna see i'd it's critical to note is that everybody they have like a minimum bar for quality you need to pass once you reach that minimum quality we were talking about trade-offs going to be really sensitive to the fact that were just talking about trade off right so if you find yourself disagreeing with something you're having this conversation back and forth ask yourself is it because I don't agree with I don't think the qualities of the stuff here or is it because it's not the way I would have done it is not the way you would have done it that's fine right like so there's multiple solution retirement trade-offs here and we can go back and forth all day if we want like Socrates and Plato and all them they can go back and forth all day but they're not shipping software leadership this offered to the user so we need to have some sort of agreement to disagree at some point reasonable people disagree all the time so just make sure you're not arguing in circles is not quite the way you would so what up the 2nd site right we don't agree on the process so this can happen if you have somebody maybe just can encode directly to master where have somebody opening pull requests and ignoring feedback right sloping a pull request because they were told to but they don't value the feedback they don't value process that all value time ultimately my advice on this is to get a father right as a team sit down and decide what it is you want out of code review what you expect right maybe it's that all changes regardless of size are gonna be put through a pull request review and then all feedback will be addressed in some manner or another you know them you have to accept the feedback we have to say like I see that I see your point there but no I really think this is better and I go this way readers I know organ revisited when we get to this other feature enable have more information it that changes something like that right so once you've done that you still don't have those problems but that doesn't solve all those problems that have people can encode directly after is still occasionally have people ignoring feedback so what you do in those situations right if you if you are as resource can encode right the master my advice to you is to review it anyway right go in there and comments on the committee and when you're done follow up with them afterward and say Hey how I know sigma this the master at a couple questions they take a look at when you get a 2nd you we we think in our addresses all in my life can you in the future so Singapore request for the if this continues to happen but it's time to break up the river and right go ahead and pull that change out an open up or request for and start adding the back there it also crucially important the you enlist the help of the team you can't be the 1 always swinging that reverse camera always been 1 cracking down if you are that means you're the only 1 value in it freely 1 willing to actually speak up for a that's that's how we're gonna handle conflict of what about what to review right people ask is a lot like was actually focusing on review from not catching bugs than 1 of my doing right the key is here that everybody can bring their own list of things to look at and that's how we get better from our from each other's expertise the other each other's area of focus I can tell you what works for me to kind give you an idea of the type of stuff that I look for 1st the node and timing I really in what I'm doing reviews on trying to stressed small changes for it I wonder about 10 minutes is a long time for me to spend on a review so I'm really trying to push for is small changes the easier to revive context on right easier to review go through a quick so once we have these small changes the 1st things persuade I'm looking at a single responsibility principle this is the ass from the solid design principles for it does every object in the system have just 1 job if an operator are familiar with solid that's not too particularly important you can kind of focus on the single responsibility principle and the rest of the of the all the LEI entity can if you square can can follow from that single responsibility principle that's why I really like to focus on that 1 naming is a big 1 I focus on a lot right is too hard problems in computer science naming things and cache invalidation n times so good names make things easier to discuss and that's after after good technical discussion means I get a better discussion face-to-face it means I can write these things more naturally so I will definitely focus on names to the point where some people are like you're missing a large picture book like I said I'm trying to make that made easier for discussion complexity is another thing I focus on right other areas of the code like out of this looking at change and see the shape of a change is there there is of the code where the shape looks complex and I'll dive into those a little bit natural break out the can you clarify then sometimes it turns out that like the complexity exists for some future feature we thought we might need a like being catch ship them off to later test coverage as I'm going through change I'm kind of assembling in my head what it is I expect to see protest coverage and if using our spec that comes at the ass so always almost always at the bottom right so I'm looking see like out his public feature back the cover this there is a controllers back the covers this edge case here and the colored unit spectra unit test on you know these methods again out of the model or whatever and not specifically like said looking for box at the task coverage is vital I see above and going to comment on it but I'm not doing your Q and as a lot of places where people are happy to be like well so and so improved it's approved it so this must be good even know they had had a shaky feeling about from the beginning that they were not doing Qs keep saying and like I said everyone has their own areas of expertise of everybody have their own check right personally interested in web security so maybe I'll look at something from that perspective and sure things are up up there maybe have somebody in your team is really great at giving practical performance advice right it's not premature optimization it's great for them to jump in right there's all sorts of England with duplications whatever it is that you're comfortable giving feedback on bring that to the table where you get the best from all of our teammates that way the morning at model learned from the best parts of so 1 thing I did
mention was style his style important yes thank style is important right if you look at a code you with a code based it looks clean inconsistent it gives the impression of a team working together toward something right everybody's on the same page In a neat and tidy codebases like a clean kitchen everything has a place in everything in its place the problem is that study I cited earlier found consistently that people who got people who received a lot of style comments on their code viewed those reviewers kind negatively right they thought they were harping on things that weren't valuable because they're missing big picture things whether this is perception a reality doesn't matter right retirement proving technical discussion so so we feel that way if they feel the discussion is not valuable than is there something we can do about it yes there it's so
my advice 1st to adopt a style guide at this point community style guide you can is the dog out writer you can look at what you've been doing just write it down somewhere request make sure that everybody knows that a argument about style whether using double quotes a single quotes or whatever it is they are going to happen in that style guide not an individual or after you've written down you're outsourcing where you RoboCup JS cents land things like that to handle this style checking for us strength about but we have found CI which is a service right that looks that run these letters on your code and adds comments as if it were a person the difference being it's a bot that providing this feedback so getting into a bike sitting discussion the bot is not very satisfying and you have the right so yes full disclosure that is a art service is however free for open source it's open source itself I think is a great product I don't anything personally to gain from it and yes check it out for that reason so these are the tools that we're gonna
use for a more meaningful technical discussion we start doing these things that we stop providing context we start making sure those authors gonna receive our the back in the right way and we know how to handle we know what we're looking for a review we know how to handle conflict becomes up what we're on our way to here is having a strong code
review culture so a strong could review culture goes beyond the quality of a single change it get to the roots of the type of team that you have so if your team has a strong code review culture what is it that you're going to see well 1st you receive
better code the IRI told you like this is about catching bonds but the code can be better because the discussion improves the solutions I can't tell you how many times I've submitted a pull request and the like that's so my best work that's going right through rate and then 5 minutes later there's 3 males from with feedback at 1st the like and I read the feedback as all totally reasonable and makes a solution even better because somebody else's viewpoint about what they're really good at and it took what I thought was already a good solution it better or maybe eternal solution totally on its head and I was wrong right but the important part is that word through do better we're getting better where better developers you'll be reading code in writing about code every single day right in black concrete examples and like I said really taking the best from each other in these conversations so maybe you're not that and web security but because I keep commenting that you can't pass occurrence that way like you start to learn that think where team ownership of code this means of my code your code their code that's all dead that's gone right at 1 point we all decided that this was a reasonable change right maybe was the best solution but we got given what we know at this time this is good so the whole team is going on the code now we're going out that is versatility right there's no more of this person handles the issues with the sales dashboard and that this person handle the orders page and when they're out read the better the box hi everybody knows what's going on in the system and finally were not healthy debate on team the lot teams that we go into the do not have healthy debates they have silent seating if somebody upset about somebody else always committing what they think is crappy code so now we have the tools for a specific technical discussions and we can the better all of these discussion so you look at all these benefits write better code better developers team ownership and healthy debate this sound like a fantastic place to work I want to work right gonna make you better every day and those the benefits line C In the strong code about 100 culture them apart
fashion questions yeah yeah it's true how do you handle somebody who's does not engage in the process right and I think helping them see the value of the and helping them feel like when they when they do give any review comments it's very engaged right so any comments they do give be excited about it right engage them in them and even if you don't necessarily agree maybe make a couple concessions right early on to come to get them back on board and like I said you write the stuff down what you expect from people you expect that you know you'll be doing these reviews a lot people say like our time for those reviews but I think that's that's all they can and we have point reviews like I said 10 minutes a long time for me spend so like I finish up a feature I look through some reviews that the and so the question is how can you encourage more junior developers to review code but perhaps more senior developers there of I think a lot of the same rules apply a rate like what you want them to do is say like like what we have apprentice like I say like review this code for me right I wanna see what your feedback on the is when they give that feedback don't just dismiss it out of hand right have a conversation about it some trying to some easy when things like that yeah reviewing is just so that the point there was reviewing is another form of pairing kind of right you're not doing this sliding doing kind asynchronous I guess I and a lot of a lot of what i talked about today really like if he knows doesn't really have a lot to do a pull request has to do with providing feedback to 1 another ISO works equally well in settings of pairings what but that is OK so the question is how do you deal with a company where there's a gatekeeper right the sole gatekeeper does the reviews and you have to get that person media coverage I right yeah so here's here's what I would say that is with your co-workers change that culture or find a new job and serious like the benefits I listed there like those are real but I see those benefits every day and it makes where I work a great place to work so right so how you provide context of 3 factors basically right there's no new features to be reviewed why would say as you explain why it is you're doing the re factor and like I said they were not doing QA in our review so I don't like maybe I know that there's some weird place where you know you change this method you search for everywhere where it was where it's called that were calling it through sand here and I know this outcome and then give you that feedback but in reality were were rely our test right that's what we factories all about is having good test so if you test pass then what I'm interested in is a reviewer is what you think you were getting out of technically from the three-factor tell me funny why you felt the pain and what what the solution that's that and the so the question is how you a working like a QA team with this basically like when you do the review verses doing the QA sign off on something so my advice there is to do the recovery before the QI in case anything significant changes and then hopefully you make you a job really boring and if they have if they find something because they do in their head they're going to and then that those changes get reviewed as well yes the question is how important is it that it be asynchronous of of I don't know I would say that I've done like on larger changes all often pull somebody over and is try and walk them through it but I do think the asynchronous this kind of makes the change have to stand on its own which is also really interesting I don't know advances and played with synchronous versus asynchronous enough the know following that what's my opinion on authors merging their own pull request I would say what I typically do is once I have a good code review workflow going with the team is if there's just a couple of small comments that easy to address and I argument trusted member of this team I trust that like we have a good relationship already in the model do is all just address that feedback if it's a straightforward thing to address that the Schelling additional review like I rename something to something they suggested but i'm result right and we work the authors urge they're up and do merge their own request sometimes was sometimes awaiting unlike specifically having a thumbs-up at 2 thumbs up or something like that that's routine worker of so the question is what refactoring it's occasionally hard to like what i'm Sarge ideas yeah OK so it's hard to commit small changes with refactorings so how do you balance the need of maybe needing to run this by somebody 1st verses like presenting a gigantic pull requests I I find that like most those large refractory come on a conversation the already having anyway so like I might have a conversation tale about like guys area the system is really but in a and then finally directors refactoring I'm for larger chain like when you actually do the review i'm leaving it several commits before you squash is probably a good way like I will in those cases also a like this review there be a lot easier for you to step through the comments right you'll see the process I went there and you can follow yeah on the team working with so the question is how do you handle different kinds of basically right and line possibly language there's a cultural barriers and had to build a language barrier too much yet like most people speak enough English to conduct a code review it but I have dealt with in dealing with the kinds of differences which a really difficult when you're trying to say that like there has to be consensus around a change a summary 12 hours ahead of you it's really difficult for them to have to wait a whole other day for feedback unfortunately that's kind of the price of having a widely dispersed team like that hopefully there are people there in that time those well they can provide a quality review and maybe you can guide the market the work it's tough when you're have distributing team like that that so wide I like 3 hours is reasonable the handle they'll be some overlap 12 hours after I don't know he has some good suggestions stock up that the OK so the question is at that time there was no bias was given a lower just on on time so cannot talk to me hallway on my a cost might guide my bike should cost on reference here really doing some gas out somewhere on this floor down here maybe eventually so you can follow us on Twitter you think you know me questions we request and finally I thank staff whose movements in the Moon and this is this this is this is this is this is this the
Maschinencode
Rechter Winkel
Maschinensprache
Datentyp
Softwareentwickler
Computeranimation
Mereologie
Besprechung/Interview
Computeranimation
Programmfehler
Beobachtungsstudie
Maschinencode
Güte der Anpassung
Program Slicing
Mathematisierung
Interaktives Fernsehen
Physikalisches System
Frequenz
Programmfehler
Übergang
Erwartungswert
Prozess <Informatik>
Mereologie
Zeiger <Informatik>
Softwareentwickler
Gerade
Beobachtungsstudie
Rückkopplung
Subtraktion
Maschinencode
Prozess <Physik>
Selbst organisierendes System
Wärmeübergang
Physikalisches System
Kontextbezogenes System
Biprodukt
Computeranimation
Programmfehler
Erwartungswert
Datenmanagement
Wärmeübergang
ATM
Äußere Algebra eines Moduls
Softwareentwickler
Resultante
Telekommunikation
Rückkopplung
Maschinencode
Umsetzung <Informatik>
Bit
Prozess <Physik>
Mathematisierung
Implementierung
Computeranimation
Client
Maschinensprache
Datentyp
Elektronischer Programmführer
Softwareentwickler
Hilfesystem
Beobachtungsstudie
Autorisierung
Siedepunkt
Abstraktionsebene
Peer-to-Peer-Netz
Schlussregel
Schlussregel
Rechenschieber
Rechter Winkel
Mereologie
Standardabweichung
Retrievalsprache
Einfügungsdämpfung
Maschinencode
Teilmenge
Multiplikation
Rahmenproblem
Thumbnail
Wasserdampftafel
Mathematisierung
Kontextbezogenes System
Service provider
Computeranimation
Deskriptive Statistik
Reelle Zahl
Datentyp
Konditionszahl
Inhalt <Mathematik>
Ideal <Mathematik>
Beobachtungsstudie
Autorisierung
Umwandlungsenthalpie
Automatische Indexierung
Modifikation <Mathematik>
Reibungskraft
Indexberechnung
Kontextbezogenes System
Binder <Informatik>
Quick-Sort
Netzwerktopologie
Rechter Winkel
Automatische Indexierung
Mereologie
Anpassung <Mathematik>
Hypermedia
Wort <Informatik>
Information
Ordnung <Mathematik>
Verkehrsinformation
Lesen <Datenverarbeitung>
Rückkopplung
Telekommunikation
Addition
Subtraktion
Umsetzung <Informatik>
Prozess <Physik>
Mathematisierung
Kontextbezogenes System
Binder <Informatik>
Kontextbezogenes System
Computeranimation
Schlussregel
Negative Zahl
Bildschirmmaske
Forcing
Informationsverarbeitung
Autorisierung
Parametersystem
Dienst <Informatik>
Abstraktionsebene
Verhandlungs-Informationssystem
Mathematisierung
Information
Computeranimation
Konfiguration <Informatik>
Rückkopplung
Maschinencode
Umsetzung <Informatik>
Mathematisierung
Computeranimation
Homepage
Dienst <Informatik>
Negative Zahl
Bildschirmmaske
Polarisation
Rechter Winkel
Offene Menge
Äußere Algebra eines Moduls
Bit
Wort <Informatik>
Computeranimation
Metropolitan area network
Telekommunikation
Negative Zahl
Umsetzung <Informatik>
Ortsoperator
Rahmenproblem
Datentyp
Kontrollstruktur
Bitrate
Bildgebendes Verfahren
Quick-Sort
Computeranimation
Arithmetisches Mittel
Maschinencode
Rechter Winkel
Mathematisierung
Kontextbezogenes System
Computeranimation
Schlussregel
Stereometrie
Bit
Umsetzung <Informatik>
Punkt
Prozess <Physik>
Komponententest
Extrempunkt
Natürliche Zahl
Minimierung
Adressraum
Versionsverwaltung
Komplex <Algebra>
Computeranimation
Einheit <Mathematik>
Prozess <Informatik>
Kontrollstruktur
Softwaretest
Nichtlinearer Operator
Shape <Informatik>
Prozess <Informatik>
Computersicherheit
Güte der Anpassung
Rechter Winkel
Information
Ordnung <Mathematik>
Versionsverwaltung
Schlüsselverwaltung
Standardabweichung
Tabelle <Informatik>
Rückkopplung
Maschinencode
Web Site
Quader
Hyperbelverfahren
Selbst organisierendes System
Mathematisierung
Kolmogorov-Komplexität
Überlagerung <Mathematik>
Task
Knotenmenge
Benutzerbeteiligung
Multiplikation
Informationsmodellierung
Perspektive
Software
Endogene Variable
Datentyp
Informatik
Hilfesystem
Schreib-Lese-Kopf
NP-hartes Problem
Videospiel
Kreisfläche
Einfache Genauigkeit
Mailing-Liste
Physikalisches System
Fokalpunkt
Quick-Sort
Einfache Genauigkeit
Programmfehler
Objekt <Kategorie>
Flächeninhalt
Offene Menge
Caching
Mereologie
Gamecontroller
Sichtbarkeitsverfahren
Beobachtungsstudie
Schreiben <Datenverarbeitung>
Parametersystem
Rückkopplung
Maschinencode
Subtraktion
Punkt
Open Source
Biprodukt
Computeranimation
Homepage
Chatbot
Dienst <Informatik>
Rechter Winkel
Elektronischer Programmführer
Autorisierung
Maschinencode
Maschinensprache
Datentyp
Mathematisierung
Versionsverwaltung
Wurzel <Mathematik>
Kontextbezogenes System
Kontextbezogenes System
Computeranimation
Schlussregel
Resultante
Rückkopplung
Umsetzung <Informatik>
Maschinencode
Subtraktion
Prozess <Physik>
Punkt
Thumbnail
Quader
Stab
Adressraum
Formale Sprache
Mathematisierung
Hinterlegungsverfahren <Kryptologie>
Homepage
Bildschirmmaske
Informationsmodellierung
Benutzerbeteiligung
Prozess <Informatik>
Vorzeichen <Mathematik>
Maschinensprache
Softwareentwickler
Gerade
Schreib-Lese-Kopf
Feuchteleitung
Autorisierung
Softwaretest
Parametersystem
Addition
Softwareentwickler
Computersicherheit
Güte der Anpassung
Einfache Genauigkeit
Schlussregel
Physikalisches System
Kontextbezogenes System
Bitrate
Teilbarkeit
Verkettung <Informatik>
Flächeninhalt
Menge
Twitter <Softwareplattform>
Rechter Winkel
Hypermedia
Mereologie
Wiederherstellung <Informatik>
Faktor <Algebra>
Refactoring
Ordnung <Mathematik>

Metadaten

Formale Metadaten

Titel Implementing a Strong Code-Review Culture
Serientitel RailsConf 2015
Teil 18
Anzahl der Teile 94
Autor Prior, Derek
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/30672
Herausgeber Confreaks, LLC
Erscheinungsjahr 2015
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Code reviews are not about catching bugs. Modern code reviews are about socialization, learning, and teaching. How can you get the most out of a peer's code review and how can you review code without being seen as overly critical? Reviewing code and writing easily-reviewed features are skills that will make you a better developer and a better teammate. You will leave this talk with the tools to implement a successful code-review culture. You'll learn how to get more from the reviews you're already getting and how to have more impact with the reviews you leave.

Ähnliche Filme

Loading...