Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Hey everybody. Thanks for coming to Working Compassionately with Legacy Code. My name's Amar Shah. I'm a developer at ShareProgress. ShareProgress works for nonprofits. We do some front end and data science consulting for them. I hacked on our social media analytics platform in Ruby and Sinatra, and Sinatra, not Sinatra, but ShareProgress is a fantastic place to work.
It's got an awesome remote-first culture, so we'd love to talk to you more about it, if you're interested. And this is a talk about compassion. So you might think that I'm a very compassionate person. And you might think that I'm a vegetarian. Maybe I meditate regularly.
Maybe I hang from trees while I meditate. You might think that because I'm up here on stage that I think I'm some kind of rock star, and maybe I think I'm a compassion rock star. But I'm not. (laughs) I'm just like you guys. I'm a software developer. And since y'all are software developers, you know that although you might spend a few minutes of your day celebrating a victory, most of the day you spend failing.
When it comes to compassion, I'm no expert. I fail all the time, just like software. But that's okay, I got a word for that. And that word is learning. So I've been looking back on some experiences that I've had with legacy code. And I wanna tell you as maybe not that grizzled old rock star, but I wanna tell you about those experiences, and how looking back on them I feel like now I see where I could have used some compassion and had a better time inheriting a frustrating legacy code application.
So this is the story of two apps. How I inherited two applications at the same company. And the story of these two legacy code applications are two stories that ended quite differently. So I was hired by a company to, based on some meager IOS experience that I could write on a resume and fool somebody into thinking that I should be trusted.
(laughs) I was hired to take on an existing legacy code application that had been bought from some contractors and never had been pushed out to production 'cause it just didn't look solid enough. So I took a look at this app that was supposed to be used internally by our company's repair technicians out in the field.
And as you can guess, it was a disaster. The UI was both boring and subtly mysterious. It was impossible to get a workflow right. You got lost every time. And the solutions under the covers were to problems that were just not the ones that needed to be solved.
Like for instance, if you wanted to share data between two people using the app on different iPads you had to put them into a room together and set up a peer-to-peer connection, and then zap that data over the network. I mean, email? The app relied on frameworks that were completely out of date and un-maintained and dead.
And if I sent to them to you here now, and you know anything about IOS, you probably wouldn't have heard of them because they don't matter anymore. And instead of doing constant communication with the server, the mobile app had to be synced every 24 hours in one huge data dump.
And if you didn't do that syncing then you weren't allowed to continue, you just had to wait. And sometimes the request to the server would take minutes to come back, and sometimes it wouldn't come back at all. It was a soul-crushing spectacle. Developers as second-class citizens, and users as a despised and outcast underclass.
Now I wasn't the first in-house developer to work on this project. I was the first full-time in-house developer to be hired by the company. But there was another contractor who had come in for a couple months and she had tried her best with this, and she was someone with a lot of mobile experience and she had a lot of options, and so when it came time to decide whether to stick around, she decided to get out.
But I had her notes and her commits, and I thought I should call her up and ask her for some advice because I kind of felt like, well I was lost. And she was really nice to talk to me over the phone, but her advice was chilling: "Kill it and start over. " So now that I had two people on my side, I decided to go to management and say, "Hey, this app isn't in production, we don't need it.
"We don't need everything that could come with it. "So, why don't we start again?" And to my surprise, they actually went for it. So there you go, a legacy code problem solved, everybody go home. But I told you I inherited two applications. And the other application was in production.
And this was a Rails web app that we used internally every day. Four or five users plugged into this all day long, posting records. Basically taking the paperwork generated by the in-the-field technicians and pushing it into our system. These data entry operator people, I really sympathized with them because this app was built by the same contractor as the first app that I mentioned, and it had all the same problems.
And the UI was unforgiving. You make a mistake and there was no way to fix it. You just had to resort to desperate measures. And enough of these desperate measures and finally the data just didn't look right. It was completely out of order. And the ironic thing about it was that some people in the office would check in once in a while, and they would notice that things weren't quite right.
But that message didn't filter up to the top. Because there was a culture in the company that if you see something, you better not say anything. When I took a look at the insides of this Rails app, this is what I saw. No automated tests. Stuck on Rails 2.
3 and Ruby 187, both of those end-of-life. You talk about fat models, I had 1500 line models of Ruby code, 300 line methods. You could inject SQL through the search filters. And there was something called an authorization loophole (laughs) and basically the app had both a customer portal and an administrator portal, and of course, you had a customer role, you'd use the customer portal.
[ ... ]
Nota: se han omitido las otras 2.950 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.