3 ms·
It really depends on the organisation. This sounds sensible, pro-active and productive until to work on legacy systems that have been in place probably or organ
by forest_dweller 6y ago
It really depends on the organisation. This sounds sensible, pro-active and productive until to work on legacy systems that have been in place probably or organisations that don't value any of these activities (you typically don't want to stay there but sometimes you just gotta put up with a role until you get a chance to move on).
Generally in this scenario your job is to make a change that fulfils the requirements, verify that it works and test it manually, pass it onto QA and move on. Businesses often don't care your improvements unless it is a new feature and it will make you look bad because it will take you longer to complete a task than they deem necessary.
As for refactoring in this situation. Don't. Even making seemly simple changes can it makes it difficult for others to code review it, or could incur breakage (yes there are some systems that are this fragile).