How to avoid the "easier to rewrite" problem?

Question

Project management

I plan to order a web application, the project will develop, perhaps the programmer will change, because. in my experience, over time, some people get bored with one project. In general, I am afraid of a problem when, when changing a programmer, it is “easier to rewrite” for a new one. If you do it on the Yii framework, can you not be afraid of changing the programmer? Or do you still need to maintain it on GitHub? I don’t want to deal with GitHub yet, is it possible to upload the project there later?
In general, I have already ordered freelance programs more than once, but there has always been this problem, the problem of versions, etc. I would like to organize everything correctly when starting a new project.

Answer 1

> In general, I'm afraid of a problem when, when changing a programmer, it's "easier to rewrite" a new one.
This means that a person simply does not know how to work with legacy code. This does not mean that the code should actually be rewritten. It is certainly possible to arrange the architecture in such a way as to isolate questionable old code and replace it slowly with new one.
The problem with (some) programmers is that they look from the point of view of "how to write the perfect code in my opinion", and not "how to get the maximum profit with the minimum cost."
Code rewriting is a loss of money with an unknown result, where is the guarantee that the third, fourth, etc. programmers will not want to rewrite again? I advise you to avoid this.
On a good note, you would need to consult with an experienced developer about some important architectural decisions (so that he immediately points out to you a rake that you may stumble upon), and you also need to establish certain requirements, for example, that the programmer comments on the code and documents the accepted solutions. So that all the necessary files are added to the repository, so that the project can always be transferred to someone else.
> If you do it on the Yii framework, you can not be afraid of changing the programmer?
It's up to the programmer, Yii doesn't forbid crooked code, although learning the framework straightens the programmer's brain a bit (and increases your chances of getting something that works).

Answer 2

There is only one way - to hire the right people.

Answer 3

>If you do it on the Yii framework, you can not be afraid of changing the programmer?
Using a framework doesn't mean you don't have bad code. In this case, Yii will force you to adhere to certain rules, which is good, but there are people who can pervert the functionality of the framework so much that it becomes scary. A lot depends on the level of the programmer. If he competently uses the capabilities of Yii and OOP, then there will be no special problems to delve into the project.
> Or do you still need to maintain it on GitHub?
Not prevent. For example, on github or bitbucket.

Answer 4

Yii is a good choice, as long as the programmer sticks to the generally accepted rules, there will be no problems. For serious projects, the use of version control systems is more of a necessity than a wish, so do not be lazy to understand before making a choice.

Answer 5

My humble opinion is that the only way to avoid this situation is to cover the code with tests.
And so, the idea of ​​​​doing everything on a version control system is very correct, but you need to do it right away, because then there will be a lot of excuses. And the same bitbucket allows you to make free private repositories.

Answer 6

In some cases, it’s still “easier to rewrite”.
The problem lies not in the choice of means, but in the approaches to writing code. If you write the code according to the principle “a little bit here, a little bit there”, then naturally after a while even understandable code will turn into shit code. If the code is clearly divided into separate functions or classes with adequate comments, then problems usually do not appear.

Answer 7

If the budget allows, sometimes they start a quality control and testing department. If you have no chance, then I will support egorinsk

Answer 8

It seems to me that for each point of the final capabilities of the application, a modular system should be implemented. Then all changes will be made relatively easily.
And why exactly yii?

Answer 9

A very ambiguous question that cannot be answered easily.
If this product is so important to you, try to keep the attention of at least one developer on the project. I figured out the following option in my head: when I need to attract a new programmer to the project, pay the old programmer for the time that it will take to transfer secret knowledge on the project to this new programmer - and I will say that I only remember about the technical details of a recently completed project, even after 3 months in outline. Find a way to keep the old programmer's attention on the project, but not full time - let him do what he is interested in most of the time. Or like this: share your business with him and perhaps he himself will want fewer mistakes that reduce income, which means he will be engaged in the project and will not forget it.
Never hire one developer. Let them work in a group. This would theoretically lead to the fact that the code will be written so that someone else understands it. It’s not a fact that the code will be smooth and beautiful, but if two or three people understand it, then the fourth one will figure it out.
How to suppress the desire to "alter everything"? Never accept work in an "almost done" state. Do you have a technical task? If not, order technical writers - let them draw up the TOR before the programmers start working. And at the end of the work, check all the points of the TK for reality. Check it on a test server, on a production server. Check several times to make sure that something doesn't break on its own after a month. Order specially testers who will be able to check the project for compliance with the TOR. Then the first rule of programmers will work - "it works - do not touch it." The new one will think three times before breaking something.
Or maybe in a year it will really be necessary to redo everything. Let the new one figure it out. Will conduct a code review and find uncorrectable security vulnerabilities, prove poor performance. Let him arrange a usability test, justify the redesign and change in the functionality of the site. Let them arrange A / B testing and help increase conversions and sales.
Something like that. Brad, of course, but from the heart.