Reddit reviews Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))
We found 9 Reddit comments about Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler)). Here are the top ones, ranked by their Reddit score.
You need to build up a foundational set of programming skills. Frameworks and libraries are important to know, but not as important as knowing how to program. The difference between a program/website/webapp that works, and a program/website/webapp that works AND has sensible code, is significant to a company. I've seen the simplest of features take weeks to implement in very poorly written code bases. This is valuable and expensive time that could have been spent building other features.
Companies are sensitive to this because very few companies are immune to the effects of poorly written and maintained code bases, so they are going to ask you code design questions and even have you do live programming challenges to see how think about the problem, and whether the design of a solution is important to you, or whether you're content to just shit out any old solution that works and move on.
To start, with, I would familiarize yourself with the basic mechanics of the language by reading the You Don't Know JS series: https://github.com/getify/You-Dont-Know-JS/tree/1st-ed
Next, I would read Clean Code by Robert Martin. It's based in Java, but the general principles are the same.
Next, I would read Refractoring: Improving the Design of Existing Code (2nd edition - which is JavaScript based). You can read the Java-based 1st edition for free.
Finally, I would read A Mostly Adequate Guide to Functional Programming.
Yes, it's a lot of reading, but these books will help you think about your code design choices, and in combination with practice, will help you write better code. But of course there is no substitute for practice. The more you write code, the better you'll be at it. The resources I linked to are just guides, not magic bullets.
In terms of other things that are necessary to learn, you'll need to learn how to use git (not to be confused with GitHub). Git is basically the industry standard version control system. You don't have to be an expert at it, but you do need to know the basics of it.
You're also going to want to get familiar with the basics of node and npm, because even doing front-end work, you'll be relying on 3rd party packages, and running builds, all of which are managed through node and npm (or yarn).
These are great suggestions. The three books I typically give devs early (that fit in well with the two presented here) are:
Refactoring by Martin Fowler
This is a list of patterns of common refactoring a and how to do them safely. It’ll help you recognize transforms you need to make in your code as it changes.
The Pragmatic Programmer by Dave Thomas and Andy Hunt
This is a great guidebook for how to get better at being a software engineer. Essential read.
And while there are lots of options for design patterns books...
Head First Design Patterns was the one that helped me internalize them. Even if you aren’t writing much (or any) Java, the method of teaching is hugely valuable.
>I just started a job with a lot of legacy code.
Good news! The 2nd edition of Refactoring has been released (almost a year ago), this time using JavaScript instead of Java!
Some of these are directly related to programming and some are not but are additional reading that touch on skills that most every programmer should have some concept or idea of.
I've read all of these at some point throughout my career and can attest to their usefulness. Here's my personal list:
Focus on other aspects. Reading and being able to talk architecture has gotten me a lot further than the “cracking the code”, leetCode type of stuff.
(None of these are affiliate links)
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420
https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599
https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X
The Stanford Algorithm book is complete overkill in my opinion do NOT read that book. That's insane. Read it when you've been doing programming for a while and have a grasp of how it even applies.
Here's my list, it's a "wanna be a decent junior" list:
​
Reasoning: So, the first book is to give you a sense of all that's out there. It's short and sweet and primes you for what's ahead. It helps you understand most of the basic industry buzz words and whatnot. It answers a lot of unknown unknowns for a newbie.
Next is just a list languages off the top of my head. But you can pick anything, seriously it's not a big deal. I did put Java first because that's the most popular and you'll like find a mountain of resources.
Then after some focused practice, I suggest grabbing some SQL. You don't need to be an expert but you gotta know about DBs to some degree.
Then I put an analysis book that's OOP focused. The nifty thing about that book, is it breaks into design patterns nicely with some very simple design patters to introduce you to design patterns and GRASP.
Then I put in a legit Design Patterns book that explains and explores design patterns and principles associated with many of them.
Now that you know how code is structured, you're ready for a conversation about Architecture. Clean architecture is a simple primer on the topic. Nothing too crazy, just preps you for the idea of architecture and dealing with it.
Finally, refactoring is great for working devs. Often your early work will be focused on working with legacy code. Then knowing how to deal with those problems can be helpful.
FINAL NOTE: Read the soft skills books first.
The reason for reading the soft skills books first is it helps develop a mental framework for learning all the stuff.
Good luck! I get this isn't strictly computer science and it's likely focused more toward Software Development. But I hope it helps. If it doesn't. My apologies.
Here's a short list of what I used:
This is all the result of lots of googling and personal experience. I am not in any way affiliated with any of these links and I have paid for everything myself when I bought them.
How I 'invented' my project idea is basically by adopting the strategy to write down every idea I had. So did something annoy me at work? Write it down. Did I need something and it wasn't available or reasonably priced? Write it down. Had a random idea? Write it down. Every few weeks review your list and see if you are still convinced it will work otherwise delete it from the list. Keep this up and you will end up with a lot of deleted ideas, some decent ideas and a few good ideas. Keep expanding on your best ideas and keep reviewing everything. In the end you will have an idea that has survived lots and lots of reviews and has a fighting chance in the real world.
Some things I like about my current project:
Well you you’ve learned your lessons the hard way. You learned some lessons right? Let me guess, rigid and coupled code really hard to change when the customer pulls 180s on you?
Good news! Many a great has done the same before you!
Read these books:
https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599/ref=sr_1_1?crid=BMSFJX83NS1L&keywords=refactoring&qid=1555768426&s=gateway&sprefix=Refacto%2Caps%2C208&sr=8-1
https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/ref=sr_1_2?keywords=Clean+code&qid=1555768503&s=gateway&sr=8-2
Try to make a sketch: What are the dependencies of each function / class / module. How are they interconnected, what is the scope of each dependency (can they be bundled into a module / class on its own?). I usually make such sketches on paper -- old school.
If you have the sketch, you can start unbundling it by trying to minimize the dependencies of each part to one another. Once that is done, you can either refactor or outright reimplement the code. Depending on how big the mess is, a complete reimplementation can be simpler sometimes (albeit more time consuming).
There are also very good books on that issue: