Geek Answers Handbook

Tracking refactoring in the error database

Suppose you work somewhere where every change in the source code must be associated with an error message or request function, and there is no way to change this policy. In such an environment, is it best to work with code refactoring (i.e., Changes that improve the code, but do not fix the error or add a function)?

  • Write a bug report and match the refactoring with it.
  • Record a function request and associate refactoring with it.
  • In the process of refactoring when working with code associated with an error-message / request function, go to refactoring.
  • Just do not refactor.
  • Other

Please note that all error reports and feature descriptions will be visible to managers and customers.

+5
source share
5 answers

I vote for the "sneak in refactoring" approach, which, in my opinion, should be done first and foremost. This is probably a bad idea for refactoring just for the sake of "clearing the code." This means that you are making changes without any real reason. Refactoring, by definition, modifies without the intention of fixing bugs or adding features. If you follow the KISS principle, any new function will require at least some refactoring, because you are not really thinking about how to make the most extensible system possible for the first time.

+7
source

How we work: There must be a good reason for the reorganization of the code, otherwise why?

, , .

- , "xyz" - , .

, .

, . , / , .

+2

, , , , , , , , . .

+2

:

  • .

, , , . , , .

  • .

. , ...

  • , -/-, .

, , x , .

  • .

, -, , . , , .

, , , . , , , .

0

( ) , !

0

More articles:


All Articles