Refactoring Principles - Warm-Up Questions

Mark each statement below as true or false. After the session, come back to this quiz and change any answers you feel are incorrect and add detail to your answers.

		True	False
1	Refactoring work should be planned and prioritized alongside user stories for the sprint.
2	When someone is refactoring the code may be broken for a few days while they do it.
3	Code reviews generate refactoring tasks in the backlog.
4	If you encounter ugly code it is your moral duty to refactor it.
5	The team lead does most of the refactoring, others should only refactor when they are told to.
6	Large changes, for example switching cloud provider, can be done through a sequence of small refactoring steps.
7	If you see duplication in the code you should use refactoring to remove it.
8	If you don’t understand the code you shouldn’t refactor it.
9	You should refactor in a code branch and have QA test it to confirm you haven’t broken anything before merging to master.
10	If you encounter ugly code that you don’t need to change to get your task done, then you don’t need to refactor it.
11	You should get permission from your manager before refactoring.
12	When we invest time in refactoring it saves us time overall.
13	It’s not possible to refactor the database if you use an Object Relational Mapper (ORM).
14	A good time to refactor is before you add a new feature to make adding it easier.
15	Refactoring can impact performance so you should profile your code after refactoring.
16	The purpose of refactoring is to make you write code faster.
17	You can’t refactor a library or published API.
18	You should refactor well-designed code not just ugly code.
19	Refactoring is a way of paying off technical debt.
20	You can only refactor if you have test coverage over 80%.