Detailed Notes
This episode delves into the intricate world of code chaos, coding standards, and best practices, and exploring the importance of writing maintainable code. Hosts Rob and Mike share their insights and experiences, shedding light on the challenges and solutions in the realm of software development.
What is Code Chaos?
Rob and Mike set the stage by discussing the frustration of code chaos. This is where similar code functionality is scattered and duplicated code across projects. They emphasize the significance of architecting solutions rather than hastily pushing code changes.
Identifying Testing Challenges
From a QA perspective, the hosts highlight the testing complexities associated with duplicate code. They discuss the pitfalls of repetitive testing efforts and the risk of inconsistent functionality across duplicated segments.
Exploring Refactoring Solutions
Rob and Mike elaborate on various approaches to address code duplication, emphasizing the importance of refactoring. They discuss leveraging modern IDE tools for code standardization and the role of automated code analysis tools like SonarQube.
Implementing Structural Changes
The conversation extends to structural adjustments, such as consolidating duplicated methods into utility functions or superclass inheritance. They stress the need for systematic organization and reuse of code components to streamline development.
Utilizing External Libraries
Recognizing the limitations of legacy code, Rob and Mike advocate for integrating external libraries and dependencies. They emphasize the benefits of leveraging established community-supported solutions to replace outdated or redundant code.
Avoid Code Chaos Encouraging Best Practices
The hosts conclude by encouraging developers to adopt best practices, such as adhering to standardized coding styles and utilizing established libraries. They emphasize the importance of continuous improvement and collaboration within the development community.
Avoid code chaos by writing maintainable code, which emerges as a paramount objective in navigating the complexities of software development. Developers can mitigate code duplication and foster sustainable development practices by embracing strategic refactoring, structural adjustments, and leveraging external resources.
We invite you to share your experiences and insights as we wrap up this discussion. Whether you’ve triumphed over project challenges or faced unexpected hurdles, your stories enrich our collective learning journey. Honesty, clarity, and proactive communication are the cornerstone of successful software development. Until next time, happy coding!
We’d love to hear from you! Email us at [email protected] or visit our website to share your thoughts and stories. Stay tuned for more enriching discussions in the episodes to come.
Additional Resources
* The Importance Of Writing Readable Code - https://develpreneur.com/the-importance-of-writing-readable-code/ * Code Reviews – Build Habits And Best Practices - https://develpreneur.com/code-reviews-build-habits-and-best-practices/ * Software Development Challenges and How To Navigate Them - https://develpreneur.com/software-development-challenges-and-how-to-navigate-them/ * SonarQube - https://www.sonarsource.com/products/sonarqube/
Transcript Text
[Music] hey everybody we have already started ranting and so we're just going to hit hit record and continue uh we're talking about right now and this is bonus stuff for you guys that are out there in the YouTube World we'll pick into more of the the meat of it shortly on the the podcast side but we're talking about code when do you the difference between like just get it done slam it in there get it done versus we'll say in quotes double quotes air quotes doing it right uh which is there's two layers two different ways at least to do it right because there is the this is how it's you know best practi is done object-oriented kind of stuff if you're an object-oriented language and making sure that you have readable code and comments and you don't have functions that have four billion lines of code in them and things like that but then there's also the right that's probably more important a lot of times which is development standards and if you're with a team in particular and you have development standards that's right whatever it is whether it's wrong or not in a general sense that is what you should be doing you should be working towards that standard and that's where we sort of got into our our rants a little bit about the the balance back and forth and so this episode before I even introduce Mike because he's just choing it the bit over there uh we're going to dive in and we're g to go right into the podcast side and we're gonna we're going to talk about this so today this episode we're gonna we're g get a little bit on a little ranty a little soap boxy and we're going to talk about sort of the the give and take of when do you when do you do it quick and when do you do it you know take your time and really architect Your solution and maybe is there a Middle Road so let's go ahead and get started well hello and welcome back we are continuing our season where we're just talking about a lot of different stuff we've we've switched up our formats a little bit we've gotten off of some of our other seasonal type topics and this season we're really getting into some of the things that we hit on on a daily weekly basis this episode we're going to talk about something that is near and dear to our part our hearts because we've been venting just before we hit record and it's about writing code writing it good maintainable and part of the whole discussion is when do you architect a solution and when you just like slam that sucker home and on the other side that's got like smoke coming out of his ears right now because this is where we started this all thing is Mike so why don't you go ahead and introduce yourself hey thanks Rob my name is Michael malash I'm co-founder of velur and founder of Envision QA and like Rob said we're talking about coding standards and coding practices today because you know I've been working on a project recently that is uh kind of a hot mess of code we have duplicate code all over the place and we're trying to figure out best standards and things of that nature and I guess I'm remiss if I don't U myself if you have a if we haven't met hi I'm Rob I am a co-founder of develop or and also uh founder of RB Consulting you can go check that stuff out at some point want to dive into this discussion and that is the key I think is the replication of code that Michael just hit on it's like you what you don't want to do is you don't want to maintain something where to change a a feature or to upgrade something you have to go change it in 15 different places the whole goal I mean one is you don't want to have billions of lines of code because it's just hard to figure out where is where is the the piece of code that you need to fix what is the thing that's broken but also if you want to maintain stuff it is very painful and error prone to have you know five different places you have to write code to do this new feature whatever it is and then you got to make sure that every piece you got it every piece you've got all the same you know the same functionality particularly if you're like I've seen many times where you may have the code theoretically the same in five different places but it's not because there's like a little thing that changed here or something that changed there and so you can't just like copy and paste and put it in each of those and boom we're off and running you have to make sure that you're utilizing all the right variables you got all the right things that all the context is the same and you have to test every single one of those pieces so now you're you're having to test something probably further Downstream so we'll start with that is what are your especially from a QA and a testing point of view what are your thoughts in in that world about just the you know the example I did the codes in five different places and we got to go make some changes so if the codee's already there and it's in five different places from a testing perspective unit testing alone should tell you that hey we've got a problem we're we've got we're doing the same functionality in multiple places uh you could essentially copy and paste the test but then now you've duplicated work in the code now you're duplicating work in the test and the other problem you might have is whatever uh classes or methods are calling this code is it calling the right section you know if you have a method here that's doing one thing and you copy that and do it somewhere else but you change one but not the other are you really going to get the changes you need so having duplicate code well from a testing standard yeah you can test it but the problem is from a coder's perspective how do you know which one to use uh it it becomes difficult and really you got to kind of watch that I mean yeah you can copy and paste but unless the functionality of that method itself is very specific for example if you're building uh like online reports so if you have a worksheet on one page uh on one report and it's the same worksheet on another report and but because they are two different reports potentially you would copy the code from one report to the other report because one report might change in the future so that's one situation where you might have two different places of code uh because the sheet itself might be different at some point in two different places so you don't want to change it on one report and suddenly change it on the other but with that being said if you have a universal report or sheet that should be on each one that would never change because you're always displaying all the data then that should be in a central place then and you should reuse that for all your reporting purposes and that I guess will reach back a little bit into the object oriented world is that's really when you want to look at the IDE like the concept of subclassing something if you've got that case where you've got two reports that start out let's say the same or you know the only difference is maybe a little bit of the data or maybe a couple little V variables that you can send in then maybe it makes sense that those both live as the we'll call it the report class but then you see one that now has a lot of changes to it then maybe what you do is you now just say hey I'm going to have a subass I'm have a child of that report class and I'm going to do my do all my customizations there so at the core I can have those things flow through and then I've got my extensions basically or my specialties on that other report that get picked up now because I don't want to go too long in this episode because we can I do want to flip little bit to the all right we've laid out a problem let's talk about the solutions for this and one of the first things is as you sort of implied is you say Hey what if what if we come into this situation so we're sitting there and we've got to change code and it's in five different places and we now have to we see that we see that it's replicated what do we do now there is the the the tried and true standard of kick it down the road turn it into technology Tech de create a ticket for it and just move on however it may be useful for you to in that time go ahead and simplify that thing from the five places down to the one for example this is one that I've run into a couple of times where somebody there were different developers and you may see this at times there's different developers that come into this solution and they've come in at different times and there hasn't been they haven't really spent a lot of time learning the code before they got in and started writing functionality and you end up having two functions that are meant to do the exact same thing and maybe the name is off by a case difference or there's an underscore or it's just a slightly different signature you know there's like one extra variable that's sent in or something like that those things and I have been in those where it's like yeah you can call either one doesn't matter you're going to get the same result back technically you're going to get the same result back either one you see something like that we have so many good refactoring tools and just if nothing else Global search and replace take one of those things knock it out put all the code in the other one and just you if you're gonna take a little longer to get the code done that's fine take a little longer to get the code done and feel free to like just tell your boss your who the customer whoever it is this is going to save you in the long run what are some great what are some of the approaches you've had so it's interesting you talk about the tools so one of the funny things is because you mentioned this before we hit record was you know some people when they're doing code reviews or you're working on a project they look at what code changes have been done and if you do too much refactoring uh or add to many spaces it looks like you've made a lot of changes when you really haven't in one of those cases you almost every modern day IDE allows you to do a full refactor or reformat of all your code so it can be standard I and there's sites out there where you can go get uh code style standards you know Google SC site there's a whole bunch of places for all these idees where you can get one decide what you want like Google you know Jasper whatever you pick a style you apply it to your ID basically format your code compile it all and then go from there basically you create a Baseline and you move forward so that's one approach the other approach is not only the refactor but so many tools nowadays not only will do the refactor but they will also help identify if you have duplicate code with in your application for instance you can use sonar Q um or sonar lint uh basically the free version of the cloud paid version and that will help you identify a lot of places where you have duplicate code uh where you have code smells and other potential uh problems within your system lastly to address that the the final part of that is the other thing is and we'll probably get into this a little bit more but if you find code that's in multiple places like for example the one you just said where you have a method here and a method there and talking about the object oriented world there's times when you want to make it like move it up make it like a parent move it into an object but there's other times where you want to create utility files for example uh one of the projects I've worked on recently actually had multiple methods in different classes on opening up or creating temporary files on the system and some actually handled the file closure correctly some did not some had bad exception handly and I think I end up ripping it out of seven places and creating one files utils with that method that handled it for everything uh so that's kind of the last thing I'll touch on I'll pass it back to you rob that's actually a great point I like that last piece because there are I've been in a few of those where which you end up having is yeah you spend a little time rolling all those things up into the the udle function or method but then what you end up doing is you can look at all of those and a lot of times you'll find that they work they do have differences so you can sort of take them and combine them into the best of all of them combined so you have something now that that properly handles all the different types of exceptions does it does all the resource management it does all of those things and even if it doesn't at least now you've got it one place so now you have consistent functionality for that feature and things like that are so common where it's you know it's like I've seen so often where it's date formatting types of things if it's not already built into and actually even when it is built into the language there's all these different ways that people will deal with with casting and moving dates around file manipulation is almost always going to be something uh sending emails sending sms's notifications those kinds of things that are just part of an application it is amazing how often there's like a or even within little U you know model files that you'll have something that there's all these little format or like little methods that somebody has that's not really part of the class they're just like hey I just need to you know reformat this address in this way and I'm just going to do it here as opposed to pulling out to a utility which begs the question or pushes the forward to say hey if you're writing some little utility thing on your method I mean on your class then think about pulling it off to a utility and just put it out there so you have a nice little container of here's the things that we may use regardless of what uh you know what package you happen to be in yeah it may seem like it's a little bit Overkill but there's also stuff like you know you don't have to you make it depending on the CL the language you can make it all static so you don't have to actually instantiate anything it's basically just like having free flowing functions floating around there's a lot of ways you can get around it if you're worried about that kind of overhead and you're smirking so I'm wondering what you're what you wanted to add on that so one additional thing I'd like to add to that is a lot of times especially with Legacy code you have methods that are out there to do specific little tasks like format a string or convert an integer or do some little utility thing that you couldn't do within the like the code libraries at the time A lot of times there are so many common code libraries out there now especially like in the Java world you have Apache Commons um you know JavaScript has nodejs they have a lot of different packages you can add on there and sometimes it's better to just go add a dependency go add on one of these utility classes and rip all this code out get rid of the stuff that is not tried and true or may be so obsolete that you're getting bugs just because you're using that and use something that the industry already supports that the community supports that has been flushed out that does work and then you just plug it in and your code works I mean you you remove a lot of that uh unnecessary uh fluff that's in your code that doesn't need to be there anymore and that does that makes it it does make it a lot easier for for others to come behind you and read it and see it as well because they're like oh I've SE like a patchy Commons is a great example particularly with like the things that have evolved over the last several years I guess now like Json stuff and XML stuff even file manipulation there's a lot of those things that it's just yeah early on it maybe wasn't as good it was a little clunky it was a little bit of a pain but now these these libraries have progressed to a point where a lot of times there's stuff and it's yeah you'll find something that was all done by hand was all manual it's like hey we have to solve this problem that's awesome you did an okay job but now let's take it to this Library where now we can just include it in we don't have to worry about you know keeping our keeping up ourselves with it we can just have that library and pick up that re that version or that um you know that pride and true piece of code that being said I think we'll wrap this one up we'll keep it so we don't go too long because we have done that a few times and as always if you have any questions shoot us a email at info developer.com check us out at developer.com you can see all kinds of posts lots and lots of content on wide ranges of languages and software development techniques and entrepreneurial stuff as well and check us out on YouTube out at youtube.com develop andur I believe that's itd develop andur our develop andur Channel and you can see this plus so many other things that we put together in the last several years now uh as always though you if there's any questions if you need us to go do a little searching feel free to ask us and we can probably point you to some examples um or maybe even some people that have done some of the same things that you're struggling to get through or you know have answers that are even better than ours for your questions that being said go out there and have yourself a great day a great week and we will talk to you next time and there's a little video bonus for everybody as grabbing a drink of water between sessions so what you say I think that was like a good short ranty kind of one yeah uh might be a little under 20 minutes on that one um it'll be close but yeah no that was good I like that that was a good cut off place um I liked how we kind of bounced from the the initial problem into kind of the different ways to look at without getting too technical without going down to too many different solutions like we didn't even touch on um you know clean code breaking it down into pieces we didn't really get too far into over optimizing over engineering uh which are topics All In themselves so yeah I think those are perfect yeah I'm okay with this going if we go a little short we go a little short they can come back to the you know they can come check out the YouTube channel if they want extra stuff if they don't get enough of us from the audio version [Music]
Transcript Segments
[Music]
hey everybody we have already started
ranting and so we're just going to hit
hit record and continue uh we're talking
about right now and this is bonus stuff
for you guys that are out there in the
YouTube World we'll pick into more of
the the meat of it shortly on the the
podcast side but we're talking about
code when do you the difference between
like just get it done slam it in there
get it done versus we'll say in quotes
double quotes air quotes doing it right
uh which is there's two layers two
different ways at least to do it right
because there is
the this is how it's you know best
practi is done object-oriented kind of
stuff if you're an object-oriented
language and making sure that you have
readable code and comments and you don't
have functions that have four billion
lines of code in them and things like
that but then there's also the right
that's probably more important a lot of
times which is development standards and
if you're with a team in particular and
you have development standards that's
right whatever it is whether it's wrong
or not in a general sense that is what
you should be doing you should be
working towards that standard and that's
where we sort of got into our our rants
a little bit about the the balance back
and forth and so this episode before I
even introduce Mike because he's just
choing it the bit over there uh we're
going to dive in and we're g to go right
into the podcast side and we're gonna
we're going to talk about this so today
this episode we're gonna we're g get a
little bit on a little ranty a little
soap boxy and we're going to talk about
sort of the the give and take of when do
you when do you do it quick and when do
you do it you know take your time and
really architect Your solution and maybe
is there a Middle Road so let's go ahead
and get started well hello and welcome
back we are continuing our season where
we're just talking about a lot of
different stuff we've we've switched up
our formats a little bit we've gotten
off of some of our other seasonal type
topics and this season we're really
getting into some of the things that we
hit on on a daily weekly basis this
episode we're going to talk about
something that is near and dear to our
part our hearts because we've been
venting just before we hit record and
it's about writing code writing it good
maintainable and part of the whole
discussion is when do you architect a
solution and when you just like slam
that sucker home and on the other side
that's got like smoke coming out of his
ears right now because this is where we
started this all thing is Mike so why
don't you go ahead and introduce
yourself
hey thanks Rob my name is Michael malash
I'm co-founder of velur and founder of
Envision QA and like Rob said we're
talking about coding standards and
coding practices today because you
know I've been working on a project
recently that is uh kind of a hot mess
of code we have duplicate code all over
the place and we're trying to figure out
best standards and things of that
nature and I guess I'm remiss if I don't
U myself if you have a if we haven't met
hi I'm Rob I am a co-founder of develop
or and also uh founder of RB Consulting
you can go check that stuff out at some
point want to dive into this discussion
and that
is the key I think is the replication of
code that Michael just hit on it's like
you what you don't want to do is you
don't want to maintain something where
to change a a feature or to upgrade
something you have to go change it in 15
different places the whole goal I mean
one is you don't want to have billions
of lines of code because it's just hard
to figure out where is where is the the
piece of code that you need to fix what
is the thing that's broken but also if
you want to maintain stuff it is very
painful and error prone to have you know
five different places you have to write
code to do this new feature whatever it
is and then you got to make sure that
every piece you got it every piece
you've got all the same you know the
same functionality
particularly if you're like I've seen
many times where you may have the code
theoretically the same in five different
places but it's not because there's like
a little thing that changed here or
something that changed there and so you
can't just like copy and paste and put
it in each of those and boom we're off
and running you have to make sure that
you're utilizing all the right variables
you got all the right things that all
the context is the same and you have to
test every single one of those pieces so
now you're you're having to test
something probably further
Downstream so we'll start with that is
what are your especially from a QA and a
testing point of view what are your
thoughts in in that world about just the
you know the example I did the codes in
five different places and we got to go
make some
changes so if the codee's already there
and it's in five different places from a
testing perspective unit testing alone
should tell you that hey we've got a
problem we're we've got we're doing the
same functionality in multiple places
uh you could essentially copy and paste
the test but then now you've duplicated
work in the code now you're duplicating
work in the test and the other problem
you might have is whatever uh classes or
methods are calling this code is it
calling the right section you know if
you have a method here that's doing one
thing and you copy that and do it
somewhere else but you change one but
not the
other are you really going to get the
changes you need so having duplicate
code well from a testing standard yeah
you can test it but the problem is from
a coder's perspective how do you know
which one to use uh it it becomes
difficult
and really you got to kind of watch that
I mean yeah you can copy and paste but
unless the functionality of that method
itself is very specific for example if
you're
building uh like online reports so if
you have a worksheet on one page uh on
one report and it's the same worksheet
on another report and but because they
are two different reports potentially
you would copy the code from one report
to the other report because one report
might change in the future so that's one
situation where you might have two
different places of code uh because the
sheet itself might be different at some
point in two different places so you
don't want to change it on one report
and suddenly change it on the other but
with that being said if you have a
universal report or sheet that should be
on each one that would never change
because you're always displaying all the
data then that should be in a central
place then and you should reuse that for
all your reporting
purposes and that I guess will reach
back a little bit into the object
oriented world is that's really when you
want to look at the IDE like the concept
of subclassing something if you've got
that case where you've got two reports
that start out let's say the same or you
know the only difference is maybe a
little bit of the data or maybe a couple
little V variables that you can send in
then maybe it makes sense that those
both live as the we'll call it the
report class but then you see one that
now has a lot of changes to it then
maybe what you do is you now just say
hey I'm going to have a subass I'm have
a child of that report class and I'm
going to do my do all my customizations
there so at the core I can have those
things flow through and then I've got my
extensions basically or my specialties
on that other report that get picked up
now because I don't want to go too long
in this episode because we can I do want
to flip little bit to the all right
we've laid out a problem let's talk
about the solutions for this and one of
the first things
is as you sort of implied is you say Hey
what if what if we come into this
situation so we're sitting there and
we've got to change code and it's in
five different places and we now have to
we see that we see that it's
replicated what do we do now there is
the the the tried and true standard of
kick it down the road turn it into
technology Tech de
create a ticket for it and just move on
however it may be useful for you to in
that time go ahead and simplify that
thing from the five places down to the
one for example this is one that I've
run into a couple of times where
somebody there were different developers
and you may see this at times there's
different developers that come into this
solution and they've come in at
different times and there hasn't been
they haven't really spent a lot of time
learning the code before they got in and
started writing functionality and you
end up having two functions that are
meant to do the exact same thing and
maybe the name is off by a case
difference or there's an underscore or
it's just a slightly different signature
you know there's like one extra variable
that's sent in or something like that
those things and I have been in those
where it's like yeah you can call either
one doesn't matter you're going to get
the same result back technically you're
going to get the same result back either
one you see something like that we have
so many good refactoring tools and just
if nothing else Global search and
replace take one of those things knock
it out put all the code in the other one
and just you if you're gonna take a
little longer to get the code done
that's fine take a little longer to get
the code done and feel free to like just
tell your boss your who the customer
whoever it is this is going to save you
in the long run what are some great what
are some of the approaches you've had so
it's interesting you talk about the
tools so one of the funny things is
because you mentioned this before we hit
record was you know some people when
they're doing code reviews or you're
working on a project they look at what
code changes have been done and if you
do too much
refactoring uh or add to many spaces it
looks like you've made a lot of changes
when you really haven't in one of those
cases you almost every modern day IDE
allows you to do a full refactor or
reformat of all your code so it can be
standard I and there's sites out there
where you can go get uh code style
standards you know Google SC site
there's a whole bunch of places for all
these idees where you can get one decide
what you want like Google you know
Jasper whatever you pick a style you
apply it to your ID basically format
your code compile it all and then go
from there basically you create a
Baseline and you move forward so that's
one approach the other approach is not
only the refactor but so many tools
nowadays not only will do the refactor
but they will also help identify if you
have duplicate code with in your
application for instance you can use
sonar Q um or sonar lint uh basically
the free version of the cloud paid
version and that will help you identify
a lot of places where you have duplicate
code uh where you have code smells and
other potential uh problems within your
system lastly to address that the the
final part of that is the other thing
is and we'll probably get into this a
little bit more but if you find code
that's in multiple places like for
example the one you just said where you
have a method here and a method
there and talking about the object
oriented world there's times when you
want to make it like move it up make it
like a parent move it into an object but
there's other times where you want to
create utility files for
example uh one of the projects I've
worked on recently actually had multiple
methods in different classes on opening
up or creating temporary files on the
system and some actually handled the
file closure correctly some did not some
had bad exception handly and I think I
end up ripping it out of seven places
and creating one files utils with that
method that handled it for everything uh
so that's kind of the last thing I'll
touch on I'll pass it back to you rob
that's actually a great point I like
that last piece because there are I've
been in a few of those where which you
end up having is yeah you spend a little
time rolling all those things up into
the the udle function or method but then
what you end up doing is you can look at
all of those and a lot of times you'll
find that they work they do have
differences so you can sort of take them
and combine them into the best of all of
them combined so you have something now
that that properly handles all the
different types of exceptions does it
does all the resource management it does
all of those things and even if it
doesn't at least now you've got it one
place so now you have consistent
functionality for that feature and
things like that are so common where
it's you know it's like I've seen so
often where it's date formatting types
of things if it's not already built into
and actually even when it is built into
the language there's all these different
ways that people will deal with with
casting and moving dates around file
manipulation is almost always going to
be something uh sending emails sending
sms's notifications those kinds of
things that are just part of an
application it is amazing how often
there's like a or even within little U
you know model files that you'll have
something that there's all these little
format or like little methods that
somebody has that's not really part of
the class they're just like hey I just
need to you know reformat this address
in this way and I'm just going to do it
here as opposed to pulling out to a
utility which begs the question or
pushes the forward to say hey if you're
writing some little utility thing on
your method I mean on your class then
think about pulling it off to a utility
and just put it out there so you have a
nice little container of here's the
things that we may use regardless of
what uh you know what package you happen
to be in yeah it may seem like it's a
little bit Overkill but there's also
stuff like you know you don't have to
you make it depending on the CL the
language you can make it all static so
you don't have to actually instantiate
anything it's basically just like having
free flowing functions floating around
there's a lot of ways you can get around
it if you're worried about that kind of
overhead and you're smirking so I'm
wondering what you're what you wanted to
add on that so one additional thing I'd
like to add to that is a lot of times
especially with Legacy code you have
methods that are out there to do
specific little tasks like format a
string or convert an integer or do some
little utility thing that you couldn't
do within the like the code libraries at
the time A lot of times there are so
many common code libraries out there now
especially like in the Java world you
have Apache Commons um you know
JavaScript has nodejs they have a lot of
different packages you can add on there
and sometimes it's better to just go add
a dependency go add on one of these
utility classes and rip all this code
out get rid of the stuff that is not
tried and true or may be so obsolete
that you're getting bugs just because
you're using that and use something that
the industry already supports that the
community supports that has been flushed
out that does work and then you just
plug it in and your code works I mean
you you remove a lot of that uh
unnecessary uh fluff that's in your code
that doesn't need to be there anymore
and that does that makes it it does make
it a lot easier for for others to come
behind you and read it and see it as
well because they're like oh I've SE
like a patchy Commons is a great example
particularly with like the things that
have evolved over the last several years
I guess now like Json stuff and XML
stuff even file manipulation there's a
lot of those things that it's just yeah
early on it maybe wasn't as good it was
a little clunky it was a little bit of a
pain but now these these libraries have
progressed to a point where a lot of
times there's stuff and it's yeah you'll
find something that was all done by hand
was all manual it's like hey we have to
solve this problem that's awesome you
did an okay job but now let's take it to
this Library where now we can just
include it in we don't have to worry
about you know keeping our keeping up
ourselves with it we can just have that
library and pick up that re that version
or that um you know that pride and true
piece of
code that being said I think we'll wrap
this one up we'll keep it so we don't go
too long because we have done that a few
times and as always if you have any
questions shoot us a email at info
developer.com check us out at
developer.com you can see all kinds of
posts lots and lots of content on wide
ranges of languages and software
development techniques and
entrepreneurial stuff as well and check
us out on YouTube out at youtube.com
develop andur I believe that's itd
develop andur our develop andur Channel
and you can see this plus so many other
things that we put together in the last
several years now uh as always though
you if there's any questions if you need
us to go do a little searching feel free
to ask us and we can probably point you
to some examples um or maybe even some
people that have done some of the same
things that you're struggling to get
through or you know have answers that
are even better than ours for your
questions that being said go out there
and have yourself a great day a great
week and we will talk to you next
time
and there's a little video bonus for
everybody as grabbing a drink of water
between
sessions so what you say I think that
was like a good short ranty kind of one
yeah uh might be a little under 20
minutes on that one um it'll be close
but yeah no that was good I like that
that was a good cut off place um I liked
how we kind of bounced from the the
initial problem
into kind of the different ways to look
at without getting too technical without
going down to too many different
solutions like we didn't even touch on
um you know clean code breaking it down
into pieces we didn't really get too far
into over optimizing over engineering uh
which are topics All In themselves so
yeah I think those are perfect yeah I'm
okay with this going if we go a little
short we go a little short they can come
back to the you know they can come check
out the YouTube channel if they want
extra stuff if they don't get enough of
us from the audio version
[Music]