As I look at this codebase, I can see that it's quite extensive and has been carefully structured to ensure efficiency and scalability. The first thing that strikes me is the sheer amount of scripts and configuration files, which suggests that the project has been built from the ground up using a robust framework. But what really catches my attention is the way everything is organized into neat directories and subdirectories, each with its own specific purpose.

For instance, I notice that there's a "Libs" directory, which contains a plethora of different types and shared variables that are used across both the front-end and back-end. Rather than duplicating code or having to manually implement similar functionality in multiple places, this approach allows for reusability and maintainability. The Libs directory is also home to various constants, enums, and types that can be easily imported and used throughout the project.

Another aspect of the codebase that stands out to me is the presence of service accounts, which enable deployment and management of local environments with different permissions. This level of granularity is essential for ensuring that sensitive data is handled securely and that access controls are in place. The fact that there are unit tests scattered throughout the codebase also suggests a commitment to testing and validation, which is essential for delivering high-quality software.

As I delve deeper into the code, I notice that each function has its own corresponding test suite, which provides an added layer of assurance that everything is working correctly. This approach also makes it easier to identify and fix issues, as well as to refactor and improve existing code without introducing new bugs or side effects. By focusing on testing and validation upfront, the developers can ensure that their software meets the required standards and is more resilient to errors and failures.

The use of automated scripts and workflows is another key aspect of this codebase. For example, I see that there are scripts that automatically execute all tests for the React Native application before allowing a pull request to be merged into GitHub. This level of automation helps reduce manual effort and increases productivity, making it easier to deliver high-quality software on time.

In terms of configuration management, the developers have clearly put thought into how to handle different environments and store sensitive data securely. By using a combination of environment variables, secrets managers, and other techniques, they can ensure that the codebase remains flexible and adaptable without compromising security or stability.

One aspect of this codebase that I think will resonate with our readers is the importance of documentation and user experience. The presence of a README file and clear instructions for running the app suggests that the developers have prioritized accessibility and usability. By making it easy for non-technical users to get started, they can ensure that their software reaches a wider audience and delivers real value.

In conclusion, this codebase is a testament to what's possible when developers prioritize organization, reusability, testing, and automation. While it may seem daunting at first glance, the attention to detail and commitment to quality that has gone into building this project is truly impressive. I hope that this video has given our readers a glimpse into the world of larger codebases and the strategies that can be employed to make them more manageable and effective.

