Your First Legacy Codebase
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 84 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31574 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Greatest elementWordPhysical systemMassAreaMultiplication signLevel (video gaming)BitVarianceExecution unitTwitterKey (cryptography)Element (mathematics)Universe (mathematics)Context awarenessEndliche ModelltheorieArithmetic meanLine (geometry)Moment (mathematics)CASE <Informatik>Disk read-and-write headParameter (computer programming)SummierbarkeitTraffic reportingTheoryMeta elementCodeBuildingFunctional (mathematics)Software developerDampingSocial classTheory of relativityPosition operatorTouchscreenSoftwareFreewareTouch typingSoftware bugWeb-DesignerDiagramCartesian coordinate systemProjective planeStructural loadProcess (computing)Active contour modelWeb browserMathematicsAuthorizationBlogOpen sourcePhase transitionProduct (business)Different (Kate Ryan album)Data managementDomain namePerspective (visual)PlanningTerm (mathematics)Military baseComputer clusterContent (media)WebsiteSubsetWritingWeb 2.0Scripting languageCodeSpeech synthesisElectronic program guideOperator (mathematics)Computer animationLecture/Conference
07:42
InformationQuicksortoutputShape (magazine)Term (mathematics)Mobile appFrustrationDifferent (Kate Ryan album)Process (computing)Strategy gameMachine visionCodeDecision theorySocial classGroup actionCollaborationismComputer architectureString (computer science)State observerTape driveCycle (graph theory)ForceBootingMathematicsRevision controlSoftware bugEndliche ModelltheorieDisk read-and-write headCAN busArithmetic progressionCodeSoftware developerOrientation (vector space)Sheaf (mathematics)Client (computing)Computer fileProgramming paradigmSoftware frameworkTwitterGoodness of fitSimilarity (geometry)Dependent and independent variablesCartesian coordinate systemDerivation (linguistics)Physical systemComplex (psychology)Patch (Unix)Moment (mathematics)Server (computing)Multiplication signData structurePlanningResultantMereologyForm (programming)Arithmetic meanWordRight angleNumberLikelihood functionTheoryPhysical lawWater vaporOrder (biology)Power (physics)
15:14
Code refactoringExpected valueElement (mathematics)Software design patternPlanningMereologyCartesian coordinate systemBound statePattern languageCodeComputer architectureInformationInheritance (object-oriented programming)CausalityDecision theoryTerm (mathematics)Row (database)Software testingPerspective (visual)GodValidity (statistics)WordSoftware developerCASE <Informatik>QuicksortShape (magazine)Source codeSoftware bugSoftware repositoryMacro (computer science)Core dumpConnectivity (graph theory)Set (mathematics)SoftwareHand fanLatent heatRoutingMathematicsView (database)Logical constantFlagLogicModule (mathematics)File formatProcess (computing)Interactive televisionSocial classContext awarenessArithmetic progressionFunction (mathematics)Computer fileArray data structureInformation privacyFrequencyNumberWell-formed formulaForm (programming)Metropolitan area networkMultiplication signPower (physics)Food energyAreaUniverse (mathematics)Greatest elementRight angleWeightComputer animation
22:46
QuicksortElectric generatorTruth tableMassCellular automatonWordDiagramSoftwareCode refactoringFamilyService (economics)Row (database)Focus (optics)Condition numberCodeCASE <Informatik>Multiplication signInformationPhase transitionBitGraph (mathematics)Level (video gaming)Decision theorySoftware testingCore dumpStatement (computer science)Source codeTouch typingComputer fileFigurate numberMathematicsOperator (mathematics)Complex systemoutputResultantCartesian coordinate systemFunctional (mathematics)Suite (music)Process (computing)Control flowSet (mathematics)Combinational logicDifferent (Kate Ryan album)Social classPhysical systemVariable (mathematics)Theory of relativityObject (grammar)State of matter2 (number)Video game consoleRevision controlForm (programming)Loop (music)IterationCycle (graph theory)Software developerLine (geometry)Power (physics)TheoryMereologyEndliche ModelltheorieRight angleTraffic reportingAreaBasis <Mathematik>Interior (topology)Volume (thermodynamics)Electronic mailing listMetropolitan area networkUsabilityComputer animation
30:19
Computer animation
Transcript: English(auto-generated)
00:03
As a rail developer, when you were going through your training, you were creating
00:31
a lot of applications using rail to remediate travel script and making things from scratch. This is what we call green-build development, where you have endless possibilities ahead
00:42
of you and you can basically build things however you want to build them. When you go to work for a company that you're going to be working for, which is generally going to be working out as a legacy application, and the opportunities to build applications from scratch are probably scarce. I want to help you understand how best to work with a legacy Rails application today.
01:05
Who am I? I've been doing web development since 1993, so it's 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 in my name.
01:22
I have the most awesome, band-aid URL ever, where I provide web codes. You can go there to find out where I'm speaking and who's writing about me and my occasional blog posts. I have a four-line meta on Twitter. Twitter is really the best way to get in touch with me. I don't really like to email very much anymore. I generally treat up Ruby and social justice, and I exchange funds with everyone.
01:46
You heard this morning in the keynote about Rails and helping a Twitter project. I'm the author of that Twitter project. It's called Intruder Government. It is the most popular open-source Twitter product in the world. There are 14,000 that help children including Rails, JRuby, Elixir, RSpec, and Plumber.
02:03
I work at GitHub on the community safety team. I work on building community management features and anti-theracism features. If you're wondering, yes, it is possible, and yes, it does not happen, perhaps not happen, but it's happening to other people. My job is really to make open source, more welcoming, inclusive for everybody.
02:22
It's pretty easy also. I'm also a notorious social justice warrior. I just swim with my green heart. He's a teen now, and I'm so sore to give up. You should think everything I say today with a greater self, because I'm coming at this from the perspective of a very liberal, transgender feminist,
02:40
who believes that people should not be shit to each other online. That's my controversial opinion, and I'm thinking everything I say with a greater self. Legacy code bases. Let's start by deploying our terms. A legacy code base is, generally speaking, a very large code base. It's kind of like building. It's kind of hard to work in. It's a code base that is really difficult to wrap your head around.
03:02
I believe that you cannot make significant changes to an application unless you can hold the whole thing in your head. And a legacy code base needs to be so large that it's really challenging to do that. In a lot of cases that the companies are going to be working for, the people who wrote the legacy code aren't there anymore. They moved on to other things, because as developers,
03:22
we don't really stay at companies very much anymore. So it's very likely that the people who engineered the code base that you're working on now are all along the board, and sunk a lot of time and money into the code base that you're operating in now. It's a significant adjustment, and they're not going to give up.
03:40
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 the writing is, the content is the writing. And as tempted as you might be to say, screw this, let's just start over, it's not really something that's feasible. So what makes me qualified to talk about legacy applications?
04:01
As I mentioned, I work at GitHub. I receive some things. GitHub probably has the largest legacy Rails 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 base that I work on.
04:20
In 2014, I joined a company called Instructure. They have a learning management software called Canvas. Canvas is open source, so I can talk about it freely. It's a massive code base. There are 400 models and 200 controllers. All told, the application is defined by about 12,000 models. You can go and check it out on GitHub.
04:41
It's Instructure, it's on Canvas, it's OMS. About 30,000 commits by hundreds of developers. And when you go and look at the application, it's really overwhelming. There's so much to it. They tried to organize it logically. There are a lot of folders in the models folder,
05:01
a lot of folders in the contours folder, but it's really complicated. It's a very complicated 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 nature, and fix some bugs in my system's code base?
05:22
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 was called waterfall development. And what waterfall development is,
05:40
you divide development into a series of phases. So you would have a discovery phase, where you're trying to figure out exactly what the application you're building is going to do. You would have a design phase, where you would architect it, and plan out exactly how you're going to build it. Then you'd have a development phase, and then you'd have an acceptance phase. Some cool things came out of the waterfall process,
06:01
even though we had made them in for more rapid development these days, but it had some things going for it. For one thing, you had to tell the requirements. One of the first things you got as a job was a requirements supplement, and usually there's a great, great guide for you to come to this day. But it told you everything the application was supposed to do, in great detail. It told you who the users were,
06:21
it told you about their interactions, it told you all about every feature, every functionality. From that design phase, we had positions on teams called software architects. If you work for a really big company, you might still have architects. I know there's a difference, but they're pretty much a coming screen.
06:40
Architects would build diagrams like this, which showed how every piece of the system interacts with every other piece of the system for a given operation. So you could see how the different pieces came together and how they're supposed to help each other. In Rails, we just fire up our editor, and by doing tasks, after the waterfall days, we would do class diagram,
07:00
which we would plan out what actually exists in the class that I have, what are its public mandates, what are its private mandates, and what are its relations to other classes. So, in short, waterfall, we had very thorough practices. Everything was spelled out for you, and development was kind of free of guesswork. There was also very creative creativity,
07:22
and the bad thing about waterfall development was that it was a pain-place load. Any project would take six to 12 months in general, and if you had a mistake in your design phase or your discovery phase, and you found out, oh, this feature can't work that way, or oh, we forgot to add, we forgot to plan for this particular feature.
07:42
Change was very expensive because the later you go through your development process, the more expensive change returns. So, these days, we live in the age of a cowboy boater. We do just-in-time architecture. We wait until the last possible moment, make decisions about the structure of our code.
08:01
So, what does just-in-time architecture look like? It seems to be evolutionary. The architecture is not planned in advance, but it's a product of organic growth. It seems to be fluid. There are no guiding principles around how an application starts and how it grows. So, the whole thing tends to be somewhat marvelous. Unfortunately, just-in-time architecture
08:21
is going to be undocumented because we're busy developers. We're just trying to find features and fix bugs. Who has the right documentation? Architectures these days are easily influenced by trends in the industry, and it's kind of interesting if you have a large-scale legacy application, you can actually be an archaeologist and dive through layers of code
08:42
to 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 talks about better archaeology and I think more about that. And with many just-in-time architectures, decisions were made by the most opinionated developers
09:00
who tend to be the loudest of developers. So, we heard this morning about a strong accomplishment is loosely held. I believe that was the one I'm saying, because that brings with it a culture of orientation rather than collaboration. So, to have a clear mental model of an application, as I mentioned, it's almost impossible to maintain and develop with that.
09:20
So, what stands in the way of wrapping your head around a large-scale application, oftentimes, if you went through a boot camp, especially, and you were using the latest version of Graf, maybe even EdgeRabs, and the latest JavaScript frameworks, the legacy application still has older versions of things, and GitHub was the one where it was great. And the ABC frameworks on the client side
09:40
are using Makeup and maybe a little behind the scenes as well. So, if you know how to do things in the latest version of Ruby, the latest version of Graf, and you go back to the older version, you're gonna find yourself kind of hindered because some of the tools that you would naturally reach for just don't exist yet. All applications tend to entropy, and legacy applications have a lot of time to slide toward complexity.
10:07
Given the just-in-time architecture that fueled 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 cohesion, lack of things coming together to work together in a seamless manner.
10:24
We can often hear that the whole thing is held together with duct tape and string. And the strong opinions, loud voices, the helpers that I mentioned, they don't tend to be good collaborators. So, you might find that individual sections of the code base are highly opinionated and reflect the technical decisions
10:40
and technical opinions of one person, whereas you go to a different section of the code base and things are designed to be coded differently. So, everyone knows what a DOM code is. It's a class-like user that's about 3,500 lines long, and you're afraid to touch it. Classes attract new methods the way that one coding account can. Every class wants to be huge.
11:03
Every class wants to live forever. As an application grows in size, when you get a large collection of classes, developers are loathed at adding new files to a large project, so they tend to tack on methods onto existing classes, whether they go a little long there or not, and whether they violate similar responsibility principles.
11:23
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 oftentimes, they'll be a private job server. And what this actually does is not reduce complexity.
11:41
It spheres the code base across different repositories, making it that much harder to understand exactly what's going on. Finally, my least favorite thing about remaining monkey patches, so if you don't know, monkey patching is opening up an existing class, like string or array, and adding a method to it, or worse yet,
12:02
changing the way the existing method works. I've seen this happen. So if you go for array, you're like, oh, it's enumerable, it has this method, and you try it out, and you get an unexpected result because someone has monkey patched an emerald. It's the worst thing that can happen to you, and there's no documentation of it because, of course, it's not a Ruby document,
12:21
because, of course, it's not standard. So you're stuck trying to figure out exactly how something in series works. It sounds pretty daunting. Working with a legacy application doesn't sound like much fun. It sounds like it's a real chore. It sounds like there's kind of a lot of pain involved in it, and that's true. But we can't come up with a strategy for working effectively with it and wrapping our head around it.
12:42
There's a strategy that was developed by a military person, a United States Air Force colonel named John Boyd. He applied this process to combat operations, and today fighter pilots use this, particularly to make decisions, but it can be applied in a lot of different situations. We're going to explore its application in terms of what it's like to go.
13:02
So it's called LUDAA, which stands for Observe, Orient, Decide, Act. 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 a situation, and you're filtering it out to understand how things that you're seeing
13:20
apply to the problem that's trying to be solved in it at the moment. Observations are basically the raw information that you want to bring yourself to and decide on. The observed information has to be processed before you can argue on it. So this is where you bring your own experience and your own knowledge to bear the sort of shape and inputs that you got
13:41
in the previous phase, and that shapes the way that you observe, the way that you decide, and the way that you act. In the decide phase, you take a course of action. Decisions are based on best guesses, based on observations, and your orientation. Decisions are works in progress. You're not going to get it right the first time through. As you keep cycling through LUDAA,
14:02
new suggestions keep arriving, and these will trigger changes to your decisions. Essentially, you're learning as you go, which is a good thing. Finally, the act stage. This is where you follow through on your decision, and then you cycle back to observe, and as you judge, you make best of your action, and this leads into the learning process.
14:20
So let's take a look at each of those as they apply to the legacy code base. First is observation, how you observe the legacy code base. If you're lucky, and you're not going to be lucky, there will be a doubt for your resident patient, and it will be full of good history. It will explain exactly how the system works, maybe some of the derivative documentation from people who document their code really well,
14:42
whichever one does the course. So don't get around to documenting them, basically. Sometimes, people are nice, and they make in-line comments that describe, oh, here's what this method does, here's inputs and here's how it does, if you're lucky. So look for good comments, and see if they actually exist. A lot of larger companies keep WAKIs.
15:03
WAKIs are really hard to maintain. They punish you through their internal base, and I like to say that WAKI stands for rare information that kills itself. So don't come to WAKI up to date, but it might be there, you might have to establish kind of a baseline. One of the jobs that I worked at,
15:21
we had these things called architecture decision records. If you don't have these, bring this to your company, if it's the only thing you 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 an issue that says, we need to solve the problem paths. We need to figure out a way to solve the problem paths.
15:42
And you talk about what the considerations are around that, what you're trying to achieve, some of the rough spots you see, and you say, what did this? And they'll let 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 sticky point, or this edge case?
16:00
And you actually engage in a discussion via an issue. And at the end, you arrive at consensus, if you're WAKI, which you should be eventually aware of consensus, even if people in this case are arguing about it. And you keep that issue around, you close it, but it's part of your repo. So someone who sees this code in the future can say, and if you went to a portal that supported the implementation,
16:22
someone can go back and say, what was the decision-making process? Why did we choose to implement code in such a clear way? And now you have a record of it, and it's a very low-friction way of doing things, because we're all used to working with issues on GitHub. So architecture decision on GitHub is pretty much wrong. You can also look at pull requests. So when you're
16:40
working on a particular part of the codebase, look for pull requests and reference that part of the codebase, because you'll always see comments on the pull request that shape the way the code was written at the end. People generally think of tests as code validation, and tests are really valuable for good validation. Some people would use tests to drive development. People write a test where they write a lot of code,
17:03
plus test-oriented development. Those are important, but I think the most important role that tests play is documentation, because tests reflect bugs that are occurring in code. They reflect edge cases, and they reflect the way a code is supposed to work. They're essentially a specification for how
17:20
code works. So reading tests can be extremely illuminating when you're trying to figure out how an application works. And if you use RSpec, there's this format flag that you pass to RSpec. You should write this down. That sheds format documentation, and the output you'll get from it is human-readable specifications. So in this case, we're running it
17:40
on a membership model, and we get membership that determines its own credibility. Membership calculates its expiration in days, and so on. So this is something you can read through and understand, oh, that's what the membership cause is doing, that's what it's all about. So use your tests for documentation. And finally, you're not going to be able to get around reading that code. I talk to a lot of
18:02
data developers, and I talk to a lot of people who are in the camps, and they ask, how are we going to get better at Ruby? And I tell 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. How well people have coded, what coding conventions are, what best practices are, and learn from the coherence of your peers.
18:24
Reading code and the legacy code base is important, too, because you're going to learn how to put together and what sort of expectations there are for code quality and patterns. So that's observation. The observed information is to be processed,
18:41
you can orient and make a decision. And this is where we draw on our experiences and our knowledge and on ourselves. So there's 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 this code base
19:02
solve that problem for us? You also want to look for terms of art, and this is basically the custom vocabulary, the custom jargon that applies to the industry you're in, and the code base you're in, so keep the glossary as you're in, if you're new to glossary, but these are the
19:21
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 you'll make onboarding a much better experience for them, so
19:41
it's a way to think after them. 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 code problem is actually a personal problem. It's very valuable early on to look for the subject matter
20:00
experts, not only on the sort of things that the business is doing and that the software is doing at the macro level, but say, who runs the subsystem, or who's one of the people who works on this particular component. You can use deep blame to find out who's doing the most of the mix and get some particular code base, and find the people that can answer
20:20
your questions for you. Another great way to bridge yourself to an application is by checking out the routes file. In a Rails application, routes define 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 logic all comes together to solve the problem.
20:41
You can get a great view of what the application is actually supposed to do. So then come to the decision base. What are you 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.
21:00
This isn't just in the context of, oh, I'm working this feature and it's a little 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 them. I'm going to reconstruct them
21:20
from scratch. I'm going to use tests to see when I've stepped outside the bounds of what's expected for these methods or this functionality. And I'm going to challenge my assumptions about how it works. And I'm going to re-implement it. And that can be a great learning experience. So make a plan for how you're going to do an exploratory refactor. For inheritance,
21:41
I'm not a big fan of inheritance. There are these tools in the Ruby and it's essential in Ruby. I'm just not a fan of using it in my applications. But a lot of applications use inheritance. You might have a base class that implements a core set of methods or defines an interface. And you have a lot of other classes that sort of interact with it. Understanding those and knowing,
22:00
if I had to extend this, what would I do? Would be a great way of equipping yourself to make changes to my code base. Also, look for modules that express common behavior that's shared by multiple constants. And ask yourself, if I needed to implement this behavior, what modules would I be using?
22:20
On a team of gems, especially about the privacy applications, they tend to collect gems like crazy. And the gem file is really long. And no one can actually say what the Ruby arrays are being used for or what the gem is being used for anymore. So an interesting thing that can help you prepare the code base is to take out a gem
22:41
and run the task and see what breaks. It's pretty critical when you're working with code base to understand what the relations between an object and a class 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 wrote a tool a few years ago called Society.
23:01
And what Society does is it shows you a conflict between classes. And that conflict might be the form of this class instantiates an object in this other class or it calls a method on this other class or it has a relation to the object record. In turn, it's diagrams that look like this. This is working in the cell mass. I don't expect anyone
23:20
to make sense of that diagram because it's too complicated. But one thing you can do is use the sort of chunks where a couple of them together. And if you're doing a refactor of your legacy application into something like a service or architecture, that can say that can tell you sort of where the edges are. If we zoom in a little bit and Society's graph is interactive so you can click around
23:40
and focus the information. You can see this case course which is the core level from Canvas where you can see all the things that the course touches. So that can be really handy thing. You can give it out, you can give it blobs, you can give it a single file. It's pretty flexible where you can use it, you can select Society from and you can do that tomorrow and it generates a nice graph
24:00
so try that out. Go exploring it. Find something that's interesting or challenging or messy and figure out how you change it or how you can add to it. Figure out where a method is defined. Find all the places it's called and ask yourself why does it live in the place where it lives
24:20
and how would I change it or extend it if I'm here to be that. The truth. 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 one when I was coming up. It's called the truth table and I'm going to give you a better example of this one. In a truth table you have one column for every input. So for every
24:40
variable you have a column and for every operation on a variable you have another column which says basically 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 is conditional. This is not nearly as bad as I've seen in some applications but it's a little
25:00
bit complicated. It can be a little bit hard to figure out what's going on. So let's take the first condition. If availability equals get work hours with date, the focus has get work hours. So here's a truth table. This lays out all the possible combinations of all the variables that are expressed in this conditional. And that first conditional is rather than in French.
25:21
If get work hours is true basically it doesn't matter what get family hours is or what get French hours is the focus will be what is the outcome of that method will always be worked on. If we take the second conditional problem if availability is get family hours with date, the focus has been family. So that is the reason for this truth table.
25:42
We know that get work hours is false because we've fallen through to the second condition and the 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, the focus has been on friends. This is the last row in our truth table. We know
26:00
that get work hours is false and get family hours is false because we've fallen through to the last conditional and the outcome is friends. So this is like a really trivial example but if you have a really messy conditional, maybe a case statement which would help get it, writing a truth table can really help you sort of untangle what's going on. And if you have to write something
26:20
that's a nasty conditional, a truth table can form what kind of tests you're going to write for it as well. So that's your truth table. So that's the decision phase. Now it's time to actually do something with what you've learned. You want to start out by making a wrench and I recommend you create a throwaway wrench or a throwaway
26:42
cracker. It's something you can experiment in safely without changing or allocation. And again use a test suite as a barbell so that you know when you've gone up the cracks, when you've implemented functionality in a way that causes unexpected results. Eat that
27:01
zone, trample Tokyo, break the application, remove things, change things, remove the methods, see what breaks. You can learn a lot about a system by observing the failure cases. So what happens when this class is instantiated with a different set of inputs? What happens when you put in something weird on the webform?
27:20
What happens when you put in the input characters? You can learn a lot by examining what happens when you are kind of ruthless with the code base. Pry is one of my favorite tools. Who uses Pry? Awesome. I'm glad to see that. So that's just a refresher. Like basically in the source code you've been required
27:40
to pry or identify. And what that does is it interrupts oriented flow. So when you execute this code it drops into a console and you can examine the state of the world. So in this case we're looking at what is this user thing that we talked about? These are objects we can first name for a line. This is a cycle
28:02
and it's important to repeat that cycle. It's a loop. Every iteration of the loop gives you new information. It allows you to orient yourself better to what you're working on. It gives you a greater understanding of the powers you need to have. So it is a very simple tool. In my experience, it gives you a code base that is foreign to our
28:22
understand. And in general when you're going through it, remember what you're trying to accomplish. You've been hired to maintain an application and add features to it. You're trying to become a valued member of a team. You're trying to be productive. So do everything in your power to achieve that particular goal.
28:42
Understand that you're not going to understand the big complex system the first week of your job or even the first month of your job, this ongoing process you're going to be constantly discovering new things and incorporating that into your purpose of knowledge. And it's going to enable you to do bigger and better things, but it definitely has an awesomeness that you need to keep at.
29:01
Pair up with someone. You might have a senior developer on your team. Look for someone who is good at teaching, not everyone who is a senior is good at ensuring our teaching. So find that person or if you've been hired by a few other new people, find someone to pair with who is also learning. If you're collaborating and you're learning while you're doing it yourself, believe it or not, you are
29:25
smart enough to figure out an obvious way to deal with this piece of work. Start shaking. Add some features. Pick some bugs. Do some refactoring. This code base is your new home. It's where you're going to be spending at least eight hours a day for the next year and a half.
29:43
So be the one who loves it. Even for all those flaws. Outside of the software industry, legacy is not a bad word. Legacy is something, it's a gift that's given from one generation to the next generation. And I think if we're thoughtful about the way we write the code, if we orient ourselves correctly and are writing code that is meaningful and
30:01
ethical and positive, then that code can be, that legacy code can be a gift that developers come after us.