How to accept the fact that you can not remove the bad code to the project?
Not so long ago began to work on the project (Beck + front). Faced with low-quality code, which is repeatedly superimposed. If Beck somehow can fix what I don't like, add documentation, then at the front is extremely a lot of GTA V on garage door, nothing documented, and reusable code business as usual. Because of this, the file bloated up to several thousand lines. To correct anything it is impossible, as it works, what to do?
Well, since you sir, to take and to fix. Ah, you are sir? Well then don't try to be clever.
Prestiti for being rude. Works - don't touch.
carli_Parisian answered on March 23rd 20 at 19:25
To score and get the cash
Juliana_Ritchie69 answered on March 23rd 20 at 19:27
To accept. Refactoring is rarely included in the roadmap of projects in organizations and the reasons for this are several:
- works don't touch (don't wanna break it to repair will)
- why pay for the same result (hardly anyone except the developers understand why they need refactoring)
If accept fails:
- make an assessment of the changes
- make a list of pros and risks of this event
- put this decision-making people in the organization
If everything is done correctly and expenditure is commensurate to business, but the advantages are enough that the idea of support. If not then see 1.
lamont21 answered on March 23rd 20 at 19:29
To make a presentation to the business leadership, to draw in the beginning a big scary problem, and graphs of growth of cost of support and service, drop conversion and so on. Next slides listing the benefits of refactoring. For example - the introduction of new features will reduce time and cost on the X-and Y-changes to existing features - on 5X and 5Y. The cost of support and development of the project will go down in X times, the cost of testing will decrease to Y. the Load and the server costs will fall by X, the speed of loading pages will increase by Y, the indices Bounce Rate will decrease to Z, the conversion rate will increase by at least X and so and so. Well, if the presentation along with the business will see marketing - for them these things are important, too. The business understands the actual bad code as a philosophical concept - does not understand.
And most importantly - the presentation should contain a concrete proposal. Something like "on the refactoring will need a Min-Max hours, but not to stop the work we're doing in parallel on the 3rd priority after bug/sekyuriti critical fixes and new features, highlighting it X hours a week."
Decision makers must understand that business will eventually be profitable and the current task is not appreciably affected.
PS: of course this is all slightly exaggerated for clarity, but the essence I think is clear.
deon_Dietrich93 answered on March 23rd 20 at 19:31
nelson_Kuph answered on March 23rd 20 at 19:33
Often and much to demonstrate to frontenders neglect, on the occasion to make condescending statements like "Oh, Well, someday you will become real programmers" and "Yes, I understand, not everyone". All the objections to genuinely wonder and ask "why are you offended, you have the same motley logs and bad code mixed up with spaghetti code." Not the fact that will help, but at least fun. The main thing is not to go too far with criticism, it should looks genuinely friendly.
ellis44 answered on March 23rd 20 at 19:35
The correct answer is a combination of the data above already answers (to Score and get the cash || to Quit)
Viviane.Bergnaum74 answered on March 23rd 20 at 19:37
Read the book "effective operation with the legacy code" and think about how to achieve the confidence that you won't break anything when refactoring.
If you don't have something from what is below to try to implement it:
- automated tests
- continuous integration
- code review or pair programming
- automatic refactoring
- static validation (typescript, for example)
To begin to analyze the statistics on causes of error - often it is bad code.
In the calculation of time for revision note at that time which occurs due to bad code and on the time that is necessary to be able to test the changes manually.
Try to convince management to implement automated testing, based on the facts above. Introduce it gradually, first for new code that's easy to test. When it will get used to the tools and start writing good tests, you can cover the old code before the changes.