Spaghetti code is the death of a project. After 40+ years as a software engineer (retired now) this has been my experience. And as Kyle found out taking over a project it is very difficult and refactoring is even more difficult. Clean code, small individual functions and remember the code should be readable by humans first. Kyle does great videos.
@jasonruff1270
11 ай бұрын
Y tf should I care about humans?
@tiagodagostini
11 ай бұрын
On other hand, some of the practices of the so Called Clean code book , when followed blindly instead of seeing where they apply reasonably, result in another type of spagheti (class bloat, that is just a different type of confusion)
@epiphaeny
11 ай бұрын
@@jasperonandroid I am currently refactoring a 1200 lines function with a cyclomatic complexity of almost 180... this is really no fun.
@frigzy3748
11 ай бұрын
The problem is that there is no clean code. I worked for almost every company from FAANG and clean code is not something I experienced.
@KroganCharr
11 ай бұрын
I'm pretty new in software dev and it's one of the first things I've learned the hard way: Keep your concerns separate. You should always be able to completely replace one thing, and everything else still works. X goes in, Y goes out, the rest of the code doesn't care what happens in between. That way, you never even get in the situation described in the video here, where you do a "refactor" that essentially amounts to a rewrite of the entire project. You shouldn't have to do a "refactored" branch that you work on in parallel to the productive branch. You should be able to push small, bit-by-bit refactoring to the productive branch. I'm not very experienced so maybe I'm being naive here, but maybe the best way to deal with "spaghetti code" is to leave it alone while it works, and when you do have to get into it, cut it to pieces while you're at it. Let's say you' go into legacy code to fix a big function that does 3 things. Split it into 3 while you're there, if possible. It may not be necessary at the moment and it may not offer immediate benefits, but it very well may pay off the next time you or anyone has to go there. Even if the logic is just as messy as it was before, separating concerns can go a loooong way and make any future refactoring efforts so much easier.
@mcmanussean
Жыл бұрын
Great advice! (20-year software engineer here). I'm surprised you didn't use the term "tech-debt", that's basically what you're describing. I think of addressing tech debt the same as addressing financial debt. You don't pay off 100% of your credit cards and then not pay your rent and buy food that month... You pay off a chunk at a time when you can afford it. If you address tech debt the same way (basically what you were describing) eventually your tech debt will be at a more reasonable level.
@tripunify
8 ай бұрын
tech-debt is overloaded term, but it is used all the time, it almost seem tech is not moving, so you go back and pay the price, but in fact when you or your team have a chance to refactor the code, the tech you use could already be out-dated. because tech is moving fast :)
@playmaker8894
Жыл бұрын
I was literally doing unnecessary refactoring this exact moment haha, what's so special about kyle is that he doesn't just teach you how to program, but the best, most optimal practices!
@paulthomas1052
Жыл бұрын
Hi Kyle, I've been a software engineer for longer than I'd like to admit to 🤫 and I totally agree that the refactoring effort can be a pointless and expensive portion of some projects. I worked on a large banking project for a well known UK finance house and spent (along with my team) way too long on refactoring code only to add more issues and cost. I understand the technical reasons but sometimes 'less is more' - it's a cliche I know but doing nothing sometimes beats doing lots !! - love your videos and all the best from UK !
@adamgoldsmith310
Жыл бұрын
You nearly got me with this one haha, overall great advice, using an iterative approach means that you can do small refactorings, and target areas of the code you are going to change next, I find that writing tests to capture the behaviour of your code before starting a refactoring is pretty much essential too, if you code doesn't have tests before you do this, it will after, this is also a good way to get into TDD
@punkypinko2965
Жыл бұрын
I promise, most devs are not spending too much time refactoring. They are writing 90% spaghetti code.
@jepsurrr
Жыл бұрын
Yes
@Azurryu
Жыл бұрын
I can't argue whether it's 90%, but most developers certainly don't go over their very first version of a function to at least clean it up.
@mikey7673
Жыл бұрын
Facts
@Oncopoda
Жыл бұрын
You promise? Source?
@Casprizzle
Жыл бұрын
That spaghetti code is their refactored code.
@scigama71
Жыл бұрын
if you put 5 developers in a room to develop an app. I bet they will all do it differently
@Blast-Forward
Жыл бұрын
Hopefully they use Prettier for common code formatting at least.
@jeremy0x
Жыл бұрын
@@Blast-Forward 🤣 it's usually weird when I see a code that's poorly formatted; especially HTML, CSS or JS with 4 spaces as indentation.
@genechristiansomoza4931
Жыл бұрын
@@jeremy0x4 spaces is not poor format
@KorhalKk
Жыл бұрын
@@jeremy0x I do space as indentation but just while I'm tweaking. Having that breather can help you find the lines easier.
@AndreasKempe
Жыл бұрын
Stupid saying that perfectly outlines the lack of planning in this society and also the perfection of constantly finding excuses for responsibilities. If you have a number of developers, the first thing to do is to design common standards and guidelines so that everyone does NOT do their own thing. Millions of projects show exactly this wrong behavior. incredibly ugly code in which everyone wanted to leave a little bit of their own "scent" because they consider themselves to be the best of all developers and in the end a project that triggers nausea and that no one can really work on properly.
@Homiloko2
11 ай бұрын
Clean and maintainable code always wins in the long run. You should always write well structured, understandable code. The thing you don't need is extremely optimized code for performance, that can come later when you actually reach a bottleneck and improving performance becomes a goal. Oftentimes, the time you'd spend gaining a few extra cpu cycles wouldn't even be noticed by the consumer. As for refactoring, you never have idle time to work on that. The way I do it, is I only refactor the classes and methods that I'm using directly in this new feature or patch that I'm working on. It's that idea of always leaving the place cleaner than when you entered. You do small (or large) refactorings along the way to achieve your goal, and the refactoring never becomes an activity in and of itself, and then you don't ever need to convince your managers and higher ups to alocate time for this (because they won't want to, they usually only care about the finished product).
@ifstatementifstatement2704
9 ай бұрын
Sure. If they only care about the finished product then they shouldn’t care how it’s been programmed either. Also not creating a class for everything, not having documentation comments, not writing tests and using basic commands of the programming language rather than the latest hot shit which takes time to learn, allows you to finish the project in a quarter of the time allocated for it during scrum meetings. That does not mean the code will be disorganised. It will be logical and will function. If any extension to it is needed then the programmers should be able to work on it if they are indeed programmers.
@robertholtz
Жыл бұрын
Refactor as you go. Ideally, think about the problem you’re solving in an abstract enough way that future iterations don’t need to be refactored to be extended. If you’re about to put a band-aid over another band-aid, refactor that section.
@Bgrosz1
11 ай бұрын
Refactoring iteratively is excellent advice. In your scenario, if you have new feature requests coming in and you don't know how much time you have available then you can't commit to a huge refactor. I refactored constantly, but often it was just the code file I was working in and small and easy refactors to make the code easier to read and update. I did plenty of large refactors, but I always knew I had the time available to do those before I had to add new features. Basically, if you're going to do a large refactor, then make sure the boss knows you need X weeks to just work on that. Your 80/20 advice is also excellent. If you can easily read and understand what the code is doing and it reasonably efficient, then your time is better spent elsewhere.
@Rachoszsky
11 ай бұрын
You didn't refactor the code, you did a rewrite. That's an important difference!
@arakovskiy
11 ай бұрын
Exactly
@TheVampWillow
3 ай бұрын
Hell yes. I'm glad you mentioned this: a refactoring is an isolated micro change to improve the design of existing code. If it is taking hours, let alone days, weeks or months, that is something else entirely. You _may_ end up making substantial changes over a long period using thousands of small refactors, but the overall activity is no more "refactoring" than running a marathon could be called "taking a step".
@vitvitvitvitvitvitvitvit
Жыл бұрын
I am experiencing something like what you went through when you were a fullstack developer. I do all the coding at my company (frontend with React and React Native, backend, deployment, etc.). I always want to refactor all the code because the me of two months ago was dumb. The worst thing is writing refactored code, which is supposed to be better, and it's not. I hate programming alone, but I think it's good in a certain way. Thanks for the tips! :)
@LanguageHelp
Жыл бұрын
In our project, we started refactoring by just hunting all if nestings and made them into if guards. It made us feel good about the code. The next time we refactor we'll focus on something small like that and change it across the code.
@petrtcoi9398
Жыл бұрын
What works for me is to put all the messy spaghetti code into a function, tuck it away in the 'utils' folder, and enjoy clean code in the rest of the project. It's like hiding the mess under the rug and never looking under it - very effective! 😄
@soniablanche5672
Жыл бұрын
Unfortunately sometimes you have to add spaghetti code in multiple files. Imagine if you have a system that adds stuff to a database, render an html page, sends email, sends notification and other bunch of stuff and each have their own file and your changes would break all of them unless you spaghetti code all these files.
@petrtcoi9398
Жыл бұрын
@@soniablanche5672 Usually, such a problem is solved by organizing the code, isolating individual functional parts from each other, thus preventing them from disrupting the operation of other parts. Here, you may have to compromise on the DRY (Don't Repeat Yourself) principles, but in my opinion, it's better than getting errors in unexpected places.
@justine_chang39
Жыл бұрын
i'm so glad to watch this video, because this sounds super similar to something I've done in the past too. Now I'm very cautious when it comes to committing to refactoring, and very cautious about updating / upgrading anything in the stack. I think we should only update is there's a bug in an older version, or there's a new feature we need in a newer version.
@tomraaff4576
11 ай бұрын
Additional tip to tip #2 ( There is no perfect code): Accept that some parts will be messy, but if you can: try to separate the messy/complex stuff from the other parts of the code as well as you can. This is where the single responsibility principle really shines. If you have a complex part that you simply can not simplify because it just is that complex, please make sure that the complexity doesn't leak out. Put it in it's own file(s) or module and make sure it's api is strict.
@nicejungle
Ай бұрын
Very good advice. Sometimes, some code is messy because of optimization (speed, memory load...) or external components with messy API. But if it's wrapped in a class with a clean API, it's ok. SRP is the first principle for avoiding spaghetti code.
@floppa9415
Жыл бұрын
It depends. I think some "clean code" best practices just aren't worth the hassle like hardcore inheritance, annotations, getter and setters when they aren't needed. But some have in my opinion have a massive impact long term. The biggest one being exact typing in typescript. For example if you have a function that takes a string but in reality only does something useful with the strings 'yes', 'no' or 'maybe' than specify this with a union type. When you look at the function a year from now you are gonna be glad you did.
@langhamp8912
Жыл бұрын
I find the Microsoft "interfaces" (not sure if other languages have something similar) to be hugely beneficial in keeping types honest across objects.
@Suto_Ko
Жыл бұрын
Absolutely, While some "clean code" practices may not always be worth the hassle, others, like exact typing in TypeScript, can have a significant long-term impact. Using union types to specify the valid input values for a function can improve code clarity and maintainability. It helps future developers understand the intended usage and prevents potential issues down the line. It's definitely a good practice to adopt for better code readability and maintainability.
@JustinK0
Жыл бұрын
It seems like if you're spending that much time to refactor the code, it seems like it wasnt "clean" in the first place, Open close principle for example suggest that its open to extend but not modify.
@randomguy-vq4ue
Жыл бұрын
making the code 1% more readable is already considered "refactoring". Never ever recode/refactor everything at once.
@75yado
11 ай бұрын
well it's situational. Sometimes you have to.
@pqsk
Жыл бұрын
You should slowly add unit tests too as you work on new/old code. I inherited a large code base last year that was written mostly bad. I started alone, but after a few months we hired one more dev. I got a good 25% of the code refactored to clean code. We’re now at about 50%. It takes time and patience, but unit tests are a must. If you refactor and then you introduce regression, you want to catch it as soon as possible. Sometimes they slip through, but it’s worse without any tests. Documenting is also a must, so you have use case steps to follow to ensure it’s all good
@csy897
Жыл бұрын
Agree. Unit tests will also help you structure the logic, make sure you explicitly know what context you're in and make sure the methods are not too complex because then it becomes difficult to test. Also, write better assertions as you go if using typescript. Because that will jump at you even before the unit tests.
@majorhumbert676
Жыл бұрын
What do you do when you have existing tests that are inherently coupled to the existing implementation? Tests are not unit tests and don't test the API.
@pqsk
Жыл бұрын
@@majorhumbert676 depends on what you’re testing. Black box testing will *always* be coupled to the implementation. White box testing shouldn’t be. Although if a function changes the post outcomes then that does require a change for white box testing.
@marcotroster8247
2 ай бұрын
The challenging part about refactoring is figuring out the domain model of the problem at hand. Most devs aren't good at this for some weird reason because we only test maths skills at university. All this DRY stuff doesn't help much. If the inherent problem complexity requires 2 things to be almost the same they're still separate things. DRY makes it tempting to introduce coupling to things that shouldn't be coupled. The "soft" part of software is actually important. You must preserve the ability to change the code. If you see a "utils" or "tools" or "misc" file, alarm bells should be ringing.
@limitlesskode
Жыл бұрын
I am experiencing this right now with a new company I just joined 😂. I’m presently refactoring
@Andrey-il8rh
Жыл бұрын
Being 1 developer on the project won't make you truly appreciate refactoring. Have you ever tried to work with a codebases supported by one hundred developers when no one refactor anything because the whole thing is already so fregile that jenga looks like a fortress next to it? I was and it's a complete nightmare. Refactoring should be embedded in the process on the most fundamental level and yes, it should be iterative, than it will work very good
@davidpsbn
Жыл бұрын
Man I love your content but for the love of God… can you hang at least 1 picture on that wall? It’s time…
@IvanToshkov
Жыл бұрын
I think this video compares apples to oranges. The first part talks about "the big refactoring", but it doesn't sound like a refactoring to me. It sounds more like rewriting at least a large chunk of the project. To quote Wikipedia: "code refactoring is the process of restructuring existing computer code-changing the factoring-without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality." The fact that you're not changing the code functionality during refactoring is quite important. It means that your unit tests should continue to work after the refactoring. Here is the process that I'm trying to follow regarding refactoring: 1. Don't start refactoring the code just for the sake of refactoring. Have a goal, like adding a new feature. 2. Identify the part that needs refactoring (if any) and what kind of refactoring does it need, to accommodate the new feature. 3. Make sure there are adequate unit tests for the relevant code. As a minimum you need tests that cover all the ways that code is currently used. 3a. If you're especially paranoid, and you should be, you can also see if the tests actually work by deliberately breaking the code to see if the tests will fail. 3b. Commit. 4. Do the refactoring. Run the tests. If they pass you can commit. 5. Implement the new feature. Write tests for it. 6. Was the refactoring actually good? Perhaps you found a better way to approach the whole thing? If so, throw away the code from point 4 onward. Go back to 3. 7. Go for code-review and merge in the main branch. Of course this doesn't always work. For example, there are features that are just too big to do in one single cycle. For these you can use the Mikado method. Google it. I think it's great. Another great use for refactoring is to help you read and understand legacy code[1]. In this case you don't even need the unit tests. You just change the code the way you think it should be and see what happens. When you're done playing, throw away all changes. You now have a better understanding of how the code works and perhaps why it's written the way it is. If you still think it should be refactored, you should go through the above procedure. -- [1] "Legacy code" is the technical term for code written by somebody else or code that you've written more than 2 weeks ago.
@dimitridoroshko
Жыл бұрын
Write code as if it will be maintained by a maniac who knows where you live
@joelbrighton2819
Жыл бұрын
🤣 Funny but sage advice!
@krccmsitp2884
11 ай бұрын
Here are some guidelines I collected, in no particular order and by no means finished. Feel free to give some constructive criticism. ;-) * Do not produce tech debt in the first place. * Follow the Boyscout Rule (and leave the code you're working on cleaner than you found it). * Refactoring is not a phase or step, it is part of the actual coding. * Identify tech debt and plan its elimination like features or bug fixes. * Make them visible by putting them onto the Backlog and Sprint board together with other items. * Fix the most painful areas first. Apply the 80-20-Rule. * Use tooling wherever and whenever possible to avoid or eliminate tech debt (code analysis, refactoring etc.) * Perfection is the enemy of done. Find effective yet good enough solutions.
@LinhTran-mh9lb
Жыл бұрын
Thank for sharing. That’s what i’m doing for all my projects. Sometimes, i was busy to review member code. That’s a big mistake !!!
@planesrift
Жыл бұрын
Now I feel better with having over 1000 lines for one single React component.
@dimitridoroshko
Жыл бұрын
That's an exception for clean code rule. 1000 lines of code for one component is way too many 😢
@AryanGNU
Жыл бұрын
That's too bad
@AryanGNU
Жыл бұрын
It will come biting you one day
@turolretar
Жыл бұрын
Those are rookie numbers in this racket
@83hjf
Жыл бұрын
I have a component with hundreds of lines in react. It's a table with 20 columnns... the columns have to be defined as children of the table itself. I could extract it to a separate file. I would get zero benefit from doing this...
@jsonkody
Жыл бұрын
I am working on refactoring very very much :) And it's good money spent - I first fast prototype a feature fast, discover ever usecase that we may want and every loophole, then when it works and when there is time I refactor that to nice readable and smaller code - at that process I sometimes see some ways of making it faster, or I pick some minor bugs.
@snowhite1qazse4
11 ай бұрын
well, you can do test first unit testing to make things easier while you refactor. Saves you time on testing. Of course you have to be well verse on unit testing before jumping into it. When we refactor by batch, we strictly requires unit testing automation
@nicejungle
Ай бұрын
Good advice. Refactoring without unit tests is pointless
@gustavoayala7385
11 ай бұрын
I think the advice is so simple that can be oversight how good it is. I can't recommend more the book of MartinFowler 'Refactoring:...' that the current edition is based on JavaScript. The key is not to think in a big complex design or elegant architecture, clean and beautiful. The magic really arise taking small steps, but there have to be automated tests, because when refactoring, and more on spaghetti code, always something can be broken.
@stevesaldivar1569
Жыл бұрын
One of my ex bosses, the one that would do the tech stuff, would always shit on me because he didn’t like code that I would write. The problem was, when he writes code, lets say a web scraper, it literally took him months because he wanted it to look perfect, and I would get the same thing done in a weekend.
@ariyoujahan9662
10 ай бұрын
1:59 I exactly know what you mean. I'm working as a front-end developer in a small R&D team and all those new devices, all new protocols and devices that come along with them... Those are just driving me crazy.
@PieterWigboldus
Жыл бұрын
Best tip me helped to write clean code was TDD. Define what it should do, code don't have to be perfect, and can be optimized, and can have bugs. But you define what it should do in the test, and everybody knows what it should do, and can make it work, or more readable. So if you don't have time to make it work, you know already what it should do, and a new developer can make it work. If you have bugs, add that scenario to the test, and then write the code. Think about data, not about code. So what should be the input and output.
@hardcorecode
11 ай бұрын
Clean code is a natural by-product of good design and vice-versa.
@Charles-sy7ej
Жыл бұрын
I kind of looked at you like a lot of other youtubers that make courses for web development. but I have actually been doing the odin project and they link a lot of your videos. So I think after I finish TOP I think I will go check out some of your courses 😅
@bharatchakrabarthy7571
Жыл бұрын
I was having a dejavu, then I remembered this video was part of your course 🤣. Cheers man
@nikhilfadnis8009
Жыл бұрын
Been there multiple times before. My learning has been it's an effort vs reward tradeoff.
@wouterzonneveld2305
Жыл бұрын
On a sidenote, I think there is a time and a place for a full refactoring. This could be when you want to eliminate a piece of the current tech stack, or when simply so much time is being eaten up by finding bugs and extra time needed to add features that the refactoring pays for itself in a relatively short amount of time.
@navidkarimi5120
Жыл бұрын
You should make a podcast with this kind of information .it will be awesome
@SebastianMineur
Жыл бұрын
Damn, Kyle! Why don't you build a sweet background set in that room at this point? Could really bump the production value of your videos.
@eio4528
Жыл бұрын
I understand the point but this is more of an explanation about a lack of planning and not an argument supporting spaghetti code. I've been the tech lead on a project where other developers consistently left the code they worked on far worse than before. One dev decided to do his own 'rogue' refactoring, ignored precedent, and introduced bugs that have been extremely difficult to replicate. His refactoring turned code that flowed through a pipeline into a set of actions that reach into a black box of globalized state control that is hard to trace the new bugs he introduced. This cost us 3 extra months of fixing these new bugs and we kept pushing the release date. Now, we have paused development and are a week or two into a project to refactor it back towards a 'pipeline'. He rushes through tickets because he's too focused on getting things done within the point estimation of each sprint. This is wrong. If a developer completes 20 points in a sprint, but creates 10 points in bug tickets that trickle in over time, how many points did he complete? I would argue it's NOT 10 and in many cases completed NEGATIVE points. Those 10 points in bug tickets may go to other developers who also create a small bug or can't complete the fix in one ticket, etc. This is why I cannot stand the concept of measuring developer productivity by measuring their points per sprint!
@chrislaforet1064
7 ай бұрын
Interesting story. All I will say (if it helps someone) is to consider that this is legacy code (per Michael Feathers) and refactoring should be done within the scope of the new additions or bug fixes. Most of the time, the problem-areas in code will come up early and often and getting this wrangled and cleaned up will result in life gettting easier in later iterations of fixes/additions.
@sire_ns
Жыл бұрын
One man's refactored code is another man's spaghetti code and vice versa.
@nicejungle
Ай бұрын
Nope A good refactoring follow the DRY principle.
@robin14441
Жыл бұрын
A good starting point for Clean Code in your projects is to use a code linter in your IDE + a code review tool that integrates in your CI/CD pipeline, such as SonarCloud. These won't avoid refactos but they surely will prevent common mistakes or bugs.
@HoD999x
11 ай бұрын
code review tools do not help. if you are a beginner, they will just make you rewrite your code in weird ways. if you are an expert, they hold you back.
@ShiloBuff
Жыл бұрын
I can relate to this so much. Im a oerfectionist and i find myself constantly refactoring and even recreating the projects from scratch. Which is exhausting. I spend countless time trying to perfect the framework and its not productive at all. On the contrary, my boss prefers to just have apps work and keeps it simple. He gets from A to B far faster. I end up with a much more complete project with unnecessary features, tons more code, and a lot more time spent. I recommend people find more of a middleground.
@GrouchierThanThou
Жыл бұрын
That typo in the word perfectionist is just too ironic.
@billmalcolm4291
Жыл бұрын
“T’was hubris that led me here.” I’d like to think I learned a lot by trying to refactor code bases that I had no business trying to refactor, but, yeah, all in all, they were very modest improvements
@unteejo3678
Жыл бұрын
Haha this video came out the moment I finish my one-month refactor.
@theodorealenas3171
Жыл бұрын
This sounds very similar to talks by Robert C. Martin. Do you draw inspiration from him? I don't imply that your stories didn't happen, but the phrasing and the storytelling is almost identical.
@QuanTran-wt4yt
Жыл бұрын
thanks for ur advices! I'm waiting for ur gsap tutorial 🥰🥰🥰
@wa1gon
3 ай бұрын
Massive refactor is almost always a bad idea. Plus one should never attempt to refactor unless one has good set of unit/intergration test. As you said at the last: Leave the code a little better than you found it. I also use refactor as a way to understand code. If I come across a method/function that is like 100 lines or so long then that cause brain overload. I will start refactor the code into methods and name them well.
@sonictailsandsally
Жыл бұрын
“Refactor small bits at a time” - That’s exactly what I’ve been saying.
@captainlennyjapan27
Жыл бұрын
Hey Kyle, I want to thank you for helping me to land a job :) Your video on React really helped me a lot to land an internship which led me to get full time jobs.
@sukhpalsandhu6341
11 ай бұрын
Completely agree. Only refactor if you need to modify the code that was originally written. As long as the original code works, leave it. Pretty sure that Uncle Bob agrees.
@arminmatthes
Жыл бұрын
I've had a similar experience with an overhaul / rewrite where I planned on completely overhauling the entire app but only ever got to do the frontend because I switched teams. It sucks and the backend is to this day still a huge mess that now because of my overhaul is only usable with the new frontend through a hacky git submodules setup and lots of symlinks... On a more positive note, the ld frontend code was such an utter mess that we're still better off with the new version using workarounds to connect the backend than we ever were with the old frontend.
@dagryl
Жыл бұрын
I spent last week refactoring my side project that is not even published yet. :)
@erwerwer2761
11 ай бұрын
Refactoring a project is a big problem, more complex than it might seem at first glance. In most cases it can't be solved in one step. This problem accumulating within long time and solve it too takes time. Do refactor step by step. Think about bad code base like excess weight. To solve problem this first step is stop eat sugar! If you done it, that's good. Next step is fitness fifteen minuts per a day.
@aaronfisk3764
11 ай бұрын
I think the correct title for this video is: All or nothing refactors are stupid, I learned the hard way
@lovalmidas
11 ай бұрын
There is usually a reason why spaghetti and 'unclean' code gets written, and while it is sometimes due to inexperience from the code, most often it is not. Spaghetti code is mostly a sign of mismatched design and poor understanding of the overall view features and requirements. Most of the resulting code look like band-aids and patches because of either an apparent difficulty to change more stuff than originally 'scoped', or a reluctance to break a design and go through a state of non-working code until you glue back the things you took apart. I found out that the me who just wrote spaghetti code (and knowing what I just did) is not well-equipped enough to be able to refactor the same code well. And when I tried, often I get stuck in refactor hell, creating new bugs, clashing against language features and dependent libraries, or coming to a roadblock in the design itself - resulting in a reversion of said refactoring process to previous build. Instead I found it to work best when me from six months later come back to review code from me six months ago. That is usually when I had enough of a breather to look through the design again, and when I learnt more about either the product, design patterns or even language features that I have in mind to be a good idea to use. This might be a good time to make worthwhile refactors over the things I need to change. Also, the 'spaghetti' code (which isn't really spaghetti by the time it passed review or made it to main branch) I wrote over the past six months served well as a decent visual to limit the scope of refactoring that I should do, so I don't have to hammer away the pieces I don't need to. A fairly good first step to pre-refactor is modularizing code - identifying common patterns in written code that can be split out to a specialized function. If the code appears only once, it is a decent signal to leave it alone. It probably does help that they were my personal projects. I got to control my development schedule, so I don't do refactoring in parallel branches with adding new code. If a refactor takes out more than a week, or more than 50% of the total code, that is not a 'refactor', that is a re-write, which is likely a signal to stop work anyway.
@nicejungle
Ай бұрын
After 25+ years of professional coding : 1. Clean code has only one reason to exist : could this code evolve and is it testable ? All other criterions (readability...) are bonus but not mandatory 2. Clean API for classes and clean hierarchy for model objects. The inside of classes could be messy, it does not really matter since it's easy to refactor class after class 3. It's ok to have a messy code if it's because of optimizations (speed, memory load...) 4. Clean code is important for certains part (the business objects for example). Controllers and templates could be messy or copy-pasted it's not really important since it's constantly evolving and changing (generally, it's faster to delete and start over a new design for example)
@PatrikRasch
Жыл бұрын
Have you been watching AthleanX because this title is spot on lmao
@DONGNebab
Жыл бұрын
I hope that in the future, you could provide tutorials for Ruby and Ruby on Rails.
@eNtrozx
Жыл бұрын
Not too long ago I did a really big refactor, but I regularly merged and deployed the new code.
@ericmp1199
Жыл бұрын
A really great video. I felt identified in literally everything u said haha
@vothaison
Жыл бұрын
The idea is very cool and philosophical, applicable to not just programming. You wanna, say, fix your life, well, fix one bit a time. Make it 80% perfect.
@adamos.webdev
11 ай бұрын
Thanks for the information 👍
@SirWolf2018
Жыл бұрын
Clean code isn't inherently a bad thing, unlike the video title suggests (which I hate so much). This phenomenon (of rewriting software not leading to success) is a known problem, already told by Robert. C. Martin in his Clean Coders video series. Indeed the solution is to prevent spaghetti code from the start, so that the code base remains maintainable and extendable over time, which is what clean code is about.
@nightside8709
Жыл бұрын
The Athlean-x of programming
@alejandro.rodarte
Жыл бұрын
Using else is killing my gains man.
@rayanuki
Жыл бұрын
Ooooh so I'll use the word "refactoring" now. I prefer the word "overhaul" and that freaks them out so bad!
@malcolmanderson6735
Жыл бұрын
What were you doing? Add some automated tests, break some dependencies, test and publish your code. Hours, maybe days per refactoring. Each step as more atomic tests, maybe an integration test or 6. If it's more than 20 hours of work you were buying of too much at a time.
@avinashrai8854
Жыл бұрын
We're going through one such project of a client which came in as super mess already
@xandorneun3723
11 ай бұрын
The story you describe is about rewriting big chuncks of an application not about a refactoring. refactorings are very small changes to a codebase, we talk seconds and minutes, they should never need their own long living branch nor should they be incompatible with new features
@Rayzan1000
10 ай бұрын
This is a clear example of acting without thinking. If your refactoring is introducing 10+ new bugs, then you are doing it wrong. Sure people make mistakes and sometimes you overlook a crucial detail, but the simple truth is that if your refactoring is introducing many new bugs, then you are doing it wrong. Besides from not refactoring everything at once, also consider why are you refactoring? What is the benefit from your refactoring? Can something be simplified? Can it significantly reduce the amount of resources spent? Or are you just rewriting it in your own preferred format? Think before you act. Don't just spit out line after line without thinking things through. Why are you using this if-statement? What happens when this is not satisfied? Is this for-loop really necessary? Could this be null/undefined? Think and do it properly the first time, and you won't have to come back to it again and again. It takes too long? It will take you longer to fix those 10+ bugs that you are about to introduce because you didn't think things through and do it properly the first time...
@rabiulazadtapu1485
Жыл бұрын
When can we expect the Next.js course, Kyle?
@benb6744
11 ай бұрын
The refactoring you talk about is actually a whole rewriting. Almost impossible to catch all the requirements and cases that were added over time to that old spaghetti project. Refactoring should be done - as you also said later - in small steps. Hopefully the requirements were once sufficiently fixed by tests, so you do not break anything when changing stuff. I wonder how you can do a whole video on refatoring without ever bringing up tests.
@mycharlottebaby
Жыл бұрын
Absolutely right: There is no perfect code. Really appreciate your valuable experience sharing!
@basnal_prakash
Жыл бұрын
Thanks for sharing knowledge,Love from India 🇮🇳🇮🇳🇮🇳🇮🇳
@web3made
10 ай бұрын
speed is senior to quality, and quality can always be applied later.
@TutorialTechie
Жыл бұрын
My friend loves writing spaghetti code but I can't stand a chance with his code. I would refactor the entire code he written he hates me for this reason😊🤣🤣
@seriouce4832
11 ай бұрын
Thanks for sharing! I am really unhappy with your take though: sure, going for that big refactor was not helping the product or your mood as it never was finished and you were doing two projects in parallel. However I am sure that you learned so much as a developer. Really going in hardcore and seeing the goal line move away etc.. I think every dev should do this once to grow, not to get things done.
@checoperez1264
Жыл бұрын
There's always discussion around "refactoring" and it has actually gotten a bad name, for the reasons explained in the video. From a business perspective refactoring is a synonym to wasting money on making something do exactly the same thing. People have to know that there's software you have, and software you want. Work with the software you have and improve it. Don't call it refactoring, speak with your stakeholders and talk about time to market and efficiency of the developer. How can you make things more scalable by using components or have a shared (internal) library that also cleans up the code in a way. TLDR, don't call it refactoring, describe the desired impact on any KPI (efficiency is one of them) and call it an improvement.
@paololucchesi2827
Жыл бұрын
As a software engineer, the method I use is simple: I refactor my code immediately after writing it. I consider refactoring as a part of implementing a new feature, and if the code I'm working on is not clean, my work is not finished.
@cx24venezuela
Жыл бұрын
Try to keep track on what code you use more, there is where you should put more enfort
@theta2170
Жыл бұрын
My attitude is: do your job and go home. If a requirement arises that needs code to be refactored, or stuff to be removed, then do it. Else allow it. One day you'll leave anyway and it won't be your problem. The people above you have no idea how that system works, just that it has the features they expect. This is especially true of agency work where directors just want clients to be happy. Refactoring time is something you'll maybe find more of inside a product team.
@laneW612
Жыл бұрын
thank you for sharing your knowledge!
@daydreameravani
Жыл бұрын
Code that looks clean is sometimes very difficult to understand, as they are usually highly abstract.
@F3GR-cx9bh
Жыл бұрын
I think it means the code was overabstracted, which is actually worse because you don't know in advance whether or not they ever gonna get appropriate to begin with and in the latter case its much harder to refactor since the excessive abstractions have already made negative impact on maintainability and readability, you should always abstract things once they start to scale, not before (though you definitely could write up (prototype) stuff in spare time in case they might get useful).
@turolretar
Жыл бұрын
can’t we just call it organized instead of clean, I’ve seen the word “clean” wildly misinterpreted
@theodorealenas3171
Жыл бұрын
Keeping code clean is an art. I gave it all in and it feels like trying a high level drawing thing with low drawing skills. I like comparing everything to drawing. I kinda miss drawing.
@Kiev-in-3-days
Жыл бұрын
If it's overly abstract it is not clean. Clean means be very easy to understand buddy.
@walkingin6375
11 ай бұрын
It's a 9 minute video, but I spent 20 minutes trying to figure out how Kyle has that black guitar standing upright there...
@hardwired89
Жыл бұрын
thank you for sharing
@lpandp90
Жыл бұрын
Incrementally working!!!
@HelloKittyFanMan
11 ай бұрын
Do you even know if they started to take your refactored work seriously by using it instead? And why did you quit from there before seeing the results of your refactored work?
@drrodopszin
11 ай бұрын
Clean code imperialist here: your code should not just be readable by humans, but consumable by your IDE. Nothing sets me into more of a code rage when I have to deal with code the just doesn't work with an IDE, where I need to read through every line of code because some smarty-pants did some magic, miracle code, like adding wonder properties during runtime to a function that can be technically also an object but nothing expects it to be like that.
@tranminhtri9963
Жыл бұрын
why didn't you do more videos about Ruby on Rails tutorials?
@drewbird87
Жыл бұрын
I sometimes have the problem where I refactor as I go *maybe* too often. Like, am I just re-plating the same spaghetti?
@CounterDayHay
Жыл бұрын
lmao re-plating the same spaghetti with a cooler plate goes crazy
@arthurprado7527
11 ай бұрын
Uncle bob, kent beck and martin fowler disagree. Now u can choose between 3 monsters os software development or this guy.
@Gvue003
Жыл бұрын
Company requirements into hiring: “Write clean code”
@mecozir
Жыл бұрын
partial scenario set height binary
@vincentdesjardins1354
Жыл бұрын
That was very good and usefull advices. Thanks
@alexandrtcacenco8129
Жыл бұрын
I do refactoring with every new issue I solve. Devs appreciate it and start using my new base classes and services, but team and department leaders are on my neck all the time.
Пікірлер: 466