Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
hello everybody I I hope you still awake it's been a tough night last night i will be talking today about some best practices let's say like that i call them 10 commandments of software engineer if i will be walking like this and you know covering
slides just shout out i'll have it the habit of walking around and i'm a bit concerned because I've seen I think already to talks which have touched on on on similar things so there will be a little bit of overlap but maybe this will be another
opportunity for you to kinda you know take some stuff of the talk like this right so let me introduce myself first I'm Sebastian Marek I'm polish but I've lived in the UK for the past seven years I'm very passionate if it comes to software
quality and and best practicing a best practices in software engineering I dare to think that I'm actually a little bit better than what was actually told during the keynote today so that I can steal I developed and actually produce some code despite the
fact that I've been a technical architect at a company called image which is based in Leeds and I actually have some publishing history and I wrote the two books and I've been publishing in PHP architect and I'm actually here speaking probably
some of my work weights could disagree and stuff like that I've been in development for over 12 years that's probably more i stopped counting the yes and i've been doing all sort of different stuff in all sorts of different languages as starting
in an early early as with c++ and pascal and then do a little bit of java and then finally ending up with scripting languages like PHP and pie a little bit of bite on and I occasionally contributed to open source software if I can even really find time I find
it as one of the ways that you can improve i actually had two conversations conference with two different kind of a teams from two different companies about you know how can you improve and how can you take it in forward and this is definitely one of the things
that you can do just try to submit a small patch or do something with the open source this will usually be a very good way of finding out what are the standards in software engineering and action getting some pretty good feedback it might sound scary at the
very beginning because yeah we can't we can't really hide it that some of the people are not really friendly if it comes to the feedback but that's just interview other people but please give it a try and you will see some differences to explain
that the full plate armor that's me actually in there with my daughter in my free time I'm really I'm really into castles and medieval times and things like that but let's move on what I want to do today is to achieve two things first of all
is to try to change a perception of being a software developer and change what you think of your job and what you're doing so this probably is what most of the people think we do we're just hacking some stuff and we just typing some weird things into
their consoles and producing some something amazing we probably think we're bad as hackers in here like no multiple desktops doing all sort of stuff while we actually like you know tackling the daily problems during development and we probably think we
we more like artists or at least some of us are and we actually create those beautiful things why we really firefighting and and and I'm trying I will try to go through all sort of things why it might what might be the reason why we firefighting and things
like this yeah and probably our moms things that we just playing nothing else that's what we do at our job but what I want to do also well what I think is that we more like craftsman and that would be mentioned in the in the keynote as well today about
software crafts manship this is kind of a a movement that it's been around for for a few years already trying to more promote and educate people about what is needed to develop proper software and to treat it more like a craft it's been a controversial
topic because it depends how you look at this guy because he could be like doing all those small things manually all the time that's not about that it's more about experience and the skills so if you look at the blacksmith for example and and how long
a blacksmith as a profession been on the market is being backed up by hundreds of years of experience and people learning and father's passing the knowledge over to sounds all over and all over again and they basically mastered a profession it's a
bit different with software engineering it's been actively as a profession trouble before the past what 60 maybe 70 years we didn't really have a lot of time to master our profession and to learn all the things that should be done properly and this
is kind of only emerging as probably the way you should we should be doing so back in the days there were guilds and people were like you know gathering together making sure they all follow the same things the same standards but it's more about passing
the knowledge over making sure that everybody follows the same thing and then we can achieve beautiful things okay also the result you know another part of that because there was some crappy craftsmen and and we have a value products as well so obviously creating
something which is great and works very well it costs money you can't deny that it's something that you need to put an effort and effort this time and time is money is always the longer you spend developing something the more it costs but the end product
hopefully should be better so it kind of there is a relation between money and the skills and the experience so sometimes you have a you have a situation when you have to develop something really really fast and if there are valid reasons why you have to do
it you could kind of relate to it as it's being gay like you know Tesco value product which it does what it says on the team is probably not the very best and it's got some holes media net so what I want you to do today I will be talking about 10 different
things some of them have been already mentioned but if you'd like to take two of them at least two of them when you come back to your workplaces and start trying apply it to your daily job that will be a success even at least think about it whether this
is something that could improve what you do I will do it in a relation to a development cycle there's a very high view of the development cycle values you know you initiate a project you design it and you implement that and you test that and then you know
hand over the project and you see what you've done but it should be enough for what I will be talking today so the first phase will be project initiation and that's where everything starts though shalt not disrupt the legacy system there's been
a brilliant talk today about legacy systems I think Michael peacock it was about refactoring to Symphony components and he actually told the story how they went from starting a project which was basically dealing with a very legacy system which was pretty
old and really really really hard to maintain and they've dealt with all sort of different problems like you know the programs using obsolete technology they couldn't really cope with that very well it costs a lot of money to maintain that and and
just because nobody understands there obviously is no documentation whenever they've changed over time I nobody bothered to put any sort of notes or create some told you know document something how it is supposed to Oregon things like that so it was quite
a challenge the problem with legacy system is is usually that they very very important for the business developers hates them business loves them they deliver the business value so it's not an easy decision to to go and say let's just rewrite that
[ ... ]
Nota: se han omitido las otras 3.997 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.