Sooner or later, if you are a programmer, you are going to acknowledge the code of a live project. This is not a surprise and when you do face it, mind my words, it's an altogether different world.
Nothing that you've written till now stands abreast with that code. Because that second-world code is written by professionals and with the understanding of a story writer. Yes, the story writer, because those professionals don't see variables, functions, classes, import statements, and those long lines of code as mere statements.
For them, they are actors, verbs, plot twists, family connections, and relationships.
If you want to learn how to read the code of a live project, continue reading this blog. Thank me later.
How to read an already written code?
(Significant Points)
- Not only the variables are just names but they also tell you about the date which is stored in them.
- Function names tell you what will happen with those variables.
- Class names tell you what RELEVANT variables and functions are encapsulated in that class.
- Import statements, at the top, will make sure what kind of packages, modules, and coder's own made classes, are being used.
- There must be individual blocks of codes that bring about the logic in the whole program.
So, where to start? Just 7 steps that you'll ever need!!
Most often than not, if you are dealing with MEAN/MERN technology programs, you're going to encounter one very important file, ie "package.json".
Step 1
"Go through the package.json file once"
If you have got the underlying hold of this file, you'll be able to catch what kind of libraries the project is using.
There are times when the projects use validations, they use libraries like formik, yup, etc.
For icons and styling, material-UI, sass, bootstrap, and more.
Like this, when you'll start knowing about these, you'll be ready for the code which may be coming your way.
Step 2
"Read Folder names"
Professional programs believe in immaculate logic, pithy files' and folders' names, and are solemn about reusability. You should once go through the names of all the folders that exist in your project.
If there are hundreds of files and folders, which are going to be, limit yourself to those which actually matter.
I work in React.js. So, for react developers, I know some important folder and file names. Some of them are src, components, actions, reducers, store, user interface, app.js, routers, routes, package.json (obviously), saga, middleware, and more.
Step 3
"Readout Route file thoroughly"
If you maintain MEAN/MERN stack projects, it's likely to say that you've encountered a file or folder name "route.js" or alike. This is the file where all your URL endpoints are maintained.
A novice programmer or professional needs to know what are paths a project is utilizing. Routes files have the path list in the object format. Similar to the JSON format, ie Javascript Object Notation.
The file can be said to have a base syntax as below:
const
allRoutes = [
{'var1': value1, ...},
{'var2': value2, ...},
{'var3': value3, ...},
.
.
.
{'var-n': value-n, ...}
]
Step 4
"Go for the Parent file"
Don't just wander around the project. Start looking for a parent file and stick to it. Read it, try to understand it, and if you are only able to understand it partially, look for the import statements that might be fetching user-made packages.
If you are a novice PHP developer, look for the code which is a bridge to the local host.
If you are a React Developer, look for App.js file and, in bigger projects, routes.js file.
If you code in node.js, look for the file in which APIs are being made. This is often very helpful as this clears your understanding of code. It also gives you a glimpse into the project.
Step 5
"Read, read more, modify, play with the code. One word: DEBUG IT"
Take a backup of the code/file somewhere and play with that file. You learn at your best when you do experimentation.
"Learning comes from mistakes."
If you can't understand the execution, delete any line and look at the result. If an error occurs, try to understand it. Google it, look at the solutions, paste the eliminated code and then move to the next line.
Repeat it until you can confidently say that you know how that code is working and what's its purpose.
Step 6
"Look for repetitive code"
If you are a web developer, you must've come across repetitive code. Like, there must be a program that is more than a hundred lines of code but all there is to it is repetition. The same block of code is written again and again for the sake of showing data.
Sometimes, to reduce repetition, we use functions like filter, map, and reduce.
We also create a function, class, component, or package and use it multiple times just to reuse the code.
So, if you just have a grasp on that unit of code, you are done. You'll be able to understand those files which use that piece of code.
Step 7
"Create a story"
Think like a poet, an artist, or a story writer. Think that you are going on a journey to the hilltop. You plan to count the steps, predict the path where you'll climb and when you're accomplished, assemble a camp.
How are you going to do it?
Firstly, let's create a variable to count steps: (We'll do it in JavaScript)
<script> letstepCount = 0; </script>
Now, let's assume the distance is 10 Km, can vary and the average human stride length is 1.3 m, can also vary.
We've to calculate the step count but, keep in mind, more than one person will want to calculate his/her steps with different stride measures and distances to the hilltop.
What should we do?
We must write non-repetitive, efficient, and reusable code. So, what we'll do is, we'll create a single function that will take all the necessary values and give us our preferred output.
In this case, our function will return the result.
<script>
function calculateSteps (stepLength, distanceToMountain) {
let stepCount = 0;
stepCount = ((DistanceToMountain * 1000)/stepLength);
return stepCount;
}
</script>Note: I've multiplied the distance (in Km) by 1000 to convert in meters. Otherwise, we'll face a logical error where the code will, unquestionably, execute but will show unexpected results.
Now, to execute this we can simply do:
<script> console.log(calculateSteps(1.3, 10)) #Expected Output: ~7,692 console.log(calculateSteps(1.2, 11)) #Expected Output: ~9,166 console.log(calculateSteps(1.39, 10.3)) #Expected Output: ~7,410 </script>
Yes, we can short the code by eliminating the variable and directly returning the value, like the code below:
<script>
function calculateSteps (stepLength, distanceToMountain) {
return ((DistanceToMountain * 1000)/stepLength);
}
</script>
This is a neat code for calculating the number of steps that it will take to cover a certain distance. If you look closely, this is also a story of parameters and a reusable function.
Just, in this way, bigger projects are made. Complexity increases, exponentially of course, but the programmers behind the code are only weaving the story.
Conclusion
In the end, all I'll say is live projects are not easy but they are simple. The sooner you have hands-on experience on a live project, the early and better it would be for you in this ceaseless career.
So, why futz, bro?
I hope this helps you in the long run. Do share your experience and views on how you cope with live projects.
Stay safe, stay healthy and live your life to the fullest! Because you only got one. :D
Comments: