You can read each symbol, but you can’t make sense of the text. Since I work with mostly, the article can be seen in the light of JavaScript aura, nevertheless, it is a general issue and should not be limited by boundaries of one language. All said below is applicable to entire software development. Disclaimer: JavaScript We are too much obsessed with how do we write code New design patterns, new frameworks and libraries, or, even new languages (TypeScript, Elm, Reason, ClojureScript, Dart) being created each full Moon, to help developers to do the — to down application logic. Hadn’t we already had multiple ways of writing code before? Do we really need that one more framework, which will help us to describe application logic a fraction better than we’ve been doing already? Maybe. Don’t get me wrong, I like constant improvements in existing frameworks, and I like new frameworks and tools being created, but, I don’t think we should spend all our energy and give only to that. As an industry, we are too much obsessed with how do we write code, we want to make writing process perfect, while the . same thing write all our attention way how do we read code is totally left behind Observation #1: We don’t write code in the vacuum, almost always we rather edit or extend existing codebase than adding new features on the blank page. Code reading phase must follow first It means . And you may think: “He must be kidding, of course, we understand code around before doing changes”. Do we? So many times I caught myself on a thought that I have quite a in code. It’s just that one more line, one more property, one more simple behaviour to already existing feature, I can just write that code right away, right?... all code changes you plan to make will fit only if you read and understand code around narrow view while making changes Observation #2: We do local code changes and totally miss the big picture. Now multiply all of that by the number of team-members who edit your codebase without picturing an entire application. What will happen in long term? Remember all the projects you’ve built from scratch? We all had that. Nice and fancy architecture, clean code, separate modules, encapsulated logic. Two years later? Probably, the answer is ‘no’ and you may already start wondering, why is that? What obstacle we had to continue building nice and clean architecture? It’s an easy question — we already had code there, that’s why. All we need to do was: to code around, it and , not just put “one more method call there” — only because code lines should be executed at one moment of time it doesn’t mean that code lines should be in one method (but I know, it’s easier like that). Clean code, did it look the same a year later? read understand make proper changes Observation #3: It seems like we have quite a struggle to write code properly if we need to read and understand existing code before that. Reading is hard, that’s why… “Deadline tomorrow”, “that old legacy from the previous team”, “I am a bit sleepy today” — all these and many other excuses we use to . We do assumptions instead: “I believe we don’t have this util method yet, I’ll add it”, “I think it’s a bit duplicated logic, but I can’t refactor everything now”, “One line fix, it must be the best solution ever”. That means we , only based on our guesses about code, but not based on knowledge after reading and analyzing code. not read code make changes in code blindly We avoiding reading code not because we are bad engineers, but, because it’s super hard. It’s the hardest task you can imagine in . programming . You take thousands small pieces and you need to generalize them to something more meaningful and less granular, in parallel recognizing repetitions and patterns, you are trying to see the big picture and make sense of all of that Observation #4: We either spend too much time ineffectively reading code, or, just decide to not read it at all. What does it even mean to ‘read code’? Well, first of all, let’s finally describe what it means to read code. It’s definitely different from reading your favourite fiction book, right? But let’s define itself first. If you try to come up with the definition of application code in your own words, it may look like this: code Code is a set of instructions (spread between files) that follow and transform data for pre-defined journeys, based on user behaviour and current environment state. Now, when we know what is code, it’s easier to understand what we trying to achieve when we are reading code. We want to: find out key steps for main journeys within an application (e.g. user registration, order submission, etc.) find out possible instructions which may affect data flow within a particular journey find out current environment state or circumstances which may affect it And we want to find out that fast. And have that knowledge forever in our minds. Because if you have that in your mind — you can see the big picture of the entire . You feel that power, don’t you? application logic being mapped to codebase You got a bug, and you already know why it happened and what line in code you should change, without even reading code. Or, they asked you about new feature, and you already know what refactoring in what file you should make in advance to keep clean architecture. Sounds too sweet to be true. Or can we do that? And then you woke up. Engage with code, don’t just look at it And now you may think: “Cmon dude, I am losing my temper here, why are you talking about these obvious things”. Well, obvious things that . How many do you use to read and understand code? Effectively. It’s a key word here. We can understand and make sense of any code if we have all the time in the world, but usually, we don’t. And usually, we just open codebase in our favourite code-editor and start jumping from file to file in full chaos. And it bothers me. We can do better than that. bother no one tools or techniques First of all. in order to start understanding code, it is not enough just to read it. You need to dive deep into it to be able to feel it. You need to engage with code, it . That is why refactoring helps so much to understand code — you read and make adjustments in parallel. reinforces your learning abilities But not only refactoring can do that. You can start doing harmless changes in code by writing comments. You can start leaving in code: it’s very important thing to mark places in code where you already been, places you already have seen and analyzed, or places you just don’t want to miss. You can always use them as a trail to find your way out of a . breadcrumbs code-maze And, since I mentioned code-maze, let’s think about it. Maybe, we’ve been looking at code from the wrong position all this time? It’s hard to find a way out from a maze (meaning, hard to read code lines and connect dots in your mind) when you are already deep inside a maze. Maybe, we should do one step back here. you are not inside a maze, but you are looking at it from the top — so it’s not a maze anymore, you can clearly see everything! And since you are imagining, think about even crazier scenario — what if entire maze just had gone and you’ve been guided where you should go and what file look to? Imagine all that noise of huge code base just disappeared.. Imagine What if there may be solution for all of that… Stay tuned, more coming soon. If you liked this post and want to have updates about my next articles, please follow me on twitter ! @bliashenko

Flow

Super

Twitter

Too Long; Didn't Read

Learn how to continuously improve your codebase

How to stop reading code and start delivering.

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@bohdanliashenko

RELATED STORIES