@Maroko1218
I've recently graduated from university and landed my first ever programming job. I really appreciate and enjoy your videos! They make me feel motivated to keep improving how I write code. Looking forward to the next one :)
@laugri
Great advice !
@researchandbuild1751
I just started some refactoring of some webcam communication code in our product. First thing i started to do was remove things that were no longer being used, because it made is so much more confusing to understand the whole. You would see these classes and think ok how is that used .. And it actually wasn't. Good to know that my instincts to remove it were right lol
@Monkman99
Dude you look just like Christopher Lee! Have you heard that before? Enjoying the videos btw, thanks Count Dooku
@JeffreyToddGrigg
I'd say, ... 1. Refactor the code you're already working on, due to feature requests. This leverages the investment you already have to make to understand the code, and to test it after your changes. It avoids the "blame game" of "Refactoring broke the system! No more refactoring allowed!" 2. Start small. Work up. Like start with (a) adding, removing, and updating comments. (That includes deleting commented-out code.) (b) Rename local variables. (c) Move variable declaration close to usage, and (d) combine declaration with initialization. (e) more in-method refactorings. (f) in-class multi-method refactorings. (g) multi-class refactorings. (h) Improve the design [of the code you're changing due to feature requests]. And the above is not a strict ordering. While it provides a general direction from simple and low risk up to larger impact and value, feel free to do "later" steps earlier if needed, or if the value is clear.
@SiisKolkytEuroo
This is the most OOP brained thing I've seen in a while
@stephenpaul7499
I like your vibe and look forward to exploring the rest of your channel :) In my experience, creating more methods hasn't worked out favorably. I want to know exactly what the code is doing as easily as possible. I can't count how many times I've been burned by a poorly named method or other abstraction (even one that I wrote yesterday!). My solution is to try to keep the number of abstractions in my code to a minimum and that means reducing methods/classes. In my opinion, abstractions are, by definition, over-simplifications of reality and are therefore to be used sparingly. Often, I will write fairly large functions and break up the body into blocks of code (almost like paragraphs) and use a comment to describe each block of code. I share many, but not all, of the opinions expressed in https://www.youtube.com/watch?v=QM1iUe6IofM. I'd be curious to hear your objections.
@nickbarton3191