Big Ruby 2014

Cómo realizar refactorizaciones complejas con confianza

Wynn Netherland  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

check one two all right I'm going get started some folks are trickling in my name is win I work at github on the API team I think there's three of us here this year so we've kind of descended upon grapevine online I answer to penguin Twitter github

usual places splash pages up a twin mm which is also a gospel R&B station ethic in North Carolina somewhere around there that you can find me wind outta FM today I wanted to talk to you about changing code and this is somewhat of a technical talk but for

the most part it's about the philosophy of how we work at github and how we change code so I don't know what you've been told but changing code is pretty easy right you just change it it's changing code with confidence that can be the kicker

I think we all know how this scene ends right with production production rolling down behind you so how do we get confidence about changing code the tests are probably the first thing that we do we write lots of tests as we develop features we write tests

we find bugs we write more tests and over time we have a test suite that that grows with us anybody less than comfortable with their test suite for their production apps it's okay and the certain things that you you test down closer to the metal that you're

just less than confident when you make those changes in production and get up we use data to inform decisions this is one of the things that kind of transform the way that I worked I've always used tools to gather metrics especially around usage of physical

utilization of boxes and things of that sort but I'd get up it kind of blew my mind of just what's possible when you track everything and you data to inform decisions so we use Hugh bots for chat ops for everything and it's kind of like the center

of the world at github and in that is a graph me command where I can pull up a graph of visualization to just about every metric that we've got that we track in the application in this case we're tracking API status codes it's just an example working

the API is usually minor API related just API status codes over time and see if it meets expectations around certain changes that we're making there's another one for serialization queries when we're taking active record objects and serializing

those to send over the wire and API responses so having rich data like this can inform decisions and help you move with a little bit more confidence we don't like to break the API and get up nobody does but there's been times where we went from a really

dogmatic we can't break the API approach to actually seeing who's using particular methods and reaching out to those folks and then making a more pragmatic choice this is powered by what we call the graph store it's powered by graphite there's

tons and tons of graphs and this thing and if it doesn't have the graph that you want you can just go and save the visualization and build that and save yourself some work the next time so it's built on graphite as I mentioned we have everything from

broad visualizations and dashboards like this this is what pops up when you do a deploy in campfire cubot will tell you check the graph store or graft me for the browser response times to see if the change that you introduced is making the site run slower

or faster for the segment you care about I did a little Dom work and chrome just to hide all the scrolling and just to get a screenshot of all of the charts this is probably ten percent of what was available on the first page it's just tons and tons of

these charts that you can pull up and gauge metrics as your you're building out things and we track these there's three basic things that we track in the application there's counters gauges and timing so a counter is usually the most common anytime

something that we care about happens in the code we will just increment it give it a name in its namespace some sort of action and that will increment a counter so that we can then take that and go graph that in the graph store there's a gauge if you want

to track a reading of something over time like CPU utilization or Homans Twitter followers or something like that right you can measure that over time and see how that grows or shrinks and then a timing gauge is where we wrap a particular method in one of

these graphite calls and whatever is inside the block is going to we're going to measure the duration of that and store that in graphite so I'm with that data we now can deploy with a little bit more confidence and so I have to temper the talk the

the frosted side of me he likes to kind of talk about all the cool things that I've learned at github and how we work at github and I forget that you know not everybody has got the same context that I do who here was not telling a computer what to do all

day before y2k was a thing yeah it was not anybody not coding before the year 2000 fair number of hands so sometimes I feel like I've got to go back and give a back story just to kind of appreciate how good we have it on certain technologies that we have

[ ... ]

Nota: se han omitido las otras 2.481 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.