Why can't a prototype be turned into a final program?
Hello! How many articles have already been about govnokod, but I think their flow can not be reduced, because the flow of govnokod only increases.
Warning: the article is full of subjectivism and surrealism. The author does not claim to the ultimate truth.
Very often, creating a new application, program, website, we first experiment, and then create from our experiments the final product.
But give the answer to the following questions without thinking:
My answers: constantly, quite often.
Why it happens?
The main reason for this is that the programmer cannot abandon the prototype of the program, and continues to wrap the functionality on it. You wrote some piece of code, checked it - it does exactly what you need. Next, we implement another feature, fasten it there too, and rushed ...
As a result, we get a plasticine lump on which pieces are stuck on all sides, and it is about to collapse. You amuse yourself with the thought that everything is about to be refactored and lead to a fenshy look. Only you can support this whole business (after all, the documentation to hell is a waste of time). But, they refuse your services, or you quit the company, and you have to transfer everything. Transferring is easier than receiving. But don't be surprised then why your ears are burning all the time.
')
The main problem in the modeling of plasticine lumps is that your hands are then all the time fat. When you sculpt a plasticine program, it becomes increasingly disgusting for you to sculpt it. The further development goes, the more you are fed up with the project.
Prototyping is an excellent programming technique, and it can very successfully be used to develop alpha versions when only application visibility is required. You simply collect in a pile everything that was invented or found. But you can not mindlessly sculpt the rest of the functional to the prototype.
A good practice will be something like this: let your prototype remain a plasticine lump, mold the newest pieces of the program on it. However, in parallel, create a clean project, and include there your improvements, thinking with your head. Use only successful designs so that your plasticine ball in a clean project turns into a steel frame.
Yes, yes, I know that this is not always possible. Often it is a pity to time, or it is not clear how to include this or that piece in the project in a clean way. But please, feel sorry for other programmers, because it is your code that I may be disassembling now.
Think more, do not do it, do not repeat in code (DRY), do not complicate (KISS), but do not oversimplify too much. Maybe then your conscience will be clear and calm during the transfer of projects, and the refinement and support of your applications will be a little more pleasant.
Warning: the article is full of subjectivism and surrealism. The author does not claim to the ultimate truth.
Very often, creating a new application, program, website, we first experiment, and then create from our experiments the final product.
But give the answer to the following questions without thinking:
- How many times, when you received source codes from other developers, did you find them extremely unattractive?
- How many times did you feel ashamed of sharing your source code with your code?
My answers: constantly, quite often.
Why it happens?
The main reason for this is that the programmer cannot abandon the prototype of the program, and continues to wrap the functionality on it. You wrote some piece of code, checked it - it does exactly what you need. Next, we implement another feature, fasten it there too, and rushed ...
As a result, we get a plasticine lump on which pieces are stuck on all sides, and it is about to collapse. You amuse yourself with the thought that everything is about to be refactored and lead to a fenshy look. Only you can support this whole business (after all, the documentation to hell is a waste of time). But, they refuse your services, or you quit the company, and you have to transfer everything. Transferring is easier than receiving. But don't be surprised then why your ears are burning all the time.
')
The main problem in the modeling of plasticine lumps is that your hands are then all the time fat. When you sculpt a plasticine program, it becomes increasingly disgusting for you to sculpt it. The further development goes, the more you are fed up with the project.
Prototyping is an excellent programming technique, and it can very successfully be used to develop alpha versions when only application visibility is required. You simply collect in a pile everything that was invented or found. But you can not mindlessly sculpt the rest of the functional to the prototype.
A good practice will be something like this: let your prototype remain a plasticine lump, mold the newest pieces of the program on it. However, in parallel, create a clean project, and include there your improvements, thinking with your head. Use only successful designs so that your plasticine ball in a clean project turns into a steel frame.
Yes, yes, I know that this is not always possible. Often it is a pity to time, or it is not clear how to include this or that piece in the project in a clean way. But please, feel sorry for other programmers, because it is your code that I may be disassembling now.
Think more, do not do it, do not repeat in code (DRY), do not complicate (KISS), but do not oversimplify too much. Maybe then your conscience will be clear and calm during the transfer of projects, and the refinement and support of your applications will be a little more pleasant.
Source: https://habr.com/ru/post/155019/
All Articles