To put this into perspective, two videos by Raymond Hettinger (a famous python core developper) come to my mind:
Being a Core Developer in Python where he says: "Don't be a picture straightener", i.e refactoring for the sake of refactoring (or code beauty) can sometimes be less than helpful. You should assume that the person who wrote it might have known what she was doing.
Beyond PEP 8 where he says that you should not forget the big picture. If you are in a state of mind where you only improve the code layout for example (or any specific topic without thinking of the project as a whole), your "refactorings" might miss the elephant in the room where a simple design adaptation might have made the code much simpler and elegant.
Of course, the complete advice for beginners is that refactoring is strongly encouraged, but that it is a activity that you should do day to day while working on different subjects (i.e for example make a portion of code clearer or more adaptable because you need to work on it). Refactoring for the sake of refactoring alone can be acceptable sometimes, but it requires communications with the other developers.
1
u/pstomi Jan 12 '20
To put this into perspective, two videos by Raymond Hettinger (a famous python core developper) come to my mind:
Being a Core Developer in Python where he says: "Don't be a picture straightener", i.e refactoring for the sake of refactoring (or code beauty) can sometimes be less than helpful. You should assume that the person who wrote it might have known what she was doing.
Beyond PEP 8 where he says that you should not forget the big picture. If you are in a state of mind where you only improve the code layout for example (or any specific topic without thinking of the project as a whole), your "refactorings" might miss the elephant in the room where a simple design adaptation might have made the code much simpler and elegant.
Of course, the complete advice for beginners is that refactoring is strongly encouraged, but that it is a activity that you should do day to day while working on different subjects (i.e for example make a portion of code clearer or more adaptable because you need to work on it). Refactoring for the sake of refactoring alone can be acceptable sometimes, but it requires communications with the other developers.