 You've been self-taught, you just got your first job as a Rails developer. Chances are, when you are going through your training, you will create a lot of applications using Rails, Remedian, JavaScript, and making things from scratch. This is what we call green build development, where we have endless possibilities to have you again, you can basically build things however you want to build up. But when you go to work for a company that you're going to be doing something about before, which is generally going to be working out as a legacy application, and the opportunities to build applications from scratch are coming from these together. So, I want to help you understand how best to work with a legacy Rails application today. So, why? I've been doing web development since you taught us. It was 1993, so pretty much forever. I built my first website before there was a graphical web browser. I've been doing Ruby since 2007. I have about 2,000 Ruby jokes to my name. I have the most awesome band that you are all ever. We have a program on the code. You can go there and find out where I'm speaking, and who's ready about me and my educational blog posts. I have a program on Twitter. Twitter is really the best thing you can touch with me. I hope you like to know where I come from anymore. My job is to do all the Ruby and social justice, and I exchange funds with other ones. You heard this morning in the keynote about Rails, about being a good product, and I think all through that good product, it's called the Trader Comment. There's the most popular open source, good product in the world, with over 14,000 applications including Rails, J-Ruby, Elixir, and Horace. I work with GitHub on the community safety team. I work on global community management features and anti-grounds features. If you're wondering, yes, it is possible, and yes, it does happen. We're asking for GitHub, it's happening, it's happening to other people. So my job is to live in open source, more welcoming and inclusive for everybody. It's pretty easy to be honest with you. I'm also a notorious social justice warrior. It's one of my great artists. I came out and I announced I was running GitHub. So you should think of everything I say today with a great insult, because I'm coming with this from the perspective of a very liberal, transgender feminist who believes that people should not be shipped to each other online. So that's my common personal opinion and I'm thinking of everything I say with great insult. So let's see the cases. Let's start by defining our terms. Elixir code-based is generally speaking a very large code-based and it's kind of unwieldy. It's kind of hard to work in. It's a code-based that is really difficult to wrap your head around. I believe that you cannot make significant achievements to an application unless you can hold the whole thing in your head. And Elixir code-based seems to be so large that it's really challenging to get out of it. In a lot of places that the companies are going to be working for, the people who wrote Elixir code aren't there anymore. They do have a lot of things. Because as developers, we don't really stay at companies very much anymore. So it's very likely that the people who engineer Elixir code-based are working on now are working for a simple amount of time and money into Elixir code-based that you're operating in now. This is going to be the adjustment and they're not going to give it up. Generally speaking, the application if you're lucky is making money for a company and you can't just burn it down. As awful as it might be, as daunting as it might be, and as tempted as it might be to say, screw this, let's just start over, it's not really something that's feasible. So what makes to be qualified is still proud of legacy applications. As I mentioned, I work at GitHub, I would see some things. GitHub probably has the largest legacy girls application in the world. And I would love to talk to you about it today, but GitHub is not itself open source, so I really can't. So I'm going to talk to you about another really large legacy code-based that I work on. In 2014, I joined a company called Instructure. They have a learning management software I call Canvas. Canvas is open source, like I talked about freely. It's a massive code-based. There are 400 models that are open-source, and they have a lot of control errors. All told, the application is defined by about 12,000 miles. You can go and check out with GitHub, it's structured as much as Canvas can announce, about 30,000 per minute by hundreds of developers. And when you go and look at the application, it's really overwhelming. There's so much to it. They try to organize it logically. There are a lot of folders that the controls are. But it's really top of it. It's very top of your domain. And when I started there, I was asking myself, how can I navigate this labyrinth of code? How can I understand this so that I can make a difference and I can actually participate in extended feature and fixing bugs in this code-based? So I think it helps a little bit to understand how legacy applications are built. So let's talk about architecture. As I mentioned, I started in the 90s. And in the 90s, we did not have agile development. We had what's called Waterfall. And what Waterfall is, is you divide development into series of phases. So you have a discovery phase where you're trying to figure out exactly what the application of your building is going to do. You have a design phase where you would architect everything, plan out exactly how you're going to build it. Then you have a development phase where you have some full things, you know, of the Waterfall process. You know, we made the bit for where we're at with all the new stages, but it had some things going for it. For one thing, you had to tell the fire test. One of the first things you got at the job was you required yourself to have a user that was very, very kind of, but it told you everything the application was supposed to do in great detail. It told you where the users were, it told you about their interactions, it told you all about every feature that you were going to create. From that, we had positions on teams called software architects. And if you work for a really big company, you might still have architects at your business, but they're pretty much on the street. So architects would build diagrams like this which showed how every piece of the system interacts with every other piece of the system for a good operation. So you could see how the different pieces came together and how they were supposed to come together. In Rails, we just fired up our editor and built a new class that came to Waterfall days. We would do class diagrams. We would plan out what experiences this class might have, what are its public messages, what are its private messages, and what are its relations with other classes. So, in short, Waterfall, we had very thorough practices. Everything was spelled out for you and development was kind of free guesswork. But it was also very free to create cities. And the bad thing about Waterfall was that it was an eight-place slot. Any project would take six to twelve months in general. And if you had a mistake in your time days, where your discovery page found out oh, this feature can't work that way or oh, we've crashed it bad, we've read plenty of this new feature, changes are very expensive because later you go to the development process, the more expensive it changes your products. So, these days, we live at an age of the cowboy weather. We do just in time architecture. We wait until the last multiple moment to make decisions about the structure of our code. So, what does just in time architecture look like? It tends to be evolutionary. The architecture is not in an advanced but it's a product of organic growth. It tends to be fluid. There are no guiding principles around how an application starts and how it grows. So the whole thing is somewhat marvelous. Unfortunately, just in time architecture is going to be undocumented because we're a busy developer and we're trying to have features in Facebook who has the right architecture. Our architecture in these days are easily influenced by trends in the industry and it's an interesting thing if you have a large-scale legacy application you can actually be an archeologist and dive through layers of code and figure out what was the popular paradigm in 2014 when this feature was added or in 2012 when this thing was developed. It's kind of cool. There are 12,000 archeologists and people who don't know about that. And with many just in time architecture decisions were made by the most opinionated developers who tend to be the loudest developers. So we heard this morning about a stronger company is loosely held. I believe that as a concept because that brings within a culture of organization rather than collaboration. If you have a clear mental model of an application as I mentioned, it's almost impossible to maintain and develop that. So what stands in the way of wrapping your head around the large-scale application? Oftentimes, if you're into a bootcamp special and you're using the latest version of ground, the latest version of ground, the latest version of ground, the latest version of ground, the latest version of ground, the latest version of ground, the latest version of ground, the latest version of times as well. So if you know how to do things in the latest version of Ruby, the latest version of Rails, and you go back to the older version, you're going to find yourself in a hinder because some of the tools that you would naturally reach for just don't reach this yet. All applications tend to entropy and legacy applications have a lot of times slide toward complexity. Given the just in time architecture that fuels the development of legacy applications, there's no single plan or guiding vision to the way the app is designed. So there can be a frustrating lack of completion, lack of things coming together to work together in a seamless manner. You can often hear that the whole thing is coming together with duct tape and string. And the stronger hands, loud voice developers that I mentioned, they don't tend to be good collaborators. So you might find that the individual sections of the code base are highly opinionated by the technical decisions and technical opinions of one person, whereas you go to a different section of the code base and things are assigned to the code base differently. So everyone know what a duct mode is. It's a class like a user that's about 3,500 lines long and you're afraid to touch it. Classes attract new methods the way that a lot of code makers can't get an attachment to that. Every class wants to be huge. Every class wants to live forever. As an application grows in size the developers are loathed to add new files to large projects and they tend to tap on methods onto existing classes to whether they belong there or not and whether they violate some more accessibility principles. Many companies who have been doing this for a while try to battle complexity in their applications by extracting features out into custom gems sometimes privately hosted. If they're good citizens they're going to be back to open source but often times they'll be applied to a job server. This actually does not reduce complexity its spheres of code base that cross-kip the moderators they can adapt much harder to understand exactly what's going on. Finally, my spare thing about remaining monkey hatches so if you don't know monkey hatching these both of them have an existing class like string or array and add a method to it or worse yet this was sent changing the way the existing method works so if you go for array you're like oh it's not memorable it has this method and you try it out and you get an unexpected result as long as monkey hatched it's the worst thing that could happen to you and there's no documentation of it because of course it's not a Ruby document because of course it's not standard so you're stuck trying to figure out exactly how something this serious works. So it sounds pretty balancing working with a legacy application it doesn't sound that much fun but that's true but we can't come up with a strategy for working effectively with it there's a strategy that was built by a military person but the United States Air Force was only John Boyd he applied this process to combat operations and to make fighter pilots use this to make decisions but it can be applied in a lot of different situations we're going to explore its application in terms of legacy code and so to observe we're going to decide four phases and it's a cycle so let's take a look at each of these four phases the observation phase you're observing the situation and you're filtering it out to understand how things that you're seeing apply to the company that's trying to solve it at the moment observations are basically the raw information that you want to arrange yourself to and decide how the exact information has to be processed before you can act on it so this is where you bring your own experience and your own knowledge to bear the sort of shape you can put and that shapes the way that you observe the way that you decide the way that you act and to decide phase you take a course of action decisions are based on best guesses based on observations and your orientation decisions are works and progress you're not going to get a right the first time through new suggestions keep arriving these will share changes to your decisions essentially you're learning as you go finally the act stage this is where you follow up through on your decision and then you cycle back to observe and as you judge the effects of your action this leads into learning concepts so let's take a look at each of those as they apply to the lexical base first is observation how you observe the lexical base if you're lucky and you're not really lucky there will be a doctor or your resident patient and it will be full of good history that will explain exactly how the system works maybe some of the derivative documentation from people who document their code really well whichever one does, of course so don't throw it in the box basically sometimes people are nice to me and a lot of comments describe oh, here's what this method does here's intuition here if you're lucky so look for code comments to make sure they exist a lot of larger companies keep waiting but these are really hard to maintain they punish you through their user interface and I like to say that waiting stands for rare information that kills itself so it might not be making up to date but it might be there that you might establish you might have to establish a baseline one of the other jobs that I worked at we have these things called architecture decision records if you don't have these brings to your company you can get out of my talk create architecture decision records they're really cool, here's how you do it on your GitHub repo you open up to issues that says we need to solve how to deal with problem patterns we need to figure out a way to solve problem patterns and you talk about what the sort of considerations are about that what you're trying to achieve some of the rough spots you see and you say, what did this and now other people on your team go to the issue and they comment on it and they're like, oh but how do we consider this sort of safety point and this is an edge case and you actually engage in a discussion via an issue and at the end you arrive at consensus which you should be eventually aware of the consensus even if it was based on your argument about it and you keep that issue around and close it but you try to read it so someone who sees this government feature can say, and if you look at support for implementation and what was the decision making process why don't we choose to implement code and just take their way and now you have a record of it and it's a very low friction way of doing things because we're always working with issues on the ground so architecture decision makers are pretty much on you can also look at core requests so when you're working on a particular part of the code base look for core requests that reference to that part of the code base because you'll often see comments on the core requests that shape the way the code was written at the end but the test is called validation and tests are really valuable for good validation some people would use tests to provide development they would write a test report they would write a code but those are important but I think the most important role in test playing is documentation because tests reflect bugs and for a very new code they reflect edge pieces and they reflect the way the code is supposed to work so reading tests can be extremely eliminated when you're trying to figure out how an application works and if you use RSpec there's this format flag that you can pass to RSpec you should write this down and the output you'll get from it is human readable specifications so in this case we're running in on a membership model and we get membership that joins its own credibility membership calculates its expiration in days and so on and you can understand oh that's what the membership cost is doing so we should test this out and finally you're not going to look around I talked to a lot of David Elbert and I talked to a lot of people who were using Cams and they asked how do I get that and I told them find a gem that you like find something that's useful to you and go and read the source code because that is the best way you're going to learn what your conventions are what best practices are and learn from the cleverness of your peers reading code the legs of the base is important too because you're going to learn how to put together and what sort of expectations your articles of quality so that's observation the observed information the observed information is your process you can orient and make a decision and this is where we draw our experiences so some questions you should ask yourself what is the problem that code is trying to solve and you can look at this on a micro level like what is this method trying to do or you can also step back and say what business are we in and what problem is the business trying to solve and how does the code base solve that problem you also want to look for a sense of art and this is basically the custom vocabulary and custom jargon that applies to the industry you're in and the business you're working and the code base you're working in so keep the glossary if you're new to glossary but like these are the words that people are using to describe the problems that we're solving and for God's sake if you come across an acronym write it down and a great thing to do from a citizenship perspective is as you're onboarding and learning all this stuff and keeping your glossary put that somewhere where other people who join the company after you can reference it and do a main onboarding a much better experience than that so that's the way to think about it you should look for patterns what are some of the architectural design patterns that influence the shape of the application and influence the development of the code base over time people I like to say that every good problem is actually a personal problem it's very valuable early on to look for the subject matter experts not only on the sort of things that the business is doing and that the software is doing in a macro though but say who owns the subsystem or who is one of the world who works a lot on this particular component you can just get playing to find out who's doing the most of this and get some things that work with the base and find the people that can answer your question that's great but the great way to bridge yourself to an application is by checking on the Routes file a real application of Routes defines how the application interacts with the world how it interacts with users so Routes can be a great way to start learning how the business lives together and solve your problem you can get a great view of what the application is actually going to do so then comes to the decision phase what you're going to do with the information that you've gathered in the process you're going to make a plan and you're going to get ready to make a work in progress so one thing you might do is plan to refactor it and this is just in the context of oh I'm working this feature and this is just gnarly and I want to make it simpler and more beautiful you can also refactor to learn what's going on and do it for a way to refactor so you're like I don't understand what this set of methods and users are really doing so I'm going to rewrite I'm going to reconstruct it from scratch I'm going to use tests to see what I've stepped outside the bounds of what's expected from these methods or this functionality and I'm going to challenge my assumptions about how it works and I'm going to rewrite it and I can make great learning experiences so make a plan for how you're going to do an exploratory refactor I'm not a big fan of inheritance there is dual center ruby and it's an essential ruby I'm just not a fan of using my applications but a lot of application fees in inheritance might have a base class that implements a course method or defines an interface and you have a lot of other classes that sort of arrive at it understanding those and knowing what would I do on a community great way of equipping yourself to make changes also look for modules that express common behavior that's shared by multiple constants and ask yourself, if I need to implement this behavior what modules would I want to use? on table gems especially about application fees they send quite gems like crazy and the gem file is really really long and no one can actually say what would be a race or what gem is that they can use for anymore so an interesting thing that when we prepare and use the code base is to take out a gem run the task and see what brings it's pretty critical when you're working with a base to understand what the relations between objects and the classes are you need to see what things change together because if you need to make a change to the code you want to know what else is going to be affected I've heard a tool a few years ago called society and what society does is it shows you a coupling between constants and that coupling might be the form of an object in this other class or a closing method on this other class where it has a relation to the object record in terms of diagrams like this this is where canvas don't match I don't expect anyone to make sense of that diagram because this is too complicated but one thing you can do is do this sort of trunks where coupling comes together and if you're doing a refactor of your legacy application in something like the service oriented architecture that can tell you where the edges are if we zoom in a little bit and society's graph is interactive so you can click around and focus the information you can see this case of course which is the core level in canvas where you can see all the things that the course touches so that can be a really handy thing you can give it out you can give it globs you can give it a single file it's really flexible when you use it you can expect society to run and you can do that as part of engineering go exploring why something is interesting or challenging or messy and figure out how you can change it or how you can add to it figure out where a method is defined by all places it's called and ask yourself why does it live in a place where it lives and how would I change it or extend it but I'm going to do that I want to share with you another really cool tool that not a lot of people use anymore but it's kind of a classic comment I was coming on and I'm going to give you a better example of this one and a true table you have one column for every input so for every variable you have a column and for every operation on a variable you have another column which says in this case if p is true and q is true then this is the outcome of these calculations so to give you a really concrete example the same thing that was conditional this is not nearly as bad as I understand sometimes patients are a little bit complicated but I'm trying to figure out what's going on so to state the first condition it's available in people with state work hours with date the focus has been worked so here's a true table this lays out all of the possible combinations of all of the variables that are expressed as conditional and our first conditional is how they're entrenched if state work hours is true basically it doesn't matter what get family hours is what get friends hours is the focus will be worked if we take a second on conditional problems if availability is get family hours with a date the focus has been with family so that is these two rows that's your table we know that get work hours is false because we've fallen through to the second condition and a conditional get family hours is true and get friend hours can be true or false without affecting the outcome and finally if availability equals get friend hours with the focus that's been on friends this is the last row in our true table we know that get work hours is false get family hours is false because we've fallen through to the last conditional and the outcome is friends so this is a really trivial example but if you have a really messy conditional maybe a case statement that's really complicated writing a true table can really help you sort of untangle what's going on and if you have to write something that's a nasty conditional a true table can form what kind of tests you're going to write before it as well so add up to your full category so that's the decision phase now it's time to actually do something with what you have learned you want to start out by making a branch and I recommend you create a throwaway branch for a throwaway pattern something you can experiment in safely without changing for allocation and again this is a test week as a barbell so that you know when you come up with the cracks when you implement it in functionality it causes unexpected results because of trampled Tokyo break the application remove things, change things remove the methods, see what breaks you can learn a lot about a system by observing its delirious cases so what happens when this class is instantiated with a different sort of inputs what happens when you put in something weird on the web form you can learn a lot by examining what happens when you are in a ruthless way with your code base pride is one of my favorite tools who uses pride awesome, I'm glad to see that so that's this refresher like basically in the source code you can then require pride if I need to pride and what that does is it interrupts program flow so when you have to compute this code it drops it into a console and you can say I'm in a state of the world so in this case we're looking at and some of these are objected with the first-hand portal this is a cycle and it's important to repeat that cycle, it's a loop every iteration of the loop gives you new information in logic of origin you stop better to see what you're working on it gives you a greater understanding of the powers you need to have so in a very social in my experience a code base that is far and then as far as you can understand and in general when you move through it remember what you're trying to accomplish you've been hired to maintain an application to add features to it you're trying to become a value member of a team you're trying to be productive so do everything in your power to achieve that particular goal understand that you're not going to understand a big complex system the first week of your job or even the first month of your job this is the ongoing process you're going to be constantly discovering new things and into your purpose of knowledge and it's going to enable you to do a better thing but it definitely has a cause in us that you need to keep having pair up with someone you might have a superior developer on your team look for someone who's good at teaching not everyone wants to see your who's good at ensuring your teaching to find that person or if you've been hired with two other new people find someone to pair with who is also learning if you're collaborating you're learning about the powers of communication even if you're smart enough to figure out how to do an organic code base you don't need to be smart don't fear the legacy code base start shaping it add some features, pick some bugs, and some manufacturing this code base is your new home that's where you'll be spending at least 8 hours a day for the next year and a half so even when you're learning you control all those flaws outside of the software industry legacy is not about work legacy is something that's a gift from one generation to the next generation I think people are thoughtful about the way to write the code and we arrange ourselves correctly and are ready to code that as meaningful and ethical and positive then that code can be that legacy code can be a gift