Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Refactoring in Java

You're reading from   Refactoring in Java Improving code design and maintainability for Java developers

Arrow left icon
Product type Paperback
Published in Dec 2023
Publisher Packt
ISBN-13 9781805126638
Length 292 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Stefano Violetta Stefano Violetta
Author Profile Icon Stefano Violetta
Stefano Violetta
Arrow right icon
View More author details
Toc

Table of Contents (15) Chapters Close

Preface 1. Part 1: Introduction to Refactoring
2. Chapter 1: What is Refactoring? 3. Chapter 2: Good Coding Habits 4. Part 2: Essence of Refactoring and Good Code
5. Chapter 3: Code Smells 6. Chapter 4: Testing 7. Chapter 5: Refactoring Techniques 8. Chapter 6: Metaprogramming 9. Chapter 7: Static and Dynamic Analysis 10. Part 3: Further Learning FREE CHAPTER
11. Chapter 8: Crafting Quality Every Day 12. Chapter 9: Beyond Code – Mastering Software Architecture 13. Index 14. Other Books You May Enjoy

Code reviews

Code reviews, often also called peer reviews, are a very powerful tool for developers’ daily work. We could almost say that they are fundamental, but the truth is that under certain conditions, it is possible to choose whether to perform them or not, provided, however, that if not, other methodologies are implemented. But let’s go in order and try to understand what a code review is.

A code review can be implemented in slightly different forms, but it typically consists of submitting a piece of code to one or more developers who did not write that code; these people are usually referred to as “reviewers.” So, for example, if you own a certain task and you developed the relative code, before deploying it in production (or usually even before merging your feature branch on your main branch, depending on your “framework”), your code is reviewed by some other teammate who did not write a single line of that code. The aim is not...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image