How to grow a program from a prototype
Every week on profile blogs we read how to use the X methodology and the Y framework to write well-designed and easily maintained software. We are constantly told that, they say, govnokod is bad, refactoring is our everything, they give some very important spherical tips in a vacuum. In most of these articles you can find abstract philosophical morals, for example, here I will print and hang them upon entering the office:
But what if I say that not all projects are the same, and some of them are not something that can be, but even need to be carefully grown from a prototype? I told about this at the Unite'12 conference , and now I will tell you.
The idea to write this text has been gathering dust in my head for a very long time. But yesterday’s article “Why it’s not possible to turn a prototype into a final program ” suddenly became a real catalyst. It turns out that I suddenly can’t do what I’ve been doing successfully for two years and am proud of it.
')
While the disgruntled reader did not start quickly scrolling down, to be the first to write a comment and tell me how wrong I am, I want to point out one fact that (for some reason) many ignore - all projects are different! If you make an enterprise application, it does not mean that no one writes embedded systems, apps for smartphones or disposable presentations.
Hence the manifestations of violent holivor in the comments to any such post. So let me first talk about the specifics of the projects that I usually do.
I work in the company Interactive Lab . Basically, we do offline interactive installations, the creation of software for which is very different from the usual software development:
So, I sit in the office, I don’t touch anyone, I read Habr, there, I eat a peach ... And then the boss comes up to me and asks a question that basically comes down to the following: “Valentin Vladimirovich, and how much will it take for you to do such a thing which we have never done and vaguely imagine how to do? .. Mmm, two weeks, right? ” Well, it turns out later that some kind of event in three weeks, the client “doesn’t know exactly what he wants, but he wants it very cool to have it all”, there are no assets, there are some ideas too ...
The principle of iterative development is not new at all, and hundreds of articles are devoted to it, including on Habré. How is it, Agile evangelists say? We take, which means, a feature developer, we look at what we can do for the iteration, say, in two weeks. We do. We look again ...
So, stop! Fichist? We have neither TK, nor a clear idea of ​​what it all should be. Iteration in two weeks? We only have 15 working days, what a fortnight, are you !?
This is how we came up with the following algorithm:
As you see, by iterations of 1-2 days, the prototype grows into the final application. And it works great.
Passing through the eyes of the algorithm, following the cycle a couple of times and leaving it, you can immediately imagine its obvious advantages:
For some reason, most of the articles on prototypes are described as something temporary, nasty, sticky and unpleasant. Like, on a careless prototype, unscrupulous developers cheat more and more new features, turning it into a Frankenstein monster. And the main conclusion - you need to rewrite everything, and happiness will come!
I am sometimes asked a reproachful question: "Are you not ashamed of the code of your application, which turned out to be a gradual upgrade of the prototype?" . I, frankly, feel ashamed of all my code that I wrote more than a month ago. Why? Because over the past month, including while this code was being written, I personally grew up as a developer. And today I would write everything in a completely different way. Well, tomorrow I really would like to rewrite all this to hell! Therefore, every time I smile dirty when I hear offers to take and rewrite everything anew.
Let us think of the prototype as a tree, which by a certain date should blossom and bear fruit. It depends only on us that it will bloom with roses and sugar peaches will grow on it, or it will suddenly become covered with killer flowers, and we, as the perpetrators of this disgrace, will be put to chop them with a sword. At the same time, as in a fairy tale, two new ones grow on the place of a felled one. I think everyone already understood the metaphor.
In general, the convergence of written code to govnokod when the number of lines n> N strongly depends on a particular person. If your programmer sculpts tentacles to the prototype tree, not caring about his future, why do you think that you have rewritten everything anew, will he not end up asymptotically at the end of a similar result?
To do, simply, you need everything right. It is good to imagine that this is not a prototype to eject, but a living organism, which will greatly change from your actions at the germ stage, having grown into its final form. And this form can be STRONGLY different from what you laid in its genotype at the start.
And as your grandmother in her small vegetable garden outside the city pulls grass around sprouts, pruning them, planting some varieties onto others, you should also carefully monitor your prototype as it grows. This is what distinguishes a good programmer from a bad one. A good programmer sees where his code grows, what needs to be done now, so that later he does not have to chop dead branches; Understands how to carefully get rid of the beetles, terrorizing the tree; knows when to fence him so that it grows in the right direction.
If I were given 10 rubles for each article in which KISS or DRY is mentioned, I would have bought a BMW 3 I dream about a long time ago. These buzzwords have already tucked into the belt a terrible OOP, on which The Gang of Four are sitting and whipping it with design patterns (that's another picture, of course).
All that matters is whether a person can grow a healthy tree from a prototype.
Specifically, in our realities, everything, moreover, needs to be done very quickly. Iterations a day or two, no more. So you start to fight with the unauthorized interpretations of KISS, DRY and all sorts of OOPs of the brain. What, honestly, does not always work.
It's like, sorry, with the ROC . Experienced priests, theologians and historians of religion, I suppose, know why this particular ceremony is such, although it looks very strange from the outside. But ask any of the 97% of other believers - you will receive the answer, they say, do as they said and you will be saved. And well, if not beaten.
And KISS, and DRY, OOP ... what else is there? Design all. All these are good concepts, but it takes a shiver when you see how they are applied in life. And you understand that such an application with the cultivation of a prototype is compatible a little less than nothing. Hence the terrible lame trees with cannibal flowers.
Especially when a person is thrown into extreme situations. If OOP, then it is necessary to have 100,500 abstract classes and an interface for each, moreover, in order to create something concrete, you need to do it through a special factory of factories of builders. But the sheer DRY. Everything is mega abstract and no code is repeated. And no one bothers that in order to achieve all this, it took you to write 20 times more code. But also IoC with DI should be fixed so that absolutely no one could understand where this program starts at all.
But programmers are people like that, let them just complicate things. You think to grow a prototype of a boiler, and after a week you catch yourself thinking that you are sitting at a nuclear reactor. And how, damn it, the idea jumped from the boiler to the reactor, it is no longer clear.
And KISS, basically, falls into the opposite extremum. Where in the middle of development you realize that everything is so simple that a branch, generally speaking, a tree can have only one, and nothing can be done about it. We throw out the prototype, say that the prototyping sucks and start anew.
As it is usually said in films. “Forget everything you know!”, “To catch a cat, you need to become a cat!” And so on. But this is not about us. Do not forget anything. On the contrary, it would be good to remember examples of the extremes of the use of all sorts of techniques, so that in a moment of fleeting reflection in time to realize that it is taking you somewhere not there.
But, for some time, the brain will break and you will have to beat yourself with a ruler, of course. Well, we can not no longer think in the abstract and not complicate everything in my head.
So, what should be done so that the prototype tree does not wilt? Some seemingly simple principles:
Very short iterations and feedback
From the specifics of the project, you need to select the minimum time for iteration and be sure to launch the application at the end of each iteration on the target device / at the target audience. If you are making an interface for a large multi-touch table, do not be lazy, go to it and poke at the drawn buttons. Is it easy to reach them? Is it easy to hit them with a fat finger? Of course, the mouse can all on a small screen. Sit down rework!
Integrity
Nowadays it is assumed that several programmers are working on the same project. Everyone makes some kind of their own module. So, important modules should be developed in parallel, developers should be synchronized as often as possible. Ideally, once per iteration. The goal is to collect all working modules together as early as possible and see what happened.
It does not matter at what stage of development the module is now. And if (as it usually happens) the integration time has come, and the code is in such a state that nothing from the past ALREADY works, and from the new STILL does not work, it may be shocking you, but you can JUMBLE the COMFORTABLE places!
Solving current problems
Suppose there is a simple task for an hour or two. But, programmers are the same people as a chess player, in his head the game immediately turns 64 moves ahead. It becomes clear that then you have to do one thing, and in order to be expandable, the second. In addition, the move to 32m is already clear that in order to make photorealistic load balancing physics miscalculation need to start doing the third right now. Anyway, let's write a framework!
LINE IN HANDS !!! And then kicking! Now we solve only current problems. The fastest way. As practice shows, such sweeping features have a high probability of greatly changing or completely disappearing altogether.
Carefully follow the extremes
Well, we do everything quickly and stupidly ... NO! Well what are you again! Try very hard not to go to extremes and do everything right, completely stupid. You see where all this business will lead you - leave yourself moments for maneuver: tidy OOP with no frills, put it into the state machines components, make a little more settings than you need now, review the slightly expanded class. To do everything is simple and just what is needed does not necessarily mean to produce govnokod. It’s just that some people don’t have it any other way.
The maximum proximity of the assets to the final
All assets from the very beginning on the basic parameters should be adjusted as close as possible to the expected ones. Suppose that in the first prototype instead of pictures there will be lolcats from the personal archive of the developer, and instead of the planned FullHD video, thedownloaded purchased Iron Man 2 in BluRay quality.
If you plan to show 100 pictures, add exactly 100 of them (150 is better for reliability), instead of checking the entire prototype's life on three smoothly scrolling pictures. And then with surprise to find out that 100 pictures lag, hang and do not interfere in memory.
There are still a number of small arrangements that are not so important as to impose their use. All the same, every team that decides to live and work on similar principles soon comes to its own specific unspoken rules.
And I just hope that from this article everyone will take something useful for themselves. And that prototype trees will grow, and the word “prototype” itself will lose its negative connotation.
But what if I say that not all projects are the same, and some of them are not something that can be, but even need to be carefully grown from a prototype? I told about this at the Unite'12 conference , and now I will tell you.
Introduction
The idea to write this text has been gathering dust in my head for a very long time. But yesterday’s article “Why it’s not possible to turn a prototype into a final program ” suddenly became a real catalyst. It turns out that I suddenly can’t do what I’ve been doing successfully for two years and am proud of it.
')
While the disgruntled reader did not start quickly scrolling down, to be the first to write a comment and tell me how wrong I am, I want to point out one fact that (for some reason) many ignore - all projects are different! If you make an enterprise application, it does not mean that no one writes embedded systems, apps for smartphones or disposable presentations.
Hence the manifestations of violent holivor in the comments to any such post. So let me first talk about the specifics of the projects that I usually do.
Projects
I work in the company Interactive Lab . Basically, we do offline interactive installations, the creation of software for which is very different from the usual software development:
- There is no clear TZ ( here is an exhibition, make it cool! ),
- All projects are small, but very different ( completely different, and not “in that project we used mysql, but in this we will use mongodb - you will have to COULD THE CODE!” )
- Very short deadlines that cannot be transferred ( "sorry, we do not have time, please move Atom Expo to a month or two" ),
- Often they work only 1 day during the exhibition, and then they are thrown out ( update : but, at the same time, the code should be clear to correct it, if something breaks an hour before the deadline ),
- The combination of software and special iron,
- Full control over the iron ( slows down? Optimized? Yes, you know, let's go buy gtx 690 ).
So, I sit in the office, I don’t touch anyone, I read Habr, there, I eat a peach ... And then the boss comes up to me and asks a question that basically comes down to the following: “Valentin Vladimirovich, and how much will it take for you to do such a thing which we have never done and vaguely imagine how to do? .. Mmm, two weeks, right? ” Well, it turns out later that some kind of event in three weeks, the client “doesn’t know exactly what he wants, but he wants it very cool to have it all”, there are no assets, there are some ideas too ...
Process
The principle of iterative development is not new at all, and hundreds of articles are devoted to it, including on Habré. How is it, Agile evangelists say? We take, which means, a feature developer, we look at what we can do for the iteration, say, in two weeks. We do. We look again ...
So, stop! Fichist? We have neither TK, nor a clear idea of ​​what it all should be. Iteration in two weeks? We only have 15 working days, what a fortnight, are you !?
This is how we came up with the following algorithm:
- Brainstorm ideas.
- The simplest and fastest prototype with test assets in a day or two.
- Test on target gland.
- Totally sucks? GOTO 1.
- It seems not bad, but you need to change / add something.
- Update prototype for the day.
- If not yet deadline - GOTO 3.
- Sleep off.
As you see, by iterations of 1-2 days, the prototype grows into the final application. And it works great.
Passing through the eyes of the algorithm, following the cycle a couple of times and leaving it, you can immediately imagine its obvious advantages:
- The concept is created iteratively with feedback from the prototype. There is no need to write an exhaustive TZ before starting work, which also does not guarantee the success of the original idea.
- How good the concept can be seen in the first two days. There is nothing more unpleasant than to understand the day before the deadline that the whole idea sucks.
- Closer to the deadline there is always a ready application. It does not have all the features, it is not beautiful enough, but it can already be put on the exhibition. Such that we simply have nothing ready, it can not be in principle.
- All the nuances of the bundle of software + iron can be found out immediately at the stage of the first iterations. If you think that on your 9 screens and 5 video cards with a total resolution of 4098x2304, your application will work the same way as on an office FullHD monitor, you are greatly mistaken.
- Having played with the prototype, there is no need to rewrite everything * with more correct code * into the final application. The prototype itself will be an application.
Prototype
For some reason, most of the articles on prototypes are described as something temporary, nasty, sticky and unpleasant. Like, on a careless prototype, unscrupulous developers cheat more and more new features, turning it into a Frankenstein monster. And the main conclusion - you need to rewrite everything, and happiness will come!
I am sometimes asked a reproachful question: "Are you not ashamed of the code of your application, which turned out to be a gradual upgrade of the prototype?" . I, frankly, feel ashamed of all my code that I wrote more than a month ago. Why? Because over the past month, including while this code was being written, I personally grew up as a developer. And today I would write everything in a completely different way. Well, tomorrow I really would like to rewrite all this to hell! Therefore, every time I smile dirty when I hear offers to take and rewrite everything anew.
Let us think of the prototype as a tree, which by a certain date should blossom and bear fruit. It depends only on us that it will bloom with roses and sugar peaches will grow on it, or it will suddenly become covered with killer flowers, and we, as the perpetrators of this disgrace, will be put to chop them with a sword. At the same time, as in a fairy tale, two new ones grow on the place of a felled one. I think everyone already understood the metaphor.
In general, the convergence of written code to govnokod when the number of lines n> N strongly depends on a particular person. If your programmer sculpts tentacles to the prototype tree, not caring about his future, why do you think that you have rewritten everything anew, will he not end up asymptotically at the end of a similar result?
To do, simply, you need everything right. It is good to imagine that this is not a prototype to eject, but a living organism, which will greatly change from your actions at the germ stage, having grown into its final form. And this form can be STRONGLY different from what you laid in its genotype at the start.
And as your grandmother in her small vegetable garden outside the city pulls grass around sprouts, pruning them, planting some varieties onto others, you should also carefully monitor your prototype as it grows. This is what distinguishes a good programmer from a bad one. A good programmer sees where his code grows, what needs to be done now, so that later he does not have to chop dead branches; Understands how to carefully get rid of the beetles, terrorizing the tree; knows when to fence him so that it grows in the right direction.
KISS, DRY, OOP, design and other extremes
If I were given 10 rubles for each article in which KISS or DRY is mentioned, I would have bought a BMW 3 I dream about a long time ago. These buzzwords have already tucked into the belt a terrible OOP, on which The Gang of Four are sitting and whipping it with design patterns (that's another picture, of course).
All that matters is whether a person can grow a healthy tree from a prototype.
Specifically, in our realities, everything, moreover, needs to be done very quickly. Iterations a day or two, no more. So you start to fight with the unauthorized interpretations of KISS, DRY and all sorts of OOPs of the brain. What, honestly, does not always work.
It's like, sorry, with the ROC . Experienced priests, theologians and historians of religion, I suppose, know why this particular ceremony is such, although it looks very strange from the outside. But ask any of the 97% of other believers - you will receive the answer, they say, do as they said and you will be saved. And well, if not beaten.
And KISS, and DRY, OOP ... what else is there? Design all. All these are good concepts, but it takes a shiver when you see how they are applied in life. And you understand that such an application with the cultivation of a prototype is compatible a little less than nothing. Hence the terrible lame trees with cannibal flowers.
Especially when a person is thrown into extreme situations. If OOP, then it is necessary to have 100,500 abstract classes and an interface for each, moreover, in order to create something concrete, you need to do it through a special factory of factories of builders. But the sheer DRY. Everything is mega abstract and no code is repeated. And no one bothers that in order to achieve all this, it took you to write 20 times more code. But also IoC with DI should be fixed so that absolutely no one could understand where this program starts at all.
But programmers are people like that, let them just complicate things. You think to grow a prototype of a boiler, and after a week you catch yourself thinking that you are sitting at a nuclear reactor. And how, damn it, the idea jumped from the boiler to the reactor, it is no longer clear.
And KISS, basically, falls into the opposite extremum. Where in the middle of development you realize that everything is so simple that a branch, generally speaking, a tree can have only one, and nothing can be done about it. We throw out the prototype, say that the prototyping sucks and start anew.
So what to do?
As it is usually said in films. “Forget everything you know!”, “To catch a cat, you need to become a cat!” And so on. But this is not about us. Do not forget anything. On the contrary, it would be good to remember examples of the extremes of the use of all sorts of techniques, so that in a moment of fleeting reflection in time to realize that it is taking you somewhere not there.
But, for some time, the brain will break and you will have to beat yourself with a ruler, of course. Well, we can not no longer think in the abstract and not complicate everything in my head.
So, what should be done so that the prototype tree does not wilt? Some seemingly simple principles:
Very short iterations and feedback
From the specifics of the project, you need to select the minimum time for iteration and be sure to launch the application at the end of each iteration on the target device / at the target audience. If you are making an interface for a large multi-touch table, do not be lazy, go to it and poke at the drawn buttons. Is it easy to reach them? Is it easy to hit them with a fat finger? Of course, the mouse can all on a small screen. Sit down rework!
Integrity
Nowadays it is assumed that several programmers are working on the same project. Everyone makes some kind of their own module. So, important modules should be developed in parallel, developers should be synchronized as often as possible. Ideally, once per iteration. The goal is to collect all working modules together as early as possible and see what happened.
It does not matter at what stage of development the module is now. And if (as it usually happens) the integration time has come, and the code is in such a state that nothing from the past ALREADY works, and from the new STILL does not work, it may be shocking you, but you can JUMBLE the COMFORTABLE places!
Solving current problems
Suppose there is a simple task for an hour or two. But, programmers are the same people as a chess player, in his head the game immediately turns 64 moves ahead. It becomes clear that then you have to do one thing, and in order to be expandable, the second. In addition, the move to 32m is already clear that in order to make photorealistic load balancing physics miscalculation need to start doing the third right now. Anyway, let's write a framework!
LINE IN HANDS !!! And then kicking! Now we solve only current problems. The fastest way. As practice shows, such sweeping features have a high probability of greatly changing or completely disappearing altogether.
Carefully follow the extremes
Well, we do everything quickly and stupidly ... NO! Well what are you again! Try very hard not to go to extremes and do everything right, completely stupid. You see where all this business will lead you - leave yourself moments for maneuver: tidy OOP with no frills, put it into the state machines components, make a little more settings than you need now, review the slightly expanded class. To do everything is simple and just what is needed does not necessarily mean to produce govnokod. It’s just that some people don’t have it any other way.
The maximum proximity of the assets to the final
All assets from the very beginning on the basic parameters should be adjusted as close as possible to the expected ones. Suppose that in the first prototype instead of pictures there will be lolcats from the personal archive of the developer, and instead of the planned FullHD video, the
If you plan to show 100 pictures, add exactly 100 of them (150 is better for reliability), instead of checking the entire prototype's life on three smoothly scrolling pictures. And then with surprise to find out that 100 pictures lag, hang and do not interfere in memory.
***
There are still a number of small arrangements that are not so important as to impose their use. All the same, every team that decides to live and work on similar principles soon comes to its own specific unspoken rules.
And I just hope that from this article everyone will take something useful for themselves. And that prototype trees will grow, and the word “prototype” itself will lose its negative connotation.
Updates
- He added to the description “but, at the same time, the code should be understandable in order to fix it, if something suddenly breaks an hour before the deadline” . Because many people paid attention to the lifetime of the installation. BUT! This does not mean at all that the quality of the code all put.
Source: https://habr.com/ru/post/155165/
All Articles