|
|
|
|
|
|
by MattyRad
2383 days ago
|
|
|
This is an excellent suggestion. I think an important question to ask before getting review is can other people understand and manipulate my code as easily as I can? Engineers who submit PRs without critiquing their own work (usually the moment they complete the ticket/task) are a liability, and can introduce some uncomfortable situations when it falls on peers to approve/criticize. Speaking from experience, my boss was very terse in code review sometimes, but it was the kick in the pants I needed to understand that my buggy, brittle code was unacceptable. If you're looking for good resources, Clean Code by Bob Martin is a classic. |
|
|
Uncle Bob also has a video series that provides a good introduction to a bunch of design issues in an understandable format (but it's not cheap at $14/video): https://cleancoders.com/ . I've seen these videos transform the way teams code.
My other suggestion is to start paying attention to how your code "feels". If something is painful/boring/fiddly it's often the case that the design isn't a good fit for what you're trying to do. TDD is excellent for this because it will move the pain front and center where you can't ignore it.
Clean code and other resources will give you tools to use when the design isn't a good fit (I could use this technique here etc...), but recognizing when you need to step back and change the design will be up to you.