Gestionando la deuda técnica de los proyectos Django

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

I'm Christian you can find me on github at CRC check my twitter handle is CC rrcc r CC r r you can also find me on IMDb i'm christian 2 i'm also looking for more pinterest friends i am IM cpanel on pinterest i currently work at tapped out but a

lot of the knowledge that i'm going to be sharing is things I've learned from my time at the Texas Tribune to you may have seen a lot of other text ripping people around oh I see something right there so everyone always starts off talks like this with

dictionary definitions wikipedia says technical debt can be thought of as work that needs to be done before a particular job can be considered complete or proper and then something Jean Kim says is left unchecked technical debt will ensure that the only work

that gets done is unplanned work another thing Jean Jean Kim says about technical debt is that it's what you feel the next time you want to make a change and for me personally a technical debt is every line of code and just in case you were curious I checked

and urban dictionary does not have a definition for typical tip I also think it's important to just know about what touch about feels like and it's when you fix one bug only to create another bug and it's when you can't even deliver it features

anymore because you don't know what repercussions your change will have and it can get so bad where you can't even install security patches because you don't know what will break and it's when you're using a rapid development framework

and you can't rapidly develop its when you hear a lot of it works for me around the office every time you're trying to replicate something and the great thing too much n go is it does let you build things very quickly but it can also get you into this

technical debt trap and the main thing that I learned is that you don't want to let Django become the scapegoat for your team's inability to develop new features and the last thing about technical that is it's it's like when everything is on

fire all the time and and this is this is your life so like there's no magic trip tips for how to clean and in technical debt so anyways here's some tips I've kind of organized them from things you can do on your own the things that you can do

a monster team and finally things that require going outside your team and to the non-technical people in your organization so first scene is Django testing you should you should do it there's three other sessions at changuk on about testing don't

let your dreams be dreams yesterday you said you would write tests today so just do it make your dreams come true just just do it so when should you write a test because a lot of times a lot of people will just there's a lot of I find that there's

a lot of looked installing tests in the first place so maybe if you can ease people in that would help a lot and something that I always thought was if you're making an assumption that's a good sign that you should be writing tests to check that assumption

and I can I could see justify not writing a lot of tests up front like doing TDD a lot of people might consider that premature optimization to be writing a lot of tests up front but if you're doing that you should do at least be doing regression testing

as a wise man once said fool me once shame on you fool me you can't get fooled again and you will get you will sleep better when you have good test coverage it's a fact so I want to give an example about testing your assumption let's say I had

a function where I just wanted to turn in a zip plus 9 or zip a u.s. postalzip I just wanted the first five so that's pretty easy I mean I just been it's a stray now let's take the first five but if you look at these examples I've set up and

I've written this as in the form of a doc test which i personally don't use but it fits nice on the slide you start to see it at the bottom my assumption that taking the first five digits falls apart and if you had tests then it'll you'll be

able to catch that and if you don't have a single test here's one that someone posted recently and that's if you just use the client to load your home page I don't have the facts to back it up but you'll get like eighty percent discover

just from this one toast and the the thing that I really like is is if you like to feature you better write a test for it so coverage is another great tool for just helping you discover where you should be where you're missing tests and a lot of organizations

will strive to get a hundred percent coverage but it's more important that your tests are quality just for writing a test to get for example just checking the Unicode method of a model may or may not actually be useful you'll have to find that on your

own so some signs that your your tests are crappy one is like can other people read and extend your tests will they take your tests and use it as a template for their own tests and be happy with it are the tests getting maintained whenever the code is beginning

maintained or are people looking in frustrated because they have to may also maintain the tests and the tests described the problem in a way where you could throw away the code and people could use the test to rebuild the code and it's not only the tests

but the same could be said about your documentation and maybe even you read me could you throw away all your code and could someone use the readme to reconstruct your entire application another thing that's a big source of technical debt is bit rot also

known as sulfur entropy and I think that if you're not actively touching a piece of code it's getting worse just lying around it's also a sign for me it's the smell as an organization if you don't have the manpower to actively maintained

all of your code and if you're interested in in this kind of learning more about this there's a series of management books called the improvement kata also known as the Toyota kata every time I research that though all I got was a bunch of marketing

seminars that were trying to sell me something but maybe you'll a better look so if you imagine your quote the code of your organization as as a globe are there areas where there's like here be dragons where people just don't know what that code

[ ... ]

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