"WEBVTTKind: captionsLanguage: enif you've never worked as a software engineer then chances are you've never seen a big code base so today I'm going to show you exactly that I've got a code base for a mobile app that I've been working on for a long time I've developed this with another software engineer we've got a few hundred, lines of code hundreds of different files quite a large structure there's a lot of different components to it and I think you're going to learn quite a bit in this video so with that said let's start exploring a large code base so I've got the code loaded here in vs code and I'll walk you through the over structure and give you a sense of what you can expect as a code base gets bigger and bigger and bigger now with that said even though this is quite a bit of code it's nowhere near as large as some other code bases that are maintained and developed by hundreds if not thousands of developers one of the code bases I worked on at my time at Microsoft was probably 200 times the size of this so even though this is quite large just imagine it can get much bigger than this this is just sufficiently large enough that I can kind of walk you through what ends up happening in in a large codebase so we'll dive into that but I do want to mention that I have a free school Community this is a place where you can network with other developers I've teamed up with a few YouTubers so we've got myself Kenny gunderman Nick white Kevin if you know who those guys are in the community we're already at over 7,000 members it's completely free you do not need to pay for it and you can join it from the link in the description anyways let's start walking through this project so a bit of context here this is for a react native mobile application for the startup that I'm currently working for it's closed source so I won't leak too much to you but I can walk you through the kind of General structure so we have a few different uh folders here in the root directory we have a GitHub or dot GitHub file or folder sorry where we have some workflows this is for running automated tests automated deployments Etc we have a CMS directory this is for the content management system we have functions this represents the backend we're using serverless functions hosted with Firebase for this project we have some Libs this is for some shared types and shared configuration and also functions that we use across both the front end and the back end and then we've got the main folder here which is for the actual application so the react native app that would run on your phone so notice right away we have kind of four sub projects within the main project we could have put these into separate repos but it made sense to kind of stick them together now if we go into something like velocity V2 the first thing you'll notice immediately is there is a ton of configuration files this is what starts happen quite quickly once you have a lot of folders a lot of files a lot of code a bunch of configuration is necessary to make sure that this works across all different types of devices and that you are configuring it properly for the different environments that you're running it in so for example if I go into EnV here you can see that we have some variables for the dev environment the production environment the staging environment and we need to manage those appropriately within the code and make sure when we load up the code and we're doing it a development versus staging versus production we have have the correct scripts that load everything in and give us the correct environment the absolute last thing we want is to be running the dev environment and accidentally modifying the staging or the production database that would be horrible right now along with all the configuration files here things like TS config reactnative config package Json gulp files fire. Json we have some custom scripts that will run before we actually start executing any code so things like generating the Google service file parsing some game data parsing some xcode configuration there's some things that we just need to do before we can start actually running the app and I wrote These in Python rather than writing them in typescript so that's the idea here you're going to have a lot of configuration a lot of different files a lot of environments and handling those becomes quite complex then of course we have our source now the source is where we actually have the code written for the actual application and inside of here we've got all kinds of different directories to really separate out all of the different uh what do you call it components use cases systems whatever you guys want to call them so we have things like utilities and within utilities we just have one file here we have styles we have some base Styles and a way to normalize some Styles we use RVE this is a way to do some Advanced animations we have a Redux folder within the Redux we have actions we have unit tests for all of our different actions same with the reducers we have all the different reducers and all the unit tests going up here we have some files just for navigation so how do we have the correct Navigators for registration login authentication Etc we have some different modules we have hooks so these are just react hooks that we put in their own separate folder we have some things related to the Google services so we need this when we're using Google signin and some other features we have a folder for different games in our application we have the source assets V directory we have a bunch of different components so inside of here we have all of the different react native components so we have components that are screens organized into different subdirectories so we have a loading screen we have main these are main screens like module details more profile public profile Etc we have registration screens again split into login profile username Etc we have welcome screen inside of its own folder so everything is meant to be super clear and easy to navigate So within just a few clicks I can immediately find the type of code that I'm looking for and I don't need to start searching through tons of different files now as well as that we've got a bunch of assets so same thing here for the assets we want to keep these nice and organized so we have fonts we have icons we have different logos we have uh some main assets like background some module details now that I'm looking at this some of the stuff could be named better we just got a lot of stuff going on we then have a file for an API call I don't actually know why that's there that should probably be removed but the idea is everything is nice and organized it's separated into different folders and directories and that way we can very easily find the code that we're looking for now as well as that we even started doing some localization so for example if we click into here you can see that we have all kinds of Vari Ables for the localized text and the strings that are going to be inside of our application right now we just have it in English but we knew that eventually we were going to want to add multiple languages so we should start doing that right away so we don't have to refactor a ton of stuff later on now what else do we have here that I can mention to you I think that's about it inside of this directory but you get the idea that there's quite a bit more than just writing in a specific framework right we've got a lot of scripts got a lot of configuration we have a bunch of tests and we have scripts that will automatically execute all those tests for us as well for example in our workflows here with GitHub we're automatically running all of the tests for our react native application but we're not going to allow you to merge a pull request unless the test pass so now I guess another thing I can show you is the libs directory so inside of Libs for example we have a bunch of different types and some shared variables that we want to use in both the back end and the front end so rather than copying them and having them in both the back end and the front end we made a shared Library this is a bit of a pain in the ass to actually Implement and Import in both of the projects but we knew it would be worth it because we need to have the same types shared across the front end and the back end uh pretty common with a typescript project so for example we have a bunch of different constants here which are separated into things like enums we have some other constants here I don't want to share too much uh we have an index file just to make this import a bit easier because we have path-based Imports and then we have a ton of different types which again are going to be shared across the projects I'm trying not to leak too much but I do want to show you a bit of the code then if we go inside of functions right we have service accounts now we need service accounts so that we're able to actually deploy this locally we can have different permissions based on who's actually executing this code that's for uh kind of Google services Firebase all that kind of stuff and then we have a ton of different functions that are called from our front end so we have functions related to the feed we have Libs this is actually a um I forget the name it's some kind of link not going to get into that right now we have things for modules we have things for notifications for the profile for the registration for social followers following making posts right and notice for every single one of these functions we have we have unit tests now in my case I really like to make sure that we have unit tests specifically for everything that's on the back end because as long as the data base is consistent and we know that we are correctly retrieving results and that all the backend functions are working properly the front end is a lot easier to test and we're not going to have bad data being sent to the front end so my idea in terms of getting speedier development here is we're going to make sure we test everything really thoroughly on the back end and then for the front end we can kind of test that later on or not be as strict because we know that all of the data is working correctly everything's being called correctly we have the correct error messages Etc right now that's pretty much all that I wanted to show you obviously I could walk through this codebase I could explain a million things and complex patterns and how to reuse code but I just wanted to give you a sense of what it's like once you start getting into a bit of a bigger code base you have a lot of different directories you have a lot of structuring you're making sure the naming is correct you want to obviously make sure you're not reusing code so setting up something like a shared library for different types or utility functions you really need to be careful with the configuration right so how do we manage different environments how do we store sensitive data uh how do we make sure that we're not manually doing a ton of things and that everything is as automated as possible so we're running a bunch of scripts that maybe do a manual operation that we typically would need to write ourself or typically need to perform ourself how do we make sure that someone who's not technical can run the app and has decent instructions for how to do that that's why you would include something like a readme file I think you guys get the idea here and hopefully this video gave you a bit of value and at least just kind of Expos you to what's possible once you start getting into some bigger code bases again this is by no means big in consideration of all the code bases that exist but I know a lot of you have never worked as a software engineer or you've never even seen a code base anywhere near this size you've worked in one or two files probably at most so I wanted to kind of give you a taste of what it's like anyways if you guys enjoyed make sure to leave a like subscribe to the channel and I will see you in the next oneif you've never worked as a software engineer then chances are you've never seen a big code base so today I'm going to show you exactly that I've got a code base for a mobile app that I've been working on for a long time I've developed this with another software engineer we've got a few hundred, lines of code hundreds of different files quite a large structure there's a lot of different components to it and I think you're going to learn quite a bit in this video so with that said let's start exploring a large code base so I've got the code loaded here in vs code and I'll walk you through the over structure and give you a sense of what you can expect as a code base gets bigger and bigger and bigger now with that said even though this is quite a bit of code it's nowhere near as large as some other code bases that are maintained and developed by hundreds if not thousands of developers one of the code bases I worked on at my time at Microsoft was probably 200 times the size of this so even though this is quite large just imagine it can get much bigger than this this is just sufficiently large enough that I can kind of walk you through what ends up happening in in a large codebase so we'll dive into that but I do want to mention that I have a free school Community this is a place where you can network with other developers I've teamed up with a few YouTubers so we've got myself Kenny gunderman Nick white Kevin if you know who those guys are in the community we're already at over 7,000 members it's completely free you do not need to pay for it and you can join it from the link in the description anyways let's start walking through this project so a bit of context here this is for a react native mobile application for the startup that I'm currently working for it's closed source so I won't leak too much to you but I can walk you through the kind of General structure so we have a few different uh folders here in the root directory we have a GitHub or dot GitHub file or folder sorry where we have some workflows this is for running automated tests automated deployments Etc we have a CMS directory this is for the content management system we have functions this represents the backend we're using serverless functions hosted with Firebase for this project we have some Libs this is for some shared types and shared configuration and also functions that we use across both the front end and the back end and then we've got the main folder here which is for the actual application so the react native app that would run on your phone so notice right away we have kind of four sub projects within the main project we could have put these into separate repos but it made sense to kind of stick them together now if we go into something like velocity V2 the first thing you'll notice immediately is there is a ton of configuration files this is what starts happen quite quickly once you have a lot of folders a lot of files a lot of code a bunch of configuration is necessary to make sure that this works across all different types of devices and that you are configuring it properly for the different environments that you're running it in so for example if I go into EnV here you can see that we have some variables for the dev environment the production environment the staging environment and we need to manage those appropriately within the code and make sure when we load up the code and we're doing it a development versus staging versus production we have have the correct scripts that load everything in and give us the correct environment the absolute last thing we want is to be running the dev environment and accidentally modifying the staging or the production database that would be horrible right now along with all the configuration files here things like TS config reactnative config package Json gulp files fire. Json we have some custom scripts that will run before we actually start executing any code so things like generating the Google service file parsing some game data parsing some xcode configuration there's some things that we just need to do before we can start actually running the app and I wrote These in Python rather than writing them in typescript so that's the idea here you're going to have a lot of configuration a lot of different files a lot of environments and handling those becomes quite complex then of course we have our source now the source is where we actually have the code written for the actual application and inside of here we've got all kinds of different directories to really separate out all of the different uh what do you call it components use cases systems whatever you guys want to call them so we have things like utilities and within utilities we just have one file here we have styles we have some base Styles and a way to normalize some Styles we use RVE this is a way to do some Advanced animations we have a Redux folder within the Redux we have actions we have unit tests for all of our different actions same with the reducers we have all the different reducers and all the unit tests going up here we have some files just for navigation so how do we have the correct Navigators for registration login authentication Etc we have some different modules we have hooks so these are just react hooks that we put in their own separate folder we have some things related to the Google services so we need this when we're using Google signin and some other features we have a folder for different games in our application we have the source assets V directory we have a bunch of different components so inside of here we have all of the different react native components so we have components that are screens organized into different subdirectories so we have a loading screen we have main these are main screens like module details more profile public profile Etc we have registration screens again split into login profile username Etc we have welcome screen inside of its own folder so everything is meant to be super clear and easy to navigate So within just a few clicks I can immediately find the type of code that I'm looking for and I don't need to start searching through tons of different files now as well as that we've got a bunch of assets so same thing here for the assets we want to keep these nice and organized so we have fonts we have icons we have different logos we have uh some main assets like background some module details now that I'm looking at this some of the stuff could be named better we just got a lot of stuff going on we then have a file for an API call I don't actually know why that's there that should probably be removed but the idea is everything is nice and organized it's separated into different folders and directories and that way we can very easily find the code that we're looking for now as well as that we even started doing some localization so for example if we click into here you can see that we have all kinds of Vari Ables for the localized text and the strings that are going to be inside of our application right now we just have it in English but we knew that eventually we were going to want to add multiple languages so we should start doing that right away so we don't have to refactor a ton of stuff later on now what else do we have here that I can mention to you I think that's about it inside of this directory but you get the idea that there's quite a bit more than just writing in a specific framework right we've got a lot of scripts got a lot of configuration we have a bunch of tests and we have scripts that will automatically execute all those tests for us as well for example in our workflows here with GitHub we're automatically running all of the tests for our react native application but we're not going to allow you to merge a pull request unless the test pass so now I guess another thing I can show you is the libs directory so inside of Libs for example we have a bunch of different types and some shared variables that we want to use in both the back end and the front end so rather than copying them and having them in both the back end and the front end we made a shared Library this is a bit of a pain in the ass to actually Implement and Import in both of the projects but we knew it would be worth it because we need to have the same types shared across the front end and the back end uh pretty common with a typescript project so for example we have a bunch of different constants here which are separated into things like enums we have some other constants here I don't want to share too much uh we have an index file just to make this import a bit easier because we have path-based Imports and then we have a ton of different types which again are going to be shared across the projects I'm trying not to leak too much but I do want to show you a bit of the code then if we go inside of functions right we have service accounts now we need service accounts so that we're able to actually deploy this locally we can have different permissions based on who's actually executing this code that's for uh kind of Google services Firebase all that kind of stuff and then we have a ton of different functions that are called from our front end so we have functions related to the feed we have Libs this is actually a um I forget the name it's some kind of link not going to get into that right now we have things for modules we have things for notifications for the profile for the registration for social followers following making posts right and notice for every single one of these functions we have we have unit tests now in my case I really like to make sure that we have unit tests specifically for everything that's on the back end because as long as the data base is consistent and we know that we are correctly retrieving results and that all the backend functions are working properly the front end is a lot easier to test and we're not going to have bad data being sent to the front end so my idea in terms of getting speedier development here is we're going to make sure we test everything really thoroughly on the back end and then for the front end we can kind of test that later on or not be as strict because we know that all of the data is working correctly everything's being called correctly we have the correct error messages Etc right now that's pretty much all that I wanted to show you obviously I could walk through this codebase I could explain a million things and complex patterns and how to reuse code but I just wanted to give you a sense of what it's like once you start getting into a bit of a bigger code base you have a lot of different directories you have a lot of structuring you're making sure the naming is correct you want to obviously make sure you're not reusing code so setting up something like a shared library for different types or utility functions you really need to be careful with the configuration right so how do we manage different environments how do we store sensitive data uh how do we make sure that we're not manually doing a ton of things and that everything is as automated as possible so we're running a bunch of scripts that maybe do a manual operation that we typically would need to write ourself or typically need to perform ourself how do we make sure that someone who's not technical can run the app and has decent instructions for how to do that that's why you would include something like a readme file I think you guys get the idea here and hopefully this video gave you a bit of value and at least just kind of Expos you to what's possible once you start getting into some bigger code bases again this is by no means big in consideration of all the code bases that exist but I know a lot of you have never worked as a software engineer or you've never even seen a code base anywhere near this size you've worked in one or two files probably at most so I wanted to kind of give you a taste of what it's like anyways if you guys enjoyed make sure to leave a like subscribe to the channel and I will see you in the next one\n"